We suppose that will give the haters something else to shout about.

You hit that one right on the head.

"But the flipside is that it means systemd will gradually encroach on even more of your operating system."

BSD gets closer.

It's very close in my world. I've just started bringing my daily driver laptop more up to date from Ubuntu 16.04 to something still in support (mainly because software is now doing OS checks, and stopping working after the OS leaves mainstream support), and now when I use it (it's currently at 20.04) I'm noticing broken things left, right and centre. Almost everything I've tried to do ends up with having to fix something before I can finish the job.

The current annoyance is that when using X.org, I'm getting background corruption, and every now and then I get my terminal sessions just flashing junk on the screen, before reverting to readable text. This is liveable with, but is incredibly annoying (and it's not just on one terminal program, it seems to affect them all!). Oh, and the fact that Network Manager keeps dropping out, leaving me with no working network connections.

20.04 should already be quite mature, so I can't really understand why these problems still exist. I can't say that they are systemd related, but some of the problems I have had (like DNS name resolution failing after one upgrade) have been. But taken together with other Linux moves away from UNIX, it's making me want to to ditch Linux completely.

I'm just wondering whether to do it now before putting Ubuntu 22.04 on the system.

There's e.g. Devuan (which just... works out of the box on a reasonably current laptop), if you want to stay with a Debian derivative. There's other alternatives as well. Don't really like Ubuntu anyway...

Don't feel too bad I am current with Debian 'stable' and those issues are still present even with the new shiny in place. NetworkManager continues to drop out constantly garbage in the terminal fonts that appear garbled at boot.

BSD gets closer.

I've only got one systemd-infested VM - I wanted to spin up a Mastodon instance and couldn't find it in my usual OS builds (Devuan and FreeBSD).

So Ubuntu LTS was installed.

The proprietary UNIX systems I use every working day still have separate /, /usr, /var, /home and /opt filesystems.

