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

121–130 of 458 posts

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

#121

Post by kimikimi »

WesternStar wrote: post #115
MereInterest wrote: post #61

Earlier quoted context omitted.

I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon…

I see this kind of talking about stuff like the Unix way and existing conventions and programs. I almost have to ask myself when did we end up in a mausoleum. The Unix way is just a guideline from a time some folks wrote some code. A seminal and important time. Its just one(perhaps of many) piece of anecdata. Old code is old code. It's useful but the patterns and conventions it was built on may no longer be relevant.…

It's a good question and infects all of our software "sacred cows."

The underlying thing is that we keep driving ourselves to "forward progress" in the sense of a collaborative hegemony, and only in those terms. Either a business wants to own the platform, or the developer wants to build that platform. To do that they have to achieve buy-in from existing stakeholders, but simultaneously reinvent incompatible things. Thus through repeated application of this approach the world of professional software development has aggregated itself into conformance to standards that barely make sense, are poorly specified, and have limited proof of concept, but tick whatever buzzword boxes are relevant to the immediate climate.

If you want to take a real stand, invest yourself in "dead" technologies. Then you can choose whatever you want, and if other people want to follow you on it it's implicit that they are working on a similar problem, and not trying to play the platforms game(else they would be looking for an angle to "modernize")

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

#122

Post by sneak »

gjvc wrote: post #45
meddlepal wrote: post #37

Oh good, the monthly HN systemd 5 minute hate is upon us once again.

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.

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

#123

Post by aganame »

dman wrote: post #101
aganame wrote: post #100

I wish systemd haters would make a public petition to remove systemd from this world. I would absolutely use such a list to make sure I never accidentally hire any one of them for any system administration positions.

As a person who does not work as a system administrator professionally but does use self administered linux machines as workstations systemd has not brought any new productivity gains but it sure has increased the learning curve.

As a person for whom Linux and BSDs have been a hobby since 1996, I have no idea what you're talking about.

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

#124

Post by Nextgrid »

gjvc wrote: post #45
meddlepal wrote: post #37

Oh good, the monthly HN systemd 5 minute hate is upon us once again.

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.

Is it actually unpopular or is there just a vocal minority constantly complaining about it while a much larger part of the user base is happily using it?

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

#126

Post by esoterae »

WesternStar wrote: post #115
MereInterest wrote: post #61

Earlier quoted context omitted.

I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon…

I see this kind of talking about stuff like the Unix way and existing conventions and programs. I almost have to ask myself when did we end up in a mausoleum. The Unix way is just a guideline from a time some folks wrote some code. A seminal and important time. Its just one(perhaps of many) piece of anecdata. Old code is old code. It's useful but the patterns and conventions it was built on may no longer be relevant.…

The conventions "Do one thing and do it well", and "Don't break the user experience" are not threadbare or shabby. Not UNIX nor its derivatives did spring fully formed from the foreheads of K̶n̶u̶t̶h̶ Thompson or Ritchie; it was written as a series of counterpoints to the prevailing designs and implementations of the day.

To us the ashes of our ancestors are sacred and their resting place is hallowed ground. You wander far from the graves of your ancestors and seemingly without regret.

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

#127

Post by theamk »

gorgoiler wrote: post #119

When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules. What’s much harder is (1) to expand ones code without coupling everything together (2) present it in a persuasive way that naturally builds a user base. SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to…

I think you underestimate how badly the old sysvinit sucked in the world with many good distribution-provided packages.

It was pretty good in the good, old days, where a sysadmin could list every daemon the system runs by heart, but it was breaking apart when you had tons of random packages:

Package X uses "start-stop-daemon" in ini file, so there is no way to get error messages if config file is incorrect. Package B has no disable switch, so you get to stick "exit" in /etc/default. Package C has this weird logging format which cannot be rotated daily, and is not integrated with anything. Package D likes to die and leave PID file around, and then it fails to restart because of that. Package E likes to bury its settings in /etc/init.d/ file, so there are conflicts every time it updates. User A likes to leave their executables on their machine after logout, so we need a cleanup script.

This was seriously getting old -- after you apply a hack after hack, you start wanting something better. There were a few candidates -- upstart, daemontools/runit, systemd. Only two of them actually did the work to add backward compatibility and integrate with upstream. Upstart sucked even worse than systemd. This left only one candidate.

Remember, even if you can claim for Fedora that someone "convinced the PHB", this does not apply to other distros. Debian, Ubuntu, Arch all chose the systemd voluntarily. This is because sysvinit sucks, and no one came up with a better option.

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

#128

Post by esoterae »

blibble wrote: post #96
throw0101a wrote: post #28

Earlier quoted context omitted.

> An init system is harder than it might seem at first […] systemd-as-init-system is not the problem. systemd-as-kitchen-sink is the problem. It's the tight coupling that annoys many people. Does udevd really need to be in the same repo? While there may be some nice things about journald, does it really have to be in the same source package? (And why can't it support remote logging with the industry standard syslog p…

> So, for the simple act of logging in, three mechanisms are required (systemd, /etc/shadow, /etc/passwd). This is inefficient, and Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user. 10 years ago this would have been considered satire

Honestly, hearing this functionality described is the same as seeing someone on television suggesting injecting bleach to cure some virus thingamajig.

Seriously. If I'd needed to solve "this problem" I would've written something to do it. This is false equivalence gaslighting on a level I only see equalled on national television.

I have an actual job where I have to get actual other things done. A lot of them. This is going to help less than none. The sheer arrogance of this continued nonsense is infuriating.

If I wanted A real computer, I would've just built it and saved the nickel.

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

#129

Post by theamk »

nine_k wrote: post #86

My beef with systemd is not its reinventing things. That part may actually be good. One problem is that a number of reinventions were poorly made. E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas. Another problem is the "I know better" attitude. Are user proce…

You don't want to use sqlite for logs -- it is way too complex, and in particular, it may roll back (=lose log entries) if it is low on space, and permanently damage data when writing onto disks with errors. It also makes wrong performance tradeoffs for logging -- your choices are either sync() all the time, or roll back on unexpected termination.

I don't like the that journald goes backwards in space and updates indices -- I like "append-only" attribute -- but at least it writes data sequentially one after another, which makes it pretty tolerant of data loss.

As for "without escape hatch", I don't remember any functionality like that? In fact, systemd is full of escape hatches which are documented and supported. Just recently, I had to modify "is computer online" check -- it was amazingly easy, all I had to do was to drop-in a fragment file for the right service. I remember doing the same in upstart -- it was a total pain, requiring reading the source code spread over dozens of undocumented files.

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

#130

Post by theamk »

sergeykish wrote: post #57
acdha wrote: post #34

Earlier quoted context omitted.

> An init system is harder then it seems ? You and Jonnax seem to think that unless you made it you have no right to say anything. Have you ever made an init system ? Researched what exactly goes into it ? Sure, there's more then just starting programs. But not much more. The only really complicated thing about getting a [linux] computer from kernel boot to firefox is setting up devices. And even that [udev,"hotplug"…

There is no competitor because there was no problem. For most of use cases SysV, rc.d worked. Just like ifconfig. Arch Linux switched to systemd earlier than Debian. And I have not noticed. Arch community accepts breaking changes. Debian? I believe they value stability. Systemd should have matured, proved its citizenship and qualities. And it would have been accepted. Instead it usurped. People had no choice but to a…

Usurped how? Who and how forced Debian and Arch to switch to systemd?
Post reply on HN