6. Myth: systemd is not modular.
Not true at all. At compile time you have a number of ...
Systemd: The Biggest Myths
71–80 of 118 posts
Re: Systemd: The Biggest Myths
#72Benefits to me as a desktop and laptop user of systemd. 1) Speed does matter. Fast boots are good. 2) The new journal is just better. Finding something in the logs is easier. 3) Service files are easier to write than init scripts and one can have more confidence they will work as intended as you need write very little configuration oneself. 4) Knowledge of dependencies means I never have to worry about starting dbus…
>I remember the same complaints with PulseAudio.
And this is perfectly the reason number two why i won't switch to systemd (reason number one is there is no need for it). PulseAudio does not work. It sucks. The irc channel is full of clueless (but trying to be helpfull) people. And nobody cares. I want my Alsa back. But now it's too late, i hope systemd will either be better (doubt it) or never be this popular.
And, I cannot lie, I don't want it because I don't want another dbus. freedesktop, stop turning my linux into a single user os. Next thing is they want to abolish x11. Sure it's about time for x12, but wayland? I just don't understand the community that surrounds Linux anymore.
Re: Systemd: The Biggest Myths
#73Earlier quoted context omitted.
> 3. Easy to check which daemons are running and not. How? This is one of the things that have really annoyed me as all the systemd services have gone from service --status-all.
htop? I'm not linux admin anymore, but I when I was, I used various service status software thingies only to find out whether the system thinks the service is running, because they tend to be wrong, and just annoy you (not starting crashed server because it "is already running" or something similar). I think debian doesn't even track service states, but I'm not sure. Of course, with systemd it will be even more fun.
+1 for htop. It's actually really useful and intuitive.
Re: Systemd: The Biggest Myths
#74Earlier quoted context omitted.
To me systemd looks mainly useful for servers. Some of the nice server features: 1. It is way easier to write a systemd unit for an in house application than it is to write a correct sysvinit script. 2. Everything runs in a cgroup making it easier to add resource limits and see which process is started by which service. 3. Easy to check which daemons are running and not. 4. Reduced startup time for containers.
I disagree. 1. Not really. Most sysadmins have a decent template init file sitting around or you just steal another one on the machine and modify it. They are also more flexible as some startup processes aren't quite as simple as systemd thinks (consider lockfiles, temp data purging, permissions etc). 2. ulimit / selinux - per process. cgroup whilst funky looking is YET ANOTHER disposable mechanism which will no doub…
1. I personally do not like copy pasting templates. Especially when it turns out there was a bug in the copy pasted template. So maybe this is just a question of personal preferences.
2. cgroups can do way more things than ulimit.
3. True
4. Have not used enoug containers to know how much it matters in practice.
Re: Systemd: The Biggest Myths
#75Earlier quoted context omitted.
One reason is that pulseaudio broke audio for many Linux users (including me). Linux audio has long been problematic but had reached a point of stability when pulseaudio was adopted by some of the major distributions. I have no idea if the problem was that pulseaudio was broken, with distributors messing up, or with Linux audio drivers. When a problem is easily solved by just an "apt-get remove X" it is easy to start…
The thing is that this is a really dated opinion. While I realise that it was really painful for those months, the end result is that audio on Linux seems to work a hell of a lot better these days. By making Linux audio temporarily problematic Linux audio became a solved problem (at least in my mind, and the minds of many users of the major distributions that use it)
It does not seem that dated to me. Last time pulseaudio broke the sound at my computer was in two weeks ago on Debian Squeeze. Could have been a Debian fuckup, could be my hardware but whatever it was it was fixed with sudo apt-get remove pulseaudio.
I realize that is all anecdotal and I could be one of the few people in the world who still have problems with it.
Re: Systemd: The Biggest Myths
#76Most "arguments" I read are are either ad-hominem or ad-pulseaudionem attacks.
I don't see a single ad-hominem.
And ad-pulseaudionem is just like a ad-networkmanagerem or a ad-dbusiem: If your software design sucks and it does not work good enough that you don't have to care about this you will be told it sucks. And to me it seems that systemd is written in the spirit of dbus and nm.
Re: Systemd: The Biggest Myths
#77Earlier quoted context omitted.
Sure, but given that developer time is a bounded resource, we can't really expect to get both fewer restarts and faster restarts. I sympathize with your example, but I would expect that you had already seriously optimized your startup process, and since systemd doesn't make services start more quickly (it only does a better job of parallelizing them), I doubt that it would have made a huge difference in your case. As…
> but given that developer time is a bounded resource, we can't really expect to get both fewer restarts and faster restarts. Your're going to have to clarify, as this statement doesn't make any sense. You're right though. In this instance, system startup was already highly optimized. In fact, the order of startup was shifted around to get Oracle (the DB in this example) up and operational as early as possible. On th…
I've always architected systems such that restart time didn't matter - the systems were able to fail over. However, in flight operations would fail, which meant that a restart would, in fact, cost >$50k - regardless of the length of time it took for that machine to come back.
Faster restart time is irrelevant to me. I'm already designed to deal with outages. Reducing the impact of a restart is extremely important (making them fewer in number, smaller in scope).
Re: Systemd: The Biggest Myths
#78Earlier quoted context omitted.
The thing is that this is a really dated opinion. While I realise that it was really painful for those months, the end result is that audio on Linux seems to work a hell of a lot better these days. By making Linux audio temporarily problematic Linux audio became a solved problem (at least in my mind, and the minds of many users of the major distributions that use it)
It does not seem that dated to me. Last time pulseaudio broke the sound at my computer was in two weeks ago on Debian Squeeze. Could have been a Debian fuckup, could be my hardware but whatever it was it was fixed with sudo apt-get remove pulseaudio. I realize that is all anecdotal and I could be one of the few people in the world who still have problems with it.
Well, all software has problems. I just doubt that if problems were as prevalent as the vocal minority make out that PA would remain in the major distributions.
Re: Systemd: The Biggest Myths
#793. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly. 5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also repla…
> "The problem for BSDs isn't so much that systemd is or isn't portable to them; it's that some upstream software is beginning to require systemd"
See, to me this is just a "shit barometer". If upstream software requires systemd, then almost without fail it is shit and, at least outside the linux ecosystem, I am better off not using it.
Re: Systemd: The Biggest Myths
#803. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly. 5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also repla…
Regarding your last point, the main thing that systemd excels at is managing the mishmash of power events, other ACPI events, service management and integration with DBus (which everything seems to require these days). However, I run Linux in three locations and here's where systemd fits for me: 1. Servers. No use whatsoever. There are two power states: off and on. None of this is really an improvement over SVR4 init…
Learning new tools is bad?!