I refuse to use systemd to this day. It's unbelievably complex and became established through political power play rather than any sort of merit. Which is without a doubt not what I expected to see in the Linux ecosystem.
Yeah, it's not so terrible technically, but politically I despise it. Especially when the people involved take a stance of "we're not actually going to discuss this or debate why this might be the best way to do it, we're just going to slowly try to make your life harder and harder until you give in" ( https://lists.freedesktop.org/archives/systemd-devel/2010-Se... )
Systemd is a double edged sword. I started using FreeBSD in 1999, and Mandrake Linux in 2000ish. I switched to gentoo when it came out, because i like to tinker and see how things work (like or hate the distro it does make you learn a quite a bit).
Fast forward to 2018 and i manage around 500 Redhat servers here. About 150 are at RHEL7 (the others need to be upgraded). So learning systemd is a requirement, it is not going away. I like some points of it. I do like the jounrnalctl command and the ease of looking at logs, however being the hypocrite i am i despise the binary logs and non compatibility with most syslogging devices (i have had to explain lost logs during an audit with systemd and it was not pleasant).
From a end user standpoint systemd is great for my desktop. For the servers it is functional, server boot time does not matter to most administrators. On VM's both boot fast enough, on bare metal....some of our large servers take 5 to 7 minutes to post (thanks HP) so the OS taking 20 to 30 seconds longer to boot is not a big deal.
I follow the systemd mailing list to see what is going on, i think if the guys over there were not as abrasive in some of their answers things would be smoother, and more receptive to the needs of some of the users. I see a lot of features that are desktop specific and that seems to be where their development lies for the most part, desktops and servers are two different beasts.
I guess the infighting just sucks, i am not a fan of systemd simply because i like a simple OS with minimal features to accomplish my objectives, however it is here to stay and i am a Linux Admin so it is part of my job and i learned to use it and keep up with development.
I still use FreeBSD for all my home servers (except my docker swarm), old habits die hard.
Speaking of BSD and Docker... I'm learning FreeBSD for a little side-project but it seams its harder to get a good deterministic deployment pipeline with Jails than with Docker. Whats the best practice there?
I don't develop on FreeBSD either, its just for prod.
Unfortunately there is not really one. I always treated jails as VM's. You could create the jails on ZFS and do a send and receive, or use something like Jenkins to build and deploy. However jails are like LXC on Linux, not like docker.
You could use nanoBSD in the source tree to create a minimal mostly immutable image with your application. It will still be like a VM though and need deployed somewhere (this is how i run my DNS servers at home, they are about 120MB each and can run on pretty much any VM host (or bare metal)). But docker does have that market better (hence why i have a small swarm at home to play on).
There is also docker for FreeBSD, still in testing but works pretty good it you build your own native images. I build a memcached image and was running that for a while.
> large servers take 5 to 7 minutes to post (thanks HP)
IBM/Lenovo xSeries servers are the same. 5+ minutes to get through the boot process, due to all the hardware init and checking. That's with UEFI too. ;)
Somehow during a system crash (hardware failure) the journal logs were corrupt and could not be read, and application logging was not being forwarded to the syslog facility. Our logs were not send to a logging server at the time, they were backed up daily and stored on tape.
If it's not technically terrible, it's not technically terrible anymore.
All the initial "ooh and aah" factor of SystemD came from using the kernel's cgroups mechanism, which was a dumpster fire by itself--something dropped by google in the kernel for easier maintenance with the understanding that no one should be stupid enough to use it for something important...enter SystemD.
Apparently cgroups is in better nick these days (as is SystemD), but until the likes of Al Viro come around and give it a clean bill of health, I think I'll pass.
cgroups are essential to properly limit daemons on baremetal servers without the overhead of containers (so more bang for bucks).
For example, you can make sure some poorly written python daemon will never use more than 50pct of the cpu or over 1 Gb of ram - and systemd services will nicely restart the daemon if\when that happens.
By not using systemd you are depriving yourself of essential tools in modern sysadmin (timers alone are worth switching to systems compared to cron anachronistic hacks)
The grandparents comment was targeted at cgroups in general. You can’t use cgroups without cgroups. To add on that: IMHO, both systemd and docker made cgroups much more accessible to joe sysadmin and while they’re not a bulletproof security feature, having them (and capabilities, another kernel feature exposed by systemd) in wider use is generally a good thing.
Sure, then you need to write scripts to monitor your daemons and their dependencies, and you may end up writing something likely worse than systemd that just suffers from the 'NIH' syndrome.
Adjusting to systemd took me a while, but I believe it was worth the effort, and I also believe most people who dislike systemd are just set in their old ways
There are 11 total from 2015: one arbitrary access, one which allows administrators to run a process as root rather than the intended user (CVE-2017-1000082), and some DoS opportunities. Not great and several great examples of why C should not be used but hardly “every other month”.
Now, it's hard to compare that it against other systems because it combines functionality which people used to have to use third-party tools for or roll themselves so you have to count that against every buggy init script or supervisor feature, apps whose developers never got around to adding the hardening features which systemd does use, etc.
The systemd developers "forget" to file a lot of the CVE bugs that should have been filed, so the CVE is incomplete in regards to the serious security issues that have affected systemd.
I still remember that time when systemd developers argued that a privilege-escalation bug systemd enabled was not really a bug. The criteria those developers* use to determine what merits a CVE filing doesn't quite match up with what you'd expect, so CVE count isn't a good metric for systemd security.
* Unfortunately, they aren't alone in their sloppy handling of security issues. Rust is also another project that is known to not file CVEs for serious bugs if they occur in previous releases.
Weirdly though, getting a CVE assigned can be a real PITA (and unsuccessful). The people who do the CVE assignment are generally overloaded, so lower impact/priority stuff often seems to get missed or not bothered with.
This hasn't been the case for a number of years, Mitre has seriously picked up their game, and you can talk to linux vendors such as Red Hat, Ubuntu and SuSE who also have blocks of CVE's assigned for things they shipped.
The alternative is DWF, which would be more popular if this was a more common problem.
Sounds like a petty dictator pushing everyone to think and act the same; manipulating people until they give in because it takes too much effort to resist. He should consider a career in politics... I always get uncomfortable when I know people who pull stunts like that in RL and it is irritating when it dramatically affects an otherwise very good operating system. I use Void Linux just to avoid systemd, considering its long track record of horrific bugs and security issues.
As a counter point, I personally enjoy using systemd to manage my home servers and PC. And I have written unit files for quite a lot too, and enjoy it.
Surprisingly, it seems as if different people have different tastes/opinions. :)
And I wish we could just use it for services! But alas, it comes with a free mandatory proctology exam, by a guy with really big hands, called "pid 1".
What's also kind of funny to me is, it wasn't designed for cloud-based services. We now have to invent whole new systems that look a lot like systemd just to manage distributed decentralized services that run on Linux systems.
Systemd would have been great for everybody if it had been developed by people with different priorities.
The fact that people keep repeating the "messy shell scripts" fallacy is proof of how effective systemd propaganda has been. The vast majority of Linux systems on the planet, which ship software made by Google, do not run systemd.
The user almost never interacts with any init system, unless they are starting up, shutting down, or doing some weird maintenance. It's an "initialization" system.
Honestly, none of this crap matters at all. You can get by just fine with init scripts, and you can get by just fine with systemd services. Except for a few people in the world who have applications that are really sensitive to either fast boot times or really complex system dependencies, any init system will work.
This is not true. systemd did standard multiple interfaces in Linux ecosystem. It is much easier to get things working nowadays than it used to be. systemd became standard thanks to meritocracy (important people in most distros decided to adopt systemd, it was not a "political power play").
It is complex, and there are bugs like any other kind of software[1], however like any other software it is improving.
[1]: For example, I used to hit multiple concurrency bugs in sysVinit used by Arch Linux. The only way to fix them was to find the correct order that system worked. No more problems of this kind thanks to systemd dependency resolving.
> For example, I used to hit multiple concurrency bugs in sysVinit used by Arch Linux
Arch didn't really use SysVinit before systemd though, but their own BSD-like rc system, which I rather enjoyed actually..
And I got hit with concurrency issues after the switch to systemd, because seemingly the dependencies for disks and file systems aren't setup correctly by the Arch scripts requiring me to add a few fake units to fix up the dependencies (otherwise the system would just fail to boot at all most of the time).
I need to run /usr/bin/expect from one of the init.d scripts. That breaks with systemd. Moving that box to Devuan (no systemd) fixed the issue. The alternative was to rebuild that particular application without systemd. So far systemd hasn't brought me anything particularly useful. I've never had any issues with getting things working (pre-systemd), and one of my pre-systemd laptops boots from power off to fully graphical in five seconds, so I don't buy the argument I hear from some that systemd is necessary for reducing boot-up time.
I made a typo in lighttpd's config once. sysvinit init script, which used start-stop-daemon, would report success, but would not start the server at all. There was no error messages, nothing in the system log.
Systemd logs all process output by default, so things like this cannot happen at all. Just for that, I'd choose it over sysvinit any time.
I am going to guess you did not start the apache via systemd? This is actually a feature: systemd only manages processes it has started. So if you started apache via /etc/init.d, you should restart it via /etc/init.d as well.
(note that the opposite is not true: many /etc/init.d scripts stop process by killing everything with this process name -- no matter if it is the right process, or user-specific one, or one managed by some other supervisor)
I don't remember exactly, but I think Apache was started via systemd because there was no error like "Apache is not started". Systemd was reporting that it is stopping and starting Apache but in fact it did nothing.
> I need to run /usr/bin/expect from one of the init.d scripts
That's interesting. Can you provide some more details?
To clarify: I don't care about the systemd argument; I'm interested in why an init script would need expect. I can think of a few pretty edge-casey good reasons and some scary ones. Care to share yours?
At least for Debian, technical committee (elected by the community) could not choose between systemd and upstart [0], so systemd was the final winner. There was overwhelming desire that sysvinit should go.
And when this question was brought to general election, community decided it did not care: [1]
So I am not sure who those "important people" were, why do you feel they did not represent you, and what would community choose, in your opinion.
I, having worked with upstart, can say it is worse than systemd.
I have used systemd and currently am forced to use it in production. It works great until it doesnt.
There have been multiple times I have no idea what was wrong as it was faster to simply recreate the system from scratch and hope the same bug didnt happen again.
Who else has more merit to make this decision than the Debian developers (= the important people) themselves? Random neckbeards whining on online forums?
At least as far as Debian is concerned, you will find that the people with skin-in-the-game (administrators) were massively against systemd. The Devuan fork/split happened exactly because of that.
> you will find that the people with skin-in-the-game (administrators) were massively against systemd
Let me offer you an anecdote from my company. Now, we're a RHEL shop and not a Debian shop, but we've been around since long before systemd.
Most of our hosts now run RHEL 7, but we still have a handful of old boxen still running RHEL 6, and I've been personally involved with quite a few migrations from RHEL 6 to 7 during my time here. Whenever we retire a RHEL 6 host and replace it when a RHEL 7 host, the general consensus from the people who administrate it is "thank god we can now use systemd instead of having to deal with sysvinit". Every time I have to do anything on one of our remaining RHEL 6 hosts, I brace myself for pain, because our RHEL 7 hosts are just that much easier to manage.
You must be joking. What meritocracy? The guy who wrote systemd had already a major failed projects under his belt. PulseAudio rings a bell? Every reasonable person understand that separation of concerns is a good thing. Systemd does the exact opposite.
Few articles to be familiar with regarding systemd:
"The same can be said of the init systems in Linux, like systemd. In a nutshell, the system should start quickly and get into a working session. We had this in 2010 or so, with boot times down to mere 10 seconds using init. No flaws, no bugs. Even in the commercial sphere, working with init, I do not recall any major problems.
Then, suddenly, we have this new binary diarrhea with a hundred million modules, and for the past five years, this unstable, half-baked, undebuggable nonsense is the backbone of most Linux distros. The invasive and pervasive nature of the systemd framework has also affected the stability of the user space, the very thing it should never have touched, and pretty much all problems with the quality of the Linux desktop nicely coincide with the introduction of systemd. The development continues, of course, and for no good reason than trying to reach the level of stability, maturity and functionality that we had half a decade ago. Someone landed themselves a lot of monthly pay checks by writing complex code to solve a problem that did not exist."
"None of the things systemd "does right" are at all revolutionary. They've been done many times before. DJB's daemontools, runit, and Supervisor, among others, have solved the "legacy init is broken" problem over and over again (though each with some of their own flaws). Their failure to displace legacy sysvinit in major distributions had nothing to do with whether they solved the problem, and everything to do with marketing. Said differently, there's nothing great and revolutionary about systemd. Its popularity is purely the result of an aggressive, dictatorial marketing strategy including elements such as:
Engulfing other "essential" system components like udev and making them difficult or impossible to use without systemd (but see eudev).
Setting up for API lock-in (having the DBus interfaces provided by systemd become a necessary API that user-level programs depend on).
Dictating policy rather than being scoped such that the user, administrator, or systems integrator (distribution) has to provide glue. This eliminates bikesheds and thereby fast-tracks adoption at the expense of flexibility and diversity."
Solaris already had a better replacement for initv so did some linux distros.
I think we need a better alternative that does not behave as a black hole, ntp, dns resolution, logging etc. do not get sucked into it and finally we need a way better implementation that does not have a remove or local priv escalation every other week[1].
Are you saying that entire TC of Debian was intimidated by Poettering? And then later, in general election, he forced majority of votes to say "we are fine with systemd"? [0]
I find this highly unlikely. Here is my take: people were tired with "sysvinit". Of all alternatives, systemd sucked less. So they went with it.
There was a heavy influence from the GNOME camp, both upstream and within Debian, by mandating the use of systemd with GNOME. At the time, I wasn't particularly happy at the disproportionate influence for a specific desktop use case at the expense of other use cases e.g. embedded, server and others.
Each binary does one thing. So for example /lib/systemd/systemd, the PID 1 process, only starts processes, nothing else.
Now, some people complain that "systemd" package contain other binaries, like systemd-networkd, or systemd-journal-gatewayd (the HTTP server). I don't understand their problems. Sure, it is annoying that "systemd" package contains network manager -- but you don't have to use it; in fact, I am not using it at all.
So I do not see the irony. I think 73 binaries, each optional, easily replaceable, and doing only one thing, is very much inline to microservices philosophy.
The number of binaries isn't in and of itself a good measure. It says nothing about the tight coupling and poorly documented interfaces which tie them all together.
There are two major things to consider here:
- how easy is it to replace each of these with an independent third-party implementation
- if it is possible, why should the design of that component be dictated by the systemd upstream
A huge amount of the value of Linux was the fact that the system was a loosely-coupled collection of parts. Much of that flexibility has been lost, and with it the utility which drove a lot of the adoption of Linux in the first place.
Re "how easy is it to replace each of these with an independent third-party implementation"
What did you have in mind when you were talking about hard-to-replace implementation?
I find the replacing all those components to be pretty easy. Those things are all loaded via regular unit files, and they need just one symlink to be completely disabled.
In particular, systemd-networkd is entirely optional, and ifupdown is still supported in ubuntu (even if not installed by default).
systemd-timesyncd is a regular service, and can be disabled directly, or via timedatectl. ntpdate still works when it is disabled.
Many other services, like systemd-hostnamed, do not even run by default. You could disabled them by default and things would still work.
The worst offender is probably systemd-logind, but luckily I did not have to deal with it. Looks like it only needed for GUI logins, not ssh one -- so most sysadmins would not have to care. That said, I did try to use it's predecessor, ConsoleKit, and it was pretty horrible as well.
Except for the journal. It is effectively required by systemd (the pid 1 binary). In the vast majority of cases, that means running systemd-journald.
Every attempt I have seen at operating without it either misses early logs or is extremely fragile/unsupported.
That's a point of fact, not a position in the larger argument here. There are good arguments as to why journald should be effectively a required component.
> /lib/systemd/systemd, the PID 1 process, only starts processes, nothing else.
That is incorrect. It also interacts with the journal, the component implicated in the exploit in the article.
> Except for the journal. It is effectively required by systemd (the pid 1 binary). In the vast majority of cases, that means running systemd-journald.
man systemd
...
--log-target=
Set log target. Argument must be one of console, journal, kmsg, journal-or-kmsg, null.
you can log to kmsg -- the messages won't be lost.
> Every attempt I have seen at operating without it either misses early logs or is extremely fragile/unsupported.
I am not surprised -- this was one of many annoying parts of sysvinit, the missing early userspace logs. This was one of the many annoying parts. Gentoo used to have a hacky way that scraped screen buffer (!) but I think it broke at some point[1].
> That is incorrect. It also interacts with the journal, the component implicated in the exploit in the article.
Fair enough, I oversimplified. It also interacts with udev, systemctl, and does cronjob handling and network interface renaming.
[1] I just checked Gentoo's website now and looks like they have a better way now due to OpenRC.
The decoupling of services is the trend of microservices. Systemd is merging many previously decoupled systems to manage them and provide a platform for decoupled services.
For me, "decoupling" means running separate processes with well-defined interfaces. Systemd does exactly that -- it has many separate processes, each with well-defined interfaces. For example, systemd-timesyncd can be run on any machine with dbus, and does not require systemd init at all.
The only "merging" systemd does is that it puts multiple binaries into one package, other than that they are completely separate. While it is annoying waste of space, there is no reason to suspect "coupling".
Can you be more specific, please? Like which interface is not well defined?
I find the fact that systemd internals are connected via the same mechanisms as non-systemd apps (units, sockets and so on) very nice, especially compared to sysvinit or upstart. Have you tried to patch network detection in upstart? Not an easy job. And upstart's manpages are less than useful, compared to systemd's.
Above in the other threads someone said "journal". This is a good point, except there is --log-target=kmsg option which disables that interface and switches it to good old kmsg which anyone can parse and read.
It's not about being smarter and trusting, it's about doing stuff and having results vs taking a ride for doing nothing.
When I'm getting a free ride, I'm not going to talk down the provider how he should be doing the job differently (not necessarily better; that might be my opinion, but not objective truth). I'm not in his shoes, solving problems he is solving, so my view could be diametrically different than his.
Important people are important people because of their merit. The fact that their opinion counts and not random users' opinion is what makes it a meritocratic instead of a democratic selection.
What you are arguing about is whether those people selected systemd based on its merits or based on other considerations is an entirely different question and an unsubstantiated accusation.
I'm sorry but no, there's no such thing as an objective measure of merit.
In 1991, most of the "important people" in technology would have laughed at Linux compared to OSes like Unix System V and DEC/HP Unix. Even as the 90s progressed most serious shops wouldn't adopt Linux and went for the BSDs (FreeBSD/ NetBSD, etc) or Solaris because Linux was considered hobbyist software. I know because I worked in tech at this time and the same attitude even continued into the early 2000s.
The point I'm trying to make is that random users' opinions are exactly how certain software projects, open source or proprietary, become popular or fall out of public use. It starts with Systems Administrators or developers getting fed up with a certain solution and adopting alternatives until it reaches critical mass and the old is rendered irrelevant.
I do too, for personal use (OpenRC on Gentoo user through and through), but due to the adoption of systemd by popular distributions I don’t see an alternative for work. Unfortunately.
That's what I did as well. But I also continue to use Slackware which doesn't have any current plans to move to SystemD.
It was the first Linux distro I ever used and I still love it to this day. I've used many different systems for work over the years but I've kept at least one Slackware laptop or desktop going since early 1995 when I first found a Slackware CDROM in the back of a book about learning Linux.
Although it gets new software, bug fixes and minor updates here and there it's remarkably similar today to what it was then. And I find it Just Works, I've had very little trouble with it over the years.
I think I like it too because it always felt like the most traditional Unix like distro I've ever used and also more BSD than System V which I also generally prefer.
I like OpenBSD a lot, but I have to nitpick your description: OpenBSD diverges from "standards" when they decide the standard doesn't make sense. They are not afraid to tear down working things when they decide it's necessary, and I've faced a lot of release-to-release breakage, forced reconfigurations, or features I've relied on go completely missing without a lot of warning.
Still a great project that I use every day, I'm not knocking it. It's just not a great example of a change-averse type of stability.
I worked with both SysV init and updstart. Upstart was not too bad. SysV init was giant piles of bash-script, always slightly different from service to service and from distro to distro. Bash is a language which two decades after, working full time in Linux, I don't completely grasp. Just a few months back we got a client still stuck on SysV init, we ran this algorithm with him:
Yes, systemd makes being an application developer on Linux so much easier. You can declaratively control state of your daemons, recover from crashes, add process limits, control startup order correctly and on and on.. Much more readable and usable than bash scripts pulling in random libraries and using endless greps to find out system state.
Hum... Symlinks existence is declarative, configuration files are declarative. Running a specific piece of software to change the state of your service isn't declarative at all.
> Bash is a language which two decades after, working full time in Linux, I don't completely grasp.
Have you taken the time to actually read the read the bash(1)? I've noticed that a lot of people (myself included) don't learn sh/bash (and shell scripting in general) initially out of necessity, not with the intent to actually learn the language. If someone wanted to learn a "normal" programming language like C++, Java, or Rust, the would probably start by reading tutorials or guides that cover the major features and teach the core concepts[1].
With bash, most people appear to start with trying to fix something like a build/install script, often resulting in cargo culting a few lines from stackoverflow, forums, "cool one line tricks"-style blog posts, or similar community resources. These can be very helpful[2], but they are not really a way to actually learn the fundamentals of the language.
For me, bash programming initially was very confusing. After I finally forced myself to take the time to actually read the docs/etc, I realized I was making a few incorrect assumptions[3] about the language. After fixing that and learning a few important tricks[4], bash became a lot easier to understand. Now it's one of my favorite languages (for simple tasks).
[1] e.g. (C) pointers, (Rust) variable ownership/borrowing
[3] IO had a lot of trouble initially trying to figure out how to return values from a function. This was hard because, bash "functions" are not really functions like you would find in most languages. I had assumed that you would return values form functions, which breaks when you try to return anything besides an integer. (bash "functions" like foo() { echo "bar" ; } defines programs that return data by writing to stdout).
[4] Always quote variables. Always use curly brackets when using variables ("Hello,, ${name}", not "Hello, %name"). Using $* is almost always wrong; Use "$@" (with the double quotes) instead, which correctly handles spaces/bad-chars in filenames.
If you don't grasp bash after two decades of Linux experience, you should maybe question yourself as to why that is rather than blame bash. Maybe you never properly spent a few days fulltime trying to learn it?
I'd take bash scripts without hesitation over systemd any day of the week. I can debug bash with my eyes closed. Every single time I had to debug systemd, I wanted to kill myself.
SystemD turns your bash scripts into C, and then gives you a config file input.
Before this; on RHEL systems there were similar initiatives, you /rarely/ touched the init scripts, you used the /etc/sysconfig/ directory of configuration files[0];
The major difference being that system administrators could actually tell you line-by-line what was happening. In C you would have to find the version of the code in some version control somewhere and hope that there's not patches applied.
The absolute truth is that you cannot know what systemd is doing, you cannot even strace it. You /rely/ on it telling you the truth and doing the right thing.
And honestly I don't trust it to do the right thing when it can't even get encoding right[1].
Personally, I totally agree with you. Aside from the political power play that made systemd "popular" (/adopted), it also gained traction because of a lack of skill among the ever growing user base of Linux. Quite a few of the "problems" that systemd claimed to solve where solvable in SysV init, but it required skill/experience.
A bit like claiming to be a car mechanic and bashing an old car because you can't tune the ignition timing, because it doesn't have a board computer doing it for you and you don't have the skill/understanding to do it yourself.
In the past, you often were required to have at least some skill/experience to get Linux to work for you. Today, it's more about choosing the right tools to use Linux with a just a bare minimum of skill/experience.
An understandable development for sure, but it also opened the door for software of questionable quality, which has at least part of its popularity to thank to the ignorance of a significant part of the user base.
Fully agreed. There has been a race to the bottom regarding technical competence by various entities for various reasons. To me it seemed at the time that Redhat used dark-pattern-like behavior in order to push systemd, exploiting people's hopes regarding a more unified Linux ecosystem.
There is nothing wrong with making things easier to use. The problems begin when the people you put in charge of that effort (Poettering and co) are extremely short-sighted, do not properly understand what came before and thus make mistakes that could have easily been avoided, are average-at-best engineers with a personal history of bad projects (pulseaudio, avahi), are bad communicators and take valid critique poorly.
When I was still at Google, colleagues at Android and ChromeOS teams laughed at the mere mention of systemd. The general consensus in the teams I mostly interacted with was that systemd resembled a hidden iceberg with enormous problems, the magnitude of which would slowly become apparent. Which is one of the reasons Google has mostly kept away from it.
How did 'skilled' programmers recover when a daemon crashed in Sys5 init-based systems? The init script ends after startup so you are stuck with a third party monitoring service that will often clash with startup functions making controlling system state really hard. systemd was worth it for that feature alone.
Linux userspace was a bunch of crufty, unmaintained tools from xinetd to logind (literally had no maintainer until system came along) to update-rc.d that additionally were not taking advantage of a lot of new kernel features like cgroups. systemd has done a great job moving the base layer of linux userspace forward.
The old world of cobbling together bash, sed and shell metacharacters was always hacky, insecure and broken as shit and we are way better off now with systemd.
One would ask himself how the BSDs manage to do it (no systemd), Android (no systemd), ChromeOS (no systemd), Solaris/Illumos (no systemd) ...
Your arguments hold no merit whatsoever. The fact is that all the problems you describe have been solved, properly, multiple times _before_ systemd entered the picture. The reasons behind systemd mass adoption were political and Redhat exerted a lot of pressure at the time and in many ways, still do.
You could use the same argument to disparage any technological innovation. Computers? Our ancestors did just fine without them and so do many people across the world to this day. But more ridiculous than that is your listing of Solaris and Android as systems without systemd. Solaris uses SMF which was one of the inspirations for systemd. SMF is much closer in spirit to systemd than it is to sysvinit or rc. The particular merits of systemd or bash scripts aside, using SMF as an argument for the later is just ignorant. Furthermore, even though Android doesn't use systemd, software written for Android is written in such a way that it doesn't interact with the init system at all. The typical user/admin has no access to the init system. I have no specific knowledge of ChromeOS but I suspect it is much like Android in this regard. The only example that really works for you are the BSDs.
"Closer in spirit" does not mean anything tangible in the real world, you are merely playing with words.
Solaris SMF is vastly simpler than systemd and has a much narrower scope and focus. I don't recall mentioning bash scripts in the post you replied to, so you are simply being disingenuous by presenting a false dichotomy.
I find it really hard to believe that you were unable to understand what I meant.
The complexity of Sysvinit is orders of magnitude less than that of systemd.
This whole thread is a discussion of the relative complexity between sysvinit and systemd. Sysvinit uses shell scripts to implement much of the logic around starting and stopping services. Any discussion of sysvinit and systemd is going to involve bash. It's disingenuous to pretend otherwise.
I will copy my post again, here, to expose your strawman or unwillingness to stop deflecting:
"One would ask himself how the BSDs manage to do it (no systemd), Android (no systemd), ChromeOS (no systemd), Solaris/Illumos (no systemd) ...
Your arguments hold no merit whatsoever. The fact is that all the problems you describe have been solved, properly, multiple times _before_ systemd entered the picture. The reasons behind systemd mass adoption were political and Redhat exerted a lot of pressure at the time and in many ways, still do."
This is the post you replied to, with arguments that (still) hold no merit. Now you are trying to shift this into something else rather than stick to the points I made _in this thread_. You pick and choose a reply of mine _from a different thread_. Moreover, you write: "This whole thread is a discussion of the relative complexity between sysvinit and systemd". No it is not. As I wrote: "The fact is that all the problems you describe have been solved, properly, multiple times _before_ systemd entered the picture."
I would take you more seriously if you stopped presenting one logical fallacy after another.
daemontools, or respawn from inittab. There are a number of perfectly reasonable possibilities, of which these are just two.
But more generally, you didn't restart daemons if they crashed. Firstly, because they used to be written sufficiently well that they never crashed, because competent people wrote them. Secondly, because continually respawning and crashing does no one any good.
Firstly, because they used to be written sufficiently well that they never crashed, because competent people wrote them.
If your deployment strategy depends on never having to run substandard software then you've already lost. Also, it just isn't true that older software was necessarily more reliable. It's just that when you found yourself maintaining poorly written software you just dealt with it through whatever means you had available. I remember having to use an IBM HSM implementation on AIX, something you would expect to just work because it was IBM software written for their own system on their own hardware, but in practice the filesystem kept invisibly crashing resulting in apparently corrupt files and I'd have to restart it every few minutes.
The thing is, most Linux distributions ran services this way for well over two decades. The world did not end, and the number of problems we experienced in reality were negligible. If we wanted automatic service restart on failure, then there were facilities for doing so should we chose to avail ourselves of them.
If something is crashing and requires a restart, then doing it automatically is at best papering over a problem the admin should be investigating. It's a mitigation, rather than a solution, and might well cause more problems than it solves.
systemd isn't bringing anything particularly new or noteworthy to the table here.
The thing is, most Linux distributions ran services this way for well over two decades.
So? That doesn't mean it was the best way to do things. Humanity existed for thousands of years without vaccines and still managed but that doesn't mean that disease wasn't a thing. Misbehaving services have always been a thing and they've always been a problem. I know because I've dealt with them. If you feel that other methods for dealing with misbehaving services are better, fair enough, but don't appeal to a mythical golden age where everybody wrote software without bugs.
I'm not in any way appealing to a "mythical golden age". I'm simply pointing out that the whole Linux world ran this way for over two decades without this being a critical problem, or even a problem of particular note.
Not only that, but automated service restarting was configurable if desired, albeit not the default. If you wanted it, it was doable with ease. This is not a new feature which systemd brought to the table, it was already available.
The sentence: Firstly, because they used to be written sufficiently well that they never crashed, because competent people wrote them. IS an appeal to a golden age. Because it's not true. People did write services that crashed and sysadmins had to work around them. I know this to be the case because I had to work with a particularly egregious example. Whether you think the older methods for managing them were better is one thing, but those problems existed and they caused lots of damage.
> How did 'skilled' programmers recover when a daemon crashed in Sys5 init-based systems?
Maybe the daemons didn't crash so often as now?
I never understood this new approach, which consists of writing a server process in a half assed way so that it crashes frequently, then solving that by putting a restarter service in front of it, done!
Can we just ban/flag these comments already? They're so obviously false and their motivations aren't sincere. Political colorization of other people's choices because you don't like it, with a thin veil of political grandstanding masquerading as insight, on top of needless hyperbole is just unhelpful. Honestly, I get that you like systemd. I understand wanting to not talk about it anymore. But not wanting other people to be able to talk just because they disagree with you is ... not a compelling perspective.
>I understand wanting to not talk about it anymore.
I didn't say that.
>But not wanting other people to be able to talk
That's certainly not my motivation. How dare you even claim that is something I want.
It's an unsubstantiated comment that doesn't offer anything to the conversation. It provides no context, nothing to argue against, no examples, no solutions, but it's allowed because it fits within the HN userbase's opinion. An opinion often grounded in narrative and not facts.
It uses conspiracy theory accessories and grandstanding. That's it.
Your comment isn't clever because it just reveals you couldn't be bothered to read what was being stated, and then even had the audacity to prescribe positions to me that I never stated. And certainly have never stated on this board.
Me too. Ironically, systemd is why I bought a Mac.
It's so hard to find a linux distro that actually works on a laptop but doesn't use systemd, so I eventually just gave up on Linux entirely.
That left me with BSD, Windows, and macOS.
I tried FreeBSD and OpenBSD but performance was atrocious and noticeably worse in almost every way than Debian and win7 on the same hardware. I'm sure BSD makes a good server OS but it's just not mature enough for serious work unless I was willing to keep my laptop plugged 99% of the time. But what's the point of a laptop if the OS performs so poorly it won't even last a 4-hour flight?
I similarly seem to be the last guy on earth who still remembers the bad old days of Microsoft's dominance so I won't pay for windows.
Interesting choice you have there. Systemd is heavily influenced by launchd, the service manager that makes MacOS tick. They're very similar in design. IPC based, socket-activated, property-based, dependencies, parallel startup, unifying init and service management...
Sorry you had such a bad time with OpenBSD. It isn't top of the heap when it comes to performance but there are benefits that balance it out.
On the Linux front, I've been using Void and it has been pretty fantastic. Runit is the default init. It is a more hands-on distro (think Arch 10 years ago), but it's fast, slim, and doesn't have systemd.
> It's so hard to find a linux distro that actually works on a laptop but doesn't use systemd
Don't you think that there's a reason for that? That systemd solves the problems that make it possible to react to events and makes laptop-usable distros possible?
Meanwhile, enjoy launchd. Maybe you will find out, that they are conceptually similar.
launchd has a clearly defined scope, and it restricts itself to doing only those tasks which fall under its remit.
If systemd had followed a similar philosophy, it would have been accepted without anything like the same amount of criticism. As it is, its scope creep is frankly absurd and dangerous.
Most of the additional functionality is optional, and in separate binaries. Apple also has similar functionality (seat management, resolver management, etc), and nobody is bothered by that.
One gets the impression that optionality is only theoretical. Same for separate binaries. The degree of coupling in the systemd architecture is enormous. So then, what purpose do separate binaries serve other than being able to (conveniently) be used for deflection or provide a certain facade?
The philosophy of systemd exemplified through PRAXIS is one of subsumption and uniformity (== taking away choice) under a singular vision defined by the systemd implementors. In practice, this means that you are penalized in various ways if you don't "buy in all the way". You can take a look at all the distributions that ship systemd by default and see how many have bought in all the way vs not using the "additional functionality".
I moved away from Linux as soon as systemd was everywhere. I first migrated to Slackware, and then to FreeBSD. I wouldn't call this kind of move overreaction.
Some people just want to know exactly what is running on their system, and how it works. That's one of the reasons I don't use Windows.
(I do confess that I never took the time to learn systemd properly, but I highly appreciate it for introducing me to the BSD world).
I don't particularly think so. The amount of my time that systemd has wasted is insane. Buying a mac would have saved me all that time... if only I liked their hardware more.
I don't think so. If the distribution you're using insists on integrating software that you don't want, it's reasonable to leave.
He tried other open source operating systems and didn't find them acceptable. Sure, there are Linux distributions that have formed to avoid systemd, but it's not clear how long any of them will last.
Mac os isn't exactly unicorns and rainbows either, but there are some benefits of being part of a larger user base, too.
Did apple reinvent every Unix daemon under the sun as part of launchd? And did they also reinvent all the security problems while they were doing it?
The problem with systemd isn't necessarily how it handles system startup and daemon supervision (although I don't care for that), it's that it subsumes so many other things, and with no technical excellence.
The aggregation of these services are all understandable, because every one of them is about running a service. They might be triggered by different events (timer, network connection, at boot, manually), but other than that they are all doing pretty much the same thing: setting up and running a service.
It isn't building in an NTP client, or a hostname resolver, or configuring your network, or taking over the system logging, or generating QR codes. It has a singular focus and design which makes conceptual sense. It's not a dumping ground for a disparate collection of poor quality alternatives to existing tools.
