Live data from Hacker News

Busybox removes support for systemd

git.busybox.net

131–140 of 203 posts

Re: Busybox removes support for systemd

#131

has anyone used Fedora 23 with Gnome, Wayland and Systemd ? I see a lot of religious handwaving around systemd, but F23 shows you the future of Linux desktop.. and it is brilliant. Right from network interfaces that dont change names when you swap hardware (powered by systemd) to making it damn easy to file crash bugs (using coredumpctl) to checking what services have failed "systemctl --failed" to a more secure grap…

> ...network interfaces that dont change names when you swap hardware...

I assume you're talking about udev's "Predictable Network Interface Names". [0]

That's a feature of udev, and -IIRC- has been around since shortly after udev's repo got merged into systemd's repo, but quite a bit before it became obvious that the Systemd Cabal wasn't going to put much -if any- particular effort into making it easy for folks to use udev without systemd.

While -due to inertia- I do use it on my systems, it doesn't provide value on systems that don't have more than one network interface of a given type. [1]

> ...to making it damn easy to file crash bugs...

I've been doing exactly this in KDE since... KDE 4.1? 4.2? So, this would be back in the ~2008->2009 time frame. I have fuzzy memories of a crash reporter in KDE 3, but -back then- I didn't build my systems with debugging info or frame pointers, so the backtraces were always useless and -thus- went unsubmitted.

> ...to checking what services have failed...

  rc-status --crashed
or

  rc-status --all --crashed
does the same for me on my OpenRC systems. Every sysvrc replacement that's not a toy provides this functionality.

> ...to a more secure graphical desktop...

I'm very glad that the Wayland folks are making good progress with their work.

> Deploying web-services on systemd is so much better...

Can you be specific here? There are a whole host of service supervision systems out there of varying quality and feature sets.

[0] http://www.freedesktop.org/wiki/Software/systemd/Predictable...

[1] After all, you can name your single wired ethernet NIC eth0, your single WiFi NIC wlan0, and your single USB-connected cellular radio usb0. That's far easier and more predictable than reading the output of lspci to figure out the name of your NIC. (If you get the urge to point out the cases in which the NIC-physical-path-dependent naming scheme does help, please carefully re-read the 'graph to which this footnote was attached.)

Re: Busybox removes support for systemd

#132
post #50

Earlier quoted context omitted.

Systemd is pointing out the truth about lots of "emperor's clothes" in the current Linux ecosystem. When there were problems about a desktop manager revamp or some crashy audio daemon, you could liquidate certain choices as irrelevant or lazy. Now the entire ecosystem's guts are being rewritten by RedHat for RedHat, and the developer community is simply going along because, in practice, they have no other choice . No…

I suspect many didn't see it coming because systemd was under the freedesktop.org umbrella rather than a Red Hat fronted project. Thing is though that while freedesktop.org is presented as being about cooperation and compatibility between desktop environments, a very large portion of what happens there is dictated by Gnome. And Gnome is yet another project that on paper is independent, but with big RH contributions i…

> Probably the worst part is that none of this is planned, there is likely no grand conspiracy. Its just that so many of the people involved walk in the same halls, share the same cafeteria tables, and sit in on the same meetings that a internal consensus ends up formed about what is the "right" way to do things.

This. The whole Linux community seems to be paranoid. It has to be a grand scheme, a plot to take over Linux, a conspiracy to kill "the UNIX way". Maybe it's just a group of guys solving their problems.

I don't see how anything of this is really Red Hat's "fault". Seriously. They develop a piece of software which solves their problems. They also incorporate projects they already maintain to improve functionality and make developing things easier. It's their projects, they're allowed to do that. The code is still open. It's not like everybody (Debian, Ubuntu, SUSE, etc) didn't have the ability to fork udev.

Yet all these projects chose not to fork the projects incorporated by systemd. Reason (1) might be it solves problems for them as well. There's no need to fork something that perfectly works for you. Reason (2) might be they don't have the resources. But that's a declaration of bankruptcy for the whole "Linux is built by community volunteers" thing. The people advising against "corporate influence" are not able to do anything of value in modern computing anymore (I'm well aware this is over-simplification, please bear with me). Requirements for software have changed. It's not 1970 anymore. And while the "old-school" users and devs are complaining about systemd & co, the "youngsters" are busy changing the ecosystem.

Re: Busybox removes support for systemd

#133

has anyone used Fedora 23 with Gnome, Wayland and Systemd ? I see a lot of religious handwaving around systemd, but F23 shows you the future of Linux desktop.. and it is brilliant. Right from network interfaces that dont change names when you swap hardware (powered by systemd) to making it damn easy to file crash bugs (using coredumpctl) to checking what services have failed "systemctl --failed" to a more secure grap…

I think this is what annoys me most about systemd. All of the advantages you list seem extremely niche to me. I mean network interfaces that don't change names? I think in over 15 years of using Linux I have never had a problem with this, and if I did I'm guessing it would be a) obvious b) trivial to fix. Same with the other stuff. To get these niche features we need to install a very complex, opaque, fragile and ver…

