Systemd 252

https://github.com/systemd/systemd/releases/tag/v252

by rascul • 4 years ago

103 302 4 years ago

boncho• 4 years ago

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.

europeanguy• 4 years ago

I'm not a Linux expert, but I thought that systemd was generally hated?

tkuraku• 4 years ago

Seems pretty great to me. Never understood the hate.

zargon• 4 years ago

bedrock of delight

It might be sarcasm?

plaguepilled3• 4 years ago

I would say it really depends on the context!

Some reasons systemd is bad:

- 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.

grepLeigh2• 4 years ago

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.

oconnor663• 4 years ago

It's one of those things where people who hate it talk a lot about that, but people who like it don't have much to say.

fuckstick• 4 years ago

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.

ruuda• 4 years ago

There are two types of software: those that everybody complains about, and those that nobody uses.

otabdeveloper4• 4 years ago

Yes, it's so hated that it's impossble to find a Linux system that doesn't use it.

HNDV3• 4 years ago

thought that systemd was generally hated?

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".

One of the things the official devuan account retweets : https://twitter.com/jaromil/status/1544618996833583104 "It's 2022 and the master of systemd is now working for Micro$oft https://phoronix.com/scan.php?page=news_item&px=Lennart-Poet... this the last bit @phoronix omits. This is a classic cybernetic strategy: to become the master of a feedback loop you create and continuously adjust the framework in which nodes interact."

I think that says enough about the sort of irrational people we're dealing with?

People who hate systemd are very, very vocal, and highly unproductive.

terom• 4 years ago

By a vocal minority.

agumonkey• 4 years ago

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.

esarbe7• 4 years ago

From my experience this was never much more than a very vocal minority.

tux3• 4 years ago

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.

UI_at_80x244• 4 years ago

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.

excsn• 4 years ago

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.

traverseda7• 4 years ago

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.

Scarbutt• 4 years ago

Alpine linux seems to be doing fine without systemd.

stevefan19992• 4 years ago

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.

cultofmetatron3• 4 years ago

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.

qbasic_forever• 4 years ago

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.

cat_plus_plus2• 4 years ago

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...

lrvick8• 4 years ago

You can run virtually any Windows application on top of Systemd already via Wine.

Unless you have some particular attachment to the NT kernel, there near zero reasons to use Windows today.

okasaki• 4 years ago

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.

boudin2• 4 years ago

lxd is not part of systemd.

Avamander2• 4 years ago

Why is lxd touching that file?

chris_wot• 4 years ago

How is that a systemd issue?

conradev• 4 years ago

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

tsujamin• 4 years ago

+1 for systemd-networkd too: it let me declaratively describe some netns/ipvlan interfacing the other day that netplan et al simply couldn't.

It could use with some more netns awareness but its pretty great at the current stage

Avamander2• 4 years ago

You can still let netplan use systemd-networkd as the renderer, though in some cases some overrides are necessary.

normaler• 4 years ago

systemd-networked + systemd-resolved is also really awesome.

It lets you configure DNS Server per link and resolve only certain domains via a specific DNS Server configured from a link.

e.g. multiple customer specific wireguard Tunnels that resolve the specific project related domains, but dont resolve all your other DNS.

blueflow6• 4 years ago

"rock-solid".

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.

encryptluks23• 4 years ago

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.

esarbe7• 4 years ago

Absolutely.

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.

effie20• 4 years ago

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?

pluijzer• 4 years ago

...the year of the Linux Desktop

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.

AnIdiotOnTheNet3• 4 years ago

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.

tapoxi• 4 years ago

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.

AnIdiotOnTheNet3• 4 years ago

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.

fullstop3• 4 years ago

It's also worth mentioning that the Steam Deck uses systemd as well.

KingOfCoders2• 4 years ago

I love systemd for deploying Golang, especially the security features, that systemd can own the TCP port for zero downtime deployments of the application and restarts of a fail-fast application. It kind of replaced Docker (dockerd) which I've used with deploying Scala and TS.

