The Debian init system general resolution returns

by mariuz • 12 years ago

66 111 12 years ago

Shish2k3• 12 years ago

So the impression that I'm getting is that some people just want Jessie to be released, even if some packages only run correctly under systemd; others wish for debian to enforce "every package must run correctly under every init system" (excluding things like init-system management tools, which are clearly tied to their system).

I wonder, how much difference does it make either way? What packages which only support systemd are we actually talking about, and how much work would it be to untie them?

pantalaimon4• 12 years ago

What packages which only support systemd are we actually talking about

Gnome, Wayland, KDE

how much work would it be to untie them?

a lot

KayEss4• 12 years ago

That sounds like a pain for my desktop, but implies there's still hope to use a simpler init on my servers so long as the coupling doesn't increase.

VLM2• 12 years ago

There is an architectural failure if your desktop environment depends deeply and inseperably (product tying) on how you spawn processes at boot.

systemd may or may not suck and I'm not discussing that aspect in this post. What definitely horribly sucks is product tying a desktop environment (you know, cut and paste, drag and drop, background images, window animations) deeply in with the earliest intricacies of the boot process.

edwintorok7• 12 years ago

I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal.

For example policykit was broken and things like mounting USB devices or managing VPN connections didn't work. That is finally fixed and with latest cgmanager from unstable, and policykit-1 from experimental those things work again.

The only noticable loss compared to systemd is the lack of 'Suspend/Hibernate' in the KDE menu, but you can still use 'pm-suspend' from the cmdline, or even with 'qdbus' and the systemd specific dbus API, so in the end this should be fixable too.

So I wouldn't put KDE into the same bucket as Gnome, its dependencies on systemd seem to be mostly indirect:

* policykit, which started to depend on systemd-logind instead of consolekit. Works with cgmanager+systemd-shim as replacement

* upowerd doesn't support suspend/hibernate anymore but apparently, so apparently systemd specific dbus methods have to be used now.

Also Gnome3 works under OpenBSD (with consolekit?), and there is definitely no systemd there, although it might not be the latest version: http://callfortesting.org/gnome3/

edwintorok7• 12 years ago

IANADD, but actually I like this alternate proposal better: http://article.gmane.org/gmane.linux.debian.devel.vote/17248 "Debian's standard requirement to support smooth upgrades from wheezy to jessie still applies, even when the system is booted with sysvinit."

