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

231–240 of 357 posts

Re: Avoiding Complexity with Systemd

#231

Post by lanstin »

mananaysiempre wrote: post #131
Nursie wrote: post #114

Earlier quoted context omitted.

> 1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses. What other system is there, right now, that can do this so well? I'm definitely onboard with the issues around tight coupling, I'm really not a fan of binary logs etc. But the unit files are pretty awesome IMHO. So serious question - what else does those as well or better?

In addition to s6 itself, the author of s6 also wrote a survey https://skarnet.org/software/s6/why.html > that provides a good large-scale view of the design space. (My gripe with how systemd does a traditional init’s job is mostly the unit and dependency types, all of which AFAICT are specified in terms of actions on state transitions, not consistency conditions on states, so for all that it has a positive boatload…

I stopped reading when they started attacking bind. Sheer ignorance. Also cathedral is good for him and his elite team but not in general?

Unix has always been worse is better. You may disagree but it is the secret sauce. YAGNI for that potentially ideal system. Sadly. I like mathematically solid systems but the people with good enough systems explore the solution space much quicker.

Re: Avoiding Complexity with Systemd

#232

Post by a1369209993 »

knorker wrote: post #149
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…

I don't think it's that people are warming to systemd. It's more that there are two kinds of people now: 1. People to young to remember stable software. 2. People who have given up, and just accepted that Linux too "just needs a reboot everynow and then to kinda fix whatever got broken". systemd has normalized the instability of shitty system software. And just like how you don't see front page news every day about 1…

3. People who realized that the FOSS community they were originally so happy to have found - of people who actually care about writing software that works, rather than user-hostile malware designed around profit margins - effectively doesn't exist anymore, and refuse to update their software anymore at all because they know that recent versions are unusably broken, to the point of requiring "a reboot everynow and then to kinda fix whatever got broken".

Re: Avoiding Complexity with Systemd

#233

Post by diragon »

drran wrote: post #76
siraben wrote: post #7

Earlier quoted context omitted.

In NixOS it's trivial to use and define NixOS modules, which handle restarting/starting/stopping systemd units. See the wiki example[0] on how to define and use a service that greets the user with GNU Hello. Also, since you have access to Nixpkgs, you can make the ExecStart as complicated as you want with whatever dependencies you desire, and trivially share it with others. [0] https://nixos.wiki/wiki/Module#Example

It looks like NixWay of doing NixThings to solve NixProblems. Why I need NixModules in the first place? ELI5, please.

It's an academically more impressive version of Ansible that's deeply intertwined with the distro's package manager.

Re: Avoiding Complexity with Systemd

#234

Post by josephcsible »

bkor wrote: post #219
josephcsible wrote: post #138

Earlier quoted context omitted.

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,

> Thankfully, sanity eventually did prevail in GNOME (just related to this matter, not in general) You've rewritten history to pretend you're right. Then you follow up with more drivel? Sorry, aside from trolling, what is your point?

> You've rewritten history

This seems pretty clear that GNOME used to depend on systemd. How am I rewriting anything? https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd#Pa...

Re: Avoiding Complexity with Systemd

#235

Post by josephcsible »

bkor wrote: post #221
josephcsible wrote: post #142

Earlier quoted context omitted.

> I know that it can be achieved without binary logs, but does any popular distribution implement compression out of the box? Are you saying that since distros don't optimally configure a program out of the box, we should scrap and replace the whole program instead of just fixing its default configuration?

> we should scrap and replace the whole program instead of just fixing its default configuration? Loads of distributions assisted that upstream works out of the box with systemd. That way the work is shared across distributions. Not sure why you make such a strange suggestion. Loads of work has been saved thanks to systemd. So much more is shared across distributions it's kind of crazy to look back.

I was talking about rsyslog there, not systemd.

Re: Avoiding Complexity with Systemd

#236

Post by josephcsible »

bkor wrote: post #214
josephcsible wrote: post #119

Earlier quoted context omitted.

What does this have to do with job policies? Systemd was forced down our throats by Red Hat adding hard dependencies on it to other software under their control, e.g., GNOME. Other distros then adopted systemd under duress, since many of the packages that Red Hat made depend on it are important to the Linux ecosystem, and the other distros didn't have the resources to fork them all.

> Systemd was forced down our throats by Red Hat adding hard dependencies on it to other software under their control, e.g., GNOME. Other distros then adopted systemd under duress What utter drivel. I've participated in the discussions around systemd in various distributions. There was a huge amount of discussion, then one by one distributions switched. Some quickly, some took various years. Again, some distributions…

> That you can only say things such as "forced down our throats" and "duress" says enough. Not capable to actually hold a discussion, let's be emotional and without any actual facts.

