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

201–210 of 458 posts

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

#201

Post by StreamBright »

theamk wrote: post #127
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…

You are describing the downside of bazaar-style development. Init had very little to do with it. The real problem was a non-standard way of writing init scripts. That is the _only_ part that systemd was supposed to solve.

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

#202

Post by yrro »

epistasis wrote: post #102
Spivak wrote: post #90

Earlier quoted context omitted.

Just set ENABLE_RESOLVE=0 when compiling and resolved is gone?

You use the word "just" as if this were a simple thing to understand and know. Is this magic incantation communicates in a way that the usual people who compile this package can understand to use it without being intimately familiar with the code? I ask not rhetorically, just out of curiosity. It's not a typical type of suggestion for other packages I've encountered with open source, and it feels far more difficult t…

Yes it is.

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

#203

Post by Conan_Kudo »

fsh wrote: post #184
kokada wrote: post #109

Earlier quoted context omitted.

Almost every distro I know turns this option off by default, including Arch, NixOS and Debian (the last one I am not sure).

It defaults to "no" on Debian 10. Maybe Fedora changed the default?

Fedora does not have this feature on: https://src.fedoraproject.org/rpms/systemd/blob/265d91aff516...

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

#204

Post by pmlnr »

realusername wrote: post #136
theamk wrote: post #129

Earlier quoted context omitted.

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

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.

Systemd is the very manifestation of NIH and reinvention, they are incapable of using existing tech.

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

#205

Post by kelnos »

theamk wrote: post #130
sergeykish wrote: post #57

Earlier quoted context omitted.

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?

GNOME, essentially. If you want to run a fully-functioning GNOME on your distro, you have to be running systemd. Or have the time and patience to maintain a large patch set to work around the systemd dependencies.

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

#206

Post by jcelerier »

rleigh wrote: post #156
0zymandiass wrote: post #39

Earlier quoted context omitted.

It's dramatically simpler and more intuitive than what it replaced, so I'm super excited when someone comes up with something even better!

> It's dramatically simpler and more intuitive than what it replaced I hope you're being deeply ironic. It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. sysvinit had a socket interface with a single message type. It had a sin…

> It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex.

As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a reliable & simple way, for init, network, timers, etc etc

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

#207

Post by dTal »

Conan_Kudo wrote: post #192
gorgoiler wrote: post #139

Earlier quoted context omitted.

A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well as LSB init shell functions making init a much more standardized process. PAM was and still is quite hard to understand but, again, it had enough power and flexibility with @ based includes to allow individual distributions to lay things out sensibly and allo…

> A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well as LSB init shell functions making init a much more standardized process. These improvements weren't real. There was a long tail of scripts that didn't follow the standard and never would. Every distribution still had their own customizations on how sysvini…

And if that's all it did, we wouldn't be having this discussion. Instead it is becoming some sort of self-appointed "userland middleware", which nobody asked for. People resent "better init" turning into "henceforth home directories will behave differently".

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

#208

Post by kelnos »

josteink wrote: post #167
downerending wrote: post #72

Earlier quoted context omitted.

Systemd has many pluses, but simplicity and intuitiveness are most certainly not among them.

Simple... for what? I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user. With systemd? 5 lines or so of boilerplate, independent of distro. I don’t know about you, but I call that simple.

I think this subthread is talking about the complexity of a system's implementation, not that of its user interface.

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

#209

Post by aerique »

tannhaeuser wrote: post #183
AnthonyMouse wrote: post #149

Earlier quoted context omitted.

The problem is not that sysvinit doesn't exist, it's that other packages now have dependencies on systemd, so it doesn't just swap out.

Exactly, and to prevent this from happening is what Devuan is all about (as I'm sure you know): to keep all the maintenance work going into Debian, while remaining mostly bullshit-free. It's what I'm about to be installing after a decade on the Ubuntu desktop. The recent snap fiasco is just the final nail in the coffin. The trifecta of SystemD, Gnome3, and SnapD means that I can just use Windows with WSL if I wanted…

Good luck with Devuan (I have no experience with it).

If it doesn't work out I can recommend Void Linux. I've been using it for years as my daily driver since Debian switched to SystemD, both at work and at home.

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

#210

Post by nineteen999 »

noitpmeder wrote: post #125

My worst gripe with systemd is that I cannot find reliable docs for older versions.

Right. All we need now is systemd-selfupdated, so that it constantly keeps itself up to date, even through egress filtering firewalls.
Post reply on HN