This should be put to rest already. Too much time was wasted on bikeshedding this in the past, to the point that it became so complex that was even made into Ace Attorney cases for easier digestion:
Apparently these are made by Dainius Masiliūnas, to give credit where credit is due.
For those who might feel hesitant to watch some weird re-enactment of a technical discussion, in a game they might not have even played, I can say: I have not played Ace Attorney either, and these are great. In 2014, I wrote¹: “That thing is unbelievably more awesome than I would otherwise have assumed.”, and I still think so.
Wow, this is incredible. I can't believe that a dramatic retelling of a dry, technical mailing list discussion could be so damn entertaining. Or that a dramatic retelling is even possible in this format.
You're welcome! It's amazing indeed. Quite an ingenious way to make a lengthy and tedious topic easier to grasp, by adding the entertaining factor. Thanks to GreatEmerald for doing the work.
When I started using Linux, in college, the advantages were that Ubuntu, and others, were super light-weight and a great way to give life to old hardware. Also, if you were interested in programming, it was a pretty good way to discover how things work.
Benefit one was destroyed by Gnome3 (and, for a while, Unity) being the default in the beginner's distros. Benefit two was destroyed by SystemD wrapping its tentacles around more and more things, and making a modern distro an obtuse, ugly system to learn from, or to work with.
Is there any persuasive reason for a college student today to try desktop Linux? Is there a good pitch anymore?
This seems to imply that the only advantage of Linux was its low system requirements, and I don't think it was ever true that that was the only advantage.
I'm not talking the only advantage, I'm talking what's going to convince people to use Linux for desktop in the first place. What would be a good one-minute pitch in 2019? Because when I first started, nearly 15 years ago, Linux had a really good one-minute sales pitch that was extremely persuasive.
Gnome3 is great if you want to disable 4323 hotkey combinations to open their overlay (except the one that can't be disabled), and download an extension that makes it so moving the cursor over 15% of the upper left corner of the screen doesn't open the overlay.
But it is slow. The overlay barely works well on a new mid-range system. A cheap laptop that is as old as Gnome3 has no chance of running Gnome3 in a satisfying way. Even if you ignore the overlay and install dmenu (which a noob isn't going to know about) it is slower than not only other wm's for Linux, but Windows and OSX. It's not a good way to get new people interested in Linux.
I think it's fine. I'm not sure that new linux users would honestly prefer something extremely fast like i3, and unity is extremely clunky and unappealing.
I never got the "good for programmers to learn on" argument. If anything Windows has better IDE support and is easier to install things on for a beginner. Not so bad on Linux with VS Code these days at least.
Why would having better IDE support make for a better learning environment? It masks what is going on, and complicates it (for the benefit of people doing much more complicated things). But if you're bashing out helloworld.py you've just made it hard to disambiguate what the file is doing, what the runtime, and what the IDE.
Windows/VS: Type some stuff in the window and hit F5, get shown visually the line that went wrong. Install other things with easy setup utilities.
Linux/CLI: Learn an obtuse (beginners, remember) command line text editor, save the file, run another text command to run it, remember the error as you go back in. Fight with apt to get things to work, pray there are no dependency conflicts/errors, learn sudo, go find an IRC channel to help with a package not working with some obscure error about "but it depends on .. which is not installed, try (command that won't fix anything)"
First one sounds much easier for a beginner to me. Making programmers learn on linux is like making student drivers start on manual tractor trailers.
> First one sounds much easier for a beginner to me
They didn't say it wasn't easier, just that they'd learn less. A better platform to learn on doesn't result in you learning less.
This is even true among "professional" developers, they think somethings impossible just because it can't be done inside visual studio because they don't know how all the parts fit together, all they can do is hit F5.
> Linux/CLI: Learn an obtuse (beginners, remember) command line text editor, save the file, run another text command to run it, remember the error as you go back in. Fight with apt to get things to work, pray there are no dependency conflicts/errors, learn sudo, go find an IRC channel to help with a package not working with some obscure error about "but it depends on .. which is not installed, try (command that won't fix anything)"
Aside from the command line text editor you have deal with almost similar issues with VS, different but similar. You can end up in DLL hell from nuget, you can fight with click once deploys, you can find useless "answers" on MSDN, etc.
apt is prone to catastrophic failure that's very hard to diagnose but setting up an IDE is as simple as clicking OK on a few prompts in an installer. For some real data nobody in the high school class I took that used visual studio had any issue with the fact it was visual studio.
Really though, thinking on it the best environment for a total beginner is probably one of those web-based things like codeacademy.
I don't want to start a huge argument or anything but it's years since apt has failed for me, and I run a bunch of systems. IDEs have a learning curve over and above learning the language, and really, locating and installing an IDE is easier than typing apt-get install <language>?
- Find its website and download the installer and install it.
- Find an "IDE" like TeXniccenter.
- Find its website, download it and install it.
- Configure it.
- I have buttons to click, great. I click on them and pray that it works. What if it doesn't? Error messages are buried somewhere and problems are horribly difficult to fix (e.g. utf8 problems or missing perl).
- I need to convert some graphics from one type to the other. Can Windows do that? What do I need to install? Photoshop?
On linux:
- Open the software center/appstore/whatever.
- Search "latex".
- Click on all the stuff I like. Done.
- Everything works out of the box and does not need fiddling.
The second one is much, much easier for a beginner.
Installing and navigating through enough of the VS interface (what is a "Project"? Why are there so many different types? Doesn't the book say I just need a text file???) to even get started in Windows is a huge challenge. The original reason I wanted to use Linux was precisely that "make a text file and run a command" appeared simple enough I could understand all the moving parts.
On Linux, you just open up a text editor, write some C/Python, then pop open a terminal and directly invoke gcc/python. There's typically nothing that needs to be installed - and if something's missing, it's just an 'apt install' away. As a beginner you can see how everything fits together since there's no IDE in the way. And if you want to dig deeper into how things work, everything is documented in the man pages.
On Windows, you need to go online, find the right downloads, then install various developer utilities just to get to a working build environment. From there everything is typically done from the IDE - which means setting up projects and dealing with more abstraction.
I'm firmly of the belief that IDEs are a great tool, but aren't something that should be introduced until after students have a firm grasp of the underlying fundamentals.
All of them since Sun started selling developer tools as an additional package?
Plus just because there is a C compiler, it doesn't mean IT has made it available to common mortals, or allowed exec on $HOME for the clever dudes that try to sneak in one.
Me too. Professionally, I develop for a number of operating systems, including Linux and Windows. I much prefer developing on a Linux system over the others, in part because it's easier to get going (most of what you need is installed with the OS), and in part because it's more flexible.
It is the UNIX cargo cult that 100% programmers use UNIX and software on other OSes just appears out of thin air as their users wish for its existence. /s
As somebody who uses both and comes from Windows I must say, that you learn a lot more in a Linux environment. The tooling is also better, because you are not made reliable on one IDE, but instead use a ton of well tested little tools that you can probably use the same way in two decades still.
Don’t get me wrong, IDEs can be great, but they come and go or change significantly over a decade and the knowledge you build with it won’t work once you SSH into a headless server.
Deepin is developed by China-based "Wuhan Deepin Technology", and is pre-shipped by Huawei on their Linux laptops. That's all I need to know to not use it.
> Is there any persuasive reason for a college student today to try desktop Linux?
I think not if we look at Ubuntu, Red Hat, etc. But maybe small ones like Alpine Linux?
This brings up a good question: What good free and open source operating system is out there that would be persuasive for a college student or someone who wants to learn an operating system as opposed to merely using it?
I found Linux From Scratch[1] invaluable when I built a system with it almost two decades ago (but I assume it's still awesome). The trick is to not use the automated build portions and read and follow their page on every step. It takes a while, but you come away with a much better understanding of how the system works.
Someone who wants to understand their system and perhaps program it in C is advised to join those of us in the world of desktop (well, laptop mostly for me) BSD. A fresh OpenBSD install couldn't be more pleasant to hack on, IMO.
If you want lightness, or need the Linux kernel for something, Alpine Linux is a tiny and solid project.
No systemd to be found (not even an option on BSDs; Alpine Linux is OpenRC).
Hilariously, OpenBSD is closer to systemd in its philosophy than anything else — one umbrella project developing all parts of the OS, often depending on each other.
Do you mean the project, or the unit system? I'd argue an init system is very much a key part of the operating system, as important as the kernel. You can't really do much without one.
If you mean the project, then you've missed the point.
Then take KDE as example (an umbrella project with many separate, independent projects below it, all of which are separate binaries, but many work better when used together, or depend on another). Or Gnome. Or any other such umbrella project.
> > > Hilariously, OpenBSD is closer to systemd in its philosophy than anything else ...
> > Hilariously, this is premise is entirely wrong.
Note that you originally asserted:
one umbrella project developing all parts of the OS
And I responded with what I feel confident is a statement of fact:
Systemd is not the OS.
> Then take KDE as example (an umbrella project with many separate, independent projects below it, all of which are separate binaries, but many work better when used together, or depend on another). Or Gnome. Or any other such umbrella project.
The examples you provide are umbrella projects, no doubt, but none are Operating Systems. Neither is systemd.
While the term "OpenBSD" can be used in the context of a distribution (common), OS (common), and the tools used to initialize same (uncommon), systemd only qualifies for the latter.
They also couldn't be further from its philosophy.
Systemd: let's break and change how everything works. You need to relearn everything.
OpenBSD: things work largely the way they've worked for decades. Even as parts of the system are rewritten, the user experience remains very much like it was before, and often the old way of configuring and using things works exactly as before even if the underlying tools have seen a complete rewrite.
> They also couldn't be further from its philosophy.
> Systemd: let's break and change how everything works. You need to relearn everything.
> OpenBSD: things work largely the way they've worked for decades. Even as parts of the system are rewritten, the user experience remains very much like it was before, and often the old way of configuring and using things works exactly as before even if the underlying tools have seen a complete rewrite.
You're arguing a different point. *BSD's focus on 'experience stability' is completely tangential to the fact that it's a curated series of different utilities, tools and programs designed to work together. Much like systemd.
The BSDs are great for that vintage Unix feel, but I find that hardware support is not adequate enough to run it as a desktop OS on modern hardware. Worse yet, a minor OS upgrade can break hardware support that was there before: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172
> Is there any persuasive reason for a college student today to try desktop Linux?
What is this college student studying?
If it's something technical then yes, 100%, you need exposure to multiple different systems, and sticking to your MS enclave is going to seriously limit your abilities.
Despite SystemD Linux is better than ever as a coding OS and as a desktop OS. It works great on a huge range of hardware and it provides frictionless access to tools to code in more languages than you can shake a stick at.
If Gnome is too heavy or restrictive for you (and I haven't gone near it since 3 launched) then try a different DE like Xfce. There's a selling point right there - switch DEs at the drop of a hat.
What sold Linux for me was trying Ubuntu on an old dusty laptop that had been sitting in my closet for a few years. It installed fast and ran fast and I got a good feeling for it in less than an hour. If the default windowing system was slow back and awkard, I would never have had no idea there was another windowing system because I'd have had no motivation to learn more.
Who else here dislikes Systemd? I do. There is so much hidden magic in terms of configuration that when things go wrong, they really go wrong. One of the things that burnt me initially was that journalctl logs are not persistent. They disappear on restart. It needs to be configured for persistent storage.
> We had to update change /etc/systems/journald.conf with Storage=Auto to make it persistent.
RTFM
Storage=
Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If
"volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal
hierarchy (which is created if needed). If "persistent", data will be stored preferably on disk,
i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to
/run/log/journal (which is created if needed), during early boot and if the disk is not writable.
"auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so
that its existence controls where log data goes. "none" turns off all storage, all log data
received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer,
or a syslog socket will still work however. Defaults to "auto".
> Defaults to "auto".
You just need to have /var/log/journal. This is your distribution/installer failing you, don't blame systemd.
This seems to be a typical case of Ubuntu brain damage. I don't think I've seen this behavior in other distributions (CentOS, Debian, Fedora, even Arch).
>On Ubuntu 16.04, /var/log/journal does not exist by default. Create it to keep and query events from previous boots.
> Who else here dislikes Systemd? I do. There is so much hidden magic in terms of configuration that when things go wrong, they really go wrong. One of the things that burnt me initially was that journalctl logs are not persistent. They disappear on restart. It needs to be configured for persistent storage.
The problem I have with the 'hidden magic' argument is that everything that provides some sort of abstraction is hidden magic, until you take the time to learn about it. For more examples of 'hidden magic', look no further than GCC, the kernel, etc.
So then this boils down to "I don't like new things", which is perfectly reasonable. But make that your argument. Sometimes there's a good reason to change stuff, because the old stuff doesn't work very well.
edit as mentioned elsewhere, logs are persisted in /var/log/journal by default. If your distro doesn't create that on install, then that's where your issue is.
In a traditional unix, when things go wrong you can use common tools like grep and text editors and shell scripts to work out what happened. With systemd, there is no way to lift the lid and find out where it broke and how to fix it. That is why the magic is hidden magic, not learnable magic.
PID 1 is not quite the same as other processes. Historically it wasn't even possible to use gdb or strace on it without patching the kernel, though I think this changed at some point. Any crash in it still causes a kernel panic that brings down the system though.
I'm sure we can also find a popular package that isn't default. People do install what they like or really care about. I don't particularly like systemd, but I also don't want to bother switching (better one standard that we improve than fragmented and poorly supported competing systems), so it's okay.
There's a difference between installing a tool that everyone wants, and replacing the init system of a distro. Honestly, I'm surprised that even 1% replaced the default there.
I already voted by removing systemd and moving to sysvinit during the period where debian-installer did not give me an option.
systemd is a constant security hazard, fails standard unix philosophy by doing one thing and one thing well, and is nigh impossible to audit.
systemd is a mistake, adopting it was a mistake, and it gives me nothing that either I don't need or want (not cloud/large orchestration stuff; standalone machines), or DO need or want but actual orchestration stuff gives me while also giving me tiny init systems (in some cases, yes, neutered systemd to limit the security implications and shear number of bugs) to bring my stripped down micro-instances up.
So, the Debian community voted, and for similar reasons as I voted. We don't want systemd, we never wanted systemd, and we will burn the distro down to get what we want. Redhat tried to use systemd to Microsoft-style Embrace, Extend, Extinguish their way into the entire Linux community, and we want nothing of it.
Alternate init systems (upstart etc.) have been trying to fix the sysvinit mess and failed to gain traction. Then systemd came along with a 'we do a little bit more' approach and all relevant distributions (yes, really) could agree upon using it.
I'm very happy the Linux world did something contrary to the Unix wars where everyone was trying to reinvent the wheel until everything collapsed.
Gaining traction often has very little to do with technical superiority, especially when considering long-term fragility or monopolisation of a space.
Systemd has been relentlessly pursued by Red Hat. It's won over some technical advocates, but created numerous enemies and critics. Ted T'so is quoted in the LWN piece. Linus himself has been diplomatic but pretty critical, at least in past (I've not seen any specific comments in the past 2-4 years AFAIR).
When it first appeared on the scene, systemd was promised as a way of shaving a few seconds off of boots. That's not something I was ever particularly interested in (my systems reboot infrequently, I'm more concerned that they come up clean, reliably, and deterministically, than fast). Meantime, systemd is now taking over my logs, network, device tree, time service, cron, and more.
The walk's not matching the talk. The complexity and insecurities remain. And yes, trying to maintain backwards (to sysvinit) or sidewards (to upstart, if that's even still alive, openrc, runit, eudev, procd, nosh, finit, ...) is difficult. It also concedes the initiative (init-iative?) to systemd.
Standards wars against well-heeled forces are exceedingly difficult. Even when technology and history are on your side.
And now for my talk on the year of Linux on the desktop....
> Meantime, systemd is now taking over my logs, network, device tree, time service, cron, and more.
This is a misrepresentation. It does have components for all of those things, but AFAIK only journald and udev (I think) are non-optional. You're free to use cron, chrony (NTP), NetworkManager (or whatever), etc.
The point isn't what I can or can't do (though I'm finding the encroachment despite my attempts to avoid it), the point remains that was billed as faster boot times. It's become vastly more than that.
Source:
the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.
The myth of UNIX philosophy, that is why Solaris, HP-UX, Aix, DG-UX, SGI ... had so many tools with endless list of options and their own service managers much like in what systemd has followed up on.
The Unix philosophy was always a guideline and goal, not a rigid rule.
The usual exceptions to the rule have generally been complexity hubs -- places where a bunch of pieces come together and need to be managed. The shell, editors, email (crossing networking, domain services, local and remote message processing, security, privacy, spam and filtering), compilers, databases, graphics editors, are all examples.
But where small and simple tools can be used they prove an excellent idea.
systemd took a set of small, simple, and fairly independent concepts and bound them up in both complexity and tight dependencies. The fact that even identifying, splitting out, and replicating functionality outside the system is a problem is a symptom of this fact.
> In short: merging elogind appears to be complex enough that it would be hard to justify in the absence of a strong commitment to the support of non-systemd init systems.
I think that outlines the problem well, systemd might be a good init system but it's not just an init system and it's an all or nothing thing. There is no meritocracy of components which has always been a strength of linux.
Sure - for example, systemd can synchronize your system time with NTP, configure your wireless network, and run periodic tasks if you'd like it to. Or, you can use different tools to do those tasks and everything works just fine.
No, hence this article. Note that the system they're having such a hard time integrating is a fork of a systemd component, which is about as close to the best scenario as you could hope for.
Show me an alternative to systemd that matches its functionality and consistency.
The whole point is that systemd replaces a large number of solutions to various system components and there’s alot to be said for pulling all that together into a consistent solution.
The competition to systemd can’t match its power, but there are good solutions for more limited scope situations like embedded.
Systemd is incredibly powerful and is very much a welcome part of software that I build. My system architectures depend heavily on systemd.
knowing what systemd is capable of is really required knowledge for software developers because it can both save you massive time and also enable the creation of systems that otherwise would have required you to write more code.
Systemd is monolithic, and does a lot of things that one might want to do differently. It follows the footsteps of a similar macOS program, and apparently imports a bit of the general philosophy from Apple: one way to do all the things, dictated by the producer of it.
It's much more than an init system; it obviates a number of other components. This may be a desired quality for some. "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
The fact that systemd did not have the highest reliability for years did not help its popularity. It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.
> OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.
Funnily Unix and C are also examples of "worse is better".
Wait, you do not block HTTP referers by default? In this day and age where vast majority of websites are out to scoop any and all available information about you?
The best option I think is to spoof Referer to a random choice of known good values. This, of course, after disabling other, more reliable tracking vectors like JS and cookies that would just identify you as a Referer spoofer.
Given that systemd is just a set of interconnecting components, is it really fair to call it monolithic? While it does ship as a unified project, my understanding is that you can substitute individual parts of it easily enough.
Exactly. Systemd is highly modular, and for the most part can work with a variety of different alternatives and interconnections. There a few hard dependencies but for the most part I don't think it's fair at all to call it monolithic.
If it's highly modular then why (according to TFA) are they struggling to incorporate a fork of a systemd subcomponent? If that's not easy to do then it's not modular.
As I understood the thread, the problem is not that it's hard to get elogind running, the problem is that getting applications to provide tested, supported non-systemd init scripts (or equivalent) requires a commitment from the packager and occasionally from the upstream community.
This is an entirely unrelated question to modularity - the "problem" is that systemd supports certain features and if you want to run without systemd, some other component needs to support them. Such components could be designed pretty easily, sure, but people who are using those features are typically happy with systemd's implementation so there's little motivation to write them.
In the article, systemd's tmpfilesd mechanism is given as an example. It's straightforward to reimplement as a standalone component, but someone has to actually be interested in writing the implementation and writing tests that it behaves like systemd does and keeping it up to date.
What you just described is still very much what I'd call a monolith. Much like if you have a microservice architecure (that we had a system level prior to systemd) then each component should be testable, upgradeable and swappable in isolotation, if you don't have that then what you've really got is a distributed monolith (obligatory xkcd: https://sebiwi.github.io/comics/distributed-monolith/).
What we have here is a dependency chain that pulls in all of systemd, therefor it isn't modular.
It isn't modular just because it's divided into modules.
Each component is testable, upgradable, and swappable in isolation. There are no technical issues with doing so. What is missing is interest in implementing and testing a full-featured alternative to some of the components. As soon as that alternative exists, it's usable.
You wouldn't say that a company lacks a microservice architecture simply because they don't have unused reimplementations of each microservice lying around, would you?
My understanding is that the problem is that extracting logind from systemd required such major surgery that they're worried the other applications which use logind won't be compatible with the modified version. There's also a seperate concern about init scripts for other applications.
It's only modular when it's used like that in practice. I write a lot of "modular" stuff, but it tangles violently first time you actually try to use it in a modular fashion.
Modularity requires more than being a "set of interconnecting components" (otherwise, all codebases with more than one source file would be "modular", and there would be no monoliths).
Modularity implies formalization and restrictions about how components communicate and depend.
One of the goals: the ability to replace the implementation of one component without having to modify/adapt the others (the top-level component (also called 'main' or 'composition root') used to instantiate all the others doesn't count).
If your components can be compiled separately (e.g without having to recompile the whole app), then you know you're modular (however, modularity doesn't necessarily involve dynamic linking).
Real world examples of modularity:
- device drivers of the Linux kernel
- SDL device backends
- decoders/demuxers in VLC
- Cubase VST effects
- Filters in DirectShow and Gstreamer
Real world non-examples:
- LLVM backends: in practice front-end implementations need to know about the various backends, so you can't simply add one.
- GCC frontends: almost modular, however, there's some bunch of places you still need to modify so they know about your new frontend.
- GCC plugins: although no line of code in GCC know about your plugin, your plugin can depend upon almost anything from the GCC implementation itself, in other words, the plugin API is too big (=the density of interconnections is too high).
- Descent 1&2 (the game) enemies: the list of enemies appears at several places in the codebase, so you can't simply add one (=the density of interconnections is too high).
> Descent 1&2 (the game) enemies: the list of enemies appears at several places in the codebase, so you can't simply add one (=the density of interconnections is too high).
I'm not sure why you picked such a specific example, but it looks like read_robot_info() will happily read in additional robots from descent2.ham if you increase MAX_ROBOT_TYPES and stick them in the same global. There might be specific behavior info sprinkled elsewhere in the game, but that is probably code you'd need to touch to implement the uniqueness of new enemies anyway.
The interfaces between those components are not stable and so outside projects cannot reimplement them, which is the entire problem with monoliths. Indeed systemd does not even maintain a stable interface with nominally separate components; it's tightly coupled to particular versions of udev and in turn the kernel.
It's monolythic in the same what that the GNU project or FreeBSD is monolithic.
It's a large number of utilities, tools, and daemons that is designed to provide the low-level features application developers and users demand from a modern operating system.
> It's much more than an init system;
Systemd is a init system, but systemd is also a major project that has taken on the task of unifying low-level Linux OS features.
> "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture.
All these systems have their own init systems they designed with no regard towards Linux and replaced older systems and obsoleted them.
> It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
Lies and misrepresentations.
> OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.
Which is why people are working on replacing both X and SysV.
You want to know the real problem with anything-but-systemd crowd?
This:
> Of course, this approach is not viable if it turns out that too few people are interested in init system diversity sufficiently to do the reasonably substantial implementation work required to maintain a competing implementation of the systemd unit features we care about.
There is no 'If' there. Some people don't want systemd, but the only people doing the work are Systemd. So their choice is to stick with Linux from 2000's or use systemd. Because nobody wants to commit to making any alternative actually work.
Making noise online is annoying, but it ultimately is not something that goes into the decision making of people designing operating systems. People willing to do the work are the ones that get to make the choices.
If somebody comes along and makes a better init system then systemd then they can do it and if it is better it will get adopted.
You can pretend that this is all Redhat's fault, but they are the only real enterprise that made the transition from sysv in Rhel 5, to upstart in 6, and then to systemd in 7.
And, ironically with systemd, migrating to another different init system is massively simplified compared to the work it took to migrate from sysv init. So now moving to a new init system is easier then ever.
Why do I say this?
Because systemd has unified OS design for Linux in a way that never happened with sysv init. Sure people were using 'sysv' and all used shell scripts, but they were all fundamentally different from one another. Only the most complicated shell scripts imaginable (think Apache init) or the most trivial could be made to work on more then one Linux distribution. Meanwhile systemd uses a declarative configuration syntax that all you need to do is create a parser and you could effectively import any systemd application configuration into a system with equivalent or better capabilities in any operating system.
The same can't be said for any of the bash scripts developed by any of the distributions prior to this for their own sysv variant.
> It's monolythic [sic] in the same what that the GNU project or FreeBSD is monolithic.
The FreeBSD system initialization artifacts are not monolithic.
> > "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
> FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture.
This is straw man incarnate.
> > It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
> Lies and misrepresentations.
Not according to here[0].
If you want to be a "systemd warrior", fine, feel free to be so. But don't lump FreeBSD and other Unix systems into your crusade.
BTW, when you wrote:
> Because systemd has unified OS design for Linux ...
Know that an init system, any init system, does not design nor define an Operating System.
And while your disdain for shell scripts is readily apparent, what you proffer as the benefit of "... systemd uses a declarative configuration syntax that all you need to do is create a parser ..." ignores the fact that POSIX shell scripts provide this feature by definition. Including, but not limited to, being able to source other files which define requisite variables.
> The FreeBSD system initialization artifacts are not monolithic.
And nobody claimed that... . The claim was that FreeBSD is monolithic in the same way that the systemd project (logind, nspawn etc. ) is monolithic.
> Not according to here[0].
Okay, let's click on that. First sentence "It doesn't". What were you trying to argue again?
> Know that an init system, any init system, does not design nor define an Operating System.
Are you purposely confusing systemd-init and systemd the project? Because your argument is the same as "GNU does not design or define an OS", which many people would call plain wrong.
> Okay, let's click on that. First sentence "It doesn't". What were you trying to argue again?
And the second sentence says:
What it requires is a service that
implements the same set of APIs as
systemd-logind.
Since GNOME requires either systemd-logind or something that behaves exactly as systemd-logind, how does that not express a transitive dependency on systemd?
So what are you trying to argue again?
> > Know that an init system, any init system, does not design nor define an Operating System.
> Are you purposely confusing systemd-init and systemd the project?
No, what I stated I thought was quite clear: an init system does not design nor define an Operating System.
You are missing the point (and probably on purpose at that). Most people do not complain about systemd as init but evrything else. Furthermore Systemd try to replace software that works better than the alternative it proposes. So your argument nobody is doing it is moot. You're comment, using a part for the whole, is misleading and used every time someone criticizes systemd the umbrella, it's getting old.
> Some people don't want systemd, but the only people doing the work are Systemd.
IMHO, that's not the best way to say what I think you really meant.
There are alternatives for just about every single systemd function (e.g. there are other init system that are not sysvinit). It is true though, that the people implementing these alternatives are far more levelheaded regarding systemd than the haters - at least in my experience.
> FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture.
I dare say there's bit of an irony in that assertion. 4 different operating systems, each of one of which uses a different init system. Pardon me, but that looks like the exact opposite of a monoculture.
Also, the rc system in FreeBSD could probably be ported with not too much effort into other operating systems, as it uses pure sh (not even bash). Surely, that cannot be considered monoculture. I would dare say that porting systemd into FreeBSD (or any of the other OSes you mentioned) should be more difficult.
Could you recommend a good guide to systemd? I learned most of my knowledge of *nix systems on FreeBSD, and as systemd has taken over Linux I find a lot of my traditional knowledge is becoming outdated as years go by. I understand basic aspects of systemd but not programming with it or building systems with it.
First and best place to start is the original "Rethinking PID 1" from Lennart. That will give you a great background in the problem he sought to solve and his thought process:
>Show me an alternative to systemd that matches its functionality and consistency.
What I understand from this topic(about the ilogind) is that you can't even create such an alternative because the packages are depending hard on systemd. So you will be forced in future to re-create systemd features and bugs similar how wine does it for Windows API.
Many packages that depends on systemd actually depends on the logind part. Most of time you could just s/systemd/elogind/ and it will work. However for a big systemd-based distro such as Debian, that means they need to provide support for _both_ systemd and elogind for all packages, which is not an easy task (elogind basically conflicts with systemd) and not worth doing without also committing to support other init systems.
Launchd is arguably the inspiration for systemd and other modern alternatives. Therefore it's very similar in scope and principle. But many parts of how it works, most notably the configuration file format, are distinctly Apple-isms (or more precisely NeXT-isms) so it probably wouldn't feel "native" to the Linux ecosystem without some substantial retooling of the code.
Apparently it's been ported to some extent to run on FreeBSD: https://wiki.freebsd.org/launchd. I'd expect this job gets harder and harder with each passing year, as the last time Apple released source code for launchd was alongside OS X Mavericks.
FreeBSD has been attempting to port launchd since 2005 or so[1]. PC-BSD/TrueOS used to have launchd branch but I think they eventually committed to using OpenRC instead. AFAIK launchd require Mach IPC support in-kernel and require XML parser running in PID 1 so it didn't see much support because of complexity and amount of work it introduces.
Ubuntu actually considered adopting launchd way back in 2006 before systemd existed but: “The option was rejected because the source code was subject to the Apple Public Source License – described as an ‘inescapable licence problem’” [0]
A lot of the systemd criticism (whether right or wrong) makes the claim the design is wrong. You can't really address that by asking critics for a precisely equivalent/capable implementations of something they feel is fundamentally misdesigned.
The issue is that many believe that the feature set is the problem. Why do you need consistency across services that have little in common?
The basic idea of an init system is pretty simple: start services in such a way that the system comes up reliably. There are two main approaches here, simple but inefficient or complex and more efficient. The FreeBSD/rsysv approach is the former, while the systemd/launchd approach is the latter. If I just want to make sure services start on boot in the right order, why not just have a script run it all? For 99% of use cases, it's good enough, so why complicate matters?
I do appreciate systemd and the faster boots I get from it, but I still find myself longing for similar init systems.
For a replacement for cron...sure, that's nice too. The benefit of being able to manually activate a timer in order to test it is completely worth it.
For an NTP implementation? Eh. I'm not sure why that needs to be bundled in under the same umbrella as the service manager. It's also just an SNTP implementation, not full NTP, so it's notably feature-crippled relative to better options like chrony.
Network management? Meh. Again, that strikes me as something that should be loosely coupled to the service manager.
A UEFI implementation? gummiboot was assimilated and become systemd-boot. Was that necessary for technical reasons, or was it just moving a project under the systemd umbrella similar to how there's an umbrella of GNU projects?
Container management? Another place where systemd-nspawn doesn't strike me as notably better than the alternatives.
At a certain point "systemd" becomes a brand more than anything else, sort of like what IBM has been trying to do with Watson. Yes, it beat Ken Jennings at Jeopardy and that's great. That doesn't mean anything associated with the overall brand is automatically equally amazing.
Many of those things are not all or nothing. For example you can use chrony with systemd. RHEL 8 does that by default. You can even install rsyslog to consume logs if you want, and it works just fine.
I agree systemd tries to do a lot (maybe too much) and often isn't better than alternatives, but I don't think that's a big deal since you can still use the alternatives quite easily.
Yes, sorry if what I wrote was misleading. You can't replace journald with rsyslog, but the only complaints I hear about journald are that it's binary so you have to use journalctl to read them. By installing rsyslog you basically get the classic log behavior back. So technically under the hood you're still using journald, but you never have to know it.
My main complaint is that journald is unreliable and is losing log entries (or lines, if you will).
I had an automation recipe that would start a bunch of cloud instances, configure them and start certain job via a systemd service unit, and collect logs from this job 24 hours later. Initially, we were pulling these logs via journald as logs for that service unit. But then we noticed that random lines (1-5 lines out of maybe 40 for a single job) would be missing in about half the instances.
We ended up pulling those logs from files in /var/log instead, made courtesy of rsyslog. Not a single missed line.
Again journald is unreliable and as a whole should be nuked from the orbit.
Sometimes between August and September, and it was on Suse Linux Enterprise Server 12.
The lines would go missing mostly if the logs were collected two or three days later instead of immediately after the job finished (it was a job running for 24 hours), which leads me to think it had to do with journald expiring entries to save on disk space. A consistent log manager would expire them chronologically, but here the lines were missing from the middle or the end of the output, so not the oldest ones logged.
Filtering journal contents by metadata is known to be unreliable.
It's not that the logs are missing, it's that they're not getting included by your query.
The way journald associates log lines with process metadata is inherently racy.
This situation has improved some with the metadata caching changes, but IIRC there are still some holes where processes can log without journald associating accurate/up-to-date metadata with the logged info.
That makes sense, I guess, in a rather warped and bizarre way. The point still stands - journald is unreliable, and after getting burnt like this it will be years before I start trusting it again.
I concur. We also saw an issue with journald missing whole hours of logs, randomly, on our embedded platform. Couldn't replace all of them with log files due to SSD degradation (we actually calculated it we were missing target device lifespan, this is not a consumer problem of course). Basically we added log files where we could, plus remote logs and left journald as-is, it can't be replaced and can't be fixed.
There are a whole lot more complaints than that for journald.
The most common one (and one I share) is how slow it can be. `systemctl status foo.service` takes a significant amount of time on any of my machines thanks to the journal, and that's just the reader side.
It used to be quite crashy with lots of CPU overhead, but that has improved over time, the metadata caching helped a bunch with the overhead.
There was also a pretty embarrassing CVE not long ago:
Right, which just turns rsyslogd into another consumer of the journal data analogous to `journalctl --follow --all`. You still have all the overhead (and surface area) of journald being in the loop of everything logged.
Many people when they encounter problems with journald want to continue using systemd for their service management, but revert to the old world of low-overhead metadata-free unstructured syslog O_APPEND text files for everything logged.
If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s.
It's not an impossibility, the systemd developers just seem to have zero interest in implementing stuff that enables escaping their overall architecture. I imagine all that's needed is some minimal IPC glue to forward all the stdout/stderr output from services to syslog when journald isn't in use. Systemd's role is to wire that stuff up to journald currently, and it's unnecessarily opinionated about journald being the only supported target in that role.
> If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s.
Journald and udevd are exactly the only piece of systemd that systemd's pid 1 requires, and udevd can be used independent of systemd's pid 1.
I just think of journald as a piece of the init system that is split to a separate process, and provides log data to other programs.
First of all, no, systemd as in PID1 does not get logs back from journald. The systemctl command is using the sd-journal API to do that directly from the journal files.
Secondly, I don't, I expect the recent logs portion of `systemctl status $unit` to be suppressed when journald isn't present.
Note that journal-caused slowness of that very command is a common complaint aimed at journald contributing to people wanting to remove it!
Yes, certainly the ability to use other options is still there. But one of the main selling points of systemd (and one that the GP comment was extolling) was the consistency of systemd. And you can't have it both ways - is it great because it's a consistent, cohesive system that provides everything you need for a Linux system, or is it great because it's a modular toolkit that allows you to pick & choose which components to use?
I was an Arch Linux user before, during, and after the systemd transition. I welcomed it initially, because pre-systemd Arch had a lot of "here's how to decide which logging daemon / cron daemon / etc to use" which I always thought was unnecessary. As I said, I think it's a great service manager.
But I've also had to deal with production servers using systemd-timesyncd and pool.ntp.org that would occasionally have system clocks that were off by ~10 minutes. SNTP was deemed "good enough"; SNTP doesn't handle falsetickers well; and under dynamic Docker workloads systemd-timesyncd would decide "network configuration changed, better synchronize the clock" every time a Docker container started or restarted.
If I use systemd as a service manager, why does that also imply I'm making "default" choices for boot loader, (S)NTP service, network manager, and container manager? Each of those has no reason to have any sort of coupling to my service manager.
My biggest quibble with stories like this one is that they keep focusing on the decision of systemd as service manager / init system rather than the umbrella of other jobs that the service manager has no good reason to try to take over.
> And you can't have it both ways - is it great because it's a consistent, cohesive system that provides everything you need for a Linux system, or is it great because it's a modular toolkit that allows you to pick & choose which components to use?
You absolutely can have it both way. Systemd is great because it offers a set of tools which are consistent, provide a lot of the functionality you want on a workstation in a cohesive way. It doesn't prevent you from choosing not to use one of the components developed under the project umbrella and uses something different instead. Systemd is modular enough for you to do that.
> But I've also had to deal with production servers using systemd-timesyncd and pool.ntp.org that would occasionally have system clocks that were off by ~10 minutes. SNTP was deemed "good enough"
Why are you using timesyncd if you need more than SNTP ? Timesyncd is not shipped by default with the systemd init system. It is not even installed by default on RHEL. Nothing prevents you from using a different NTP client with the systemd init system.
> If I use systemd as a service manager, why does that also imply I'm making "default" choices for boot loader, (S)NTP service, network manager, and container manager?
It does not imply that at all. You absolutely do not have to use the boot loader, timesyncd, networkd and nspawn with systemd. They are not even installed by default on some distributions. They are not coupled to the service manager.
Been trying out systemd-networkd for a couple of years now and it is a mess. Especially when you want to do something like ipsec/vpn/vxlan. Also, no possible way to reload a specific interface?
> Especially when you want to do something like ipsec/vpn/vxlan.
I have a wireguard tunnel setup by networkd with custom rules to only send traffic from a slice through it. It works fine. Take a look at the netdev documentation [1].
The problem is rather how the troubleshooting works.
You don't know how the network will be parsed or which statements that works with your version. Very difficult to debug when it doesn't behave as it should.
After a lot of fiddling with source routing on e.g. Debian Strech I was able to something working. But only half of the times I restarted networkd.
I would like some better tooling to assist with more difficult setups.
Hm, Stretch has an old version, no? Or do you use a backport repo?
But, yes, turning on debug mode is harder than it should be, and it's usually not the right level. (I usually just go for strace first, but with netdev I guess it's using netlink to talk to the kernel, so that'll not help much :/ )
Backport, because all the needed statements are not there.
I use strace etc (and debug level in networkd), but then you realise that this should make it easier not tougher. I did learn about ifup -v though which gave me all I needed. But both tools silently ignores flags that is wrong.
I'm writing my own tool now that is more strict in that sense instead.
Sorry about the rant but it's at least three trips to get everything working flawless in systemd-networkd now..
When it comes to Linux networking I find that tooling is very, very, veery bad, compared to what it should/could be.
Of course it's free and open source, so we can at least try to make it better besides complaining, but that part is harder than it should be (otherwise the whole problem would have been "solved" by now).
Totally agree. I find network management bad wherever you go.
Systemd-networkd is fine layout wise, it's just the tooling that could be improved upon. Also here you see the problem with systemd-networkd being shipped together with systemd deb, if it were to be standalone it would be so easy to backport just that.
Funnily enough I found it much easier setting up networking in weird configurations using Gentoo... For simple DHCP stuff yeah but iirc you can use NetworkManager without systemd.
For servers which get set up once and are expected to be left alone from then on, that's not the case.
With anything dynamic though - laptops, VMs - the various solutions can be pretty hit and miss. NetworkManager was terrible for many years, but seems relatively ok these days.
What I always wondered is: Why is a lot of the discussion about systemd vs initd when systemd is so many things. And the follow-up question would be: Why hasn't anyone taken apart systemd and reused only the parts they found useful, like the system manager for example. "Systemd: The Good Parts", so to speak.
That is pretty much the issue: to some, systemd is too many things.
Realistically, one tends to take or leave an upstream package since picking and choosing pieces of it is far more work than a typical package maintainer takes on. Also, upstream design decision changes can make doing so problematic down the road.
> picking and choosing pieces of it is far more work than a typical package maintainer takes on.
Not necessarily. RHEL does not ship gummiboot, timesyncd or networkd for example; it uses grub, chrony, NetworkManager. On my raspberry pis running Debian I have systemd as pid 1, one runs ConnMan (it connects to wireless) and the other runs networkd (it connects to Ethernet).
The article mentions that Debian does not have these "embrace, extend" problems yet because they've been using a fairly old version of SystemD, but they are going to run into those issues when they upgrade.
Doesn't necessarily imply that in general, sure, but for the specific cases of systemd and timesyncd/gummiboot/nspawn, they are in fact trivially separable. I'm pretty sure that's even the out-of-the-box config of Debian.
I'd say that is one of the complain I hear often "systemd is so many things", Unix philosophy tells you to do one thing and to do it well, a lot of people against systemd were against it for that reason.
"do one thing and do it well" does not mean "intentionally only support one piece of hardware". If your do one thing is "offer a bootloader that works on your hardware" or "offer device detection and driver loading for all your devices" that is not somehow scope creep. It's the only sensible way to architect those things.
Similarly, curl supporting both HTTP and HTTPS is not a violation of "do one thing and do it well" - if you fail to support at least those two protocols, you've built a shitty tool.
It's best to consider "do one thing" in the context of "what does the user want the software to do". A web browser having lots of functionality baked in is not necessarily a violation of this principle if all of that functionality is used to solve one user problem (I want to view YouTube, or I want to use GMail). At that point, the factoring issue lies somewhere else - the definition of the web platform, etc.
Systemd attempts to solve very many user problems all at once, with varying levels of success, and other software packages have solved one or two of them at once instead. In that case there is a clear way to separate the ones that probably apply the "unix philosophy" and the ones that obviously do not.
The Linux kernel and related components themselves sort of violate this, but that's mostly a matter of necessity - super-modular microkernel designs have not worked out great in practice. However, it still is built around relatively narrowly-scoped drivers for individual devices or services, instead of massive Megadrivers that handle every component in your system. Your PC may have an Intel GPU integrated on the CPU die, but it's still using a separate video driver, and the video driver is probably separate from things like the compositor and the actual PnP layer beneath that detects what hardware you have.
If you look at the average USB device in Windows' device manager (this is probably true in Linux as well but I don't know how to dump the data), you can see a given device like a mouse or a phone is actually split up into a bunch of sub-capabilities exposed by the device, and those can each have their own driver. Same thought process there.
> You can use systemd without almost all of the sideparts.
Can you? The whole premise of systemd revolves around ability to use existing init files, written by upstream developers.
Upstream init files are going to use arbitrary parts of systemd functionality, which may include network and container management, timers and God knows what else.
So in effect you HAVE to use those parts of systemd — unless you are insisting on writing all your init files from scratch (at which point you may as well use any of systemd alternatives).
For one, have you ever written an unit file? It literally takes 3 minutes.
And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I?
I've tried, it was more like 3 hours before I gave up and I was only writing it in the first place because systemd got involved where I didn't ask it too. All I did was mount a network drive from a shell script and systemd decided that it didn't know how to unmount it and instead hang for 90 seconds when the system shutdown.
Systemd defaults to the kernel's standard way of unmounting filesystems (i.e., umount(2)). You would have to write a .mount file only if your filesystem _couldn't_ be unmounted the normal way.
The alternative for systemd would've been to shutdown the system without waiting for a clean unmount, which can lose data, which is what used to happen with SysV. The alternative for you would be to unmount your filesystem yourself before shutdown, which is what people used to do with SysV. Some SysV distros even had scripts that tried to automatically clean up mounts before shutdown, which is exactly what systemd does now, and your 90-second hangs would've shown up there too.
> The whole premise of systemd revolves around ability to use existing init files, written by upstream developers.
There are many premises for which systemd was designed, but this is not one of them, let alone "the whole premise".
1. Before systemd, upstream developers were never precluded from supplying their own init files, and many often did.
2. Even in systemd, downstream maintainers and users were never precluded from modifying, overriding, or even completely replacing upstream-supplied init files.
The difference is that with SysV upstream-provided init files were often bad because upstream developers had to use a bunch of hacks in shell scripts to (necessarily reinvent and) supply features that were essential but SysV couldn't provide. The distro maintainers and users were thus sometimes _forced_ to try and fix upstream-supplied init files, but even they could do only so much because ... shell scripts on SysV.
Systemd allows everyone (upstream and downstream) to write better, cleaner, more maintainable init files.
> which may include network and container management, timers and God knows what else.
1. Timers are a core requirement of service management, and they're correctly a part of the service manager that is systemd.
2. network management (systemd-networkd, systemd-resolved, and .link, .network units) and container management (/var/lib/machines, machinectl etc) are _not_ service management features and are _not_ implemented in pid-1 systemd. I have also not seen any upstream package that used them. In fact, these features _cannot_ be used from service unit files.
> ... unless you are insisting on writing all your init files ...
It's not an all-or-nothing affair. It never was, not with systemd not with SysV.
> ... at which point you may as well use any of systemd alternatives
Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false.
>Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false.
Not to mention, systemd is much better than the alternatives in terms of allowing the sysadmin to override parts of the config for a service without needing to merge in updates from upstream later on. I can just add an override for e.g. PrivateTmp=yes and if there's some update to the original unit file later on, it'll apply that update but it won't mess with my override that I set up.
With SysV I'm stuck with updates being a pain that I'd need to manually merge every time there's some change if I didn't want it to just nuke my changes.
Mostly because the many projects under the systemd umbrella are somewhat coupled and not that easy to use outside of it.
For example many of the larger DEs use logind because it is good at what it does and consolekit at that time was not really active anymore. That meant that for example freebsd had to either make the DEs work with consolekit (and maintain it) or make a logind implementation work with their implementation.
This is one of the confusing things about the discussion. The systemd project very much follows the "unix way" in that there are lots of subprojects that do one thing well, but is developed in a cathedral style (just like the *BSDs are) and not easily reusable, which kinda loses the benefit.
> many of the larger DEs use logind because it is good at what it does and consolekit at that time was not really active anymore.
More that ConsoleKit developers and logind/systemd overlapped. For GNOME, logind seemed better and used to be separate. A warning that it would not always stay decoupled was underestimated/ignored.
Once logind was tied to systemd all hell broke loose :-P
Having something like systemd is great; e.g. GNOME has various user services running. Nowadays systemd manages those user services. But as great as that is, it makes non-Linux more difficult. IMO systemd on Linux makes things very easy and it's better to standardize on it.
Because it was originally advertized as an optional init replacement. The acrimonious debates were because a number of people did not believe that's all is going to be, given the history of its designers.
Of course, nowadays many people would flat-out deny that systemd was sold as an init replacement, and claim that what you see was the original intention all along.
At the time of the Debian debate around systemd it was already very clear that systemd was not just an init system. The systemd website at that time already mentioned it to be "basic building block for Linux". People just pretending it is or only should be an init system was one of the annoying things about the discussion; people only compared the init system part of things and ignored that systemd offered more to developers. Any additional functionality was "not to be used" or "developers should offer alternatives". That wasn't very realistic then and now.
I've been waiting for almost a decade now. In the meantime I've run systemd in production on thousands of servers (with no audio card) at multiple jobs. How much longer should I wait for horrible things to happen, or can I safely assume that they're not happening?
You're moving the goalposts. I was supposed to be horrified at bad things like PulseAudio being merged in, not vague bad things in general. If anything, the fact that none of these servers use networkd nor (until very recently, well after that bug was fixed) UEFI is a sign that in fact systemd isn't a giant glob and I can pick and choose components. So, bring on the PulseAudio merge, if it's anything like networkd I have nothing to fear.
systemd is a dependency graph solution. If you have to know "when network is available" or "when time is synchronized", your init system has to know about these events and that is why I imagine they coupled network and time services.
Could it have been done any differently? Perhaps. Would it require more moving parts? Definitely.
systemd is a distro. I imagine it would have been a heck of a lot less controversial if it had been upfront about that, instead of stealthing into other distros as an 'init system' and then consuming them from the inside like a chestburster from Alien (1979)
Dhclient has a lot of hooks where you could easily stick a script or binary to report back to systemd what the state of the network config is. But that would require systemd folks to spend time and effort on thinking about how to integrate existing software into their ecosystem, so they rather roll their own, which obviously takes much more time in total, but it fits the general NIH attitude of the whole project. Oh and it gives them the opportunity to repeat every mistake ever made regarding writing DHCP/NTP/... clients made during the past thirty years, plus some bonus RCEs.
Im advocating using existing stuff instead of reinventing the wheel. Making it work with existing DHCP clients is certainly less code than implementing a whole new one.
Are you familiar with the development process? Like, do they one day go "ok we are gonna build a dns into systemd now, let's open up the RFC for that, print it out and stick the papers on the walls gogogo" or is it like, "let's incorporate vital parts of state of the art into our project" ?
systemd-networkd uses a ridiculously asinine process for determining something as simple as "network is ready", so I'd hope that isn't actually considered one of its core functions upstream.
> At a certain point "systemd" becomes a brand more than anything else
Bingo, so what's the problem? Except for the timer/cron functionality, everything else you listed is separate software that just comes from the systemd brand.
Service manager and container spawner is the same thing. So yes. The whole insight of systemd is that the cgroup tree can be used for service management. It was a container manager before container management was even a thing. (Including private mount namespaces, network namespaces, all that shebang)
Systemd-nspawn contains no new code; just calls existing systemd library code. It gives people a familiar image based interface for a small cost in terms of lines of code.
Bootloader i have a less strong argument for but at least it allows them to iterate in hopefully-standards-soon.
Also systemd-boot is not an UEFI implementation. I'm not sure where you read that. It's an extremely small UEFI executable that lists a list of boot entries. (Note that an UEFI executable is just a Windows .EXE file).
UEFI itself has more lines of code than the Linux kernel, replacing it would be insane (though very noble. See coreboot and Linuxboot projects).
One argument is that it allows them to iterate on standards like the following:
Well that's why it's modular. Let's examine the biggest systemd cool aid drinkers, Red Hat. Fedora 31 comes with NetworkManager and no systemd-networkd by default. It doesn't come with systemd-boot. You have to manually install systemd-nspawn. All of this is true on RHEL/CentOS too. With systemd being able to do a lot, doesn't mean it actually does a lot in practice - not yet at least.
On Debian, systemd similarily basically only takes care of service and timer management (and cron is still available on all systems). I guess it does NTP too, I don't really spend much time thinking about my NTP client.
Yes, systemd is a brand. But just like you don't have to eat every burger at McDonald's, you can choose what works for you.
How is the systemd project any different in that respect than the GNU project, or FreeBSD? If you don't want systemd-boot, or systemd-networkd, or literally anything other than core systemd and the journal you don't even have to build it, let alone install and run it.
The only part of systemd other than core init that you have to run is the journal and even then you can configure the journal to just forward to rsyslog and not store any logs even just in tmpfs.
Stuff like systemd-nspawn wasn't even developed to be a container management solution. IIRC the main goal was just to leverage the existing namespacing features in core systemd to allow booting up a minimalistic container in order to make developing systemd easier.
I built a RPi-Distro using pi-gen a couple of months back. I still have to figure out how to enable wifi using systemd. There are lots of pieces here and there.
Earlier it was just one (config) file and one start/stop script.
systemd-networkd is completely optional. In raspbian it is disabled by default and a very simple unit-file that calls ifup/ifdown is used. For wifi you obviously have to configure wpa-supplicant or use NetworkManager.
> Show me an alternative to systemd that matches its functionality and consistency.
As for init system, I would argue nosh[1] is a better init system. It’s based on daemontools design (same as s6, runit, etc, where it’s just a process that monitors a service directory). nosh can even semi-automatically convert systemd unit files[2] to a run script (including socket activation and all).
For everything else that is not part of the system initialization process (initialize/running/shutdown) I don’t think they need to be tie into PID 1. elogind aims to do this job of taking the logind part out of systemd into its own service, which I found to be a good way of living in systemd world without using systemd (e.g. GNOME works) but it requires a lot of commitment of patching everything to link against elogind instead of systemd (Void Linux/Artix Linux are doing a good job at this).
> Show me an alternative to systemd that matches its functionality and consistency.
I'm using runit on void for years now. It has no functionality besides being a service manager. Having more functionality is a non feature.
> because it can both save you massive time
It also can cost you massive time whenever it doesn't work. Then you have to dig yourself through an opaque mess caused by literally millions of lines of C code. I wouldn't trust it with any mission critical. The only usecase for systemd I can think of is grandmas laptop. Maybe that is the target audience for debian, who knows. It is certainly not me.
> Show me an alternative to systemd that matches its functionality and consistency.
My issues with systemd do not pertain to functionality and consistency: rather, they are issues of taste, style, competence, design and size.
The basic ideas behind systemd are, frankly, great. The free desktop really really needs something like it. 100% behind the idea and the functionality.
The consistency is pretty good too, I think. It would be taste if it were less consistently in bad taste and more consistently in good taste.
Which brings us to taste. First, systemd is security-important system software written in C. Why? There is no good reason to write software in C in 2019. Use a safer language like Go or Common Lisp (both of which are performant enough). I don't know if Java or other JVM languages would work. Perl probably would, although ensuring that a Perl project produces sane code is … difficult.
Also on the issue of taste: systemd incorporates Windows-style .INI files wholesale into Unix-like systems. The freedesktop.org folks were already doing this, but why encourage it? The world has at least two better text-based alternatives to .INI files: S-expressions and YAML. Even JSON would be better, even without comments.
Also on the issue of taste: systemd just doesn't feel like Unix. In order to get anything done one has to hand-edit lots of little files rather than run a few commands. It's a bit like if you had to run a text editor on a directory to add a file, rather than just creating the file. I'd love to see some commands like mktimer, mkservice or somesuch.
I am mostly over the binary logfile issue — after all, ultimately everything on a computer is stored in binary — but I do wish that the tools were a little saner. It's still a pain to figure out where error outputs and so forth are going.
The manner in which systemd takes over the world is completely inexcusable. I fully expect to see systemd-browser within the next decade, no doubt with just a few hooks to prevent using Firefox or Chromium, and of course with a few security issues just to spice things up.
I really wish that someone with good taste had managed to get the attention of and money from Red Hat in order to design a clean, intelligent, 21st-century init system.
Systemd doesn't replace a large number of solutions; it contains a large number of solutions.
Also, in the article:
> Others, including Triplett, said that not only do the developers of other init systems lack the desire to implement systemd features, but they argue that those features should not exist in the first place.
Something with all the functionality of systemd is just another systemd, which some people don't want in any shape or form.
Systems is awesome because writing a service is as simple as writing a unit file. You don’t have to worry about daemonizing, you don’t have to worry about logging (use systemd syslog option).
Systemd is hosted on GitHub and while that can be forgiven because it was recently that it was acquired by Microsoft, it uses Microsoft azure pipelines. I don't think I can forgive that. I refuse to work with anybody that uses Microsoft stuff. (Vscode is fine because I use it)
Systemd in my opinion is a great idea with bad implementation like polkit. It is needed as modern systems are dynamic so global system state keep changes various types of events suck device, path, socket, ipc calls, network, etc.
There are 3 ways to deal with this:
> Assume things are static or hack the support. Sysvint and openrc does this. It tends to hacky as you are create a static setting in a dynamic environmet. This is analogous to using synchronous api to deal with async operations.
> Create a monolithic suite of daemons which handle the state as internal api. Example is systemd and launchd. It tend to be feature creep as you can't replace internal component so you need to deal every use case.
> Have state daemon with each class of state and event is handle independently but a protocol to make sure state is share properly. No init I know of does this.
A great example is if you want do some recuring action on an external network drive. The service manager must know the program the has been run. the Timer program must know if the drive has been mounted. The mount manager must know the network is on or off. The network manager must know if the device interface is on or off. So there is complex dep trail which is very dynamic. the 3rd option is best but 2nd is a compromise and thats what systemd does.
Great article. For those who didn't read it, removing or switching away from systemd is not on the table. They are deciding whether to even support alternative init systems at all, and whether there's enough developer interest to do so.
On the one hand, there are no serious alternatives to systemd. (There are unserious ones like OpenRC, and abandonware like upstart.) And there's no point in Debian crippling itself in the hope that a serious alternative will spring up. Personally I find it intrusive and unintuitive, but I'm willing to admit defeat. Might as well take the plunge and go all out.
On the other hand... man, it's sad to see the state of things, where IBM/Red Hat employees basically run the entire Linux userland, and stuff Red Hat doesn't use gradually bit rots away. We saw it with Gtk3's poor support for non-GNOME apps, we're seeing it with various systemd components being required for GNOME (which incidentally breaks non-Linux OS's but who cares about those?), we're going to see it when Wayland replaces X and breaks every old app that hasn't stuck with the upgrade treadmill. As a Debian user since the early 2000s, it saddens me to think of all that we're going to lose because "Linux is not about choice."
> IBM/Red Hat employees basically run the entire Linux userland
This seems like a very dishonest exaggeration.
> systemd components being required for GNOME (which incidentally breaks non-Linux OS's but who cares about those?)
Is it not true that it's completely up to GNOME to choose what platforms and operating systems they wish to target? Is it also not true that GNOME, being open source, can at any time be forked (like MATE) and developed separately by those who disagree with where the project is going? This is an age-old saga in the world of open source, and I don't see the issue.
> we're going to see it when Wayland replaces X and breaks every old app that hasn't stuck with the upgrade treadmill
What do you suggest should happen instead? Wayland shouldn't happen? Unless replacing and breaking happens, nothing happens. We can't just ship X as the default forever and hope that Wayland won't slowly die while people voluntarily tweak their installations and move over.
> As a Debian user since the early 2000s, it saddens me to think of all that we're going to lose because "Linux is not about choice."
In what way is Linux not about choice? It's such an incredible hyperbole, and it couldn't be further from the truth.
In some ways, the infected discussions around open source mirror those of free speech. People conflate "censorship" with "being ignored", just like people conflate "nobody wants to maintain your pet project" with "Linux freedom of choice is dying".
The answer has always been the same in all FOSS discussions: If you want something else to happen, put in work hours, or donate money towards realizing your vision. If you're not willing to do either of those, your individual opinions on where Project X is going are very likely just noise.
>> IBM/Red Hat employees basically run the entire Linux userland
> This seems like a very dishonest exaggeration.
Definitely a dishonest exaggeration. Google runs Linux userland. Have been for entire last decade. Unless by "userland" you means something other than "system, used by most of users".
> Definitely a dishonest exaggeration. Google runs Linux userland. Have been for entire last decade. Unless by "userland" you means something other than "system, used by most of users".
I'm pretty sure they meant "runs" in the sense of "runs the show" (make the majority of the decisions in Linux userland projects) not in the sense of "uses".
> I'm pretty sure they meant "runs" in the sense of "runs the show" (make the majority of the decisions in Linux userland projects) not in the sense of "uses".
I was not meaning that in some twisted way. Most computers on modern Internet are smartphones — desktop use is slowly declining. And Google runs the show on the dominant smartphone platform. Red Hat's desktop is completely irrelevant in comparison.
You didn't mean it in that way, but the parent comment you were responding to did mean it in that way. I don't think anyone could in good conscience argue that RHEL Desktop is the most widely used Linux platform, so I you're not gaining much by refuting that argument.
(As for your point, Google -- even on Android -- still uses plenty of software which is majority-developed by Red Hat and other Linux distribution companies. The kernel alone is an obvious example, but there are many others.)
>The answer has always been the same in all FOSS discussions: If you want something else to happen, put in work hours, or donate money towards realizing your vision. If you're not willing to do either of those, your individual opinions on where Project X is going are very likely just noise.
This.
All this whining is mostly done by those that don't contribute anything at all but leech off others work.
> Is it also not true that GNOME, being open source, can at any time be forked (like MATE) and developed separately by those who disagree with where the project is going?
It's not true when they're unwilling to commit to stable interfaces (and indeed sometimes make changes that appear to break compatibility with forks for the sake of it). The reason GNU/Linux is based on Unix isn't that Unix was the best OS design, it's that Unix's loose coupling philosophy was the only thing that made rewriting it as open-source possible at all. If the only way to fork any one Linux program is to fork all of them (and that's the path we're going down) then you don't have freedom 3 in practice, even if the program is notionally under an open-source license.
> What do you suggest should happen instead? Wayland shouldn't happen?
If the cost of Wayland is removing the ability to be cross-platform then yes, it shouldn't happen. Microsoft manages to make their proprietary programs run on FreeBSD. NVidia manages to make their proprietary drivers run on FreeBSD. If a flagship open-source project can't manage to run cross-platform that's pathetic.
> man, it's sad to see the state of things, where IBM/Red Hat employees basically run the entire Linux userland, and stuff Red Hat doesn't use gradually bit rots away.
Word, but that's the symptom. The cause is a severe lack of developer time. If no one develops the Linux userland unless they're paid for it by companies like Red Hat, then of course the entire userland will eventually come from those companies.
For the same reason, Debian currently can't afford to burden its maintainers with supporting alternative init systems, which means they still have to write legacy init scripts and reap none of the benefits of systemd.
This is such a perfect example of a combination of overly exasperated negative of the current to glorify supposedly perfect past that is boarders on party.
Yeah, it is. It just feels like there's a lot less energy in the Linux dev scene than there was back then. Not entirely a bad thing, mind you, a lot of that energy produced heat instead of light, but still...
Systemd is at odds with the core design philosophy of UNIX. That is do one thing and do it well. Systemd has been brilliant for speeding up the boot speed, thanks for that! But I do understand the controversy of systemd design.
It is not, because it's made of modules that do one thing very well which are then woven together, to work in unison, which is opt-in for distribution maintainers to configure.
systemd at it's core is very much adhering to UNIX principles.
> The Unix philosophy died when ls learned to sort its output and find learned to execute commands.
As for "find", I leave the explanation of it to this[0] recounting. Suffice to say that one command doth not a philosophy make.
Regarding "ls learned to sort", let's put this trope to rest, shall we?
The 'ls' command, as I am sure you and all whom read this posting are aware, is described[1] as:
NAME
ls -- list directory contents
Now there are many command options which have been added to 'ls' over the decades, no doubt. But you partially identified the death of "The Unix philosophy" as being "when ls learned to sort," so let's focus on that.
The implication of that assessment, in this context, I assume to be a reference to "do one thing and do it well."[2]
Which begs the question; what is the one thing which 'ls' must do? Given the summary description quoted above, that "one thing" is:
list directory contents
This leaves the remaining conjunctive clause of "do it well."
Since the operation of 'ls' includes both filtering and production due to the functional requirement of having to "list directory contents", there exists two disjoint concerns which must be addressed in order to satisfy the goal of "do it well." For example, an invocation can involve identifying C source files ("*.[ch]"), yet want the production of the files which match based on when each file was last modified ("-c").
To achieve sorting on the modification time using another program, such as sort[3], would require 'ls' produce both the desired output as well as out-of-band information needed to sort[3]. This also implies that the desired sorting (such as numeric or lexiographic) must be provided out-of-band as well. And this, too, would imply that sort[3] is made aware of what/where the out-of-band data can be found. All of this leads to a "Leaky Abstraction."[4]
Instead, if one identifies the functional requirement of 'ls' to treat both filtering and production as coequal concerns when listing directory contents, the need for 'ls' to "learn to sort" becomes self-evident.
INI files and usingCamelCase always felt like an odd choice for something trying to replace the heart of a Unix system.
Of course, these choices don’t matter at all in the grand scheme of things, but it’s also these little design differences that seem to nudge systemd into the contrarian oddball bucket, for me.
Kind of like the summer intern that wants to refactor lots of code and changes the coding style while doing so.
Systemd seems so big because of the way it is branded when in fact it is many different parts put together. What people refer to as systemd is many different parts that have been branded as such.
It's like saying gnu is bloated because it is 395 different packages [0].
Systemd-init does one thing and does it well. Logind does one thing and does it well, etc. . GNU and FreeBSD are then also at odds with the core design philosophy of UNIX.
Speeding up booting is a nice side benefit but not at all what systemd is about.
> Speeding up booting is a nice side benefit but not at all what systemd is about.
That's a claim I've seen before. Maybe it's true, but it's not what I get from reading the initial introduction "Rethinking PID 1" [0] is that systemd is very much about fast booting. That blog story says:
"As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.
For a fast and efficient boot-up two things are crucial:
- To start less.
- And to start more in parallel.
"
The remainder of the post talks mainly about those things. In my mind, that clearly means that fast booting was the major design goal of the project.
(Off topic to your comment, but what the post does not talk about is taking over lots of unrelated services. Even the name of Poettering's blog, "Pid Eins", seemed to indicate that systemd was meant only as an init-implementation. That would have been a lot better).
> This doesn't mean being fast was irrelevant for us, but reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.
> That would have been a lot better
Yeah, I noticed that all the complaints about systemd almost never are about the init implementation. Instead people complain about journald (e.g. binary=plain text+time stamp instead of just plain text) or networkd or about Poettering or how there is some shadowy conspiracy. Honestly, I think if all the non-init parts had another name like "linux plumbing project" and were developed separately by non-Poettering, much fewer people would complain (even though the software is the exact same).
It would also make discussions much clearer if people said in the beginning what exactly they are complaining about, e.g. "logind is buggy" instead of "systemd is evil".
As said before, Poettering opens his introductory blog post "Rethinking PID 1" with a bit of history, and then immediately writes "As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast." That's the very first thing he writes about systemd. And the speed of booting comes up again and again in the blog post. Then how can it not have been one if his major considerations?
So he's contradicting himself, or he changed his mind in the three years between those blog posts.
> It would also make discussions much clearer if people said in the beginning what exactly they are complaining about, e.g. "logind is buggy" instead of "systemd is evil".
That's what one gets if one puts everything under the same name, throw everything in one tarball.
Not sure about boot speed. At least on my system booting Debian became noticably slower in Debian 8,9 and again in 10. Maybe simply because software got larger or because I didn't do clean installs but upgraded my existing system, I don't know. But the only boot speed improvement I got in the last years was switching to SSD. Thought I do like that with systemd you can at least find out easier which parts slow down the boot process.
> Systemd is at odds with the core design philosophy of UNIX
No. All the enterprise Unix OSs had advanced system management facilities that a mesh of RC scripts well before Linux (the OSS Unix OSs still mostly don't). Whatever the core design philosophy of Unix was or is, mostly people who do work on it as a hobby seem to care.
"MX Linux ships with systemd present but disabled by default. The MX Linux team strongly urges users to remain with this configuration which uses sysvinit instead. This page simply provides information for those interested in the question."
+ 1 for MX Linux. I have it on my Dell 7373 and it works really well. Very stable, and the UI looks great straight out of the box. With TLP pre-installed, the battery life went from 3 hours on Windows to 7-8 hours on MX Linux. And systemd is disabled by default, but is available if needed! Highly recommended.
I think the problem can be restated more clearly thus:
Today, Debian Packaging Policy requires packages to supply an sysvinit-style init script. In order for a software package to be allowed in Debian, a software package which does not have such a script from the upstream developer(s) must be provided such a script by the packager; the Debian Maintainer.
However, the Debian default init system is systemd, and this seems to be a stable situation. No other init system seems to be gaining more than minuscule traction, and 99% of Debian installations keep using systemd. Given this, what is the rationale for requiring, as a strict no-you-can't-be-in-Debian-otherwise requirement, Debian Maintainers to provide and write sysvinit scripts, when only a very small minority is using sysvinit?
One should always remember that all work in Debian, and also frequently upstream development, is provided by volunteers, and very little can be reasonably demanded unless there are very good reasons for doing so.
There are also other ways to more gently push packages to provide sysvinit compatibility. The Packaging Policy could have a SHOULD requirement instead of a MUST (to use the RFC 2119 terminology). There could be a Lintian warning given to packages which does not provide sysvinit scripts matching their systemd service files. I’m sure there are additional ways.
Most software probably already have sysvinit scripts from upstream already. These would not go away. Most of the remaining Debian packages have sysvinit scripts written by the Debian Maintainer, and these would not go away either. The question is what to do with new upstream software which inherently depend on systemd, and the Debian Maintainer does not feel able to write a sysvinit script. Should this software be prohibited from going in Debian?
I think the answer is obviously “no”, when looking at it this way.
But I’m only a Debian Maintainer (and only of my own upstream software), not a full Debian Developer, so what do I know?
> Given this, what is the rationale for requiring, as a strict no-you-can't-be-in-Debian-otherwise requirement, Debian Maintainers to provide and write sysvinit scripts, when only a very small minority is using sysvinit?
Because Debian decided that they want to have the ability to ever support anyting other than systemd. If they lose support for initscripts that are portable across PID 1s then Debian===systemd will be true and it will be extremely hard to ever change it.
One way to work around that is to either demand a sysvinit script or a systemd service file that can be automatically turned into a sysvinit script by a converter. It would not be pretty but it would allow the 1% without putting unnecessary constraint on the maintainer.
First, let me be clear: I have my issues with systemd. The "exmbrace, extend, exterminate" fears from the article are justified to some degree. I don't like Poettering's personality (ok, this is only tangentially related). Why the fsck does it ship an NTP and DHCP client? Both of which had their share of security issues because inexperienced idiots needed to pretend to be rock star programmers reinventing the wheel for no good reason. Oh and I use neither Gnome nor KDE so I couldn't care less if they'd break when switching to another init system.
BUT:
Get your shit together and accept reality. Systemd is here to stay, and as the article mentions, supporting other init systems will become more and more of a chore. Combine this with quotes like
> [...] the project had been unable to fully support systemd alternatives due to a lack of developer interest [...]
> "We have already voted with apt: less than 1% of new installs use sysvinit"
and then the fact that with Devuan WE ALREADY HAVE DEBIAN WITHOUT SYSTEMD. Why the fsck should we waste every Debian developer's/contributor's time with supplying brain damaged init scripts, patches and workarounds for 1% of the Debian user base.
Hey I have an idea; let's cut back on QA and reassign those resources to ensuring Debian works with sysvinit. Does the Debian project have any staff working on security? Scrap that, let's have them work on supporting retarded init systems from the 90s instead!
Exactly what we expected. Systemd has become a hard dependancy, and is continuing to branch out into unrelated systems causing unnecessary changes and bugs due to poor code quality of the maintainers.
I continue to standartize on Debian VM containers for infrastructure, but only because of lack of alternatives.
the fact is that some really good dev make the works but nobody care and nobody wants to give real supports(i mean financial supports) to do the thing in the right way.
Is systemd portable? can you build it with musl? that it works on BSD?
s6 and 66 do.
>systemd was promised as a way of shaving a few seconds off of boots
s6 do the same without socket activation(fallacious arguments to sell systemd)
Give to s6 and 66 dev the same financial potential of systemd and you will get a real init and service manager in the real *nix philosophy with well designed code.
Actually only one distro show s6 + 66 in action but make it very well
"We have already voted with apt: less than 1% of new installs use sysvinit"
Terrible argument. That's what the Debian installer installs. We replace systemd after installation, as part of our configuration management system.
And, once again: the more systems you run, the more you pay attention to security, the less likely you are to run popcon. Popcon results keep showing laptops and desktops because of that built-in sampling error.
Popcon does, I believe, skew toward workstations over servers. But I don't think including servers would change things, in fact it probably show even bigger systemd use. Servers is where managed process solutions like systemd (and upstart, runit, etc.) really shine.
Also, many of us are painfully aware of the ongoing hassles that tend to come with diverging from default core components, and this is especially true with systemd as more projects come to depend on it. We therefore grit our teeth and accept the installer's unwelcome default. We have effectively been coerced.
> Elogind would provide support for systemd's D-Bus-based login mechanism — needed to support small projects like the GNOME desktop — without the need for systemd itself.
What I find so off-putting about the systemd advocacy is the combination of a sort of learned helplessness ("we don't have anything else", "Red Hat forces it") combined with an argument that it is inevitable, anyways.
It reminds me of the Windows NT advocacy back in the late 90s, that "Unix is Dead" and that Microsoft's invincibility made it inevitable, anyways.
Because a bunch of people did not agree with this view, we ended up with something quite different than the roadmap that Microsoft had for us.
I am a systemd detractor and I happily use Void with runit, so I would really never say that we don't have anything else. I don't know what the magical features are of the ever growing giant squid that is systemd that people swear they can't live without, but I haven't encountered them.
I wish someone would just port smf to linux and we could forget this systemd holy-war. Before anyone asks why I don't do it; I don't run enough linux servers to care too much really..
I no longer really hate systemd, but for OSS, keeping options open is always good, in the case of system that is before it is coupled with all distros too deeply, let's make sure there are possibilities to use other init system as well.
for example, in embedded system, we avoid systemd at all costs.
313 comments
[ 3.0 ms ] story [ 288 ms ] thread* http://aaonline.fr/player.php?trial_id=57684
* http://aaonline.fr/player.php?trial_id=57899
* http://aaonline.fr/player.php?trial_id=58428
* http://aaonline.fr/player.php?trial_id=60363
* http://aaonline.fr/player.php?trial_id=69970
* http://aaonline.fr/player.php?trial_id=70639
* http://aaonline.fr/player.php?trial_id=71040
* http://aaonline.fr/player.php?trial_id=71116
* http://aaonline.fr/player.php?trial_id=71715
For those who might feel hesitant to watch some weird re-enactment of a technical discussion, in a game they might not have even played, I can say: I have not played Ace Attorney either, and these are great. In 2014, I wrote¹: “That thing is unbelievably more awesome than I would otherwise have assumed.”, and I still think so.
1. Previous discussion: https://news.ycombinator.com/item?id=7203500
Thanks for mentioning this!
Benefit one was destroyed by Gnome3 (and, for a while, Unity) being the default in the beginner's distros. Benefit two was destroyed by SystemD wrapping its tentacles around more and more things, and making a modern distro an obtuse, ugly system to learn from, or to work with.
Is there any persuasive reason for a college student today to try desktop Linux? Is there a good pitch anymore?
But it is slow. The overlay barely works well on a new mid-range system. A cheap laptop that is as old as Gnome3 has no chance of running Gnome3 in a satisfying way. Even if you ignore the overlay and install dmenu (which a noob isn't going to know about) it is slower than not only other wm's for Linux, but Windows and OSX. It's not a good way to get new people interested in Linux.
Why would having better IDE support make for a better learning environment? It masks what is going on, and complicates it (for the benefit of people doing much more complicated things). But if you're bashing out helloworld.py you've just made it hard to disambiguate what the file is doing, what the runtime, and what the IDE.
Linux/CLI: Learn an obtuse (beginners, remember) command line text editor, save the file, run another text command to run it, remember the error as you go back in. Fight with apt to get things to work, pray there are no dependency conflicts/errors, learn sudo, go find an IRC channel to help with a package not working with some obscure error about "but it depends on .. which is not installed, try (command that won't fix anything)"
First one sounds much easier for a beginner to me. Making programmers learn on linux is like making student drivers start on manual tractor trailers.
They didn't say it wasn't easier, just that they'd learn less. A better platform to learn on doesn't result in you learning less.
This is even true among "professional" developers, they think somethings impossible just because it can't be done inside visual studio because they don't know how all the parts fit together, all they can do is hit F5.
> Linux/CLI: Learn an obtuse (beginners, remember) command line text editor, save the file, run another text command to run it, remember the error as you go back in. Fight with apt to get things to work, pray there are no dependency conflicts/errors, learn sudo, go find an IRC channel to help with a package not working with some obscure error about "but it depends on .. which is not installed, try (command that won't fix anything)"
Aside from the command line text editor you have deal with almost similar issues with VS, different but similar. You can end up in DLL hell from nuget, you can fight with click once deploys, you can find useless "answers" on MSDN, etc.
Can't say VS has ever given me problems outside very complex large projects that are out of scope here while the Linux part is based on experience.
You seriously underestimate the amount of work people have to do to get started in an IDE.
Really though, thinking on it the best environment for a total beginner is probably one of those web-based things like codeacademy.
Let's agree to disagree.
As an example I write papers using latex.
On Windows I have to:
- Figure out that I need miktex.
- Find its website and download the installer and install it.
- Find an "IDE" like TeXniccenter.
- Find its website, download it and install it. - Configure it.
- I have buttons to click, great. I click on them and pray that it works. What if it doesn't? Error messages are buried somewhere and problems are horribly difficult to fix (e.g. utf8 problems or missing perl).
- I need to convert some graphics from one type to the other. Can Windows do that? What do I need to install? Photoshop?
On linux:
- Open the software center/appstore/whatever.
- Search "latex".
- Click on all the stuff I like. Done.
- Everything works out of the box and does not need fiddling.
The second one is much, much easier for a beginner.
On Linux, you just open up a text editor, write some C/Python, then pop open a terminal and directly invoke gcc/python. There's typically nothing that needs to be installed - and if something's missing, it's just an 'apt install' away. As a beginner you can see how everything fits together since there's no IDE in the way. And if you want to dig deeper into how things work, everything is documented in the man pages.
On Windows, you need to go online, find the right downloads, then install various developer utilities just to get to a working build environment. From there everything is typically done from the IDE - which means setting up projects and dealing with more abstraction.
I'm firmly of the belief that IDEs are a great tool, but aren't something that should be introduced until after students have a firm grasp of the underlying fundamentals.
Or get the IT to install the respective C compiler.
Plus just because there is a C compiler, it doesn't mean IT has made it available to common mortals, or allowed exec on $HOME for the clever dudes that try to sneak in one.
Me too. Professionally, I develop for a number of operating systems, including Linux and Windows. I much prefer developing on a Linux system over the others, in part because it's easier to get going (most of what you need is installed with the OS), and in part because it's more flexible.
Don’t get me wrong, IDEs can be great, but they come and go or change significantly over a decade and the knowledge you build with it won’t work once you SSH into a headless server.
Why not both?
There is e.g. Elementary OS (also an Ubuntu derivative) with another lightweight GUI.
I personally run Void Linux (which lives happily without both systemd and sysvinit) with Xfce.
I think not if we look at Ubuntu, Red Hat, etc. But maybe small ones like Alpine Linux?
This brings up a good question: What good free and open source operating system is out there that would be persuasive for a college student or someone who wants to learn an operating system as opposed to merely using it?
1: http://www.linuxfromscratch.org/
If you want lightness, or need the Linux kernel for something, Alpine Linux is a tiny and solid project.
No systemd to be found (not even an option on BSDs; Alpine Linux is OpenRC).
Hilariously, this is premise is entirely wrong.
> ... one umbrella project developing all parts of the OS, often depending on each other.
Systemd is not the OS. Full stop.
Do you mean the project, or the unit system? I'd argue an init system is very much a key part of the operating system, as important as the kernel. You can't really do much without one.
If you mean the project, then you've missed the point.
Certainly seems to want to become it.
> Certainly seems to want to become it.
touché
Then take KDE as example (an umbrella project with many separate, independent projects below it, all of which are separate binaries, but many work better when used together, or depend on another). Or Gnome. Or any other such umbrella project.
> > Hilariously, this is premise is entirely wrong.
Note that you originally asserted:
And I responded with what I feel confident is a statement of fact: > Then take KDE as example (an umbrella project with many separate, independent projects below it, all of which are separate binaries, but many work better when used together, or depend on another). Or Gnome. Or any other such umbrella project.The examples you provide are umbrella projects, no doubt, but none are Operating Systems. Neither is systemd.
While the term "OpenBSD" can be used in the context of a distribution (common), OS (common), and the tools used to initialize same (uncommon), systemd only qualifies for the latter.
Systemd: let's break and change how everything works. You need to relearn everything.
OpenBSD: things work largely the way they've worked for decades. Even as parts of the system are rewritten, the user experience remains very much like it was before, and often the old way of configuring and using things works exactly as before even if the underlying tools have seen a complete rewrite.
> Systemd: let's break and change how everything works. You need to relearn everything.
> OpenBSD: things work largely the way they've worked for decades. Even as parts of the system are rewritten, the user experience remains very much like it was before, and often the old way of configuring and using things works exactly as before even if the underlying tools have seen a complete rewrite.
You're arguing a different point. *BSD's focus on 'experience stability' is completely tangential to the fact that it's a curated series of different utilities, tools and programs designed to work together. Much like systemd.
I tried netbsd a couple times but I’ve never gotten it to compile.
What is this college student studying?
If it's something technical then yes, 100%, you need exposure to multiple different systems, and sticking to your MS enclave is going to seriously limit your abilities.
Despite SystemD Linux is better than ever as a coding OS and as a desktop OS. It works great on a huge range of hardware and it provides frictionless access to tools to code in more languages than you can shake a stick at.
If Gnome is too heavy or restrictive for you (and I haven't gone near it since 3 launched) then try a different DE like Xfce. There's a selling point right there - switch DEs at the drop of a hat.
That statement seems inconsistent with itself. It's the default, you can change it.
RTFM
> Defaults to "auto".You just need to have /var/log/journal. This is your distribution/installer failing you, don't blame systemd.
>On Ubuntu 16.04, /var/log/journal does not exist by default. Create it to keep and query events from previous boots.
The problem I have with the 'hidden magic' argument is that everything that provides some sort of abstraction is hidden magic, until you take the time to learn about it. For more examples of 'hidden magic', look no further than GCC, the kernel, etc.
So then this boils down to "I don't like new things", which is perfectly reasonable. But make that your argument. Sometimes there's a good reason to change stuff, because the old stuff doesn't work very well.
edit as mentioned elsewhere, logs are persisted in /var/log/journal by default. If your distro doesn't create that on install, then that's where your issue is.
I've happily been using grep, strace, etc to debug issues in both systemd and 'traditional Unix' systems for years.
The Debian developers voted by setting the apt default.
So no.
I already voted by removing systemd and moving to sysvinit during the period where debian-installer did not give me an option.
systemd is a constant security hazard, fails standard unix philosophy by doing one thing and one thing well, and is nigh impossible to audit.
systemd is a mistake, adopting it was a mistake, and it gives me nothing that either I don't need or want (not cloud/large orchestration stuff; standalone machines), or DO need or want but actual orchestration stuff gives me while also giving me tiny init systems (in some cases, yes, neutered systemd to limit the security implications and shear number of bugs) to bring my stripped down micro-instances up.
So, the Debian community voted, and for similar reasons as I voted. We don't want systemd, we never wanted systemd, and we will burn the distro down to get what we want. Redhat tried to use systemd to Microsoft-style Embrace, Extend, Extinguish their way into the entire Linux community, and we want nothing of it.
Systemd has been relentlessly pursued by Red Hat. It's won over some technical advocates, but created numerous enemies and critics. Ted T'so is quoted in the LWN piece. Linus himself has been diplomatic but pretty critical, at least in past (I've not seen any specific comments in the past 2-4 years AFAIR).
When it first appeared on the scene, systemd was promised as a way of shaving a few seconds off of boots. That's not something I was ever particularly interested in (my systems reboot infrequently, I'm more concerned that they come up clean, reliably, and deterministically, than fast). Meantime, systemd is now taking over my logs, network, device tree, time service, cron, and more.
The walk's not matching the talk. The complexity and insecurities remain. And yes, trying to maintain backwards (to sysvinit) or sidewards (to upstart, if that's even still alive, openrc, runit, eudev, procd, nosh, finit, ...) is difficult. It also concedes the initiative (init-iative?) to systemd.
Standards wars against well-heeled forces are exceedingly difficult. Even when technology and history are on your side.
And now for my talk on the year of Linux on the desktop....
This is a misrepresentation. It does have components for all of those things, but AFAIK only journald and udev (I think) are non-optional. You're free to use cron, chrony (NTP), NetworkManager (or whatever), etc.
Source:
the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.
http://0pointer.de/blog/projects/systemd.html
And in case that's been modified, the earliest archived version:
https://web.archive.org/web/20100503054610/0pointer.de/blog/...
Discussed on HN at the time:
https://news.ycombinator.com/item?id=1308367
And on LWN:
https://lwn.net/Articles/385536/
Also on LWN, "Systemd as Tragedy", from January 2019:
https://lwn.net/Articles/777595/
Also discussed on HN:
https://news.ycombinator.com/item?id=19023232
The usual exceptions to the rule have generally been complexity hubs -- places where a bunch of pieces come together and need to be managed. The shell, editors, email (crossing networking, domain services, local and remote message processing, security, privacy, spam and filtering), compilers, databases, graphics editors, are all examples.
But where small and simple tools can be used they prove an excellent idea.
systemd took a set of small, simple, and fairly independent concepts and bound them up in both complexity and tight dependencies. The fact that even identifying, splitting out, and replicating functionality outside the system is a problem is a symptom of this fact.
I think that outlines the problem well, systemd might be a good init system but it's not just an init system and it's an all or nothing thing. There is no meritocracy of components which has always been a strength of linux.
edit: as of a couple of years ago when I last had the time to care. I suppose it's possible something has changed, but I doubt it.
The whole point is that systemd replaces a large number of solutions to various system components and there’s alot to be said for pulling all that together into a consistent solution.
The competition to systemd can’t match its power, but there are good solutions for more limited scope situations like embedded.
Systemd is incredibly powerful and is very much a welcome part of software that I build. My system architectures depend heavily on systemd.
knowing what systemd is capable of is really required knowledge for software developers because it can both save you massive time and also enable the creation of systems that otherwise would have required you to write more code.
It's much more than an init system; it obviates a number of other components. This may be a desired quality for some. "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
The fact that systemd did not have the highest reliability for years did not help its popularity. It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.
Funnily Unix and C are also examples of "worse is better".
https://www.jwz.org/doc/worse-is-better.html
(Mildly NSFW)
https://wiki.mozilla.org/Security/Referrer
This is an entirely unrelated question to modularity - the "problem" is that systemd supports certain features and if you want to run without systemd, some other component needs to support them. Such components could be designed pretty easily, sure, but people who are using those features are typically happy with systemd's implementation so there's little motivation to write them.
In the article, systemd's tmpfilesd mechanism is given as an example. It's straightforward to reimplement as a standalone component, but someone has to actually be interested in writing the implementation and writing tests that it behaves like systemd does and keeping it up to date.
What we have here is a dependency chain that pulls in all of systemd, therefor it isn't modular.
It isn't modular just because it's divided into modules.
Come on, that's literally what it means. Just because your modules aren't compatible doesn't mean it isn't modular.
You wouldn't say that a company lacks a microservice architecture simply because they don't have unused reimplementations of each microservice lying around, would you?
Modularity implies formalization and restrictions about how components communicate and depend.
One of the goals: the ability to replace the implementation of one component without having to modify/adapt the others (the top-level component (also called 'main' or 'composition root') used to instantiate all the others doesn't count).
If your components can be compiled separately (e.g without having to recompile the whole app), then you know you're modular (however, modularity doesn't necessarily involve dynamic linking).
Real world examples of modularity:
- device drivers of the Linux kernel
- SDL device backends
- decoders/demuxers in VLC
- Cubase VST effects
- Filters in DirectShow and Gstreamer
Real world non-examples:
- LLVM backends: in practice front-end implementations need to know about the various backends, so you can't simply add one.
- GCC frontends: almost modular, however, there's some bunch of places you still need to modify so they know about your new frontend.
- GCC plugins: although no line of code in GCC know about your plugin, your plugin can depend upon almost anything from the GCC implementation itself, in other words, the plugin API is too big (=the density of interconnections is too high).
- Descent 1&2 (the game) enemies: the list of enemies appears at several places in the codebase, so you can't simply add one (=the density of interconnections is too high).
I'm not sure why you picked such a specific example, but it looks like read_robot_info() will happily read in additional robots from descent2.ham if you increase MAX_ROBOT_TYPES and stick them in the same global. There might be specific behavior info sprinkled elsewhere in the game, but that is probably code you'd need to touch to implement the uniqueness of new enemies anyway.
It's monolythic in the same what that the GNU project or FreeBSD is monolithic.
It's a large number of utilities, tools, and daemons that is designed to provide the low-level features application developers and users demand from a modern operating system.
> It's much more than an init system;
Systemd is a init system, but systemd is also a major project that has taken on the task of unifying low-level Linux OS features.
> "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture.
All these systems have their own init systems they designed with no regard towards Linux and replaced older systems and obsoleted them.
> It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
Lies and misrepresentations.
> OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.
Which is why people are working on replacing both X and SysV.
You want to know the real problem with anything-but-systemd crowd?
This:
> Of course, this approach is not viable if it turns out that too few people are interested in init system diversity sufficiently to do the reasonably substantial implementation work required to maintain a competing implementation of the systemd unit features we care about.
There is no 'If' there. Some people don't want systemd, but the only people doing the work are Systemd. So their choice is to stick with Linux from 2000's or use systemd. Because nobody wants to commit to making any alternative actually work.
Making noise online is annoying, but it ultimately is not something that goes into the decision making of people designing operating systems. People willing to do the work are the ones that get to make the choices.
If somebody comes along and makes a better init system then systemd then they can do it and if it is better it will get adopted.
You can pretend that this is all Redhat's fault, but they are the only real enterprise that made the transition from sysv in Rhel 5, to upstart in 6, and then to systemd in 7.
And, ironically with systemd, migrating to another different init system is massively simplified compared to the work it took to migrate from sysv init. So now moving to a new init system is easier then ever.
Why do I say this?
Because systemd has unified OS design for Linux in a way that never happened with sysv init. Sure people were using 'sysv' and all used shell scripts, but they were all fundamentally different from one another. Only the most complicated shell scripts imaginable (think Apache init) or the most trivial could be made to work on more then one Linux distribution. Meanwhile systemd uses a declarative configuration syntax that all you need to do is create a parser and you could effectively import any systemd application configuration into a system with equivalent or better capabilities in any operating system.
The same can't be said for any of the bash scripts developed by any of the distributions prior to this for their own sysv variant.
> It's monolythic [sic] in the same what that the GNU project or FreeBSD is monolithic.
The FreeBSD system initialization artifacts are not monolithic.
> > "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
> FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture.
This is straw man incarnate.
> > It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
> Lies and misrepresentations.
Not according to here[0].
If you want to be a "systemd warrior", fine, feel free to be so. But don't lump FreeBSD and other Unix systems into your crusade.
BTW, when you wrote:
> Because systemd has unified OS design for Linux ...
Know that an init system, any init system, does not design nor define an Operating System.
And while your disdain for shell scripts is readily apparent, what you proffer as the benefit of "... systemd uses a declarative configuration syntax that all you need to do is create a parser ..." ignores the fact that POSIX shell scripts provide this feature by definition. Including, but not limited to, being able to source other files which define requisite variables.
0 - https://www.quora.com/Why-does-GNOME-3-require-systemd
And nobody claimed that... . The claim was that FreeBSD is monolithic in the same way that the systemd project (logind, nspawn etc. ) is monolithic.
> Not according to here[0].
Okay, let's click on that. First sentence "It doesn't". What were you trying to argue again?
> Know that an init system, any init system, does not design nor define an Operating System.
Are you purposely confusing systemd-init and systemd the project? Because your argument is the same as "GNU does not design or define an OS", which many people would call plain wrong.
> Okay, let's click on that. First sentence "It doesn't". What were you trying to argue again?
And the second sentence says:
Since GNOME requires either systemd-logind or something that behaves exactly as systemd-logind, how does that not express a transitive dependency on systemd?So what are you trying to argue again?
> > Know that an init system, any init system, does not design nor define an Operating System.
> Are you purposely confusing systemd-init and systemd the project?
No, what I stated I thought was quite clear: an init system does not design nor define an Operating System.
This is orthogonal to the question you present.
0 - https://www.quora.com/Why-does-GNOME-3-require-systemd
IMHO, that's not the best way to say what I think you really meant.
There are alternatives for just about every single systemd function (e.g. there are other init system that are not sysvinit). It is true though, that the people implementing these alternatives are far more levelheaded regarding systemd than the haters - at least in my experience.
I dare say there's bit of an irony in that assertion. 4 different operating systems, each of one of which uses a different init system. Pardon me, but that looks like the exact opposite of a monoculture.
Also, the rc system in FreeBSD could probably be ported with not too much effort into other operating systems, as it uses pure sh (not even bash). Surely, that cannot be considered monoculture. I would dare say that porting systemd into FreeBSD (or any of the other OSes you mentioned) should be more difficult.
http://0pointer.de/blog/projects/systemd.html
What I understand from this topic(about the ilogind) is that you can't even create such an alternative because the packages are depending hard on systemd. So you will be forced in future to re-create systemd features and bugs similar how wine does it for Windows API.
——
[0]: https://en.m.wikipedia.org/wiki/Launchd
Basically every type of systemd configuration files are just INI files, which I seem to remember originating in MS-DOS...
[1]: https://wiki.freebsd.org/launchd
[0]: https://en.wikipedia.org/wiki/Launchd
The basic idea of an init system is pretty simple: start services in such a way that the system comes up reliably. There are two main approaches here, simple but inefficient or complex and more efficient. The FreeBSD/rsysv approach is the former, while the systemd/launchd approach is the latter. If I just want to make sure services start on boot in the right order, why not just have a script run it all? For 99% of use cases, it's good enough, so why complicate matters?
I do appreciate systemd and the faster boots I get from it, but I still find myself longing for similar init systems.
For a replacement for cron...sure, that's nice too. The benefit of being able to manually activate a timer in order to test it is completely worth it.
For an NTP implementation? Eh. I'm not sure why that needs to be bundled in under the same umbrella as the service manager. It's also just an SNTP implementation, not full NTP, so it's notably feature-crippled relative to better options like chrony.
Network management? Meh. Again, that strikes me as something that should be loosely coupled to the service manager.
A UEFI implementation? gummiboot was assimilated and become systemd-boot. Was that necessary for technical reasons, or was it just moving a project under the systemd umbrella similar to how there's an umbrella of GNU projects?
Container management? Another place where systemd-nspawn doesn't strike me as notably better than the alternatives.
At a certain point "systemd" becomes a brand more than anything else, sort of like what IBM has been trying to do with Watson. Yes, it beat Ken Jennings at Jeopardy and that's great. That doesn't mean anything associated with the overall brand is automatically equally amazing.
I agree systemd tries to do a lot (maybe too much) and often isn't better than alternatives, but I don't think that's a big deal since you can still use the alternatives quite easily.
You can use rsyslog in addition to journald, but there's no way to get journald out of the picture - it's intertwined with the service manager.
I had an automation recipe that would start a bunch of cloud instances, configure them and start certain job via a systemd service unit, and collect logs from this job 24 hours later. Initially, we were pulling these logs via journald as logs for that service unit. But then we noticed that random lines (1-5 lines out of maybe 40 for a single job) would be missing in about half the instances.
We ended up pulling those logs from files in /var/log instead, made courtesy of rsyslog. Not a single missed line.
Again journald is unreliable and as a whole should be nuked from the orbit.
The lines would go missing mostly if the logs were collected two or three days later instead of immediately after the job finished (it was a job running for 24 hours), which leads me to think it had to do with journald expiring entries to save on disk space. A consistent log manager would expire them chronologically, but here the lines were missing from the middle or the end of the output, so not the oldest ones logged.
It's not that the logs are missing, it's that they're not getting included by your query.
The way journald associates log lines with process metadata is inherently racy.
This situation has improved some with the metadata caching changes, but IIRC there are still some holes where processes can log without journald associating accurate/up-to-date metadata with the logged info.
https://github.com/systemd/systemd/issues/2913
The most common one (and one I share) is how slow it can be. `systemctl status foo.service` takes a significant amount of time on any of my machines thanks to the journal, and that's just the reader side.
It used to be quite crashy with lots of CPU overhead, but that has improved over time, the metadata caching helped a bunch with the overhead.
There was also a pretty embarrassing CVE not long ago:
https://nvd.nist.gov/vuln/detail/CVE-2018-16865
Many people when they encounter problems with journald want to continue using systemd for their service management, but revert to the old world of low-overhead metadata-free unstructured syslog O_APPEND text files for everything logged.
If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s.
It's not an impossibility, the systemd developers just seem to have zero interest in implementing stuff that enables escaping their overall architecture. I imagine all that's needed is some minimal IPC glue to forward all the stdout/stderr output from services to syslog when journald isn't in use. Systemd's role is to wire that stuff up to journald currently, and it's unnecessarily opinionated about journald being the only supported target in that role.
Journald and udevd are exactly the only piece of systemd that systemd's pid 1 requires, and udevd can be used independent of systemd's pid 1.
I just think of journald as a piece of the init system that is split to a separate process, and provides log data to other programs.
Secondly, I don't, I expect the recent logs portion of `systemctl status $unit` to be suppressed when journald isn't present.
Note that journal-caused slowness of that very command is a common complaint aimed at journald contributing to people wanting to remove it!
E.g. `service_directory/service/logs`
Seems like a trivial way to solve it...
I was an Arch Linux user before, during, and after the systemd transition. I welcomed it initially, because pre-systemd Arch had a lot of "here's how to decide which logging daemon / cron daemon / etc to use" which I always thought was unnecessary. As I said, I think it's a great service manager.
But I've also had to deal with production servers using systemd-timesyncd and pool.ntp.org that would occasionally have system clocks that were off by ~10 minutes. SNTP was deemed "good enough"; SNTP doesn't handle falsetickers well; and under dynamic Docker workloads systemd-timesyncd would decide "network configuration changed, better synchronize the clock" every time a Docker container started or restarted.
If I use systemd as a service manager, why does that also imply I'm making "default" choices for boot loader, (S)NTP service, network manager, and container manager? Each of those has no reason to have any sort of coupling to my service manager.
My biggest quibble with stories like this one is that they keep focusing on the decision of systemd as service manager / init system rather than the umbrella of other jobs that the service manager has no good reason to try to take over.
You absolutely can have it both way. Systemd is great because it offers a set of tools which are consistent, provide a lot of the functionality you want on a workstation in a cohesive way. It doesn't prevent you from choosing not to use one of the components developed under the project umbrella and uses something different instead. Systemd is modular enough for you to do that.
> But I've also had to deal with production servers using systemd-timesyncd and pool.ntp.org that would occasionally have system clocks that were off by ~10 minutes. SNTP was deemed "good enough"
Why are you using timesyncd if you need more than SNTP ? Timesyncd is not shipped by default with the systemd init system. It is not even installed by default on RHEL. Nothing prevents you from using a different NTP client with the systemd init system.
> If I use systemd as a service manager, why does that also imply I'm making "default" choices for boot loader, (S)NTP service, network manager, and container manager?
It does not imply that at all. You absolutely do not have to use the boot loader, timesyncd, networkd and nspawn with systemd. They are not even installed by default on some distributions. They are not coupled to the service manager.
Apart from networking. That’s an f*ing mess without systemd.
I have a wireguard tunnel setup by networkd with custom rules to only send traffic from a slice through it. It works fine. Take a look at the netdev documentation [1].
What are you trying to do exactly ?
[1] https://www.freedesktop.org/software/systemd/man/systemd.net...
You don't know how the network will be parsed or which statements that works with your version. Very difficult to debug when it doesn't behave as it should.
After a lot of fiddling with source routing on e.g. Debian Strech I was able to something working. But only half of the times I restarted networkd.
I would like some better tooling to assist with more difficult setups.
But, yes, turning on debug mode is harder than it should be, and it's usually not the right level. (I usually just go for strace first, but with netdev I guess it's using netlink to talk to the kernel, so that'll not help much :/ )
I use strace etc (and debug level in networkd), but then you realise that this should make it easier not tougher. I did learn about ifup -v though which gave me all I needed. But both tools silently ignores flags that is wrong.
I'm writing my own tool now that is more strict in that sense instead.
Sorry about the rant but it's at least three trips to get everything working flawless in systemd-networkd now..
Of course it's free and open source, so we can at least try to make it better besides complaining, but that part is harder than it should be (otherwise the whole problem would have been "solved" by now).
Systemd-networkd is fine layout wise, it's just the tooling that could be improved upon. Also here you see the problem with systemd-networkd being shipped together with systemd deb, if it were to be standalone it would be so easy to backport just that.
Coreos even made a complete systemctl dbus integration.
With anything dynamic though - laptops, VMs - the various solutions can be pretty hit and miss. NetworkManager was terrible for many years, but seems relatively ok these days.
Realistically, one tends to take or leave an upstream package since picking and choosing pieces of it is far more work than a typical package maintainer takes on. Also, upstream design decision changes can make doing so problematic down the road.
Not necessarily. RHEL does not ship gummiboot, timesyncd or networkd for example; it uses grub, chrony, NetworkManager. On my raspberry pis running Debian I have systemd as pid 1, one runs ConnMan (it connects to wireless) and the other runs networkd (it connects to Ethernet).
It's a nice design rule for CLI utilities, it doesn't work for systems.
Similarly, curl supporting both HTTP and HTTPS is not a violation of "do one thing and do it well" - if you fail to support at least those two protocols, you've built a shitty tool.
It's best to consider "do one thing" in the context of "what does the user want the software to do". A web browser having lots of functionality baked in is not necessarily a violation of this principle if all of that functionality is used to solve one user problem (I want to view YouTube, or I want to use GMail). At that point, the factoring issue lies somewhere else - the definition of the web platform, etc.
Systemd attempts to solve very many user problems all at once, with varying levels of success, and other software packages have solved one or two of them at once instead. In that case there is a clear way to separate the ones that probably apply the "unix philosophy" and the ones that obviously do not.
The Linux kernel and related components themselves sort of violate this, but that's mostly a matter of necessity - super-modular microkernel designs have not worked out great in practice. However, it still is built around relatively narrowly-scoped drivers for individual devices or services, instead of massive Megadrivers that handle every component in your system. Your PC may have an Intel GPU integrated on the CPU die, but it's still using a separate video driver, and the video driver is probably separate from things like the compositor and the actual PnP layer beneath that detects what hardware you have.
If you look at the average USB device in Windows' device manager (this is probably true in Linux as well but I don't know how to dump the data), you can see a given device like a mouse or a phone is actually split up into a bunch of sub-capabilities exposed by the device, and those can each have their own driver. Same thought process there.
No need to use networkd for example, networkmanager works great along systemd.
Actually most my systems use only systemd and journalctl to my knowledge. I prefer my established tools for all other jobs.
I think systemd actually won when they absorbed udev.
Can you? The whole premise of systemd revolves around ability to use existing init files, written by upstream developers.
Upstream init files are going to use arbitrary parts of systemd functionality, which may include network and container management, timers and God knows what else.
So in effect you HAVE to use those parts of systemd — unless you are insisting on writing all your init files from scratch (at which point you may as well use any of systemd alternatives).
And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I?
And all my services run just fine.
It leaks into user land.
The alternative for systemd would've been to shutdown the system without waiting for a clean unmount, which can lose data, which is what used to happen with SysV. The alternative for you would be to unmount your filesystem yourself before shutdown, which is what people used to do with SysV. Some SysV distros even had scripts that tried to automatically clean up mounts before shutdown, which is exactly what systemd does now, and your 90-second hangs would've shown up there too.
> It leaks into user land.
Init has always been in user land.
There are many premises for which systemd was designed, but this is not one of them, let alone "the whole premise".
1. Before systemd, upstream developers were never precluded from supplying their own init files, and many often did.
2. Even in systemd, downstream maintainers and users were never precluded from modifying, overriding, or even completely replacing upstream-supplied init files.
The difference is that with SysV upstream-provided init files were often bad because upstream developers had to use a bunch of hacks in shell scripts to (necessarily reinvent and) supply features that were essential but SysV couldn't provide. The distro maintainers and users were thus sometimes _forced_ to try and fix upstream-supplied init files, but even they could do only so much because ... shell scripts on SysV.
Systemd allows everyone (upstream and downstream) to write better, cleaner, more maintainable init files.
> which may include network and container management, timers and God knows what else.
1. Timers are a core requirement of service management, and they're correctly a part of the service manager that is systemd.
2. network management (systemd-networkd, systemd-resolved, and .link, .network units) and container management (/var/lib/machines, machinectl etc) are _not_ service management features and are _not_ implemented in pid-1 systemd. I have also not seen any upstream package that used them. In fact, these features _cannot_ be used from service unit files.
> ... unless you are insisting on writing all your init files ...
It's not an all-or-nothing affair. It never was, not with systemd not with SysV.
> ... at which point you may as well use any of systemd alternatives
Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false.
Not to mention, systemd is much better than the alternatives in terms of allowing the sysadmin to override parts of the config for a service without needing to merge in updates from upstream later on. I can just add an override for e.g. PrivateTmp=yes and if there's some update to the original unit file later on, it'll apply that update but it won't mess with my override that I set up.
With SysV I'm stuck with updates being a pain that I'd need to manually merge every time there's some change if I didn't want it to just nuke my changes.
For example many of the larger DEs use logind because it is good at what it does and consolekit at that time was not really active anymore. That meant that for example freebsd had to either make the DEs work with consolekit (and maintain it) or make a logind implementation work with their implementation.
This is one of the confusing things about the discussion. The systemd project very much follows the "unix way" in that there are lots of subprojects that do one thing well, but is developed in a cathedral style (just like the *BSDs are) and not easily reusable, which kinda loses the benefit.
More that ConsoleKit developers and logind/systemd overlapped. For GNOME, logind seemed better and used to be separate. A warning that it would not always stay decoupled was underestimated/ignored.
Once logind was tied to systemd all hell broke loose :-P
Having something like systemd is great; e.g. GNOME has various user services running. Nowadays systemd manages those user services. But as great as that is, it makes non-Linux more difficult. IMO systemd on Linux makes things very easy and it's better to standardize on it.
Because it was originally advertized as an optional init replacement. The acrimonious debates were because a number of people did not believe that's all is going to be, given the history of its designers.
Of course, nowadays many people would flat-out deny that systemd was sold as an init replacement, and claim that what you see was the original intention all along.
Everybody does that. Are you using networkd? Every distro makes different choices and user can then further configure what they want to use.
You can already configure systemd as you like, there is no need to 'take it apart'.
1: https://nvd.nist.gov/vuln/detail/CVE-2018-15688
2: https://lwn.net/Articles/674940/
If you want to count like this you might as well speak of vulnerabilities in GNU.
From the second link you posted:
> None of that completely ended the systemd squawking, but it was clear to most that the real problem lies in the UEFI implementation.
So I am not sure what you hoped to prove here.
Could it have been done any differently? Perhaps. Would it require more moving parts? Definitely.
systemd now is something like all except kernel, DE and applications. It's not clear.
So you're advocating making systemd even bigger and dependent on more stuff?
Bingo, so what's the problem? Except for the timer/cron functionality, everything else you listed is separate software that just comes from the systemd brand.
Systemd-nspawn contains no new code; just calls existing systemd library code. It gives people a familiar image based interface for a small cost in terms of lines of code.
Bootloader i have a less strong argument for but at least it allows them to iterate in hopefully-standards-soon.
Also systemd-boot is not an UEFI implementation. I'm not sure where you read that. It's an extremely small UEFI executable that lists a list of boot entries. (Note that an UEFI executable is just a Windows .EXE file).
UEFI itself has more lines of code than the Linux kernel, replacing it would be insane (though very noble. See coreboot and Linuxboot projects).
One argument is that it allows them to iterate on standards like the following:
https://systemd.io/BOOT_LOADER_INTERFACE.html
And https://systemd.io/BOOT_LOADER_SPECIFICATION.html
And https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT.html
On Debian, systemd similarily basically only takes care of service and timer management (and cron is still available on all systems). I guess it does NTP too, I don't really spend much time thinking about my NTP client.
Yes, systemd is a brand. But just like you don't have to eat every burger at McDonald's, you can choose what works for you.
The only part of systemd other than core init that you have to run is the journal and even then you can configure the journal to just forward to rsyslog and not store any logs even just in tmpfs.
Stuff like systemd-nspawn wasn't even developed to be a container management solution. IIRC the main goal was just to leverage the existing namespacing features in core systemd to allow booting up a minimalistic container in order to make developing systemd easier.
That's one thing where it's way better.
Earlier it was just one (config) file and one start/stop script.
For WiFi, you still need WPA supplicant or similar, but you'll have those two things playing together.
As for init system, I would argue nosh[1] is a better init system. It’s based on daemontools design (same as s6, runit, etc, where it’s just a process that monitors a service directory). nosh can even semi-automatically convert systemd unit files[2] to a run script (including socket activation and all).
For everything else that is not part of the system initialization process (initialize/running/shutdown) I don’t think they need to be tie into PID 1. elogind aims to do this job of taking the logind part out of systemd into its own service, which I found to be a good way of living in systemd world without using systemd (e.g. GNOME works) but it requires a lot of commitment of patching everything to link against elogind instead of systemd (Void Linux/Artix Linux are doing a good job at this).
[1]: https://jdebp.eu/Softwares/nosh/
[2]: https://jdebp.eu/Softwares/nosh/worked-example.html
I'm using runit on void for years now. It has no functionality besides being a service manager. Having more functionality is a non feature.
> because it can both save you massive time
It also can cost you massive time whenever it doesn't work. Then you have to dig yourself through an opaque mess caused by literally millions of lines of C code. I wouldn't trust it with any mission critical. The only usecase for systemd I can think of is grandmas laptop. Maybe that is the target audience for debian, who knows. It is certainly not me.
My issues with systemd do not pertain to functionality and consistency: rather, they are issues of taste, style, competence, design and size.
The basic ideas behind systemd are, frankly, great. The free desktop really really needs something like it. 100% behind the idea and the functionality.
The consistency is pretty good too, I think. It would be taste if it were less consistently in bad taste and more consistently in good taste.
Which brings us to taste. First, systemd is security-important system software written in C. Why? There is no good reason to write software in C in 2019. Use a safer language like Go or Common Lisp (both of which are performant enough). I don't know if Java or other JVM languages would work. Perl probably would, although ensuring that a Perl project produces sane code is … difficult.
Also on the issue of taste: systemd incorporates Windows-style .INI files wholesale into Unix-like systems. The freedesktop.org folks were already doing this, but why encourage it? The world has at least two better text-based alternatives to .INI files: S-expressions and YAML. Even JSON would be better, even without comments.
Also on the issue of taste: systemd just doesn't feel like Unix. In order to get anything done one has to hand-edit lots of little files rather than run a few commands. It's a bit like if you had to run a text editor on a directory to add a file, rather than just creating the file. I'd love to see some commands like mktimer, mkservice or somesuch.
I am mostly over the binary logfile issue — after all, ultimately everything on a computer is stored in binary — but I do wish that the tools were a little saner. It's still a pain to figure out where error outputs and so forth are going.
The manner in which systemd takes over the world is completely inexcusable. I fully expect to see systemd-browser within the next decade, no doubt with just a few hooks to prevent using Firefox or Chromium, and of course with a few security issues just to spice things up.
I really wish that someone with good taste had managed to get the attention of and money from Red Hat in order to design a clean, intelligent, 21st-century init system.
This misses the point about init diversity. Let me show you one that has _less_ fuctionality, and is thus more suited to LXC os containers.
Also, in the article:
> Others, including Triplett, said that not only do the developers of other init systems lack the desire to implement systemd features, but they argue that those features should not exist in the first place.
Something with all the functionality of systemd is just another systemd, which some people don't want in any shape or form.
There are 3 ways to deal with this:
> Assume things are static or hack the support. Sysvint and openrc does this. It tends to hacky as you are create a static setting in a dynamic environmet. This is analogous to using synchronous api to deal with async operations.
> Create a monolithic suite of daemons which handle the state as internal api. Example is systemd and launchd. It tend to be feature creep as you can't replace internal component so you need to deal every use case.
> Have state daemon with each class of state and event is handle independently but a protocol to make sure state is share properly. No init I know of does this.
A great example is if you want do some recuring action on an external network drive. The service manager must know the program the has been run. the Timer program must know if the drive has been mounted. The mount manager must know the network is on or off. The network manager must know if the device interface is on or off. So there is complex dep trail which is very dynamic. the 3rd option is best but 2nd is a compromise and thats what systemd does.
EDIT: Fixed the formating
On the other hand... man, it's sad to see the state of things, where IBM/Red Hat employees basically run the entire Linux userland, and stuff Red Hat doesn't use gradually bit rots away. We saw it with Gtk3's poor support for non-GNOME apps, we're seeing it with various systemd components being required for GNOME (which incidentally breaks non-Linux OS's but who cares about those?), we're going to see it when Wayland replaces X and breaks every old app that hasn't stuck with the upgrade treadmill. As a Debian user since the early 2000s, it saddens me to think of all that we're going to lose because "Linux is not about choice."
This seems like a very dishonest exaggeration.
> systemd components being required for GNOME (which incidentally breaks non-Linux OS's but who cares about those?)
Is it not true that it's completely up to GNOME to choose what platforms and operating systems they wish to target? Is it also not true that GNOME, being open source, can at any time be forked (like MATE) and developed separately by those who disagree with where the project is going? This is an age-old saga in the world of open source, and I don't see the issue.
> we're going to see it when Wayland replaces X and breaks every old app that hasn't stuck with the upgrade treadmill
What do you suggest should happen instead? Wayland shouldn't happen? Unless replacing and breaking happens, nothing happens. We can't just ship X as the default forever and hope that Wayland won't slowly die while people voluntarily tweak their installations and move over.
> As a Debian user since the early 2000s, it saddens me to think of all that we're going to lose because "Linux is not about choice."
In what way is Linux not about choice? It's such an incredible hyperbole, and it couldn't be further from the truth.
In some ways, the infected discussions around open source mirror those of free speech. People conflate "censorship" with "being ignored", just like people conflate "nobody wants to maintain your pet project" with "Linux freedom of choice is dying".
The answer has always been the same in all FOSS discussions: If you want something else to happen, put in work hours, or donate money towards realizing your vision. If you're not willing to do either of those, your individual opinions on where Project X is going are very likely just noise.
> This seems like a very dishonest exaggeration.
Definitely a dishonest exaggeration. Google runs Linux userland. Have been for entire last decade. Unless by "userland" you means something other than "system, used by most of users".
I'm pretty sure they meant "runs" in the sense of "runs the show" (make the majority of the decisions in Linux userland projects) not in the sense of "uses".
I was not meaning that in some twisted way. Most computers on modern Internet are smartphones — desktop use is slowly declining. And Google runs the show on the dominant smartphone platform. Red Hat's desktop is completely irrelevant in comparison.
(As for your point, Google -- even on Android -- still uses plenty of software which is majority-developed by Red Hat and other Linux distribution companies. The kernel alone is an obvious example, but there are many others.)
This. All this whining is mostly done by those that don't contribute anything at all but leech off others work.
It's not true when they're unwilling to commit to stable interfaces (and indeed sometimes make changes that appear to break compatibility with forks for the sake of it). The reason GNU/Linux is based on Unix isn't that Unix was the best OS design, it's that Unix's loose coupling philosophy was the only thing that made rewriting it as open-source possible at all. If the only way to fork any one Linux program is to fork all of them (and that's the path we're going down) then you don't have freedom 3 in practice, even if the program is notionally under an open-source license.
> What do you suggest should happen instead? Wayland shouldn't happen?
If the cost of Wayland is removing the ability to be cross-platform then yes, it shouldn't happen. Microsoft manages to make their proprietary programs run on FreeBSD. NVidia manages to make their proprietary drivers run on FreeBSD. If a flagship open-source project can't manage to run cross-platform that's pathetic.
Word, but that's the symptom. The cause is a severe lack of developer time. If no one develops the Linux userland unless they're paid for it by companies like Red Hat, then of course the entire userland will eventually come from those companies.
For the same reason, Debian currently can't afford to burden its maintainers with supporting alternative init systems, which means they still have to write legacy init scripts and reap none of the benefits of systemd.
Thanks to all great Debian developers!
systemd at it's core is very much adhering to UNIX principles.
Speaking only for myself and every Unix developer and system administrator I have ever met:
No, systemd in no way, shape, or form adheres to well known Unix prinicples.
Perl, the do-all tool, was the final nail in the Unix philosophy, way back in the 80's.
Principles != dogma.
> The Unix philosophy died when ls learned to sort its output and find learned to execute commands.
As for "find", I leave the explanation of it to this[0] recounting. Suffice to say that one command doth not a philosophy make.
Regarding "ls learned to sort", let's put this trope to rest, shall we?
The 'ls' command, as I am sure you and all whom read this posting are aware, is described[1] as:
Now there are many command options which have been added to 'ls' over the decades, no doubt. But you partially identified the death of "The Unix philosophy" as being "when ls learned to sort," so let's focus on that.The implication of that assessment, in this context, I assume to be a reference to "do one thing and do it well."[2]
Which begs the question; what is the one thing which 'ls' must do? Given the summary description quoted above, that "one thing" is:
This leaves the remaining conjunctive clause of "do it well."Since the operation of 'ls' includes both filtering and production due to the functional requirement of having to "list directory contents", there exists two disjoint concerns which must be addressed in order to satisfy the goal of "do it well." For example, an invocation can involve identifying C source files ("*.[ch]"), yet want the production of the files which match based on when each file was last modified ("-c").
To achieve sorting on the modification time using another program, such as sort[3], would require 'ls' produce both the desired output as well as out-of-band information needed to sort[3]. This also implies that the desired sorting (such as numeric or lexiographic) must be provided out-of-band as well. And this, too, would imply that sort[3] is made aware of what/where the out-of-band data can be found. All of this leads to a "Leaky Abstraction."[4]
Instead, if one identifies the functional requirement of 'ls' to treat both filtering and production as coequal concerns when listing directory contents, the need for 'ls' to "learn to sort" becomes self-evident.
0 - http://doc.cat-v.org/unix/find-history
1 - https://www.freebsd.org/cgi/man.cgi?query=ls&apropos=0&sekti...
2 - https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_a...
3 - https://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sek...
4 - https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
Of course, these choices don’t matter at all in the grand scheme of things, but it’s also these little design differences that seem to nudge systemd into the contrarian oddball bucket, for me.
Kind of like the summer intern that wants to refactor lots of code and changes the coding style while doing so.
It's like saying gnu is bloated because it is 395 different packages [0].
You might want to read this blog post: http://0pointer.de/blog/projects/the-biggest-myths.html
[0]: https://www.gnu.org/software/software.en.html#allgnupkgs
Speeding up booting is a nice side benefit but not at all what systemd is about.
That's a claim I've seen before. Maybe it's true, but it's not what I get from reading the initial introduction "Rethinking PID 1" [0] is that systemd is very much about fast booting. That blog story says:
"As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.
For a fast and efficient boot-up two things are crucial:
"The remainder of the post talks mainly about those things. In my mind, that clearly means that fast booting was the major design goal of the project.
(Off topic to your comment, but what the post does not talk about is taking over lots of unrelated services. Even the name of Poettering's blog, "Pid Eins", seemed to indicate that systemd was meant only as an init-implementation. That would have been a lot better).
[0] http://0pointer.de/blog/projects/systemd.html
> This doesn't mean being fast was irrelevant for us, but reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.
> That would have been a lot better
Yeah, I noticed that all the complaints about systemd almost never are about the init implementation. Instead people complain about journald (e.g. binary=plain text+time stamp instead of just plain text) or networkd or about Poettering or how there is some shadowy conspiracy. Honestly, I think if all the non-init parts had another name like "linux plumbing project" and were developed separately by non-Poettering, much fewer people would complain (even though the software is the exact same).
It would also make discussions much clearer if people said in the beginning what exactly they are complaining about, e.g. "logind is buggy" instead of "systemd is evil".
Indeed it does.
As said before, Poettering opens his introductory blog post "Rethinking PID 1" with a bit of history, and then immediately writes "As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast." That's the very first thing he writes about systemd. And the speed of booting comes up again and again in the blog post. Then how can it not have been one if his major considerations?
So he's contradicting himself, or he changed his mind in the three years between those blog posts.
> It would also make discussions much clearer if people said in the beginning what exactly they are complaining about, e.g. "logind is buggy" instead of "systemd is evil".
That's what one gets if one puts everything under the same name, throw everything in one tarball.
No. All the enterprise Unix OSs had advanced system management facilities that a mesh of RC scripts well before Linux (the OSS Unix OSs still mostly don't). Whatever the core design philosophy of Unix was or is, mostly people who do work on it as a hobby seem to care.
"MX Linux ships with systemd present but disabled by default. The MX Linux team strongly urges users to remain with this configuration which uses sysvinit instead. This page simply provides information for those interested in the question."
https://mxlinux.org/wiki/system/systemd/
Works a treat!
Today, Debian Packaging Policy requires packages to supply an sysvinit-style init script. In order for a software package to be allowed in Debian, a software package which does not have such a script from the upstream developer(s) must be provided such a script by the packager; the Debian Maintainer.
However, the Debian default init system is systemd, and this seems to be a stable situation. No other init system seems to be gaining more than minuscule traction, and 99% of Debian installations keep using systemd. Given this, what is the rationale for requiring, as a strict no-you-can't-be-in-Debian-otherwise requirement, Debian Maintainers to provide and write sysvinit scripts, when only a very small minority is using sysvinit?
One should always remember that all work in Debian, and also frequently upstream development, is provided by volunteers, and very little can be reasonably demanded unless there are very good reasons for doing so.
There are also other ways to more gently push packages to provide sysvinit compatibility. The Packaging Policy could have a SHOULD requirement instead of a MUST (to use the RFC 2119 terminology). There could be a Lintian warning given to packages which does not provide sysvinit scripts matching their systemd service files. I’m sure there are additional ways.
Most software probably already have sysvinit scripts from upstream already. These would not go away. Most of the remaining Debian packages have sysvinit scripts written by the Debian Maintainer, and these would not go away either. The question is what to do with new upstream software which inherently depend on systemd, and the Debian Maintainer does not feel able to write a sysvinit script. Should this software be prohibited from going in Debian?
I think the answer is obviously “no”, when looking at it this way.
But I’m only a Debian Maintainer (and only of my own upstream software), not a full Debian Developer, so what do I know?
Because Debian decided that they want to have the ability to ever support anyting other than systemd. If they lose support for initscripts that are portable across PID 1s then Debian===systemd will be true and it will be extremely hard to ever change it.
Where does this statistic come from? None of my Linux machines report what my installation is or is not using, and I doubt that I'm alone in this.
https://lists.debian.org/debian-devel/2019/10/msg00380.html
See also the popcon statistics for the systemd-sysv and sysvinit packages:
https://qa.debian.org/popcon-graph.php?packages=systemd-sysv...
Yes, I saw that, but it doesn't explain how the figure was arrived at. If it's from popcon, then the figure is very suspect.
First, let me be clear: I have my issues with systemd. The "exmbrace, extend, exterminate" fears from the article are justified to some degree. I don't like Poettering's personality (ok, this is only tangentially related). Why the fsck does it ship an NTP and DHCP client? Both of which had their share of security issues because inexperienced idiots needed to pretend to be rock star programmers reinventing the wheel for no good reason. Oh and I use neither Gnome nor KDE so I couldn't care less if they'd break when switching to another init system.
BUT:
Get your shit together and accept reality. Systemd is here to stay, and as the article mentions, supporting other init systems will become more and more of a chore. Combine this with quotes like
> [...] the project had been unable to fully support systemd alternatives due to a lack of developer interest [...]
> "We have already voted with apt: less than 1% of new installs use sysvinit"
and then the fact that with Devuan WE ALREADY HAVE DEBIAN WITHOUT SYSTEMD. Why the fsck should we waste every Debian developer's/contributor's time with supplying brain damaged init scripts, patches and workarounds for 1% of the Debian user base.
Hey I have an idea; let's cut back on QA and reassign those resources to ensuring Debian works with sysvinit. Does the Debian project have any staff working on security? Scrap that, let's have them work on supporting retarded init systems from the 90s instead!
I continue to standartize on Debian VM containers for infrastructure, but only because of lack of alternatives.
https://skarnet.org/software/s6 https://skarnet.org/software/s6-rc
> It isn't modular just because it's divided into modules.
https://skarnet.org/software Real modularity, each API are completely independent from each other
>For one, have you ever written an unit file? It literally takes 3 minutes.
http://web.obarun.org/software/66/frontend.html Simple frontend file to declare a service, take 3 minutes to write it too.
>but the only people doing the work are Systemd
the fact is that some really good dev make the works but nobody care and nobody wants to give real supports(i mean financial supports) to do the thing in the right way.
Is systemd portable? can you build it with musl? that it works on BSD? s6 and 66 do.
>systemd was promised as a way of shaving a few seconds off of boots
s6 do the same without socket activation(fallacious arguments to sell systemd)
Give to s6 and 66 dev the same financial potential of systemd and you will get a real init and service manager in the real *nix philosophy with well designed code.
Actually only one distro show s6 + 66 in action but make it very well
The kernel is GPL.
Most of the userland (GNU stuff) is GPL.
So is systemd.
Terrible argument. That's what the Debian installer installs. We replace systemd after installation, as part of our configuration management system.
And, once again: the more systems you run, the more you pay attention to security, the less likely you are to run popcon. Popcon results keep showing laptops and desktops because of that built-in sampling error.
How is GNOME desktop a small project?
It reminds me of the Windows NT advocacy back in the late 90s, that "Unix is Dead" and that Microsoft's invincibility made it inevitable, anyways.
Because a bunch of people did not agree with this view, we ended up with something quite different than the roadmap that Microsoft had for us.
I am a systemd detractor and I happily use Void with runit, so I would really never say that we don't have anything else. I don't know what the magical features are of the ever growing giant squid that is systemd that people swear they can't live without, but I haven't encountered them.
SMF was nice. RIP Sun.
I no longer really hate systemd, but for OSS, keeping options open is always good, in the case of system that is before it is coupled with all distros too deeply, let's make sure there are possibilities to use other init system as well.
for example, in embedded system, we avoid systemd at all costs.
This is why I'm leaving the Linux world entirely. I can't think of any other realistic way to avoid systemd in the long term.