Interesting to see that the commit linked here has been yanked from the repo. For the curious, here is the original commit comment: > remove systemd support > systemd people are not willing to play nice with the rest of the world. > Therefore there is no reason for the rest of the world to cooperate with them. > Signed-off-by: Denys Vlasenko http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...
Busybox removes support for systemd
111–120 of 203 posts
Re: Busybox removes support for systemd
#112Earlier quoted context omitted.
People have been trying to fix the boot process in linux for years. Like most things, everybody screams when something changes, but nobody is willing to put in the work to make something better. RedHat had enough, and finally jammed systemd down on the Linux ecosystem. This had two effects: 1) Technical: it exposed a LOT of shortcomings in the architecture of Linux for operating on modern systems. The whole "This bel…
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 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 examining the situation. The kernel not rate limiting is a fault in the kernel. The fact that a user program exposes it does not mean that the user program is the one in the wrong. And Sievers basically said: "Not rate limiting logging is a kernel problem. We're going to make you fix it." So, basically he had the temerity to both A) pull a political power play and B) be technically correct--and it pissed Linus off ferociously.
Linus, however, is fighting with the 800lb gorilla. That's not a good position to be in. Linus needs the RedHat programmers more than the RedHat programmers need Linus. They'll keep Linus around to avoid the bad PR that would come with a fork, but, if he gets in the way, they'll just cut him out of the loop.
Re: Busybox removes support for systemd
#113I really like systemd because all the controversy made me look towards FreeBSD, and this has really been a great experience. No offense, but I can't stop thinking about the Linux community as a screaming child with short attention span. The BSD community seems more like an old grey beard, sitting calmly in the corner solving problems in the best way possible. This may take some time but the result is often superior.
GEOM, cvsup, how many versions of port managers?, perl and gcc extraction/clang migration in base system, and the big ones NetBSD and OpenBSD--all represented wrenching progress--*BSD has its own set of people throwing temper tantrums at various points, as well.
Re: Busybox removes support for systemd
#114Interesting to see that the commit linked here has been yanked from the repo. For the curious, here is the original commit comment: > remove systemd support > systemd people are not willing to play nice with the rest of the world. > Therefore there is no reason for the rest of the world to cooperate with them. > Signed-off-by: Denys Vlasenko http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...
Hm? It's still there. http://git.busybox.net/busybox/log/?ofs=49
Re: Busybox removes support for systemd
#115I have to make this comment with a throwaway as its related to my previous job. Leaving aside the technical issues the launch of systemd 'looks' very much like a playbook PR campaign designed to push through something unpopular. The discrediting debates, labeling near abuse and mockery of opponents, appeals to authority and exaggerated consensus do not look accidental. This has all the markings of a sophisticated cam…
> The discrediting debates, labeling near abuse and mockery of opponents, appeals to authority and exaggerated consensus do not look accidental. This has all the markings of a sophisticated campaign.
Sophisticated? That's pretty laughable. To most outside observers this looks like monkeys flinging poo.
In addition, you make a serious error in your assumptions:
Popular != technically correct Unpopular != technically incorrect
RedHat did not just magically have an epiphany and decide to shove systemd down on everybody. They started by using "upstart". Remember how everybody went apeshit over that? Sounds a whole lot like the current debate doesn't it? After using upstart for a while, folks at RedHat decided that wasn't sufficient and they needed a replacement for that.
People seem to think that just magically RedHat decided to rip things up for no reason at all. That's patently false--RedHat has some issues that need to be solved and systemd solves those. If you want to beat systemd, you're going to have to give RedHat something which works better.
After their experience with upstart, it's no surprise that RedHat just decided to ignore the community. It was clear that a solution was never going to be accepted.
Re: Busybox removes support for systemd
#116> systemd people are not willing to play nice with the rest of the world. Can we get a bit a of context on that?
After they repurposed the "debug" kernel flag and made it literally unusable with systemd, Linus banned one of their core devs (Kay Sievers) from contributing to the Linux kernel, and I quote: "I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project." https://lkml.org/lkml/2014/4/2/420
Re: Busybox removes support for systemd
#117PID 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.
you are exactly on point. the unix way is simplicity and transparency. systemd is complex and opaque. it's ok to have systemd's goals, but an additional goal should be "not a huge monolith"
We all agree with you on the 'simple as possible' but you need to spend some effort on the 'no simpler' part.
Re: Busybox removes support for systemd
#118The technical aspect here is completely insignificant. All they did was remove a basic listener function that was already optional, used to communicate with systemd's socket activator without linking to libsystemd itself. And it seems only one Busybox daemon ever made use of it. The political significance is quite high, and I have to say I feel that this move, though perhaps a bit childish, is a valid signal to expre…
Re: Busybox removes support for systemd
#119Earlier quoted context omitted.
Yes systemd is Red Hat's "embrace, extend, extinguish" strategy for Linux.
Redhat used to be good before they forked off the desktop OS into Fedora. They went downhill in my eyes quickly after that.
Re: Busybox removes support for systemd
#120Earlier quoted context omitted.
After they repurposed the "debug" kernel flag and made it literally unusable with systemd, Linus banned one of their core devs (Kay Sievers) from contributing to the Linux kernel, and I quote: "I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project." https://lkml.org/lkml/2014/4/2/420
You're just fanning the flames. That incident has nothing to do with this Busybox commit.