Slashdot Mirror
Debate Over Systemd Exposes the Two Factions Tugging At Modern-day Linux
walterbyrd (182728) sends this article about systemd from Paul Venezia, who writes:
In discussions around the Web in the past few months, I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server. I've also seen a large backlash against systemd from Linux system administrators who are responsible for dozens, hundreds, or thousands of Linux servers, physical and virtual. ... The release of RHEL 7 has brought the reality of systemd to a significant number of admins whose mantra is stability over all else and who perhaps had not waded into the choppier waters of Fedora or Debian unstable to work with systemd before it arrived in RHEL.
I know quite a few of us in hacker culture who hate the fact tha systemd does not feel UNIXy at all. It breaks practically every principle of the UNIX philosophy. Reminds me of working with windows, and that is never fun.
IMO, administrators' backlash against systemd is just plain wrong. It enables some seriously cool administrative features, a lot of which are very much utilized by CoreOS to make setting up and managing a cluster of servers a breeze. Is creating unit files really so difficult? The syntax is not exactly complex. As for stability... I have never, not once, had a systemd related crash or anything of the sort. Some distros do particularly suck at packaging systemd, however (I'm looking at you, Gentoo). Give it a try, preferably on something like Arch. If you still have complaints... well, stick to slackware, I guess?
I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server
I haven't seen an overwhelming support anywhere. Most people who run Linux on their laptops say, "meh, as long as it boots."
This article is a LOT better than the previous one by the same author. He makes his point clearly, that he doesn't like SystemD, as a sysadmin he doesn't want binary log files etc; but if someone else feels like they need systemD, maybe there should be a fork to make place for those people. It's a fairly kind, open attitude. Maybe we should have more of that around here.
"First they came for the slanderers and i said nothing."
This should be productive.
The headline states the obvious for anyone who has looked at any of the previous systemd articles on slashdot.
The summary is the excerpt background information in the article rather than a summary of the article is about.
And the article is why systemd is bad.
Let the flames continue!
Who controls the system, the system administrator or software developers?
How many packages come with init scripts that actually work?
How many packages have dependencies that aren't documented?
How many packages work only on a narrow subset of environments that are tested by the developers?
The answer, of course, is "all of them."
Today, the competent administrator can control startup, dependencies, etc on a granular basis. With systemd, that control has gone - somewhere else.
Who gets called when stuff fucks up because some bozo fucked up their package's systemd configuration? It won't be the package developer, that's for sure.
I Agree to a point. I believe you are talking more about the "Doing one thing well" kind of aspect like most of our tools give us. But there is also the fact that we have enjoyed the benefit of choice. (Choice of shell, choice of desktop environment or window manager, etc). Should there be a choice at install time whether your system is sysdemd or sysvinit or makefile or whatever I think it would be a good thing (maintainability be damned though). Me personally I will stick with my sysvinit style startup. Has /. done a poll about this yet?
I use LMDE on three laptops. I don't support systemd. Ignoring the technical arguments, it's been forced down people throats and that alone should be enough for people to step back and halt it's adoption.
That aside, will people please stop this constant masturbation about startup times? There are way, way, way more important things to deal with than edging out a few more seconds. Systemd provides me with no perceivable gains. I don't sit down, press the power button, then stare at the screen until I can log-in, then wait again for the desktop to load. I press the power button, plug-in the laptop, take out my mouse, manager whatever papers I'm going to use, etc... and then log-in. When I had a desktop, I almost never rebooted it. Startup times matters even less on desktops.
However, systemd does provide me perceivable losses. Time spent arguing over systemd could have been spent making everything else better. Systemd removes options, that while I'm not doing anything with at the moment, I like the ability to choose in the future. There are way too many instances of previously good companies/projects suddenly fucking over it's users (of which systemd is becoming an example of in and of itself). I prefer not being locked into something. Systemd didn't present itself as an option, it demanded that it be a requirement.
Personally, I find it crazy that Microsoft and other large software companies are doing more to support scripting while somehow the linux community is being dragged into less and less scripting. (article mentions desktop users don't want to know how to script anything). We need more scripting not less. I'd love to be able to pull out the couple commands I use that are buried in menus and place them as buttons on the menu bar. I don't want an AI to do it for me, I want to take my common commands and make them easier to navigate to and execute or completely automate them.
wow talk about not knowing whats going on, from day one there's been multiple factions doing their own thing on every little single nitpicky detail, which is why linux is both good, and a fucking nightmare to deal with
keep squabbling
If you assured me I could go from initd to systemd seamlessly then of course I'd migrate. If not then maybe I'd give the paint some time to dry. Granted the reliance I have on linux is relatively low. If I were a linux sysadmin with thousands of systems and my job on the line my answer would be "YOU WANT TO DO WHAT WITH MY MACHINES!"
lennart poettering is the santa claus politician of *nix , well just Linux because none of his garbage ports.
He promises stuff that does magic and its free, but the reality is hey can deliver, nor his sycophants and minions, anything that works.
He is poetter-izing linux, making it suck in the same ways as many commercial OSen.
I have to say systemd is the crappiest rip off of SMF I have ever seen.
The division is not between administrators and users but between luddites and users. Luddite administrators generally spent years learning all the arcana of Unix administration and simply can't accept that a large body of this knowledge is now inapplicable. THAT'S the source of "systemd divide".
Oh, and in our company we manage clusters of up to 30000 machines for our customers. And we simply _love_ systemd because it makes so much easier to make reliable clusters.
This is also about Debian betraying its self-stated aim to be "The Universal Operating System." Debian, as a general purpose OS, also supports/supported kFreeBSD and Hurd kernels. systemd is Linux kernel only. The "technical decision" to drop non-systemd init support in the next release throws the users and contributors of non-Linux kernels under the bus and betrays aim of the Debian project itself.
Administrators dislike constraint based systems.
This should surprise no one. One of the problems with a constraint based system is that you don't control the precise ordering of things.
This doesn't bother the Debian folks, because their build system is a constraint based system. If they have a package to install which has dependencies, they don't control the actual build order of the dependencies, or of their dependencies, and so on. Turtles all the way down. You do an apt-get install foo, and it's going to try to build subcomponents when they become available to try to build. And if they fail to build, they don't care: they "try again later", in case something that happens later satisfies the dependency that wasn't satisfied the first time around.
This is very disturbing to system administrators, who like things to be both orderly and predictable. All dependencies should be mapped out, known, and explicit. If something gets tried now, and fails, the correct response isn't "We'll try again later!", it's "Stop! Someone fix this fucking thing, it's obviously broken".
The build system is not deterministic; if there are two components, and one has a subdependency on some X of "at least version N", and another has a subdependency on X of "at least version N+2", then depending on the vagaries of network overhead, it's possible that half your code gets built with version N and the other half gets built with N+2, and things break. Things breaking is in fact far more acceptable to a system administrator than "things act weird", and "things act weird" is at least deterministic for a given build instance, and far, far, more preferable than "things sometimes work and sometimes don't".
So system administrators dislike Debian for large system installations. And they dislike systemd for starting things up and shutting things down.
A desktop system is far, far more forgiving: "It's not working; I'll just reboot!". As long as things "mostly work", then things are great! "Look! It's as good as Windows!".
Note that launchd in Mac OS X has many of the same problems as systemd; it's also a constraint based system. It's somewhat worse, in that it insists on controlling file descriptors and sockets and Mach ports for the things it starts - which means you have to rewrite a lot of at least the startup code in most Open Source software to tolerate being run by something that opens the files and sockets that it expects to do itself. But that's just a lot of make-work, and people who are paid to do work are paid because it's not something they'd be willing to do voluntarily, for free, and that's what they're exchanging for the money they are getting in exchange for putting up with that part of the job.
Unlike the people making things work with launchd, though, the people expected to make things work with systemd aren't being paid. And so systemd represents make-work and change for chage's sake, which doesn't sit well with volunteers.
--
So yeah, a lot of people find systemd annoying. Kirk McKusick once accused "vnode" as being "the structure that's taken over the kernel"; in Linux, systemd is fast becoming "the program that's taken over user space".
How this will all play out, I don't know, but don't expect it to be resolved any time soon, given the dichotomy between the philosophies of the stakeholders involved.
Systemd articles have become the new Slashdot clickbait. It seems every freakin' day there's another "discussion" about that unholy abortion.
I do not fail; I succeed at finding out what does not work.
It's not just the init, it's also the applications that are being infected with Lennart-ware, e.g. gnumeric. It's a great spreadsheet, but recently it's been picking up various egregious hard-coded dependancies that simply don't make sense. This occurs mostly via GTK, which seems to pull in a significant chunk of GNOME.
I run a minimalist Gentoo desktop, and I notice when additional dependancies are dragged in. The past year or 2 has seen goffice, ghostscript, harfbuzz, dbus, and various other crap become hard-coded dependancies for gnumeric. It was not necessary a couple of years ago. If I had several million dollars, I'd hire a bunch of progragrammers to port gnumeric from being dependant on GTK to being dependant on FLTK (Fast Light ToolKit) http://www.fltk.org/ Some of the money would go to ongoing maintenance.
Another few million dollars, and I'd like to hire a team to hack and slash away at Firefox. I was around when "Phoenix" was forked as a lightweight alternative to the Mozilla web-browser. I savoured that promise. That promise has been dashed into the ground, with a Firefox that's bigger, heavier, and slower than the original Mozilla ever was. Time for a new fork.
I want GNU-Linu-x, not GNOME-Lenna-x
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
Erich Schubert. Look him up. Him and people like him are why debian is going this progressive way.
...is Unix. When choice is taken away you are left with Windows.
Time is what keeps everything from happening all at once.
We should get a Registry for Linux too ... wouldn't that be neat?
Your comment, along with all of the others, proves to be that nobody that dislikes systemd has actually used it.
Required service dependencies are *absolutely* trivial, unidirectional or bidirectional.
This whole comment section is hurting my head. So so so much misunderstanding and untruth.
Whether one dislikes systemd or not isn't necessarily because of what it does or doesn't do. The issue for many people (myself included) is simply that it's a monolith that keeps trying to grow larger in an "open" world that was meant to stand for a certain amount of platform agnosticism and component independence.
I realise that systemd can make life easier for some more novice users but to be true to the spirit of the open source community I would expect it to be optional where it can be so. When it starts to intrude into critical areas and make itself mandatory in some releases, that bothers me. It makes me think that the whole business is a sneaky attempt to subvert the Linux kernel and eventually take control of Linux as a whole.
One wonders if there had been as much hoopla of Poettering and crew showed as much respect for backwards compatibility as Torvalds has enforced for user space facing APIs in the kernel...
Your comment, along with all of the others, proves to be that nobody that dislikes systemd has actually used it.
Required service dependencies are *absolutely* trivial, unidirectional or bidirectional.
This whole comment section is hurting my head. So so so much misunderstanding and untruth.
On the contrary; I've fixed a number of the dependency orderings in ChromeOS using systemd. Like I said, it's fine if you are OK with rebooting, and as you said, it's possible to express the dependencies correctly. I don't think we are contradicting one another.
It's also possible to explicitly specify correct build order dependencies in the Debian build system, so that it can avoid retries. My issue is that it's also possible to express the dependencies as loose constraints, and things can still be made to work (rebooting in case the mouse didn't start up correctly in ChromeOS was one of the things I fixed; 95% of the time, it started fine, but the first reboot after an upgrade, before the boot cache files had been built, it didn't, due to timing). The Debian build system does it by retrying.
The problem is that people depend on this behaviour to get them out of jams, rather than drilling down and fixing the missing underlying dependency specification, *because the system _mostly_ works without them needing to do so*. And *that's* the problem. If it just freaking *broke* outright, like a reasonable system, you'd know (A) what to fix and (B) that you didn't have any more hidden timing related crap lurking in the shadows, which wouldn't show up in in house testing, but might show up as a heisenbug at some customer site. That's just not acceptable.
How can using systemd possibly affect technical reasons against it like its increased attack surface, inherent architecture, and complexity in slot 1? Those aren't going to change when one uses it. I do use it, and they are still present.
You're not replying to the reasons raised, but merely using a common fallacious form of argument to deflect them and avoid addressing the actual downsides.
Can someone (maybe even Paul Venezia, the author) provide a link to a reliable source substantiating the claim that systemd has "owerwhelming support" amongst end users?
Or has InfoWorld just turned into a giant FUD cannon?
Systemd has it's downsides. The real downside is that you have so much complex code running as root. most other complaints can be dealt with.
Binary logfiles: You're not supposed to keep important log files on the local machine. Send them to your central logging facility where they are stored in a database. If the machine is still running, you can use the appropriate tools to look at the binary log files for debug. All your logging, stats and alerting should be centralized anyway.
Doesn't feel unixy: Get with the times. It's scriptable and tweakable more than ever. Just get used to the way it works.
Solution looking for a problem: Just not true, see the benefits.
Systemd is one of the options to solve some problems that have been pestering unix for a long time.
Dependency in services: Systemd can restart all dependencies on a service in the right sequence if you have to meddle with one part of a stack
long startup times: Systemd has the possibility to start up things in parallel. No long waits for earlier systems that your service doesn't depend on. Mostly useful for mobile users, but HA systems benefit too due to shorter maintenance downtime
Location/circumstances specific profiles: Depending on where you are and what kind of facilities you have available, your system can "adapt" by changing power profiles, network connectivity, firewalling and whatnot. Primary benefits are for mobile users, but servers changing load depending on things like overheating, having to run on UPS power and such are also quite useful.
Systemd isn't the only project that wants to work this way. Upstart is another one that at least wants to deal with the startup concurrency and dependency problems of classical init. Sun (Oracle) Solaris SMF is also a good example of this line of thinking.
While you can have doubts about the amount of complex code and forks to 3rd party code done by systemd while running as root, I don't think it's useful to complain that someone moved your cheese and took away the init scripts you used to use in the old days. Once you figure out how to work with the new tools, you'll find it's way more tweakable and controllable than classical init. If in the end you choose for init or a different alternative, that's up to you, but at least investigate and educate yourself, before you start complaining with arguments that just aren't true.
I was promised a flying car. Where is my flying car?
One of nodes in your 500-node cluster is hanging because SysV scripts shat down its pants yet again because of a subtle race condition. Reproducing it locally yields nothing. Logging in SysV is nonexistent so debugging the issue is non-trivial. All while your cluster is frozen waiting for that critical DB node to start.
Now enter systemd. The traditional race conditions are solved right away. No more PID races, clean dependencies on mount points. In case of a service failure, its stdout/stderr are readily available. Boot graph with all the dependencies clearly shown is waiting for you to check it. The system status (including service watchdog timers) is easily streamed into an external monitoring system..
Yeah, sure SysV scripts are better.
" simply that it's a monolith " - that again is a reworked dictionary definition to suit an argument. systemd is not a monolith
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
SysV is not better. But BSD init is not worse.
Yet another clueless anti-systemd rant by Paul Venezia, yawn.
So now he goes on an ad hominen and labels systemd proponents as clueless noobs, while serious admins hate it. Right. I, for one, in one of my duties as a professional system admin manage hundreds of Linux machines, can't wait until we finally get rid of that SysV init crap in favor of systemd (I won't rehash all the advantages systemd brings here). Due to EL7 switching, we'll eventually get there, thanks Redhat!
1. systemd was FORCED down my throat by just issuing a "pacman -Syu". it took me THREE fucking days getting my desktop back to normal after sifting through a barely comprehensible arch wiki page. systemd had long since been adopted by other distros and i was amazed how BROKEN it still is.
2. systemd FORCED me to sit down and learn a new set of tools for NO reason. my system worked just fine before systemd. i've since migrated to openrc (thx gentoo devs and apg + artoo from the arch community for making it possible (relatively easy to adopt) on my system.
3. systemd VIOLATES EVERYTHING K.I.S.S. it tries to be much too clever and it makes me feel dumb
4. systemd GRABS everything. not just init. try to install gnome without systemd... no way you can do that without a major hassle.
5. systemd -FORCES me to jump through hoops and rely on the good will of some very nice folks to provide me with a viable alternative. i have to rely on experimental and often buggy packages to get back to before where i had NO PROBLEM with init.
i hate SYSTEMD and this pottering can go to hell for what i care. thx for a whole lot of lost time. if it where just nothing and didn't force me to waste all this time i wouldn't even have cared... but this means WAR!
fuck you pottering. fuck you arch linux guys for violating your core principles and fuck all those ZEALOTS not giving me a choice in the matter and think they know what's best for me. this is the worst time being a gnu/linux advocate in like EVER.
on a positive note: thank you windows 7 for staying predictably stupid and giving me a working system while my linux init was broken for three days.
If you are full-time sysadmin having setup the perfect shop with sysvinit, you'll probably not see that many benefits. However, lots and lots of people don't have access to a resource like you. When systemd is properly integrated, these people will get a much better experience out of the box, e.g. daemon supervision, watchdog integration or better on-demand startup of services (for really cheap VPS stuff).
If you know your stuff, you'll have configured this by hand long ago - but most people don't know their stuff. systemd allows distributions a better default experience.
And as usual, the embedded developers are barely at the table. Though I guess, to be fair, in this case at least, it is easier for us to bypass the debate and control what is on our systems... but after GPLv3 this invisibility has been a bit of a sore point.
Dude I call bullshit on you. You're talking about theoretical problems that no one ever really runs into ever. There are 2^15 PIDs available. You're not going to iterate over all of them and actually run into a PID race in an init script. That is not a thing. It's just something you might learn in an OS class or something because, well, it /COULD/ be a thing in that theoretically there is a race there, so it's good for learning about races (I guess...). But it's not a race you're ever going to run into in a million years unless you have a fork bomb in your startup scripts. And if you have a fork bomb in your startup scripts, you have bigger problems. And if your entire cluster is freezing because of that one node, maybe you should work on that single point of failure since computers _DO_ have hardware failures occasionally and you _ARE_ likely to get bitten by having a single point of failure like that.
But not because of sysvinit. Stop making shit up.
And you have a slightly lower UID than I do. Which means you should have grown out of your "disparage people who have more experience than I do because I'm so cool" adolescent phase by now. Stop talking about people who "can't see past their bash manual". That's not a thing, either. Having experience is a good thing. Unless you changed careers, you should have enough of it by now to see that. Look in the mirror and think about why your personal growth might maybe be going a little slower than it should.
Oh, SystemD? Well, I think those programmers should probably have spent their time solving real problems, and I'm suspicious of it, because it seems like it's reinventing the wheel, because of its questionable design decisions thus far (such as binary log files), and because Poettering's other brainchildren like PulseAudio are best avoided. But, given that there seem to be enough people who dislike it to support at least one mainstream distribution, I'm pretty sure I won't be stuck with it, so, if someone else likes it, good for them.
vi ~/.emacs # I'm probably going to Hell for this.
If your entire cluster is awaiting a single DB node to start up, methinks your architecture is crap.
Let's start by saying that the death threats against Lennart Poettering are ridiculous and should not be tolerated.
That being said, the design of systemd confuses me. It seems ripe for all manner of stability and security problems. As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon. That's guaranteed to cause all kinds of system crashes.
What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. It wouldn't take longer to load. The services and behavior would be identical. But it would be a lot more stable, because a child process could be restarted if it crashes, keeping init to a bare minimum.
What's even more surprising is that someone with some sense hasn't done exactly that: Make a wrapper for the systemd build that patches a few things and just compiles it differently, into a slightly larger number of binaries. This way, we can benefit from the unification of services, while maintaining stability, and Poettering would have to be intentionally self-destructive to try to keep breaking that wrapper every release.
I would rather run a server OS on my desktops than a desktop OS on my servers. That's why I use Linux as my main OS instead of Windows or OS-X. And I'll keep doing so, though I may, sadly, have to leave Debian after more than a decade.
Stop-Prism.org: Opt Out of Surveillance
" simply that it's a monolith " - that again is a reworked dictionary definition to suit an argument. systemd is not a monolith
Which part of systemd+udev+dbus+avahi+journald+consolekit+logind is not a monolith? The part where I can exclude any one from the mess and still have a bootable system? Oh wait, they are all hard dependencies on each other.
I used OpenRC with Gentoo for several years and was highly satisfied. Simple flat files and scripts did everything I needed. I had less pleasant experiences adding USB devices to udev. The XML config files seemed out of place and far too complex. With systemd things are far worse. The design is childish. Reduced boot up times are a canard. Kill systemd. Kill it dead.
Wow, I'm pretty sure you don't know how hilarious that comment is. Surely nobody could intentionally be that ironic?
Ted Lemon wrote the Vixie/ISC DHCP; it's a beautiful piece of elegant code. Dave Mills invented NTP and wrote several of the implementations; he also invented BGP and wrote the fuzzball, and if that doesn't impress the hell out of you, you really don't know anything about computer science or the history of the Internet.
Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. -- Edsger Dijkstra (1984) On the nature of Computing Science (EWD896)
*NIX "admins" (users with a better password, nothing more) fear systemd: Why? It makes doing what they do with arcane by hand configuration a snap for even midrange users. This takes away their 'magic power' (lol, not) and they fear for their jobs because of that simple fact.
Your comment shows you haven't booted many enterprise level servers. They don't do a quick BIOS test like a normal PC, some take upwards of 5 minutes. So what is a few seconds of boot time when the hardware takes that long?
Every article I read about Systemd somewhere mentions dependencies. I don't get it. My computer has handled those ever since openrc came out. For example, it knows not to start network server daemons such as ssh, httpd, etc... before the network. If you turn the network off it will automatically stop all those daemons first. Turn the network back on and they come back right after. That's about as complex as dependencies get on my system, everything else can and does start in parallel. If I did install some new magic daemon that depended on 5 others before it could run though the facilities are there in openrc for me to set that up.
So... what is so special about Systemd?
It is, and this ridiculous claim that it's not so because it's not a singular binary is as telling as it is tedious.
Worse yet, it's a monolith that's ousted EMACS as the poster child for feeping creaturism.
Something I've not seen mentioned yet in all the argument over systemd is an analysis of the circumstances which have allowed it to exist in the first place. Rolling your own distro is not easy. Maintaining your own distro is far less easy. As a result, many, many people gravitate towards distributions that more or less fit with their own preferences and needs, happy to have someone else do all that un-easy work. In the current model, the majority of these people are Consumers, not Contributors.
The problems begin when one or a handful of distros gain critical-mass popularity. These problems achieve full fruition when the personalities driving these popular distros become egotisitcal, self-aggrandizing narcissists. I cite Ubuntu and RedHat as examples of "popular" distros. I further cite Unity and systemd as the products of individual personalities imposing their will/beliefs on everyone else, because they find themselves in a position where they can. Once you have a sufficient following, you are a Leader, whether by chance or design. These "leaders", with your tacit approval, make decisions for you because they're doing a whole lot of stuff that isn't remotely fun, and they're doing it for everyone, for "free". Their level of popularity has created a type of "vendor lock-in", and at some point they transition from a model of community collaboration, to a Vendor who knows better than you do how your Linux should run.
We created systemd. You and I. We didn't take a sufficiently active part in the development and lifecycle of these distros, content to be passive Consumers. We encouraged a cycle that has finally allowed individual, prima donna egomaniacs to corrupt the foundational principles of *nix because they are desperate to slavishly imitate the path of past egomaniacs who were "successful". They would twist Linux into a mere platform for the expression of their misguided aspirations.
The progression is slow and insidious. It starts as Community rule, then organizes into an oligarchy. There is nothing intrinsic to Open Source that prevents this. Active participation and input by all is the only remedy, but the vast majority of us are too complacent to vote for our government leadership, much less censure or boycott our favorite Linux distribution. Instead we complain, loudly and often. But it doesn't change the fundamental circumstances. All complaining does is obfuscate the real problem, which isn't systemd. It's the system.
Lennart has the influence and authority that we all gave him. If you don't like it, roll your own distro. Or, if you want to do more than simply *claim* that you believe in the *nix and Open Source principles you are so passionately wish to defend, ponder your own contributions to systemd.
I don't. It's a metaphor, you flid.
If I'd said "do I need to resolder my amplifier to connect different speakers in" would that have confused you less, or more?
systemd requires modifications to many other programs. Or do you deny that?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
(Song) Jumble of Lines - FK Systemd (Revision)
youtu.be/zCUIqMk9OOs
SystemD introduces (further) systemic vulnerabilities into Gnu/Linux.
Here is a song feeling that situation out.
Dedicated to Erich Schubert, who put his time in to comment on the videos.
He didn't want to. He didn't like it. But he took the time and there's something to be said about that.
Each and every video.
(C) Gnu GPLv2 (song and graphic)
Some pro-systemd people downvoted this. Capacha: indolent
Some systemd fanboys modded this down.
Discussion on lennart poettering, systemd, sysv:
http://youtu.be/2toVPMHRo8M
Fuck SystemD. Poettering.
Would you rather they use a massive hairball of interdependence that the developers themselves state are required even if you try and claim they are not?
When you cant win, ad hominem.
I think I missed the poll. Can someone support the statement with a poll/survey data?
My experience is the opposite.
There is enough of a divide over systemd to make it an option or a fork will result.
If debian does not allow turning systemd off, I think the following will happen:
- debian fork created, allow turning systemd off.
- majority of debian users adopt fork.
- majority of systemd people use Ubuntu or fedora.
- systemd-off becomes option in Debian
- systemd-off becomes option in Ubuntu and Fedora
Systemd all but guarantees that Linux will never get any traction in the desktop: By making it more Windows-like, all those with a Unix-esque leaning will shun it, while those in the Windows camp will stay with Windows: Why have burger when you can have steak?
Startup time matters? Hmm. Let's see.
15:11 up 39 days, 13:13, 5 users, load averages: 1.09 1.11 1.41
well that's my laptop, can't remember what I was doing 39 days ago or why I'd care how long it takes to boot, I could go make tea, or read a book, or whatever. Really not at all important.
Servers? Well, they may spend anywhere from ~2-5 minutes doodling around in the BIOS, so shaving a few seconds or whatever from the system boot time means they take about ~2-5 minutes still doodling around in the BIOS. If you've done servers right, there will be redundancy, so who cares how long server A takes to reboot when servers X, P, Q, M, and R are chirping merrily away. Sorry, but I'm just not seeing the need for speed.
valen% uptime
3:22PM up 168 days, 14:53, 47 users, load averages: 0.58, 0.36, 0.34
Oh no! My slow OpenBSD server will reboot slowly when I upgrade to 5.6. Oh, the humanity!
Processes need to be restarted when libraries and sundry components underneath them are patched.
When you patch openssl, you need to restart Apache, otherwise the running httpd will be using the old, unpatched libcrypto.
When you patch glibc, any processes that you do not restart will not bring the glibc patch into the memory of a running process, and will continue to express any vulnerability that you patched.
Ksplice seems like a really nifty thing, but as patches pile on, more and more of the running userland is out of date. Going for a long uptime means less trust over running processes.
I can't believe I'm saying this, but where are the grammar nazis when you need them the most?
This makes no sense to me.
Seems to me that re-boot time = startup time + shutdown time.
But, as I understand it, systemd advocates make a huge fuss about faster startup (which I have not noticed btw), yet the same systemd advocates claim claim that shutdown time is not important.
WTF?
- Hide everything in a binary blob
- Embrace monoculture
- Do not play well with others - especially UNIX
- There can only be one and so you must win at any cost
- Replace accepted standards with *your* standard
- Embrace, extend and extinguish because the people responsible for it have a culture which wants that
- Adopt Borg philosophy: resistance is futile, we have already won, why are you arguing?
- Be intensely hubristic: systemd is the best, therefore systemd is superior to all other systems, therefore systemd should to the jobs that other systems do.
Not since the day you stopping changing for better and looking for better things. You cling on the past, you don't have any better visions for things to come or any idea for future.
Your UNIX philosophy doesn't have ACL or system policies for fine-grained security control, or DRI to allow real gaming and accelerated video playback and capture, or the component-based design which all modern desktop systems base on, or even the capability to support PnP and USB devices and instant changing of multi-monitor setup in X.
Your UNIX philosophy sucks yet you cannot see it, because you still hide in the basement doing creepy network stuff in front of 3 CRTs with the original xterm.
Please go f*** yourself and die to save Linux.
I personally ran into tons of problems with SysV scripts. They are not theoretical. One of them forced me to go into our data center at night to power-cycle a machine: http://anonscm.debian.org/cgit... (can you find it?)
And yes, I really do hate the old "let's just hack a bash script approach" or "'sleep 10' solves this race" kinds of admins. And mostly because I have to make their shit run on large-scale clusters that experience all kinds of weird failure modes.
The one I see is if you try to stop and start it simultaneously (or, "within a racy amount of time"), there could be a race with the PID file. Theoretically I guess you should have a consistent state if you start and stop the daemon simultaneously (either it should end up stopped or started), but it seems like it would be bad practice to attempt to do something like that. Slackware's rc.bind script has this comment, which is hilarious:
# Start BIND. As many times as you like. ;-)
# Seriously, don't run "rc.bind start" if BIND is already
# running or you'll get more than one copy running.
Sound logic. I learned not to blindly run "rc.whatever start" long ago.
You want people to test code on weird clusters that apparently are tightly integrated somehow and not using a standard batch submission mechanism. I used to want people to test code on Linux/SPARC. Neither of us is going to get what we want, because expecting other people to test such marginal use cases is expecting other people to do our work for us.
And why would you have to manually power cycle a machine because named didn't start? And why would you have to fix a failure on a single node of a huge cluster overnight? If that was the nameserver for all the machines, well, you should have had at least two nameservers. It's not like they take much CPU. Single points of failure are bad.
vi ~/.emacs # I'm probably going to Hell for this.
The one I see is if you try to stop and start it simultaneously (or, "within a racy amount of time"), there could be a race with the PID file.
There's an infinite loop near line 92 if for some reason BIND becomes unresponsive to signals. That actually happened to me, so that's why I can pinpoint it. And to add insult to injury, this loop happens during service shutdown and can leave the machine inaccessible remotely.
Now let's check the systemd's version of this file: http://pkgs.fedoraproject.org/... Please tell me which one is better.
You want people to test code on weird clusters
Not really. I simply want people to stop assuming that race conditions are rare and write reliable software.
Because they don't bother to shut down. They just power it off, or unplug it.
Isn't this the point of having different Linux distributions? The system administrators responsible for keeping hundreds of machines stable should be using one distribution, while an advanced user setting up their home network should be using another distribution.
Well, the problem in your example wasn't a race condition. It's that they never did kill -9.
The comparison with the SystemD version of the file is invalid because the complexity has just been shifted elsewhere. In the init version, the complexity is in the script. In the SystemD version, it's in a monolithic binary running as PID 1. Which is better is not clear just from looking at the files.
However, and I've said this before -- even if Debian's init scripts suck, that just proves /Debian's/ init scripts suck. Slackware's init scripts are much, much cleaner than Debian's or Red Hat's.
You might want to look into some sort of "(sleep 600; reboot -f ) &" inside of your shutdown script if you're going to be working with machines you can't easily get to to power cycle. That would potentially solve all sorts of obscure corner cases in shutdown. You'd have to put that in after it did its final "I KILL YOU ALL MWA HA HA" signaling to shut down the user processes so the sleeping shell doesn't just die with the rest of userspace. Still, might want to look into it.
vi ~/.emacs # I'm probably going to Hell for this.
The answer backs my original point, while they may be a backport to Debian 7 it's not actually live in a production release of Debian. So tell me, do you also claim that Redhat has everything in the latest Fedora release? That is the equivalent, and it's extremely dishonest.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
I thought ChromeOS used Upstart, not systemd. When did this change?
Never start vast projects with half-vast ideas.
The comparison with the SystemD version of the file is invalid because the complexity has just been shifted elsewhere. In the init version, the complexity is in the script. In the SystemD version, it's in a monolithic binary running as PID 1.
Yes, it's written ONCE, thoroughly audited and tested on variety of systems.
Which is better is not clear just from looking at the files.
Look at http://anonscm.debian.org/cgit... - can you spot a fatal flaw in this file?
Systemd supports SysV style init scripts.
I don't like the part that overwrites resolv.conf to use 127.0.0.1 as the nameserver if it thinks the network is down, but I'm not going to play shell script bug hunt with you. SystemD also has bugs. Almost all software has bugs. The software on Apollo 11 had bugs. And Debian's init scripts are, indeed, messy and imo overkill and inferior to the rc.d method used by Slackware and the BSDs.
I'll just leave you with this: https://plus.google.com/112984...
Yes, yes, "it's just an interface to journald!" So it's more like syslogd embedding a web server and QR encoder than init itself. Much better.
vi ~/.emacs # I'm probably going to Hell for this.
I don't like the part that overwrites resolv.conf to use 127.0.0.1 as the nameserver if it thinks the network is down
So turn it off. Duh.
Yes, yes, "it's just an interface to journald!" So it's more like syslogd embedding a web server and QR encoder than init itself. Much better.
Incorrect. That web server lives in a separate gateway daemon, that is started as a regular service (and it's totally optional). It has NOTHING to do with PID1.
Probably best if you do some of your own investigation into Systemd as to what you can configure in and out of its usage. Don't rely on the misinformation peddled in these postings . e.g. one of the biggest bits of misinformation is that systemd only emits binary logs but if you check the config options you will see
Caveat: I'm a server admin and also part-time contributor to two distros.
I think you may be unintentionally setting up a straw man argument, or perhaps not understanding the issues yourself. Technically, you just said the person was wrong/perpetuating a myth, but then you basically say systemd is *not* logging via text files -- it is forwarding its interpretation of the raw data to another process (often syslog-ng, et al) to save it as a text file. There are some issues with this...
It was promised that this wouldn't be the case, and people had good reasons for not wanting to have journactl as a middle-man by fiat with systemd, let alone a middle man storing in binary. One was supposed to have the option of disabling journactl so other tools could natively capture those raw messages, generally as text files. This was a promise that was supposed to be done in months after a specific release in order to convince adoption. Instead they started writing their own dhcpd server.
As to why this is a real issue, especially in serverland, a few points:
1. Over the last decades, people have worked out tried-and-true systems for documenting and verifying logging. So from an audit perspective, with journalctl you can't lock down syslog-ng and that process, because you've introduced an untrustworthy one above it. They know the current strengths and limitations -- to the point that there are legal/liability issues involved for many if their logging goes wonky. Journalctl adds a layer between the systems they have that work (and even have protocols in place for in terms of auditing), and as of right now adds a *wonky* layer that's very buggy. And by buggy I mean prone to corruption and simply not doing as its told.
2. One can't even remotely log a journal natively, which is par for the course in many server environments. You can't make this stuff up, please see bug #1098132 (https://bugzilla.redhat.com/show_bug.cgi?id=1098132) At the time I'm writing this, that functionality still just *doesn't exist* in systemd/journalctl. It was almost pushed into the last revision, but the bugs were show-stoppers so was pulled. Even if it does go into the next systemd revision, how long until it's really kosher for solid/production environments? 1 year? Two? Three? Yet it's being pushed as the default *now*.
To explain why this is important: if someone cracks in, the log files are going to be one of the first things they muck with. You have locked down syslog/et al, so you can tell if they muck with the binaries, but the log files themselves are considered compromised. Logging remotely at the same time before the data even hits the disk creates another layer of safety, which you simply can't do with systemd/journalctl. One day you will, assuming you want the binary journal and journalctl, but even if you wanted those now you couldn't. Yes, you could rsync over a copy of the files, but there's a reason why people aren't just doing that for regular logs and this is going long.
Here's the real kicker: most of this issue would go away if systemd was willing to allow the user to not use journalctl and let things like syslog-ng have that data in the raw. It is choosing not to allow that as a tactic, as opposed to what the users and tech itself wants, and so here we are.
And systemd has been seen in the wild to dead hang on shutdown because it yanks the server before unmounting NFS.
Systemd suffers from the same problem as pulse: forcing massive/breaking changes onto all users to add features only a few want.
And the whole binary log files fiasco might have been avoided by adopting an actual portable (and reliable) standard like sqlite.
Also for many of us, the OS is tool to get a job done, not the goal itself.
Sorry still don't care. The argument against systemd is being perpetrated by a small number of folks who have an axe to grind. They operate anonymously to hide how few and irrelevant they are.
BSD and forget about it...
Desktop Linux (which I use and love) has less than 5% market share of desktop PC users.
What is the market share of Linux on server machines? I don't know but I would guess at least 50%.
So why do the concerns of Desktop Linux users dictate the decisions for what goes into Linux distributions?
Having a choice would satisfy both Desktop and Server Linux users and give people like me (Desktop Linux user who dislikes systemd) the ability to choose sysvinit, openrc, and others while still allowing people who like systemd to use and enjoy it.
I thought ChromeOS used Upstart, not systemd. When did this change?/q
Never released; it turned out to be a bad idea.