Lennart Talks Up The Power Of systemd-sysext For Testing /usr Changes

[Old Grouch]

Linux is not a UNIX, and UNIX isn't a single, coherent standard anymore either. Linux is UNIX-like, meaning that deviating from that if it promises additional features or comfort is fine.

Systemd being a standard or not is debatable, but I think it is, since you encounter it in nearly all of the most commonly used private and enterprise distros and to the most part it behaves the same across said distributions.

With the whole containerization boom and distros using immutable system images becoming more and more common, a plugin-/extension philosophy for the filesystem does make sense IMO.

Er - no you don't. The Linux kernel is used in a lot of small/embedded systems - for example SOHO routers where the resource usage of systemd might not be appropriate. In pure numbers, I suspect non-systemd use is still substantially greater. The world is not made up solely of desktops and servers. I don't think Android uses systemd either, which is a substantial user base of the Linux kernel.

I don't want to make this into a fruitless systemd good/bad argument. I just wanted to point out that currently there are significant use-cases for the Linux kernel that don't also use systemd. Some people find systemd works for them. Others don't. The diversity of approaches is, at present, useful.

[Old Grouch]

"The dogs bark, but the caravan goes on"

...into the danger the dogs were trying to warn about.

[jacob]

Systemd being a standard or not is debatable, but I think it is, since you encounter it in nearly all of the most commonly used private and enterprise distros and to the most part it behaves the same across said distributions.

PS: There are official standards (documents that specify how something is supposed to work) and there are de-facto standards (tech that everyone uses). Official standards are not always relevant or useful (X.25, X.400 etc, anyone?) and de-facto standards are not always open and interoperable (MS Teams is an obvious example).

Systemd is a de-facto standard but fortunately it is open and free.

[jacob]

Linux is not a UNIX, and UNIX isn't a single, coherent standard anymore either. Linux is UNIX-like, meaning that deviating from that if it promises additional features or comfort is fine.

Systemd being a standard or not is debatable, but I think it is, since you encounter it in nearly all of the most commonly used private and enterprise distros and to the most part it behaves the same across said distributions.

With the whole containerization boom and distros using immutable system images becoming more and more common, a plugin-/extension philosophy for the filesystem does make sense IMO.

I would go even further: Linux was UNIX-like initially. The 1.x kernel series' APIs were modeled after POSIX and UNIX, and the use cases for the OS were those for an UNIX system. But that was a quarter of a century ago. Virtually every new kernel feature and API that has been implemented in Linux 2.0 and onwards (clone, eventfd, signalfd, CFS, namespaces, all the way to the big ones like cgroups/cgroups2, DRM and io_uring) have nothing to do with UNIX and are Linux-specific. Today, Linux is first and foremost the premier mobile and embedded OS, then a cloud OS and virtualisation platform, then a workstation OS (but a very different one from the UNIX workstations of the 90s) and then there also some *nix style servers that run Linux, but it hasn't been the primary focus of development for a long time. Linux has also a very different view of interoperability and multiplatform-ness than UNIX: While for UNIX, "portable software" means software that runs on SunOS, AIX, HP/UX etc. (and today the BSDs), Linux interpretation of portability usually means running on Linux and Windows, simply because those are the two platforms that together account for almost all of the world's computing.

[kiffmet]

I've created a few systemd unit files and yes I like it, but no systemd is not THE standard, and also goes contrary to the UNIX philosophy at times.

Linux is not a UNIX, and UNIX isn't a single, coherent standard anymore either. Linux is UNIX-like, meaning that deviating from that if it promises additional features or comfort is fine.

Systemd being a standard or not is debatable, but I think it is, since you encounter it in nearly all of the most commonly used private and enterprise distros and to the most part it behaves the same across said distributions.

With the whole containerization boom and distros using immutable system images becoming more and more common, a plugin-/extension philosophy for the filesystem does make sense IMO.

[jacob]

The UNIX philosophy is not about RAM and CPU, not at all. It is about engineering, design, clean interfaces, avoiding complexity, not running into a dependency hell. Lots of it still applies in modern software engineering.

https://homepage.cs.uri.edu/~thenry/...t/ch01s06.html

The complexity argument has always been a strawman. Complexity is an inherent characteristic of a given problem, it can't be wished away. You can either tackle it head-on, which means absorbing it in the software, or you can deny it to keep the software falsely "simple", which means pushing it elsewhere (usually on the final user).

Engineering has never been been addressed by the UNIX philosophy. In fact that philosophy has been almost entirely about ad-hoc hacks, afterthoughts, workarounds, ductape and 90% solutions to problems that shouldn't have existed in the first place (I'm looking at you, pid files). It's the same about what you call "clean" interfaces: what part of the UNIX interfaces can actually be described as clean? There is almost no formal specification of anything, there is no way to pass structured data anywhere (i'm not talking about streams of bytes that may or may not deserialise to something meaningful), there is no error management of any kind (errno doesn't count), there is no asynchronous notification, synchronisation is an unholy mess, etc. As for dependency hell, well here you have a project that has implemented a feature once and for all, so that it will always be there, ready to be used, and users and developers alike won't have to worry about dependencies. With the UNIX approach that doesn't provide any self-content integrated solution to any problem and everything requires a Rube-Goldberg assembly of bits and pieces held together by OS, distro and host-speciffic scripts, every day is a new excursion into dependency hell.

So sorry but not sorry, it certainly doesn't apply to modern software engineering. In fact I can't think of a single modern piece of software developed according to the UNIX philosophy. There is probably a reason to that, wouldn't you agree?

[jacob]

Standardization.

That's exactly what this project provides. A push-button way to do it that works once and for all, everywhere and predictably. Not sure what you mean by the way, that a better way to standardise something is through another mess of ductape scripts?

[Nuc!eoN]

"The dogs bark, but the caravan goes on"

You may bark as loud as you wish

[Weasel]

I usually hate systemd but I have to admit this feature is cool.

[sinepgib]

I'd argue that a philosophy born from a time in which 64k of RAM was worth a year's salary and CPUs couldn't multitask needs to be buried. Computers have moved on, but some of the antiquated philosophies from the Early Days haven't. There's very little software these days that adhere to "the Unix philosophy" and that's only natural. Software philosophy has moved on as new hardware capabilities and orders of magnitudes of available resources have allowed new concepts that places a lot of single tasking software in the obsolescence bucket.

I don't really like systemd 100%, but I get tired of religious adherences to "The Way" as if it's the only True Way of doing things.

I agree that people made a religion of the Unix way as if it were the beginning and end of good engineering, but it's worth noting that philosophy isn't only about resource efficiency (I'd argue in most cases composition of many commands is the opposite, and it's central to that philosophy, that's why modularity in software increases as hardware gets cheaper, instead of the other way around) but rather about maintainability.
As with anything, in reality it has its own pros and cons and you have to deal with trade offs and different priorities that are context dependent, etc.