Live data from Hacker News

Systemd redux: The end of Linux

blog.lusis.org

371–380 of 464 posts

Re: Systemd redux: The end of Linux

#371
post #355

Earlier quoted context omitted.

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…

> Yet, name one problem you had with sound on linux in the past year? That's just it. Linux sound worked fine for me before Pulseaudio, and FreeBSD sound has always worked perfectly fine for me. In fact, FreeBSD solved sound mixing sooner via /dev/pcm virtualization (while Linux chose to create the Linux-only ALSA instead), and has always had lower observed latency. Pulseaudio screwed up my audio so badly that for a…

WAIT you NEVER had an audio problem in Linux before PulseAudio? I would have said the weakest link in Linux on desktop WAS audio.

Now PulseAudio was released into the wild too soon by too many distros BUT it has fundamentally fixed what was HORRIBLE in Linux. (Previously a Sound Engineer and Record Studio owner)

BUT I would say that Systemd is extremely stable and not broken. What people are complaining about is the philosophy aspect.

Re: Systemd redux: The end of Linux

#372

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…

I still haven't tried pulseaudio; my first interaction with it was so terrible.

Re: Systemd redux: The end of Linux

#373

Earlier quoted context omitted.

I may be wrong, but I took GP to mean that FreeBSD is a good enough OS to use daily, hence Torvalds wouldn't have had a need to create Linux. Obviously, Torvalds hasn't abandoned Linux in favor of FreeBSD today, and no one said he has or is planning on it.

> I may be wrong, but I took GP to mean that FreeBSD is a good enough OS to use daily, But that's not at all what Torvalds's quote means. He meant that, if FreeBSD had been available, he would have worked on contributing to that instead and improving it for daily use, rather than building Linux to be used for daily use. (The state of FreeBSD in this hypothetical world has no bearing on the state of FreeBSD today). In…

The thing is though, back then in the early 90s FreeBSD could have been good enough; most x86 computers didn't have a GUI at all, and if they did it was OS/2 or Windows over DOS. Hardware was arguably much simpler too. Linux was created as a response to Minix, not BSD[1], and Minix was just a "teaching" OS, not a daily driving workstation OS. He didn't initally build Linux for "daily use", but as a hobby project, per his own words.

[1] https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RR...

Re: Systemd redux: The end of Linux

#374

Earlier quoted context omitted.

I don't think they would complain if things became easier. All I hear about is problems with systemd, and having to solve problems (and learn how systemd and all its components interact so you can debug it) is not easier.

Yeahz they all spend like 20 mins and come out crying without spending at least a week understanding it. Which software stack do you know that you instantly get in 20 mins. I for one cannot understand the sysvinit or upstart in 20 mins (ie) to develop and debug. How do you debug sysvinit anyway? Echo's I place in the code do not appear on the screen. Can i claim 'Oh shit this is so broken...'?

You can start the daemon manually to check why it fails, or check logs, or put echo in the code like you say, or run the script with -x, there are many possibilities. sysvinit is quite easy to get, because you just apply what you already know (running shell scripts, running shell scripts with -x, read (log) files, etc.) and there isn't a layer in front of you that you don't know how to debug or trace.