xdfgh11125• 4 years ago

Hey, someone rediscovered xinetd

klodolph2• 4 years ago

I remember using xinetd, and while xinetd does do the job… sometimes… systemd is much more comprehensive, so you don’t need to fuss about with different configs for xinetd, cron, init.d, etc. This is especially nice since the number of config options has skyrocketed, so systemd really simplifies administration (in my experience, at least).

oblio• 4 years ago

Hey, someone rediscovered xinetd

1. http://0pointer.de/blog/projects/systemd.html

Replacing inetd was a systemd design goal.

2. Snark for someone learning is a bad move.

athrun• 4 years ago

It's challenging to restart a service without dropping connections with xinetd.

Even more so when the process is misbehaving, has children, and is not exiting cleanly.

KingOfCoders2• 4 years ago

Isn't it astonishing? I've been using Linux pre-Slackware with downloading boot.tgz and root.tgz on two floppy drives, wrestled with M4 and sendmail, have been writing internet applications for 35+ years but never used a Linux daemon to manage my applications. You're never too old to learn I guess.

blueflow6• 4 years ago

I once won a backdoor contest by installing a systemd socket who launched /bin/sh as root. At this point, people don't question why systemd is being bound to some random ports.

vegai_• 4 years ago

Hey, someone rediscovered xinetd

With a much better piece of software, exactly.

mnutt• 4 years ago

It's great, you can have it launch multiple processes on the same port using SO_REUSEPORT. Normally it'd be a bit of a pain to health check multiple processes running on the same port without some other machinery since it is possible to get into a state where all but one process is hung. Systemd watchdog will provide your service with a socket and expect updates on a regular interval or else it will consider your service dead. This socket is also very handy for service startup, to have your process just notify systemd it is ready rather than having to poll to see if your process is listening yet.

b1125• 4 years ago

own the TCP port for zero downtime deployments of the

It's not zero downtime, if the app isn't reaponding. And any infra that cares about uptime, has redundant instances.

This feature is, IMO, a feel good feature.

dinosaurdynasty4• 4 years ago

It's zero downtime in that at no point does the kernel not respond to a TCP SYN packet and all those connections eventually get seen by the daemon. (Really useful for updating local services on Unix sockets.)

It's also much simpler than redundant instances, and applications are updated much more commonly than hardware failures so it's a cheap way to increase availability in practice.

And if your app can restart in a couple seconds... It might as well be zero downtime, and if not responding for a second is an issue, you have bigger issues.

shrubble2• 4 years ago

People who want to use it can use it.

I am thankful for the non-systemd distributions, which are listed at https://nosystemd.org ; just scroll down to the list if you want to skip the advocacy.

ohCh6zos• 4 years ago

I have absolutely fallen in love with FreeBSD after Debian and Arch stopped being what I wanted.

It feels closer to what I wanted than a proper Linux.

shrubble2• 4 years ago

I have found FreeBSD to be very coherent as a Unix; and the documentation is very well written. Jails, once understood, seem very good also, even if not perfect.

stopdropnhotpot2• 4 years ago

systemd is fine for single user systems and perhaps verts, but I would never deploy it on a server. The deprecation of cgroup v1 is a welcome change. It's come a long way, but it still has a very long way to go.

panick21_6• 4 years ago

Facebook runs lots of Systemd but I'm sure on your infrastructure you couldn't run it.

Dah00n• 4 years ago

Facebook is a Bad Example on stability at scale..

stopdropnhotpot2• 4 years ago

I imagine Facebook uses highly monitored virts that are spawned and destroyed constantly. I really wouldn't call them "servers" more like instances or staging hosts for containers. Root exploits aren't so serious in a ethereal state..

WhyNotHugo2• 4 years ago

Facebook also uses PHP. The fact that somebody made a huge service work with a specific tool doesn't automatically imply it's the best tool, or even a good tool.

cat_plus_plus2• 4 years ago