I think that is a sensible requirement as upgrading from sysvinit-core to systemd-sysv was quite problematic (wouldn't boot if you had some entires in ftab, etc.), and some may want to stay on sysv at least for an initial reboot.

buster2• 12 years ago

Not again... I think this was already decided.. Can we just move on? I've switched to systemd on my laptop months ago and had not a single problem. Boot times are noticably faster.

Does Linux have to stay at software from the sixties forever? Can't we just move on to systemd and wayland and whatever fits better into the 21st century?!

I really feel this is all too political and FUD after months and months of senseless complaining about systemd and particularly far too personal regarding Lennart Poettering. If people like SysV init so much there will always be alternatives but this shouldn't hinder the majority of users to move forward with systems that just work with systemd (e.g. Debian+Linux). Nobody really uses Debian/kFreeBSD anyway, for example. Yet, it's a common statement that is brought up.

untothebreach3• 12 years ago

I would be thrilled if Debian gave users the choice of init systems. I switched to systemd a couple months ago as well, and had nothing _but_ problems. My laptop never turns off, so boot times are irrelevant to me, and I would like to have a linux system that actually allows me to listen to audio, obtain an IP address, etc.

I would gladly switch back to Debian if I could swap systemd out for something else.

pantalaimon4• 12 years ago

systemd in Debian is still in testing, it's expected to be buggy at this point.

Have you tried a distribution which already comes with systemd preconfigured, such as Fedora, Suse or CentOS?

ultramancool7• 12 years ago

Please do not dismiss legitimate issues as personal attacks. Just because you did not hit issues, doesn't mean others didn't. My experience was quite negative:

- Binary log files, which are also prone to corruption and crashes

- Unnecessarily complicated and unfamiliar init script structure. I feel like I went from one that was arguably too verbose to one which is too vague.

- The need for unnecessary things like dbus to be run at startup

- Complication of some simple configuration tasks (in my experience on Arch at least, network configuration was a bitch)

- udev has apparently been hijacked and may cause issues for those who don't want systemd

All in all, it feels like change for the sake of change to me, I see no advantages which I desire, and several minor to moderate disadvantages, but learning and using it is pushed on me for no reason. Personally, I've moved to running FreeBSD, it's simple and stable, though I've been considering Debian/kFreeBSD, I'd be sad to see it go. But it's the farthest of the issues with systemd IMO.

As far as your boot time improvement goes, that's great, but modernly, my systems are either always online or suspended to RAM or disk, rarely rebooted.

buster2• 12 years ago

Sorry, but all your reasons are no bugs or technical problems. Frankly, it seems to me that this is your inability to accept change.

Yes, sometimes we need to embrace new things and learn new things. That doesn't mean they are bad.

And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init just because you might or might not use Debian/kFreeBSD at some point in the future (instead of FreeBSD in the first place).

If i remember correctly kFreeBSD even is in such a bad unmaintained state the the discontinuation of it is discussed. Yet, you bring it up as an argument against systemd.

(FYI: As of February 2014, popcon registered 130 kFreeBSD, compared to 32 HURD users, and 165,821 Linux users. )

P.S.: I reboot my laptop everyday, i don't suspend.

nodata2• 12 years ago

- Unnecessarily complicated and unfamiliar init script structure.

Unfamiliar, yes. Complicated? You have to be kidding me. systemd "scripts" remove the crud and hacks that the old init system built up over years.

antihero2• 12 years ago

(in my experience on Arch at least, network configuration was a bitch)

What exactly about this was hard?

I have one config file - /etc/wpa_supplicant/wpa_supplicant-wlan0.conf - which you can add to simply with wpa_passphrase "MySSID" "MyKey" > /etc/wpa_supplicant/wpa_supplicant-wlan0.conf

Then I ran a couple commands once:

systemctl enable wpa_supplicant@wlan0

systemctl enable dhcpcd@wlan0

And now it happily connects to any of the wireless networks I've set up in the config file.

If I want to control it or switch networks or reload my config, I can use wpa_cli to do this easily.

Totally minimal, no need for NetworkManager or netctl or anything, and works flawlessly.

Obviously if your net setup is more complex, this could require a better tool, but most of weird stuff would be done with iproute2 or whatever.

dnlrn3• 12 years ago

Binary log files, which are also prone to corruption and crashes

Why are they more prone to corruption? Software bugs aside they should actually be less prone to corruption, because they allow you to verify if corruption has happened. syslog has no such mechanism.

Unnecessarily complicated and unfamiliar init script structure. I feel like I went from one that was arguably too verbose to one which is too vague.

Yeah, right...

The need for unnecessary things like dbus to be run at startup

Why is dbus unnecessary? It’s a great way to do IPC. So great that it will be implemented in the kernel as kdbus.

Complication of some simple configuration tasks (in my experience on Arch at least, network configuration was a bitch)

The init system was never responsible for setting up your network. Even before systemd, Arch recommended netcfg/netctl instead of setting it up in /etc/rc.conf.

monstermonster2• 12 years ago

Not really a deep Linux user here but systemd brings the bad bits of windows to Linux: Abstract stateful configuration, black boxes and communications to do simple tasks. As someone who supports lots of software built on this approach (windows desktop) then I will assure you it's a pain in the butt big time.

Sure it may work for you but if N machines have state A and P machines have state B then getting all N and P machines to state B is incredibly difficult. It looks easy until you do it. That's probably one of the largest and most common things we do when deploying more than a trivial single machine.

To put it into perspective, everything becomes as much of a PITA as RPM packages without yum.

That was immediately obvious to me when I installed CentOS 7 on a couple of test machines to replace our costly Riverbed appliances and timedatectl threw "failed to issue RPC" on one machine but not the other. Same steps to install.

That's where we don't want to go.

We are now running FreeBSD and nginx on a HyperV cluster.

sethrin2• 12 years ago

Abstract stateful configuration might be a bad thing, but having a configuration file execute arbitrary, complicated code sounds like a much worse thing to me. I would be interested in differing opinions, but I think in another context the words "executable configuration file" would be a cause for deep concern.

andmarios3• 12 years ago

Since you switched to systemd on your laptop and everything is ok, I have to inform you that on Wednesday I switched my PC to systemd and nothing was ok to the point where I had to install another Linux distro and lose some good hours in the process.

vezzy-fnord4• 12 years ago

From what I can tell, all this means is that Debian packagers will have to drop hard dependencies on components of systemd in many cases. I see nothing objectionable with this, as there have been some absolutely inane things going on at the packaging sphere. For example, treating the fact that upstream provides a systemd unit file as a dependency on systemd. To some extent, this can also be blamed on inherent weakness in most contemporary package managers that lack the ability to easily express multiple classes of dependencies, and treat everything as a hard one.

That said, we still keep saying the same shoddy sentiments from systemd proponents. "Can't we just move on?" "systemd hasn't had any problems for me. Don't like it? Leave it!", "This must be Canonical.", so on and so forth.

The /r/linux thread is a depressing clusterfuck of uninformed proponents, as always.

_delirium2• 12 years ago

One thing that is not making the discussion clearer is that many people are failing to distinguish between two different kinds of dependencies. Depending on a systemd library versus depending on the systemd daemons running are quite different scenarios. It would be ideal for the latter to be minimized, but the former is not a problem at all.

To take an analogy, plenty of Debian packages depend on libselinux1, because they feature optional selinux functionality, and not depending on libselinux1 would result in broken symbol tables. But most of these packages work perfectly fine without SELinux configured (as you might guess, since very few people actually have SELinux configured). Having libselinux1 on your system does not require you to use SELinux, and imo it would be unreasonable to complain that your system is now "infected" by SELinux because you can't uninstall libselinux1. It's just a library, like many others, and having it on your system doesn't impose policy requirements on you as administrator or user. Yet people are making exactly that argument with systemd, complaining that some systemd library or another is on their system and thereby "infecting" it. Rather than focusing on the more legitimate issue of which packages actually require systemd daemons to be configured/running.

digi_owl2• 12 years ago

Do systemd even have such a "inert" lib?

Best i can tell everything happens via dbus (to be replaced with kdbus), and that again requires that systemd is running as pid 1 (as it will refuse to run as anything else, unless it is inside a namespace governed by another systemd as pid 1).

EmanueleAina6• 12 years ago

I agree with the sentiment of not having hard deps on systemd. In fact many teams already put some actual work toward that goal (eg. the GNOME team) but the main problem I see is who is mandated to do this work.

As an example, GNOME upstream requires logind if you don't want to rely on the bug-ridden and unmaintained ConsoleKit.

AFAIK the Debian GNOME team does not wish to enable the ConsoleKit backend on Linux due to not having enough resources to test it and nobody stepped up to maintain it. While they initially represented this fact with a dependency on systemd, but ultimately said dependency is now on libpam-systemd, which depends on systemd or systemd-shim.

So it's not like Debian teams are against what the GR proposes, but it's easy to see the GR as a way to force them to do work that they don't have the resources to do.

ausjke2• 12 years ago

To make Debian init-neutral is a great idea in my opinion, just like Linux distro we have many flavors, there is no real reason for mandating systemd to be the sole init system I think. New changes are good or bad, let's give people more choices, the better one will eventually win, or they just co-exist, that's how the nature works, systemd is no different.

Morgawr• 12 years ago

To make Debian init-neutral is a great idea in my opinion, just like Linux distro we have many flavors, there is no real reason for mandating systemd to be the sole init system I think.

Oh, it's an amazing idea. So I assume you candidate to be a fulltime maintainer of the whole software stack and packages, right? Why don't we support OSS4 too, while we're at it! After all, support for everything is just free of man hours!

ausjke2• 12 years ago

How about merging all linux flavors into one so we have one system like MacOS? or Windows? hi they each have lots of different versions to maintain, what a waste of resources.

systemd by all means is still new, how can you convince all of us that it is _the_ init system all of a sudden?

It's good to have options, for each apps(email,web server,database,you name it) in Linux there are normally a few options too, why is systemd that different?

acdha6• 12 years ago

How much are you willing to pay for those choices? Each init system doubles your testing load, which is already a concern, but more importantly it also means that there are features which are either need to be dropped or which will require time developing abstraction layers for multiple init systems.

That might still be worth doing but this is a lot more than saying “Oh, if you don't like vim don't install it”. All of that will require time, effort and be a source of bugs / UI clunkiness which no other operating system has to deal with – I'd much prefer that people pick 1 system and spend time getting closer to the “it just works” level which OS X and Windows have been at for years rather than maintaining a stable of patches and extra code.

pyre4• 12 years ago

“it just works” level which OS X

I have experienced issues with launchd which do not exist in the components that it replaced (e.g. cron, init, etc).

For example, try setting a cronjob that runs every minute in launchd (e.g. running fetchmail). launchd says, "process exited too quickly" and disables the entry. [I'll note that this was an old example. Hopefully it's been fixed, but it's been far from "just works".]

ultramancool7• 12 years ago

Why are you using Debian then? Debian is about flexibility, they build for an insane multitude of architectures and they offer Hurd and FreeBSD kernels even! With every package imaginable, Debian maintainers already invest a lot of work in supporting all of this. They work very hard to automate tests and builds in order to minimize this effort level and manage to create a high quality, flexible system.

If you don't want flexibility but instead want a single ascended choice system like on OS X or Windows, use RHEL or one of the forks of it instead. Debian may simply not be the system for you.

felixgallo4• 12 years ago

Linux has been at the "it just works" level for decades, where it matters -- on servers and appliances. It's "Linux on the desktop" where apparently boot times are a big deal requiring screwing up the entire operating system for.

felixgallo4• 12 years ago

The fundamental problem here is that desktop Linux users, who have absolutely had a bad experience over the decades, have gotten so tired of incompetently executed half-assed solutions that they now grab at any other solution with the fervor of a drowning victim.

Why have they gotten to this point? Because the people working on desktop have generally been the D-team. The A-team is working on kernels and infrastructure, the B-team turns out packaging, and the D-team has been coming up with hair-raising stuff like gnome, 'desktop bus', pulseaudio, enlightenment.

So this weird little monoculture has emerged in which no other concern matters except that they get rescued from drowning -- that their boot times (!?!?) go to 5 seconds from 10, that hot-plugging USB drives (!?!?!?!) be wrapped in with the init system if it helps at all, that DHCP (!!??!?!?!?!!) and core files (!!!!!!!!) and all logging (!!!!?!?!?!?!?!?!) be taken over in the name of helping even 1% on the core experience.

But at the same time, two basic axioms of reality still bear:

1. Linux on the desktop is irrelevant and will never win, both in terms of the Linux story and in absolute terms; and every scrap of effort that goes into it has been objectively wasted for two decades and will continue to be wasted.

2. Linux everywhere else has been working fine for longer than most of the desktop people have been alive.

following from (2), the people who run servers recognize that although systemd has some good ideas, it forcibly bundles together a grip of super bad ones too, and is clearly implemented by people who don't understand systems outside of the desktop.

The attempt to turn Debian back into a distribution for everyone, rather than a small collection of desktop people, is completely valid and sensible. That said, it's totally clear why the desktop people want it this way, and why they have such a misguided emotional investment in their terrible new windows emulator.

pyre4• 12 years ago

pulseaudio

To be fair, some of the ideas behind pulseaudio are good:

- Unify all of the different audio systems that existed: OSS, ALSA, esound daemon, etc...

- Network accessible sound. Years ago I was able to setup pulseaudio to stream audio from my HTPC to my laptop where I had headphones plugged in. The process to do this wasn't entirely user-friendly, but prior to pulseaudio, people would setup yet another audio subsytem that every app would then need to support on a case-by-case basis.

EmanueleAina6• 12 years ago

As the existence of CoreOS proves, much of systemd benefits are not desktop-oriented, and I can assure you that many systemd developers/maintainers are not desktop developers but experienced sysadmins/developers.

Thas said, while I may agree with the spirit of the GR, like I may agree with the existence of the Hurd and kFreeBSD ports, I wonder who will do the work needed to patch and support other init systems, given that up to now no-one bothered putting some actual work instead of pretending others should do it.

At least the Hurd and kFreeBSD porters were kind enough of carrying out most of the effort themselves, even if unfortunately I don't think it was sufficient.

(And no, please, systemd has nothing to do with Windows, please avoid such baseless comments which only manage to start useless flames)

sandGorgon3• 12 years ago

Systemd has been trying to drag desktop linux into a world that is as seamless as OSX and it is so sad that most people blast it as "not the linux way". And even sadder that people type this on Macbooks.

The truth is that the West has moved on from Linux - Apple has won. Linux is most relevant in Asia, where we want to run it on cheap, locally assembled desktops. SystemD is bringing so much to improve the state of desktop linux - it is enabling fundamental security like XWindows-without-root[1], service dependency management ,etc.

there is a lot of fud around binary logs (which incidentally are append only and have a grep like interface built around it) and hard dependencies on systemd for any cgroup access. The second is actually kernel mandated - all cgroups have to have a single arbitrator for external applications. Direct access to cgroups will be dropped in the future. AFAIK, as on today systemd is the ONLY arbitrator that complies with the kernel-dev requirements.

I'm keen to see where desktop Linux can go to - I believe that it is going to be transformative for India. I strongly believe desktop Linux initiatives like SystemD and Mir/Wayland is going to take us there

That said, if you have worked with Docker - I find myself wishing very frequently for SystemD as pid 1. Right now I use supervisord as PID 1 (for a multiprocess container) and it is definitely more difficult to use than SystemD. Plus the ease of imposing resource limits (using systemd.resource-control) is simply unparalleled [1] http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights

Zardoz84• 12 years ago

Have you any information about that with systemd, updates of some software that run as service on the machine, would need now to reset the machine ??

For my, it is the only big issue that I see for my personal usage.

sandGorgon3• 12 years ago

Actually, that is another systemd FUD. SystemD enables stateless systems - now that I think of it, very similar to Docker - by clearing out the /var and /etc directories. Which means that when you reboot the system, it acts as a system reset. This is actually, pretty hard to actually implement and systemd is trying really hard to do this.

Imagine being able to build your own private DigitalOcean and able to have pristine machines for a new fleet deployment (possibly even avoiding the stale confidential data issues plaguing DigitalOcean).

http://0pointer.net/blog/projects/stateless.html

randomguy54• 12 years ago

Yeah, but desktop Linux is not really relevant. systemd brings tons of improvements for servers and thats the main drivel for in.

And it's written "systemd", not so camel-case monstrosity.

The Debian init system general resolution returns

Related Stories