And yes LSB init scripts are broken under systemd, exactly because of what you describe (placing echo doesn't show) because it redirects the execution through systemd, and stores the output in journald. Try writing (or debugging) an init script on a non-systemd system and see how much easier it is.

systemd also tries to act "smart" and remember the last state a service was in which makes developing LSB init scripts on a systemd system ... complicated. If an init scripts exits with success (perhaps because the deamon wasn't configured yet) then systemd will remember that and the next time you issue a 'start' it'll be a noop, and claim it was successful. Which leads to countless hours wasted until you figure out what really happened: systemd never even run your script again. So then you run 'restart' on the init script and all is well again.

Re: Systemd redux: The end of Linux

#375
post #163

Earlier quoted context omitted.

systemd makes a lot of sense for embedded systems: * Embedded systems use watchdogs. systemd implements a watchdog supervisor chain, where systemd supervises applications, and the hardware watchdog supervises systemd. * kdbus: efficient IPC * networkd: simple network setup, very fast DHCP client * fast boot times * handles many complexities, so that embedded developers can focus on their application

That all sounds fantastic, but what do you do if just one component of systemd doesn't work for you? Or if you only want to use one or two components of systemd?

Regarding the first question: Then you use something else instead of that component. For instance, the existence of networkd does not preclude the use of (say) dhcpcd or your own network setup scripts. Of course, there are a few components that are more central (e.g. journald, udevd). In that case you file a bug report and/or fix it. Same as when one component of the kernel (which is vastly larger than systemd) doesn't work for you.

As for the second question: certain parts of systemd can certainly be used on non-systemd systemd (such as udev or nss-myhostname). But most would require at least some changes.

Re: Systemd redux: The end of Linux

#376

Earlier quoted context omitted.

> I may be wrong, but I took GP to mean that FreeBSD is a good enough OS to use daily, But that's not at all what Torvalds's quote means. He meant that, if FreeBSD had been available, he would have worked on contributing to that instead and improving it for daily use, rather than building Linux to be used for daily use. (The state of FreeBSD in this hypothetical world has no bearing on the state of FreeBSD today). In…

>In terms of FreeBSD today, while it's possible to use it for daily use, it suffers from even worse driver issues than Linux does No it does not. It has fewer driver issues by far. Because it does not have broken half-assed binary only drivers by obscure vendor X that don't actually work. Unsupported hardware is simply unsupported, rather than broken.

> Because it does not have broken half-assed binary only drivers by obscure vendor X that don't actually work.

I've always found it interesting that Nvidia offers a more complete and stable BSD driver than its GNU/Linux counterpart. That said, AMD/ATI support is abysmal, and even Intel video is lacking compared to GNU/Linux.

> Unsupported hardware is simply unsupported, rather than broken.

That's a matter of interpretation. If FreeBSD doesn't support my hardware, it's the equivalent of being broken for me, given that I can't use it anyway. That said, I try to build or buy the most OS-agnostic workstations possible so my options are always open.

Re: Systemd redux: The end of Linux

#377
post #219

Earlier quoted context omitted.

Just look at this very thread - there are numerous posts trashing the "old ways" of UNIX. It has been a common thread throughout the systemd mess. Lennart himself is very strongly outspoken against any use of shell scripting (not just in init).

Sigh. Obligatory reference to http://0pointer.de/blog/projects/the-biggest-myths.html : "Myth: systemd is incompatible with shell scripts. This is entirely bogus. We just don't use them for the boot process, because we believe they aren't the best tool for that specific purpose, but that doesn't mean systemd was incompatible with them. You can easily run shell scripts as systemd services, heck, you can run scripts wr…

Note that your quote doesn't contradict pdkl95's statement. Nowhere did they say that systemd prevents you from starting shell scripts, but that the developers have a (strong?) revulsion towards them.

Re: Systemd redux: The end of Linux

#378
post #249

I have mixed feelings about systemd: like many others, I've spent a lot of time with traditional Unix systems (25 years) and like the simplicity and stability commonly associated with them and familiar tools/conventions. On the other hand, OS X showed what a modern system built on Unix should feel and look like, while Linux never got anywhere near (not only on the GUI layer). If it takes unreasonable people to make p…

On the other hand, OS X showed what a modern system built on Unix should feel and look like, while Linux never got anywhere near (not only on the GUI layer). This feels like a non-sequitur. The nice GUI of Mac OS X has nothing to do with launchd (which is the systemd-like portion of Mac OS X).

Are you kidding me? Launchd helps coordinate a massive selection of on-demand GUI-related services and their prerequisites. (254 services on my Mavericks install as of writing)

SysV init is ill-suited to that sort of complex event-oriented management, which (for example) is exactly why Canonical developed Upstart in the first place.

Re: Systemd redux: The end of Linux

#379

Earlier quoted context omitted.

it was tested enough to ship in redhat enterprise linux 7.

Upstart was tested enough to ship in RHEL6. It does not mean it works perfectly and has no bugs. But systemd IS NOT only an init system. So if systemd 208 (until 213) by default saves the core files in the journal and your core file is bigger that what systemd devs decided was appropriate in a .c file (around 768MB, IIRC), you lose it. That is _inacceptable_. And while we (=the company i work for) still have not offi…

> So if systemd 208 (until 213) by default saves the core files in the journal and your core file is bigger that what systemd devs decided was appropriate in a .c file (around 768MB, IIRC), you lose it. That is _inacceptable_.

Is that not, however, a simple fix? There might be a case of death by million cuts but that's true of any new software that replaces any existing software.

Re: Systemd redux: The end of Linux

#380

Earlier quoted context omitted.

Thank you for doing this. That being said, it's a little too esoteric for my tastes (among other things: "if you are looking for a stable production system that respects your freedom as a computer user, a good solution at this point is to consider one of more established GNU/Linux distributions."). Do you know of any Linux distros that a) don't use systemd, b) are vaguely active / supported, and c) run on UEFI? (My c…

>it's a little too esoteric for my tastes Yes, we're still in alpha. Not ready for prime time yet. >Do you know of any Linux distros that a) don't use systemd, b) are vaguely active / supported, and c) run on UEFI? Gentoo? I use Debian most of the time, which of course uses systemd now.

> Gentoo doesn't officially support UEFI
Post reply on HN