Just looking back, we were using the hybrid ".uucp" pseudo domain in 1995, e.g. see the contact details for the third author on this papes: https://www.researchgate.net/publication/2291331_Beyond_Hack... (not me, a colleague). For those who don't recognise this, .uucp was an unofficial "TLD" used for UUCP-based email systems accessible via an Internet relay by a dial-up modem. The relay would rewrite jlc@bmtech.uucp to bmtech!jlc, a short UUCP bang-path email address.
"Munitions"? "Intelligent distribution panel"? Look, the UNIX part might not be obvious at all, but if you somehow didn't have enough of a rough idea after seeing that many retro CPUs and systems listed below, that might say more about you than the author.
That wasn't ever in doubt. That's also not the relevant piece of information - people looking for a summary want to know why the thing is worth paying spending time on, not random attributes
You do realize when you say that you do assume they know it's an OS and by that you effectively have to regress into using the same level of argument as me just like how I assume they don't know it's an OS, right?
On the last 64 bits, yes. On mobile phones, the first 64 bits may be fixed. This was something I argued against when I was at Vodafone Group, but didn't get any traction. That was a while back, but I'd assume that this is still the case, and that mobile phone addresses can be used for tracking.
The story about "the width of the backsides of two Roman horses" is just a myth. Which should be obvious if you look at the many different railway gauges in use. You can trace it back to 19C standardisation, and argue over whether Brunel's 7'¼" was better than standard gauge, or if we should all have converted to 3m Breitspurbahn, but that's a different question.
Yes - but that's the gauges you are taking as standard. In fact narrow gauge railways are pretty common, since they are easier and cheaper to put through some landscapes. But as for main line high speed / high load railways, the balance of cost vs utility usually works out the same. Another major effect is standardisation in Victorian Britain (which is why Brunel's gauge on the GWR was replaced). Those engineers went out in to the wider world, and took standard gauge with them, and often the locomotives were manufactured in Britain. Hence the long distance railways often use exactly the same gauge - but the exact measurement was a matter of Parliament deciding on what compromise to draw based on early railway lines, bearing in mind that it was a lot easier to reduce gauge rather than increase it.
But this doesn't really contradict the myth. You certainly can have rail gauges that are _smaller_ than two horses' asses. You don't _have_ to use all the available width all the time.
It's the lack of something significantly larger that matters for this myth.
> Hence the long distance railways often use exactly the same gauge - but the exact measurement was a matter of Parliament deciding on what compromise to draw based on early railway lines, bearing in mind that it was a lot easier to reduce gauge rather than increase it.
The Russian railway was specifically designed to be incompatible with others (it's slightly larger) to make it harder for invading forces to use it. But even then it was not that much different from others.
I can't say I'm wild about a world where Digital Research won. When they were dominant with CP/M, the tools and documentation were bad to the point where most machines had Z80 processors and DR only provided an 8080 assembler, so you had to DB significant bits of code to get the missing opcodes. Developing RSXs to access bank-switched memory under CP/M 3 could have been so much easier with a few examples and perhaps debugging tools. MS/DOS was just so much easier.
I remember using a Z80 assembler on a CP/M 1.x machine, way back when. If it wasn't by DRI could it possibly have been (shock, horror) Microsoft??? We did have a Microsoft Fortran compiler, which was crap, but that was mostly down to being floppy disk based.
Not trying to be funny, I used the assembler a lot, but I really can't remember who supplied it.
Oh, just had a thought - this was on Research Machines 380Zs, so perhaps it was Research Machines home-grown one?
Yes, there were one or two third party assemblers available. From memory, the issue was with the downstream tools - so for instance on CP/M 3.0, I think you had to use the DR one to be able to build an RSX (equivalent of a TSR under DOS. You could count the number of 8080 CP/M 3.0 machines on the fingers of one foot.
You've reminded me that I have a 380Z or 480Z in the loft - I must get it going again.
DR-DOS was more than alright, if Microsoft hadn't smothered it the computing world would look very very different today …
I'm sure this is a mostly forgotten part of computing lore; apologies for the Gemini's Overview:
“Microsoft actively stifled DR-DOS in the early 1990s through anti-competitive tactics, primarily using the "AARD code" in Windows 3.1, which deliberately created compatibility errors to scare users away from the competing operating system. Microsoft also used FUD (fear, uncertainty, and doubt) tactics, such as hinting at future incompatibilities.
Key Tactics Used by Microsoft:
The AARD Code: Windows 3.1 installer contained heavily obfuscated code, discovered in 1992, that specifically checked if the system was running DR-DOS. If detected, it displayed a fake "Non-Fatal Error" message to induce panic.
Vaporware Announcements: Microsoft announced upcoming versions of MS-DOS to dampen demand for current versions of DR-DOS.
OEM Pressure: Microsoft leveraged its monopoly to ensure pre-installed Windows came with MS-DOS, hindering DR-DOS's retail market success.
While Digital Research released a patch (the "business update") to bypass the AARD code, the damage to market perception and OEM deals was significant. The case was later part of legal battles between Caldera (which acquired DR-DOS) and Microsoft.”
Yeah we know of the issues, and related lawsuits, and here we are OEMs still only sell GNU/Linux devices on their online shops, leaving to regular consumer stores Android, WebOS and Chromebooks.
Ah, and Valve had to come up with Proton, as game studios can't be bothered to natively target GNU/Linux.
reply