Is the project a new site sponsor or something? :-) I get it that systemd has some benefits - faster startup, more reliable production administration. And at the same time it's not everyone's cup of tea - for example, many believe that the strength of UNIX is many simple and interchangable commands rather than big monolithic code base controlled by a single team. Anyway, there have been 251 previous versions of systemd, so it's not clear to me why this one is special and deserving of our attention after another systemd related story yesterday?

panick21_6• 4 years ago

You do understand how Hacker News voting works?

twic2• 4 years ago

Yes. Clicks on the voting arrows go to the HN backend, which routes them to systemd-votecount, which then generates article rankings and publishes them over D-Bus, from which the backend picks them up and renders them as HTML.

Denvercoder9• 4 years ago

Anyway, there have been 251 previous versions of systemd

Trivia: when udev (which was at v182) was merged into the systemd project, they skipped from v44 to v183 to align the version numbers; so there have only been 112 previous versions of systemd.

Timja• 4 years ago

I despise systemd.

Having shell scripts that you can read and edit makes so much more sense.

Putting a script in a directory to have it run at startup makes sense. Systemd's approach of "registering a service" is hell.

Having logs in plain text is beautiful. Having to use special software to read logs is hell.

Octabrain• 4 years ago

You can still have your wonderful script but in the case of systemd, you delegate the execution lifecycle of that script to a unit, which, IMHO, is a great abstraction compared to the mess of having to deal with the status of the service from the script itself. You simply throw the unit file into directory, then enable it. Your script does its thing, systemd deals with when to run it, in which runlevel etc

About the logs, yes, plain text files, commands and pipes are great, but journalctl is really great too. It is powefull and includes everything you might need to inspect logs with accuracy in the same tool.

Just to clarify: I'm not a fanboy, I'm just pragmatic.

lakomen2• 4 years ago

journalctl is really great too

until you're forced to run a rescue system without systemd and try to read logs. And don't say that it doesn't happen, because that situation is 99%.

tenebrisalietum• 4 years ago

So I think systemd is becoming a tentacle demon upon Linux but "registering a service" is not hell.

- You create a new whatever.service text file with some data=value pairs and put it in /etc/systemd/system. Doing this is at least only 25% as hard as learning bash.

- systemctl daemon-reload

- systemctl start whatever.service

Not hard.

kosolam• 4 years ago

I use systemd and I like it. Because it works. Every question that pops up I can easily find the answer by googling.

teddyh4• 4 years ago

• At shutdown, systemd will now log about processes blocking unmounting of file systems.

Nice.

k_bx2• 4 years ago

I love systemd for everything except its cron replacement, somehow it's a real mess. Yet I desperately want something more modern to play with journald well. Any advice?

mariusor• 4 years ago

I think generally people view timers as a net superior alternative to crons: they have better logic for the times, they support dependencies, they support randomized delays, etc. Why do you think they're a real mess?

k_bx2• 4 years ago

I guess their UX for a simple cron-like use-case. I remember trying to set it up and it wasn't a great experience. Just trying to see if others agree or not.

esarbe7• 4 years ago

I concur with siblings suggestion of systemd timers. Works like a charm. Has jittering and nice tui.

loudmax• 4 years ago

Systemd timers are more complicated than cron, but there's a reason for the complexity. Once you've put in the extra effort to understand the logic, they're really powerful.

If you don't want the complexity, then just run crond.

gorgoiler3• 4 years ago

It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend.

How long until “Systemd: The Good Parts”?

*The most trivial new name would be système which would at least be in keeping with the French naming.

**In Debian stable if you create a new user, ssh in as that user, logout, then delete the user, you can’t because systemd is still running a detached housekeeping process as that user. If you wait a bit then the systemd process goes away but that, to me, makes it a worse bug not a better one.

HeckFeck• 4 years ago

It happened for PulseAudio, perhaps something compatible but leaner can emerge for systemd.

phoronixrly• 4 years ago

It happened to Pulse after the project stopped being a moving target. Just look at the changelog of this systemd release.

