Live data from Hacker News

Why I dislike systemd

steven-mcdonald.id.au

61–70 of 254 posts

Re: Why I dislike systemd

#61

I don't "hate" systemd either, I just think it's a bad approach. It flies in the face of the "open architecture" concept and stifles innovation. It discourages users from learning about how their operating system works, and it unnecessarily puts too much control of a fundamental component of the OS in the hands of a too-small number of people. None of these reflect the Linux I grew up with. Thus, I am not a fan of sy…

Interesting way to think about it.

IMHO systemd is taking much of the hacks and weird glue that has historically held distributions together and replaced it with an active upstream project. Maybe some of the solutions they've come up with could need some improvements, but I have much higher confidence those improvements would happen now compared to how things used to be.

Nowadays you can code something up and come to the systemd mailing list and get feedback and get it integrated. Previously you'd have to convince one or more not-really-connected distro hackers that your new fancy thing is worth rocking the boat for.

Re: Why I dislike systemd

#62
> nearly everyone (or at least the most vocal crowd) seems to either love it or hate it

"At least the most vocal crowd". Which means that most people DO NOT CARE, and the systemd war is beyond ridiculous.

As Linus said, > "I don't actually have any particularly strong opinions on systemd itself."

Re: Why I dislike systemd

#63
post #31

Am I missing something? The author states: > Try to find the answer to "which units are going to be started on next boot?". Isn't this just `ls /etc/systemd/{user,system,network}/ /*` (bah HN formatting is messing this up) Also the other states: > Speaking of which, why is systemctl daemon-reload even a thing? Because configuration changes while things are running. Otherwise we wouldn't need apache2 reload, nginx rel…

> Isn't this just `ls /etc/systemd/{user,system,network}//*` (bah HN formatting is messing this up) Nope. There are many virtual units for which there are no files. One example is the on-demand getty units. There are two for "plymouth" boot-splash stuff (I see these attempted-and-failed units on archlinux where plymouth never exists). There's some autofs thing. There's auditd. I'm actually not booted into linux right…

Couldn't/Shouldn't this be solved with some script that traces the dependencies of units?

I'm not familiar enough with systemd to understand how to trace dependencies and create a complete list of all units that will run at next boot but I expect this to be doable by someone with that expertise.

Re: Why I dislike systemd

#64

There is something epically beautiful about OpenBSD's consistency over the last 10 years. I swear that a 2004 OpenBSD sysadmin would be close to 100% efficient with a circa 2015 OpenBSD system, despite the absolutely massive number of improvements and changes that have been made with the operating system. Once systemd starts to get traction, it's cognitive overhead is going to become a real problem for sysadmins who…

Except that there's no reason for systemd's model to "get traction" outside of desktop-focussed Linux distributions, since a "better user experience" is it's current raison d'etre. So no, I shouldn't need to have to "learn to trust the operating system / systemd" on my servers -- it has no reason to be there!

The model where services do not daemonize and write a pid to a file is actually hugely better for servers. Most of the rest of it is not useful.

Re: Why I dislike systemd

#66
post #50
post #33

Earlier quoted context omitted.

> I'm one of the people who jumped ship to OpenBSD in the last year or so. Ha. FreeBSD here. And so long as you get the right hardware, I find BSD to be far simpler than linux distributions out there. Ports? Beautifully elegant and simple. Configurable. Magnitudes easier than configuring rpm/debs. Getting a package approved in debian? Alioth? No offense, the wiki, all these pages on the debian website - they have no…

I've occasionally used {Net|Free|Open}BSD over the past few years (in fact, I think my Jornada in the back of the closet still runs NetBSD). I kept sticking to Linux partly because I was using it at $work, partly because it was simple enough and I'm kindda lazy. But yeah: > I find BSD to be far simpler than linux distributions out there. The way OpenBSD handles WiFi configuration is a good example of this. Want to co…

While I don't disagree that wpa_supplicant has been spawned from hell, I find it strange that the existence and popularity of NetworkManager is given as a clue for why {Net|Free|Open}BSD is better. You know, connecting to a WPA protected Wifi network is not the only problem users have. For example, another one would be connecting to a VPN, a task that NetworkManager greatly simplifies, assuming that such integration is available of course (e.g. if you think connecting to a Wifi network is problematic, try connecting to a L2TP over IPSec VPN).

There's also the issue that the simplicity exposed in your example is a little misleading. Will the system persist that command and re-execute it on boot? Will it remember my previously used Wifi networks and connect automatically should I want that? How can I view the available Wifi networks in range? Being able to connect to a Wifi network using a simple ifconfig command is great, but the notion that your 80% of use-cases is the same as everybody else's 80% is misguided at best.

> If I ever need them -- OH THE HORROR AND THE BLASPHEMY -- I have a Windows laptop, which for all intents and purposes is by now about as closed and as hard to wrestle with as Fedora

And therein lies my problem with your entire comment. It's not that I disagree with your usage patterns, but I disagree with your assertions in light of these usage patterns. So you're saying that xBSD is simpler / better, yet you can't use it on your laptop, as it lacks things you need. Well, no shit.

Re: Why I dislike systemd

#68
post #59

Earlier quoted context omitted.

What I think your getting at is that essentially you need a mechanism to commit your changes before the thing that's reading those changes receives them. In essence, an atomic operation for the change. Completely agree.

I'm hearing "we need to build a version control system or a transactional database into our init daemon" here :)

Version control systems and transactional databases are built over atomic operations. Transactions in particular refer to having multiple operations that either succeed or fail all at once, making in essence atomic operations composable (they normally aren't).

Editing a file and saving it multiple times is not an atomic operation, but reading a file can be, so having the user issue a reload command only after he's finished editing a file is an entirely reasonable approach that has been used in Linux since forever and it only shares some basic building blocks with version control or transactions, but there's nothing fancy about the approach. Fancy and very error-prone would be to apply configuration changes automatically, which is what the article seems to suggest.

In other words the joke is lame :-P

Re: Why I dislike systemd

#69

I don't "hate" systemd either, I just think it's a bad approach. It flies in the face of the "open architecture" concept and stifles innovation. It discourages users from learning about how their operating system works, and it unnecessarily puts too much control of a fundamental component of the OS in the hands of a too-small number of people. None of these reflect the Linux I grew up with. Thus, I am not a fan of sy…

Definitely disagree with that. I've been using some form of a Linux based OS since 1998. Now i'm finally starting to feel like this is #mylinux.

Re: Why I dislike systemd

#70
post #59

Earlier quoted context omitted.

What I think your getting at is that essentially you need a mechanism to commit your changes before the thing that's reading those changes receives them. In essence, an atomic operation for the change. Completely agree.

I'm hearing "we need to build a version control system or a transactional database into our init daemon" here :)

I assume the next version of systemd will include git.

Actually, it's not that bad an idea:

    cd /home/efaref/config/servername
    vim blahd.service
    git commit -m "Update blahd service file to increase widget count"
    git push live master
Then have something else watching the master branch of the live repo do a git pull, systemctl daemon-reload. It doesn't even have to live on the same server. If one of the config files is a puppet script, you can maintain everything.
Post reply on HN