Systemd is without doubt one of the most important items of software on a modern Linux today, except perhaps for the Linux kernel itself. It turned the mess of shell scripts and other crap into the rock-solid, foundational system services layer we enjoy nowadays. If we do ever get the year of the Linux Desktop, we will have to thank the authors of systemd for giving us a bedrock of delight to build upon.
From an outsider perspective these stick out to me as most important:
- Unified logging subsystem
- On-demand launching, memory limits, and general resource management
- Advanced security features, i.e. sandboxing, DynamicUser
- Well thought out and implemented given the constraints (feels like Linux quality)
In general it represents a shifting of code from daemon developers (who previously handled daemonization themselves) to the system.
On-demand launching is good for performance: work can be deferred from boot and inactive daemons can be stopped. This is critical on battery and RAM constrained devices
I wish Windows ran systemd--seriously. Windows services and low level functionality is just a hot mess of cruft, decade plus old UI and configs, etc. Please jettison it all and give a consistent declarative way to manage it all like systemd does for Linux.
Yeah, imagine if Windows was made up of many simple and interchangeable components for which alternatives were easily available from sources other than Microsoft? Don't like services? Choose among half a dozen alternative background process management options, without affecting logging or file system layout, or listening to inbound network connections...
If only that were true. "Virtually any Windows application" is a fantasy I'm afraid, many important applications run poorly or not at all on Linux. Then there's the "particular attachment to the NT kernel" caused by driver support for $HARDWARE - there's tons of niche hardware that just can't be driven from Linux.
If you use a computer for actual industrial work, you will hit one of these problems very quickly.
> there's tons of niche hardware that just can't be driven from Linux.
Linux developers can often do wonders, but they still do not have a crystal ball. If that hardware is niche+closed+expensive I don't see how they can produce working drivers or software. Manufacturers not releasing documentation are the problem, not Linux, or BSD or any other non supported OS.
Games are the most reliable category of software, the one WINE targets the hardest. Almost every software I try that isn't a game, fails to work in some way.
The worst offenders are "industry standard" software. 3ds Max. Ableton. Photoshop. Altium. MS Office. Visual Studio. Go check WineDB and see how many versions of these are rated "Garbage".
I say again - if you attempt to rely on WINE to do real industrial work on Linux using Windows tools, you are virtually guaranteed to hit a showstopper somewhere almost immediately. It's just not viable.
I'd argue the success of the Steam Deck is evidence of the Linux desktop's maturity. The normal game UI is just another Wayland session, and it's a fully functional PC running Arch Linux. KDE is installed and easily accessible.
I'd say the success of the Steam Deck is a testament to the maturity of the Windows API[0]. Old enough and reliable enough that it is a better target for games on Linux than Linux Desktop's own shit show.
[0] and of course the efforts of the WINE project and proton.
There's a lot of good aspects of Windows. The NT kernel is actually really good, the driver model is largely user mode, it had application-specific sound mixing, PowerShell is really good, etc.
Having a lot of user mode stuff does tickle my fancy, being someone who is very keen on microkernels (despite windows being a hybrid), I can appreciste some of their design choices.
I had to chattr +i /etc/resolv.conf because my resolv.conf would keep getting truncated (as in empty) every time I restarted an lxd container. Rock solid my ass.
Maybe I'm wrong, but that just seems to show that if you want to resolve lxd domains (hostnames?), you need to inform systemd-resolved to ask lxd for those domains, which is... sensible?
> you should notify resolved of the domains that LXD can resolve
You'd have the same issues if you replaced systemd-resolved with e.g. dnsmasq. Split DNS always needs resolver configuration.
I think it's just someone unhappy that they used to be able to edit resolve.conf before systemd-resolved took it over. I recall being annoyed about it as well, but that was some time ago.
I keep wondering about this year of the Linux Desktop. So often I see it used as a snide towards Linux users (not by you). I think it shows naivety.
What does it mean? Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable.
Or does it mean that Linux for overtake the market share of Windows and macOS. For that I would caution to be careful about what you wish for. Being an underdog brings an added benefit of having more flexibility and the option to think outside of the box. For Linux to overtake Windows it would slowly turn into Windows itself in my opinion.
> Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable.
Damning with faint praise. The success of Linux gaming is due to the efforts of projects that re-implement Windows APIs, and things moving to the web are obviously not targeting Linux either.
- Its a "big" for small docker containers (which is part of why a lot of people like Alpine Linux).
- It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script.
- the binaries are all a lot bigger in terms if SLOC and in terms of storage space than the solutions they replace. This makes auditing the code more of a chore and is a big argument against it in certain security environments.
- (my main gripe) systemd produces vendor lock-in from seemingly unrelated apps. A lot of packages which indirectly depend on a systemd functionality need to be patched to work on OpenRC Gentoo, for example.
Some arguments for systemd:
- systemd abstracts process management. This can be fantastic for scripting and security (again, context dependent)
- systemd by default kills services on log out (which is great for desktop - but can be an obstacle for servers). This is a good default behavior from a security perspective.
- systemd has some parallelization of init, making start up more predictable (because something falling over is less likely to nuke the whole procedure - again good for desktop)
- systemd provides a lot of tooling to stop you doing things the "wrong" way. For example, systemd-analyze-security provides configuration tips to harden your system
==========
In general, I would say that systemd is a very impressive tool and helped a lot of distributions standardise how they handle boot. I wish it did not impact downstream development the way it does though.
> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script
I never really understood this point — it’s not some proprietary format that has to be reverse engineered, you quite literally has both encrypt and decrypt source code available for every single version it has been released. You can also just pipe the binary output through the provided “decrypt” tool and then further use the usual unix tools if you wish.
But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before.
> But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before.
From what I've seen using Alpine Linux for a few weeks on my Raspberry Pi, logs are written to /var/log/messages after the init process starts and launches the logging service. All logs before the init starts can be retrieved using dmesg? I'm not sure about this though, let me know if I'm wrong.
One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since).
>One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since).
I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics.
> I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics.
I can grep my way through text logs as well but being able to get logs for different purposes using --flags is better user experience. I can always resort to to using grep, sed, and awk if I want to when using journald but the loss of these quality of life features make it hard for me to consider using a distro that does not have systemd.
It’s even more difficult to understand when you consider than text files are themselves binary logs and given how many encoding they can have they are not even trivial ones.
People should just call systemd logs structured rather than binary because that’s what they are. Sure it means you need a shim if you want to view them as plain text but it’s not like we are talking about some unfathomable complexity here.
And you don't need journald to read the log files either, you can use `journalctl --file /path/to/file.journal` to read them directly via `journalctl`.
I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important.
Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.
There are solid technical reasons for systemd's binary logging.
The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones.
Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can help guard against log tampering.
Being able to boot a server with a 'live USB image'; mount root, and inspect the logs to see what happened are not possible when you got a binary blob for a log. When things have really fucked up, you need the 'ease of access that plain-text log files provides.
If your live USB image is from this decade, it will almost certainly come with journald for reading the logs. If it doesn't, why choose such a bad live USB image?
Just nitpicking, but AFAIK it's not journald which is used to read the logs, it's journalctl itself which directly reads the binary logs from the filesystem (and the normal filesystem ACL permissions are used to allow or deny reading the logs).
How do you do that? If you want non-binary logs, you can have journald tee log records to rsyslog; but the canonical log is still the binary log. Have I missed something?
Systemd will produce logs in its own structured representation and write them straight away as plain text in the logger of your choice. For all intent and purpose, you now have text logs.
What I meant by "canonical" is that you can't get rid of the binary log; you can pipe it into a database, or a textfile, or /dev/null, if you want, but that database or textfile is transcoded copy of the binary log.
Every log ever is a transcodification of a system state. What difference does it actually make that it is emitted into systemd structured format before being put into your logger?
Seems like a pointless complain to me. It’s arguing for the sake of it.
That's not true, you can configure journald to be in-memory only in which case there's no binary log, no file. If your using systems, you can't really git rid of journald, but you can get rid of the binary logs.
It's unusual, but there are occasionally times when it's nice to run multiple processes in one container, and a proper service manager would be useful. Usually I see supervisord used for that kind of thing in practice.
nohup is POSIX, systemd is decidedly not. That makes it systemd’s responsibility not to break nohup, and more generally not to require non-admin users to be aware of it.
Nohup is a disgusting hack from a previous century. I don’t see how having less information on what is happening to a process good — nohup interprets supposedly meaningful signals never meant for this misuse differently.
If you want to continue to run a process you have to start a service which is exactly that.
No, I don't have to do that at all, I can in fact use the standard unix way of making a process not terminate on SIGHUP by telling it to ignore SIGHUP.
SIGHUP is not a signal to shut down, it's a signal that says the controlling terminal is gone. The action taken by the process at that point is the decision of the process and the user that launched it, not the init system. This is exactly what it is for.
Changing that without understanding what people used it for across UNIX vendors for decades, was dumb. And it showed off just how little the writers of the service knew about how users actually use their systems. Huge red flag.
It's not just random long-running batch jobs it killed either, it seems that it would kill all sorts of useful stuff people run for reliability. The irony of the init system killing screen/tmux sessions which people run specifically to keep their shell going in case of a disconnect!
>And it showed off just how little the writers of the service knew about how users actually use their systems. Huge red flag.
Why do you assume they didn't know about this quite basic mechanism? They added 2 configuration options, one at compile time (to set the default) and another configurable by the user. In fact, distro maintainers didn't look up what it did and they just compiled it as is, resulting in the surprising behavior of killing lingering processes.
Also, it is an init and service management system and long-running processes are services. If you want to run something for "reliability" you should create a service for it, or just run the command with "systemd-run", to properly communicate with the responsible process manager what it supposed to do when the user logs out (and to actually make it reliable, e.g. you can then set it to auto-restart on failure, etc) Safely killing lingering processes and cleaning up after them is the correct default behavior, so systemd just tries to enforce that - they actually communicated with nohup maintainers to optionally add this systemd communication, so that "nohup whatever" would still work, but they were not open to it.
Even then, the default broke decades of standard behaviour so systemd failed users here.
> long-running processes are services.
Not all of them. A data processing/computation job running for tens or hundreds of hours is usually not a service. What is "long-running" anyway? Again, people used nohup for running their jobs for decades without being logged in. That is the standard usage of nohup, systemd broke it.
It might be the “correct” behaviour under systemd, it was not the correct behaviour under multiple other unix systems for decades, nor was it the expectation of Linux users or admins.
Paint it how you like, systemd broke decades-old, desirable behaviour for no good reason.
The attitude that everyone else is clearly wrong is unhelpful, and seems a red hat pathology. You see it with this and with Gnome, and it drives people away.
and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost.
systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end users shouldn’t need to talk to init.
Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session.
> The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session.
That was proposed to nohup when systemd introduced the modification. It’s what nohup does on macOS.
A very productive discussion was happening but then the anti-systemd mob showed up with pitchforks, brigaded the discussion on the bug tracker and made sure nothing good would come out of it.
That’s when I personally decided Linux was a lost cause and definitely switched to macOS.
> I personally decided Linux was a lost cause and definitely switched to macOS.
That is an strange course of action. So because you saw some low quality discussion on the internet, you switched from free software you can influence to commercial one you can't?
I don’t care about having this kind of influence. These are tools. I want the tools I use to be good so I buy good tools.
It’s not about low quality discussion. A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices.
> I want the tools I use to be good so I buy good tools
Right, good strategy.
> A significant part of the Linux community seems to me to be deeply toxic and that leads to what I consider to be suboptimal technical choices.
Do you mean toxic users influence some developers to make bad decisions? Any examples? Toxic users dumping on systemd may be one, but I don't think they have that much impact, systemd seems pretty successful in not giving away. Anyway systemd is a very specific case, this is not representative of all linux software projects.
I’m guessing you don’t mean setsid(2), but when you say “seat and/or session management,” what does that mean concretly? Why should init be involved instead of something under the user’s control?
How is systemd not under the user’s control? It is an init and service management system and long-running processes are services. Where else should it be managed? Systemd is the only component that knows whether you are logged in/out, whether you still have another seat open, etc. And its responsibility is to properly close resources, and not let unannounced processes to linger needlessly in the background.
systemd is usually a root process, regular user does not control it. Whether user being logged off means no such user processes should run is a policy question that has different answer on different systems and depends on the user as well. Systemd "unified solution" - killing user processes on logout - is not working well for many people especially on shared machines.
init belongs to root. Only sysadmins can choose it (or not) and configure it, so only they should have reasons to interact with it or understand its UI.
systemd-logind(1) manages user sessions. If you want to replicate the functionality of what “nohup” used to give you, I am reliably informed that “systemd-run --scope --user $command” does the right thing. Or, you can enable it permanently for your user with “loginctl enable-linger”.
When I see “manages user sessions,” I don’t know what that phrase means. What is a “session” (again assuming not a POSIX session leader) and what are we concretely doing to “manage” it?
Is there a guide that explains the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years? I would never expect a non-sysadmin to have read the “systemd-run” or “loginctl” manpages or know how to find them. I’m a nerd and even I don’t know how to get to the point of understanding what https://man7.org/linux/man-pages/man1/systemd-run.1.html is trying to tell me.
> the bare minimum that typical end users need to know to stop systemd from breaking use cases that have worked for years?
That is bound to be a losing strategy. Systemd development (of breaking changes) is not stopping anytime soon. The simplest solution is to switch to an OS without systemd, like Devuan or Alpine or BSD.
I mentioned systemd-logind. Its manual page systemd-logind(8) states¹: “See sd-login(3)² for information about the basic concepts of logind such as users, sessions and seats.”.
Systemd does a lot of good but they like to move fast and break things. Making tmpdir per process, their homedir changes etc are all good for security but tend to break things in unexpected ways
Today you still have this functionality as an unprivileged user via systemd --user units in .config. Unlike nohup you get proper logging and processes can even restart automatically on reboot if you want.
I've developed a distrust for anyone who hates on systemd in 2022, especially if their rationale is vague dogma like "it does more than 1 thing, it's not Unix-like!"
It's usually a signal that the person is not a practioner.
Systemd is the most important and well-developed Linux framework, besides the Linux kernel itself.
I don't trust anyone's opinion, for or against, unless they've used alternatives. I've used systemd, I'll probably use it again, and I'll keep hating on it if someone gets me started. Fortunately on my own systems I've been a happy OpenRC user instead.
I've used both (OpenRC and systemd). I like the simplicity of OpenRC and still uses it on a few servers running on Gentoo, but on a laptop/desktop I think systemd is a better fit, having user services with user level logging for example.
Feigned certainty is often a indication of the opposite. In many cases people just absorb someone else's opinion on topics just in an effort to feel informed.
I'm not going to say I'm never guilty of it myself, but often asking even for the slightest bit of further explanation collapses that or otherwise just leads to repetition.
I mean have you actually used the alternatives? I find most of the people with that opinion are young pups who jumped on the linux train after most of the systemd bugs have been ironed out, but who still have zero experience with the alternatives.
I have used all the alternatives, and written my own init systems from 0.
Systemd is really well designed and makes Linux workstation use predictable and more secure across distros in numerous ways. You can have any service you want now, even xorg/ wayland, as an unprivileged user. It basically removes all need to use root if used correctly.
Systemd however is however not designed for server use, but neither is OpenRC or any of the alternatives. Servers filesystems should contain a kernel, a shim init binary, and a static binary for a target service.
When you want to upgrade your fleet you compile a new bundle of those three things into a new filesystem image and boot servers from the new image.
> Systemd is really well designed and makes Linux workstation use predictable and more secure across distros in numerous ways. You can have any service you want now, even xorg/ wayland, as an unprivileged user. It basically removes all need to use root if used correctly.
It sometimes randomly fails to boot, waiting for some strange condition, while I am not able to intervene via keyboard in any way. That is "well designed"?
I run Xorg as unprivileged user by executing startx, on sysvinit system. There is no problem that needs systemd solution here.
I mean it's pretty hard to debate the merits of systemd as a server init system when you think we should all be using come kind of containerization system :p
The Linux kernel is simply not designed to run trusted code and untrusted code at the same time. One service has a bug or a security flaw and everything goes down with it.
The sandboxing is a convoluted mess few even know where to start learning to use. Lets say you successfully configure process namespacing, network namespacing, filesystem namespacing, cgroups, and apparmor or selinux all correctly to restrict every last syscall. You will still get burned by a crash, resource exhaustion, or security breach due to the next of a long series of implementation bugs in each of these arcane features.
Humans cannot create a large codebase of coherent and provably correct C code with memory safety and they really should stop trying.
Hypervisors are the only sandbox that works reasonably well and burning some extra ram is cheaper than most security breaches.
On my laptop, systemd is awesome; I love it. Everything works together nicely.
On my servers, systemd gets in my way, tries to do too many things, and gets in my way more then it helps.
On a laptop things are much more dynamic. From sleep/hibernation/wifi-LAN-wifi (+/- VPN) switching/etc.... these fiddly bits were much harder to manage on Linux for DECADES then they are now. The reboot interval on laptops is huge compared to servers. An init system (plus all the extra plumbing) work well together.
On servers however; I HATE systemd. For logging, networking (and DNS) alone systemd wastes so much more of my time and gets in my way. I think the need for an 'improved' init system was always a red herring. I've never had a service race-condition, or other conflict that didn't take more then 10 minutes to fix in the 30 years I've managed *nix servers.
There was one time where I was stumped why my VPN server kept failing to start at boot but came up fine if I restarted manually. My dyslexic ass inverted the script number (ie. 13 instead of 31 or something like that). That was just a face-palm embarrassment.
Systemd should never be used on a server. Or any other desktop init system for that matter.
Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations.
A production filesystem should contain a kernel, an init binary, and either a container runtime or a static binary of your target application. At most a production init binary just needs to setup virtual filesystems and be a reaper for a target application binary.
> Production systems should never be changed or administered in place, only replaced. Servers should be immutable appliances. They do not need a package manager, or systemd, or ssh, or even a shell. Such things are developer tools and only belong in development environments like workstations.
That is a very restrictive work methodology (unikernels,exokernels). Although interesting and certainly useful in some cases (high security, rare updates), Bryan Cantrill was partially right on this - in the real world, we often need to debug stuff running in production and support paying customers who require that. Your idea of "production systems" and "servers" seems very specific and the "should" statements are often not true in practice.
Developer tools definitely belong on the server too, you need them to determine how to build your stack binaries in the best way for the OS and HW architecture there and keep them updated and secure.
If it was generally hated there would be a lot more support for the distros that don't have systemd. There isn't. Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year. Even alpine is kinda niche, it's mostly used as a way to make lightweight docker containers, rather than as a distro that stands on its own, the fact it uses musl as its libc means you can't use it on a server that has nvidia gpus for machine learning, you can't use it on a desktop where you need a browser capable of DRM, you can't use it on a personal computer if you ever intend to install a video game etc.
I have -yet- to hear anyone in my life actually use something like Devuan, the systemd-less fork of Debian, in a production environment.
Six years after their first release, instead of standing on their own as a distribution, they're still deeply angry and obsessed with systemd and this is the level of professionalism they exhibit on social media :
https://twitter.com/DevuanOrg/status/1586963662295687169
Of course, one of the twitter comments underneath is "systemd macht frei".
I think that is an overstatement. I use systemd but there is legitimate criticism and even a questionable conflict of interest in the creator now working for the competition. People working against the best interest of the community is a real threat that shouldn't simply be ignored. However, so far systemd has worked out alright for me so I can't complain too much but the documentation is still lacking in certain areas and so doing things that are easy to understand with a traditional script based RC can become frustrating when you are trying to figure out the systemd-way to do things.
Microsoft hasn't been the competition for while. They might not be "part of the team", but they definitely have more to win by linux being alive than dead. I'd put them more along the lines of IBM or Oracle, huge corps trying to somewhat discreetly steer linux in a path that suits them.
Impressive. They have even a document that describes the problems with systemd. And not just any document, it's the most viewed research thesis of all time! Wow!
The Devuan founder is truly the most impressive person in the universe.
>Except for alpine, all of them are extremely niche, half of them are dead, the other half barely have enough people to stick around for a release a year.
Void Linux doesn't use systemd because it doesn't build against musl libc. Void ships musl and glibc packages for multiple CPU architectures and has a very lively development team and update cycle. It's not dead, it's just not insanely huge, either.
It started with bad press because author made pulseaudio and its design didn't appeal to many (lots of features but missing pieces, not due to dev but market forces and drivers). So when the same guy says he's gonna rewrite pid1 with a radically different design people went ballistic.
My personal opinion is that proper dependency based init systems are amazing but I'm not fond of some slightly superficial aspect of systemd (syntax, parameters, logic, config files).. to the point I think in a few years someone may make a cleaner variant.
It’s not generally hated. It has a cadre of permacritics that are very vocal and often dramatic, and some of them often pop up in threads such as this one, that is all. It’s especially pathological since there are alternatives - if you hate Lennart, Redhat or whatever, use something else and move on.
Meanwhile millions are using it to get shit done without much drama. It’s been years since I filed a bug on systemd, but that’s what grown ups do when inevitable bugs are encountered, not make themselves and everyone miserable because they deeply integrated some dubious 1970s Unix philosophy into their personality.
A couple years ago, absolutely. To decide whether to generally hate systemd, and with what intensity, you should follow a curve that decreases proportionally with how long ago the change was made, and that starts as high as the multiplication of how much churn it causes times how old the thing it replaced was, all of which is of course multiplied again against the buggyness curve
When pipewire replaced pulse, despite pulse being well established and a core desktop component, there was very little churn and few bugs. People not impacted did not mind at all that a major component was changed, or that it did many things and bundled three completely different protocols into one, arguably not very reminiscent of Unix Philosophy™
I would confidently predict that a change as large as systemd, to a component as old, and that causes as much churn (rewriting, relearning) would follow a roughly similar hate curve, only distinguishing itself by whether it was more buggy or less buggy than the predecessor.
It's churn people hate, not change. The lesson I learned is that you can make large changes to the system, it's only hated when it forces humans changes.
It's worth remembering that much of the churn was caused not by having to rewrite configuration, but by the multitude of bugs that plagued systemd early on, and the way they were treated did not help. systemd upstream was extremely difficult to work with and made a lot of people reluctant to embrace change, because when something didn't work -- which we all understood was natural for software developed in the open -- you were pretty much screwed. Shell scripts and duct tape were bad but it could take less time to fix something than it took to get people "up there" to admit that they're really looking at a bug, not a feature.
I ran systemd very early on because it gave me some things I liked from SMF but I completely understand why so many people hated it. It's a (suite of) program(s) with good ideas that was hampered by extremely poor maintainership and relation with other open source projects.
Pipewire broke me lots of times during its development and rollout, and that's okay, because new software has bugs and in some of my other use cases "hey it's a lot better than Jack". What I'm not going to do is carry a grudge against the maintainer for decades?
I've been using Linux since Slackware installed from a pile of floppy disks. I'm extremely happy with systemd (desktop and server) and view it as one of the most important UX advancements ever made in the Linux sysadmin space. It replaced a smorgasbord of broken nonsense with a unified and thoughtful system that is objectively superior to what it replaced. I suspect a lot of the extreme reaction to systemd is not just resistance to change, but based on an emotional attachment to the rag-tag heterogeneity it made obsolete.
Hehe, I remember some people complaining about it. I never could hate SystemD once introduced to it as an infrastructure engineer. The difference was night and day in Debian (from wheezy to jessie).
Setting common sig handlers, restart on exit, etc. are just one-liners with unit files. In the previous one, SysV, it was an annoying incantation especially if you were a newbie, like me at the time, or product engineer who was dabbling. You could easily screw it up. Some non infra engineers cursed the SysV files and loved the SystemD unit files.
Now I use dynamic user and the other security features in my unit files and wonder how many lines it would have taken to do that in SysV, so the complaints are laughable at this point.
Less hated ad time goes on. I still think it's architecturally stupid (look at openrc for something that accomplishes similar goals but better), but it's been a while since it's broken anything terribly for me, or introduced any terrible security vulnerability. It's not great, but it's not actively hurting.
I was sold after a single session of writing a couple of dependent services. Logging, retries, cleanup. Everything was so ridiculously straightforward, rather than a bunch of bash hacks and lock files.
I have trouble believing that people who loath it so much have actually sat down to read the documentation.
But I almost never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora. Without systemd, bootstrapping a complicated desktop environment would be a hot mess.
Well, maybe you would say Alpine is not intented to run heavyweight stuff like that and is mostly focused on security and containers.
That's exactly what Alpine is, the OpenBSD of Linux distros. OpenBSD likewise cannot be used as your production powerhouse as well.
>never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora
Alpine runs musl libc. This makes it buggy with all sorts of software that rely on glibc-isms, that makes it incompatible with proprietary drivers like NVIDIA and make it harder to run proprietary/binary software on the userland.
Bad argument, glibc and musl are not always compatible, and you can use that as argument against either. When it comes to standards, musl is actually the more conformant one.
The glibc 2.26 release with the ucontext breakages made me stick with musl.
Plus, when i did multiarch support in Alpine later, i found that LDSO paths for musl are much more systematically and don't have name collisions like glibc.
There are some very unfortunate ideological choice made by its author but they are not the one you quote. The reluctance to give developers a way to detect Musl from C code would be a better exemple. It’s both annoying and counterproductive.
> Without systemd, bootstrapping a complicated desktop environment would be a hot mess
What is a complicated desktop environment? Why should I run it? I want to run simple desktop environment, like Xfce. I run startx in tty, and get unprivileged Xorg with Xfce on sysvinit system. It's rock solid.
alpine linux is a minimalist distro intended for running a single process within a container. I guarantee the base OS the container is running on us running systemD.
No: "Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency."
who out there is using alpine as their daily driver desktop? the only time I've ever seen it used is as the base image for docker containers precisely because its so minimal (ie: lower attack surface area)
I've started managing my user services using systemd --user and portable services and it's just amazing how well the individual components work together to create fully isolated, containerized, per-user services.
I'm lovin' it and I'm not missing the hot mess of the dozens of shell scripts that I needed before.
What kind of user services and "portable services" are you managing? I have trouble imagining what that means. User pulseaudio daemon on your laptop/desktop? Or some server services for many clients?
In short it allows you to bundle your application in one file and have it run in a sandbox. Like a docker container, but without docker, managed by systemd.
User services are also a systemd thing; you can create systemd unit files (service descriptions) and have them run as a user. So as a user you can manage your own running processes using the same systemctl interface as system processes. If you are allowed to "linger" on a system, you can run user processes as a service, set them up and tear them down without root permissions.
I have several systems where I run i.e. webservices without having full root access. I build an portable systems image, deploy it to the server and then can manage that service with my unprivileged user account.
Systemd does all the usual things, like logging, supervision, resource quotas, and so on.
Right now my mom is nagging me to fix her Ubuntu laptop, which doesn't shutdown anymore because some of the units got messed up. I'm at the verge of telling her to install windows.
That is a really simple fix. Sounds like one of the units is hanging. This actually shouldn't prevent shutdown but may make it hang for like 2 minutes.
