HN user
Scientist, sysadmin, mostly lurker.
Some additional discussion at NextPlatform.
It's an all-CPU system, but the CPUs have Scalable Matrix Engines on them, and a lot of cores, adding up to something that resembles GPU-scale parallelism, so it is accelerated in that sense, rather than in the sense of having separate discrete accelerators.
https://www.nextplatform.com/hpc/2026/06/25/a-deep-dive-on-c...
Interestingly (to me), I learned about the "ridgeway" just a few days ago, from Jim Leary's episode on the "History Rage" podcast, where historians vent about popular historical misconceptions.
For the Ridgeway in particular, the claim from the podcast is that there is in fact no archaeological evidence that this was a prehistoric routeway, nor that it was a single coherent long-distance entity. The claim is that it appears this way because highland areas and ridges are better preserved, because they're generally not cultivated and are less subject to erosion, so the whole thing is just a selection effect.
Discussion starts around 39:25 in the podcast[1]
Jim Leary has a book about this, "Footmarks: A Journey into our Restless Past"[2].
To be fair, I personally am ill-equipped to assess the claim, and it does look like an interesting place to ramble. The linked article also, to continue being fair, does not call it a road, they limit themselves to calling it a "prehistoric trackway", which may well be defensible.
[1] https://www.historyrage.com/episodes/episode/69e607e6/histor...
[2] https://uk.bookshop.org/p/books/footmarks-a-journey-into-our...
Slightly OT, but if you are interested in this sort of thing, William Dalrymple and Anita Anand co-host the Empire podcast, which has many episodes and guests and recommended reading covering lots of ancient history.
I'm not affiliated with it, I'm just a fan.
I think yes?
Kinetic energy scales as velocity squared, so a car at 100 MPH has 4x the energy of a car at 50 MPH. But in the 50 MPH scenario there are two cars, so the total energy dissipated in the 50 MPH head-on collision is half that of the 100 MPH brick-wall collision. In the brick-wall case, presumably all the energy is available to demolish the one car, but in the head-on case, the energy is spread out demolishing two cars.
Impact force is maybe trickier, it depends on the acceleration, but if the two 50 MPH cars end up with zero momentum, then they have 50 MPH of delta-v each over some collision time. The single car of course has 100 MPH of delta-v. If the collision times are the same (arguably a reasonable approximation if the head-on is a highly symmetric), then the impact force in the head-on case is half that of the brick-wall case.
Vaguely reminds me of the Adapteva Epiphany RISC multi-processors from the old Parallella Kickstarter project, and presumably others, but that's the one I played with for a while.
I'm not sure how this project's interconnect differs, they do say theirs is revolutionary, maybe that's the difference.
[1] https://www.adapteva.com/epiphanyiii/ [2] https://parallella.org
Lovely. "The Mythical Man Month" was a recommended supplementary text when I was in undergrad computer science, and it was well worth the read, especially for me -- I have a tendency to get hung up on the cool tools and fun methods in programming, which is OK in hobby environments, but if the purpose of the software is to solve a problem, you need to keep an eye on the problem. The book extends this insight to managerial methods, famously, and to me feels akin to Goodhart's law, about how once a metric becomes a target, it ceases to be a useful metric.
There's a great interview with Frederick Brooks on Youtube, not specifically about the System/360, but the guy was amazingly self-aware: https://www.youtube.com/watch?v=ul0dbgs8Mdk
I'm not sure if this is a fair question or not, but suppose I have a 6-byte blob I want to send. I can pad it out to 8 bytes, use this scheme to encode it, and send it.
Then I want the receiver to understand that only the first 6 bytes of their decoded results are part of the transmission -- how do I do that?
Base64 has a special character ('=') that is used for encoding padding, but this method doesn't seem to have that. The spec says "it is up to the application to ensure that frames and strings are padded if necessary", which suggests they've scoped this problem out.
I suppose I can always build a little "packet" that starts with the payload length, so that the receiver can infer the existence of padding if there is additional data beyond the advertised payload length, but now the receiver and I need to agree on that protocol.
I noticed that too.
I was also surprised that they called out the complexity of EV drivetrains (and charging systems, but I don't know anything about those) as a factor. My prior understanding was that EV drivetrains are significantly simpler than ICE ones, the number of moving parts is comparatively low for EVs, and you don't have the large temperature gradients and intense mechanical impulses that come from repeatedly igniting fuel/air mixtures.
I don't dispute the empirical claims, but as the parent comment implies, I think this is mostly about the maturity of the repair ecosystem, and it's reasonable to expect that that will improve as EVs become more prevalent. It's not a reason to stop, it's a reason to keep going.
Sorry for the late reply, but no to all three. We lived in Chicago when this became a thing. My grandmother did live in Denver (well, Aurora) though.
The article being from 2011 is perhaps why it can be as long as it is without mentioning "Coarse-grained reconfigurable arrays", or CGRAs, which, at least as of 2019 when I learned about them, seemed to occupy a good middle ground between conventional CPUs and FPGAs.
The idea is that, instead of being a bunch of gates like an FPGA, the components of the CGRA are at the scale of an ALU, or maybe an on-silicon network switch, with a single CGRA having different parts that are optimized for e.g. numerics, IO, encryption, caching, etc., which you can knit together into the processor you need.
That's maybe where this idea went?
Here's a more recent link covering similar ground:
https://semiengineering.com/specialization-vs-generalization...
First hit for me is the Bluesky social media logo.
I love this, it's got that "technical correctness is the best correctness" vibe going on big-time, and it will probably change the way I see that slice of the world.
Butterflies loom weirdly large in my life, at one point many years ago my grandmother decided that butterflies were my wife's "thing" (they aren't, we're not sure how this happened), and so for many years we got butterfly-themed gifts from her. It was merely odd, so we just rolled with it, but now we have various butterfly tchochkes around, all of which, a brief survey reveals, are in the dead pose.
I learned about this after stumbling across the "Museum of Jurassic Technology" in Los Angeles, several years ago.
It was pretty clear from the outset that it wasn't a "real" museum, and one should not take the labels at face value, but as I worked through the collection, the random inconsistencies started to gel into a coherent sort of museum parody.
Searching around afterwards led me to the pataphysics movement.
Googling the museum again, I see it's now "by advance registration only", so I guess it's harder to stumble across, but I liked it.
Definitely not my field, but a colleague of mine in grad school who was doing GR stuff was convinced that black holes didn't have singularities.
As I recall (it was a long time ago), it was mostly an aesthetic preference, he felt it was far more likely that at very high curvatures or energies or both, the domain of validity of GR would be exceeded, and Something Else would happen that preserved the theory in the low-curvature regime.
It sounds like that's not even required, if I'm reading this right (did I mention it's not my field?), it sounds like even within GR, singularities are avoidable? Very cool.
And in French, in particular, it's named after India, but the word is an abbreviation and contraction of the phrase "poulet d'Inde" ("Indian chicken"), which got shortened to "dinde".
Even more radical proposal: Make this restriction on senior corporate officers. Your salary can depend on how well the company does, but your investment portfolio depends on the broader market.
I mean, as long as we're using investment restrictions for social engineering.
On the one hand, I am not surprised -- at my workplace, we only ever had one Itanium system, an SGI Altix 3000-series computer. It was kind of niche even when we bought it, and core-for-core, the Itanium CPUs were slower than their competitors. What the SGI was really good at was MPI parallelism. I don't know how much of that was the CPU and how much was the overall system design of the Altix, which featured a pretty amazing interconnection fabric (CrayLink, I think?), and cache-coherency and a sophisticated memory model. But not all problems parallelized well, so the system ended up kind of being this weird outlier that was a good answer to some classes of problems, but you had to remember it existed.
On the other hand, it's a bit of a shame to formally, officially lose another option out of the computing ecosystem.
These are interesting and fun. Each issue follows a particular theme (youth, risk, energy, time, etc.) and I occasionally wondered if they would run out, but they seemed to keep going. Articles were an interesting mix of deep dives and short bits that make you go "huh".
Lewis Lapham also has a podcast, where he interviews authors of books he's liked.
Commander Koenig.
The article implies pretty strongly that there is an ozone problem that's independent of the smoke problem, so the proposed ozone controls are still necessary, and that erasing two days of bad air quality by attributing it to wildfire smoke is an over-broad exemption that disguises a real local source of additional air quality issues, but it doesn't offer supporting evidence, or come right out and say that.
Supporting evidence is offered that the actual air quality was actually bad, and that this had adverse health impacts, but as far as I can tell, that is not in dispute. What is in dispute is the extent to which this justifies imposing additional air quality regulations locally.
Sure, Wayne County is working the refs on the air-quality rating system, but it's not obvious to me whether they're justifiably avoiding responsibility for issues that are not their fault, or using those issues as cover for negligent inaction. The article doesn't offer much support to disentangle these positions, notwithstanding their evident editorial position.
This is very cool, as are a lot of older algorithms, and some newer ones. Probably mechanical computers had lots of under-the-hood optimizations that would be interesting to dig into.
It reminds me of e.g. the CORDIC algorithm, used to calculate trig functions (needed by rocket guidance systems) with a combination of fixed-point arithmetic and table look-up. Doubtless there are many others.
Not mentioned in the article, but if you add the key to your agent with "ssh-add -c <key>", then whenever the key is used to connect to another machine by the agent, the agent will prompt (on the machine where it was initially run) to confirm that the connection is intended, generally via "ssh-askpass".
In my world, I use this routinely, precisely to detect a connection using a hijacked session, as described in the article. It does not detect the agent hijacking itself, it only detects new connections -- it pops up for all connections, both intended and unintended.
I know we're all supposed to do defense in depth, but I confess to having a bit of a jaundiced view of attacks that begin, "first, become root on a machine in the target domain....". Containment is a good idea, but if you're at the point where you're doing containment of compromised root accounts "inside", things have gone pretty far wrong already.
Selecting what metrics to use for categorization in a scientific study is a subjective choice, and searching for objective measures can de-contextualize your data.
You might want to give this more thought -- on reading the piece, my take-away was, "this guy is a half-step away from inventing the slide rule".
IMO, what the slide rule does is replace the memorization of squares and roots, or of logarithms of digits. I've never used a slide rule professionally, but I've noodled around with a few (I inherited a fancy one from my grandfather), and it really forces you to think about scaling and precision in a way that's different from both calculator and pencil-and-paper arithmetic, and the idea of knowing how to do the mantissa, and then using logical rules to infer the order of magnitude, is central. I think that's the through-line of the article, too, or at least it seemed so to me.
We have a related issue in US civilian Federal agencies, where the IT security posture has been moving for some time to a formal compliance scheme. The idea is that to manage things at scale, it's desirable to have certified solutions, and mandate a very broad set of controls.
This makes general-purpose Linux systems a hard sell -- Ubuntu and RHEL have e.g. FIPS-validated encryption stacks, but they're generally older releases (currently Ubuntu 20.04 is certified and 22.04 certification is pending), and of course limiting your choice of distro is unwelcome for computational researchers. For data at rest, there are certified self-encrypting hard drives, but they are very hard to source, in part because the FIPS 140-2 suite is also very old, and the newer FIPS 140-3 suite is not yet certified.
There are probably ways around this, the diversity and flexibility of Linux cuts both ways, so you can maybe do a FOSS VM infrastructure on top of a certified hypervisor, and get the best of both worlds that way, but it's a lot of work.
And unlike in the aviation-safety world, it's not clear that the certified solution is technically better. It has pluses and minuses, but the biggest plus is administrative, not technical -- it's easy to check.
Seconding this, for sure. "/usr/sbin/sshd -T" (T for "test") has been a life-saver more than once.
My strongest version of this is that any application that manages any state should be able to report on that state in a human- and machine-readable way.
I remember writing a GTK extension widget many years ago, and yes, it was very much like this. The macros end up making your very own hand-coded vtable-equivalent, so that function calls get dispatched to the appropriate point in the inheritance chain. It was pretty eye-opening!
I recently read what you might call an "apprecation" of the Sextant, the navigational instrument -- it was a mix of a travelogue of the author's trip across the Atlantic, a narrative history of nautical navigation, and a technical exploration of the sextant itself.
The relevance here is the history of navigation -- finding, losing, re-finding, and re-naming islands happened a lot, especially in the south Pacific. Nice reminder that the growth of knowledge isn't always linear.
The book is "Sextant: A Voyage Guided by the Stars and the Men who Mapped the World's Oceans", by David Barrie.
Thanks for the link to the paper, it clears up some issues I thought I might have had. It's nice to see an appreciation that some of the systems for which we require safety are "intractable" in the sense they describe, that is, not amenable to decomposition into parts where rules can be applied in isolation.
My favorite safety book, Charles Perrow's "Normal Accidents", is sort of about that too, although it's not at all prescriptive.
The concern I thought I might have had, from the Safety4Sea article, is that it wasn't clear to me how you distinguish "the system working correctly" (normal work leads to a result with no adverse events) from "the system being lucky" (normal work is blind to some risks which arise rarely, and didn't arise this time). The paper looks like it's much clearer on "Safety II" being about understanding what went right, which is very reassuring.
I used to use this system in undergrad at the University of British Columbia, one of about ten or so installations. It was pretty cool at the time. I (dimly) recall it had something like output redirection, when you run your compiled executable, you can assign virtual devices ("PRINT" for the printer, e.g.) to various channels, and avoid storing files, which was constrained and costly.
A few things I can't believe we lived with -- a flat file-space, and I think 8.3 file-names?
It ran a lot of "standard" IBM OS/VS utilities, and I spent many happy hours in my summer internship squeezing a few extra milliseconds out of my FORTRAN-H executables.