rleigh

Not any longer. Back in the mid-2000s the company I worked for sold point-of-sale systems based upon a multi-user 4GL application (TAS Pro). Similar to dBase/Clipper etc., using the Novell Btrieve ISAM database engine.

With the advent of USB and SATA we ceased to be able to source industrial embedded x86 boards which could run the application. At the time this was with Novell DR-DOS, which was relatively modern in terms of hardware support but still behind the times and we were struggling to manufacture new systems. The company was very small, so a full rewrite was investigated--I did a prototype using PostgreSQL and Gtkmm--but it wasn't realistic. Today, an AI could probably do a full rewrite in a day or two, including migration tooling. Back then, it would have been a multi-year effort for one person given the application's size and complexity.

My solution was to run Linux since it had full support for the hardware. Debian Sarge at the time. This used a Perl frontend and dialog(1) to present a simple menu system at startup. This did backups, software updates (over dialup!), remote access for support (again over dialup), ran backups and ran the main application. It would start DOSEMU which provided the application with VGA display, COM ports and parallel ports for the application to drive "directly" (from its perspective). It also used Samba and CUPS to provide the DOS environment with shared network drives with exclusive byte-range file locking needed for the multi-user network database to work with concurrent users without data corruption, and also multi-user report printing and receipt printing.

I left the company a year after this was put into full production, but the last I heard it kept the company viable with a supportable product for many years after until its owners retired. This kept software from the early 1990s running well into the 2010s, and there are likely still sites running it to this day.

> most users don't want to have their favourite FS randomly removed from the kernel

True. But when you look at this, isn't the deeper problem that Linux remains such a monolith, and there's a stark difference between "included" and "not included" in the kernel. It's now over 35 years old. The fact that we can't have stable APIs and develop more out-of-tree drivers is not a strength, it's a weakness.

Even old Unix systems like SVR4 managed to have stable, public driver interfaces, despite being rather proprietary. FreeBSD manages to have drivers in its ports tree, with a stable API for a given major version. What makes Linux so special that it can't manage this?

I understand all of the arguments about why this has to be so. But... they might have made sense in the early days, but after 35 years it screams of immaturity. Plenty of other systems, including other open source systems, manage to do this, including having versioned interfaces so things aren't set in stone. Linux remains right at the extreme end of guaranteeing nothing. I've long thought this was unnecessary and counterproductive.

As I said, no individual has the capacity to fix this.

When it comes to compatibility, different companies and groups make different tradeoffs. Last week, I had to use a (brand new) datalogger. It came with a CD, and instructions for installing on Windows 98! And yet, it worked flawlessly on Windows 11. Looked dated, but perfectly functional. Can you imagine a third-party application from 1998 working on a contemporary Linux installation, or a Mac? Of course not, it's almost impossible to do this. Like it or loath it, Windows will run software from 35 years ago without trouble. It's not just about big office suites, it's about the thousands and thousands of useful tools that it will run without complaint, and that's what has made it so indispensable even while they continue to make it increasingly awful.

Apple made a different tradeoff, where compatibility is not guaranteed. It might be fine for a few years, but no one is using software from a 1998 Mac on a modern Mac, it just won't run. It's one of the reasons the Mac ecosystem is so limited, since there just isn't that huge backlog of material.

And Linux is that on steroids. The incompatible churn in libraries, tools, system services, windowing systems, it's both relentless and counterproductive. How many years will your software work until it breaks. Is it even possible to run on more than one blessed distribution in the present day. Linux is great, and it's a great platform to develop on. But it's an absolutely cursed platform to distribute software for.

Developers run software in VMs. Most people do not.

I've been developing open source software since the late '90s. I was a Debian developer for nearly 15 years. I stopped actively participating in this stuff about 10 years ago. I'm involved in a few libraries and that's it.

The "Linux" ecosystem is utter chaos, and there are too many developers who are their own worst enemies. There's too much churn, and too little strategic thought. Compatibility is king. Microsoft know this, or used to. But too many developers on the Linux/open source side of things don't care. They have repeatedly self-sabotaged the development of a coherent ecosystem throughout the last three decades by repeatedly breaking backward compatibility and replacing well-established software with incompatible replacements. Even RedHat. The pursuit of new and shiny trumps compatibility every time, and half-baked new technologies replace stable and established technologies long before they are ready, leading to developers and end users being eternal beta testers of rubbish. It is not possible to develop software for a platform which does frequent rug-pulls leaving your software unusable.

This isn't solvable by any individual, no matter how hard or how long they work for.

