Live data from Hacker News

Busybox removes support for systemd

git.busybox.net

141–150 of 203 posts

Re: Busybox removes support for systemd

#141

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…

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

True - but that is a good question by itself right ? Why - when you already had sysv and upstart and everything. Supervisord seems to be very popular that is very, very similar to systemd in its working (same concept of unit files, declarative language,etc). If you like supervisord, then systemd is just a short hop away.

OpenRC would do the same - but are you claiming that openrc is BETTER than systemd ? Because systemd is making that claim.

What I'm failing to understand is how is systemd bad ? it is making my linux machine extremely stable and working with it (creating new unit files) is extremely intuitive. Where is it making everyone's life hard ? the old way of "service nginx restart" still works. "dmesg" still works...

Re: Busybox removes support for systemd

#142
post #50

Earlier quoted context omitted.

Debian isn't really a leader. They're more of a passive target platform and their committee has people from various strokes of the Linux community. As such, RH decisions with significant influence definitely would impact them. Ubuntu, in turn, is symbiotic with Debian, though still quite forked from it in most aspects beyond the packaging infrastructure (now with Snappy diverging even further). Nonetheless, Unity nee…

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…

This is Too Big To Fork https://news.ycombinator.com/item?id=6810259 at work. Any legally free-slash-open-source software project which is so complex that only a few big actors have the will and ability to make and maintain a fork is de facto under the shared proprietary control of those big actors. (The same goes for software where control of the installed base means de facto control over any changes to widely-used interfaces.) "Freedom of the press is guaranteed only to those who own one." The Linux 'ecosystem' is only unusual in that (as it seems) there's exactly one big actor left standing by now.

Re: Busybox removes support for systemd

#144

Earlier quoted context omitted.

So RedHat's choices impact Debian/Ubuntu, Arch, and SUSE so much? Honest question; I don't know the details. Or are you saying that distros rely on other components that are simply not feasible (maintained) anymore, so they have no choice? Just seems like if it's as bad as so many say, it just doesn't make sense for all these distros to blindly go along. Even the GNOME lockin doesn't seem like it'd explain it.

Debian isn't really a leader. They're more of a passive target platform and their committee has people from various strokes of the Linux community. As such, RH decisions with significant influence definitely would impact them. Ubuntu, in turn, is symbiotic with Debian, though still quite forked from it in most aspects beyond the packaging infrastructure (now with Snappy diverging even further). Nonetheless, Unity nee…

> Debian isn't really a leader. They're more of a passive target platform and their committee has people from various strokes of the Linux community.

This is so not true that it is bordering on FUD. Systemd's leadership depended on debian making a fairly democratic, open and violently fought battle between upstart vs systemd. Everyone knew that Ubuntu (which is pretty much defacto installed in every laptop sold in Asia) would adopt systemd based on Debian's decision.

It was an argument that went on for a year. Read it for yourself if you want - https://bugs.debian.org/727708

Not only did Debian make the decision to support systemd, it voted to NOT support other init systems. Mark Shuttleworth made his announcement the day after (http://www.markshuttleworth.com/archives/1316 ).

It is an interesting position to take by painting systemd as the lackey of a capitalist monopoly trying to take over the world. I can see how that can get a lot of mindshare. The truth is far simpler - systemd is far superior.

Re: Busybox removes support for systemd

#145
post #112

Earlier quoted context omitted.

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

I did read the thread before I even posted, thanks.

Linus' first reaction to systemd accidentally flooding the kmesg queue was to make an ad hominem flame directly at another developer when the kernel was responsible for at least half the problem (lack of rate limiting).

Most people would qualify that as "throwing a hissy fit".

Re: Busybox removes support for systemd

#146
post #85

Earlier quoted context omitted.

Redhat does a lot of upstream development. By comparison Debian just has enough resources for keeping Debian running. SUSE seems to be an afterthought at this point. Ubuntu seems to mostly be concerned with itself.

> By comparison Debian just has enough resources for keeping Debian running. I think that's a touch unfair. The fact that Debian runs on the BeagleBone Black and RedHat doesn't puts a bit of lie to that statement.

Red Hat has no reason to care about platforms like BeagleBone Black.

Re: Busybox removes support for systemd

#147

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…

yeah, i had similar experience while deploying production stuff to systemd. It does not hurt anymore, it has lot reliable tooling that just works. I understand that it's not "unix way" as people like to say. For me that also means "being reliable". Systemd gives me as an application developer everything i need and takes a lot of pain away. I'm happy.

Re: Busybox removes support for systemd

#148

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.

Embedded is not embedded:

Theres the really deeply embedded systems running on tiny processors which probably only run a single binary and are never updated.

And then there are big systems (think cellphones, automotive infotainment, etc.) running on quad core procoessors where you have dozens of processes, which might even be independently installed or updated. For those kind of systems you really want a sophisticated init system, and the cost of systemd is probably minimal compared to the instances of chromium/webkit/blink that you might already have on your system.

Re: Busybox removes support for systemd

#149

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.

Yes, and this has been one of the ways to configure uClibc buildroot for some years, now.

* http://superuser.com/a/699401/38062

* http://buildroot.uclibc.org/downloads/manual/manual.html#_in...

One might think that the technical changes here are "completely insignificant", but in fact there has been quite a lot of interaction between systemd and the BusyBox world over the years. With those as context, the headlined patch appears in rather a different perspective. Some examples:

* Davide Cavalca's patches from 2011 adding socket inheritance to BusyBox's syslogd, some options to hwclock, and some units: http://lists.busybox.net/pipermail/busybox/2011-January/0743...

* Davide Cavalca's patches from 2012 disabling some log services in favour of the systemd journal: http://openbricks-commits.narkive.com/jCnYGx8H/r13814-busybo...

* Peter Korsgaard's patch to avahi for BusyBox-rootfs disabling things that uClibc did not have, from 2010: https://github.com/enclustra-bsp/busybox-rootfs/blob/4e302ac...

* Peter Seiderer's patch adding a PostgreSQL systemd unit to uClibc buildroot in 2014: http://lists.busybox.net/pipermail/buildroot/2014-May/097163... ( approved in 2015: http://git.buildroot.net/buildroot/commit/?id=828d7b2f0d2288... )

* Albert Antony's BusyBox patch from 2015 to add crond.service: http://permalink.gmane.org/gmane.comp.embedded.ptxdist.devel...

* Denys Vlasenko is the person removing the ability for syslogd to inherit its socket (via a systemd mechanism) in the headlined patch. Here is the very same person adding that same code in the first place, back in 2011: http://git.busybox.net/busybox/commit/?id=9b3b9790b32d440eb8...

Re: Busybox removes support for systemd

#150
post #146
post #85

Earlier quoted context omitted.

> By comparison Debian just has enough resources for keeping Debian running. I think that's a touch unfair. The fact that Debian runs on the BeagleBone Black and RedHat doesn't puts a bit of lie to that statement.

Red Hat has no reason to care about platforms like BeagleBone Black.

My comment was more the fact that Debian has enough excess resources to support the Beaglebone Black. So, categorizing Debian as having barely enough developers to support itself is disingenuous.
Post reply on HN