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

Avoiding Complexity with Systemd

mgdm.net

Post reply on HN
Print view View original

201–210 of 357 posts

Re: Avoiding Complexity with Systemd

#201

Post by _d7dt »

bayindirh wrote: post #95
idoubtit wrote: post #71

Earlier quoted context omitted.

I doubt answering rants is useful, but I'll try to give factual counter-arguments. > there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years of typing cat /etc/resolv.conf systemd-resolved is not enabled by default in Debian and many distributions, and it is not needed in any way by systemd. If you don't like it, don't use it! Your rant does not sound very serious. Did you real…

This would be a comment with two parts. First one will be counterarguments, second will be a generalized response. Please bear. Part One: --------- > systemd-resolved is not enabled by default in Debian and many distributions, and it is not needed in any way by systemd. If you don't like it, don't use it! It's not possible to ask systemd about which parts are enabled and up to which extent. It always adds a discovery…

>There was a thousand ways to do that before systemd, systemd added yet another way. It's not bad, but it was not novel in any way.

The difference here is that systemd actually went to the individual distro maintainers and listened to their concerns, made the necessary changes, and convinced them all to adopt it. That's damn hard to do in the Linux world, I commend anyone who can do it successfully.

Regarding your part 2: For whatever reason, there is an absurd amount of misinformation posted whenever systemd comes up. If you posted something that was wrong about some other service manager, I would correct that too. You deserve to know the right answer to things, for your sake, not for the sake of systemd (or any other program). Please don't dismiss attempts to correct misinformation as being unproductive, it's the flame war which is the unproductive part.

Re: Avoiding Complexity with Systemd

#202

Post by regularfry »

spinax wrote: post #161
WesolyKubeczek wrote: post #77

For me, systemd is the best thing since sliced bread. As a programmer, I now don't need to care about dropping privileges, managing logging, daemonization (the moment I need to do the double-fork dance again, chairs will be flying, I swear), dropping into a chroot, and do half-arsed guesses "is it up and running yet?" from a convoluted mess of shell code that looks like a bunch of hair stuck down a drain for a month.…

As a systems guy with a focus more on ops, I agree. It's not all roses - journald/journalctl and binary logging can go die in a pit of fire for example - however setting LimitNOFile= in a unit is just really, really nice (as well as CPU limits and all sorts of other cgroup/namespace needs). But let me just mention again that journald/journalctl can go die in a pit of fire - if it wasn't for everyone adding rsyslog to…

> journald/journalctl and binary logging can go die in a pit of fire for example

This is, of course, not a problem, because as systemd folk are wont to point out, systemd is not, in fact, monolithic, meaning they use well-defined interfaces and can be swapped out for an alternative.

Re: Avoiding Complexity with Systemd

#203

Post by lanstin »

midasuni wrote: post #13
Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

The key Unix skill isn’t typing cat /etc/resolv.conf but strace -f -ff -o /tmp/1 -p 33333 to figure out how your DNS resolution is occurring. Maybe it is the traditional way, maybe some code is configured to use a network placed resolver. You can find out.

Re: Avoiding Complexity with Systemd

#204

Post by Nextgrid »

stefanha wrote: post #48

Recently I have been wondering if systemd solves problems that are becoming less and less relevant to developers. New services are often deployed as containers. While systemd has a bunch of container-related functionality, it does not integrate well into the Kubernetes or even Docker workflow. It's used very little in those environments. If you are building CoreOS or NixOS system images, or traditional Linux system s…

Containers might be popular in startups' "pay five figures a month to $CLOUD_PROVIDER" scene when VCs rain infinite free money, but there are still plenty of occurrences where you have to deal with old-school physical machines where it's often easier to just run the software on the bare-metal rather than using Docker and yet another layer of abstraction.

Re: Avoiding Complexity with Systemd

#205

Post by zxzax »

zozbot234 wrote: post #178
eesmith wrote: post #144

Earlier quoted context omitted.

I know so very little of systemd as it doesn't touch anything I do. I can pattern match that https://blog.darknedgy.net/technology/2015/10/11/0/ - "Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise" from six years ago (Discussion at https://news.ycombinator.com/item?id=10370348 ) might be relevant. Are those points reasonable? Dunno. If so, have t…

