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.
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.
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.
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.
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 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.
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:
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.
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.
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...