Live data from Hacker News

Debian committee members vote for systemd as init system

lists.debian.org

101–110 of 152 posts

Re: Debian committee members vote for systemd as init system

#101

Earlier quoted context omitted.

Well, when Lennart says that *BSD is irrelevant as if he was the judge of that... I don't see why he shouldn't be able take a little heat. After all - he is the god that wrote, you know, PulseAudio and Systemd. There are other hackers around that are not "Linux hackers" who might have a different view about the quality of Linux space. I tend to agree with them.

What does this suddenly have to do with BSD? kashchei claims that Lennart is incapable of ever producing good code and that all his creations must therefore die. Nothing about BSD.

It may seem unrelated but it is not. Lennart lacks the humility necessary for his contributions to be considered genuine advancements. He dismissed BSD in the context of discussing systemd. The way he put it, anyone who doesn't see the light coming from his code is irrelevant.

When I put this next to the half-success that PulseAudio is (which was similarly promoted and blindly embraced by all major distributions out there), I find questionable the idea of systemd being the next best thing since hot water.

Re: Debian committee members vote for systemd as init system

#103

I have to remind everyone that the author of systemd is Lennart Poettering, the guy behind Pulseaudio. I think, this is one "feature" that should outweigh all supposed benefits of this program. For those unfamiliar with Pulseaudio development, it's a third-generation audio subsystem (after OSS and ALSA with JACK forming two previous ones, and ESD being the beginning of the third) that is famous for overcomplicated, n…

PA was force-pushed too early, systemd got it's own momentum. AFAIK PA suffered from external unsolvable forces, like hardware/driver giving inconsistent if not false data to PA, causing failures; I believe systemd is shielded from this. The benefits (sound dependency based state) already outbid the other issue one might have with it (less freeform scriptability as in SV).

Re: Debian committee members vote for systemd as init system

#104
post #90

I have to remind everyone that the author of systemd is Lennart Poettering, the guy behind Pulseaudio. I think, this is one "feature" that should outweigh all supposed benefits of this program. For those unfamiliar with Pulseaudio development, it's a third-generation audio subsystem (after OSS and ALSA with JACK forming two previous ones, and ESD being the beginning of the third) that is famous for overcomplicated, n…

I find hard to read such comments and think that they are valuable contributions anymore. First of all, Pulseaudio was not the biggest success, true, but can't someone learn from their mistakes? Both are also living, moving software products that continue to improve, as you said, "development marred with huge number of bugs that ruined audio on Linux until recently" - key words: "until recently". Secondly, about the…

The design is still beyond horrible, and on par with Windows. If everything that can be shoehorned into a system and "works" despite being a complicated mess, was accepted, we would have adopted Windows registry and SNMP as primary configuration mechanisms, too -- after all, they both work more reliably than Pulseaudio does.

Re: Debian committee members vote for systemd as init system

#105
post #62
post #17

Can anyone give a quick rundown of the different init systems? For the most part it can get confusing for a non day to day system administrator when I am trying to get a program to "run on boot". Between rc.local, init.d, run levels, etc. sometimes it is just frustrating.

I can give a simplified overview of the major difference as I understand it (the difference being the method by which each init system starts its daemons on boot): sysvinit/bsdinit - Starts daemons in serial (i.e. synchronously). Considered slow and outdated by today's standards. upstart/launchd - Starts daemons in parallel, based on which daemons depend on each other (If B depends on A, A is started first. If C does…

Ah um some of this is wrong.

