Debian May Be Leaning Towards Systemd Over Upstart

[gens]

Well, to an *extent*. The problem is the person criticizing Neil was doing the same thing: arguing about the person, not about the issue. Levelling an entirely unfounded accusation at *Neil Brown* that he doesn't understand the Unix way is, you have to admit, pretty funny.

actually reading that it shows he understands UNIX all too good
"solve only 90% of the problem" is also one of the... how you call them.. unix guidelines (?) and he demonstrated it in the example
(i read a bit of the Unix haters handbook and recommended it to all who wanna laugh (note for people: you might or might not learn something from it while doing that))

he also subtly states systemd is not perfect (another note for nitpicky forum dwellers: nothing is perfect)



@middy and others who talk about "unix lovers", "the future", "lennart haters" and so on

i never used a Unix (installed solaris once long time ago)
but i like the generic "keep it simple, stupid" principle, that goes along with "do one thing and do it well"
ofc if the goal can be done simpler by doing more things...

i think (my opinion, gosh) linux needs standardization
a well planed standardization of data formats, mechanisms etc. (like wayland for example or the LFS filesystem standard or POSIX or ...)
that could bring about a simpler but still powerful end system

but then again that is my opinion, and i am not entitled to my opinion 'cuz i dont like lennart's approach to problems and questions at hand (also i type without punctuation, that pisses off some people)
(PS i only mention him after someone repeats he's reasoning without understanding it)

funny enough i can be that kind of an asshole from time to time, but i learn and some times maybe even apologize (the dbus in kernel talk he seemed down to earth)

[mrugiero]

"solve only 90% of the problem" is also one of the... how you call them.. unix guidelines (?) and he demonstrated it in the example
(i read a bit of the Unix haters handbook and recommended it to all who wanna laugh (note for people: you might or might not learn something from it while doing that))

I read just a little bit of it. It was funny, it mixed hilarious comments with real criticisms and with pure, only partly justified hatred. Clearly what anyone wants in a haters handbook.

a well planed standardization of data formats, mechanisms etc. (like wayland for example or the LFS filesystem standard or POSIX or ...)
that could bring about a simpler but still powerful end system

I agree with this.

[beetreetime]

While it is true that systemd now does mean a lot more than "init process", and near future you'll be able to argue that even kernel implementation of dbus is systemd, doesn't change the fact that in practice the tools are very separate. So, please stop parroting old, multiply refuted arguments and actually read (or watch) what Pottering has to say. If you don't want to, shut up and migrate back to BSD edition 3, as you obviously like 80's so much. We'll be working in the present working on current problems.

They don’t have to go that far. There’s Slackware and Crux. Linux distributions known for their stubboness in accepting new technologies.

On that subject, the Linux community will get a great boost if all distributions rally behind systemd. It’s time for distros like slackware to be made to use systemd.

Add the news that dbus will eventually be moved to the kernel. This goes against the UNIX philosiphy that at its base is a collection of small tools specialized in doing ONE thing well.

OSes compliant with the UNIX philosophy and POSIX are useless today. Don’t believe me? Just look at all the BSDs today. They are so useless that their developers use either windows or apple macs instead of usinf what they develop.

[Delgarde]

Nice, I'm glad to hear that the technical committee are making technical choices.

Having read through that long email chain in detail over the past month, I think that's a stretch. Certainly there's a leaning towards systemd, but they're nowhere near actually making decisions - at best, I think they might have decided that they had to make a decision...

[Delgarde]

Too bad... I had hoped for openrc. If the choice is between systemd and upstart, then systemd is definitely better.

OpenRC was never really in the running. From very early on, the discussion made it pretty clear that if they were going to go through the pain of changing from sysvinit, it would be to something actually worth that pain. OpenRC was not regarded as offering any substantial advantage over Debian's existing setup...

[Delgarde]

i don't know if any of you know this but some debian developers are also systemd developer

Well, sure... some Debian developers can be found contributing to various projects. At least one of the technical committee discussing this issue is a contributor to Upstart, and is having to be very careful about conflicting interests...

[Delgarde]

I have nothing to say against systemd. It is working fine.

My concern is that it is getting bigger and bigger all the time and IMO this is worrysome.

It could be a perfect replacement for sysv init without replacing syslog. I have heard that it is about to replace inetd. What is next?

Well, think about it. The job of an init system is to start processes - various daemons, from web servers to ssh servers to display managers. And oddly enough, that's exactly what inetd does as well. So why run a separate inetd service when 99% of the functionality is already present in the init system? Right from day one, one of systemd's features was that it used knowledge of the sockets used by a daemon to aid dependency tracking, so it's not like an inetd-style handover system is a big deal.

Oh, and when you say "about to" replace inetd, it already has. That's how Fedora runs ssh by default - rather than a long-running daemon, it uses socket-activation to start a daemon per-connection, essentially the same thing as inetd...

As for syslog - consider that an init daemon is the only thing in the system that can catch the stdout/stderr output of a running daemon, and ensure that gets logged as well as stuff that went properly to syslog. That's a damned useful feature, so don't go thinking it's unnecessary for systemd to have anything to do with logging...

Add the news that dbus will eventually be moved to the kernel. This goes against the UNIX philosiphy that at its base is a collection of small tools specialized in doing ONE thing well.

The UNIX philosophy is just that - a philosophy. It's not some fundamental law of the cosmos that says that a highly modular system is the best way to do things, and more to the point, it doesn't mean that everything must be split into small pieces if it doesn't make sense to do so. It's not holy law, despite what some people seem to think...

But as it happens, systemd *is* highly modular. It might be a single source package, but it's not like the whole thing is compiled into just one binary that does everything. The systemd binary does the stuff that makes sense to be in PID 1, but stuff that doesn't is split into a handful of utility binaries and dbus services...

With PulseAudio on top of it, by centralizing everything in a single place, that sounds like a terrible catatrosphe waiting to happen. If this gets compromised, linux boxes, will become amazing spying devices knowing everything that the user is doing. I really don't like where this is going!

Oh, wonderful... now we're getting into conspirary theories... obviously Lennart works for NSA, and is trying to dominate the world by sneaking backdoors into all of his open source contributions. And not just Lennart, but all other people who work on those projects. No, get real...

Really, think about it. If *anything* gets compromised, that could happen. Nothing to do with systemd, or whether you favour complex init systems or simple ones, or putting everything into one package or not. If you want to be paranoid, make sure there's no dodgy code in the kernel, or in your desktop, or bash or gcc, or coreutils, or any other package you run on your system. Because a backdoor could be added to those just as easily as in systemd or pulseaudio...

[Delgarde]

The problem is, systemd fixes multiple ugly issues which really are unsolvable for anything but the init system. And sure we've lived them for few decades. You can also live with a nail in your foot for a long time, doesn't make it desirable.

Exactly. The people complaining about adding complexity to PID 1 miss the point that there are real problems that can only be solved by putting code in PID 1. Logging, for example - with classic sysvinit, the only way to get stdout/stderr output from a daemon was to shut it down, then manually run it in a terminal, passing extra parameters to stop it from backgrounding itself. But if you're prepared to make PID 1 smarter, you never need to background the daemon, and thus trapping output and redirecting it to a log becomes a trivial problem.

Similarly, a proliferation of daemons with essentially the same function of starting other processes - init, inetd, crond, atd. It's easy to talk about UNIX philosophy and modularity, but what about the amount of redundant code covered by those four services? The fundamental feature of all of them is that they start processes and (potentially) trap the output and report it in some way - the only difference is a triggering event (system startup, a socket connection, or a scheduled time). Is merging some of them into a single service such a bad idea? Especially the latter two - there's really no good reason for having two separate daemons responsible for scheduled tasks, differing only on whether the tasks are recurring or one-off...

[peppepz]

I've maintained my little Linux installation since the 90s. Systemd is too complex and undocumented for me, so once the Linux userspace begins depending on systemd, it's end of line for me. Linux is no different than OpenSolaris or Darwin if it becomes an opaque item that other people make for me and I use as-is. Sigh, I'll find a new hobby. Rant over, everybody get off my lawn now.

[Delgarde]

but i like the generic "keep it simple, stupid" principle, that goes along with "do one thing and do it well"
ofc if the goal can be done simpler by doing more things...

And that's the thing - "do one thing and do it well" isn't always the same thing as "keep it simple". Often, that just results in a lot of very simple pieces, and some absolutely unholy levels of complexity that glue all the simple pieces together. So it's little surprise when someone new comes along, sees this, and says "to hell with unix philosophy, this'd be much simpler if it was more monolithic".