Live data from Hacker News

Systemd Sucks, Long Live Systemd

naftuli.wtf

181–190 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#181

Earlier quoted context omitted.

> a big wadded up ball of code. To be clear, they're all under the same umbrella project, but separate components and not everything is in PID 1. People seem to be confused by that.

Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.

It's kind of annoying reading people lecturing projects they clearly don't know the internals of on how much better their code would be if they did X.

This applies not just to your comment here but to a ton of comments that pop up on HN all the time. Why not in Go? Why not in Rust? Why not in React and node and electron and why don't you use my library that's still in alpha? It's not OOP. You're not using tabs. MIT is too permissive. GPL is too restrictive. And obviously, this should be a set of tiny separate libraries, how dare you work on free software with different ideas than mine.

I once found a project called Razor-qt. It was a desktop environment that included a bunch of interdependant binaries all under the same repo. I didn't like that very much. I joined it, worked on it, ended up leading the project and merging it with LXDE into LXQt. When came the time for the reorganization, I did push to create tiny components that "could be downloaded piecemeal and compiled independently". And we did end up going that route.

You know what I didn't do? I didn't go on HN and complain about a project I didn't know the internals of at the time.

But hey, maybe you know better. ¯\_(ツ)_/¯

Re: Systemd Sucks, Long Live Systemd

#182

More and more systemd is becoming symptomatic of deeper divide within the Linux "community". The split being between those that embraced Linux for being a free, in both senses, _nix unburdened by AT&T and running on commodity hardware, and those that got to know it after the dot-com crash as the L in LAMP. The former cares for Linux as a _nix, the latter could not care less about _nix and may see it as a vestigial ap…

No, it's symptomatic of most of the Linux community having embraced systemd, and the holdouts being few and far between.

Re: Systemd Sucks, Long Live Systemd

#183
post #92
post #83

Earlier quoted context omitted.

I keep forgetting why I hate systemd (and as a FreeBSD user for all things, I have never used it) and then an article like this reminds me ... binary logs. Seriously - just reading it is painful. binary logs That's a lot of things, but it ain't unix.

Eh, like the other commenter said, you get used to it. Everything in life is a compromise in one way or another. Using journalctl instead of less? That took me about 5 minutes to commit to memory, and then...that's it. I don't even think twice anymore about using one command or another to read the contents of the log.

But you still need less, so now you've added one more command to remember for minimal benefit; less and grep are standard tools for working with everything, journalctl is a one-off.

Re: Systemd Sucks, Long Live Systemd

#184
post #24

I'd probably respect SystemD a lot more if it measured itself against a modern init system like Gentoo's OpenRC instead of pretending it's invented dependency handling. https://wiki.gentoo.org/wiki/Comparison_of_init_systems > OpenRC provides a number of features touted as innovative by recent init systems like systemd ...

OpenRC's the only init system I've actually liked . It's one of the things I really miss from when I used Gentoo, and I don't know why more distros didn't adopt it years ago.

TrueOS has just switched from Mewburn rc to OpenRC. They've had some problems to overcome.

Re: Systemd Sucks, Long Live Systemd

#185
post #177

Earlier quoted context omitted.

networkd doesn't know about wpa_supplicant, just as it doesn't know about openvpn, vpnc, ... If you want a network manager that does know about those and might give more helpful error messages if they fail, use for example NetworkManager.

Then perhaps networkd should be dropped, because: repeat after me: everything eventually fails. How can you tell when a programmer has graduated from "completely new at this" to "has some valuable experience"? That point comes when they stop assuming success. Check for error and do something useful with the returned value. Write tests yourself. Fail gracefully. Log status, so you know what was happening just before i…

`ifconfig`, `ip`, `dhclient` or Debian's `ifupdown` don't care about errors from wpa_supplicant either. Let's drop them too?

Or actually all of them (including networkd) work fine, but are not the right tool for every usecase.

Re: Systemd Sucks, Long Live Systemd

#186

Earlier quoted context omitted.

networkd doesn't know about wpa_supplicant, just as it doesn't know about openvpn, vpnc, ... If you want a network manager that does know about those and might give more helpful error messages if they fail, use for example NetworkManager.

Indeed, I'm not using networkd anymore. And it was just an example, the phenomenon exists all over systemd. So basically, you're saying that systemd et al integrate with everything on my system, except for when it's useful?

No, I say that networkd is not the right tool for every usecase. For some it is nice, for others not.

Not that different from other tools like `ifupdown`, `NetworkManager`, `wicd`, `connman`, ...

Re: Systemd Sucks, Long Live Systemd

#187
post #132

Earlier quoted context omitted.

The idea of systemd isn't bad. What's annoying is the friction involved in using it. It's just a shade too ornate, a little too magical, in both cases only by a small degree, but it's an important one. Creating a workable systemd init script is actually pleasant. Getting it running is easy. Checking for errors with status is nice, but searching the logs is annoying. pm2 ( https://github.com/Unitech/pm2 ) has a neat f…

I'm not sure how you could write this with a straight face. Systemd has friction, but writing init scripts doesn't? Are you kidding me? Have you ever had to write init scripts for production servers? Writing systemd unit files is entirely more straightforward and simple than any init script hackery. And how is "journalctl -u sshd -f" not straightforward? Systemd has its issues sure, but your comment is pure FUD.

Ad hominem aside...

"journalctl -u sshd -f" is not straightforward because it's a _redundant_ new command when I already know grep and tail. Small tools handling text is a wonderful way to make a system easy to learn and powerful to use, and we're just throwing that out.

Re: Systemd Sucks, Long Live Systemd

#188

Earlier quoted context omitted.

Who said the unit philosophy was the be-all, end-all? Unix doesn't even believe it's own philosophy because it's too damn painful. Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? Unix is just a collection of random decisions made by various people over the years. The Unix philosophy is really more like "I've always done it that way so don't you dare change i…

"The C compilation model of separate header files is not a good design" This is probably just your lack of experience not having worked on 50+ million LOC compiling for 12 hours and not having anything else as a better option. There is a reason these things exist.

For as long as C has existed, other languages have provided alternatives where symbol information is extracted from the main source files automatically by the compiler and optionally cached for next time, or if you don't want to ship users of a library source, for example. In other words: This has been solved in a better way since the 70's.

Re: Systemd Sucks, Long Live Systemd

#189
post #132

Earlier quoted context omitted.

The idea of systemd isn't bad. What's annoying is the friction involved in using it. It's just a shade too ornate, a little too magical, in both cases only by a small degree, but it's an important one. Creating a workable systemd init script is actually pleasant. Getting it running is easy. Checking for errors with status is nice, but searching the logs is annoying. pm2 ( https://github.com/Unitech/pm2 ) has a neat f…

I'm not sure how you could write this with a straight face. Systemd has friction, but writing init scripts doesn't? Are you kidding me? Have you ever had to write init scripts for production servers? Writing systemd unit files is entirely more straightforward and simple than any init script hackery. And how is "journalctl -u sshd -f" not straightforward? Systemd has its issues sure, but your comment is pure FUD.

Given that astrodust was mentioning "systemd init script" I'd think they are praising unit files and just got the terminology "wrong"...

Re: Systemd Sucks, Long Live Systemd

#190
post #166

Earlier quoted context omitted.

Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.

OTOH, sharing code between different components developed under an umbrella project is not bad per se - if they require the functionality, re-implementing it from scratch for each component would not be a good idea, either. Duplicating and manually syncing the code also has its share of problems.

But this tends towards Windows model, not a form of UNIX-like model. If I wanted a Windows-like, I'd use a Windows.
Post reply on HN