upstart doesn't have dependencies thats systemd. Upstart you have to specify when a service should start based on events or combinations of events like "start on started avahi and started nfs". Theoretically this make upstart more flexible though complex event handling is mostly broken. This system also means upstart ends up trying to start everything it can it might start a service which is not needed but because it's start on event has activated it starts. systemd differs in that only required services for that .target are started (and services required by those.

systemd has Require/Wants to specify dependencies as well as the socket activation features. Socket activation requires a compliant daemon as well so a lot of services still use explicit dependencies. Socket activation does give you a lot of other stuff for free, listening on privileged ports as user, restarts without dropping connections, delayed start (not starting until requests come) etc.

Re: Debian committee members vote for systemd as init system

#106
post #90

I have to remind everyone that the author of systemd is Lennart Poettering, the guy behind Pulseaudio. I think, this is one "feature" that should outweigh all supposed benefits of this program. For those unfamiliar with Pulseaudio development, it's a third-generation audio subsystem (after OSS and ALSA with JACK forming two previous ones, and ESD being the beginning of the third) that is famous for overcomplicated, n…

I find hard to read such comments and think that they are valuable contributions anymore. First of all, Pulseaudio was not the biggest success, true, but can't someone learn from their mistakes? Both are also living, moving software products that continue to improve, as you said, "development marred with huge number of bugs that ruined audio on Linux until recently" - key words: "until recently". Secondly, about the…

Also: just saying that something is a myth does not make it any less true. The whole point is that systemd (and Pulseaudio) is anti-Unix because its author does not understand Unix design, how would his opinion be of any value in this matter?

Re: Debian committee members vote for systemd as init system

#107

I have to remind everyone that the author of systemd is Lennart Poettering, the guy behind Pulseaudio. I think, this is one "feature" that should outweigh all supposed benefits of this program. For those unfamiliar with Pulseaudio development, it's a third-generation audio subsystem (after OSS and ALSA with JACK forming two previous ones, and ESD being the beginning of the third) that is famous for overcomplicated, n…

PA was force-pushed too early, systemd got it's own momentum. AFAIK PA suffered from external unsolvable forces, like hardware/driver giving inconsistent if not false data to PA, causing failures; I believe systemd is shielded from this. The benefits (sound dependency based state) already outbid the other issue one might have with it (less freeform scriptability as in SV).

I see a pattern here. What guarantees that in ten years the same claims won't be made about systemd being pushed in 2014 "while not ready", but by 2023 all issues are ironed out after the whole thing was rewritten three times and was responsible for more security breaches than bind and sendmail combined over their history?

In my opinion, there is no replacement for true modularity, simple, future-proof interfaces, and clear, human-readable and human-writable formats.

Re: Debian committee members vote for systemd as init system

#108
post #74
post #27

Earlier quoted context omitted.

This is the second part: http://aceattorney.sparklin.org/jeu.php?id_proces=57899

Unfortunately, the second part seems to get stuck in "cross examination" and it's impossible to continue.

Does it? It's a Phoenix Wright game. You have to press and present evidence.

EDIT: You're right. Pressing each statement yields more dialogue, but without evidence, you can't progress.

Re: Debian committee members vote for systemd as init system

#109
post #81
post #40

Earlier quoted context omitted.

I know less about the new Linux ones, but a brief summary of the two big "traditional" ones: Linux systems traditionally use "SysV Init", the init system from AT&T UNIX System V (1983). It's the one that has: 1) run levels; and 2) a pile of shell scripts in /etc/init.d that run on run-level changes. Run levels probably make most sense if you think of Ye Olde Mainframe booting: first it initializes core services, then…

Whoa! You aren't bashing any of them and the explanation is 100% correct! WHAT HAS THE INTERNETS COME TO? Congratulations on a very well-written summary!

WHAT HAS THE INTERNETS COME TO?

The way it was supposed to be?

Re: Debian committee members vote for systemd as init system

#110

Earlier quoted context omitted.

PA was force-pushed too early, systemd got it's own momentum. AFAIK PA suffered from external unsolvable forces, like hardware/driver giving inconsistent if not false data to PA, causing failures; I believe systemd is shielded from this. The benefits (sound dependency based state) already outbid the other issue one might have with it (less freeform scriptability as in SV).

I see a pattern here. What guarantees that in ten years the same claims won't be made about systemd being pushed in 2014 "while not ready", but by 2023 all issues are ironed out after the whole thing was rewritten three times and was responsible for more security breaches than bind and sendmail combined over their history? In my opinion, there is no replacement for true modularity, simple, future-proof interfaces, an…

systemd is already used and from what I've seen there's far less complaints than PA[1], even talks of admins suggesting to look into it. That's for the 'not ready' part. For the rest, I'd agree with you, but I think the gain in abstraction and correctness is quite worth it, even with it lacks some simplicity.

[1] never encountered a single issue with systemd since archlinux pushed it as default, even on hybrid sysvinit scripts and naked systemd installs, compared to PA which may crash far too regularly, but that's just me.

Post reply on HN