Busybox removes support for systemd • Hacker News Board

Re: Busybox removes support for systemd

#161

Post by Sanddancer » Sun, Nov 01, 2015, 4:54 PM UTC

sandGorgon wrote: post #123

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 the key word there is desktop. The systemd folks are desktop folks first and foremost, server operations be damned. coredumpctl requires root access, which means one has to be much more diligent in scripting automatic actions to handle core dumps. Failed services again are something that any supervisor service can handle and report -- launchd can get all that information from launchctl. Rootless X is something OpenBSD has had for years, through better access control than linux devs seem to be able to be bothered with.

The biggest problem with systemd is its mediocrity. The journal is an interesting idea, but it's inflexible. Its insistence on json and internal formats mean that it doesn't work with the rest of the extant logging infrastructure tools that exist, so if you want to have a dedicated log server, you have to run essentially two syslogds. Its core dump misfeatures make it harder to use extant access control features to manage files. Its unit files don't allow for any sort of extensibility, so adding things like a configtest command for a unit are impossible. In short, its oversimplified itself to the point where it adds a huge management load just to keep servers where they were.

Re: Busybox removes support for systemd

#162

Post by digi_owl » Sun, Nov 01, 2015, 5:00 PM UTC

Sevrene wrote: post #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 he…

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

I can't shake the suspicion that ever since gamergate, or perhaps even "for the lulz" anonymous, there have been people going around the net, latching onto anything vaguely controversial, and trying their best to stir up trouble by making threats and statements that are barely relevant to the topic.

Re: Busybox removes support for systemd

#163

Post by otterley » Sun, Nov 01, 2015, 5:39 PM UTC

vezzy-fnord wrote: post #89

otterley wrote: post #81

Earlier quoted context omitted.

What is the criteria by which you classify something as "opaque"? The documentation for systemd and its utilities is second to none.

The documentation for systemd and its utilities is second to none. God help the software industry if that is indeed the case (of course, it is not).

What specifically do you find lacking in it?

Re: Busybox removes support for systemd

#164

Post by embik » Sun, Nov 01, 2015, 6:03 PM UTC

digi_owl wrote: post #160

embik wrote: post #132

Earlier quoted context omitted.

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

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

Totally agree. The needs of modern computing (server-, desktop- and security-wise) have drastically increased IMHO. You need to read so much documentation and existing code before you can even start coding. That's just not feasible in your free time after work if you're having an active social life or another computer-unrelated hobby.

Although I have to admit I might be biased about this topic. I'm contributing to a FOSS project which got a lot of flak for trying to raise money for employees in a ... well, more aggressive way. While not necessarily agreeing with everything that happened, I do believe you need to work full-time on modern FOSS projects to push ahead.

Re: Busybox removes support for systemd

#165

Post by the_why_of_y » Sun, Nov 01, 2015, 6:32 PM UTC

vezzy-fnord wrote: post #93

XorNot wrote: post #87

Earlier quoted context omitted.

Most of systemd is not in PID 1. People making this complaint don't seem to have any idea what is in init normally or why you might want to add more stuff there (for example, where are you going to manage cgroup trees for system processes from?)

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…

This question has always appeared to me as academic, with little or no real-world relevance.

If your service manager process were to crash, what are you going to do about it?

If you restart the service manager, it won't know what state the system is in, which services are running and which are not, which services were running at the time when it crashed but then stopped just before it restarted, etc.

How are you going to do that in a race-free and reliable way that is actually better in practice than the alternative (reboot)?

And if your service manager is a single point of failure, it doesn't matter much which PID it's running it, it has to be perfectly reliable anyway (just like the kernel).

Re: Busybox removes support for systemd

#166

Post by the_why_of_y » Sun, Nov 01, 2015, 7:03 PM UTC

sandGorgon wrote: post #144

vezzy-fnord wrote: post #40

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…

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

Your comment gets it mostly right, except:

> Not only did Debian make the decision to support systemd, it voted to NOT support other init systems.

This is incorrect: systemd was merely voted as the default init system, other init systems are explicitly supported, here's the TC decision:

https://lists.debian.org/debian-devel-announce/2014/08/msg00...

Re: Busybox removes support for systemd

#167

Post by vezzy-fnord » Sun, Nov 01, 2015, 7:17 PM UTC

the_why_of_y wrote: post #165

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…

This question has always appeared to me as academic, with little or no real-world relevance. If your service manager process were to crash, what are you going to do about it? If you restart the service manager, it won't know what state the system is in, which services are running and which are not, which services were running at the time when it crashed but then stopped just before it restarted, etc. How are you goin…

There's been a lot of research in fault recovery through message logging and checkpoint-based methods that could be applied here, e.g. [1]. Of course, you use "academic" as a snarl world, so I don't think anything will convince you.

The idea that the service manager would not be able to know the system and service states is completely false. Solaris SMF is a design that does, via its use of the configuration repository. Simpler designs can then deduce enough metadata from the persistent configuration in the supervisor tree. There's many possible approaches.

The idea that such fault recovery is implausible is a naive one that only one unfamiliar with the research literature could espouse.

If we take your logic to its conclusion, we should just run everything in ring 0 with a single unisolated address space, because hey, anything can fail. Component modularization and communication boundary enforcement is the first step to fault isolation, which is the first step to fault tolerance.

[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52....

Re: Busybox removes support for systemd

#168

Post by JdeBP » Sun, Nov 01, 2015, 7:44 PM UTC

the_why_of_y wrote: post #165

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…

This question has always appeared to me as academic, with little or no real-world relevance. If your service manager process were to crash, what are you going to do about it? If you restart the service manager, it won't know what state the system is in, which services are running and which are not, which services were running at the time when it crashed but then stopped just before it restarted, etc. How are you goin…

> If your service manager process were to crash, what are you going to do about it?

With the assistance of the SRC_kex.ext extension, you re-establish knowledge of all running services in a new service manager.

* http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com...

Or you make the other engineering tradeoffs.

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

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

Re: Busybox removes support for systemd

#169

Post by toyg » Sun, Nov 01, 2015, 8:32 PM UTC

digi_owl wrote: post #160

embik wrote: post #132

Earlier quoted context omitted.

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

This has been the case for some time now, but the ecosystem of large-ish companies was diverse enough as to avoid appearing dominated by this or that player. The fall of Novell and Nokia, coupled with Ubuntu's various pivots and IBM's troubles, left Red Hat as the lone real force with the capability to steer the most significant projects.

This is nobody's fault, but it's not healthy in the long run.

Re: Busybox removes support for systemd

#170

Post by teddyh » Sun, Nov 01, 2015, 9:30 PM UTC

JdeBP wrote: post #151

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…

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

All right, what was the removed code doing?

> * That's a 1980s idea of "normal".

That’s why I called it “normal and traditional”.

> * Most programs in the wild do not correctly speak the forking readiness protocol

True enough. But for practical purposes, it’s mostly good enough. And I’d think that it doesn’t matter that much for people running BusyBox with sysvinit.