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

Systemd redux: The end of Linux

blog.lusis.org

Post reply on HN
Print view View original

421–430 of 464 posts

Re: Systemd redux: The end of Linux

#421

Post by [deleted] »

sethrin wrote: post #277
return0 wrote: post #237

As a rule of thumb, it's good to distrust products when you know that the politics behind have been loud enough to be heard widely. But the sharp razor which will decide if systemd is better is simplicity. Those who have switched, is systemd simpler than sysvInit?

Simplicity is not necessarily a good measure of suitability. See this: http://mjg59.dreamwidth.org/2414.html There are some aspects of systemd that are simpler than sysvinit. The mess of double-forking and PID files goes away, and process management is much more reliable. Setting up containers for services is much simpler. Unit files are generally much simpler than a given init script. I think more useful adages ("bo…

[deleted]

Re: Systemd redux: The end of Linux

#422

Post by thwarted »

icebraining wrote: post #154
nitrogen wrote: post #127

Earlier quoted context omitted.

I also don't believe any sysv implementation had crash recovery or socket activation of daemons, both of which are huge feature wins. That's because there were other components handling those tasks, like inetd and /etc/inittab. I do like having Upstart handle respawning for me, though.

Inetd only did TCP socket activation, not of unix sockets, though.

Inetd only did TCP socket activation, not of unix sockets, though.

False.

http://manpages.ubuntu.com/manpages/hardy/man8/inetd.8.html

    The service name entry is the name of a valid service in the file
    /etc/services. … For UNIX domain sockets this field specifies the
    path name of the socket.


    The protocol must be a valid protocol as given in /etc/protocols.
    Examples might be “unix”, “tcp” or “udp”. … A protocol of “unix”
    is used to specify a socket in the UNIX domain.
xinetd does not appear to support this feature.

Re: Systemd redux: The end of Linux

#423

Post by dredmorbius »

seivadmas wrote: post #244
badgersandjam wrote: post #95

Earlier quoted context omitted.

I had no opinion on systemd until yesterday. In fact I had a glace or two at the code and it's pretty clean and I liked the rough objectives laid out. I installed CentOS 7 on a machine last night that we're replacing CentOS 6 on and was poked in the face with timedatectl and dbus problems for an entire hour, some of which were intermittent. Debugging these issues is a horrific pain. I lost 4 hours on it. I've never l…

You know this is funny, I remember reading comments EXACTLY like this about 3-4 years ago but with pulseaudio in place of systemd. Pulseaudio was Lennart's previous project. It broke everything in linux sound for a while, everybody moaned and hated it and said it was the worst thing since the crucifixion of Christ. Yet, name one problem you had with sound on linux in the past year? There are very few. Pulseaudio now…

Great example except ... I don't have pulseaudio installed on my system. Not even out of any specific effort to avoid it.

