Avoiding systemd isn't hard
vitavonni.de
vitavonni.de
In the future? Yeah, probably.
This wouldn't be an issue if the systemd people weren't notoriously hard to get along with. Really, I think all of the reasons why systemd attracts hate can be boiled down to this. Nobody wants a standard init system that's overtly hostile to bug reports and reasonable changes.
Say what you want about upstart and sysvinit, but I don't recall a point where the maintainers of it were told off for hijacking kernel flags...
This. It doesn't help this guy's case that he's basically calling anyone who doesn't want systemd a "troll". That's not the way to win people to your side of a disagreement.
This. Backed by nothing, calling the systemd team "notoriously hard to get along with". I'd be interested in seeing proof of "this".
"The only way to deal with journal corruptions, currently, is to ignore them: when a corruption is detected, journald will rename the file to <something>.journal~, and journalctl will try to do its best reading it. Actually fixing journal corruptions is a hard job, and it seems unlikely that it will be implemented in the near future."
A major bug is reported, and their response is "it's too hard so we won't fix it" in a project that is soon to be at the core of every major GNU/Linux distro? No thanks.
But that's a lot to overcome.
It'll only grow, though. Most certainly.
Only up to a point. Systemd is getting too bloated, and software engineering tells us that the effort to maintain this will grow exponentially.
So we have two options: if systemd improves and decides to follow UNIX principles, good. Otherwise it'll be replaced like consolekit et al. It's great that we have so many init systems to choose from. The only problem now is software that hard depends on systemd when a single line of code could avoid that.
For instance, openssh-client depends on libgssapi-krb5-2 and libselinux1, but neither of those packages have a dependency on the Kerberos 5 userspace clients or on SELinux being configured or enabled, respectively. If you happen to install Kerberos or enable SELinux, then openssh-client will work fine without a recompile (because Debian doesn't have USE flags). If you don't, the libraries will just do nothing. I think SELinux is a terrible and misguided idea that subverts the UNIX philosophy, adds needless complexity, and also doesn't work, but I have no objection to libselinux1 being installed.
Same thing with bsdutils and libsystemd0. The discussion has never been about being "without systemd code" as if it were a noxious poison. (It's free software, I would _hope_ people incorporate good code from it into other packages.) It's about being without systemd, the init system, and if bsdutils did depend on a particular init system, it would be flagrantly in violation of the Technical Committee resolution.
When was Linux or GNU following the Unix philosophy? Can you name a figurehead who says it ever did?
That can only happen if the dbus executables are installed; libdbus-1-3 Recommends but does not Depend on dbus. This is the standard way of things for everything in Debian, and the dbus packaging is no different from the Kerberos packaging here.
As I mentioned, it would be in violation of the tech-ctte ruling if depending on libsystemd0 also brought in systemd itself as a hard dependency.
> it's a reasonable concern to have.
The entire worldview of systemd is that you shouldn't be spawning things from your current environment (cf. daemonizing in /etc/init.d/foo), you should ask some parent keeper process to spawn the executable. It sounds like it would involve systemd doing the exact opposite of what it currently does if libsystemd were to fork-and-exec much of anything.
For instance, systemd is obsoleting the setuid dbus-daemon-launch-helper, which I am super excited about, having gotten on dbus-daemon-launch-helper's bad side far too many times.
It's almost as if systemd was being forced upon you no matter what.
You don't have to. Someone apparently implemented the logind interface(!) so that GNOME could function on non-systemd systems. Just use that.
> This wouldn't be an issue if the systemd people weren't notoriously hard to get along with. [...]
Are you kidding? I've been following along the mailing list for at least two years and I've never seen any of the unreasonableness you claim. (I'm not in any way connected or invested in the systemd project, just as a little disclaimer.)
If you're going to pull this stunt please at least give us concrete references.
> Say what you want about upstart and sysvinit, but I don't recall a point where the maintainers of it were told off for hijacking kernel flags...
Ah, I see. You're just another troll recycling talking points. Oh, well.
Oh, and btw: Complain all you want -- in F/OSS the people doing the work get to decide. Deal.
[0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/virt...
So what happens with the pinning example with GNOME (I didn't know this useful command)? Because of the dependance on systemd it is not upgraded then?
He also does those really creepy youtube videos: https://www.youtube.com/watch?v=2toVPMHRo8M
And I've heard he contacted other devs and I've heard a couple of stories that I'm not sure I can share publicly at this point.
Generalizing that all systemd opponents are trolls because there is one guy with serious mental health issues is not a valid argument.
There has been no General Resolution amongst debian package maintainers. Red Hat has instituted a regulatory capture of the "bug squashing" committee within debian (the "Technical Committee") by having current or former (but stock holding) employees moonlight in debian and gradually gain membership in that comittie.
Once their numbers were sufficient they proceeded to file a bug report on the fact that systemd was not standard in debian.
This is illicit abuse of process and they need to be prosecuted.
Debian is an unincorporated association. It has bylaws, trade practices, and dealings by which it was governed. The RedHat associated members of the Technical Committee have illegally and in bad faith abused their positions in-order to realize financial and strategic gain for their employer.
Do you really believe this is hate speech? Hate speech attacks a person or group on the basis of attributes such as gender, ethnic origin, religion, race, disability, or sexual orientation.
Seriously though, I am not really sure how I feel about this. While systemd obviously has benefits, I just can't shake the feeling that it goes against the Unix paradiam. But then again, I also prefer xterms and a window manager over a desktop environments like KDE, Xfce, and Gnome, so maybe that explains my mixed feelings.
Very glad to hear we have a major binary distro like Debian committing to init system flexibility this strongly. I just hope it's true. The people who are hesitant can experiment and stay where they are for now, moving only when it's actually desired rather than forced.
it's very unlikely that SysVinit will continue to be supported, because writing init scripts for SysVinit is hard work, and if it isn't used as the default on Linux they'll rot.
I'm not in love with sysvinit, I just don't think systemd is the best option. It clashes, at least with my views on simplistic system design philosophy. OpenRC and FreeBSD's rc seem notably better than both systemd and sysvinit to me.
Opponents of systemd have spread a LOT of FUD and misinformation about systemd. I know, because I was initially very skeptical of (or even opposed to) systemd based on what they had said. Fortunately, I discovered that much of it was misleading or inaccurate after my main distro switched to systemd.
Even if we give them the benefit of the doubt and say that it wasn't an intentional attempt to spread misinformation, and that they were simply speaking very vocally about a topic that they themselves had not taken the time to read up on, it is not much of a stretch to call that behavior "trolling".
Well, obviously there's another, more charitable interpretation.
> I discovered that much of it was misleading or inaccurate after my main distro switched to systemd.
Systemd is a continuously-varying project, and just because your distro smoothly switched, doesn't mean there were no problems for early adopters. Or that just because your configuration works, no difficulty with the multiple systemd components have, do or will arise.
Actually, I never claimed that my distro switched smoothly. Ironically, I literally commented just yesterday complaining that my distro (Arch) did not switch smoothly (and IMHO switched too early)[0]. I had a lot of issues when I first switched - I couldn't even boot my system, as a lot of stuff did not migrate cleanly.
Switching is always going to cause upheaval and breakage to at least some extent, and that's not what OP and I are referring to when talking about FUD.
What I'm talking about are people making factually incorrect (and worse, trivially verifiably incorrect) statements about systemd and what it does. Some of them are just blatantly wrong ("systemd forces you to use binary log files"[1], "systemd means you can't use init scripts"[2]), "systemd means you can't use crontab"[3], or my favorite "systemd gives QR code output"[4]). Others are technically true, but highly misleading ("I don't want everything to run in PID 1"[5], "systemd is the only way to run cgroups"[6])
There's a difference between disliking systemd on technical merit and disliking it based on false information that one hasn't even bothered to verify, and then vocally spreading that misinformation.
[0] https://news.ycombinator.com/item?id=8482950
[1] systemd by default does not use any log files (IIRC), and provides text logs as an alternative to the recommended binary default. You can keep using syslog just as always.
[2] systemd allows for init script compatibility. I won't claim that all init scripts will work without any modification, but it's not like you can't keep using init scripts instead of systemd configs if you don't want to
[3] systemd.timer is something you can use instead of crontab, but it will also run regular CRON jobs as well.
[4] systemd does have an option to display kernel dumps as QR codes. This feature is generally not compiled or available by default
[5] systemd includes some functionality that runs in PID 1, but most of what people actually are talking about does not run in PID 1
[6] systemd is the only way to run cgroups, because the Linux kernel requires that a single arbiter handle all cgroups, and systemd is (was?) the only program that has actually implemented the entire necessary ABI to do so. Anyone is free to write another program to handle cgroups instead of systemd.
I think most people don't care how much of systemd is pid 1, there are components like udev that systemd is assimilating, we just want choice, I happen to like modern daemontools-like init systems a lot, but I use various init systems depending on what I want, and that's great IMO. However, read this:
Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call.
The factually incorrect statements stem from such messages from lead developers, they've stated that in the future systemd will be sort of "merged" with linux, and that's no good. We know because we've been using great OSs and this is clearly a regression.
As well, many (most?) people associate "trolling" with "intentional griefing" and not "willful ignorance". I believe that many of the people arguing against systemd are either ill-informed or only considering their own use-cases, but I don't think it is appropriate to generalize them as trolls if their goal is something other than "to make people angry".
"Don't listen to the FUD" # Fixes the first sentence
I can understand that feeling when ideas and chooses are not based on the same as your own. The whole Mono is evil was the definition of FUD to me and not based on the presented facts. To me the issue was mono and C# was a language that was already was a standard and that we had public confirmation that M$ would not do anything to anyone using mono. BUT I would be hard to call people who don't believe like me that SystemD is easier as a user or that Mono was a great choice of a language. I think society is based on what do we do to those who believe differently then ourselves.
I mean, it could be that the shims are nice and easy, but it seems to be the expectation that this will not be the case, right? Especially since systemd seems to be on a very aggressive expansion of responsibilities campaign.
I see it only getting easier actually. Folks in the BSD projects for example have their own init system but still want software like gnome, so shims are used to provide the api abstraction. This can be applied elsewhere in the Linux world as well. Again, this is only for software where the developers have explicitly decided to hard-code in dependencies to systemd, which is not likely going to be everyone.
I'd put good money on this getting harder and harder going forward though. At some point it will be everyone, or at least practically everyone, because every Linux distribution with any mindshare will have been using systemd for years, and hard-coding systemd will be not a lot different than hard-coding calls to the C standard library.
Also, shims? How god-awfully inelegant can we be? "You don't like systemd? Cool. You can run something else (as long as it looks, feels, and behaves exactly like systemd)."
Look, I'm not a religious zealot. Systemd is what they want me to run; systemd is what I'm running. I can live with ugly software. It's not the end of the world. But oh dear god is it ugly.
Frankly i am reminded of the stuff we would see Jobs pull on stage. Like "Redmond, ready your copying machines"...
And once it is a hard dependency then Red Hat will be in control of strategy for the dominant init system.
That's what concerns me, not the immediate technical challenges which can overcome. But those who are busy now patching the broken bits won't have influence over the direction of systemd in the future.
We'll all go where one billion-dollar enterprise-oriented vendor leads us.
http://arstechnica.com/information-technology/2013/02/linus-...
The reason is that RH right now is deep in two camps, cloud and military/government contracts.
http://www.bizjournals.com/triangle/blog/techflash/2014/09/u...
and systemd has two parts as best i can tell.
One part is aimed at cloud via containers and sandboxes (soon to come to desktop as well via Gnome).
The other is aimed at securing "seats" via logind. This because the earlier consolekit had a limited reach because it didn't have a partner sitting as pid 1.
And the military is after all the origin of the concept "trusted computing".
I am not saying that there is a willed conspiracy. But with Red Hat being a for profit organization, anything that bring in the cash in the short run will be given priority...
Any good suggestion?
Its not like Debian "requires" gnome or kde or whatever as part of the install. Just install what you want.
Not sure though, I'm not super informed about what Debian is planning for the switch.
I think (no experience, but it makes sense) that Gentoo lets you pick the init system easily at install, you might want to look at that.
You might want to try it though. In my experience, the minimal config for systemd is quite lightweight and clean. I don't use KDE or Gnome, but I quite like systemd on my Arch workstation. Arch (and Fedora) have had it for quite a while now, even back when it was probably a bad idea to switch...
systemd-shim? Well, yeah, but that's the entire point of it's existence.
You'd probably have some of the same people complaining if you tried to "evolve" SysV.
I guess things are pretty good right now in the Linux world if this is the thing to argue over.
Parallel boot, sure. But you can always drop runit or openrc or something similar on top and get it already.
socket based service start, (hardware) event based, pass.
Frankly the core of sysv, the init binary, does very little. It sets up virtual terminals and fires up one or more processes (that it will keep an eye on and maybe restart).
The latter processe(s), most commonly a shell script of some kind, are what do the actual starting of "services" and managing of runlevels etc.
This is a very flexible system, as most of the logic involved is easy to get at. It is housed in interpreted scripts rather than compiled C code.
you can even run the scripts directly in a root shell if you have the need to do so (or perform the scripted commands manually).
Basically the scripts do little more than what someone would do manually if they were presented with a bare shell after kernel boot.
I'm particularly excited about socket activation for my servers, as well as auto-remounting of network shares if connectivity is lost (my laptop on/off wifi or traveling, etc).
I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it". systemd is a collection of smaller tools, which is the UNIX philosophy (debunking that argument). It can be replaced as per this article and if software projects don't explicitly bake in hard-dependencies (but even then there are ways around it like shims and what-not that several people have built).
Distros are looking around at all the available init systems, and a large amount are deciding systemd offers something more than the rest, and then going with it. (you can review the debian debate for gritty and technical details). There really is no reason to be so angry at systemd.
systemd might be a collection of many small tools, but they don't compose well. Dbus isn't a substitute for piping little blobs of text between stdin and stdout of a bunch of different programs that are utterly agnostic of each other's existence.
And systemd might well be great. Aesthetically, I don't care much for it, but I'm using it with no problems, so I guess it's fine. But it's not "the Unix philosophy".
I'm guessing you want more then that though right?
ForwardToSyslog=True
or
systemd.journald.forward_to_syslog=True on the kernel command line.
Is it just cool to not read documentation anymore?
Systemd components are NOT interchangeable with something else, so let's stop pretending they are. Please.
[1] CentOS and RHEL 7 ship with an earlier version of systemd, and I'm not sure if the packages have been patched in some way or not to fix this. If not, good riddance if you are a sysadmin trying to pass core dumps along to developers.
Theoretically my configuration would look like rsyslog linking in a compatibility library and having something like this small config snippet from /etc/rsyslog/rsyslog.conf of the future:
# Connects rsyslog directly into the innards of systemd
$ModLoad systemd
I wouldn't even have journald installed on my system, at all. No config file named /etc/systemd/journald.conf, none of that. Just rsyslog.
That's like saying HN website is composable with emacs because I wrote this on emacs and then cut and pasted it into the browser. Really being composable would imply meta-x post-buffer-to-hacker-news direct API on emacs.
It doesn't really matter to me because systemd is going to force me to convert my systems to freebsd. But if I was staying on linux, I'd like systemd to at least minimally cooperate with the rest of the ecosystem instead of spreading like a cancer.
In ISC DHCP (I don't know if systemd is handling dhcp or not), you can add shell scripts as pre or post configuration hooks. I set up a cluster where the local hostname is set from DHCP/DNS, rather than vice versa.
But mostly, like I said, it's just ugly. D-bus? Binary logs? Sure, you can build a working system like that, but just ugh.
I don't get the hate, I love it.
The argument is really that given that systemd as a project does a hell of a lot, it's actually really hard to replace bits of it - as people who are trying to are quickly finding out, there's a few dependency trees for various components which end up requiring that systemd manages most layers of the system. So you either use all of systemd, or as little of it as possible.
According to Lennart Poettering himself, udev is going to end up depending on systemd being the init system. udev! It'll be damn near impossible to replace systemd then. (And anybody who wants to use anything else, or even have the choice to use anything else, is a "systemd-hater".)
That's not debunked. The small tools of the UNIX philosophy are supposed to compose well with others. If I want to replace systemd's init with that from daemontools (for instance) and keep the rest of systemd working, that should be possible.
Or let's suppose that I want to opt in to systemd's auto-remounting and socket activation (for instance), but for whatever reason I need to keep my syslogs as text on disc, so I can't use systemd's binary logs but need my legacy syslog system. Can I do that?
> I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it".
The arguments I've heard boil down to "it's badly designed and therefore I don't want it."
/etc/systemd/journald.conf ForwardToSyslog=True
I'll just say, a GNU/Linux distro has many components, but they're not monolithic because they integrate well, you can do ls|grep etc, you know this. But if we want to change one component of systemd, we can't do it! You see? A lot of components, but they comprise a blob and can't be separated or used individually.
I also have a suspicion there is a more friendly way do what PolicyKit provides, which is not at all very transparent to an administrator. You could easily trust software with privileges without realizing it. There are also concerns about the hard dependency on these utilities for GNOME, but I don't use it myself so I don't know if the concerns are valid or not.
I believe however most of the criticism centered on how udev was dropped as a separate utility, despite concerns from other developers, and the way people who tried to keep feature parity in a stand alone fork was treated. They was basically told they were regarded as downstream developers.
This is mostly water under the bridge now of course, but it makes cooperation a lot harder than it should be.
http://lwn.net/Articles/512895/
And rsyslog can cryptographically sign logs too nowadays:
http://blog.gerhards.net/2013/05/rsyslogs-first-signature-pr...
I found a message that might shed some light on it:
"[...] Let me turn your question around: we swapped out one of the most central pieces of Linux systems, one of the pieces that is probably the most core of what administrators interface with every day. How could this change ever have gone without any noise?"
http://lists.freedesktop.org/archives/systemd-devel/2014-Oct... (read the whole message, it's quite interesting).