https://blog.darknedgy.net/technology/2020/05/02/0/ is a 2020 post from the same blog, pointing out that these issues basically remain unaddressed. But again, this is not just some "anti-systemd" talking point; the pro-systemd side also acknowledges this! They just think sysv-init was even worse.

I honestly would like to see a better service manager than systemd, but just my opinion from following development of these things: a huge reason why it can't happen comes from underlying deficiencies in the kernel, and with Unix. The real core issues can't be addressed without a large amount of changes there, which are outside the control of a service manager.

Re: Avoiding Complexity with Systemd

#206

Post by generalizations »

ageofzfarm wrote: post #189
generalizations wrote: post #175

Earlier quoted context omitted.

> But system init is a hard, complex problem. It's not. Read the shell scripts that openbsd uses to init. Simple, straightforward, easy to understand.

The complexity is buried in the huge work the OpenBSD devs make to keep the kernel and the base system small, elegant and consistent. I read your comment more as a tribute to the excellent work of the OpenBSD team than a denial of the thesis of the complexity of the init process.

> The complexity is buried in the huge work the OpenBSD devs make to keep the kernel and the base system small, elegant and consistent.

>> You can’t create a simple solution for that, since there is an inherent complexity.

They didn't bury the complexity, they removed it. And I agree, that's hard to do. It'd be nice if the systemd folks put in the same effort to remove the complexity from their system.

Re: Avoiding Complexity with Systemd

#207

Post by CGamesPlay »

In the TLS example, how does systemd handle certificate rotation? Are the certificate files symlinks, hard links, or copies? If hard links or copies, presumably my service will need to be signaled or restarted to get the new certificate; does systemd do this?

Re: Avoiding Complexity with Systemd

#208

Post by regularfry »

theranger wrote: post #113
kzrdude wrote: post #41

Earlier quoted context omitted.

yes, people forget that we are a village. Contrary to “popular misconception”, Linux is not a settler's freehold where every holdout makes their own rules. Admins have to work with a diversity of systems. They can choose how to setup new ones, but they have to work with a range of them. What everyone does has an effect on everyone else. If some distro introduces a new way of doing things, it has some chance of ending…

So the admins should really not rant about systemd but complain about the distributions who switched to systemd or about their employers who force them to use such distributions.

More than one thing can be bad.

Re: Avoiding Complexity with Systemd

#209

Post by zxzax »

josephcsible wrote: post #138
bonzini wrote: post #130

Earlier quoted context omitted.

It's not a hard requirement, GNOME still runs on the BSDs.

Thankfully, sanity eventually did prevail in GNOME (just related to this matter, not in general), but there was a period of time where systemd absolutely was a hard dependency,

I'm not sure what period you're alluding to, but if that did happen, it seems it happened because things stalled on the BSD side, not because of any changes in GNOME. Can you please elaborate what you mean? I'm interested to get a BSD developer's view of the history, but I've only seen a few vague blog posts on this matter.

Re: Avoiding Complexity with Systemd

#210

Post by cout »

sseagull wrote: post #134
5e92cb50239222b wrote: post #128

Earlier quoted context omitted.

A thoughtful comment downvoted into oblivion without any explanation. Classic HN. I too don't get the hate that binary logs receive. They aren't any harder to work with than text logs. journalctl makes it easy to read logs from an offline system, too. The compression it automatically provides saves a lot of space across our machines. I know that it can be achieved without binary logs, but does any popular distributio…

I think the argument is really about transferablilty of skills. I already know how to manipulate compressed files because I have to do that in other places. And once you realize logs are just text files, I can immediately transfer all my skills of dealing with text files to dealing with logs. But now I have to learn another set of tools (or at least another command to convert it to text files). It's not really a huge…

I think this is exactly it. Journalctl doesn't resemble any tools I already know, so I have to look up how to use it each time. Binary logs aren't the problem; we have had those for ages (e.g lastlog). I just wish journalctl were a little more familiar.
Post reply on HN