ciupicri• 4 years ago

From the logind.conf man page [1]:

KillUserProcesses=
Takes a boolean argument. Configures whether the processes of a user should be killed when the user logs out. If true, the scope unit corresponding to the session and all processes inside that scope will be terminated. If false, the scope is "abandoned", see systemd.scope(5), and processes are not killed. Defaults to "no", but see the options KillOnlyUsers= and KillExcludeUsers= below.
In addition to session processes, user process may run under the user manager unit user@.service. Depending on the linger settings, this may allow users to run processes independent of their login sessions. See the description of enable-linger in loginctl(1).
Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1).

[1] https://www.freedesktop.org/software/systemd/man/logind.conf...

gorgoiler3• 4 years ago

Ahhh, thanks. Now you mention it, wasn’t there some major scandal about this when it first shipped?

dark-star4• 4 years ago

Wait, what French naming?

seszett• 4 years ago

I don't know if it was intended, but "système D" in French means hacking together something with whatever you have available. D meaning "démerde" (literally getting out of shit or a shitty situation) or "débrouille" depending on the language registry you want.

It's a rather common expression.

mekoka• 4 years ago

"e" following "d" in the alphabet, the successor to systemd would be called "systeme", which is the french translation (système) for "system".

lotharcable2• 4 years ago

It feels like the time is ripe for something simpler and more modern to replace* systemd.

Well then do what Poettering did and write it.

It's threads like this why I am eternally grateful that Linux kernel uses a merit driven approach and not concessus driven one.

traverseda7• 4 years ago

Yeah, but Redhat has been slowly getting control of more of the infrastructure. Want to make your own? Well even if you make something backwards compatible with Gnome or udev, get popular and they will probably find some way to break your compatibility.

You end up needing to fork all the projects that Redhat has gotten their tentacles around.

kasabali• 4 years ago

Well then do what Poettering did and write it.

This is such a superficial and ignorant take I'm having hard time forcing myself to believe it was written in good faith.

Dozens of alternatives already exist. The problem isn't writing, problem is having politicial power Poettering had. (ie. He was employed by Red Hat and had close connections with other Freedesktop developers.)

Shorel2• 4 years ago

Ubuntu had the alternative software called Upstart.

It was killed because of the Red Had power behind Systemd.

Technically, I don't know which one is better, but politically, Systemd was a power move by Red Hat.

cies• 4 years ago

I expect there will be a system that is not necessarily less complex (as what systemd does IS quite complex); but is more:

* safe (uses Rust with unsafe)

* modular (systemd is pretty all-or-nothing)

* open access (less RedHat dominated)

Probably it will be using some of the same standards as systemd or at lease be BW compatible to some extend. Once Debian picks it up, it's game over systemd.

PetitSasquatch2• 4 years ago

Don't we already have multiple, alternate systems that are significantly simpler?

The primary reason why I don't use systemd at all, on any desktop or server I manage, is not that I think it isn't powerful or reliable but, I cannot fit it into my head.

The scope and complexity of it goes beyond what I'm personally willing to invest into any one subsystem designed to regulate my operating system.

I find that because I can't easily integrate day to day systemd operations into my general knowledge of the Unix / Linux shell environment, it essentially creates a cognitive switching cost that I'm not willing to pay given the efficiency and utility I get from my existing knowledge and skills.

Systemd seems to work well for a lot of people, but doesn't sell itself to me given my objective, and capacity, to internalize simpler tools for high levels of mastery.

That's why I don't use systemd but do use other, more simpler systems, that are readily available.

rainbow2982213• 4 years ago

You don't have to fit anything in your head. I often find myself consulting the index at `man systemd.directives` to remember things: https://www.freedesktop.org/software/systemd/man/systemd.dir...

In lot of cases I've found systemd units much to actually be simpler and easier to maintain due to everything being in a simple declarative format. The old alternative is to have a lot of shell scripts that can get very complex, and to consult another few hundred man pages for various shell utilities...

