Arch Linux to migrate to Systemd • Hacker News Board

Re: Arch Linux to migrate to Systemd

#91

Post by pjmlp » Wed, Aug 15, 2012, 12:13 PM UTC

sparkie wrote: post #89

planckscnst wrote: post #37

systemd is so obviously better than anything out there, I'm surprised there is any controversy. I've yet to see a valid complaint. "Poettoering sucks! PulseAudio!" That's not much of a technical argument against systemd, now is it? Pretty much everyone who complains about PulseAudio doesn't even know what it is; they just blame it when their audio doesn't work (usually for some unrelated reason). "It's not determinis…

> I've yet to see a valid complaint. Perhaps this is the main problem - the people pushing technology are not willing to acknowledge that people have different use cases to them. There are complaints, and they are valid - you just do not see them as valid, because they don't concern you. Since you brought PulseAudio up, there's a very legitimate, common complain about it - latency. Yes, the people who care most about…

Well put.

Re: Arch Linux to migrate to Systemd

#92

Post by ElliotH » Wed, Aug 15, 2012, 12:20 PM UTC

sparkie wrote: post #89

planckscnst wrote: post #37

systemd is so obviously better than anything out there, I'm surprised there is any controversy. I've yet to see a valid complaint. "Poettoering sucks! PulseAudio!" That's not much of a technical argument against systemd, now is it? Pretty much everyone who complains about PulseAudio doesn't even know what it is; they just blame it when their audio doesn't work (usually for some unrelated reason). "It's not determinis…

> I've yet to see a valid complaint. Perhaps this is the main problem - the people pushing technology are not willing to acknowledge that people have different use cases to them. There are complaints, and they are valid - you just do not see them as valid, because they don't concern you. Since you brought PulseAudio up, there's a very legitimate, common complain about it - latency. Yes, the people who care most about…

This takes away no choice, I'm sure if you want to use old style init that'll be available too, you'll just sacrifice easier config, faster boot, better diagnostics, logging and profiling of boot.

Re: Arch Linux to migrate to Systemd

#93

Post by sparkie » Wed, Aug 15, 2012, 12:29 PM UTC

ElliotH wrote: post #92

sparkie wrote: post #89

Earlier quoted context omitted.

> I've yet to see a valid complaint. Perhaps this is the main problem - the people pushing technology are not willing to acknowledge that people have different use cases to them. There are complaints, and they are valid - you just do not see them as valid, because they don't concern you. Since you brought PulseAudio up, there's a very legitimate, common complain about it - latency. Yes, the people who care most about…

This takes away no choice, I'm sure if you want to use old style init that'll be available too, you'll just sacrifice easier config, faster boot, better diagnostics, logging and profiling of boot.

The old init will still be available, but the point is that anything built to run on systemd only, will not be easy to use with older systems without effort to backport them. This isn't much of a problem if you do choose to use systemd though, because it's backward compatible with older scripts.

Re: Arch Linux to migrate to Systemd

#94

Post by thedeuce » Wed, Aug 15, 2012, 12:33 PM UTC

yew wrote: post #79

caf wrote: post #43

Earlier quoted context omitted.

...except that those things do still need to be re-implemented in every program that requires them, since most POSIXy programs are portable to more than just systems using systemd.

This being my primary problem with the current upheaval in Linux system organization. Its instigators have mostly made it clear that they consider everything not Linux (or possibly preferably not their favorite flavor thereof) to be obsolete - throwing portability out the window. Frankly, it's getting old.

you're getting old.

Re: Arch Linux to migrate to Systemd

#95

Post by rogerbinns » Wed, Aug 15, 2012, 12:50 PM UTC

dredmorbius wrote: post #59

rogerbinns wrote: post #42

Earlier quoted context omitted.

Note that a better way of saying things is that systemd deals with state changes a lot better. Booting is one big state change, but when you have a laptop you go through a heck of a lot of other state changes (suspend, hibernate, resume), docking, connectivity changes (eg wifi coming and going), storage added and removed etc. You may let other people use your system (more state changes). systemd can also ensure that…

