Hacker News Reader

Comment by microtonal | Hacker News Reader

You missed some:

https://lwn.net/Articles/621895/ https://lwn.net/Articles/621003/ https://lwn.net/Articles/620879/ https://lwn.net/Articles/620878/ https://lwn.net/Articles/619749/

They are related in the sense that are all fall-out of the struggle to integrate or block systemd in Debian and/or how it exposed some problems with the Debian constitution.

It's a shame to see that so much talent is lost and frustrated over what in my eyes seems to be a small issue. systemd and Upstart are both a large improvement over the System V init scripts. So, it's quite logical that it should be replaced at some point. Since systemd seems to have the most traction in other major distributions and upstream software, it makes sense to make that the default, while making it still possible to switch to Upstart et al. if someone wants to (at the risk of losing support for some upstream software).

If it turns out in three years that systemd is a dead-end, rip it out, and use whatever is better then. Distributions did that with devfs, the old hotplug scripts, egcs (which was merged back in mainline), etc.

View on HN

I get the impression which is admittedly informed by very cursory examination of the issues that ripping systemd out may be far more difficult than ripping say, Upstart. Systemd seems to have taken the approach of owning far more than just the Systemv init stuff and that removing it might entail sweeping changes to huge parts of a linux distribution. Systemd does seem to be pushing somewhat of a lock-in strategy and for many in the linux community that rubs them the wrong way.

Personally I don't really care much either way.

I get the impression which is admittedly informed by very cursory examination of the issues that ripping systemd out may be far more difficult than ripping say, Upstart.

Definitely. But this is probably true for many things at a low-level in the stack. E.g., it would also be hard to replace D-BUS or the Linux kernel (as evidenced by the fact that Debian/KFreeBSD will probably not be in Jessy).

I agree that it is a worry. But you can never make progress without taking any risks. We have tried 'fully isolated init' for years and it does not really work for modern systems/applications.

    We have tried 'fully isolated init' for years and it 
    does not really work for modern systems/applications.

I keep hearing this but I haven't seen any concrete reasons why it would be true. I'm curious what those reasons are. As I said I don't personally care that much as I work far enough up the stack to not be affected for the most part.

I think it's not a problem primarily with "init" itself, but for example that systemd provides you with the capability of starting a service "after network is up" so it needs to be able to tell "when network is up". That's much easier to do if there's a canonical (from systemds POV) way to tell "what's networks state". That again leads to "bah, let's do that ourselves" so there's now an optional systemd component that does this, that, this and people start relying on those - systemd-logind is a requirement for gnome. You could write a replacement for systemd-logind that offers the same functionality, but as long as nobody does, you're stuck with systemd.

The way I see it is that the systemd developers just plowed a way through the undergrowth and produced a suite of components that provide functionality that's appealing for people to build on. That's an offering that was accepted and now other people complain that the "systemd people are forcing their system on us and I want sysV init". The right course of action would be "meh, don't like systemd, I'll build a better offering." Talk is cheap, code is what counts.

I very much like systemd. It's documentation is actually long, but clear and well structured. The init component is much simpler than the mess of shell scripts used before. There certainly are problems and issues with it, but I've met problems and issues with about any kind of software I had to deal with so far (including my own), so I take that as a given.

Your response only makes sense if your alternatives are: (1) systemd, (2) sysvinit and (3) a horrible death.

I know dozens of init systems that do much more, markedly better than systemd, and are modular so you can easily replace them when the time for a new technology comes. systemd is very recent, and still its opinionated architecture is showing inflexible to changes.

no, the alternatives are

(1) systemd (2) write and advocate the usage of a different init system. (3) a horrible death

I'm certainly not opposed to having a better alternative, but the systemd people managed to write something that is better than sysvinit and made the package good enough to get people to use it. Now people complain that they're taking over the linux world by force, but they actually don't. They just provide something people want - it's not that they forced the gnome people at gunpoint to use systemd.

I happen to like modern daemontools-like init systems a lot, (runit, s6) but I use various init systems depending on what I want, and that's great IMO.

The problem is that systemd is that is being forcefully pushed to all distros. For instance, by merging udev with systemd. We want to keep all the alternatives available.

I don't see any force involved. udev is their code. Don't like how they use it - fork.

