Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Busybox removes support for systemd

git.busybox.net

Post reply on HN
Print view View original

151–160 of 203 posts

Re: Busybox removes support for systemd

#151

Post by JdeBP »

teddyh wrote: post #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 con…

That is wrong in three ways.

* That's not what the removed code was doing at all.

* That's a 1980s idea of "normal". Forking is something that has been gradually disappearing as standard practice for daemons for the past 16 years, as can be seen from the large number of daemons that now have "don't fork" modes, as compared to the number in the middle 1990s. The idea that daemons fork as some sort of standard practice was the mainstream thinking then, but it is not now.

* Most programs in the wild do not correctly speak the forking readiness protocol, in part because those programs are not forking as a readiness protocol in the first place. Many people, in particular those involved in the Debian Technical Committee hoo-hah a while back, considered the opposite of what you claim to be actually true. There is no need for the flawed, bodged, and in practice broken forking readiness protocol when one has a proper readiness notification protocol. http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/un...

Re: Busybox removes support for systemd

#152

Post by JdeBP »

vezzy-fnord wrote: post #14

The 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…

> The technical aspect here is completely insignificant.

I disagree. My initial reaction was to lament the fact that BusyBox syslogd has lost the ability to be passed its socket as an open file descriptor. One may debate whether systemd's mechanism or UCSPI-UNIX (extended to datagram sockets) is the better way to pass such descriptors along. But it now has no mechanism. BusyBox syslogd is now less than it was.

Re: Busybox removes support for systemd

#153

Post by JdeBP »

ymse wrote: post #102
throw23000 wrote: post #98

I 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…

How is this related to anything, let alone your job? As I'm sure you know, systemd grew out of Red Hat, and Debian as most other Linux distributions have adopted it in lack of a better alternative. There is no grand scheme to it other than getting rid of SysV. In a few years time uselessd, nosh, dmd and the many other systemd-lookalikes in development have matured and there will once again be diversity in init land.

The self-styled "uselessd guy" is present on this page, and xe has gone on record some months ago that uselessd is a "dead project". Replace uselessd in your list there with s6-rc and System XVI, therefore.

* http://skarnet.org/software/s6-rc/

* https://github.com/ServiceManager/ServiceManager/

* https://news.ycombinator.com/item?id=9809829

* https://news.ycombinator.com/item?id=10215008

* https://news.ycombinator.com/item?id=10212885

And replace "systemd-lookalikes" with service and system management systems, while you are at it. Neither of those is aimed at looking like systemd, and it would do them a disservice to miscategorize them as such.

nosh 1.22 is about to be announced.

Re: Busybox removes support for systemd

#154

Post by generic_user »

johnny22 wrote: post #107
generic_user wrote: post #52

Earlier quoted context omitted.

Just to add to the others CentOS was essentially bought by RedHat and there Core developer is now a RedHat employee. Magically there was a new major 7.0 version bump adopting SystemD as the one and only init system. A new flashy website and a refusal to allow any alternative init system into the official packages other then SystemD. Needles to say CentOS is no longer an independent alternative to RedHat Linux.

CentOS has NEVER been independent of RHEL

RedHat has to release there sources for others to use. Most of the code is under some form of GPL. CentOS was an independent volunteer driven effort that compiled and packaged that code into a new distro not affiliated with RedHat. That is why they had to remove RedHat branding and they could not market CentOS as RHEL etc.

Re: Busybox removes support for systemd

#155

Post by weland »

bsder wrote: post #150
weland wrote: post #146

Earlier quoted context omitted.

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.

Nonetheless, Red Hat really is doing a lot of upstream development, certainly more than Debian does as far as I know. Indeed, the Debian community has managed to keep their release schedule and meet their goals lately, so they're probably in a better shape than "barely enough to support itself", but there hardly seems to be room for comparison between the two.

Re: Busybox removes support for systemd

#156

Post by vezzy-fnord »

sandGorgon wrote: post #127
vezzy-fnord wrote: post #93

Earlier quoted context omitted.

Yes, not charting out your module boundaries and just bundling the system and service state along with parsing and cgroup management in the same process is relatively unwise. Even Solaris SMF got it right by keeping init(8) small amidst the otherwise highly impressive feature set of the main service management, using contracts (the equivalent to cgroups, which actually predate them) outside PID 1. So the same can be…

