Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd: The Biggest Myths

0pointer.de

Post reply on HN
Print view View original

101–110 of 118 posts

Re: Systemd: The Biggest Myths

#101

Post by curlypaul924 »

nona wrote: post #66
betterunix wrote: post #54

Earlier quoted context omitted.

The thing is, I am not any better off today than I was when I was using ALSA. None of the problems I had with ALSA were solved by PA; ConsoleKit/PolicyKit came closer to solving those problems, and even then, new problems were introduced. The excruciating transition to PA put a bad taste in everyone's mouth, and now we are all sitting here asking ourselves, "Why did we even bother?" So in a sense, you are right: PA i…

Yep, we are better off now. I remember trying to get bluetooth audio working in the alsa-only days. Or network sound with esd/ssh. Or figuring out how to route audio nicely apps. Or saving my laptop battery. Or many other features that were simply damn difficult to pull off. People don't seem to remember how crappy the audio situation used to be, for users and for ISVs. I respect Lennart and the current PA maintainer…

Pulseaudio plus blueman does solve the bluetooth problem quite nicely. It's the main reason why I use pulseaudio.

In exchange for that I put up with confusing audio dialog boxes, high audio latency, high cpu usage when playing audio, skips and crackles when playing games, arcane commands to enable loopback, and the occasional necessary restart of the pulseaudio daemon when sound stops altogether. I guess that's a reasonable trade.

Re: Systemd: The Biggest Myths

#102

Post by curlypaul924 »

andor wrote: post #99
gnosis wrote: post #61

Earlier quoted context omitted.

"I seriously doubt that many of those actually do anything reasonable with audio." Actually, serious audio work on Linux is done with JACK. PulseAudio is completely inadequate for serious audio work.

You're stating it as if it were a shortcoming of PulseAudio. PA is inadequate for most audio work, because the latency is too high -- which is a feature . Latency vs. CPU usage is always a compromise. To achieve low latency, you need very small buffers for "rendered" audio, and lots of well-timed copy operations to the audio hardware. To just play some audio files efficiently, you want large buffers, because then few…

I don't see how high latency in pulseaudio is a feature. Pulseaudio has both high latency and high cpu usage. I've seen cpu usage by the pulseaudio daemon as high as 20% when playing audio.

Re: Systemd: The Biggest Myths

#103

Post by mverwijs »

__david__ wrote: post #96
mverwijs wrote: post #89

Earlier quoted context omitted.

I don't like the idea of anyone running mission critical services from their homedir.

Why not?

So what is the homedir for? "Home directories for users". See 'man hier'. This to me means it is not a directory for services.

This doesn't answer your question of course. There is still the 'why' of it.

Why has this become the standard?

The homedir is a volatile place. Where users reside often. And make changes often. Any place humans change things is a place where stuff breaks easily and on a regular basis. What if Lennard calls 'rm' with a wrong switch? Or chown? Or chmod? The service receives pain.

Or he could decide that he no longer wants his homedir to be readable/executable by everyone on the system, so he chmod 0700 his homedir. Forgetting that this will render his trac instance unavailable.

Or what about sharing some responsibility? How is Lennard ever going to share the maintenance of the ticketing system with anyone else? What impact will that have on the ticketing system? Will it have to be migrated anyway to /srv or /usr/local or /opt? What configs will that affect? What about the webserver configs? What about file permissions, uids, gids?

What about backups? Are they configured for this specific service? If it is ever migrated to another location, do they have to be reconfigured? Or will /home/lennard just be backed up as before and no one will remember that trac is now in /srv/trac, making a restore improbable.

What about a reboot? Will the service come back up? What if you have to re-implement this service on another machine after this one explodes? Are you sure you did not forget to point /etc/rc.local (or some other hack) to your new machine?

These are only the reasons I could think of off the top of my head. And most of these are actual examples from the field.

A standard is a standard, because it works for more people than just you. The question you, and lennard, should be asking yourself is: How can these standards work for me as well?

(As you can probably tell, I grew up in Ops, not Dev. I have seen the pain of the 'works-for-me'-mentality.)

Also, cnvogel is obviously more consise than me. :-)

Re: Systemd: The Biggest Myths

#104

Post by bkor »