In the case of AIX, this is largely because of the diskless boot operations that still want / and /usr to be completely read-only (although I've come across IBM supplied software that broke those rules - it cam as a great surprise to the people who wrote some AIX hardware maintenance task scripts that they could not write to /usr because it was read-only!)

Oh. and in case you wonder whether this is actually used any more, the IBM Power 775 Supercomputer systems running AIX ran their compute nodes as diskless systems, but I suppose that even this is more than 5 years ago.

I don't recall AIX installations ever giving you an option to not have those default filesystems, it just creates them regardless. I know we collapsed everything into /, /var and /home years ago on Solaris when I used to work with it. There didn't seem to be much need for the separation of usr & opt and it added overhead to systems management and meant we could run slices 5 & 6 for Live Upgrade targets. ZFS root then removed the option of a separate usr or opt filesystem and it was sometimes a pain to even get /var split off.

When I started working with Solaris in the late 90s, we were told / & /usr were separate to help system recovery as we should be able to recover a system from just the root filesystem. As /usr/bin & /usr/sbin migrated into symlinks from their equivalents in /, that became less of a fact of life, but "we've always done it that way" creates a whole legacy of its own. This was also back in the day I suspect some larger systems had to split them into different disks because of size limitations.

One minor thing: I like having /opt - for the stuff I build myself that is not related to the OS as per the "vendor".

I feel its going the wrong way, we want *more* separate hierarchies.

The BSD /usr/local approach is very nice to separate ports/packages from the base install. Linux distros often lack a coherent concept of a base and now with this merge, it will get even harder.

Weirdly I really like the Solaris (i. 10) approach of /opt/csw, /usr/sfw, /usr/ucb, etc. And the OpenBSD Xenocara in /usr/X11R6 is just much neater.

One of my projects is designed to take this even further, and create small self-contained / encapsulated hierarchies out of any package and dependencies: https://github.com/osen/pkg_bundle

TL;DR; I basically don't like packages and dependencies and all their cruft sprawled all over my systems. It makes it difficult to audit for one.

"The Reg FOSS desk is very happy that he hasn't had to edit an init script in many years, and does not miss such things even one tiny bit, but all the same it's going to irk some people."

It's a long time since I had to edit an init script. It's like restoring from backup. You don't miss doing it if you haven't had to but when you need it you really need it. With init scripts if there's a problem you can either put tracing statements into the script or run it from the command line, stepping through it. Good luck doing that with a black box. Systemd hasn't put me to that trouble, partly because it hasn't had the chance. Years back I had a shedload of trouble sorting out a problem with upstart which is similarly opaque.

I rarely edit init scripts, but the ability to run then line at a time by hand can sometimes be a lifesaver. Some of this really feels like development for the sake of justifying P's employment.

"Some of this really feels like development for the sake of justifying P's employment."

Well, yes. That's systemd in toto.

I'm happily using Gentoo and living without systemd or his god-awful sound system.

While I agree that /usr is somewhat 'overgrown' I do very much like the separation between /usr/{stuff} and /usr/local/{stuff}

That is staying, because it is useful. It's just the /bin Vs /usr/bin part that is being merged.

And for no reason at all.

Who is this change helping? Why do the systemd devs get to decide these things? I'm not paying them or asking them to. I'd pay them to *stop* coding if I could afford to.

This feature should deliver much faster system reboots so long as you don't need to restart your kernel.

OK, I'll bite. When might I want to reboot but not restart the kernel? I have two desktop machines running Linux and I only ever reboot them when I do a kernel upgrade.

"This feature should deliver much faster system reboots so long as you don't need to restart your kernel."

Not sure why I would need that. Windows did need to be rebooted for almost everything (the running gag was "mouse movement"), but Linux? Only if you do stuff for the kernel, and even then there was some way to switch that over (it was a loooong time ago that I tried that out, so memory might not be as fresh as it never was). And the article mentions as much in the second to last paragraph. So I am confused.

I also don't really get the argument " The /usr merge also allows making the entire vendor-supplied OS resources read-only for increased security and robustness." why was this impossible before? Why do we get better "separation between vendor-supplied OS resources and machine-specific"? Surely merging directories makes it more difficult (and I totally get it, stuff ended up apparently randomly in /usr/bin and /bin and likewise sbin because some people could not be arsed to think about that issue...). To be honest I don't care either way...

(and I have not had to edit an init file in a looong while either, but I had some run ins with the oh-so-clever systemd and its kraken of tools that made it pretty difficult to fix network and sound problems I had, so there's that). I use my computers for work and recreation and expect them to "just work" and no longer like to fiddle with stuff (which is why I now prefer Linux), rather than a few decades age, when I wnated to fiddle with stuff (which is why I preferred Linux back then).

I'm not saying systemd is bad. But then I'm not saying it is actually good. (but I have been burned by pulseaudio... but if you look at my older code I freely admit it was shite, so no hard feelings there?)

Ah yes, once again systemd is "solving" another problem that didn't exist. I can honestly say that I have had far more problems with systemd than any other init system I've used on any OS over the past three decades; frankly it's garbage.

Who on earth edits init files anyway? I just don't get it. I mean, distribution package maintainers presumably do, but ordinary users or even sysadmins? In my experience no other init system is so convoluted, nor so fragile and above all, so infuriatingly pointlessly dog slow; it just seems to hang up fatally at every possible opportunity for the most trivial of things. Just the other week I had a new systemd botchup to add to my lengthy list of reasons to hate it; suddenly a server which has been in production for several years came crawling to a halt; the / partition was apparently suddenly full when it had 70% free for years. To cut a very long story short, clearing around 3 gigs of logs (systemd as logger) suddenly freed up ten times that amount of space. Never had that issue with any other logger, nor seen any particular reason why my init system should also be the system logger.

I don't merely hate systemd because of its primary author, I hate it because it's demonstrably far worse than what we had before (and what I still use on my own most important systems) and most of all because it constantly and inexorably grows like a particularly aggressive cancer whilst becoming harder and harder to avoid.

In this case, it's solving a problem that it has largely created. The requirement to reboot after most updates is due in no small part to the way that systemd has taken over so much of the OS. It used to be that you could just restart services and carry on, but now even relatively minor updates require a reboot. This is a problem that would only get worse under poettering's plan to cram update management into systemd, using read-only system images.