That's part of the reason why I switched to FreeBSD as a replacement for a good bit of stuff I previously did on Linux. It might be lacking in some aspects, but there's not quite the same level of insane and pointless churn without purpose.

And I say this as someone who used to hand-build kernels from applied patch files, back when it was fun and the improvements were consequential.

I got downgraded for the first time today. Because I was using a library with the characters "bio" in it. The classifier is strict beyond reason. It got the name from a commit message in the git history (wasn't even in my prompt) and it immediately freaked out. I eventually got it to work by getting opus to write a plan, then editing the plan to strip out all references including commit hashes, then getting Fable to review and refine that edited plan. Eventually got it done. But what a pain.

That said, I've got it easy. My colleagues who are chemists and biologists can't even ask one question. There are so many triggers in their memories and workspaces they can't even ask a non-triggering question. And we all work in medical diagnostics, it's not like we're doing anything remotely nefarious. Fable could be such a benefit, but the limitations make it worthless.

The enclosure is the real added value, hardware-wise; and the H2D has even better environmental control (active heating and cooling of chamber).

While the open-source part of me loves the more open nature of Prusa, the commercial-minded part loves the immediate convenience of the Bambu. But the environmental control is something which Prusa doesn't really do well yet. Heated chamber, as well as filament humidity control is something Bambu has done which Prusa has not, and when it comes to printing with "engineering" filaments like PA6CF, PA6GF and other higher-end lubricating plastics for bearings etc, along with support filaments like PVA which are incredibly hygroscopic, the Bambu is the only contender if you want high-quality prints that don't warp.

IMO this is where Prusa gave up the race and need to catch up. Give me equivalent or better environmental control, and I'll be happy to consider it.

The accessibility to non-experts, and the fact that it just works out of the box without fiddling around optimising settings, is why I have a Bambu family at work and zero Prusas.

There are plenty of embedded chips which only provide RMII. No RGMII or alternatives.

To truly fix this would require revisiting of some very old fundamentals.

The C0 control set (ASCII 0x00 to 0x1F) contains all sorts of esoteric functions, most of which are generally unused, and only a few of which are useful and could be implemented at a higher-level. ESC sequences are only part of the problem.

And this also applies not just to terminals, but to systems programming as well. None of these have any business in e.g. filenames, but it's all commonly permitted. Some systems do forbid them, and it should IMO be universal.

If we really want to fix this, then we would develop a character encoding that strips out all control characters entirely, including LF and CR, and have text be nothing but graphic text characters. It's so entrenched and convenient that it's difficult to see that happening. But I do think routine stripping of all control characters in situations that don't require them would be good for security.

This is broadly correct, but not entirely. Terminals have historically had additional capabilities, be that ringing a bell (BEL) or outputting to a line printer. There are escape codes dedicated to doing file/tape access and running system commands. Not in wide use, but they do exist. See ECMA-48 for some examples from the '80s.

True, I missed that. I suppose with symlinks you have the reverse problem: you can point to deleted filenames and then have broken links. The cycle detection is still an issue though--it has indeterminate complexity and the graph can be modified as you are traversing it!

Historically, it made deletion rather difficult with some problematic edge-cases. You could unlink a directory and create an orphan cycle that would never be deleted. Combine that with race conditions on a multi-user systems, plus the indeterminate cost of cycle-detection, and it turns out to be a rather complex problem to solve properly, and banning hard-links is a very simple way to keep the problem tractable, and result in fast, robust and reliable filesystem operations.

When they used to have to fit the whole thing onto six floppy discs, it had to be constrained in size and scope. Today there are no constraints and it really shows. I think having hard constraints, be it storage, memory, cpu, update distribution, product requirements, drives quality and forces hard engineering decisions to fit within them. I think a lot that is wrong with Microsoft of today is a complete loss of enginering discipline and focus; you only have to look at the incoherence of their GUI development strategy to see how badly they are doing there.

I think it would have been useful for them to have really made a proper effort at modularising Windows along the lines of how Linux distributions and the BSDs do things. I can't see any way of recovery from the bloated mess they have created; they can't keep cramming any more in, it's an unstable, unusable and untestable mess.

Likely. Whenever I see that it usually means it itself created the test failures but won't admit to it!

Just for a bit of balance, another book I bought was the ZYNQ book and companion materials. It's made by a university in collaboration with Xilinx. They don't hide that because it's niche and low volume, they used a print-on-demand service. I even went and looked them up, and it's a small UK printer with pretty reasonable pricing for self-publishing small runs of books. The quality was great, no problems with it at all. So it /can/ be done.