> I think in over 15 years of using Linux I have never had a problem with this, and if I did I'm guessing it would be a) obvious b) trivial to fix.

I have run into this. Two wired Ethernet NICs in a system. After a kernel upgrade, the module load order of each NIC got swapped, and the name of each NIC changed. Took me a while to track that one down. :P

For 99.9% of desktop users (and -I suspect- many servers), this doesn't ever matter, and the "predictable" names are substantially less predictable and discoverable than 'eth0' or 'wlan0' or whatever.

Additionally, if you move a NIC in your system to another expansion slot in the system, its name will change. So, there's that to remember about this particular scheme.

NOTE: I'm not trying to claim that it's not helpful! The "predictable network interface" naming scheme solves a real problem. It's just that it -like most things- creates a few unique problems of its own. ;)

Re: Busybox removes support for systemd

#135
This comment thread seems to be the 2-minutes-hate for systemd, with mostly predictable results. But the actual news seems to be that Busybox removed the use of the systemd notify system which lets systemd know that the service has indeed started and it’s OK to start other processes which depend on it. This is no great thing – the normal and traditional Unix way of daemons is for a program to fork, where the fork continues to be the actual daemon, and the original process exits. Systemd can detect this exiting of the started process, and will take that as the signal that the daemon is ready, so there is no need for the notifying function in this case.

Re: Busybox removes support for systemd

#136
post #126

PID 1 should be boring. Tiny, simple and boring. Any software project that raises this much controversy should be looked at with a raised eyebrow. A software project this large, complex, controversial and coupled that wants to be PID 1? Absolutely no way.

sysvinit provided me with so much excitement that now I will take anything that just isn't sysvinit.

It only replaces sysvrc, [0] but I find the OpenRC-powered systems I admin to be quite sane and easy to manage.

[0] But that's okay. I strongly suspect that when most folks say "sysvinit", they really mean "sysvrc". Hell, I used to be one of those folks until a while back.

Re: Busybox removes support for systemd

#137
post #112

Earlier quoted context omitted.

I don't want to argue about systemd vs this or that, but re: (2) you are totally misrepresenting linus's objection to systemd (developers). the well-publicized incident to which you're referring had systemd introduce something that broke userland, then instead of fixing it in systemd code, proposed a kernel change for it. this is, obviously , bad practice. it would be one thing if the systemd code exposed a vulnerabi…

I wasn't referring to any particular systemd thread (my experience has been watching Linux/Linus in the context of ARM), but I think you are referring to the post by semi-extrinsic and this thread: https://lkml.org/lkml/2014/4/2/420 I examined that thread, and the upshot seems to be that the kernel wasn't rate limiting logging so userland could break the kernel . And Linus threw a hissy fit instead of actually examin…

> And Linus threw a hissy fit instead of actually examining the situation.

You really, really, really need to take ten minutes or so and read the whole thread. If you've not the time for that, then the single message linked here provides a decent amount of context: https://news.ycombinator.com/item?id=10484317

Re: Busybox removes support for systemd

#138
There's a lot of hate for systemd and there's also a lot of people ignoring valid criticisms and going so far as labeling those making the criticisms as haters. This does not bode well for reasonable discussion. It has become very political.

Whether systemd is a good thing or a bad thing depends ultimately on what you're trying to do and what sort of operating system you're using. For some people systemd is really helpful, for others it gets in the way and creates unnecessary complexity where it otherwise wouldn't exist.

I've been using systemd along with fleet on coreos, and it's fantastic for me but I personally wouldn't want systemd on my desktop. The problem is that it has been forced onto people left right and centre when it doesn't suit their needs. That essential reasonable debate never occurred and those that are forced to either swap distro or 'convert' to systemd get upset. If there was a reasonable debate people would still hate on systemd, but at least the reasons for using it would be more known and the criticisms atleast acknowledged.

Re: Busybox removes support for systemd

#139
post #84

Earlier quoted context omitted.

Devuan is someone's extended tantrum and little more. Like every other rage-fork it'll die a slow death because who wants to develop on a platform founded on the premise of "why do we need to change anything? It's all working fine!"

And yet: https://git.devuan.org/explore They began work on a logind compatibility layer over ConsoleKit2, they're writing a NetworkManager alternative, they directly influenced and are supporting a udev alternative called vdev (which also has libudev compatibility), and a host of other things. For a rage-fork, it's pretty impressive. They're changing a lot. It's easier to just astroturf in the corner, though, I suppo…

> ...they directly influenced and are supporting a udev alternative called vdev...

Have you a notion as to why they're using vdev rather than eudev? What appears to be the vdev introductory blog post makes no mention of eudev.

Re: Busybox removes support for systemd

#140
Wait, people are using Systemd on embedded Linux? You go out of your way to replace the Linux userland with a single small binary, and possibly go through the trouble of using a small libc implementation, and then you install this mammoth called systemd.
Post reply on HN