thaumaturgy wrote: post #64
jmj42 wrote: post #58

Earlier quoted context omitted.

Very true, and, to be honest, I'm not advocating for systemd. Though according to the original article this isn't quite the issue that it's claimed to be (I'm not actually familiar enough with systemd to be able to have an opinion on it), see point 20. My assessment on the systemd debate, though, is that it feels a bit like neophobia and the technical justifications (against systemd) are a bit on the weak side.

You're right, it is mostly neophobia. I sort of tried to say that in my top comment; I don't think that systemd is technically inferior, I just can't yet justify switching to it. But, I've been meaning to write about this for a while: I think neophobia is starting to become an unnecessarily religious article of faith in the technical community. I run a small consulting shop, we support (or try to support) just about…

Systemd is actually way better at logging why a service did not start. With sysvinit I often had to figure out the exact command the shell script would start the daemon with to see the stderr output. Systemd just logs this by itself and you can see this output in e.g. systemctl. This saves loads of time.

Re: Systemd: The Biggest Myths

#105

Post by bkor »

glogla wrote: post #70
mfjordvald wrote: post #44

Earlier 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.

systemd tracks service status way more reliably than sysvinit. It also stops services more reliably. This due to the usage of cgroups.

Re: Systemd: The Biggest Myths

#106

Post by bkor »

jpollock wrote: post #77
jmj42 wrote: post #56

Earlier quoted context omitted.

> 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 (ma…

This usually depends on how business critical it is. If some service is not very business critical, then how do you justify (or get budget for) the extra resources you need to make it way more reliable?

But even when not business critical, it is nice that you can bring it up quickly.

Re: Systemd: The Biggest Myths

#107

Post by koide »

fosap wrote: post #100
koide wrote: post #81

Earlier quoted context omitted.

Can you chime in and inform us where is Lennart wrong and how? I (and probably many others) would LOVE that.

I'm not going to watch this cringeworthy thing again, but i can remember than he insisted that dbus was useful and that we need a gnome session in our login manager. That would be enough to proof the point.

And the point is that the arguments he made about why dbus is useful (a lightweight IPC mechanism with use cases not covered by UNIX sockets or TCP sockets, doing much more) and why do we need a gnome session on the gdm (to get i18n, network and accessibility features you need most if not all of the session) are well reasoned and make sense to us out of the loop.

Could you provide the counterarguments?

Re: Systemd: The Biggest Myths

#108

Post by fosap »

koide wrote: post #107
fosap wrote: post #100

Earlier quoted context omitted.

I'm not going to watch this cringeworthy thing again, but i can remember than he insisted that dbus was useful and that we need a gnome session in our login manager. That would be enough to proof the point.

And the point is that the arguments he made about why dbus is useful (a lightweight IPC mechanism with use cases not covered by UNIX sockets or TCP sockets, doing much more) and why do we need a gnome session on the gdm (to get i18n, network and accessibility features you need most if not all of the session) are well reasoned and make sense to us out of the loop. Could you provide the counterarguments?

Yes. dbus effectively breaks network transparency of x11 apps and turns Linux into a Desktop-Single-User OS. While I'm not regually writing desktop applications i have never ever missed dbus. And ipc mechanisms have a tendency to become unpleasant (Corba, SOAP).

I don't have a gnome session in my login manager because I don't need i18n for the words "login" and "password". (although that would be totally possible without a whole gnome session). I don't have a braille line so i can't say anything about accessibility, but that should be (in a ideal unix world) a single printf to /dev/braille. Also the feedback is audible and visual, this seems to be no issue to me.

Re: Systemd: The Biggest Myths

#109

Post by bkor »

delinka wrote: post #71

6. Myth: systemd is not modular. Not true at all. At compile time you have a number of ... So it's only modular at compile time. This seems like a negative to me.

You can also disable various things during runtime. A->B does not imply B->A.

Re: Systemd: The Biggest Myths

#110

Post by bkor »

Niten wrote: post #95

This article from last August hits the nail on the head with regard to systemd: http://www.pappp.net/?p=969 "I’m not sure that this is a bad design, but it is most definitely not UNIX or anything like it."

The blogpost already addresses everything that above article gets wrong.
Post reply on HN