Systemd redux: The end of Linux • Hacker News Board

Re: Systemd redux: The end of Linux

#251

Post by badgersandjam » Fri, Nov 21, 2014, 2:15 PM UTC

watt wrote: post #245

badgersandjam wrote: post #121

Earlier quoted context omitted.

Absolutely no idea. It just went away spontaneously which is even more worrying as that suggests the system is non-deterministic. I don't have the error on my phone which I'm on at the moment but it threw a dbus error with no debug info.

It must be a hardware problem on your side, dude. Simple as that. I imagine 10 years ago you would be the person complaining that GCC segfaults randomly during compiling Linux kernel, complaining that it's not "tested completely". While the segfault was caused by CPU overheating (not cooled properly) and flaky memory (causing bits to flip).

Known good HP DL380 G8 pulled from production, ECC RAM, monitoring, SAS disks, full hardware test and memtest86 pass.

Nope. Not that.

We don't buy crappy hardware or not test it.

Re: Systemd redux: The end of Linux

#252

Post by aidanhs » Fri, Nov 21, 2014, 2:18 PM UTC

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…

Let's say PulseAudio is really good now (I can't disagree). It was initially released 10 years ago. So 6-7 years after initial release ("3-4 years ago") it was causing people grief.

I'm not sure that's a great vote of confidence for the road ahead of systemd (given that systemd presumably has a bit more to it than PulseAudio). To quote the article, "I do honestly believe this will end up being the start of a rocky period for Linux".

Ubuntu 14.04 will keep me happy for ~5 years, then I can take another look at what the current state of things are.

Re: Systemd redux: The end of Linux

#253

Post by davexunit » Fri, Nov 21, 2014, 2:19 PM UTC

TheLoneWolfling wrote: post #243

davexunit wrote: post #19

I'm quite happy to be a part of the development team for GNU Guix, a distro that is not using systemd. I'm not a systemd hater, but it's definitely not for me and I'm not thrilled with the direction that development is going. It's a shame that sysvinit and friends are so bad that using systemd is the best option we have right now. Maybe GNU dmd will be able to stand up to it someday.

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.

Re: Systemd redux: The end of Linux

#254

Post by badgersandjam » Fri, Nov 21, 2014, 2:32 PM UTC

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…

You're entirely right and I've upvoted you.

However, with one small caveat: servers don't generally have sound cards so the impact of this was relatively low. There aren't that many desktop Linux users out there. I mean I'm a Unix guy at heart and I'm typing this on a Windows laptop. I've never used Linux on the desktop and probably never will.

Now servers do have init processes and we don't really want to spend the next 3-4 years being guinea pigs. I'm quite happy for the vendors to do this behind the scenes or offer it as an alternative but we've got an RHEL+CentOS release with systemd in it already and a Debian with systemd in it just around the corner. A pulseaudio situation, even for 6 months, will result in no small amount of chaos.

I do indeed remember times before even ALSA when you had to pay OSS for drivers for your turtle beach card etc. But that's in the distant past, not right now and of little relevance. Windows was fine on the desktop then as well and the sound worked fine out of the box.

Re: Systemd redux: The end of Linux

#255

Post by andreasvc » Fri, Nov 21, 2014, 2:33 PM UTC

vidarh wrote: post #198

pdkl95 wrote: post #196

Earlier quoted context omitted.

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…

His response seems perfectly reasonable to me - even more so after reading that whole exchange. Why should the Systemd team pay the overhead - in terms of complicating their code - to work around incompatibilities in another libc that will also affect portability of a lot of other Linux software?

It's a matter of perspective. You could also say that glibc is adding incompatibilities by deviating from standards, and now systemd depends on them. I don't consider it "perfectly reasonable" that Gnome, systemd and the Linux kernel are now starting to depend on each other when previously all of these components could be exchanged for others. It's a mischaracterization to say that the systemd "shouldn't have to pay the overhead" of making their code compatible, because they started out with introducing an architecture that promotes this very lock-in to begin with.

Re: Systemd redux: The end of Linux

#256

Post by jerven » Fri, Nov 21, 2014, 2:35 PM UTC

e40 wrote: post #227

olau wrote: post #159

Earlier quoted context omitted.

Are you really extrapolating from ONE data point? In some sense systemd is more stable in that it's fixing some longstanding bugs with sysvinit, but of course it will have some bugs of it own. If you don't want to deal with that, you could skip a release.

it's fixing some longstanding bugs with sysvinit Honest question: I've been using sysvinit for a very long time and I have no concept of what those bugs might be.

Simple one PID files.

Assume server with lots of processes.

Service A starts writes PID to disk, lets say 123. lots of processes start and stop as it goes along and does its work. Service A crashes/stops working PID 123 gets reused by a new process SysAdmin comes and hits /etc/init.d/ServiceA restart shell script calls kill 123 which was a totally different process now not at all related to ServiceA.

etc...

Clean unmounting not depending on timeouts to be high enough.

etc...

Not starting a database before the filesystem with the database files is mounted.

etc...

Re: Systemd redux: The end of Linux

#257

Post by bkeroack » Fri, Nov 21, 2014, 2:42 PM UTC

jerven wrote: post #256

e40 wrote: post #227

Earlier quoted context omitted.

it's fixing some longstanding bugs with sysvinit Honest question: I've been using sysvinit for a very long time and I have no concept of what those bugs might be.

Simple one PID files. Assume server with lots of processes. Service A starts writes PID to disk, lets say 123. lots of processes start and stop as it goes along and does its work. Service A crashes/stops working PID 123 gets reused by a new process SysAdmin comes and hits /etc/init.d/ServiceA restart shell script calls kill 123 which was a totally different process now not at all related to ServiceA. etc... Clean unm…

> Not starting a database before the filesystem with the database files is mounted.

This was solved decades ago with numbered init symlinks:

  K20postgresql
  S20postgresql

Re: Systemd redux: The end of Linux

#258

Post by jerven » Fri, Nov 21, 2014, 2:43 PM UTC

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?

Yes, declarative unit files are simpler than Turing complete shell scripts.

Re: Systemd redux: The end of Linux

#259

Post by erglkjahlkh » Fri, Nov 21, 2014, 2:45 PM UTC

pjc50 wrote: post #171

AaronFriel wrote: post #80

Perhaps this is a controversial idea, but is this not just someone finally taking the tried and true Open Source "advice" to heart? That is, every time I've reported something is broken, wonky, doesn't work reliably, et cetera, I've been told, "Submit a patch.", "Write some code.", or worse, "Implement it yourself." Someone finally got fed up with the haphazard state of affairs in Linux-land. Fed up with the fragment…

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

Re: Systemd redux: The end of Linux

#260

Post by rogerbinns » Fri, Nov 21, 2014, 2:49 PM UTC

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…

> Yet, name one problem you had with sound on linux in the past year?

A month ago with Ubuntu 14.04 - paired with a bluetooth speaker, but would not send any audio to it (A2DP) without any indication as to how to diagnose or correct the issue.