You can add state-change management to your system without mucking with really solid, stable, low-level, critical code like init. There's already hotplug support, xinetd, ifupdown's pre/post up/down stanzas, and the like (though networkmanager's screwing that bit up wonderfully). Chroot jails too. I'm not saying that these are perfect (and some are a very pale shadow of perfect indeed), but they're independent of ini…

No one is stopping you from making your own distro that meets your own needs. And servers generally do not have state changes, and it would generally be acceptable to just reboot on any of them.

You may enjoy micro-managing your networking etc - good for you. Some of us don't like doing that. To give one example of stuff that certainly doesn't just work, I was trying to run Squid on my (Ubuntu) laptop and it certainly can't handle state changes well, and neither can Ubuntu's ifup/down and init system. I often ended up having to manually do stuff that the system should have been able to handle well.

I'm personally delighted with systemd's functionality - the way it captures output from services would have saved me hours in the past from services that wouldn't startup cleanly and avoided providing useful information as to why.

(Separately: my kingdom for a simple caching web proxy server)

Re: Arch Linux to migrate to Systemd

#96

Post by CrLf » Wed, Aug 15, 2012, 12:57 PM UTC

I don't really understand the problems these "init" replacements wish to solve. I mean, actual, real-world problems. To me, it's just another instance of the same worrisome trend that brought us NetworkManager and makes everything evolve to integrate with D-Bus: do everything to make desktop-Linux better, even if it negatively impacts the use-cases where Linux is actually successful (everything else).

I don't care much for the desktop, but I do care for servers.

Boot times on servers are irrelevant. Reducing them brings little benefit. Servers shouldn't have to be rebooted that often for it to matter, and also, servers spend most of their boot time POSTing and initializing firmware for the various cards. In many cases, twice as much as it takes to boot a normal SysV init Linux install.

Not only that, but it is much more important to be able to effectively troubleshoot boot problems than to get some dubious features that nobody really felt missing for all these decades.

I don't care if Fedora or Arch do this, but I do care if more server-oriented distributions do. I still haven't gotten over the fact that RHEL6 now gives you the option of using NetworkManager (bleh) or configuring interfaces through (badly designed) configuration files. What's wrong with the old system-config-network?

Re: Arch Linux to migrate to Systemd

#97

Post by ciupicri » Wed, Aug 15, 2012, 1:00 PM UTC

ijobs-ly wrote: post #82

In my biased opinion, once you have gotten over the learning curve, nothing beats daemontools for running services. It is a fantastic set of tools. Why some OS doesn't just embrace djbware I'll never understand. It compiles, smoothly, in seconds. (There's no need for distributing binaries.) And the chances of the author initiating lawsuits (as some Linux foundations are known to do), over something placed in the "pub…

> And the chances of the author initiating lawsuits (as some Linux foundations are known to do), over something placed in the "public domain" are close to nil.

Could you give some examples of those lawsuits?

Re: Arch Linux to migrate to Systemd

#98

Post by planckscnst » Wed, Aug 15, 2012, 1:10 PM UTC

sparkie wrote: post #89

planckscnst wrote: post #37

systemd is so obviously better than anything out there, I'm surprised there is any controversy. I've yet to see a valid complaint. "Poettoering sucks! PulseAudio!" That's not much of a technical argument against systemd, now is it? Pretty much everyone who complains about PulseAudio doesn't even know what it is; they just blame it when their audio doesn't work (usually for some unrelated reason). "It's not determinis…

> I've yet to see a valid complaint. Perhaps this is the main problem - the people pushing technology are not willing to acknowledge that people have different use cases to them. There are complaints, and they are valid - you just do not see them as valid, because they don't concern you. Since you brought PulseAudio up, there's a very legitimate, common complain about it - latency. Yes, the people who care most about…

> Since you brought PulseAudio up

I brought it up primarily as an example of what is NOT relevant to systemd.

> But don't tell that to Poettering - because he is adamant that his solution is the only solution, and anyone who it doesn't suit is just playing with toys.

That's not what he said about PulseAudio. He specifically mentions the need for the other APIs and that the situation sucks. http://youtu.be/9UnEV9SPuw8

> That's literally how he referred to Debain's choice to not push systemd because it targets multiple kernels, which systemd does not work with. (Which btw, Arch does too - although perhaps not the same people.)

The advantages the Linux kernel provide (particularly, cgroups) is such a useful thing it would be stupid not to use it just because it doesn't exist everywhere. So either stick with your current init system, make a similar init system that is compatible with unit files (which are extremely simple), or add the necessary features to the BSD kernel. I'm not seeing a valid complaint here because systemd doesn't affect you unless you want it to.

>Arch was built with a different mentality - the one of personal freedom to do what the hell you want with your desktop, not for the benefit of some company. You are free to use or reject any software you don't want.

> Well, not any more. Pushing systemd on users breaks that mentality - because the choice is stripped from you. The choice is already there in Arch though - and has been for a while. If you want systemd, you can use it. If you don't want it, don't bother. Moving the other way is not really possible though - because if you build your system around systemd, you can't revert back (without taking the time to rewrite everything that depends on systemd.)

There is no "everything that depends on systemd" other than the init process itself. You say this choice is stripped from you, but what you want is to force the Arch developers to maintain init scripts. Take responsibility for it yourself - get together with other people who want those init scripts maintained and maintain them. You won't get things you want by just demanding that the world give it to you.

> The dependency problem in itself is a complaint against systemd. Should udev users be forced to use systemd for example? Normally we would introduce another layer of abstraction to our code - such that we can share common code between systemd-udev and non-systemd-udev, and have a solution where everyone wins - the systemd users benefit from improvements in systemd integration, whilst everyone benefits from improvements to udev which aren't systemd dependent. This is programming 101.

Where are these systemd-dependent parts of udev? They don't exist. There is no need for an abstraction layer to deal with the differences because there are no differences from a user perspective.

>What I am against though, is the politics of it. The constant pushing of systemd down everyone's throat like it's a fucking panacea.

Really, you're more political than anyone I've seen on the pro-systemd side of things.

>One day saying "don't use if if you don't want," and the next blogging "you're fucking idiots for not using it." (Lennart's approach to Ubuntu.)

Are people not allowed to express an opinion?

Re: Arch Linux to migrate to Systemd

#99

Post by peterwwillis » Wed, Aug 15, 2012, 1:10 PM UTC

FooBarWidget wrote: post #16

dredmorbius wrote: post #11

Systemd takes a reliable, known, thoroughly debugged process (init, or various of its tweaks, including Ubuntu's upstart and Debian's insserv ), and converts booting from a deterministic, predictable process to one that's inherently unpredictable . And the stated objective? "To reduce boot times". The best way to reduce boot times is to not boot . The reason I reboot systems is to return them to a known good state (o…

I'm sorry, but shell scripts suck as a language for booting the system. You need to fork() and exec() for almost anything non-trivial, wasting precious CPU cycles in the progress. It looks like every Linux distro has its own way to manage boot scripts. And when they fail, you have no idea what happened. More importantly, init only handles starting and stopping of services. They don't manage services, like restarting…

How long does it take your servers to finish POST? Shaving CPU cycles on boot is not something I ever worry about, because just getting to the boot loader takes minutes.

Also, shell scripts rock for an init system language. It's a language that almost everyone knows and can debug without being a CS major. The only reason you 'have no idea what happened' is because the scripts are written poorly, and code in any language would be hard to debug if it's written poorly.

Fork and exec, seriously? You're worried about functions that take microseconds to finish? Look again - the huge sleep cycles to wait for drivers to finish initializing takes up a lot more time.

I have written my own init systems three times in three languages, and examined countless distros' versions. Trust me, shell is the best compromise.

Re: Arch Linux to migrate to Systemd

#100

Post by alexchamberlain » Wed, Aug 15, 2012, 1:13 PM UTC

CrLf wrote: post #96

I don't really understand the problems these "init" replacements wish to solve. I mean, actual, real-world problems. To me, it's just another instance of the same worrisome trend that brought us NetworkManager and makes everything evolve to integrate with D-Bus: do everything to make desktop-Linux better, even if it negatively impacts the use-cases where Linux is actually successful (everything else). I don't care mu…

I have little experience with servers, but... I must agree with your sentiment. One of the great things about Linux is how simple things are. GUIs are great, but not if I have to start a desktop just to get a network connection!