I understand your pain, I sometimes don't like the direction things that I use move or the ways they change, but I'm not sitting at the sidelines complaining about being pushed around. I get to use stuff others provided for free, I'm grateful for that and I either fork/change it or move on to something else. I'm not in a position to tell them what they should be spending their time on.

Lennart Poettering could just stop developing and supporting udev any second, that's his personal decision and I couldn't say "he forced me to use windows" and I don't see anybody else could.

Don't like the (maybe) coming systemd dependency for udev? Build the code to set up the bus yourself or pay someone or wait until someone knowledgeable gets sufficiently fed up and builds something. Same for the gnome dependency on systemd: Either accept it or contribute the time to make it work without while retaining the features it has.

Not only udev, they roadmap is to pack the whole system so as to remove any difference between linux installs, their words, not mine. Currently, we can fork udev, but in the future, are you telling my to fork the whole operating system? And all applications that unnecessarily depend on said system? That would require millions of dollars, at least.

Also, Windows can also be forked, by distributing patches instead of binaries. So that argument is a red herring, DOS has been forked before, and every proprietary application, but that doesn't mean I can't ask other developers a bit of respect for those of us who are using other init systems, I will maintain my software, just let me do that. All the discourse about democracy around GNU/Linux wasn't supposed to be summed up as "Fork or GTFO".

> Currently, we can fork udev, but in the future, are you telling my to fork the whole operating system? And all applications that unnecessarily depend on said system? That would require millions of dollars, at least.

Yes, indeed, I do. Because most applications will not unnecessarily depend on systemd, but rather because the dependency provides some (perceived) benefit to the developers. And if the developers decide that the benefit is worth the dependency, they'll do it. And if you want to prevent that future, you need to provide something that offsets the benefit - write the test and compat code to support gentoo, write the docs, provide the money (or other incentive) for the developers to do so. That's how it works. You don't have to do all of that yourself, you can form a group, build your own distro, run a fundraiser, whatever you choose. But you don't get to sit back and complain and hope the world changes for you and neither do I.

There's no democracy in the OSS scene, users don't get to decide what the software they use looks like and even maintainers or other software have no vote. It's more like a market - we use what's best for our personal cause. You pick and choose and the software with the most users will prevail, others either hold their ground or disappear (ConsoleKit).

Who are this developers you keep talking about? When Microsoft bundled IE, WMP with Windows, we said, OK, developers decided that the benefit is worth the dependency, they'll do it, but we didn't like that, I'm not talking about legal issues, what I'm saying is this is an attack to the GNU/Linux philosophy. If GNU/Linux closed its source and went proprietary, you would say exactly the same things: Fork or GTFO. But I would say, this is not right. I just don't want systemd bundled with necessary GNU/Linux components, like the Linux kernel, in the future. As simple as that.

All this discussion doesn't and won't preclude me from do all the things you said under "preventing the future".

> Who are this developers you keep talking about?

People developing software. For example the gnome folks. You, me. (don't know about you, but I have services that use systemd for starting and supervising the service)

> If GNU/Linux closed its source and went proprietary, you would say exactly the same things: Fork or GTFO.

Yes, actually, yes. If Linus decided that all future development he wants to do is now closed source, I either have the option to fork and continue in the open or GTFO. I'm not the one to decide what he can to in his time. There's be a number of legal issues surrounding that, for example that he can't take the current kernel code, but if he decides that within the given framework he closes his development, fine with me. If Linus decides that he thinks that a deep integration between the kernel and systemd is the way forward for his project, I have to accept that. I may not like it, but unless I do something to change it I can't force it any other way.

The beauty of OSS is that you can exactly do that - take the last public version and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does.

Not if Linus decided that, if the Linux Foundation decided that they wanted to switch the license to proprietary. See the mailing list message of Linus against deep integration between the kernel and systemd!

> The beauty of OSS is that you can exactly do that - take the last public version and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does.

Read my previous comment: The beauty of proprietary software is that you can exactly do that - take the last public version, patch it and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does. :)

> Not if Linus decided that, if the Linux Foundation decided that they wanted to go commercial. See the mailing list message of Linux against deep integration between the kernel and systemd!

Why not? Do you pay them for their time? I don't. So who am I, what do they owe me? Nothing. Not even a new free version of linux.

>Read my previous comment: The beauty of proprietary software is that you can exactly do that - take the last public version, patch it and make something better, something that's more the way you like it, no matter what the original owner thinks, says or does. :)

