Debian May Be Leaning Towards Systemd Over Upstart

[Ericg]

You may wish to read again. I am specifically railing against arguments based purely on the person. My immediate and top problems with systemd include journald's logging format and the sheer size of the codebase.

Ah, apologies, I was very exhausted last night.

The logging format is personal preference, frankly I don't care. And if I really need a text-dump then thats what "journalctl -o export" is for.

The size of the codebase... As others have said, whats the big deal? Its not all one binary, its not all pid 1. Systemd is and will remain the name for the umbrella project, its a collection of tools specifically designed to work together, that doesnt mean its all in the systemd binary.

[Laser]

The "systemd is linux only" argument made by some is totally moot IMHO. If components which cannot be swapped between debian versions are a matter, why do they support jails? They don't work on Linux. Same for pf. Also Lennart does not have to accept patches made for BSD compatibility because it means they had to guarantee BSD compatibility and as they don't use it, they have no interest in that. Or even the possibility, if you so want. However, nobody stops you from creating a BSD fork of systemd.

My immediate and top problems with systemd include journald's logging format and the sheer size of the codebase.

If you want text log, just do "systemctl enable syslog-of-your-choice.service" and you have your old logging format back. Though I don't know what the advantage of those are.

[peppepz]

Now you've now created a persistent bash subshell that can't exit until the daemon does, something repeated for every single daemon you have running... a dozen processes that do nothing but accept the stderr output of another process and dump it to a file. And if the daemon does write it's normal logging to syslog, you've got two files containing disjointed logging output which you have to reconcile when hunting for errors, difficult if the stderr output lacks timestamps. Whereas by having both syslog and stdout/stderr output handled by the init service, having them merged into the same log is relatively trivial.

The subshell is just an example to show that even something as dumb as a bash shell can capture the standard error of a daemon and save it to a file. So saying that this is a "real problem that can only be solved by putting code in PID 1" is simply not true. Which does not mean that putting code in PID 1 is wrong. What is wrong is stating it as inevitable.

No idea what that count includes (does that count config files?)

Yes. The binaries and libraries amount only to 40. Their behaviour is defined by the config files, among other things.

but what's your point? I'm objecting to the idea of 4 daemons that do essentially the same thing - whereas presumably the 538 files you refer to don't.

My point is defining what is a proliferation and what is acceptable complexity. Numerically, four things aren't a proliferation, in my opinion; hundreds of things are. Conceptually, saying that inetd does the same thing as cron is like saying that a punch card reader does essentially the same thing as a blu-ray reader: it's true, but you can't operate them without knowing the differences. Thanks to its design, UNIX allows you to communicate over the internet almost in the same way as you would between local processes. But there are different considerations that need to be taken into account for internet services compared to local services, the first ones that come into my mind: security, performance, network configuration. Does that complexity goes away if we merge cron with inetd? No, it's only hidden, therefore harder to study, and the result is less modular, therefore less flexible.

Eh, stuff changes, you learn new stuff. That's just the way the world works....

That's a straw man. I embrace change when it's for the better. In particular, time is money, and if I must invest time into learning new stuff, I need to have good reasons for that. Otherwise I'll just keep the old stuff, because knowing how stuff works if fundamental when it happens to break and you are supposed to fix it.

There's value in standards, no question - but you're talking about taking two existing systems that achieve similar results via wildly different processes, and trying to find some level of compatibility between them. The best possible outcome is that you end up with something so abstracted around the lowest common denominator as to be totally worthless...

The only possible outcome without standards is that we have a single implementation, and clients of that implementation must accomodate to its changes. This is fast, works, and can even be very successful: take as examples MS-DOS, or ACPI.

Oh, and competition doesn't necessary lead to better code quality...

Not necessarily. But in biology, mutations are the only propelling force of evolution. In software, the existence of different implementations allows for testing different designs whose advantages are not clear until they're adopted in production. To make concrete examples, I think that the quality of GCC improved since LLVM is there. Same for glibc when the eglibc fork appeared. And ffmpeg vs libav. And even Windows vs Linux, if we put one foot outside of the open source world.

[mrugiero]

Systemd as Debian's new init-system of choice has probably just been dealt its fatal blow as upstart is preliminarily working with kFreeBSD. Given the immature refusal of Poettering to even accept any patches allowing systemd to run on other platforms, which is vulgarly defiant of Debian's stated aims, one assumes they will be leaning towards upstart once more.

And thank goodness I say. Software monoculture is a trend that the FOSS community has been moving to, under the weight of Red Hat and their ilk. Someone needs to say no to this.

