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

121–130 of 203 posts

Re: Busybox removes support for systemd

#121

Post by joonoro »

AdmiralACK wrote: post #91
cosarara97 wrote: post #64

Earlier quoted context omitted.

There is plenty of people happy with debian's adoption of systemd, myself included.

I'm going to step out on a ledge here, but those that are happy with it really don't understand linux or much of how it works beyond editing a few confs. None of which ever touch systemd

Considering how many distros have adopted systemd, of whom I am willing to bet most of their devs "understand" Linux and aren't completely against systemd, I would not say that they are happy with it because they don't understand it.

Re: Busybox removes support for systemd

#122

Post by jessaustin »

yeukhon wrote: post #119
AdmiralACK wrote: post #77

Earlier quoted context omitted.

Redhat used to be good before they forked off the desktop OS into Fedora. They went downhill in my eyes quickly after that.

But isn't Fedora really is a bleed-edge version of CentOS? So what's the issue?

ISTM "bleed-edge version of CentOS" is a bit of an oxymoron. When has anything in that distro been current, to say nothing of cutting-edge?

Re: Busybox removes support for systemd

#123

Post by sandGorgon »

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 graphical desktop (rootless gnome with systemd) - it makes for a better linux.

Deploying web-services on systemd is so much better - think supervisord, but much more stable and robust. Even docker machines using systemd is great (in fact it is a great way to explore systemd).

Re: Busybox removes support for systemd

#124

Post by _b8r0 »

Avshalom wrote: post #86
bossrat wrote: post #72

Earlier quoted context omitted.

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"

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_;)

Re: Busybox removes support for systemd

#125

Post by okasaki »

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 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 verbose set of tools that throw away most of what I've learned in my 15 years. Blah!

Re: Busybox removes support for systemd

#126

Post by sobkas »

erpellan wrote: post #38

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.

Re: Busybox removes support for systemd

#127

Post by sandGorgon »

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…

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

Re: Busybox removes support for systemd

#128

Post by lomnakkus »

AdmiralACK wrote: post #91
cosarara97 wrote: post #64

Earlier quoted context omitted.

There is plenty of people happy with debian's adoption of systemd, myself included.

I'm going to step out on a ledge here, but those that are happy with it really don't understand linux or much of how it works beyond editing a few confs. None of which ever touch systemd

Classic ad hominem. Do you have anything substantive?

FTR, I understand "linux"[1] better than most and I'm very happy with systemd. So there. It's by no means perfect and could probably stand to be revisited architecture-/design-wise in a few years when there's even wider community experience with it -- but that can come as incremental improvements.

[1] Whether you meant the kernel or user-space. Both as a user, administrator and developer.

Re: Busybox removes support for systemd

#129

Post by merb »

magila wrote: post #42
felixgallo wrote: post #34

Earlier quoted context omitted.

that is not at all what happened. Here's Kay Sievers, defiantly posting after in his own words after the incident: https://plus.google.com/+KaySievers/posts/3cWXzYqB6MB

There were two different issues at play: 1. A system hang due an assertion in journald spamming kmsg. 2. The question of whether systemd should be logging to kmsg or doing anything based on the "debug" kernel command line argument. Linus got pissed because, based on Steven Rostedt's post to LKML and the referenced bug report, it looked like Kay was refusing to fix issue #1, but that bug had already been addressed and…

1. i think that assumtion is right.

I mean rate limiting stuff that comes from anywhere is needed. not cause of the fact that systemd does it. I mean if I could write a userspace tool that crashes the kernel.. is somewhat aweful.

Re: Busybox removes support for systemd

#130

Post by merb »

bsder wrote: post #112
simondedalus wrote: post #103

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…

I think the way you did. Many things in systemd aren't as good as they should be. However it's working and does his job. The issue that raised up here is definitly a problem in the kernel. I mean it's not a good practice that other programs could flood yours. However the problem whey they argued that so hard is caused by the fact that both parties trying to fight a political war over the linux ecosystem which is just bad, kay sievers also said it. They make a project that can only be good if all parties, kernel, init, gui, are playing together and not fighting against each other like childish politicans.
Post reply on HN