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.

Let me just throw in:

ETL State Chart and Hierarchial FSM https://www.etlcpp.com/state_chart.html and https://www.etlcpp.com/hfsm.html

Quantum Leaps https://www.state-machine.com

I've used them primarily in safety-critical systems where complexity, timing and the ability to effectively verify behaviour is obviously important. Being able to separate the decision-making from the actions is a great aid. Having to strip back the decision making to "what do I do next" when I'm in this state and this event occurs is a bit different to how most programs are structured, but really does aid separation and makes it easy to reason about behaviour under different conditions.

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.

It's not just Amazon. I bought a copy of an ARM assembly book from a proper bookseller (Blackwells) which was a proper hardback for a high price--something like £80, and I received a print-on-demand mess with a hardcover. The print was there but barely legible, a dotty mess which gave me a headache. I returned it.

I can see print-on-demand working very well, but not until the quality issues are sorted out. Being charged top dollar for something which is substantially inferior is unacceptable.

If it loads at all. The last two days, the start menu refuses to launch it when you click on it.

The lack of quality in Windows is simply astonishing. And the new start menu and taskbar are terrible. Quite how a company can transform a product into such a mess in just a few years is incredible.

I started on the cheapest £15/mo "Pro" plan and it was great for home use when I'd do a bit of coding in the evenings only, but it wasn't really that usable with Opus--you can burn through your session allowance in a few minutes, but was fine with Sonnet. I used the PAYG option to add more, but cost me £200 in December, so I opted for the £90/mo "Max" plan which is great. I've used Opus 4.5 continuously and it's done great work.

I think when you look at it from the perspective of how much you get out of it compared with paying a human to do the same (including yourself), it is still very good value for money whether you use it for work or for your own projects. I do both. But when I look what I can now do for my own projects including open-source stuff, I'm very time-limited, and some of the things I want to do would take multiple years. Some of these tools can take that down to weeks, do I can do more with less, and from that perspective the cost is worth it.

I've found it to be terrible when you allow it to be creative. Constrain it, and it does much better.

Have you tried the planning mode? Ask it to review the codebase and identify defects, but don't let it make any changes until you've discussed each one or each category and planned out what to do to correct them. I've had it refactor code perfectly, but only when given examples of exactly what you want it to do, or given clear direction on what to do (or not to do).

It's the other way around. It's the GPL which is incompatible with the CDDL (and many other licences).

The CDDL is actually very permissive. You can combine it with anything, including proprietary licences.

Yes, this is a prime example of completely gratuitous breakage.

The change adds zero value. It's a deliberate API break. And it could have been made a non-breaking change all for the sake of a single one-line macro or inline function.

This isn't unintentional. It's a deliberate choice they have made. And not just this one, it's happened repeatedly over the years.

The thing that really gets me, as an end-user/developer, is that it forces incompatible changes not only in my codebases, but in every other application developer's codebases worldwide. A small change in GTK+ imposes hundreds of thousands of man-hours of maintenance work upon every application developer. And this burdensome work not only takes time, effort and money, it doesn't improve our applications one iota, and on top of that, it breaks backward compatibility so our code will not longer build with older GTK+ versions. Most of us won't be chasing the latest development release, applications might need to target a wide range of distributions with a wide range of GTK+ versions. So it's a logistical nightmare as well.

The lack of concern for the needs of actual application developers is why I eventually had to give up on it entirely. At some point it doesn't make any sense either commercially or for free software development, it's just masochism.

Recently it's got really bad though. The taskbar is badly broken.

* If you use auto-hide, it won't show when some applications are open. Edge in particular is bad.

* Some applications simply don't show on the taskbar at all. Teams is one. It's in the alt-tab list.

* Sometimes it stops working entirely.

The testing and QA of this stuff appears to be largely absent.

And also in QtXmlPatterns (now also retired).

Just for the record, Xalan-C is even less maintained than libxslt. It had no releases for over a decade, and I made a final 1.12 release in 2020 adding CMake support, since the existing builds had bitrotted significantly, along with a number of outstanding bugfixes.