stevefan19992• 4 years ago

I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.

twic2• 4 years ago

I think it's because there were other alternatives that solved the same important problems, while being much simpler and less intrusive.

lakomen2• 4 years ago

The arrogance of Lennart has something to do with it. The way he tends to disregard real bugs as not a bug, since he and his production are perfect and always right. Numerous cases of that. Then the security aspect of a jack of all trades process running as one that controls every other process. Reading logs after a panic and rebooting to check them is a pain in the ass without journald on the chrooting system, reading and parsing logs the same.

There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft.

The above doesn't represent my personal opinion, it's a representation of what reasons people might have.

TacticalCoder• 4 years ago

There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft.

I only learned about that a few days ago, here on HN (some thread or some old comment).

It is completely insane and gives lots of fuel to the systemd haters.

I do run both Debian (systemd) and Devuan (a Debian fork with all the systemd stuff removed). I use Devuan on my main desktop PC and I've got exactly zero problem.

That's the thing: many "sell" systemd as some mandatory machinery but it simply ain't. Ultra-light containers (like Alpine-based ones) run fine (and faster) without systemd. Desktops do run fine without systemd (I'm running Devuan on my workstation and Debian on my laptop: it's basically the same experience). For certain types of servers I can understand some see benefits in running systemd.

Neither IBM / Red Hat nor Microsoft should be those setting the terms of what is or is not an acceptable "PID 1" for Linux.

The day Linux becomes "systemd Linux" is the day I'll switch to a BSD.

I don't mind that systemd exists as long as people still have the choice to run a non-systemd Linux. The kernel should be orthogonal to systemd and there should be Linux distros packaged without systemd.

And systemd proponents shouldn't go out of their way to try to prevent non systemd Linux from existing.

rfmoz3• 4 years ago

About the bugs, the Github have 1.8k issues open.

That makes me think, is there a way to know what are the projects with more open issues on Github?

denton-scratch6• 4 years ago

who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft.

Woah, I missed that news! I don't imagine he'll stop writing Linux software though.

WastingMyTime897• 4 years ago

Numerous cases of that.

Like when? Because I have interacted with projects where Lennart is part of the admin team and from where I stand it’s all in your head.

Both bugs and security are taken seriously.

The above doesn't represent my personal opinion, it's a representation of what reasons people might have.

I admire the courage you display in standing for your opinion.

lotharcable2• 4 years ago

There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft.

Yeah, well... Microsoft is probably soon to be one of the bigger Linux developers out there. As the profit slowly drains out of the desktop their core business model is going to be increasingly dependent on open source and Linux.

Just in case anybody reading this is a big fanboy of Linux... This is what winning feels like.

VLM• 4 years ago

Systemd is a somewhat successful non-unix operating system, marketed to people who want a unix-like operating system using force. This isn't what anyone wants but you'll go along or they'll unleash a hell of sophistry about how this is "really" what everyone wants even if its the opposite, made up stories about the opponents, or only bad people don't want what we want and you don't want to be tagged as one of the bad people so you're gonna say you officially love systemd, correct?

It would be like going to the EV car dealership and being told the best modern EV they sell is a diesel pickup truck and they will unleash sophistry hell on anyone who doesn't go along with their meme that the best modern EV is obviously a diesel pickup truck but pointing that out in public is doubleplus ungood badthink.

Ironically, for a non-unix-like operating system, its not that bad and works some of the time, although not as well as a unix-like OS would work for someone who's engineering criteria is a unix-like OS. Most people would be technically better off with a unix-like OS than a systemd based OS, but thats not what the corporate marketing department is selling, so we all love systemd, uh huh.

traverseda7• 4 years ago

and you don't want to be tagged as one of the bad people so you're gonna say you officially love systemd, correct?

That does seem to be like weirdly a thing with redhat projects. I once saw someone say that being anti-systemd was correlated with supporting trump on hackernews, and of course if you don't like gnome you hate accessibility and poor people (who apparently don't know how to use less hobbled/phone-like user interfaces).