No, actually you can't. You're not entitled to unless you specifically sought a license that permits it. All Open Source Licenses grant you that permission.

Well, if Microsoft could, and did, port IE and Office to UNIX, why would the free and open software people have a problem in allowing more user choice? Why would they need to hard depend on software designed to be non-replaceable? With most free software organizations set up as nonprofit, we must hold them to a higher standard to ensure their continuity under the legal framework.

> No, actually you can't. You're not entitled to unless you specifically sought a license that permits it

Please take a look at 17 U.S. Code § 117.

> Well, if Microsoft could, and did, port IE and Office to UNIX, why would the free and open software people have a problem in allowing more user choice?

No, why? If they port it and even if they provide it closed source binary only, I'd still believe that an open source browser and office packet are fundamentally more in societies interest, but they're certainly entitled to build and distribute IE and Office for linux/unix/catOS and I'm not entitled to tell them to stop. Given the license of pretty much all linux distributions I think nobody would be. Just as microsoft allows the distribution of OpenOffice and Firefox for Windows. They don't have to like it.

>> No, actually you can't. You're not entitled to unless you specifically sought a license that permits it

> Please take a look at 17 U.S. Code § 117.

I'm not going to discuss american law with you, but please note that this paragraph puts severe restrictions on redistribution of copies, while the GPL does not. I'm not a law scholar, much less an american law scholar but I don't think this means what you think it does.

I'll tell you one thing, I know nothing about you, but this person is considered by many the best programmer in the world, one thing is certain, compared to the good done to the world, he's various levels above you and me, he's the creator of daemontools, the way it follows the unix philosophy has been an inspiration, I'll refer you to this page about software law http://cr.yp.to/softwarelaw.html

It seems you don't read my comments, because I've edited binaries, and distributed patches of proprietary software, that's not illegal, only I didn't distribute the binary or code without permission. Let me tell you, having systemd source doesn't help me at all because it's a megalithic blob.

Is the GPL a good thing? Yes, BUT just because you license your junk with the GPL you don't deserve a Nobel peace price. You seem to think that had Hitler released a hello world program with a GPL license he would be a saint, and can't be criticized, "fork or shut up", you say?

Please note that the link you posted says exactly what I was stating:

> As long as you're not distributing the software, you have nothing to worry about.

You're not allowed to redistribute the software, modified or not. GPL or any other OSS license grants you the the permission. (and no, distributing software under GPL does not make you a saint or even a good person. See Reiser)

No shit, I don't distribute the GNU/Linux software either, too big and inconvenient (GB) compared to a patch (bytes).

>> GPL or any other OSS license grants you the the permission

The sysvinit alternatives that I know and use, all use an OSS license, most of them less restrictive (BSD or MIT). I use free (as in freedom) software; that's why systemd is harmful to me, always trying to create incompatibilities with other open source programs lacking a multi-million corporation backer.

>better than sysvinit

Better in some ways, worse in others. If systemd were unequivocally better in all areas, nobody would be complaining. By saying what you said, you're subtly but deliberately telling every one of those people that their concerns are irrelevant and/or a result of their ignorance. This is the systemd developers' M.O. and a large part of the reason why there's so much drama over systemd.

Right, "better" is a relative term in software. I'm not disputing that there certainly are problems in systemd, but as a package I still think that systemd does more things "better" than sysvinit than it does things worse. There's certainly a lot of room for improvement - build upon it and create and advocate an init system that is better than systemd in more areas than it is worse.

> This is the systemd developers' M.O.

So far I've mostly seen "we believe this is better and we'll build it this way, like it or leave." That's certainly opinionated, but hey, they're totally entitled to have that view (why would they build it if they thought it's worse?!) My view and your view may differ, but we don't get to complain unless we provide something that we think is better and get a lot of people to agree on that.

>I'm not disputing that there certainly are problems in systemd, but as a package I still think that systemd does more things "better" than sysvinit than it does things worse.

The community seems pretty evenly split on this point, with folks like myself taking the opposite view: systemd is a regression in so many fundamental areas that its improvements in things like boot times and init script syntax just are not worth the tradeoffs that it imposes. I don't care if the frogurt is free when it's full of potassium benzoate.

