Portable systemd services
lwn.net
lwn.net
It's not a technical thing, it's cultural. The two sides are playing tug-of-war with the same OS, and systemd's winning, but maybe it would be better to have a positive culture around the changes they're making instead of always having people dragging on the rope. Some forks have been good in the past - EGCS/GCC for example.
Every major Linux distro has chosen systemd as their future. I think that means whoever wants something different needs to change their name, rather than every major Linux distro changing theirs. Just as the Gnome 2 fans chose a new name for their future based on that lineage.
..and here I was thinking they chose it as an init system.
Gentoo is a major Linux distro too.
Gentoo officially uses OpenRC (and eudev), which is what you get if you follow the installation handbook. However, Gentoo also encourages choice and allows many options for init, daemon management, etc, which includes systemd. Other options ( are also available, too, at least unofficially.
> if the user makes no decision
While OpenRC is the official default, the "compile and setup everything yourself" nature of Gentoo makes this kind of statement somewhat irrelevant. One of the major reasons to use Gentoo is the ability to pick the components you want in your OS so it meets your specific needs. So yes, while there is a default, the concept of having a "default" is less important when you are installing everything manually.
I guess one can argue about what level of popularity makes something a "major Linux distro". I, personally, wouldn't put Gentoo into that category, unless I saw some evidence of dramatic increase in its usage.
Do you have an example of a distro that feels that way?
I only follow Fedora and RHEL/CentOS close enough to know, and they're still quite pro-systemd on all fronts, though there's still some hybrid stuff sticking around for backward compatibility and user comfort (so, a lot of stuff people were used to doing in the past still works the same on systemd-based systems).
Void Linux switched from systemd to runit.
Systemd is just fixing things that have been broken for a very long time.
This. I for one don't miss the mess of shell scripts for network management, init, bootloader, cron, etc. I personally think systemd already does 10x better at each of these tasks then the broken scripts have ever done.
That's not what has been done.
systemd unit files are not "scripts". They are declarative configuration files, usually orders of magnitude smaller than the initscripts, network scripts, etc. that they replace. The Apache unit file on RHEL7 is ~17 lines long, and it replaced an initscript that was a couple hundred lines long.
It is a difference of both degree and kind.
Just saying, the de facto ways of using systemd are starting to diverge a lot from the intended behaviour. And of course, the de facto usage is what we'll judge each piece of software's merits on...eventually.
On the other hand, Linux has a history of _forcing_ desktop users to mess with device management for the simplest of tasks, e.g. making their audio devices work.
So you've never restarted a service on your desktop system?
I don't use a Linux desktop (I often retry) because that is unattainable.
I think of systemd as one component in an attempt to create a good desktop environment based on the Linux kernel. Sort of like how Android is an attempt to create a good phone environment based on the Linux kernel.
Based on that, I think it makes more sense to come up with a separate name for something like a Gnome/Wayland/Weston/systemd/Linux combination. While we are at it we could come up with a separate name for a Linux based system configured primarily by writing scripts. We should stop pretending that there is some sort of generic combination of things called "Linux".
systemd works on systems as small as embedded systems up to huge hpc systems. It's not just a desktop thing.
This is fundamentally an implementation of Lennart's blog post - http://0pointer.net/blog/revisiting-how-we-put-together-linu.... That article used the words "We want an efficient way that allows vendors to package their software " ... which was followed by a storm of angry systemd-is-the-borg-it-needs-to-die tweets and articles.
Even on HN - the response to this article seems fairly muted... although it is a bigger political issue than even init systems. I wonder what the response would have been to "systemd introduces new portable packaging format"
There's no fundamental technical reason Linux couldn't have just 1 extensible package format and 1 extensible package manager. All the reasons for the split are social ("I like A"), political ("we want to be able to control A") or historical ("A came first, we built our house on A, we can't abandon A").
Likewise, different packaging formats exist for different needs. Docker and Ubuntu Snap are for different needs, yet they overlap. Systemd did initially not care about packaging and containers. Yet, there is an overlap, like "How to do logging?". Docker and Systemd both grow and overlap more and more.
We have gratuitous differences which could have been prevented with a better design. See for example even the mess in the rpm world where a SUSE rpm may or may not work on Red Hat.
Converting between the differing package formats is actually relatively easy and tools like `alien` exist, that do that.
As I said: social/political/historical reasons bringing us down.
[1] I know about lsb_release, but that's an example of an afterthought, not a part of the initial design.
My point still stands, something like this should have been included from the first releases of Linux distros, 20 years ago. And that was just a random example I came up with after 2 minutes of trying to prove a point. There's many, many more like it.
Also, just for kicks I took at look at the spec and...
1. ANSI_COLOR is funny:
> A suggested presentation color when showing the OS name on the console. This should be specified as string suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code for setting graphical rendition. This field is optional. Example: "ANSI_COLOR="0;31"" for red, or "ANSI_COLOR="1;34"" for light blue.
2. And some parts are scary:
> parameters may be set using os-release
Oh-oh! Everything is optional! That's really bad for a RFC.
My hope for systemd is that it unifies the Linux Desktop universe. The Free Desktop movement has stopped doing that.
There is a time for exploding into lots of variants and a time for unifying. Remember the time, when git came up? There was an explosion of DVCSs (Monotone, Darcs, Bazaar, and more). For now, the world has mostly settled on git with Mercurial as a secondary.
The blog post is dated September 2014. Nix had been around for at least a decade by then (e.g. see https://nixos.org/docs/papers.html ).
Wikipedia says Gobolinux is about the same age as Nix.
I wonder if this proposed system would be as amenable to handling such a wide variety of software (e.g. https://nixos.org/nixpkgs/manual/#chap-language-support ) on such a wide variety of platforms (e.g. https://github.com/NixOS/nixpkgs/tree/master/pkgs/os-specifi... ).
Why is it so hard to settle on a standard when it comes to this stuff? The same confusion exists when it comes to rpm and deb packaging formats. At the end of the day both do the same thing and yet to deliver software to redhat and debian systems you have to double your packaging effort.
There will never be agreement on standards that are used as strategic weapons in developer mindshare turf wars between companies using monopoly-or-die-trying business models.
Let it come.. we'll be watching and picking up the good ideas too. And working hard to make sure snaps continue to win on merit, rather than lack of competition.
I don't care what init system you run, but if you're writing userland software (GNOME, for one), than what init system I run is none of your damn business. For that matter, ideally you'd at least try to support the *BSDs.
As much as Systemd is the borg, I could at least live with that. I cannot live with the fact that systemd maintainers continue to say that having high-level userland software link to libsystemd is viable and acceptable. I cannot live with the fact that systemd continues to violate widely-accepted defaults for no reason (kill all processes on logout? really?). I cannot live with the fact that Lennart has widely stated that you should ignore POSIX and that all systems other than Linux don't matter.
This is a direct violation of the KISS principle which made Unix and Linux so great. Not only do they want to intertwine user software with system software, now they even want an additional layer of abstraction on the _system_ level!
I think we need a counter strategy against the aggressive takeover of the Linux land before it is too late. I have nothing against people who love systemd. If they want it they should use it. But any Linux user should also have the option to get rid of systemd _completely_ if it turns out to be a failure.
Init systems and system services should be as replacable as desktop environments! Only if systemd is aiming to be "portable" like that than I can live in peace with it.
The Gentoo folks, as well as many of us Arch users, are with you. Gentoo in particular has been aggressively forking and maintaining patch sets for any of the software that has succumbed to the cancer (the *kits, various desktop software, DBUS, GNOME, and most notably udev. Although if they weren't needed for some pieces of software I use, I'd gladly chuck 90% of that stuff). So yeah, if you want to help, that's where to contribute your effort.
Gentoo and Arch are good options. However, in the long term classical Linux will likely only be able to run on retro systems and FREE HARDWARE! If Gentoo and Arch want to survive they should focus on free hardware pretty soon.
I think so because upcoming mainstream hardware will likely all be based on UEFI/SB. SB is yet optional but I expect it to be mandatory soon. Only Linux with certified kernels -- likely systemd Linux -- will be supported on those systems. I don't like that because I want to be able to install up-to-date kernels and software at any time without messing around with proprietary certificates.
The Monster 6502 [1] was an excellent starting point into a world of discrete SMD cpus. I hope there will also be a 16/32-bit cpu capable to run Linux (or its successor). At least 68katy [2] is capable.
The most promising project however is RISC-V which will hopefully be available with non SB-mainboards.
Honestly, the only thing that keeps me from migrating to the BSDs at this point is Steam.
As long as the vendors cooperate you will be fine. We will see how it works at Win 11+.
> and if we don't, then someone will crack it sooner or later.
Other people may be able to live with it but for me this is an unacceptable option. Either a system fully supports Linux or BSD, or I take another one.
(see discussion 3 months ago: https://news.ycombinator.com/item?id=12224408)
If my understanding is right, the industry went:
CGI -> processes -> VMs -> containers
I'm thinking of going back to step 2.
No, but seriously I understand the reason why you'd want this, but what stops systemd from being divided into smaller modules? Like the Linux I'm used to.
One of the features I would like to see for example is less binary logging and this journalctl madness. Binary logging makes it harder for me to plug in other programs to parse the logs or whatever I want to do.
So what I would like to see is modularity in the sense where I can choose to run systemd as an init system, and something not-systemd for logging, or for scheduling or whatever.
Most components can be replaced (the journal isn't one of them, AFAIK, but most others can, and the journal can be configured to send things to a plain text log). Personally, I don't find the binary log to be that problematic. It is taking some getting used to, of course. 20+ years of muscle memory for grepping and awking and cutting text log files is hard to overcome, but the amount of help the system provides is nicer. It's better documented and better at guiding the user than the old way, IMHO.
Which brings to mind something I like about systemd becoming standard that rarely gets discussed, I think: It brings a level of consistency that some other UNIX systems have had for a long time; the BSDs, for instance, have the feeling of all of the pieces having been designed to work together. Linux has never had that feeling; but with systemd, a large amount of Linux real estate now feels that way. The documentation correctly references other components docs. The way various components work together is reasonably documented because they were built at roughly the same time by roughly the same people (or at least people who interacted during the design), so the interfaces are clearly delineated. That's cool, I think.
So, sure, I'm having to learn new stuff every time I interact with systemd, and that's frustrating. I know Linux like the back of my hand, so when I find myself having to read the docs for even simple stuff, I get grumpy. But, I get over it. It's gonna be fine, and we'll all get through this learning curve.
Of course not. Now you have two logging services. Hardly a replacement.
The idea is that systemd wanted to not implement a bunch of different logging APIs within systemd itself. They wanted one logging API across all of the systemd components; and, then, if the end user needs logs to some other target, they use one utility (journald) to spit it out to that other target.
I believe the thinking that went into this decision was sound. The alternative would be for every component in systemd to know about multiple logging targets, which would be exactly what people are accusing systemd of being (but isn't, in this case): bloated. systemd and all of its components log one way, allowing for a very simple logging code path. journald allows you to use those logs in many ways.
So, either, systemd would need to expand to include support for a bunch of different logging mechanisms, or it would support one simple logging API and provide a way to export those logs to other targets.
Are you here arguing that systemd should be made larger and more complicated, in order to support other kinds of logging (like syslog and plain text files) without the help of journald?
To me, this looks like modularization and componentization at a reasonable level of abstraction. It simplifies the logging code for every component, while also providing a means for end users to consume the logs in the ways they prefer, including plain text.
It's not modularization. It's scope creep in pure form.
Lennart wrote a pretty good summary of why journald exists, and I think it holds up to scrutiny pretty well:
https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBA...
One could argue about what the right "one log" target is, but I doubt one would come up with syslog. syslog-ng and rsyslog were incremental improvements, and solve some of the issues, but they're 18 and 12 years old, respectively, and both pre-date containers, widespread cloud computing (AWS came in 2006), service-based architectures, etc. When they were new, we still had servers that did one thing.
One can also argue about whether journald is the right implementation, even if we acknowledge that a new standard is needed, we don't have to agree that journald is the right one. But, I wasn't writing the code, and what they came up with is pretty good. I don't have any major complaints about it, except that I have to learn some new stuff.
So, I respect the argument that they should have chosen an existing standard for logging, but I also see the reasons why they chose to build something new. I think if I'd been involved in the decision, I probably would have come down on the side of journald, in the end (but would have needed some convincing).
Of the reasons he wrote it, half of them is not met by journald, and the other half could be implemented without much trouble on top of syslog. Hard to call it "holding up to scrutiny pretty well".
And I fail to see how journald is better than syslog in the age of containers.
Hopefully, you'll be able to direct your energies into maintaining one of the distros that has chosen to stick with the old way of doing things (Devuan seems to be the most promising one coming up, but I guess there are several others). I'm not opposed to folks having choices, as long as I don't have to maintain them.
[#] LXC/libvirt type containers I see as merely cheap VMs, though I like them very much.
As for Docker, you can continue to use the logging tools you're used to, or you can have it output to the journal. Docker supports many logging drivers: https://docs.docker.com/engine/admin/logging/overview/
That's not what modular means. Can you use only parts of systemd if you wanted to? Can I e.g. use the very useful dependency-based service initialisation but keeping my log facilities and networking management intact?
Yes, though most distributions have chosen to use more than just the init functionality.
"Can I e.g. use the very useful dependency-based service initialisation but keeping my log facilities and networking management intact?"
No (logs) and yes (networking). Logging from systemd components, as far as I know, have to go through journald, but journald can send it as plain text to syslog, if you want it to. So, kinda yes on that one, too.
networkd didn't even exist yet when many people began using systemd for their init, and it is entirely possible to use other methods of managing your network services. RHEL still, AFAIK, has a hybrid model that keeps a lot of the old configuration files even though they have switched to systemd for a lot of stuff. Maybe it uses networkd on the backend; I haven't needed to find out, as the config files work the same way they always have.
I think the confusion comes from the fact that very few people want to only use one component of systemd. Even though you can, there is value in all of the pieces working well together and providing a consistent interface and API. Most distros that switch, choose to switch a lot of things over at the same time, because it's just nicer to do so, not because they had to. And, the people who hate systemd don't want any of it, so they never learn enough to know that they probably could get the bits from it they want without being tied to all of it.