I initiated its removal to the Apache attic in 2022 in https://marc.info/?l=xalan-c-users&m=165593638018553&w=2 and the vote to do this was in https://marc.info/?t=166514497300001&r=1&w=2&n=20. It has now gone nearly four years without any commits being made.

It's a great shame we are now in a situation where there is only a single proprietary implementation of the very latest version of the standard, but even the open-source 1.x implementations are fading fast. These technologies have fallen out of favour, and the the size and complexity of the standards is such that it's a non-trivial undertaking to keep them maintained or create a modern reimplementation.

It's more than generous. You can run it with much less resource utilisation than this. It only needs a few tens of kilobytes of flash (and you can cut it right back if you drop bits you don't need in the library code). 32 KiB is in the ballpark of what you need. As for RAM, the amount you need depends upon what your application requires, but it can be as little as 4-8 KiB, with needs growing as you add more library code and application logic and data.

If you compare this with what MicroPython uses, its requirements are well over an order of magnitude larger.

The main source of complexity isn't the .deb format, but the tooling and infrastructure around the format. It's mired in overcomplexity, and it's very much still in a '90s mindset of building locally with multiple layers of Perl-based tools. If it was rethought to be git-native using docker images or equivalent then it could be of equivalent simplicity to other contemporary systems. When I look at what you can do with the FreeBSD ports and Poudriere or with Homebrew and other systems, I see how much of the complexity has been added incidentally and incrementally, with good intentions, but a radical rethink of the basic workflows are necessary to consolidate and simplify them.

[I used to maintain sbuild and was the author of schroot back in the day]

Honestly, I found that one of the most user-hostile workflows they implemented to date. It's really obnoxious.

The number of times I've wanted to save in their native XCF file format is... zero. But I always want to save in a standard image format, and I don't really consider that to be exporting, just saving.

I understand why they wanted this, but I don't think many of their actual users did.

It really depends upon the target market. That's fine for hobbyists. But I use the Bambu X1 for small-scale prototyping in a company, and it has to be usable out of the box. We can't justify an entire week of labour for each printer we buy.

The Bambu has been ideal for that reason. Every material pretty much just works, and the quality is excellent. The cloud integration and janky LAN mode is the downside, and this current topic even moreso.

sbuild is at least 25 years old, it might be nearer to 30 at this point. I did a lot of cleanup of it during the mid-2000s, including adding the schroot support to it which is being removed here, and that included abstracting virtualisation backends which allowed newer solutions to replace it. The original had to run as root to do a chroot(2) call, and it reused the same environment between builds. schroot removed the need to run as root, and it could provide a clean snapshot for each build. But it too is now rather dated--though the replacement tools often lack some of the features it has, like being able to build from ZFS cloned snapshots or Btrfs snapshots, or even LVM snapshots. We wanted it to be fast as well as safe, and the time-to-build and time-to-clean-up using these was and is excellent.

Replacing key infrastructure is hard, particularly when it's working well and the cost of replacement is high, especially so when it's volunteer effort. It was cutting edge back when Perl was all the rage, but while Perl might no longer be the fashionable choice, tools written in Perl continue to work just as they always have. I found it dense and impenetrable even 20 years back, and I used to have the whole thing printed out on fan-fold paper from a dot matrix; it was about 3/4" thick and covered in annotations! Understanding several thousand lines of obscure regexes is a cautionary tale in how to write unmaintainable Perl, and was one of the motivations to clean it up, refactor it into meaningful functions, and document what it was doing so that it could be maintained with a little less effort.

Good to see schroot is being replaced in sbuild, given that it's nearly 20 years old and no longer a cutting-edge solution to the problem of creating build environments. Can't believe time flies that fast since I wrote it in 2005!

Has an outright replacement for sbuild itself been considered? Given the ubiquity of modern CI systems, it seems quite possible to replace it entirely. I would have thought GitLab runners or Jenkins or any other standard CI system would work well. While I once enjoyed writing Perl, sbuild is not a great piece of code, and the problems it was trying to solve now have better and more widely-used solutions which don't require ongoing maintenance of an even older piece of Perl code.

And Siemens SolidEdge is totally free for hobbyist use.