esarbe7• 4 years ago

Rubbish.

Linux+GNU is either a Unix operating system or it is not. Having systemd on board changes exactly nothing, since there never was a system services interface anyway. Files in a directory you say? That's not an interface, it's a recipe for failure. Or why do you think that every distribution used to ship their own init scripts?

You EV car dealership is awfully flawed, especially with Linux+GNU you can even build you own car. So why are you complaining? Nobody is forcing you to use a distro with systemd. Nobody can force you. You're not a victim, you're privileged.

systemd is for the first time providing Linux+GNU with a sane system services management and finally gets it ahead of OSX or windows in terms of capability. Instead of unconstrained bash scripts (that require ridiculous template magic or fail for the first edge case) you need only a ten line service description that does things that an init script would not been able to deliver. Like the most basic thing ever; reliable restart. The amount of hacks that were necessary to get an init script to only semi-reliably restart are atrocious - and deamontools are just the beginning.

I've come to understand that the dislike of systemd has less to do with the technology at hand but more with human nature.

cptnapalm• 4 years ago

While systemd does have many good features, it also has failed to turn computers off on various systems and distros. I repeat: failed to turn computers off. This wouldn't be acceptable in beta quality software. But it's systemd and for whatever reason gets a free pass on failure to do incredibly basic things.

VancouverMan• 4 years ago

It's quite simple: many people had atrocious experiences with systemd.

Systemd ruined Debian for me, for example.

I'd been using Debian testing for years and years, on multiple systems. Despite its name, I'd always found Debian testing to be more reliable than the stable releases of other major distros.

When performing updates and upgrades during those many years of using Debian testing, I had only ever experienced trivial issues that I could easily resolve, usually just on my own with a few minutes of investigation.

Then systemd was forced onto Debian's users.

As soon as it ended up on one of my systems, the problems started. That very first update left my computer unable to boot. That was the first time in over a decade of using Debian that that'd happened. I also remember it taking far too long to diagnose and resolve whatever that initial problem was.

Subsequent updates involving systemd just caused me more and more problems. They usually weren't minor issues, either. They'd significantly impact the usability of my installation.

To make matters worse, I, as a user, didn't see systemd even bringing me any benefits.

Eventually, I lost my ability to trust in Debian and its reliability, even for Debian stable once systemd eventually made it there.

Now I completely avoid Debian and other systemd-using Linux distros whenever I can.

effie20• 4 years ago

I recall part of the problem was that in some cases, Debian packagers/developers did not know how to integrate systemd with sysvinit properly, there were weird problematic constructions such as sysvinit scripts calling systemctl or vice versa and some breakage due to the way they used systemd. Of course, one could ask whether this was partly due to bad systemd documentation and unfulfilled expectations of promised systemd behavior.

mindslight• 4 years ago

I think it just has many details you can end up hating, so a person will inevitably run into one or two.

I myself don't have a problem with the monolithic thing that replaced sysv init scripts. While the definition of sysv init scripts was attractively simple, the resulting implementation was not. Wading through many lines of boilerplate shell that's mostly accidental complexity is not my idea of a good time.

But I do hate how systemd splays its config and dependency graph throughout hundreds of tiny files and symlinks in multiple directories (and .ini files at that!), and then insists that this is no problem because you can "just" learn some bespoke commands to analyze them for you. With my sysadmin hat on, I'd much rather have a unit be a single file in a single well known directory, that specifies only the service properties and no dependency information. And then have the dependencies orchestrated by a single logical top-level file that pulls those units in and defines what depends on what. In general if I'm going to customize a distribution-supplied config file, I'd much rather overwrite the distribution file and completely own it going forward, rather than having the distro file and my file merged with some arbitrary rules.

Having said that, I've moved many of my machines to NixOS where systemd is just another thing to be mitigated and nixified. The expected on-disk format doesn't matter, because it's all generated from a single logical config file and then splayed out however systemd wants. The nix config looks a bit verbose and wonky, but at least it's contained. But it also feels like it would be quite easy to switch out down the line...