Does this sound any better? Red Hat used their influence over GNOME (and other programs) to add a hard dependency on systemd to it. This forced other distros to either switch to systemd or drop support for GNOME. I suspect that had Red Hat employees not added hard dependencies on systemd to any other software, that no distributions other than Fedora and RHEL and its clones would require it.

Re: Avoiding Complexity with Systemd

#237

Post by spinax »

zxzax wrote: post #213
spinax wrote: post #211

Earlier quoted context omitted.

System Ops (at scale, large company, lots of teams) in a nutshell: you did not build the system or choose what kind, it was most likely installed using vendor defaults by the systems owner and you were called in because it's misbehaving. Most likely 50 other people have touched various parts of it, some with skill some without. "Give me an IP, username and password - what OS is it?" are about all you start with and g…

Ok so complain to the ops department that they need to unify their logs. That's their problem, not yours. If the company is big I would expect them to be doing that anyway, either they coalesce around a journald-type thing that aggregates the logs locally, or they'll use another centralized service like datadog, splunk, etc. Edit: If you are ops then this is your entire wheelhouse, you should be able to solve it at s…

It has been my career experience that 5+ digit employee companies more resemble Chiba City than they do the USS Enterprise.

Re: Avoiding Complexity with Systemd

#238

Post by knorker »

throw-8462682 wrote: post #227
knorker wrote: post #163

Earlier quoted context omitted.

Agree with that. It breaks catastrophically. But it's also overengineered. Like starting a daemon on first connect is "neat trick", but should never have gone beyond that. Like: oh, I want to restart this daemon, because I want it to re-run its init code (possibly with new settings), but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart"…

Starting a daemon on first connect is essential for fast boot times of a system with multiple dependent network services. This is mostly a desktop use case though. Not sure if it can be disabled for servers.

But I would also like to see data showing how often desktop users reboot (on purpose, that is, not because systemd or something says "you should reboot now" because it's shitty software that doesn't just work cross updates).

Like, who even boots their computer anymore? Isn't the typical user on a laptop, and just suspends it?

My workplace even had to install corp software that forces a reboot every N days (with warnings ahead of time) because people just Do. Not. Reboot.

And even for the people that do, at what cost, here? You have a bunch of services and services completely broken, but "they started just fine" (except they didn't start), and only break once you actually need them.

So to me this really looks like it applies neither to servers nor desktop. I'm really not seeing any use case except fetishizing boot times.

And for me this always SPENDS human wait time, not save it. I try to use a service, and nope, it needs to "boot up" first. Could you not have done that already, WTF? (and maybe it fails to boot, which I only find out about now that I'm already in the zone to use it)

Are we really optimizing for kernel developers, here? Can't they just disable the services they don't need, to speed it up?

And we have eleventy billion cores now. Really? You can't start a 645kB gpsd? It takes what, 3ms?

Re: Avoiding Complexity with Systemd

#239

Post by dec0dedab0de »

geofft wrote: post #104
einpoklum wrote: post #100

Earlier quoted context omitted.

1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses. 2. Some of the systemd logging is binary, so good luck with that if there's a problem. 3. Have you tried non-systemd init systems other than sysvinit? 4. Yes, it is convenient when everything below your development is cenrtalized by a single entity. It can easily provide a consistently useful underpinning. But…

I really don't understand the scenario where binary logging is a problem. journalctl is a command just like, I dunno, gzip, and people are fine with gzipped logs. If something goes horribly wrong with your system, you're not looking at logs with an oscilloscope, you're looking at logs by mounting the disk on some other working OS - whether it's the initramfs, or a live CD, or whatever. You can run gunzip (Not to ment…

Say the computer writing the log was destroyed, you were able to recover the storage, but the only computer available did not have journalctl.

Or if you're writing to network storage and would like to analyze the logs from your haiku box.

Text is not perfect, but it's the one thing that is always available.

Also I'm not sure about the journalctl format, but in general binary formats don't handle partial corruption well. Which is something kind of important for logs.

Re: Avoiding Complexity with Systemd

#240

Post by zxzax »

josephcsible wrote: post #234
bkor wrote: post #219

Earlier quoted context omitted.

> Thankfully, sanity eventually did prevail in GNOME (just related to this matter, not in general) You've rewritten history to pretend you're right. Then you follow up with more drivel? Sorry, aside from trolling, what is your point?

> You've rewritten history This seems pretty clear that GNOME used to depend on systemd. How am I rewriting anything? https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd#Pa...

That's not a full picture, apparently that was due to some specific problem in Gentoo: https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...

AFAIK the GNOME Wayland session still depends on logind, but that's more because there has been no interest in getting it to work on BSD yet.

Post reply on HN