You are assuming that a) kFreeBSD is a priority to Debian and b) they will keep the same configuration for Linux and kFreeBSD.
They are defining the default, not the everyone-will-use-it-like-it-or-not package. Even Keith Packard said he believes Debian will have to support more than one init system, so his defense of systemd is clearly just to make it default. If systemd suits better the needs of more users (and Debian GNU/kFreeBSD has FAR less users than Debian GNU/Linux), then it's probable a better default. This doesn't mean they can't use upstart (or more likely launchd) in kFreeBSD.

[peppepz]

2) You can't, without sacrificing all of the things that make journald so good, like different log priorities (warn/error/debug etc.), filtering, unified timeline view (where all of the daemon messages are shown in one place in the order that they were emitted, including the messages from the init system itself), etc.

Log priorities in the standard error? You can't have them unless the program is rewritten with the promise that its standard error is formatted in a certain way. Which is against (1) - and then a well-behaving program could as well use the syslog. Logging by process name is found in the plain inetutils' syslogd and is in upstart too: but this discussion is really unnecessary, because the point was whether those things *need* to be done by pid 1 or not. I am already convinced that systemd is excellent software.

You couldn't argue that. If anything, the main function of the kernel would be to control the hardware.

What do I do with a well-controlled hardware that doesn't run processes? What's your opinion about microkernels, which do not control hardware by design?

Care to point out an example?

Systemd's sd-daemon library. It can be used to achieve init-system-independent socket activation and service state notification.

No. With the new approach, you issue systemctl disable network.target and carry on with your day.

It's not the same thing. Also, you're exchanging a soft requirement (that a server is stopped when I no longer want the network target) with a hard fact (with a stopped inetd, there is no way that any internet socket-activated service can be executed).

Or even better, disable the actual services that you don't want to boot, because otherwise you might accidentally stop a service you did want to boot after all.

That's only a problem if the same program that serves internet services also manages your console session. I know that I have no critical services depending on inetd, and that I can keep running internet clients if I stop inetd.

Stopping the inetd daemon is a horrible, hacky way of doing that and you should never even consider doing that as an option.

It was just an example. And we have a different idea of what's a hack and what's elegant.

And that's what unit files are about. They are supposed to be cross-distribution,

Debian for instance are currently shipping modified unit files to suit their unique environment, IIRC.

and as far as I know there is nothing preventing other init systems from using them.

Now that would be a good idea. How practically realizable, I don't know.

[Marc Driftmeyer]

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.



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.

Never mind OS X is UNIX and POSIX Compliant.

[Siuoq]

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

http://www.debian.org/devel/constitution#item-6

technical means, they should decide in technical question. Obviously they should find the solution what is the best for Debian Project, and not, which program is technically better

[Siuoq]

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

http://www.debian.org/devel/constitution#item-6

technical means, they should decide in technical question. Obviously they should find the solution what is the best for Debian Project, and not, which program is technically better

You...really can't simplify things that much.

It's not like there is a single systemd process running which does init, and journalling, and everything else. Just because the functions are part of one *project* doesn't mean they're part of one *code path*. It's not like a bug in systemd's journalling code will inevitably break your init sequence. Functions can be isolated from each other without being part of completely different development projects.

GNOME requires logind for some reason, therefore they requires systemd as PID 1 well. systemd is the bug you mentioned.

[finalzone]

GNOME requires logind for some reason, therefore they requires systemd as PID 1 well. systemd is the bug you mentioned.

OpenBSD runs Gnome 3.10 without using logind.

https://www.bsdfrog.org/tmp/gnome310.webm

In addition: https://wiki.gnome.org/ThreePointEle...emdUserSession

It's important to note that with these patches, we still support non-systemd systems (as well as older systemd). How far into the future we do so is an open question, but it should not be too difficult to leave non-systemd systems with the previous model over the next few cycles.

[Ericg]

GNOME requires logind for some reason, therefore they requires systemd as PID 1 well. systemd is the bug you mentioned.

You can rip out the logind requirement, the developers specifically not (see the other user's post like 1 or 2 above me). MORE specifically though... Gnome doesn't actually require -LOGIND- what it requires are the dbus interfaces that currently only logind provides. But if someone wanted to start their own login project that provided those same interfaces then Gnome could require logind OR $project_name OR neither of them for as long as the fallback code is maintained.

Thats the beauty of it, you don't depend specifically upon logind, you depend upon the dbus interfaces it provides. Then if something else wants to provide them and do it in a non-breaking manner, then its just a drop-in replacement