forgotmypw175• 4 years ago

At the very top of this page, there are two features listed which will be removed in the future.

This means that anyone who relies on this feature is now tasked with all the extra work and cognitive load of finding replacements for those features, changing and testing their configuration, and the risk of deploying these changes.

To me, that is a "non-consensual" change, and I try to avoid any technology that has a history of these non-consensual changes, because I want my systems to run without extra maintenance.

sdgfdhdgj2• 4 years ago

To me, that is a "non-consensual" change, and I try to avoid any technology that has a history of these non-consensual changes, because I want my systems to run without extra maintenance.

Then stop using Linux. The Linux kernel replaces subsystems with different, incompatible subsystems all the time. For example packet filtering was once ipfwadm then ipchains followed by iptables and now nftables.

captainmuon2• 4 years ago

About removing support for what they call split-usr and unmerged-usr: Why does a init system and daemon manager even need suppport for a certain directory layout, shouldn't it be agnostic? Having a separate usr-space saved my bacon in the past a couple of times.

The thing I dislike most about Systemd is that it leads to homogenisation, where to me, running Linux is about choice.

Macha• 4 years ago

The kernel initramfs only mounts the root partition - parsing fstab and running mount is handled as part of init. This means that an init system needs to support split-usr by ensuring it can go without the contents of /usr at least long enough to bootstrap (which requires special treatment of the mounting scripts/units) or else avoid using /usr at all

dsr_2• 4 years ago

I believe that the end goal of systemd is to end Linux distributions as anything other than a flavor.

This will not work completely, but it may work well enough that non-systemd linux will be considered an unusual eccentricity.

LeSaucy• 4 years ago

One could make the argument we are already there.

marcosdumay• 4 years ago

Until some eccentricity works well enough that everybody adopts it.

Then it's only a matter of barriers and lock-in... And systemd imposes a lot of those.

HNDV3• 4 years ago

http://www.islinuxaboutchoice.com/

where to me, running Linux is about choice.

Quote :

"From: Adam Jackson To: Development discussions related to Fedora Subject: Linux is not about choice [was Re: Fedora too cutting edge?] Date: Wed, 09 Jan 2008 15:58:45 -0500

Linux is about choice.

If I could only have one thing this year, it would be to eliminate that meme from the collective consciousness. It is a disease. It strangles the mind and ensures you can never change anything ever because someone somewhere has OCD'd their environment exactly how they like it and how dare you change it on them you're so mean and next time I have friends over for Buffy night you're not invited mom he's sitting on my side again.

As a consumer, yes, you have lots of choices in which Linux you use. This does not mean Linux is in any sense _about_ choice, any more than because there are so many kinds of cars you can buy that cars are about choice.

The complaints up-thread about juju and pulse are entirely valid, but the solution is not to try to deliver two things at once. If you try to deliver both at once you have to also deliver a way of switching between the two. Now you have three moving parts instead of one, which means the failure rate has gone up by a factor of _six_ (three parts, and three interactions). We have essentially already posited that we have insufficient developer effort to have 100%-complete features at ship time, so asking them to take on six times the failure rate when they're already overburdened is just madness. Alternatively, we could say that we're integrating features too rapidly, but you do that at the expense of goal 1, to be the showcase for the latest and greatest in free software.

Software is hard. The way to fix it is to fix it, not sweep it under the rug.

There is a legitimate discussion to be had about where and how we draw the line for feature inclusion, about how we increase and formalize our testing efforts, and about how we develop and deploy spike solutions for corner-case problems like the one device class that juju happens to do worse than the old stack. But the chain of logic from "Linux is about choice" to "ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster.

- ajax "

captainmuon2• 4 years ago

Hah, I knew somebody was going to post this and almost added a disclaimer.

When I say Linux, I'm talking about Linux distributions. Not the bare kernel, not embedded Linux.