Sure, if that's your view, I'm fine with that. If the people that build the distro-of-choice for me decide that frogurt is the best init system for the distro they want to build, I'll either swallow that or move on to something that uses guaranteed potassium-benzoate-free-frogurt as init, but I'm not going to tell them that they're not allowed to do this. Because they are. You don't have to like it, you don't have to eat it but they're free in their choice just as you are free to build something else.

>You don't have to like it, you don't have to eat it but they're free in their choice just as you are free to build something else.

And I'm also free to correctly identify that their poor leadership decisions are ruining a wonderful piece of software and causing the community, including Ian fucking Jackson, to abandon the group that made it possible.

If there are really "dozens of init systems" out there that "do much more, markedly better than systemd, and are modular" how come exactly zero of them have been adopted by any Linux distro of note?

I've been hearing this for decades: If Linux and *BSD are better than Windows, how come exactly zero people have made the switch?

Except they've been adopted, systemd has been mandatory only in some bigger more commercial distros.

Thanks for the detailed response. It makes a certain amount of sense.

    The right course of action would be "meh, don't like
    systemd, I'll build a better offering." Talk is cheap,
    code is what counts.

This statement seems to ignore Upstart though. Which is again from a very cursory examination exactly that. A better and more modular init without some of the complaints of systemd and yet is not gaining the mind share.

Why isn't it considered a viable alternative?

Well, ubuntu used upstart and moved away, redhat/centos the same (though the centos 6.5 version of upstart was horribly outdated and crappy in terms of features). I actually kinda liked upstart, but I prefer systemd.

Upstart's event-based model was semi-broken and AFAIR the original author admitted as much. (I believe he posted a message stating this to a maining list, but I cannot find it ATM.)