It may be standard on some systems, but not, apparently on debian (it's an "optional" package).

And that's part of the point: stuff that needn't be present shouldn't be. systemd's a whole 'nother ball of wax in that regard.

And yes, I'll even allow that Linux audio has been frustrating over the years. But in my case, problems going away had nothing to do with Lennart's work.

Re: Systemd redux: The end of Linux

#424

Post by icebraining »

thwarted wrote: post #422
icebraining wrote: post #154

Earlier quoted context omitted.

Inetd only did TCP socket activation, not of unix sockets, though.

Inetd only did TCP socket activation, not of unix sockets, though. False. http://manpages.ubuntu.com/manpages/hardy/man8/inetd.8.html The service name entry is the name of a valid service in the file /etc/services. … For UNIX domain sockets this field specifies the path name of the socket. The protocol must be a valid protocol as given in /etc/protocols. Examples might be “unix”, “tcp” or “udp”. … A protocol of “unix…

Oops, you're right, I misread an article about socket activation.

Re: Systemd redux: The end of Linux

#425

Post by digi_owl »

simoncion wrote: post #400
digi_owl wrote: post #111

Earlier quoted context omitted.

I find myself reminded of a poster at a school toilet: "your mother does not work here, clean up after yourself".

I'm afraid that I have no idea what you're trying to say. Would you elaborate?

Gnome apparently assumes someone else is supposed to clean up after them, and so leave processes behind.

In essence, systemd has becomes Gnome's mother...

Re: Systemd redux: The end of Linux

#426

Post by the_why_of_y »

byuu wrote: post #394
the_why_of_y wrote: post #386

Earlier quoted context omitted.

To clarify, "/dev/pcm virtualization" means FreeBSD does audio mixing and re-sampling in kernel space.

That is correct. Let's look at the simplest form of sound mixing: /* A */ sample = (sample_a >> 1) + (sample_b >> 1); //lowers volume of A and B by 50% /* B */ sample = max(-32768, min(+32767, sample_a + sample_b)); //prone to clamping Obviously, the algorithms will become fancier (to mix better, to support multiple bit depths and frequency rates, to avoid popping if one stream runs out of samples, etc), but it's sti…

Sorry, it was not my intent to "play this up as a bogeyman", and don't know enough about audio to have an opinion on this design decision anyway. (Do audio devices support floating point formats nowadays?)

I just find it amusing how a monolithic design of doing all audio stuff in the kernel is held up by some as an example of reliability and as superior to a more modular design that is more in line with the UNIX philosophy.

About the KMS however, I've heard that DisplayPort link training has latency requirements that are difficult to meet in anything but a kernel interrupt handler... a quick duckduckgo search finds a short note about that on: http://fedoraproject.org/wiki/Features/RadeonDisplayPort

Also X servers have traditionally needed direct PCI bus access to get the hardware initialized, which means that a buggy X server can hang your PCI bus so the driver running in user space likely doesn't increase reliability in practice.

It's an interesting question to what extent the limited success of microkernel based UNIX implementations is to historical accidents and network effects, and to what extent due to actual technical limitations and additional complexity of a microkernel architecture.

Re: Systemd redux: The end of Linux

#427

Post by the_why_of_y »

pdkl95 wrote: post #196
rythie wrote: post #166

Earlier quoted context omitted.

You can't realistically submit a patch to change the direction that Systemd's is going in. For example, they won't accept a patch which removes 95% of the code, so a more modular system can be built. Submitting a patch, implies you agree with the general direction but need a bug fixed or a feature added.

Not only would submitting a patch be agreeing to their goals (Lennart gets to push the Overton window a bit further), suggesting that we should simply submit patches presupposes that the systemd cabal would ever accept them. Unless it is perfectly in agreement with their goals - including the complete software - they probably won't accept it. They don't even accept already written and tested patches for trivial thing…

For better or worse, systemd has adopted the OpenBSD approach to portability. Nothing is stopping you from creating a systemd-portable project, similar to how OpenSSH-portable makes OpenSSH usable on non-OpenBSD platforms.

As to logind, it may have been a better choice for the long term to do a separate implementation of the public and stable logind DBus API instead of trying to run the systemd-logind implementation without systemd as PID1, but supposedly whoever did the latter thought it was the best short-term choice.

Re: Systemd redux: The end of Linux

#428

Post by byuu »

the_why_of_y wrote: post #426
byuu wrote: post #394

Earlier quoted context omitted.

That is correct. Let's look at the simplest form of sound mixing: /* A */ sample = (sample_a >> 1) + (sample_b >> 1); //lowers volume of A and B by 50% /* B */ sample = max(-32768, min(+32767, sample_a + sample_b)); //prone to clamping Obviously, the algorithms will become fancier (to mix better, to support multiple bit depths and frequency rates, to avoid popping if one stream runs out of samples, etc), but it's sti…

Sorry, it was not my intent to "play this up as a bogeyman", and don't know enough about audio to have an opinion on this design decision anyway. (Do audio devices support floating point formats nowadays?) I just find it amusing how a monolithic design of doing all audio stuff in the kernel is held up by some as an example of reliability and as superior to a more modular design that is more in line with the UNIX phil…

> Sorry, it was not my intent to "play this up as a bogeyman"

Okay, my apologies as well then. It was hard to get a read from just that one sentence with the word kernel emphasized.

> (Do audio devices support floating point formats nowadays?)

Natively, no. You can be lazy and do it anyway in software mixing though.

> I just find it amusing how a monolithic design of doing all audio stuff in the kernel is held up by some as an example of reliability and as superior to a more modular design that is more in line with the UNIX philosophy.

Certainly, it would be ideal if everything non-critical were in user space. But audio in the kernel is probably at the very bottom of the list. Audio mixing is maybe 0.0001% of the kernel code, and is some of the safest, simplest arithmetic code imaginable. It's worrying about the one ant you saw on the counter when your entire house is infested with termites.

> About the KMS however, I've heard that DisplayPort link training has latency requirements that are difficult to meet in anything but a kernel interrupt handler

I don't know if that's true or not, but I am running a DisplayPort monitor (ZR30w) now without KMS, and it works fine. Obviously the video driver is still running in kernel mode, but at least it's a module outside of the kernel itself that runs after my system is booted.

What I'd really like to see is distros and vendors instead relying on UEFI GOP for boot-time mode setting.

> Also X servers have traditionally needed direct PCI bus access to get the hardware initialized

Well, compare it to audio. Eventually even a userland mixer will have to send the samples through some sort of hardware interface. But if your goal is stability, then it would be ideal to get as much code out of the kernel as possible.

> and to what extent due to actual technical limitations and additional complexity of a microkernel architecture.

Certainly nothing is ever perfect. There are so many potential problems with computers. Cosmic rays can flip bits in your RAM if you don't shell out an extra $500 for the premium CPU, mainboard and ECC RAM. Strong enough power surges (lightning) can burn through and destroy absolutely any running computing equipment. Hardware can literally fail and take down your system. Things can overheat, there can be design flaws in the silicon itself, etc.

So I look at it like OpenBSD looks at security. You want to stack all the protections you can. Mirror your drives, use ECC RAM, don't run anything in kernel space you don't have to, try and build as much redundancy and safety as you can into the system. It won't be perfect, but every bit will help increase uptime.

...

So again, sure, audio should preferably be in user space. Just, it's many thousands of times worse that video isn't even trying to do this, and is in fact going in the opposite direction to become more tightly coupled with the kernel.

Re: Systemd redux: The end of Linux

#429

Post by the_why_of_y »

erglkjahlkh wrote: post #259
pjc50 wrote: post #171

Earlier quoted context omitted.

Or stop using Linux entirely and move to FreeBSD.

Unfortunately FreeBSD doesn't have very good MAC system. Capsicum and friends implement only ~10% of what SELinux offers. Also the virtualization is far more basic, and lacks tooling (it's like receiving a huge bag of Legos and instructions on how to build space shuttle).

IMHO Capsicum has significant potential to provide similar real-word security improvements in a far simpler way than SELinux (once the relevant profiling of daemons is done); there was some work by somebody at Google to port it to Linux and I hope that will be usable sometime soon.

Re: Systemd redux: The end of Linux

#430

Post by the_why_of_y »

bashinator wrote: post #406
byuu wrote: post #362

Earlier quoted context omitted.

And if Linux weren't available, Lennart would most likely be working on systemd for BSD. Whether or not he would be successful in getting it adopted there is unknowable, but it would be possible. This is why choice is good, and lock-in is so bad.

I don't think it would get adopted in its current form. Systemd is a massive violation of the Principle of Least Astonishment[0]. [0] http://www.unixguide.net/freebsd/faq/16.17.shtml

To avoid violating this principle, the commonly accepted industry best practice to never change anything at all.
Post reply on HN