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

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

Post reply on HN
Print view View original

421–430 of 458 posts

Re: Systemd, ten years later: a historical and technical retrospective

#421

Post by michaelmrose »

Koshkin wrote: post #390
michaelmrose wrote: post #380

Earlier quoted context omitted.

Virtually nobody is using multi-seat and none should. For most cases you would get better results by networking n cheap boxes rather than trying to buy a single beefy box to support n users on every dimension including perhaps even power usage if you used low power devices. Contention for io is a problem. Everyone wanting to say decode video simultaneously is a problem. Browsers high ram usage is a problem.

> rather than trying to buy a single beefy box to support n users This sentiment has always felt weird to me, as I have always seen UNIX as an OS that has been designed - from the ground up (in late 1960s ) to support multiple concurrent users - whether it is via a serial terminal, and now multi-seat, VNC or an X terminal. By today's standards it's not even such a "beefy box" that can easily do that.

Blame browsers as soon as 3 users wanted to use facebook youtube on your 1200 box each user will probably have a worse experience than 3 users running 400 boxes plus hardware failure would reduce capacity to 0% instead of 1 box failing at a time.

Re: Systemd, ten years later: a historical and technical retrospective

#422

Post by AnthonyMouse »

sneak wrote: post #229
AnthonyMouse wrote: post #142

Earlier quoted context omitted.

> Traditions are not always inherently valuable. Try new things. Discard the ones that don't work for you. But that's the trouble. The people who make systemd keep integrating it with everything else they make and vice versa, which makes it harder to try new things because instead of things coming in pieces you might replace, it comes as one big interdependent blob.

That's their business, and their decision if they're the ones doing the work. You can always simply not use that big interdependent blob, same as ever. I'm not sure what the problem is. I recently installed a Gentoo system with ConsoleKit and KDE Plasma, and it works great, not a trace of systemd anywhere. I also understand the original Gentoo guy forked Gentoo and made a new distribution (Funtoo) where systemd isn't…

Let me try this a different way.

People say that if you don't like systemd then don't use it -- and that's what the people who don't like systemd want to do. But not all of them want to compile everything from source like Gentoo.

So use Devuan, you say, or some other esoteric distribution with six thousand users instead of a million. Which is presumably what they are doing.

But they still want Debian/Ubuntu to use something other than systemd by default, because you need a lot of people to use something in order to get good bug reports and get people interested in fixing those bugs and making improvements to it. Use in popular distributions is the only way for the alternative to get those things, which makes people who don't want to use systemd unhappy when the most popular distributions do.

Re: Systemd, ten years later: a historical and technical retrospective

#423

Post by lmm »

cycloptic wrote: post #399
lmm wrote: post #304

Earlier quoted context omitted.

>The fact that the logind developers came to a different solution than you, after spending much more time thinking about it and actually implemented it, doesn't exactly imply logind developers are the ones with an attention deficit, or that logind is bad. ("CADT" apparently means "Cascade of Attention-Deficit Teenagers") The logind developers went against the established wisdom of experience (that big rewrites are ge…

>We should be less "inclusive" of people who want to rewrite everything. They should feel like impostors. You can't produce good quality if you're not willing to call out bad quality; Linux succeeded (for a time) because Torvalds had high standards and was willing to maintain them. I'm making a humble request, please do not bring this attitude in open source projects. Really I mean it. It's not helpful and it only ma…

> I'm making a humble request, please do not bring this attitude in open source projects. Really I mean it. It's not helpful and it only makes people angry.

I respect your position but I disagree. Projects shying away from criticism in the name of inclusiveness has gone hand in hand with a drop in quality, not just in terms of unwise rewrites but in terms of plain old bad/buggy code - which should not be surprising.

> You are also misinterpreting the behavior of Mr. Torvalds and confusing things.

My point is that Torvalds - historically - used language on the level of "incompetent vandals" freely where appropriate. In a serious software project people are, and should be, willing to state those kind of views very clearly and directly.

> The kernel developers have actually been some of the most adamant about rewriting major parts of the kernel and breaking internal APIs over and over again (not syscalls)

