The main reason for forking seems to be opposition to SystemD. Initially I was unconvinced but then I remembered the recent story of Lennart Poettering (one of the authors of SystemD) on The State Of Open Source Communities where he describes the hostility towards him personally https://news.ycombinator.com/item?id=8414859
In light of that, forking is a more civilised approach than bullying and threatening the author.
Lennart Poettering is a bully himself, with a well-documented instance where he continuously interruped a talk at the 27th Chaos Communication Congress, even going as far as taking over the stage while insulting the presenter. Lennart Poettering is a toxic person, toxic to the OSS community, and he's the last person that can complain about bullying.
You mean that famous talk when the very poorly prepared presenter ("Datenwolf") took the stage to trash-talk and spread misinformation about large parts of the Linux Desktop, evidently oblivious to important requirements like accessibility that modern desktops such as Gnome and KDE are designed to meet, which LP had to correct by comments?
This is the talk you mean right? Have you actually seen the talk? Yes, Lennart interrupts the talk but everything he says is correct, while the presenter just spreads random FUD.
The presenter clearly shows that he doesn’t understand most of the stuff he talks about, talks about 3 year old bugs that already got fixed, etc.
Yes, it’s not the nicest way to interrupt a talk, but the presenter should have expected some kind of reaction, given the controversial headline.
People like Lennart put their heart into their software. If you shit all over it and spread random FUD, you can expect some response. What would you have done?
Also he doesn’t “take over the stage”. He comes up after the talk has ended, because people on IRC asked him to.
The way Lennart interacted with the speaker during that talk was extremely inappropriate. If he had corrections to make he could have arranged a short talk afterwards or a written blog post. It is very poor form to be so disruptive to a speaker, no matter how much you disagree with them.
No it isn't.. being on a soap box doesn't give you some special permission to just spread false information without being interrupted. I heard this argument before, there was an article about book reviews, and that authors who interacted with reviewers (by writing on their own blogs about them or on twitter) would be labeled Bad Behaving Author and be shunned by the review community. What's up with that?
If someone talks shit, he should be challenged as soon as possible, preferably in front of the same crowd they are talking shit in front of. If you take the opportunity to talk in front of a lot of people, you should also take the responsibility to be properly prepared, and be ready to face the consequence of not performing adequately.
Let's get this straight: he's not on a soap box (a term that refers to people who shout at passers by on the street), but rather at a conference at which he was invited to speak. The audience came into the room to hear him give his talk. Lennart rudely interrupted this.
> I heard this argument before, there was an article about book reviews, and that authors who interacted with reviewers (by writing on their own blogs about them or on twitter) would be labeled Bad Behaving Author and be shunned by the review community.
That's not my argument at all. I specifically suggested he _should_ respond with a blog post. Don't put me in the same group as those people. I encourage anyone to share their views on their own blogs, in comment sections, and on Twitter.
> If someone talks shit, he should be challenged as soon as possible, preferably in front of the same crowd they are talking shit in front of.
I disagree that it is appropriate to interrupt and shout someone down just because you think they are "talking shit". The definition of "talking shit" is subjective. If someone is interrupted before they can make their point, then the observer does not have the ability to judge whether they are right or wrong. It instead becomes a matter of whoever has the best rhetorical tactics. (Or who can shout the loudest.)
My job involves giving a lot of talks, and if someone were to engage with me like this I _would_ be prepared: I'd be prepared to tell them to wait until I have finished my talk and address their comments afterward. This has happened many times, and it worked out fine for all involved. It's called civility.
> Let's get this straight: he's not on a soap box (a term that refers to people who shout at passers by on the street), but rather at a conference at which he was invited to speak. The audience came into the room to hear him give his talk. Lennart rudely interrupted this.
I was actually there and the talk was so much better for this. Also, I don't think the Chaos Communication Congress is that much like a business conference. It is hackers and people who care about software, not so much for proper manners.
If I remember correctly, Lennart specifically came to the congress because there were rumors before that this talk will be bashing Lennarts software, so it was no surprise to see him show up.
Yeah, especially if everything what he wrote there was like that bitcoin hitman stuff, which turned out to be just a line like "maybe we should start btc fund?" from IRC written after someone else complained about issue with systemd by guy known from his funny trolling there - and absolutely nothing more than that.
While at first I felt a bit sorry for him when I read that post, after I learned about what exactly was that "hitman threat" I lost any remaining respect to Poettering. That's just grabbing attention and playing victim. He deserves negative response for that.
> I'd really welcome the anti-systemd ranters to just do some work that makes them feel happy, such as making a new distribution that has the exact init system they want.
Most people are already working on things that make them happy. The frustration here is that the tools they depend on are changing... in a way that they don't like.
They also have limited time for projects. Any time spent fixing other peoples projects is time they don't spend on their own projects.
I left the Linux desktop world nearly 10 years ago, for these kind of reasons. I use a Mac as my desktop, because I don't have to fight with it. 99% of everything works, and the other 1% breakages are ones I can live with.
You know, provided Apple continue to agree with you...it seems more like you're just zenning over the fact that even if you did disagree, you couldn't change anything.
Choice is widely regarded as actually making people more unhappy.
EDIT: It's also an ironic comment, since a frequent criticism of systemd is that it's trying to be too much like Apple's launchd.
I'm not "zenning over" anything. I need a computer to get work done. I don't need to be mucking with the computer to keep it working.
My choice is to use a (mostly) closed system, because it meets my needs.
Other people don't like systemd because they feel it removes their choices.
There is no contradiction in the two approaches. There's also no irony.
If Unix had started out with something like systemd, fewer people would be complaining about it now. It's the change that people don't like. And the apparent removal of choice.
> In light of that, forking is a more civilised approach than bullying and threatening the author.
Yes, but it is sad that the more straightforward approach of contributing back to the community isn't taking hold.
If you are worried about mission creep... you help stamp out a very clear mission. If you are worried about bloat, you contribute patches. If you are worried about a nasty hairball... you contribute code reviews. If you consider C code less readable than Unix shell... please don't reference the Unix Philosophy as the principle behind that thinking.
forking is a more civilised approach than bullying and threatening the author.
Absolutely, in that almost anything is. :)
But specifically, at this point I'd really welcome the anti-systemd ranters to just do some work that makes them feel happy, such as making a new distribution that has the exact init system they want.
I suspect that Debian would love for them to do that as well. Debian is in general welcoming of downstream distros since the downstream distros—if given proper care and feeding—often feed back useful improvements to Debian.
The problem here is that no one is actually doing a fork (yet). Some of the same loud, uninformed minority have just created a ranty web page that presents a skewed view of history and makes threats. It's just more of the same interminable mailing list snarks but in web page format.
Trying to put out and support an entire distribution may serve to broaden their minds as to the delicate position the distribution is in with regard to integrating upstream work into a coherent whole.
Sadly I'm not convinced that any enlightenment is going to be achieved because the people behind this web site admit that they haven't even got the time to become involved enough in Debian to have a vote, so I don't know where they're going to find the time to launch a non-toy distribution.
I saw that as a giant red warning flag as well. Why would I expect them to maintain a fork and ensure it has full sysv init support, if they don't even have the time to engage in the current process?
It's all a bit overdramatic anyway - there are heaps of Debian forks; they're called 'downstream distros'. Ubuntu is one.
> Why would I expect them to maintain a fork and ensure it has full sysv init support, if they don't even have the time to engage in the current process?
Probably because they (experienced Unix veterans) realized that it makes much more sense to test the demand of a fork (that's what they made the website for) than to continue any useless discussion about systemd. Some systemd proponents obviously have serious problems to make a sober discussion anyway (interestingly also in a prominent German forum).
Notice: "If SystemD will be substituting SystemV in Debian, we will fork the project and create a new distro: Pure Debian by Veteran Unix Admins. We hope this won't be necessary, but we are well prepared for it."
They are not eager to make a fork but I think they will actually do it if necesary.
The anti-systemd-brigade only seems to be a small minority of Debian devs (though they're very loud, and very persistent), so I'm not sure it would have much effect on the project as a whole.
If a fork would reduce the time spent arguing about the init system (which 99% of users don't care about), it could even prove beneficial for Debian.
[It seems unlikely the fork would attract the critical mass of devs/users to succeed on its own though.]
Decoupling systemd is a feature desired by system administrators, who are responsible for installing and managing most debian and debian-based distros.
on the contrary, systemd is a feature desired by system administrators, who are responsible for installing and managing most debian and debian-based distros.
I have. I ran Arch for 3 years, up until 3 months after they implemented systemd. It made a KISS situation incredible complex. I switched back to Debian on my desktop after that. If Debian switches to systemd, I'll switch to Slackware, until SystemD has proven iteself to be stable and simple to administer. Not before.
I've installed systemd on Debian testing months ago and have not had a single problem. https://wiki.debian.org/systemd has some hints.
I think it's likely when Jessie is released you'll most likely find that stuff still works.
Is that because you think it's somehow technically inferior or because you you've learnt a whole bunch of skills and don't really want to have to replace them? I mean, would you like to see the init system change, period?
There's a whole lot of "I don't/do like it" and "It did/didn't work for me" but not a lot of explanation of why they do or don't like it, or what didn't work, and I'm interested in those details.
I'm not even "anti-systemd". I'm actually in the process of implementing systemd for the firmware of an embedded target in $dayjob because socket activation is actually a good idea and happened to work well when I played with it.
But a switch to a different init system shouldn't break your system so badly that it no longer boots. And yet that's what happens if you rely on keyscript to unlock your drives in /etc/crypttab.
Racy code has issues with race conditions. Any error in setuid executables can be very dangerous, so they are strongly discouraged. However, once you've decided that you have to write a setuid program, there's no particular reason to not write it in a scripting language.
As a datapoint, the KDE folks think that using scripting languages for setuid executables is okay:
/usr/lib/kde4/libexec/fileshareset: setuid Perl script, ASCII text executable
During boot - before the rootfs is even mounted, what kinds of exposure are you thinking of that's worse than the shell scripts which already make up cryptmount labyrinth? Some sort of `() { :;};` response from the smartcard I'm querying? If I can control the smartcard response, wouldn't I also be able to crash a similarly badly-coded custom C program which does the same?
Only in the future it may use kdbus for some purposes (eg. uploading firmware blobs), but this will only affect internal interfaces.
On the other hand, systemd does not require the D-Bus daemon when you're launching systemctl it as root, the D-Bus daemon is only needed to route the call when used by unprivileged users. When used as root, systemctl connects to the PID1 socket directly and D-Bus is basically just a serialization protocol (and systemd does not depend on libdbus either).
To be fair, udev communicates with the kernel via netlink. All the userspace notifications are done via dbus. So dbus was already part of the equation whether people realize it or not.
You raise a good point. I hadn't considered a shell based init system where the shell scripts only run at startup and aren't available to run at any other time.
You mentioned smart cards... what system would handle when you connect a smart card after boot?
The trigger is the appearance of the volume. If the mounter actions crypttab properly it'll run the keyscript which challenges the smartcard or TPM or USB crypt token or some combination thereof, which in turn provides the response to cryptsetup.
By default nothing happens when you insert a smartcard; if the keyscript tries to run without the smartcard it will retry, timeout, and eventually fall back to askpass. If there's a LUKS keyslot with a backup passphrase which can be entered by a human operator at the tty, this also serves as a disaster-recovery mechanism so that you can afford to lose the LUKS keyslot associated with the token/smart card.
I'm sorry. I wasn't clear. I was asking about the work that gets you to the point where the volume appears. You don't necessarily have a device file for the volume, so something needs to be ready to handle that logic when the device is inserted, then when it has figured that out, you have to notify the automounter that it is time to go to work (or not), etc.
Now add logic so that all of this magically gets powered down all the time to conserve power (and then figure out what you do with the filesystem when that happens).
Now handle the case where you have a bad connection so it is constantly flapping as inserted & not.
Now handle the case where it gets ripped out with no warning.
Now handle the case where you have a smartcard and you are using it to provide the key to decrypt another smartcard...
I think I get your point, but for what it's worth the sysvinit cryptroot/crypttab setup has worked seamlessly for servers for years. Basically if keyscript fails (smart card not available or challenge material not available or TPM won't unseal) it falls back to ask pass on a TTY with the hopes that you can type something in.
I also do appreciate the systemd features for mobile and desktop devices.
But the sysvinit mechanisms aren't rendered completely irrelevant by systemd; the sheer stupid dumb luck of the the thing is actually deterministic and repeatable in my experience. systemd migrations have exposed hidden dependencies I hadn't previously had to worry about between services, which is good in one way, but not necessarily good in other ways (transient intermittent failures which never occurred under sysv).
Yes, it's unfair to blame systemd for poorly defined services - I do like the concept systemd is offering in that respect. But if I have servers in the rack which have smart cards in them that I know are always attached except for very rare events where a sysadmin will be dealing with things, I don't think there's harm in a 4-line shell script failing maybe once or twice in a server's lifetime if it means not having to maintain bespoke C programs for years and years
You can still use a keyscript (I do), it just need to be done in a different way. Instead of putting the configuration in /etc/crypttab, which confuses systemd indeed, you can still use the kernel cryptopts variable. For example, in the grub configuration add something like:
Anf then in /etc/fstab use the /dev/mapper/<target> (sdc5_crypt in the example above) as the root device, as before.
Then you need to make sure the initramfs contains all the tools needed to support this (that was done automatically with /etc/crypttab, it's "manual" with the kernel option). To do this, add under /etc/initramfs-tools/hooks a script file to load what's needed in the initramfs: cryptsetup, passdev, the needed kernel module. You can roughly copy the existing /usr/share/initramfs-tools/hooks/cryptroot and simplify it.
I've seen other distro documenting the kernel approach instead of /etc/crypttab for the root filesystem. It may become the standard way in the future, and there's no reason it couldn't be fully automated. There's some coordination between several components so it may take a bit of time to converge to an accepted and supported way thought.
Thanks, I appreciate the hint, I should have noticed that a kernel parameter would be one way to do it (I'm familiar with writing initramfs-tools/hooks to make the existing keyscripts work).
The fact remains though that a wheezy dist-upgrade is going to ruin your day badly enough to spend some time digging up your iDRAC/whatever creds (admittedly, nobody is going to dist-upgrade their prod servers without testing first... or are they? :P)
> The anti-systemd-brigade only seems to be a small minority of Debian devs (though they're very loud, and very persistent)
The pro-systemd brigade only seems to be a small minority of Debian devs (though they're extremely loud, and trollishly persistent).
I've thought for a long time that they must have a place where they all hang out in secret and share links to discussions where they need a pro-systemd response / a handful of downvotes.
In this way they give the impression that their numbers are much larger (the reasoning here is that for any given post or discussion, if the number of "ambient" / "organic" critical comments or downvotes that it receives is a proxy for how critical the community at large is, so by sharing links they make it seem like there's a broad base of support for systemd).
This kind of thing seems to happen periodically, where a person / group of people railroads a decision using methods that are outside the "accepted" set of methods for OSS development, namely meritocratic discussions.
Who knows what their motivations are. It probably varies per person. Having "I designed and implemented a new init system and got all the major distributions to adopt it" on a resume is a huge demonstration of "impact", which is something that really pays off in a lot of companies / organizations.
Using the same argument, forking would seem like a horrible idea if there isn't active maintainers.
Until I saw that line, I was thinking: well quit talking about doing it, and just do it!
The idea of a non-systemd distribution in general is something I've been expecting to pop up for a while. And if the vocal people online represent a real desire not to switch, then one really should exist. Beyond that I'm rather uninterested in such a project one way or another.
The trouble here is that the bulk of the work is just maintaining a changeset to debian packages. They haven't even spun up dak and friends, so I'm assuming this is DOA for now. It seems like a lot of hot air to pressure debian, or at the least attract contributions that can maintain their fork. Is "fork" a scary word to any DD, considering debian is already the upstream distribution for other, more popular, derivatives?
The issue is that Gnome, KDE, and other software requires systemd. You need to fix/maintain their compatibility with other init systems. Then it is easy for Debian user to switch init systems.
You listed two desktop environments, neither of which are of interest to sysadmins.
Eg. I run an Openstack cluster and do not care if there are gnome or kde packages available. I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.
The idea of a server based fork of Debian is kind of appealing in some ways, like the Fedora server and cloud projects[1][2] which are quite interesting work, aimed at a (sub)distribution with focus on particular use cases, not the kitchen sink approach.
I'd be running it on my desktops. All I need is a way to spawn chromium and emacs and consoles (I like konsole, but if it drags in too many dependencies I'll put something else on).
If/When chromium depends on systemd (WTF, a web browser / page renderer logically SHOULD depend on your init system, of course) then I'll use another browser... somehow.
I'm in a similar position with regard to those (or any) desktop features not being relevant for most of the systems I administer.
I'm kind of irritated about having to learn a whole set of new things. I do recognise that there are some benefits for my use case in systemd. The desktop stuff aren't the only things that systemd brings.
More than that though, is the fact that it's going to be the new default everywhere. So while you say
I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.
I think you (and I) will actually face more work in trying to avoid systemd than convert to it. You'll be fighting against your distribution's default and the default of every bit of third party software targeted at your distro. From what I have seen most conversions are fairly painless.
So from my position that sits somewhere between "ambivalent" and "that's kind of nice", going with the flow seems the easier path.
2) My position is between "that sucks" and "ambivalent"
But I do think that going with the flow is a much easier way. This isn’t a fight worth fighting if your concern is maintaining running systems. Of course it might be worth while to stay on an LTS release till the very last moment, to let all the bugs shake out.
Probably not software like Apache and Postgres, no.
But when systemd is the default init system on almost every Linux distribution, new software will have the systemd integration written first and tested most.
> The issue is that Gnome, KDE, and other software requires systemd.
This I can't wrap my head around, why does Gnome for example need systemd? There are standard ways on GNU/Linux to do everything it needs in a unix fashion (by deferring to small specialized tools):
shutdown
reboot
whoami
uname
mount
...
These and similar tools (or libc functions) give you all information you need (username, etc.) and system functions a desktop environment needs (reboot, hibernate). You then only need something like udev for plug-and-play (which is available without systemd, and as a part of it), and interfaces to the X/Wayland server and the audio system (which are both not a part of systemd). This seems to be all stuff that can easily be abstracted away in one module per OS. I don't see why you have to tightly couple your DE to systemd. (Unless, you are using your DE as a vehicle to push systemd, which I hope is not the case...)
Systemd provides interfaces to reboot/shutdown as non root api which is controlled by polkit. It also allows a non root process running as part of an active session to get the DRM FD and other device FDs as part of the logind interface.
It's big, gnarly, essentially undocumented, and contains a bunch of features to support tricky cases like multiseat machines (systems with two or more sets of keyboard, mouse and monitor, each with a different user) that are rarely used but still need to be supported because the API's designed around them. Even the systemd developers don't think a reimplementation is feasible.
A bad thing about systemd and where we are now is the ever-changing API that is mentioned, which hampers alternatives to systemd.
But, that is where we are now, Debian isn't in much of a position to change that, and forking probably isn't going to help with that. Debian wasn't ignorant of that either; these issues were discussed at length in the tech committee debate that originally settled on systemd being the default for jessie.
KDE doesn't require systemd. The KDE folks are still concerned about operating on the BSDs. Some of them are still concerned about running on Windows [0] and OS X [1].
Elias Probst:
"Reading the comments shows a lot of misconceptions about +Martin Gräßlin's proposal [to use systemd features to make Plasma startup under Wayland a little bit simpler]:
* KDE SC will still allow to use the old-way to startup a KDE session, as it will still ship the X11-way of doing it for [BSDs]. If you want to use a modern Wayland/systemd stack you're fine by using the defaults. If you don't want to: use the old X11/script startup stack.
* KDE SC won't enforce using systemd as init-system by this change. Instead, it will use parts of systemd which are completely independent from the init-system being used to handle the startup of the KDE session. If systemd is being used as an init-system, that's a plus because of some systemd integration effects, but that's all about it."
Go ahead and fork. Just leave me alone while I enjoy using systemd.
I think some people are taking this way too personal and overreact.
Forking is probably the best way to stop all the whining.
A fork would also mean that Debian (systemd edition) would not have to keep legacy init script support. You could have a 'clean' systemd in around Jessie+1 I imagine.
Debian already supports non-Linux kernels on which systemd won't function. So the legacy init support (or a compatible alternative) will still be required.
But I won't be surprised to see them come slinking back in four months with their tails tucked when nobody's actually maintaining any software for the fork.
Yes. My spidey sense has been tingling about a Debian fork, given the facts mentioned on the link, consistent problems with at least one of Lennart Poettering's previous projects (pulseaudio), and the strong likelihood that politics played a bigger part in the "adoption" of systemd versus technical merit. If the answer from systemd people is that we have no choice but to use systemd, then I hope that a fork happens, and I will contribute a lot to that project, despite the trite downvotes these affirmative comments get.
One thing I struggle with: how does one calibrate one's spidey sense? Reading comments in online forums is likely to bias one towards the people talking the most, which is not a good bet as a representative sample. It's not just systemd; it's any topic of heated discussion. All we hear from on many topics are the people with the strongest emotions. How can we compensate?
While I agree with the concept of supporting multiple init systems, I don't quite understand why they'd want to fork it out into an entirely different distro.
Isn't it possible to do this with patches, similar to how the linux kernel has RT patches?
No. Even the pro-fork advocates (even the above article) see the Jackson / Vernon proposal as a much better idea (choice of init systems with a systemd default)
No. IMHO Debian is less a distro than a democratic experiment - and systemd shows it is working. If you don't like systemd (and I vastly prefer my FreeBSD world) get on board with the democratic process - it is always messy, frustrating, driving you insane slow. That's how you can tell it is working
Just use coreOS and docker on the server and leave the init system discussion to the desktop people.
There are some fundamentally different and sometimes conflicting requirements regarding the startup process on a server and on a desktop machine and I think systemd which is obviously desktop driven will be the catalyst for a split between server and desktop distros.
I don't think classical desktop environments have much future personally, but that's just my gut feeling.
Server will definitely move further into modularization of services, and that will make init systems there less and less interesting.
CoreOS is entirely based on systemd. Fleet is a distributed systemd. It is far more systemd oriented than any other distro, having built it in as a core feature form day one.
If Ritchie and Thompson knew the damage fork-ing would cause to the open source community, they would have never implemented the idea, as a system call in UNIX[1] in 1971.
I don't think that they care(d) much about "the open source community". And why do you think forking causes damage to the open source community? It helps resolve conflicts of interest.
I know they didnt care (there wasnt any significant OS community at the time) and even if they did its not reason to remove a core feature of like fork, because someone might abuse the idea.
It was a kind of pun to state my disaproval to level of fragmentation the linux community has gotten into.
Okay this SystemD saga might or might be AS important as some people tend to think. But fragmenting the community so much and having people working to 10 different, unstable solutions instead of 3 stable ones, its a waste of resources IMHO.
Indeed. Reducing fragmentation is one of the reasons many distribution maintainers liked systemd, since it replaces tons of special snowflake tooling that every distro reimplemented differently with one common upstream (eg. set the hostname, configure binary formats, where to store the OS release name, etc.)
The website could be replaced by a much shorter version simply stating "I dont like SystemD. -anonymous".
The author is essentially making a threat, that there will be a fork of Debian if the project does not give in to his demands. Then he states that he is totally not just speaking for himself, but for a much larger group, and in fact claims to have the majority on his side. I have a hard time evaluating the seriousness of these claims, as there is no intend to back up any of this.
As far as the arguments go, there is nothing new here. The concerns have been stated before, and have been heard, too.
Also, critique starts with "We like controlling the startup of the system with shell scripts that are readable".. How on earth is a systemd service file less readable then a hundreds of lines bash script?
I read the 'shut up' line in the post above yours as more along the lines of 'do something useful, post bugs, show some commitment' rather than 'shut up systemd is the Only Way'.
Perhaps the sponsors of the linked site are doing bug reports on packages like systemd-shim and others. Perhaps the upstream project members involved are ensuring that they have init scripts for systemv available. They could add a question with links along those lines easily.
This sentence (if it's not obvious) is a hint to invest energies into making debian work fine without systemd instead of countless whining and crying but in the end doing nothing.
There may be some people opposed to systemd, but there have been votes that saw systemd as the clear winner for the default init system. Why should the majority of users who are FOR systemd bending to some users who don't like systemd out of some philosophical view? Instead of behaving like a little child, people can work on letting Debian run fine without systemd (which IS the fact today, i can simply switch between sysvinit and systemd just by installing a package).
And in the end, you should remind yourself that this is only about the default for one linux distribution. You will still be able to use sysvinit if you like. There is choice. The majority wants systemd. The minority wants sysvinit. Only because the opposers are loud and make a lot of noise about this doesn't change the fact that they are a relatively small number. Changing the default is the only sane thing to do.
> people can work on letting Debian run fine without systemd
Arch switched to systemd about a year ago. When official distro packages are shipping with systemd service files by default, it means there is drastically less effort required on your part to maintain a systemd-based environment. It would take an experienced and dedicated crew to translate the systemd service files of dozens of upstream packages to Runit for instance. The enterprise level support just isn't there, whereas with systemd it is.
That being said, I like writing systemd service files. I just wonder what would happen if more distros pushed for, e.g. uselessd or Runit as the standard init system.
> uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint) is a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design.
Just curious, have you ever used systemd and ran into a problem where your service file screwed up and you had yo read systemd's source code or are you making this up?
I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out.
took me some time to figure out it was systemd.
the firewall wrapper for iptables gives you an insecure default config and is hard to fix via config management "add a service that means port 3128 TCP, now allow incoming connections"
My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it.
> My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it.
You should be laying down a base initial configuration at the time that the machine was provisioned. The basic example of this is the sudoers file. The default setup for Ubuntu/RHEL is different enough that it was causing problems and the solution was simple - force defaults.
> I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out.
> And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script.
? You end up diving in to the service file vs. the script.
> And don't get me started on binary log files.
Having worked with binary and plaintext log data for the better part of a decade now, I have to say that pretty much the entire set of claimed advantages of plaintext log data is very wrong, and we've wasted a ton of productivity & efficiency because of it.
If you really are sure of its superiority though, just put a little stub in front that converts the binary log to a human readable format that still needs a program in order to present to the user...
> SysVInit has served me thus far with no issues.
Speaking of attitude... there are two ways to look at that datapoint...
And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script.
That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script.
your attitude is the problem
The attitude here is to fix problems at their source. Instead of using the hammer for everything, sometimes coming up with a new tool is a better idea.
That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script.
Generally I agree with this at a broad level. But, there is still the problem of: I need this running now. To do that, I need to compile and run a custom systemd, and hope that my patch gets accepted upstream, and that in a few months my distro finally adopts it and puts it in the standard package.
Generally speaking I really like systemd and am excited to get some time to update my installed stuff to use it, but the above is a real concern.
We have SysV shim layers for that though. We had them in Upstart, and we have them for SystemD. Boiled down, it can still run shell scripts that look like SysV scripts, and will be able to do so indefinitely because that's basic functionality.
At the worst case though, this reduces systemd to a shim-launcher for SysV init, which is the situation you find yourself in now or when using Upstart, which tons of Ubuntu users already have been.
> And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script.
Surely the systemd equivalent would be delving into the source code for dash, or god help you dash... I know which one I'd prefer--not that I've ever hard to do either, fortunately!
It would be nice for those of us not in the know to see an example of more-or-less similar configuration expressed in the respective systems for comparison. Although I tend philosophically towards the declarative route, I don't really have a good understanding of the issues involved in this specific instance - but I'd like to.
I dare you to tell my why lxc-docker silently fails to start at boot in jessie. Without a single shred of clue in any log, no matter what logging options are turned up - at least with a shell script I can add some echo/exit/touch etc. statements to convince myself it's at least being noticed at startup: https://groups.google.com/forum/#!topic/docker-user/bg5-hlmR...
The next step in troubleshooting that one is to run strace and find out what's happening. I agree it's frustrating but if no one debugs these things, problems won't get solved. (and yes, scorching the earth and installing a different distro is a valid solution to the problem at hand)
I'm not sure how to make strace pid 1 :-) And I'm not quite ready to abandon Debian yet. I've created a virt-install script which reproduces the problem reliably (honestly all it does is install jessie, then lxc-docker). Hopefully my workload eases and I can put this trivially reproducible thing into a bug report somewhere (debian? systemd? docker) for somebody to see what's going on.
FWIW systemctl start docker works fine after the system has booted. It's configured to require network.target, and even though I can see network target scroll by during boot, it's still not being noticed.
The work-around is to make multiuser want docker, then I've got docker starting at bootup.
Sounds like lxc-docker.service simply wasn't enabled. "enabling" is basically creating a symlink from multi-user.target.wants to lxc-docker.service. This is done by 'systemctl enable lxc-docker.service' once that service declares WantedBy=multi-user.target in its [Install] section.
Other symptoms that would indicate this was the problem would have been that 'systemctl status lxc-docker.serivce' would have said "Loaded: loaded (...; disabled)" and "Active: inactive (dead)". i.e., systemd never started the service because nothing ever wanted it.
strace -p1 should do the trick, you can attach after start, but you will have to get it started early, probably as a systemd service. Or if its in a container, strace form outside the container.
> I dare you to tell my why lxc-docker silently fails to start at boot in jessie. Without a single shred of clue in any log, no matter what logging options are turned up - at least with a shell script I can add some echo/exit/touch etc. statements to convince myself it's at least being noticed at startup: https://groups.google.com/forum/#!topic/docker-user/bg5-hlmR....
Have you tried adding "touch" commands in ExecStartPre/ExecStartPost? Systemd also gives you a hint of why something didn't start via "systemctl status $servicename".
No offence, but systemctl status isn't exactly new to me. The issue is that network.target apparently never fires any service which requires it (in Jessie at least). For what it's worth systemctl status docker shows it's just inactive (dead) - journalctl similarly shows no clues at all. I have a Debian pressed.cfg & virt-install script to reproduce if you're interested, https://gist.github.com/csirac2/f6e4ac6e7c715243d4b8 and https://gist.github.com/csirac2/57a1ddf7931fa3e9d17a although these aren't up to date with what I've been preparing for a bug report
Without doing any further investigation: does the type of service you're setting in your user file match the way you're starting up the daemon? For a "normal" service, you need to start the service as "normal" and have it run without forking / exiting (as systemd handles daemonization).
If you start a "normal" service using a command that double-forks and immediately exits (like a `--daemon` flag), systemd will see that the process has exited to mean that the service has finished, and will terminate any of its child processes (as you want runaway dependencies culled when a service crashes). This sounds like the behavior you describe.
Being a developer and being an admin are completely different jobs.
A admin needs to know a dozen languages and codes in bash most of the time, they have a hand written folder with glued in scraps next to their terminal which explains why they did what, how and why. This folder has entries like "reboot three times, do an rain dance and run godHelpYou.bash as root" because that's the only way that you've found out how the libraries actually talk to each other.
For people like this "do one thing and do it well" is the only way that you can beat the impossible complexity of a modern machine back into a running computer even some of the time. When you have a single point of failure which is a black box you're just back to windows land: restart the service, reboot the computer, reinstall the system.
From this point of view devs look like a tribe of monkeys building a shit pyramid over your village. They just keep flinging more shit at the top thinking they are the greatest ever monkeys. When the shit pyramid collapses and buries everything you know and love under a few meters of shit, probably killing someone in the process, these monkeys just shrug say a few words about how that was the best shit pyramid anyone had ever build and start making a new one one or two valleys over.
For people like this "do one thing and do it well" is the only way that you can beat the impossible complexity of a modern machine back into a running computer even some of the time. When you have a single point of failure which is a black box you're just back to windows land: restart the service, reboot the computer, reinstall the system.
For the developers, on the other hand, it might mean that some use case that is important for the admin is simply not yet implemented. The solution, as so often, is... drumroll to report a bug! Developers care about their users. Just talk to them.
Also, admins should realize that "reducing complexity" is a goal that they share with the developers. systemd is all about reducing complexity by implementing functionality the right way, on the right layer. For example, with systemd it's way easier to write a daemon, because it takes care of
* daemonizing: just stay in foreground
* logging: just output to stdout/stderr. journald will collect everything, and if you want, forward it to a classic syslog service
* startup: no more shell scripts required, just a simple service file
* supervision: just add "Restart=on-failure" to your service file. It also supports software watchdogs.
Different people have different definitions of complexity. For me having a single point of failure is complexity, for most people a centralized single process handling as much as possible is simplicity. Neither is right or wrong.
Whether a system is tightly coupled is independent of whether it's implemented as a single process. Objections to systemd as monolithic, as constituting a single point of failure, etc. are based on its being a tightly coupled set of components.
That systemd is tightly coupled is a valid objection, but "single process" has a specific meaning in this context and it implies a much worse design, with every component potentially taking down PID1. As far as I know, this is not the case in systemd.
And what happens when that single file doesn't work? The one time I had to deploy a custom service using systemd, there was no feedback as to why it wasn't working with service start. No error message, no guidance on how to debug online, no indication of where to look. By contrast adding it to a shell script just worked.
An init system should have a verbose mode that tells you exactly what steps are being taken to start a service and what the result of each step is. Maybe this will come later, but -given the guy's history- it won't be written by Poettering.
you're seriously suggesting strace as an acceptable form of troubleshooting?
Don't get me wrong, I love to bring out strace and will use it to solve all sorts of problems, but it really shouldn't be necessary use it near the start of troubleshooting.
> Also, critique starts with "We like controlling the startup of the system with shell scripts that are readable".. How on earth is a systemd service file less readable then a hundreds of lines bash script?
Bash scripts? Unless I'm really mistaken, startup scripts need to be written towards the POSIX shell. It's kind of like bash scripts except you pretend the year is 1985 and no bash versions released after that exists.
Not so convinced by this. "Those days are dead and gone and the eulogy was delivered by Perl." -- Rob Pike
Systemd in debian would have an easier time making friends if it didn't usurp PID1 for roles that are currently outside PID1, and if it didn't encourage software which is currently init-system agnostic to grow a dependency on a specific init-system implementation.
Looks like the Squeeze LTS project[1] could use some help[2] and the team proposing a fork are server type folk reading between the lines. Good fit of skill sets and a way of generating positive outcomes quickly to build confidence? So fork from squeeze forward updating strategic packages?
PS: I love the 'how long are your beards?' line. Obviously, I'd rather Debian didn't fork and that we kept choice for server people in one of the larger Linux distros just on an 'ecological diversity' basis.
You can do a window manager on top of X with systemv right now in Jessie [3], the '--no-install-recommends' option to apt-get is helpful. But the result will be seriously old-school. Its rather fun for surfing in cafes and wasting time on forums but for my day to day work (not programming) I prefer a full fat desktop like KDE/Gnome.
Sure, feel free to fork Debian. Just don't call your fork Debian or "Pure Debian" or anything silly like that. Debian is a registered trademark of Software in the Public Interest, Inc., and as we saw with the Standard Markdown debacle, people do not like when names of established stuff is hijacked.
There's a whole bunch of debian derivatives out there and veteran unix sysadmins don't necessarily have the skills to deliver this so not sure this is really all that news worthy until they create something.
283 comments
[ 3.5 ms ] story [ 262 ms ] threadIn light of that, forking is a more civilised approach than bullying and threatening the author.
This is the talk you mean right? Have you actually seen the talk? Yes, Lennart interrupts the talk but everything he says is correct, while the presenter just spreads random FUD.
The presenter clearly shows that he doesn’t understand most of the stuff he talks about, talks about 3 year old bugs that already got fixed, etc.
Yes, it’s not the nicest way to interrupt a talk, but the presenter should have expected some kind of reaction, given the controversial headline.
People like Lennart put their heart into their software. If you shit all over it and spread random FUD, you can expect some response. What would you have done?
Also he doesn’t “take over the stage”. He comes up after the talk has ended, because people on IRC asked him to.
If someone talks shit, he should be challenged as soon as possible, preferably in front of the same crowd they are talking shit in front of. If you take the opportunity to talk in front of a lot of people, you should also take the responsibility to be properly prepared, and be ready to face the consequence of not performing adequately.
Let's get this straight: he's not on a soap box (a term that refers to people who shout at passers by on the street), but rather at a conference at which he was invited to speak. The audience came into the room to hear him give his talk. Lennart rudely interrupted this.
> I heard this argument before, there was an article about book reviews, and that authors who interacted with reviewers (by writing on their own blogs about them or on twitter) would be labeled Bad Behaving Author and be shunned by the review community.
That's not my argument at all. I specifically suggested he _should_ respond with a blog post. Don't put me in the same group as those people. I encourage anyone to share their views on their own blogs, in comment sections, and on Twitter.
> If someone talks shit, he should be challenged as soon as possible, preferably in front of the same crowd they are talking shit in front of.
I disagree that it is appropriate to interrupt and shout someone down just because you think they are "talking shit". The definition of "talking shit" is subjective. If someone is interrupted before they can make their point, then the observer does not have the ability to judge whether they are right or wrong. It instead becomes a matter of whoever has the best rhetorical tactics. (Or who can shout the loudest.)
My job involves giving a lot of talks, and if someone were to engage with me like this I _would_ be prepared: I'd be prepared to tell them to wait until I have finished my talk and address their comments afterward. This has happened many times, and it worked out fine for all involved. It's called civility.
I was actually there and the talk was so much better for this. Also, I don't think the Chaos Communication Congress is that much like a business conference. It is hackers and people who care about software, not so much for proper manners.
If I remember correctly, Lennart specifically came to the congress because there were rumors before that this talk will be bashing Lennarts software, so it was no surprise to see him show up.
IMO this is the attitude that encourages toxic behaviour in the open source community. Hackers should not be exempt from standards of civil discourse.
While at first I felt a bit sorry for him when I read that post, after I learned about what exactly was that "hitman threat" I lost any remaining respect to Poettering. That's just grabbing attention and playing victim. He deserves negative response for that.
Most people are already working on things that make them happy. The frustration here is that the tools they depend on are changing... in a way that they don't like.
They also have limited time for projects. Any time spent fixing other peoples projects is time they don't spend on their own projects.
I left the Linux desktop world nearly 10 years ago, for these kind of reasons. I use a Mac as my desktop, because I don't have to fight with it. 99% of everything works, and the other 1% breakages are ones I can live with.
Choice is widely regarded as actually making people more unhappy.
EDIT: It's also an ironic comment, since a frequent criticism of systemd is that it's trying to be too much like Apple's launchd.
My choice is to use a (mostly) closed system, because it meets my needs.
Other people don't like systemd because they feel it removes their choices.
There is no contradiction in the two approaches. There's also no irony.
If Unix had started out with something like systemd, fewer people would be complaining about it now. It's the change that people don't like. And the apparent removal of choice.
So there you are, happy with a radically non-traditional Unix environment (no X, launchd is one of the patterns systemd is copying, etc).
Yes, but it is sad that the more straightforward approach of contributing back to the community isn't taking hold.
If you are worried about mission creep... you help stamp out a very clear mission. If you are worried about bloat, you contribute patches. If you are worried about a nasty hairball... you contribute code reviews. If you consider C code less readable than Unix shell... please don't reference the Unix Philosophy as the principle behind that thinking.
Absolutely, in that almost anything is. :)
But specifically, at this point I'd really welcome the anti-systemd ranters to just do some work that makes them feel happy, such as making a new distribution that has the exact init system they want.
I suspect that Debian would love for them to do that as well. Debian is in general welcoming of downstream distros since the downstream distros—if given proper care and feeding—often feed back useful improvements to Debian.
The problem here is that no one is actually doing a fork (yet). Some of the same loud, uninformed minority have just created a ranty web page that presents a skewed view of history and makes threats. It's just more of the same interminable mailing list snarks but in web page format.
Trying to put out and support an entire distribution may serve to broaden their minds as to the delicate position the distribution is in with regard to integrating upstream work into a coherent whole.
Sadly I'm not convinced that any enlightenment is going to be achieved because the people behind this web site admit that they haven't even got the time to become involved enough in Debian to have a vote, so I don't know where they're going to find the time to launch a non-toy distribution.
Using the same argument, forking would seem like a horrible idea if there isn't active maintainers.
It's all a bit overdramatic anyway - there are heaps of Debian forks; they're called 'downstream distros'. Ubuntu is one.
Probably because they (experienced Unix veterans) realized that it makes much more sense to test the demand of a fork (that's what they made the website for) than to continue any useless discussion about systemd. Some systemd proponents obviously have serious problems to make a sober discussion anyway (interestingly also in a prominent German forum).
Notice: "If SystemD will be substituting SystemV in Debian, we will fork the project and create a new distro: Pure Debian by Veteran Unix Admins. We hope this won't be necessary, but we are well prepared for it."
They are not eager to make a fork but I think they will actually do it if necesary.
If a fork would reduce the time spent arguing about the init system (which 99% of users don't care about), it could even prove beneficial for Debian.
[It seems unlikely the fork would attract the critical mass of devs/users to succeed on its own though.]
Yes I want a better init system and process manager setup. But personally, I'm not sure that goal is worth losing Unix distro compatibility.
I would love a system that works the same across OSX, BSD's, Illumos and other newer experimental OS's etc.
There's a whole lot of "I don't/do like it" and "It did/didn't work for me" but not a lot of explanation of why they do or don't like it, or what didn't work, and I'm interested in those details.
But a switch to a different init system shouldn't break your system so badly that it no longer boots. And yet that's what happens if you rely on keyscript to unlock your drives in /etc/crypttab.
Apparently the answer is to write a different custom C program for every possible permutation of obtaining key material to feed to cryptsetup: http://lists.freedesktop.org/archives/systemd-devel/2014-Aug...
... which is somehow more clean than a 4 line keyscript.
... and certainly lends credence to the idea that systemd just isn't unixy.
Racy code has issues with race conditions. Any error in setuid executables can be very dangerous, so they are strongly discouraged. However, once you've decided that you have to write a setuid program, there's no particular reason to not write it in a scripting language.
As a datapoint, the KDE folks think that using scripting languages for setuid executables is okay:
/usr/lib/kde4/libexec/fileshareset: setuid Perl script, ASCII text executable
This isn't even remotely controversial. There is a reason that the setuid bit is ignored for unix shell scripts.
Only in the future it may use kdbus for some purposes (eg. uploading firmware blobs), but this will only affect internal interfaces.
On the other hand, systemd does not require the D-Bus daemon when you're launching systemctl it as root, the D-Bus daemon is only needed to route the call when used by unprivileged users. When used as root, systemctl connects to the PID1 socket directly and D-Bus is basically just a serialization protocol (and systemd does not depend on libdbus either).
To be fair, udev communicates with the kernel via netlink. All the userspace notifications are done via dbus. So dbus was already part of the equation whether people realize it or not.
http://blogas.sysadmin.lt/?p=141
I gave a cursory glance to the systemd/src/udev files and found no mention of dbus.
You mentioned smart cards... what system would handle when you connect a smart card after boot?
By default nothing happens when you insert a smartcard; if the keyscript tries to run without the smartcard it will retry, timeout, and eventually fall back to askpass. If there's a LUKS keyslot with a backup passphrase which can be entered by a human operator at the tty, this also serves as a disaster-recovery mechanism so that you can afford to lose the LUKS keyslot associated with the token/smart card.
I'm sorry. I wasn't clear. I was asking about the work that gets you to the point where the volume appears. You don't necessarily have a device file for the volume, so something needs to be ready to handle that logic when the device is inserted, then when it has figured that out, you have to notify the automounter that it is time to go to work (or not), etc.
Now add logic so that all of this magically gets powered down all the time to conserve power (and then figure out what you do with the filesystem when that happens).
Now handle the case where you have a bad connection so it is constantly flapping as inserted & not.
Now handle the case where it gets ripped out with no warning.
Now handle the case where you have a smartcard and you are using it to provide the key to decrypt another smartcard...
I also do appreciate the systemd features for mobile and desktop devices.
But the sysvinit mechanisms aren't rendered completely irrelevant by systemd; the sheer stupid dumb luck of the the thing is actually deterministic and repeatable in my experience. systemd migrations have exposed hidden dependencies I hadn't previously had to worry about between services, which is good in one way, but not necessarily good in other ways (transient intermittent failures which never occurred under sysv).
Yes, it's unfair to blame systemd for poorly defined services - I do like the concept systemd is offering in that respect. But if I have servers in the rack which have smart cards in them that I know are always attached except for very rare events where a sysadmin will be dealing with things, I don't think there's harm in a 4-line shell script failing maybe once or twice in a server's lifetime if it means not having to maintain bespoke C programs for years and years
cryptopts=source=/dev/<disk>,target=sdc5_crypt,keyscript=/lib/cryptsetup/scripts/passdev,key=/dev/<other_disk>:/somdir/root.key
Anf then in /etc/fstab use the /dev/mapper/<target> (sdc5_crypt in the example above) as the root device, as before.
Then you need to make sure the initramfs contains all the tools needed to support this (that was done automatically with /etc/crypttab, it's "manual" with the kernel option). To do this, add under /etc/initramfs-tools/hooks a script file to load what's needed in the initramfs: cryptsetup, passdev, the needed kernel module. You can roughly copy the existing /usr/share/initramfs-tools/hooks/cryptroot and simplify it.
I've seen other distro documenting the kernel approach instead of /etc/crypttab for the root filesystem. It may become the standard way in the future, and there's no reason it couldn't be fully automated. There's some coordination between several components so it may take a bit of time to converge to an accepted and supported way thought.
The fact remains though that a wheezy dist-upgrade is going to ruin your day badly enough to spend some time digging up your iDRAC/whatever creds (admittedly, nobody is going to dist-upgrade their prod servers without testing first... or are they? :P)
The pro-systemd brigade only seems to be a small minority of Debian devs (though they're extremely loud, and trollishly persistent).
I've thought for a long time that they must have a place where they all hang out in secret and share links to discussions where they need a pro-systemd response / a handful of downvotes.
In this way they give the impression that their numbers are much larger (the reasoning here is that for any given post or discussion, if the number of "ambient" / "organic" critical comments or downvotes that it receives is a proxy for how critical the community at large is, so by sharing links they make it seem like there's a broad base of support for systemd).
This kind of thing seems to happen periodically, where a person / group of people railroads a decision using methods that are outside the "accepted" set of methods for OSS development, namely meritocratic discussions.
Who knows what their motivations are. It probably varies per person. Having "I designed and implemented a new init system and got all the major distributions to adopt it" on a resume is a huge demonstration of "impact", which is something that really pays off in a lot of companies / organizations.
"Impact" isn't always "progress", though.
And generally more convincing, probably due to actually understanding both sides under debate.
Until I saw that line, I was thinking: well quit talking about doing it, and just do it!
The idea of a non-systemd distribution in general is something I've been expecting to pop up for a while. And if the vocal people online represent a real desire not to switch, then one really should exist. Beyond that I'm rather uninterested in such a project one way or another.
The trouble here is that the bulk of the work is just maintaining a changeset to debian packages. They haven't even spun up dak and friends, so I'm assuming this is DOA for now. It seems like a lot of hot air to pressure debian, or at the least attract contributions that can maintain their fork. Is "fork" a scary word to any DD, considering debian is already the upstream distribution for other, more popular, derivatives?
There's already plenty of them.
The issue is that Gnome, KDE, and other software requires systemd. You need to fix/maintain their compatibility with other init systems. Then it is easy for Debian user to switch init systems.
Eg. I run an Openstack cluster and do not care if there are gnome or kde packages available. I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.
[1] http://fedoraproject.org/wiki/Server/Product_Requirements_Do...
[2] https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD
I'd be running it on my desktops. All I need is a way to spawn chromium and emacs and consoles (I like konsole, but if it drags in too many dependencies I'll put something else on).
If/When chromium depends on systemd (WTF, a web browser / page renderer logically SHOULD depend on your init system, of course) then I'll use another browser... somehow.
I'm kind of irritated about having to learn a whole set of new things. I do recognise that there are some benefits for my use case in systemd. The desktop stuff aren't the only things that systemd brings.
More than that though, is the fact that it's going to be the new default everywhere. So while you say
I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.
I think you (and I) will actually face more work in trying to avoid systemd than convert to it. You'll be fighting against your distribution's default and the default of every bit of third party software targeted at your distro. From what I have seen most conversions are fairly painless.
So from my position that sits somewhere between "ambivalent" and "that's kind of nice", going with the flow seems the easier path.
1) No desktop features are of any interest to me.
2) My position is between "that sucks" and "ambivalent"
But I do think that going with the flow is a much easier way. This isn’t a fight worth fighting if your concern is maintaining running systems. Of course it might be worth while to stay on an LTS release till the very last moment, to let all the bugs shake out.
Postgres and Apache? Seriously?
But when systemd is the default init system on almost every Linux distribution, new software will have the systemd integration written first and tested most.
This I can't wrap my head around, why does Gnome for example need systemd? There are standard ways on GNU/Linux to do everything it needs in a unix fashion (by deferring to small specialized tools):
These and similar tools (or libc functions) give you all information you need (username, etc.) and system functions a desktop environment needs (reboot, hibernate). You then only need something like udev for plug-and-play (which is available without systemd, and as a part of it), and interfaces to the X/Wayland server and the audio system (which are both not a part of systemd). This seems to be all stuff that can easily be abstracted away in one module per OS. I don't see why you have to tightly couple your DE to systemd. (Unless, you are using your DE as a vehicle to push systemd, which I hope is not the case...)It's big, gnarly, essentially undocumented, and contains a bunch of features to support tricky cases like multiseat machines (systems with two or more sets of keyboard, mouse and monitor, each with a different user) that are rarely used but still need to be supported because the API's designed around them. Even the systemd developers don't think a reimplementation is feasible.
http://dvdhrm.wordpress.com/2013/08/24/session-management-on...
http://dvdhrm.wordpress.com/2013/08/24/how-vt-switching-work...
http://dvdhrm.wordpress.com/2013/08/25/sane-session-switchin...
Here's a good summary of the issue: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...
A bad thing about systemd and where we are now is the ever-changing API that is mentioned, which hampers alternatives to systemd.
But, that is where we are now, Debian isn't in much of a position to change that, and forking probably isn't going to help with that. Debian wasn't ignorant of that either; these issues were discussed at length in the tech committee debate that originally settled on systemd being the default for jessie.
Yes, really.
Elias Probst:
"Reading the comments shows a lot of misconceptions about +Martin Gräßlin's proposal [to use systemd features to make Plasma startup under Wayland a little bit simpler]:
* KDE SC will still allow to use the old-way to startup a KDE session, as it will still ship the X11-way of doing it for [BSDs]. If you want to use a modern Wayland/systemd stack you're fine by using the defaults. If you don't want to: use the old X11/script startup stack.
* KDE SC won't enforce using systemd as init-system by this change. Instead, it will use parts of systemd which are completely independent from the init-system being used to handle the startup of the KDE session. If systemd is being used as an init-system, that's a plus because of some systemd integration effects, but that's all about it."
via: https://plus.google.com/+MartinGr%C3%A4%C3%9Flin/posts/GMtZr...
[0] http://mail.kde.org/pipermail/kde-windows/2014-October/threa... [1] http://mail.kde.org/pipermail/kde-mac/2014-October/thread.ht...
But I won't be surprised to see them come slinking back in four months with their tails tucked when nobody's actually maintaining any software for the fork.
Fork off and die.
p.s.: it's systemd, not SystemD.
Isn't it possible to do this with patches, similar to how the linux kernel has RT patches?
No. IMHO Debian is less a distro than a democratic experiment - and systemd shows it is working. If you don't like systemd (and I vastly prefer my FreeBSD world) get on board with the democratic process - it is always messy, frustrating, driving you insane slow. That's how you can tell it is working
Don't fork.
Edit: Matthew Vaughn is an actor not a Dev.
There are some fundamentally different and sometimes conflicting requirements regarding the startup process on a server and on a desktop machine and I think systemd which is obviously desktop driven will be the catalyst for a split between server and desktop distros.
I don't think classical desktop environments have much future personally, but that's just my gut feeling.
Server will definitely move further into modularization of services, and that will make init systems there less and less interesting.
[1] http://cm.bell-labs.com/cm/cs/who/dmr/man21.pdf
It was a kind of pun to state my disaproval to level of fragmentation the linux community has gotten into.
Okay this SystemD saga might or might be AS important as some people tend to think. But fragmenting the community so much and having people working to 10 different, unstable solutions instead of 3 stable ones, its a waste of resources IMHO.
The author is essentially making a threat, that there will be a fork of Debian if the project does not give in to his demands. Then he states that he is totally not just speaking for himself, but for a much larger group, and in fact claims to have the majority on his side. I have a hard time evaluating the seriousness of these claims, as there is no intend to back up any of this.
As far as the arguments go, there is nothing new here. The concerns have been stated before, and have been heard, too.
Also, critique starts with "We like controlling the startup of the system with shell scripts that are readable".. How on earth is a systemd service file less readable then a hundreds of lines bash script?
Also relevant: http://www.itwire.com/business-it-news/open-source/65684-deb...
Perhaps the sponsors of the linked site are doing bug reports on packages like systemd-shim and others. Perhaps the upstream project members involved are ensuring that they have init scripts for systemv available. They could add a question with links along those lines easily.
There may be some people opposed to systemd, but there have been votes that saw systemd as the clear winner for the default init system. Why should the majority of users who are FOR systemd bending to some users who don't like systemd out of some philosophical view? Instead of behaving like a little child, people can work on letting Debian run fine without systemd (which IS the fact today, i can simply switch between sysvinit and systemd just by installing a package).
And in the end, you should remind yourself that this is only about the default for one linux distribution. You will still be able to use sysvinit if you like. There is choice. The majority wants systemd. The minority wants sysvinit. Only because the opposers are loud and make a lot of noise about this doesn't change the fact that they are a relatively small number. Changing the default is the only sane thing to do.
Arch switched to systemd about a year ago. When official distro packages are shipping with systemd service files by default, it means there is drastically less effort required on your part to maintain a systemd-based environment. It would take an experienced and dedicated crew to translate the systemd service files of dozens of upstream packages to Runit for instance. The enterprise level support just isn't there, whereas with systemd it is.
That being said, I like writing systemd service files. I just wonder what would happen if more distros pushed for, e.g. uselessd or Runit as the standard init system.
> uselessd (the useless daemon, or the daemon that uses less... depending on your viewpoint) is a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism. Basically, it’s systemd with the superfluous stuff cut out, a (relatively) coherent idea of what it wants to be, support for non-glibc platforms and an approach that aims to minimize complicated design.
http://uselessd.darknedgy.net
And don't get me started on binary log files.
As was said before, buster, your attitude is the problem. It's the same as the systemd developers and those within the community.
SysVInit has served me thus far with no issues.
I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out.
took me some time to figure out it was systemd.
the firewall wrapper for iptables gives you an insecure default config and is hard to fix via config management "add a service that means port 3128 TCP, now allow incoming connections"
My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it.
You should be laying down a base initial configuration at the time that the machine was provisioned. The basic example of this is the sudoers file. The default setup for Ubuntu/RHEL is different enough that it was causing problems and the solution was simple - force defaults.
Why on earth does it need to do that?
? You end up diving in to the service file vs. the script.
> And don't get me started on binary log files.
Having worked with binary and plaintext log data for the better part of a decade now, I have to say that pretty much the entire set of claimed advantages of plaintext log data is very wrong, and we've wasted a ton of productivity & efficiency because of it.
If you really are sure of its superiority though, just put a little stub in front that converts the binary log to a human readable format that still needs a program in order to present to the user...
> SysVInit has served me thus far with no issues.
Speaking of attitude... there are two ways to look at that datapoint...
That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script.
your attitude is the problem
The attitude here is to fix problems at their source. Instead of using the hammer for everything, sometimes coming up with a new tool is a better idea.
Generally I agree with this at a broad level. But, there is still the problem of: I need this running now. To do that, I need to compile and run a custom systemd, and hope that my patch gets accepted upstream, and that in a few months my distro finally adopts it and puts it in the standard package.
Generally speaking I really like systemd and am excited to get some time to update my installed stuff to use it, but the above is a real concern.
At the worst case though, this reduces systemd to a shim-launcher for SysV init, which is the situation you find yourself in now or when using Upstart, which tons of Ubuntu users already have been.
Surely the systemd equivalent would be delving into the source code for dash, or god help you dash... I know which one I'd prefer--not that I've ever hard to do either, fortunately!
FWIW systemctl start docker works fine after the system has booted. It's configured to require network.target, and even though I can see network target scroll by during boot, it's still not being noticed.
The work-around is to make multiuser want docker, then I've got docker starting at bootup.
Other symptoms that would indicate this was the problem would have been that 'systemctl status lxc-docker.serivce' would have said "Loaded: loaded (...; disabled)" and "Active: inactive (dead)". i.e., systemd never started the service because nothing ever wanted it.
Oh dear, that seems to be the case... https://github.com/docker/docker/commit/053c3557b3198466ecfb...
Even the docker page tells you to use the docker package for Jessie: https://docs.docker.com/installation/debian/
Have you tried adding "touch" commands in ExecStartPre/ExecStartPost? Systemd also gives you a hint of why something didn't start via "systemctl status $servicename".
If you start a "normal" service using a command that double-forks and immediately exits (like a `--daemon` flag), systemd will see that the process has exited to mean that the service has finished, and will terminate any of its child processes (as you want runaway dependencies culled when a service crashes). This sounds like the behavior you describe.
A admin needs to know a dozen languages and codes in bash most of the time, they have a hand written folder with glued in scraps next to their terminal which explains why they did what, how and why. This folder has entries like "reboot three times, do an rain dance and run godHelpYou.bash as root" because that's the only way that you've found out how the libraries actually talk to each other.
For people like this "do one thing and do it well" is the only way that you can beat the impossible complexity of a modern machine back into a running computer even some of the time. When you have a single point of failure which is a black box you're just back to windows land: restart the service, reboot the computer, reinstall the system.
From this point of view devs look like a tribe of monkeys building a shit pyramid over your village. They just keep flinging more shit at the top thinking they are the greatest ever monkeys. When the shit pyramid collapses and buries everything you know and love under a few meters of shit, probably killing someone in the process, these monkeys just shrug say a few words about how that was the best shit pyramid anyone had ever build and start making a new one one or two valleys over.
For the developers, on the other hand, it might mean that some use case that is important for the admin is simply not yet implemented. The solution, as so often, is... drumroll to report a bug! Developers care about their users. Just talk to them.
Also, admins should realize that "reducing complexity" is a goal that they share with the developers. systemd is all about reducing complexity by implementing functionality the right way, on the right layer. For example, with systemd it's way easier to write a daemon, because it takes care of
* daemonizing: just stay in foreground
* logging: just output to stdout/stderr. journald will collect everything, and if you want, forward it to a classic syslog service
* startup: no more shell scripts required, just a simple service file
* supervision: just add "Restart=on-failure" to your service file. It also supports software watchdogs.
If start-via-systemd doesn't work, hack around it with a script and report it as a bug or write to the mailing list.
An init system should have a verbose mode that tells you exactly what steps are being taken to start a service and what the result of each step is. Maybe this will come later, but -given the guy's history- it won't be written by Poettering.
Don't get me wrong, I love to bring out strace and will use it to solve all sorts of problems, but it really shouldn't be necessary use it near the start of troubleshooting.
Bash scripts? Unless I'm really mistaken, startup scripts need to be written towards the POSIX shell. It's kind of like bash scripts except you pretend the year is 1985 and no bash versions released after that exists.
Not so convinced by this. "Those days are dead and gone and the eulogy was delivered by Perl." -- Rob Pike
Systemd in debian would have an easier time making friends if it didn't usurp PID1 for roles that are currently outside PID1, and if it didn't encourage software which is currently init-system agnostic to grow a dependency on a specific init-system implementation.
Like what exactly? This is a non issue. systemd has very little actually running in PID1.
PS: I love the 'how long are your beards?' line. Obviously, I'd rather Debian didn't fork and that we kept choice for server people in one of the larger Linux distros just on an 'ecological diversity' basis.
You can do a window manager on top of X with systemv right now in Jessie [3], the '--no-install-recommends' option to apt-get is helpful. But the result will be seriously old-school. Its rather fun for surfing in cafes and wasting time on forums but for my day to day work (not programming) I prefer a full fat desktop like KDE/Gnome.
[1] https://lists.debian.org/debian-security-announce/2014/msg00...
[2] http://www.phoronix.com/scan.php?page=news_item&px=MTc4NTE
[3] http://sohcahtoa.org.uk/osd.html
> […] it can be helpful to monitor and update the Wikipedia page about SystemD.
So they are basically suggesting to manipulate Wikipedia in order to paint a worse picture of systemd?