systemd is NOT making the change to manage cgroups from PID1. Kernel is - systemd is just the first (and currently the only) one to comply with this change. Legacy cgroup API is going away. It is the same case for the /usr merge [1]. systemd is not forcing the change, but it is complying with the changes required and is getting blamed for it. [1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...

Incorrect. The kernel mandates a single writer. It doesn't enforce any particular PID.

Re: Busybox removes support for systemd

#157

Post by GFK_of_xmaspast »

_b8r0 wrote: post #124
Avshalom wrote: post #86

Earlier quoted context omitted.

The unix way is also a different incompatible implementation of regex in every utility and a thousand interesting and dangerous modes of failure in the event of whitespace Systemd has issues I'm sure and I don't trust poettering's software further than I can throw him but not being 'unix'-y isn't a strike against it.

> The unix way is also a different incompatible implementation of regex in every utility and a thousand interesting and dangerous modes of failure in the event of whitespace Then_stop_using_whitespace_and_that_problem_is_solved_for_some_values_of_solved_;)

"You're doing it wrong and should have known better" is also the unix way.

Re: Busybox removes support for systemd

#158

Post by SFjulie1 »

vezzy-fnord wrote: post #21
SFjulie1 wrote: post #18

Earlier quoted context omitted.

That's one of the critics of open source (BSD) world versus free software world. GNU /Linux projects have been designed for figthing on socio-ethico-political grounds against proprietary software. The first one being Unix. (GNU's Not Unix) On the other hand, BSD prefers to see itself like a community of pragmatism, and creating values in business by sharing externalities (plus a bunch of fanatics that loves nice code…

My interpretation is a tad more charitable. The reason the Linux community is so dysfunctional is because, for most people born during a certain time period, it's the first ever OS they use that isn't Windows, and the first ever Unix. Naturally this creates a lot of sudden revelations, and a lot of blowhards who think they're hot because they can rice their Arch Linux box. In the process a lot of false sense of techn…

The AT&T lawsuits for the Unix (c) infringement has been largely used as a FUD from both MS and GNU against open source.

It was fixed fast, but the PR standed long. (calomniez, calomniez, il en restera toujours quelque chose)

The BSD community having been beaten early by the IP problems have been more cautious since this time whereas the linux (as an OS) community becoming an official UNIX (c)(tm) in 1997 as they became POSIX compliant and have been artificially protected from IP problems has been careless in disentangling itself from all the proprietary shit that IBM and other big company that wanted to kill the cost of maintaining their own OS have been putting in the OS. (the legal construct for protecting linux from patent/IP problems involves a lot of big companies and complex clauses).

POSIX may have follow IP protocol in the direction of bloatware specifications.

Linux without this compliance and the support of the big companies seeing it as a way to reduce their costs (RH/IBM/maya/Oracle) would not have been able to substitute itself to other proprietary UNIX in the realm of "professional IT". Especially because big vendors made a pax romana around linux concerning the claims of patents when contributing to the OS.

But by mimicking and being driven by normalization/fundations where the main stake holders are proprietary vendors (HW/SW...) linux has became something of a proprietary software itself.

(Just look at who are the main ISO/IETF/IEEE/POSIX contributors nowadays, and the member of OSI/linuxfundation.)

Those who controls the API controls the OS.

Re: Busybox removes support for systemd

#159

Post by jo909 »

vezzy-fnord wrote: post #156
sandGorgon wrote: post #127

Earlier quoted context omitted.

systemd is NOT making the change to manage cgroups from PID1. Kernel is - systemd is just the first (and currently the only) one to comply with this change. Legacy cgroup API is going away. It is the same case for the /usr merge [1]. systemd is not forcing the change, but it is complying with the changes required and is getting blamed for it. [1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...

Incorrect. The kernel mandates a single writer. It doesn't enforce any particular PID.

You are right, but the cgroup manager should still be something that starts very very early, so you can start components that make use of it. If literally everything your init system starts should automatically use cgroups, you have to start it with the init system or as the first thing the init system will start.

Re: Busybox removes support for systemd

#160

Post by digi_owl »

embik wrote: post #132
digi_owl wrote: post #54

Earlier quoted context omitted.

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 Li…

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

May well be the case.

Somewhere GregKH mentioned how the pace of kernel development had changed, with git being a major part of it.

It may well be that the pace have now gotten to the point where hobbyists have a hard time keeping up, as they have things they need to do besides stare at code all day.

Post reply on HN