I'm pretty sure CP/M 86 was already a thing. I believe there was even Concurrent CP/M 86, which let you run up to 4 (or more?) virtual sessions concurrently. Light years ahead of MS-DOS but nobody wanted it, so DRI dumbed it down and added MS-DOS compatibility and re-released as DR-DOS (still superior to MS-DOS though).
CP/M-86 was definitely a thing, but CP/M-386 was not. By the time the 386 existed, DRI had dropped the CP/M name in favour of Concurrent DOS - though they had MS-DOS compatibility in Concurrent CP/M - and, as you say, eventually renamed it to DR-DOS.
Much as I loved DR-DOS, it did have occasional compatibility hiccups.
Also, it was super common practice to just go direct to undocumented internals. You didn't have a clean API to duplicate, you had all the untamed glory of a CPU with no MMU to deal with, and all the programs that did shonky things because they worked.
> which let you run up to 4 (or more?) virtual sessions concurrently
On the console -- but the selling point was that you could also attach dumb terminals to the serial ports and they could run DOS apps too. So you had a cheap multiuser box, where adding 3 or 4 or 8 more users cost about 10% as much as a network with 3 or 4 or 8 more client PCs.
> Light years ahead of MS-DOS but nobody wanted it,
No, not at all. One descendant is still supported today, some 45 years later.
> so DRI dumbed it down and added MS-DOS compatibility
No, not even slightly.
> and re-released as DR-DOS (still superior to MS-DOS though).
Not a fair description at all.
Here's how it went:
MS-DOS beat it to market.
So, DR brought multitasking and multiuser from MP/M to turn CP/M-86 into Concurrent CP/M: CCP/M-86
MS-DOS did great. So, lots of apps.
So, DR added DOS compatibility to CCP/M.
It also did a single-user OS, called DR DOS Plus. Oversimplification: this was a single-user non-multitasking CP/M-86 that read/wrote FAT and could run DOS apps.
Intel did a new chip, the 80286.
DR ported to it. A native protect-mode 286 OS, which used new 286 features to pre-emptively multitask DOS apps.
Intel removed those features before it launched the 286. This killed DR's new OS.
So, it refocused: it temporarily dropped DOS compatibility, and sold it as an RTOS instead, with a multitasking version of GEM as its GUI.
Intel put the features back and Concurrent DOS 286 became a product but it was too late. This was a better OS/2 before OS/2 1.0 launched.
Intel put DOS multitasking into hardware in the 386. DR rewrote CDOS286 in C creating CDOS386.
This had really good DOS compatibility.
So DR updated DOS Plus to make DR-DOS: a superset of MS-DOS 3.3, with FAT16 for big hard disk, and it could run DOS device drivers.
This did OK.
IBM did DOS 4. Bigger, but with big disk support, and a GUI app launcher/file manager.
DR leapfrogged with DR-DOS 5: all that, but smaller, with built-in memory management.
A brief arms race ended with Win95 which bundled MS-DOS and so killed the DOS market.
Meantime, DR took the better DOS compatibility and made Multiuser DOS, which did well and throve for decades.
cp/m-86 targets 8086, which is no more useful or relevant to 386 protected mode than the original z80 version. Did you think they just picked the 68k version at random?
> cp/m-86 targets 8086, which is no more useful or relevant to 386 protected mode than the original z80 version. Did you think they just picked the 68k version at random?
The big reason for picking the 68K version is it was mainly written in C (initially in Pascal, but they later switched to C.) By contrast, the more famous 8080 versions were largely written in assembly, as was the 8086 version.
Well, CP/M-80 1.x was mostly written in PL/M, a dialect of PL/I developed by Gary Kildall, but CP/M-80 2.x+ was rewritten in assembly for speed; PL/M was still used for some of the utilities. Obviously, C compilers are much easier to come by nowadays than PL/M compilers are.
Climate Activist: The oceans are getting warmer & global currents are threatened by imminent collapse - we must do something!
Big Oil: Prove it!
Climate Activist: Data gathered between 2016 and 2026 shows ...
Big Oil: That's old news! Do you have more recent data?
Climate Activist: Well, no, because Trump2 dismantled the ocean observation system in 2026 ...
Big Oil: So you have no data to back up your claims?
Climate Activist: Not recent data, no, but ...
Big Oil: Case dismissed! Why should anyone take action based on subjective opinion, not backed up by hard data? For all we know the oceans could have miraculously cooled & the currents are fine!
It's mostly just about getting the data out of the news cycle. If you don't have new data on the oceans warming then there's no news story, so less pressure on Big Oil to greenwash their industry.
"Valuable to society" and "valuable in the sense that it produces a profit for a business funding it" are different things. This is the reason why we have government funding.
A self-inflicted situation that is preventable and gets increasingly bad over time with no limit to how bad it can get, is a crisis.
We're already today experiencing some consequences of that. They're going to get worse, not better. The easiest time to prevent the amount of worse they could get, is to act now.
That's why it's a crisis. We are today creating our situation 20 years in the future, which currently looks bleak.
New users are probably the only ones who really need guided product tours. If I'm a longtime existing user I'm far less likely to be interested in a guided tour.
If your usability is good, you don't need a guided tour even as a new user because you can just figure out as a new user how it's supposed to work and get your job done. Guided tours and documentation should be limited to expert features that only a very rare subset of people need. The things everyone does should be obviously easy to use right away and so no helping or tour is needed.
Happened to me too! Guy posted asking kinda rudely whether I was going to fix a bug. Told him I'd be happy to accept a PR for a fix. Never got a PR (project has been dead for some years now - just lost interest).
^ This. People bemoan the death of coding, but easily 80%+ of the code I've written commercially was just CRUD or ETL shite. I've done a few interesting things (a formula parser, a WYSWIG survey builder for signature pads, a navigation controller for line-guided industrial vehicles, etc.) but yeah, don't miss writing reams of boilerplate. I always tried to take a Kent Beck inspired Smalltalk/TDD inspired approach to the code I wrote and took pride in my work, but ultimately you're working in a shitty corporate environment where none of your colleagues cares because they're burning at both ends, the management only does lip service to Quality, and Deadlines and the Bottom Line are Everything. If LLMs make this shit more bearable then bring 'em on, I say!
> I always tried to take a Kent Beck inspired Smalltalk/TDD inspired approach to the code I wrote and took pride in my work, but ultimately you're working in a shitty corporate environment where none of your colleagues cares because they're burning at both ends, the management only does lip service to Quality, and Deadlines and the Bottom Line are Everything.
LLMs are a multiplier. If this depressed you, then there is no way I can see the following happening.
> If LLMs make this shit more bearable then bring 'em on, I say!
What LLMs are going to do is multiply the amount of "none of your colleagues care" and "Management only does lip-service to ..."
It's not that none of my colleagues care, or that management is necessarily bad. That doesn't help, but it's not the cause.
It's the nature of the job. A CRUD REST server needs to be built. It's a shitty job, but someone has to do it. The interesting part of the job is over there, in whatever actually-novel part of the system is being built. But someone still has to build the CRUD REST server. There are frameworks and patterns that help, but not as much as you'd think, or they claim.
It's just part of the job. By far the largest and least interesting part of the job.
Ask 10 people & you'll get 10 different answers :D. Here's mine: I don't think software development jobs are going to disappear, even though the amount of hand-written code will in all likelihood decline. Those employing s/w devs are just going to expect more output. Until recently most smaller teams wouldn't even attempt more ambitious projects due to worry they'd blow it (yes, the uncomfortable reality is that most s/w projects fail). Now, they're getting braver since LLMs are essentially a RAD tool, and I'd argue that's a good thing.
I've been a professional dev for 20 years, and done plenty of solo projects, but also worked on teams at small & large firms. Even when we were able to build good products, the amount of man-hours sunk into those products often meant they weren't profitable. One of my former bosses made the whole s/w dev dept. gather int the cafeteria one day & ranted at us that he's spent 6 million Euros paying software developers but our products aren't selling, and he doesn't understand why we take so long to build basic products. That boss left shortly thereafter & the company was restructured, but in a way, he wasn't wrong. I can imagine that had we had LLMs things might've turned out differently, but who knows.
Beautifully written, a joy to read but, sadly, it feels like something from a bygone era. Nobody chants "Developers! Developers! Developers!" anymore now that everything is dominated by AI, and the joy of coding is gone too. People like Steve Yegge, who I used to aspire to be like back in 2006, when I started my career as a developer, now writes about how he uses 10+ concurrent LLM agents to code, review, and ship & doesn't even bother to even look at the code being produced anymore. Just today, I implemented 2 features using Cursor & GPT-5.1 Codex-Max & I didn't have to write a single line of code myself. But it felt wrong. It makes me think, "What am I even doing here - Why not just let the product manager prompt the LLM?".
Same, I got so much fomo from reading the gas town post I think you’re alluding too. Someone else can link it but it’s not “worth the read” in the way this was communicates so many ideas and captures/distills the zeitgeist of that time.
I guess the gas town one does capture our moment, but embracing YOLO spaghetti-o with reckless abandon, is a) depressing, even though I also feel like a middling programmer and b) actually seems to be dazzling these newer beleaguered bureaucrats precisely because they think they could just talk to the LLM instead of TMitTB.
Anyway, if that post and its ilk leave a bad taste, this was mouthwash for me. Lucky 10,000 I know, but I had never seen this (or felt so seen, as they say). I had to go check that he wasn’t wrong about PHP being Personal Home Page. I somehow never picked up that the recursive naming thing is a backcroynm.
> It makes me think, "What am I even doing here - Why not just let the product manager prompt the LLM?".
It feels different if you replace "LLM" with "outsourcing". Thing is, instructing a team of software engineers what you want is a lot more work (they need a lot more handholding), a lot more expensive, and a lot slower. But I'd argue that the work is the same - writing specifications, adjusting accordingly. Minus the human factor.
LLM coding agents won't kill software development as a job, but it will affect outsourcing and agencies as an industry. Of course, outsourcing companies will / are using it too.
>LLM coding agents won't kill software development as a job
They won't same as the industrial revolution didn't kill farming as a job but it sure did ate up most of the farming roles. Most of the people you have ever met are people who would have been farmers had they been born before the revolution. Developers without much leverage, underpaid, overworked and competing with hundreds of experienced devs for a single role is likely to be the eventual future of most software development thus gradually becoming similar to other stem roles in terms of pay, competition and negotiation power.
The difference is that before nobody forced you to be the manager of outsourced team, either you're fired or you're still working with code. Now you'll be expected to generate everything and oversee 10 agents.
I used to think this, until I tried it. Now I see that it effectively removes all the tedium while still letting you have whatever level of creative control you want over the output.
Just imagine that instead of having to work off of an amorphous draft in your head, it really creates the draft right in front of you in actual code. You can still shape and craft and refine it just the same, but now you have tons more working memory free to use for the actually meaningful parts of the problem.
And, you're way less burdened by analysis paralysis. Instead of running in circles thinking about how you want to implement something, you can just try it both ways. There's no sunk cost of picking the wrong approach because it's practically instantaneous.
Sure, and that goes even for myself. Like for example, on some projects maybe I'll be more interested in exploring a particular architectural choice than actually focusing on the details of the feature. It ultimately doesn't matter, the point is that you can choose where to spend your attention, instead of being forced to always go through all the motions even for things that are just irrelevant boilerplate
Fortunately, at least in Europe, there are definitely companies still around who either don't force the usage of slop machines or even have a culture of rejecting them completely (yes, that's a thing, and I'm glad to be working at such a company).
Why not just let the product manager use some no-code tool?
I think software engineers are having an identity disconnect from their roles as engineers vs coders. Engineering is about solving problems via tools and knowledge through constraints. An engineer is not diminished by having other engineers or better tooling as assistants. If you are having problems understanding your role in the problem, frankly you need to review your skillset and adjust.
You are correct in the abstract, but concretely I contest how useful LLMs are for producing software. I don't doubt their usefulness in prototyping or, say, writing web apps, but I truly do not think they are revolutionary for me, or for software development as a whole.
I was on a night train of ÖBB (Austrian rail) from Vienna to Berlin last summer, and unfortunately it was not very pleasant. When we got on the train, one of the staff told us to keep our belongings safely stowed within the interior of the compartment, far from the windows and door. Also, he advised us to keep the compartment door locked at all times. The train stopped in Prague for hours, during which time the station announcements kept me awake (they are really loud!). Then, when travelling through Poland, the train hooted every couple minutes when it approached a railway crossing. I ended up getting maybe 2 hours of sleep on the whole trip and my body was aching the next day. Never again!
"Then, when travelling through Poland, the train hooted every couple minutes, because apparently railway crossings in that country don't have automatic boom gates, so the trains just hoot to warn cars."
Some don't, some do, but law requires the passing train to hoot when it's coming near the railway crossing regardless. I'm polish, so that's that. Sorry you didn't get enough sleep, though.
I understand, no disrespect meant to Poland - I've edited my answer to not sound disrespectful. My grandfather on my mother's side was Polish. It was just an awful trip. I guess I had built up this romantic idea in my head about night trains, but the reality is that the they are extremely noisy, so you should at least pack some earplugs. Also, the security warnings by the train staff made me nervous.