They have; at the same time they've been adamant about the need to avoid regressions, both in terms of maintaining external interfaces and in not ripping things out before a replacement offers feature parity and there's a reasonable migration plan in place. The bottom line is that they caused nowhere near the level of user-facing breakage that the systemd/gnome folks have, and that speaks to higher standards and better judgement.

Re: Systemd, ten years later: a historical and technical retrospective

#424

Post by lmm »

cycloptic wrote: post #361
lmm wrote: post #348

Earlier quoted context omitted.

> That is not relevant because the "common standard" in this case is the logind D-Bus API. There are no other active and viable alternatives to login management. It has two implementations, systemd-logind and elogind. You can choose either one, and only the first one requires systemd. Is there any commitment to treating those as stable interfaces, with a decent deprecation cycle around any incompatible changes? If so…

It appears they have marked the Logind API as being stable because it is intended to be used by the display server and by the DEs. I don't have any secret information here, I just saw this chart on their website. https://systemd.io/PORTABILITY_AND_STABILITY/ About BSD and non-systemd systems: I actually think it is possible for there to be better compatibility here eventually if someone builds more shims. BSD using M…

> The only non-systemd init that hasn't dragged their feet on this has been OpenRC, and even they still would not make any effort to be systemd-compatible because of objections over other things. So what is the solution here?

You either hammer out a common interface with compromises from both sides, or you implement the parts you want as progressive enhancement from a lowest-common-denominator baseline. It's not easy, it's not glamourous, but it's the right way to do it. Look at how e.g. web standards stuff happens when there's disagreement between different browser makers.

> Also, just going by the data, the repos for KDE (collectively) and FreeBSD (a monorepo, like systemd) are much, much bigger, just as tightly-coupled if not moreso, and get a lot more activity than the repo for systemd. It seems strange that you would pick those projects to contribute to.

I'd disagree with the idea that KDE is more tightly coupled; in my (limited) experience it's very cleanly factored and it's clear where the interface boundaries lie. It's a big project but if you want to fork and patch one part of it you can do that.

FreeBSD is theoretically more tightly coupled than GNU/Linux, but in practice I've found a lot less of the kind of interface churn that you see in Linux. Linux went through two or three rounds of different audio APIs where on FreeBSD you still just use OSS. I've lost count of how many times the way you do network config on Linux changed - I genuinely can't set up a network on Linux any more - whereas in FreeBSD it's all just ifconfig. Linux forced a quick migration to HAL followed by an equally quick deprecation in favour of udev; FreeBSD is still using HAL. There's just so much more commitment to stable interfaces, both in theory - a deprecation cycle for even the kernel ABI - and in practical experience. Or maybe it's just that the project doesn't have enough manpower to churn as much as Linux does, but either way the end result is that I can patch my system and expect my patch to keep working.

Re: Systemd, ten years later: a historical and technical retrospective

#425

Post by kbenson »

brmgb wrote: post #350
josefx wrote: post #301

Earlier quoted context omitted.

> Lennart and the systemd team did exactly that 10 years ago. Why can't you? It would be impressive if Lennart managed that by himself. Red Hat wanted it done, Ret Hat also has its hands in various open source projects that suddenly started to sprout hard dependencies to systemd. Projects like Gnome were Red Hat is by far the biggest contributor. Not much an individual programmer can do compared to a corporation thro…

> Red Hat wanted it done Red Hat had zero interest into a new init system when Lennart started systemd. They had just moved to upstart and Red Hat customers don't really care about init systems. Red Hat customers pay for their systems to be stable and to have someone to call when something goes wrong. Systemd gives Red Hat no competitive advantage whatsoever. I'm probably not going to make myself a lot of friends by…

> I'm probably not going to make myself a lot of friends by saying this but I don't really understand the systemd opponents.

