But we're talking about a system that is also older than most people.
It was first put into operation in 1967 in the U.S.A., and brought over to the U.K. in 1974. It's formally called 'NAS En Route Stage A', and is written in a 1950s language named JOVIAL. It originally ran on an IBM 9020. It runs on IBM 9020 compatible systems today.
For some reason, a couple of years ago someone added a lengthy unverifiable description of it to Wikipedia's IBM 9020 article, even though that very description said that NAS hadn't run on a 9020 for 34 years at the time of writing, but had been running on a 4381.
A lot of people have already made almost all of the same observations that I was going to make.
Except for: There is no bug that originates in a GNU version of an old networking program and magically makes its way into the NetBSD, FreeBSD, DragonFlyBSD, and OpenBSD (Yes; I checked.) versions of that program.
History simply didn't happen that way.
This bug goes as far back at least as far as the Jolitz-released 386BSD source for libexec/telnetd , where it can be found and which is credited in the GNU versions of the file. GNU just took the 386BSD code. But BSD had a telnetd before 386BSD. In BSD, telnetd itself goes back to 1983. Although its code to do line mode did not pre-date RFC 1116, which was published in August 1989.
The code to do line mode was written the month after that RFC, by Paul Borman, and the bug is in the very first version of that code:
It's sad that this is probably going to become canon, now, Raymon Chen being as influential as xe is, when what actually happened was that in 1998 H. Peter Anvin saw UD2 in Intel's doco, and that there was a second opcode that was just described by Intel as merely undefined, so gave it the mnemonic UD1 in the 0.98p3-hpa version of NASM because 'calling it UD1 seemed to make sense'.
That's is famously not what 'dd' was designed to do. Its description in the original Unix 6th Edition manual was 'convert and copy a file'. It's infamous for people mis-remembering it as a disc copier when it was actually a file transcoding utility that understood EBCDIC and could re-block things.
I think we are saying the same thing. By disk, i meant disk I/O which is the main practical purpose of the tool. Of course, Linux being Unix, a raw disk is a file, so is /dev/null.
Of course a file can be everything, which is a kind of the point of Linux. But that doesn't change the fact that 'dd' is for disk (or file) I/O. Also please don't argue semantics, it leads nowhere.
But that's not the main point. The main point is the Rust coreutils version of dd is slow. I highly doubt it's impossible to write an implementation in Rust that's as fast as the C one. But the Rust community needs to invest time and energy into finding why that's the case and fixing it. Until that happens the broader Linux community is right to push back on adopting it.
But I guess that shows another weakness of Ubuntu's model of versioning. You can't fix a bug if they don't merge. They have their own bugtracker (and so does every distro?) so you, Mr Dev have to deal with angry users not only on your Github Issues page, but on every distro's own bugtracker as well, and will have to perpetually support whatever old version they decided to shit (times X distro).
Does that mean BTW that they'll keep shipping the same broken dd for the next 2(4) years?
The apparently related bug in the origin project is https://github.com/uutils/coreutils/issues/2949, filed back in 2022 and which sat unmoved for several years until, probably not coincidentally, almost the same time yesterday that this appeared on Hacker News.
One of the few good things to have come out of this repeated silliness, is that for 2 years I've witnessed people reading more about what is being altered by these executive orders and sourced by Google Maps et al. and learning why the U.S.A. GNIS is such a woefully bad data source.
And it's not because of the antics of Donald J. Trump. It's been a shit-show for 50 years: a tale of long-term multiple-phase projects losing funding and changing direction mid-phase, of technical debt never dealt with, of the consequences of data entry methodologies, and of cultural erasure because of magtapes encoded in EBCDIC.
(Yes, EBCDIC. There wasn't a systematic deliberate plan to eliminate diacritics from the U.S.A. in the 1970s, as one might guess from observation. There was EBCDIC. In fact, there was initially a plan to put the accents back on, with extra data fields to record the correct names from state-level sources, after moving away from EBCDIC. During the Reagan Era. You can see today how that turned out.)
One bizarre thing, almost as bizarre as the re-spelling of an entire country by EBCDIC, is that the name change from South Park to South America is tame in comparison to the sort of shenanighans that went on in the GNIS. Ghost towns that never existed got named after rural post offices in wide open unpopulated country, railway stations, steam train water stops, local stations serving farms, company executives, loads of springs in California, and in extreme cases things like a fish pond, survey marker trees, and a cage for a monkey. Or a lone building at a crossroads got the name of something else because a map font was difficult to distinguish, or a name printed by something else just happened to run over it.
And then some people handy with computer automation enshrined this rubbish, by mass-importing it into Wikipedia. Wikipedia is still cleaning this up by hand almost two decades later. Oh the wonders that we have collectively done with computers! (-:
The creators of South Park have a long way to go before they are anywhere near as mad as actual history is.
I read the article thinking that it was not going to mention Dymaxion. Articles like this rarely do. The BBC has an article on the U.N. resolution (https://www.bbc.co.uk/news/articles/cly5r60v4mro), and it does not.
And then right at the bottom it went and mentioned Dymaxion.
Dymaxion is one of the few projections that actually shows Antarctica with something resembling its actual shape. Interestingly, to counter the people who say that the best thing to learn from is an actual globe, a couple of children's globes of the world that I had as a child had large metal caps around the axle that obscured most of Antarctica.
Any decent atlas uses a variety of projections, of course. The tatty, second-hand, older-than-I-am atlas that I had at school was already on to Interrupted Mollweide's Homolographic by page 3. (-:
Honestly it's so difficult to find a map that satisfies all of one's requirements for teaching kids if you're a bit rigorous.
I might be asking bit too much but I want Antarctica to be shown correctly, I want all microstates to be shown, I want all the "(UK)" and "(FR)" mentions for overseas territories to be there, ideally Taipei to be shown as a capital, etc, and that's only what I care about, I'm sure there are dozens of other details I don't think of that are wrong on most maps.
I ended up making my own world map with d3 (that was 10 years ago, I don't know what I would use today) and print it at a print shop. I printed a dymaxion map (with ocean blue for the gaps) and another more "normal" projection though I don't actually remember which one, with Antarctica as an insert. It wasn't even expensive, and in addition I was able to put all the names in both French and Dutch.
You might assume that in Belgium, it would at least be possible to find bilingual maps but no, if you can find one that's not in English you're already lucky.
I really like oblique projections. Have you seen this neat one from Kerkovits - A Low-Distortion Oblique Map Projection of the World’s Landmasses (2024)?
Even computer maps at the time like Google Earth had distortion around the poles, as if they were pieced together in slices. So that combined with the globe caps are why I never really knew what they looked like as a kid.
You might get a kick out of the AuthaGraph projection, if you haven't seen it before (although Antarctica may be a smidge distorted relative to dymaxion)
Both the world's population (with 88% to 12%) and landmass (with 68% to 32%) favor the northern hemisphere, so it makes sense to favor it in a general map as well.
Australians are mostly the descendants of British colonists (and prisoners) - the most successful colonizers in history - so the answer is what you might expect.
> Interestingly, to counter the people who say that the best thing to learn from is an actual globe, a couple of children's globes of the world that I had as a child had large metal caps around the axle that obscured most of Antarctica.
"I had toy globes which, unlike actual globes, covered up significant chunks of Earth, so actual globes are bad"
As the one who contributed the autotools build system and CI job for posting source tarballs in various formats, I can assure you it was not "unintentional". Distributing that many different compression formats for the same source archive and even including an uncompressed version of the same archive has little practical purpose except benchmarking / demonstration.
reply