If I choose to use Linux over macOS or Windows, the #1 reason is that it gives me greater choice. On the desktop, to choose different desktop environments, to customize it to a greater extent than what is possible on other platforms. (That even applies to some extent to the server, I can choose from a greater selection of alternative services and am more flexible than in the Windows Server world, where it is more often a IIS, MSSQL, .NET stack.)

If I don't value choice, than frankly there is very little to make me choose Linux over whatever is preinstalled on my Laptop. I used to have fun tinkering with my Linux installation and developing my own tools and workflows etc., but now that I'm older and don't have so much disposable time I prefer something that is good enough out of the box. I'm sure many people can relate.

If the greater Linux community still embraced "Linux is about choice", and I could still run stuff in the "mix and match" spirit of ca. 2009, but with a modern kernel and modern apps, then I would immediately switch to desktop Linux. But you can't choose your window decorations, themes, desktop panels independently anymore and get a somewhat matching look and feel. It's only Gnome island, KDE/Plasma island, and hacker-minimalist island.

Woodi• 4 years ago

Welcome to C: ...

rfmoz3• 4 years ago

SystemD fundation basement was a Linux implementation of the MacOS LaunchD. It was a step forward over the traditional init managers, but in any case disruptible over something new, because an equivalent design was running on Apple devices time before.

http://0pointer.de/blog/projects/systemd.html

fullstop3• 4 years ago

launchd or perhaps, more likely, upstartd.

rfmoz3• 4 years ago

UpstartD was the good alternative offered by Canonical, but Redhat finally won with their SystemD.

legulere• 4 years ago

That's a pretty long list of small changes, but nothing really sticks out. I don't really see any ground of discussion about this.

xarthna2• 4 years ago

I have long been an advocate against systemd for the typical reasons (overreaching responsibilities, lock-in, lack of choice, software assumption "it will be there", complexity, driven by large corporate interests [see lock-in], being modeled after launched, etc etc). I feel like the chickens are coming home to roost.

That said, if one wants to use it, then use it. However, there are alternatives which I would love to see receive more adoption. I've been extremely happy with my Artix [1] system running s6 [2] init.

1. https://artixlinux.org/

2. https://skarnet.org/software/s6/

TheFreim2• 4 years ago

Why s6 over other options? I've long considered switching from arch to something without systemd since I use almost zero systemd features but have not had time to discern which init system to use.

xarthna2• 4 years ago

Mostly because of the philosophy of the software's author. This was the selling point for me. It is incredibly small scoped by design, easy to understand, and is very explicit in it's actions. It is not as "user friendly" as other inits, though the author is currently working on making it more accessible. It practices separation of mechanism and policy, it attempts to do less than more, and it know when to stop and not introduce scope creep. All by design. I won't ever have to worry about it becoming a system layer and reaching into my network stack, or making policy decisions for me.

I'm sure other available init systems have their selling points - but to be honest, after reading s6's reasoning and design goals I was sold. I'm happy to report that after a year and a half I'm pleased with the decision.

t43562• 4 years ago

I'm enjoying dinit in artix. I think Artix is not terribly mainstream but the dinit part of it seems easy to deal with so far. It would be interesting to see it get polished in a different distro.

Living without systemd is sometimes a rough choice at the moment but I think it can be polished.

E39M5S622• 4 years ago

Take a look at Chimera Linux - https://chimera-linux.org/ . It's a desktop-focused distribution that uses dinit. It'll be one to watch once it stabilizes.

rektide• 4 years ago

Small detail, but interesting to see varlink capabilities added.

systemd-resolvd gains "monitor" capabilities via the lightweight json rpc system varlink.

definitely useful just for monitoring dns broadly, seeing whats happening on the system. there's probably some more specific creative uses folks could hack together here.

effie20• 4 years ago

it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions ... -- Lennart Poettering - Red Hat, Inc.

https://lists.freedesktop.org/archives/systemd-devel/2010-Se...

Systemd 252

Related Stories