Slashdot Mirror
Ask Slashdot: Can You Say Something Nice About Systemd?
ewhac writes: "I'm probably going to deeply deeply regret this, but every time a story appears here mentioning systemd, a 700-comment thread of back-and-forth bickering breaks out which is about as informative as an old Bud Light commercial, and I don't really learn anything new about the subject. My gut reaction to systemd is (currently) a negative one, and it's very easy to find screeds decrying systemd on the net. However, said screeds haven't been enough to prevent its adoption by several distros, which leads me to suspect that maybe there's something worthwhile there that I haven't discovered yet. So I thought it might be instructive to turn the question around and ask the membership about what makes systemd good. However, before you stab at the "Post" button, there are some rules...
Bias Disclosure: I currently dislike systemd because — without diving very deeply into the documentation, mind — it looks and feels like a poorly-described, gigantic mess I know nothing about that seeks to replace other poorly-described, smaller messes which I know a little bit about. So you will be arguing in that environment."
Nice Things About systemd Rules:
Bias Disclosure: I currently dislike systemd because — without diving very deeply into the documentation, mind — it looks and feels like a poorly-described, gigantic mess I know nothing about that seeks to replace other poorly-described, smaller messes which I know a little bit about. So you will be arguing in that environment."
Nice Things About systemd Rules:
- Post each new Nice Thing as a new post, not as a reply to another post. This will let visitors skim the base level of comments for things that interest them, rather than have to dive through a fractally expanding tree of comments looking for things to support/oppose. It will also make it easier to follow the next rule:
- Avoid duplication; read the entire base-level of comments before adding a new Nice Thing. Someone may already have mentioned your Nice Thing. Add your support/opposition to that Nice Thing there, rather than as a new post.
- Only one concrete Nice Thing about systemd per base-level post. Keep the post focused on a single Nice Thing systemd does. If you know of multiple distinct things, write multiple distinct posts.
- Describe the Nice Thing in some detail. Don't assume, for example, that merely saying "Supports Linux cgroups" will be immediately persuasive.
- Describe how the Nice Thing is better than existing, less controversial solutions. systemd is allegedly better at some things than sysvinit or upstart or inetd. Why? Why is the Nice Thing possible in systemd, and impossible (or extremely difficult) with anything else? (In some cases, the Nice Thing will be a completely new thing that's never existed before; describe why it's good thing.)
We will assume out of the gate that systemd boots your system faster than ${SOMETHING_ELSE}, so no points for bringing that up. Bonus points are awarded for:
- Personal Experience. "I actually did this," counts for way more than, "The docs claim you can do this."
- Working Examples. Corollary to the above — if you did a Nice Thing with systemd, consider also posting the code/script/service file you wrote to accomplish it.
- Links to Supporting Documentation. If you leveraged a Nice Thing, furnish a link to the docs you used that describe the Nice Thing and its usage.
I've done migrational upgrades to System-d with Arch Linux with zero problems in addition to using it with new installations. It works fine, and I'm still really confused about the jihad-level hatred it seems to engender in some people.
AntiFA: An abbreviation for Anti First Amendment.
Most distros are focusing on system d because they simply do not have the resources to do anything else.
This is the sad reality. The Red Hat-isation of the linux world. It's either the Red Hat way or the highway.
And most distros obviously are not chosing the highway.
My problem with things like systemd is not that they have nice features - lots of things have nice features. Windows' Shadow Copies is a lovely feature that's a lot easier to configure that some alternative equivalents, etc.
It's that they put those nice features into some new paradigm of configuration when you could have just added them to the existing system.
Reliable servers don't just crash. This is the Windoze (C)(TM) method of reliability by restarting. Defensive nanny processes are a hack and hardly unique to systemd. They invariably result in trying to restart a broken configuration 1000 times in a row. Death to systemd.
Seriously, I've been a Linux Guy since the 90ies and I honestly couldn't care less.
Anything I know about init is about runlevels - and those are a really neat thing. I mean really cool. You can fiddle with those using mc (Midnight Commander) and debian has a stack of 4-6 of those preconfigged and set up by default - last time I checked, some 7 years ago or something anyway.
Point is, my grandma can set up a runlevel that ex- or includes the LAMP stack in it's 'launch', 'init' or whatever-it's-called sequence and I can set my box to it by typing "init [simple Int here]" for my box to go there.
Again, that is pretty neat and cool and the best working solution I've run into so far.
Way better than anything in the Windos world, that's for sure.
If this "systemd" thing - whatever that is - doesn't break this or offers a neater improvement on that runlevel stuff or a way better concept that's worthwhile moving into, perhaps like the SVN vs. Git thing in which Git comes out on top IMHO - without requiring some bullshit GUI tool to be usable, that's all very fine and dandy with me.
If, on the other hand, you're going to push this new fad and hurt me wile doing so, I'm coming for you some time in the future. With a baseball club and my mafia friends. Other than fucking around with one of the best filemanagers ever - Konqueror - and replacing it with an inferior dolphin - this isn't some GUI toy you should fiddle with. This is Linux at a level where it's actually *the* industry standard. As in 'no other even comes close to this level of reliability and quality". Fucking that up would be a really stupid idea.
Otherwise I really positively couldn't care less - and that's how it should be, no? Except for, maybe, if I were a System Developer or Distro Release Manager or something.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
'systemd' needs to stay optional, and I mean that explicitly. optional. Not "default", and not "optional, in the sense that you then have to do the maintainer's job for them because they are too lazy to consider people not using systemd, because systemd is the default, and the maintainer does not want to consider the people that dont want systemd, regardless of the reasons or circumstances." kind of way.
Systemd is potentially useful for only a subset of the linux ecosystem, and forcing this kind of change is a bad thing.
Please allow me to explain why:
Systemd seeks to be a "Be all, end all solution to system initialization", which ultimately means that it will itself try to cover every possible thing that its maintainers believe needs to or should happen during system init. That in and of itself means that it will be large and cumbersome; exactly the things that embedded linux should avoid, where ultra-minimalism is king. (We are talking systems that have just a few dozen megabytes of memory, and just a few hundred megahertz of processor power at the most. Having all that gobbled up by the init system as soon as power is applied is not going to win you any trophies, and boldly asserting that embedded devices need to obey a desktop paradigm is throwing the baby out with the bathwater.)
This is especially true with "reference distributions", like debian. Debian "console only" deployments with tools like debootstrap are reasonably common with embedded devices, as are deployments that make use of chroots for specific sandboxed services. A chroot does not need a full blown init like systemd. It is best served with a simple init script. Building a distro with the intention of killing simple init, and replacing it with a monolithic solution like systemd will make service daemons much more difficult to control in this way, and will actually rob core functionality away from the distro that goes that route--- exclusively in favor of desktop flavored deployments.
Linux is more than desktops.
Linux is routers.
Linux is home automation systems.
Linux is servers performing specialized functions.
Linux is so much more.
Please be more considerate about trying to force systemd into debian. Optional is OK. Optional like "gnome vs kde vs xfce vs $ManagerHere". Not "optional" like "unity on ubuntu". Debian is a reference distro, upon which many other distros are based. It has already found its niche in the linux ecosystem. Please dont try to reinvent it.
In which case a nanny process restart is useless. Thanks for making my point, idiot.
What the fuck, you think you can set rules for discussion on Slashdot?
Sadly he can't force the rules on anyone, no matter how useful those rules would be for such a debate. So, instead of actually doing what the poster wants, we instead get comments like yours which add absolutely nothing to whether or not systemd is any good.
And yes, it's a question I was considering posting on too. It would be nice to see some useful information.
So thanks for clogging the top level posts up with useless, pointless crap. You have done your fellow slashdotters a great service showing you can be angry on the internet.
SJW n. One who posts facts.
With more people jumping to FreeBSD, we might get better hardware support over here.
Prediction for end of Universe #42: Fencepost error in Quantum_bogosort.cpp
Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.
Firstly, if I'm properly monitoring the process, then I'll be alerted and can investigate.
Secondly, there may a *reason* the process goes down, and having it down may be a good thing. If someone's trying to fuzz our httpd process for exploitation, then it happily restarting will open up a wider attack window.
Autopilots on production servers seem like a bad idea to me.
Method of processing duck feet
Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.
I have the opposite view. If something goes down:
1) I want to know about it. I want some monitoring system to send me an alert of some description.
2) I want it set up in a way that it won't clobber it's own log files. Preservation of the reason something failed is key.
3) I want it to automatically restart if possible. I say if possible because I want to avoid a re-start loop but if something goes down and comes back up then the end user is happy as uptime is maximised and providing criteria 1 and 2 are met I'm no worse off as an admin. Believe it or not random crashes may sometimes happen and may have nothing to do with the config or the system itself. I may be caused by some edge case that was hit by a user, and in those cases I am unlikely to find the problem quickly and in the interest of not limiting user access would be inclined to get the system up and running as quickly as possible and then sort through the log history into what the actual problem was afterwards anyway.
Wait, so now we aren't setting read/write status in fstab anymore?
How do you set filesystem read/write status for just the ntpdate process in fstab?
Sometimes, availability really is critical. In that case I want to take the risk of an automatic restart before the cause is investigated. However, it is important to appreciate that the approach is risky . The restart can cause cascading errors that change a reasonably simple issue into a multi day recovery operation.
Those facilities are not given by systemd. They are given by cgroups and other security features. Systemd just has a way for you to specify them for services, it's not doing all of the heavy lifting.
Similarly, imagine that config file, interpreted by SysVInit scripts, and applied the same. Would that be better or worse than systemd?
And, to be honest, in terms of the userbase, that's quite a niche preference. I can count on my fingers the number of times that I've personally had to lock down a service to the bare essentials. That's what package managers and SELinux policies are for.
Again, it's a lovely feature. But does that justify ripping out the init code from the entire distro for? And could it be done any other way (I'm guessing yes).
i'm a small time admin, running about 100+ wireless nodes for artisans, private and commercial users. the -majority- of users running debian on desktops (autopilot upgrades rolled out), the rest are smartphones etc. windows is -actively- banned from the network. all routers, servers, firewalls are running debian, handrolled with lenny, wheezy and jessie, but all configs by the book, and audited by an experienced 2nd set of eyes. i'm 35 years in computing, telecoms and electronics. systemd is the worst single time-waster event in my professional career. although not yet enabled by default in jessie, it's causing a -lot- of disruption with basics like remote rebooting becoming an economical hazard (petrol costs), remote desktops not cranking up, auto logins not working (previously reliable packages like gdm3 break on upgrade due to forced dependencies to systemd related packages), endless hangs on startup/shutdown, many users complain about slow shutdowns, or machines not shutting down at all, services not starting. and yes: i understand how the beast works, and i can see the beast is doomed. the logging is a ---fucking--- nightmare, works fine on paper, but is making it impossible to get basic stuff done when in the real world things break, and taking the unreadable logs with it into the ether. i'm yet to see a machine that actually booted faster, or indeed shut down faster. agressive parallelization seems to apply ony for a subset of computing equipment i'm unfamiliar with. i can already hear the smart arse comments from corporate armchair admins: 'do this, do that ...' but the reality is that the problems caused by the yet flaky systemd is creating such an extra workload that is buries any hope of getting to grips with it. driving to each customer and wipe the systems fucked by systemd and re-install them with wheezy or carefully pruned jessie is cheaper, and we can all have our lives back. i never thought i'll be wading through backported software again ...
for regular user systemd brings no obvious advantages, at least not for their ancient harddrives on single core desktops - but instead a few ended up with trashed installs, e.g. by old non-critical errors being dragged into an upgrade and then breaking on (remote) reboot.
if i hadn't left the core machinery on lenny and wheezy i'd be in deep shit now, and likely going out of business.
stefan zalewski, burren.org
Much more useful to me would be to get that listing, with those log tails, on a sysVinit. And that is far from impossible.
So do it already.
Watch this Heartland Institute video
Wow. The usual complaint is the myth that systemd is monolithic. It's not. But now you're complaining that it's broken up into too many services? And how is this any different from sysvinit, which also starts any number of different binaries?
All they've done in systemd is write C code to start up services that used to be started instead by shell scripts and added the ability to make dependency resolution automatic so that services are only started when they need to be. So basically, they made it smarter and faster. The complaint that it's got too many binaries is moronic and a complaint just as well against sysvinit.
Systemd is modularized into a number of different binaries, each of which handles a different service. Thus, different functions are isolated from each other. This enhances stability and improves startup performance when not all need to be running first thing at boot time.
Oh, and all of systemd's config files are written in ASCII, in the traditional UNIX way. One cool thing they've done is made a single parser implementation (in a shared object library) so that all of the config files have the same syntax. Also, when you debug a problem with parsing for one service, you automatically debug it for all others at the same time.