I think sections 3.5 and 3.6 (all of them, including subsections outlines current problems pretty clearly. Summarized, systemd is complex to reason about, ambiguous in how it functions, and poorly documented in many cases. All the very similar directives with slight nuances paint a picture of people that didn't really understand the problem space as well as they thought they did (and to be fair, nobody did, and they probably had the best understanding, as woefully inadequate as it was). For a sysadmin, who rarely (but not never!) has to dive into the intricacies of unit files and the myriad directives and their nuanced behavior for creating a server but less rarely is affected by odd behavior introduced by systemd, it's a liability.

What we have now is a chance to learn from those missteps and build something even better. Systemd as a catalyst for rapid chance was wildly successful. As an init system that capitalizes on those changes in a way that users (that is, system/distro packagers) can take advantage of, not so much, since it's so wildly complex. The article posits that BPF will be used to create programs to take over some of these tasks, which may be right. Alternatively, we could start pulling out the components that systemd subsumed, and formalizing them into new standards that others could develop for. Whether that means actually pulling out the component (e.g. logind) to a new repo, or just formalizing API is up for debate.

Re: Systemd, ten years later: a historical and technical retrospective

#426

Post by realusername »

rurban wrote: post #404
realusername wrote: post #136

Earlier quoted context omitted.

Sqlite is battle-tested though, it has one of the most comprehensive test suite and is used on billions of devices already. What systemd is doing with this log storage system is reinventing sqlite, because systemd has a fairly new and not battle-tested database implementation, it has shortcomings. I would argue that either they use plain text logs like before or use sqlite but they should not reinvent a new db.

sqlite is a dirty hack. just because people like hacks doesn't mean it's ready for the serious stuff. it is not. https://research.checkpoint.com/2019/select-code_execution-f...

It's certainly more ready than a custom hacked-up database which has data corruption even on my own laptop.

Re: Systemd, ten years later: a historical and technical retrospective

#427

Post by dijit »

theamk wrote: post #420
dijit wrote: post #393

Earlier quoted context omitted.

> you mean, "add -x to the invocation, get back a few screenful of text, wade through that looking for "export" lines and copy them to your terminal, find "start-stop-daemon" line, copy the part of the line and remove irrelevant parameters, and paste into your terminal as well? I mean, yes? Granted I'm not a developer but printing out exactly what's happening line by line with all variables expanded and all logical c…

Are you perhaps confusing something? > A "bad" daemon might not print anything to stdout when invoked (which goes to dmesg) but regardless, this whole comment just reeks of someone who hasn't actually dealt with systems before 2014. The daemons never print to dmesg -- they may print to syslog, but not all do. The only daemon that I know of that prints to dmesg is systemd :) To be specific, let's do a simple example.…

log_warning_msg is a function which is wrapping 'echo'.

if you 'echo' it will go to the console.

Your distro can/does log everything that goes to the boot console.

The function 'log_warning_msg' is provided by the sourced bash file: /lib/lsb/init-funtions ; you can find a copy here: http://www.linuxfromscratch.org/lfs/view/7.0/scripts/apds02....

It's just doing echo.

If you add "echo" it will print. I promise.

And anything printed goes to whatever your distro is using to log tty0 console output. (usually /var/log/dmesg or /var/log/messages)

Re: Systemd, ten years later: a historical and technical retrospective

#429

Post by bandrami »

sneak wrote: post #122
gjvc wrote: post #45

Earlier quoted context omitted.

It's worth considering why the topic makes such a regular appearance. I suggest it might be because that so many users of this website find it to be a remarkable example of not only how something so widely unpopular can become so widely established, but also being something that they have to contend with frequently.

It would appear from distribution adoption that systemd is a lot more popular than it is unpopular.

Oh God no. Alpine is the most-used Linux distro out there (containers count, remember) and it's mostly used specifically to avoid the opaque mass of spaghetti unit files that is systemd service management.

Re: Systemd, ten years later: a historical and technical retrospective

#430

Post by bandrami »

dralley wrote: post #132
sneak wrote: post #122

Earlier quoted context omitted.

It would appear from distribution adoption that systemd is a lot more popular than it is unpopular.

One of the reasons distributions appreciate systemd because systemd unit files are easy to write and can easily be written and maintained upstream and used with very few if any modifications downstream. Your average HN user doesn't see or particularly care that it makes things easier for distro maintainers, so it's much easier to push the corporate conspiracy angle than to accept that a lot of the hand-wringing takes…

As a Slackware and OpenBSD user I've really never understood this complaint. The init scripts they ship with are neither difficult to understand nor hard to read, and new ones are very easy to write.

Maybe the LSB stuff was awful; I never used it, and for that matter I can't think of a reason I would want to. It's the old FreeDesktop.org issue: it's a probably-interesting solution to a problem I just don't have.

Post reply on HN