Exposing the event model directly to the jobs also made reasoning about the current system state (which is what actually matters, not how we got there) tended to make upstart jobs a lot more complicated than necessary. (This is from memory, it's been ages since I actually looked at upstart jobs.)

Here are some specific examples:

read comments #6 and #8 on this 5 year old unfixed bug and weep: https://bugs.launchpad.net/upstart/+bug/447654

in comment #7 on this (unfixed) bug Scott says it could be solved by having upstart use cgroups instead of ptrace to track processes: https://bugs.launchpad.net/upstart/+bug/406397

> systemd provides you with the capability of starting a service "after network is up" so it needs to be able to tell "when network is up"

That's not that hard once you have proper dependency-driven init, Gentoo's done it for a long time. You just need some way for the networking scripts to tell init that they're started now. Traditionally they'd do it by forking into the background once they're done starting just like any other init script. It's a bit harder if the network might not become available until after startup but not that much so.

> It's a bit harder if the network might not become available until after startup but not that much so.

That rarely happens in server environments. I wonder how much of the recent debates about init systems is caused by the the rise of mobile consumer devices and developers' desire to cater to them.

I care when my laptop takes more than a few seconds to start up, but I really don't care when one of my cloud servers takes a few minutes to start up. Network not ready yet? Meh, we could just sleep(10) and try again.

Socket activation:

http://0pointer.de/blog/projects/socket-activation.html

Socket activated containers:

http://0pointer.de/blog/projects/socket-activated-containers...

Resource management:

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

Better service information:

http://0pointer.de/blog/projects/systemctl-journal.html

In fact, the whole series is a recommended reading. Anyway, all these features requirer tighter integration with other components than SysV init. E.g. Linux' cgroups, services that support socket activation, integration with the logging system for status information, etc.

Also, a lot of techniques in systemd were already pioneered in launchd on OS X since Tiger.

<i>Socket activation</i>

Because minimal boot time is way more important than predictable, repeatable functionality. It's totally cool if some other daemon lies about whether or not my service is actually listening while just happily buffering into /dev/null. This is all brilliant stuff and a huge step forward over UNIX.

1. The purpose of systemd is not speed; it is simply a happy side-effect of its design.

2. Socket activation do 𝐧𝐨𝐭 buffer into /dev/null; that is simply FUD.

They don't buffer into /dev/null... until you fill the buffer.

And the purpose of systemd, as near as I can tell, appears to be making my system into a Windows box, complete with binlogs.

No, when the buffer is full, the write() call blocks. Otherwise no UNIX pipes could ever reliably transport data.

True, I was wrong here.

>> that is simply FUD

You should educate yourself about FUD, I recommend the Halloween documents, where they explain the unfeasibility of FUD tactics against an open source project, and that if someone tries to do it they won't get anywhere.

It's totally cool if some other daemon lies about whether or not my service is actually listening

You're a little late; inetd(1) first appeared in 4.3BSD, c. 1986.

Oh shit, let me go recompile my chargen and telnet servers then.

We stopped using inetd for reasons. Modern services don't work this way, nor should they.

Yeah, but inetd was just about TCP sockets. systemd also supports unix-socket activation, which can block the client when the buffer is full, preventing data loss. I agree that TCP socket activation is iffy (though I still use inetd for non-critical stuff), but unix-socket activation seems safe to me.

Safe, but seems like it's solving a problem that doesn't really exist, or at least exists as a mosquito not warranting a bazooka swat.

Your analogies are great, transmiting a clear picture of systemd, like this: http://upload.wikimedia.org/wikipedia/commons/a/a6/Professor...

This style of debate is not welcome on Hacker News. Please drop it while you're here.

What offended about his post, out of curiosity? The Rube Goldberg analogy (I found that rather apt), or the "Professor Lucifer Butts" aspect of it (which I'll also confess to finding not the least apropos nickname for a certain Red Hatted German)?

The sarcasm combined with the scabrous smack.

There are some online communities in which that kind of thing is ok. HN is not one of those.

> combined with the scabrous smack.

The word 'scabrous' means "dealing with salacious or indecent material". Feel free to inspect the image, I guarantee it's safe for work.

I was chiding your comment for being rude, not salacious.

The first meaning of "scabrous" in my dictionary is "having a rough surface", and that's how I meant it. There's a long tradition of using that word to describe rough-and-tumble discourse, and it seemed fitting. You didn't just smack another user, you smacked them with a pointy implement (a link to an insulting image). That's not ok on HN. Neither is smacking people without a pointy implement. And telling another user "You're a liar and a coward, and you know it" is right out—a bannable offense, although we didn't ban you for it.

I'm insisting on this more than usual, because we don't want the pugilistic approach that is popular in some related (by subject matter, at least) online communities to take root here. When commenting on HN, please eliminate incivility from what you post.

This is a well thought out and complete response, it's just unfortunate that an image illustrating an overcomplicated system to solve a simple problem has elicited this censure; instead of the comment, in response to another user throwing a personal insult against an OSS hacker, where I call this user "a coward".

Your position about the place we want HN to be is clear, but I still believe the image is not insulting or offending anybody in any way. Those who flagged it, could they have misinterpreted it as an insult to the developers? An insult to the users? An inappropriate "scabrous" picture based on the URL? Or just as an attack to a program that needs our praise?

You're right. The "liar/coward" comment was the much greater offense, but that one was flag-killed.

I realize now that I was being too cute pulling out the old "scabrous" to make what is really an obvious and mundane point, and ended up confusing things. Sorry. I get bored sometimes and throw in variations which HN moderation comments are obviously not the place for. Let me try to be clearer.

There's nothing at all wrong with that image per se. It's great. I've made more than my share of Rube Goldberg analogies and know exactly where you're coming from. Had you linked to the same image in a thoughtful comment about overcomplicated systems, with no trace of incivility, of course it would be fine. It was only a problem in this context, i.e. a drive-by potshot in an inflamed discussion on a polarized topic.

Why make apples and oranges comparisons to the kernel? It isn't that hard to replace sysvinit. Why should sysvinit's replacement regress in this area?

Because systemd is, although people argue this point, essentially monolithic. Sure, in theory it's modular, but the module dependencies are so intertwined that good luck using any of the modules without the entire thing - or writing so many compatibility shims that you might as just write the module yourself. And that's even assuming a compatibility shim can be written without essentially reimplementing the entire module. It prevents incremental replacements. And it keeps expanding to pull more and more essentially unrelated functionality into itself.

It's "you're stuck with this architecture unless you redo the whole darn thing". And, again, systemd keeps getting larger and larger. As you say, it isn't that hard to replace sysvinit. But to replace systemd you need to replace / write shims for far more things. (Your window manager? I wish I was joking...)

I'm confused by the Window manager comment. As far as I understand, essentially, ConsoleKit development was stopped, and work on systemd-logind etc began as a better way forward, rather than rewriting ConsoleKit.

During this timeframe, GNOME developed integration with systemd-logind, similarly to how it developed ConsoleKit support beforehand. And in fact the ConsoleKit backend was supported for a while afterwords. But this is no longer the case as nobody was willing to support it and maintain it in upstream GNOME. So it was removed.

So I'm confused by the comment. Your insinuation seems to be this is somehow the fault of systemd for requiring a shim for things like GNOME, if you want them to work without systemd itself as PID 1. But the reality is that any software which has an API dependency that you want to replace is either going to A) need a shim or B) need a replacement that is also supported by the project. And the ship already sailed on option #2 - ConsoleKit held on until upstream decided to remove the bitrot.

I find this line of argument very weird. Indeed, this whole scenario seems to be a story of exactly how FOSS often works and how we envision it to work: people do the work, and in some cases they may compete with or achieve superiority over another project. And other people adopt that work and use it for their own work later on. And people may develop replacements that are or are-not compatible as they see fit.

It's probably very true that GNOME and systemd developers worked together to reach agreements on systemd-logind, so it could be used by both and they could understand each others needs. But why is it systemd's fault if nobody stepped up to maintain ConsoleKit, and systemd's fault if GNOME decided to remove support for something they saw as bitrot? Am I missing something extremely key here? Or do you consider this nobody's fault and just something that happened?

Stopped by Poettering, because there was corner cases where Consolekit could not reach. In essence, Perfect became the enemy of Good (tho that consolekit was ever good outside the fevered minds of some control freak in a uniform is anyones guess).

I'm starting to wonder if this is a problem with modern culture in general -- all over the place I'm seeing less "let's try our different approaches and see who has the best end result" and more "I will rape you to death with a flaming donkey for not running your project my way". It's like nobody wants to do any work to demonstrate that their way is superior, they just want to sit back and bitch about how the other way is inferior, until the other team gives up and our overall result is nothing :-/

(See also: both sides on pretty much any political issue in the past few years)

"rape you to death with a flaming donkey"

Dude ...

Downvote all you want, but this expression needed a reaction !

Of course English being not my mother tongue I didn't have enough vocabulary to express my distress at the mental picture that exploded in my brain when I read those words.

I thought "dude" conveyed best my disgust, puzzlement and amazement :-)

I don't hate you though.

Both sides did lots of work to make their solution better and each side had a sizable list of legitimate advantages over the other. The ultimate decision came down to a subjective value judgement about which advantages were more important and inevitably wound up ignoring about half of those honestly held priorities (not to mention the work that went into Upstart). I don't see how it could have happened any other way.

It's sad that people resigned over it but the pain itself seems unavoidable from where I'm sitting.

> the pain itself seems unavoidable from where I'm sitting.

If there's enough time and energy in the community to be throwing death threats around, surely there is enough energy to maintain debian/systemd and debian/upstart as separate distros, both of which live happily ever after, sharing the 99.999% of code and infrastructure that they have in common? Then if one side really IS technically superior, people will naturally end up moving to that one and the other will die a gentle natural death, no personal attacks and resignations needed.

(For example, see what happened when Canonical wanted Debian to be more apple-like -- they didn't send death threats to Debian developers, they just did the work that they wanted to see done, and now both projects are a great success)

That was the Linux community of old. These days it seems it is the old hats that is required to fork if they want to maintain their tried and true ways rather than risk their systems to a massive switchover.

A better political analogy would be comparing the talking heads on propaganda TV channels vs the lobbyists and corporate donors who actually run the .gov.

There's some strife at both levels, the level of discourse is quite a bit different as is the level of publicity, and the level of actual impact.

You could be correct about modern culture and public non participant trolling culture. But there are more groups involved than just that (loud) group.

It all comes down to the fact that talk is cheap while concrete action is expensive.

Systemd is seemingly deliberately designed to be difficult to replace. And it causes problems on some Debian platforms right now - as someone who was about to install Debian/kFreeBSD on a server, I am now very worried about the project's future.

Yep. right around the announcement of the GR there was a bug reported where installing one package would result in pam-systemd getting pulled in, and then it would cascade until sysv was replaced by systemd. I do wonder how many such bugbears there will be before there is a collective "fuck this" and just a blanket mandate of requiring systemd components everywhere...

It's not a problem to have systemd installed; on Debian it doesn't actually run as init unless you install the systemd-sysv package.

Debian has ports to FreeBSD and HURD; systemd doesn't support anything but Linux. I would assume that this would make systemd a non-starter in Debian (especially since there are no technical reasons systemd couldn't be ported).

There are also other issues. Yes, sysvinit doesn't parallelize scripts or do automatic dependencies. If that's all systemd fixed, I'm sure everyone would be for it. But systemd seems to be consuming everything in its path (logging, cron, etc), ignoring the well-proven and time-tested design tenet of "do one thing well".

I think Debian's supported parallel script execution and dependency resolution on top of sysvinit for a while anyway. It's not a true dependency-based init because the dependencies are resolved at configuration time rather than runtime, but whether that matters depends on what you're doing.

The reason why sysvinit runs on FreeBSD and HURD kernels is that those kernels have implemented the Linux procfs file system.

https://teythoon.cryptobitch.de/posts/on-portability-of-init...

Besides, none of these are release architectures, so why should their limitations restrict what features >99.9% of Debian users have available?

I look forward to seeing what these people will all create now they're not involved in Debian. It's not a good situation, but it does mean there's talent free to tinker with new ideas.

>Since systemd seems to have the most traction

Windows has even more traction, how about replacing all distributions with windows then?

How does another OS have anything to do with the need of replacing init system?

Systemd has been very good for me in Arch and in OpenSUSE for me. I feel like it is a much better tool for my needs.

>systemd and Upstart are both a large improvement over the System V init scripts.

Userland utils like wget depending on a specific init package is a large improvement over sysvinit? Nope.

How is wget depending on systemd?

So I had to look this up.

On Arch at least, wget depends on util-linux (package containing kernel tools like mount, dmesg etc.): https://www.archlinux.org/packages/extra/x86_64/wget/ And util-linux depends on systemd: https://www.archlinux.org/packages/core/x86_64/libutil-linux...

I have to assume this is Arch-specific, because I can't anything that basic as util-linux including a dependency on a specific init tool (and given there are still distros using other inits than systemd and still working fine...)

The systemd is a make dependency only. Unless you plan on compiling it yourself, you don't need systemd to run it.

    ~ $ y -Qi libutil-linux | grep Depends
    Depends On     : None

EDIT: conversely, these are the packages depending on systemd:

    ~ $ y -Qi systemd | grep Required | fmt
    Required By    : accountsservice  chromium  colord  crda  cups
    device-mapper  gnome-session  lib32-systemd  libgdm  libgusb  libpulse
    libusb  libvirt  libwacom  lvm2  media-player-info  mesa  mkinitcpio
    netctl  polkit  procps-ng  qt5-base  qtwebkit  rtkit  spotify  subversion
    systemd-sysvcompat  udisks2  upower  xf86-input-evdev  xf86-video-ati
    xf86-video-modesetting

As a sysadmin and developer I don't understand this systemd-hate. If you ever have written a /etc/init.d script for a python non-daemoning script running in a virtualenv, or something to the same effect, you'd notice the improvement over SysV init scripts.

Upstart is nice too, but as a Linux desktop user I love socket activation: I can have cups, avahi and other optional/non-critical daemons "active" but not actually using any resource, until effectively used by some other process.

>If you ever have written a /etc/init.d script for a python non-daemoning script running in a virtualenv, or something to the same effect, you'd notice the improvement over SysV init scripts.

These are solved problems. You're creating a bunch of low level OS spaghetti because you don't want to have to write a shell script for your software? That is not a responsible decision-making process, that's moving the mountain to you.

And making it harder for someone to come afterwards and untangle the mess.

I swear a earlier discussion here on this very site had someone honestly suggest the usage of strace to figure out why systemd failed to boot.

Countless subtle race conditions and security issues in the shell spaghetti that makes up real-world init scripts indicate that it's not a "solved problem".

That's probably because util-linux has a command, logger, which can optionally log to systemd's journal. Take a look at http://man7.org/linux/man-pages/man1/logger.1.html.

Probably accidentally, due to a poorly abstracted dependency chain.

Debian:

[wget]-depends-[libuuid1]-recommends-[uuid-runtime]-depends-[libsystemd0]

Ph’nglui mglw’nafh Cthulhu R’lyeh wgah’nagl fhtagn

Reply on news.ycombinator.com