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

Systemd 250 Released

lwn.net

Post reply on HN
Print view View original

161–170 of 204 posts

Re: Systemd 250 Released

#161

Post by totony »

zeec123 wrote: post #125
totony wrote: post #112

Earlier quoted context omitted.

Redhat made the scripting for you. I don't think it's that complicated of a script (although it would be easier with a retry command) sleep $random for i in 1 2 3 4; do backup && exit 0 sleep 15m done logger "backup failed" exit 1 add script to @startup in crontab or whatever they use. You can use another wrapper that only execute it if the backup is newer than now-24h. Backup could even be remote and you could track…

No, you are maybe 80% there. - Your logger does not send a mail with the restic logs to me. - How do I check that the backup is newer than 24h? I have to make sure the last backup succeeds. - Do I have to touch a file in /var for every backup script? When do I touch it? After the backup run, before? What if I shutdown my laptop during the backup? These corner cases take exponentially more time to get right than the f…

Well it's not a hypothetical solution, the script is probably about the same length as the timer config.

I used logger because it's better practice to log and for the logger to send email, you can send email using the mail command or msmtp. The timing was omitted because it is trivial and didnt serve to illustrate the point, just do backup && touch /var/lib/lastbackup && exit 0, with a if at the start of the script like if [ -x "$(find -mtime -1 /var/lib/lastbackup)" ]

The mid-backup shutdown is a property of the backup script, you'll have to consider that even using systemd.

Sadly there are not many distros without systemd. Everyone is strained in resources and Redhat is pumping money into the ecosystem, so it's really easy to take over most of it. Like I said I don't dislike systemd, I think it adds value, but it's just not the best solution since it does not integrate with others well.

EDIT:

>You don't like systemd, then do not use it and move on.

But this is the issue with systemd: you can't. Want gnome? needs dbus, which needs logind which is systemd. Need libvirt? also needs dbus. Need Y? Needs systemd-tmpfs, which packages the whole systemd as a dependency. Same thing for systemd-udev.

The interlock is so brutal most distros are forced to switch because they can't handle the dev burden.

Re: Systemd 250 Released

#162

Post by Maursault »

starklevnertz wrote: post #9

I just want to pre-empt the inevitable bitching about systemd to say I think it’s awesome and incredibly useful and consistent and powerful and I’d take it any day over the mess of stuff that filled systemd’s duties before. Sure it isn’t perfect, but what software is? And let me ask a question, if systemd is crap, why does every major distro use it? If it was truly crap then surely the distro builders would use the a…

> And let me ask a question, if systemd is crap, why does every major distro use it?

Won't find systemd in Gentoo, Slackware or Alpine. Also it is a little interesting, just a little, that whatever imperative systemd has to exist is entirely absent in every SysV and BSD, and yet variants of SysV and BSD and thier hybrids still exist, somehow, no worse for the wear.

Re: Systemd 250 Released

#163

Post by kaba0 »

fsflover wrote: post #128
3np wrote: post #18

Earlier quoted context omitted.

I don’t follow how a new startup/system management architecture makes it “not UNIX”. We do put OS X in the UNIX column, after all. POSIX and all that.

https://en.wikipedia.org/wiki/Unix_philosophy Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. AFAIK none of these describes systemd.

Do you browse the web like `curl | render-http`? UNIX philosophy is not a law. For complex problem domains separating it into multiple parts is not always possible and only makes the whole thing more complex. System init is quite a complex problem domain.

Re: Systemd 250 Released

#164

Post by kaba0 »

Woodi wrote: post #123
ChuckNorris89 wrote: post #14

Earlier quoted context omitted.

Would anyone care to explain to someone who isn't 1337 in the inner workings of Linux, why systemd makes modern Linux not very UNIXY anymore and why everyone seems to hate it to death?

Like someone already answered systemd started as init replacement "to make Linux boot faster" - that was PR pitch. But then it consumed many system services like logging, time, logging in, hardware detection, network, mounting, audio, GNOME, etc etc. That alone is enough to clearly state systemd is bullshit. Everything is now interdependend and it is realy hard to replace some parts of it like eg. udev - decade old s…

Systemd was never meant for “making init faster” - it was meant to making it correct and maintainable. That’s another added benefit that actually getting the boot dependency ordering correctly allows for parallelism beside many other benefits which will make it faster.

Also, your listed “features” are bullshit: logging in, audio, GNOME, etc have absolutely nothing to do with systemd. Even logging can still be forwarded to any log tool you would like, but having it implemented inside is a sane choice — you have to start taking logs when there is not even a file system available. You know how was it solved in the pre-systemd days? It was simply ignored!

System init is a very complex problem, systemd only gives you the essential complexity for the task.

Also RE poweroff speed: there is a single flag you can toggle to either kill lingering processes (which is usually not enabled because some hacky tools like tmux likes to live in the background and systemd killing it is bad) or wait a bit before. So yet again, systemd does the correct thing while before these were simply killed.

Re: Systemd 250 Released

#165

Post by kaba0 »

davydm wrote: post #37
ggm wrote: post #24

Earlier quoted context omitted.

It used to be process 1 was init, and it forked/exec'd everything else typically from /etc/rc (this elides over a lot) -its the first binary the kernel runs. Everything else stems from the birth of user process number 1. Fork/exec is the lightweight process inheriting of open i/o and memory state with copy-on-write which made Unix a joy to work with. It's a delightful mapping of kernel and userspace into complex inhe…

consistency ftw: https://news.ycombinator.com/item?id=29670751 gimme open-rc or gimme death actually, sysv was fine too open-rc solves the parallel-startup desire for people who want a faster boot and doesn't hide logs in binary formats which can only be interrogated with specialised tools - my primary reason for leaving Debian-based systems that I'd used for 16 years was having systemd forced on me and trying to dea…

Because using journalctl is so bad.. Hell, you can even forward to a text-based logger. And it’s not like it is some proprietary format either

Re: Systemd 250 Released

#166

Post by kaba0 »

lmm wrote: post #158
kaba0 wrote: post #152

Earlier quoted context omitted.

Why was it chosen by debian multiple times with the most democratic process out there?

It was forced through by breaking the rules of the process and overruling the committee that should have made that decision. Many old-school Debian maintainers quit in disgust at that point, so if subsequent votes have been in systemd's favour then that's probably why.

Some source would be interesting, because it is just blind words otherwise. Also, Arch and several other distros made the choice independently. I am fairly sure Red Hat is not some evil entity kidnapping the families of maintainers making them switch to systemd..

Re: Systemd 250 Released

#167

Post by thefz »

mst wrote: post #52
42jd wrote: post #30

Earlier quoted context omitted.

As someone who has learned Linux/Unix just the past few months using a systemd based distro, I find it a breeze to use. Great documentation, FOSS, and really easy to pick up. I just don’t understand why there is so much dislike thrown around when that energy can be focused elsewhere on truly bad behavior/software. And from my understanding, there are distros out there that don’t use systemd for those who dislike it t…

I'm an old school unixhead who's nonetheless made his peace with systemd because, honestly, it makes lots of things work way better than most previously available solutions did. Thing is, it also forcibly changed a bunch of things by introducing defaults that were not at all what people expected. They might have been better overall, but it still caused some nasty surprises. Let me try and explain a bit more concretel…

> SystemD changed that behaviour to "if a filesystem doesn't come up, and you don't set an option to tell systemd it's ok if that doesn't happen, don't finish booting".

I still have to find a way to let it digest sshfs filesystems that may hang at boot without stopping the whole boot process.

Re: Systemd 250 Released

#168

Post by fsflover »

kaba0 wrote: post #163
fsflover wrote: post #128

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Unix_philosophy Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. AFAIK none of these describes systemd.

Do you browse the web like `curl | render-http`? UNIX philosophy is not a law. For complex problem domains separating it into multiple parts is not always possible and only makes the whole thing more complex. System init is quite a complex problem domain.

I browse the web using Firefox, i.e., extendable browser with a huge number of plugins. Unix philosophy is not a low. It's a rule helping to make computing understandable, robust and extendable.

Re: Systemd 250 Released

#169

Post by tpoindex »

davydm wrote: post #37
ggm wrote: post #24

Earlier quoted context omitted.

It used to be process 1 was init, and it forked/exec'd everything else typically from /etc/rc (this elides over a lot) -its the first binary the kernel runs. Everything else stems from the birth of user process number 1. Fork/exec is the lightweight process inheriting of open i/o and memory state with copy-on-write which made Unix a joy to work with. It's a delightful mapping of kernel and userspace into complex inhe…

consistency ftw: https://news.ycombinator.com/item?id=29670751 gimme open-rc or gimme death actually, sysv was fine too open-rc solves the parallel-startup desire for people who want a faster boot and doesn't hide logs in binary formats which can only be interrogated with specialised tools - my primary reason for leaving Debian-based systems that I'd used for 16 years was having systemd forced on me and trying to dea…

You want MXLinux - Debian with just enough systemd to work in a modern environment but with SysV init. https://mxlinux.org

> not to mention 5-minute shutdown times

5 minutes? Try total hang on shutdown, and often not starting up. That was my systemd experience. I traced it down to a NFS mount that no amount of tinkering would mount reliably pn boot. Granted that was several years ago, but soured me on systemd.

Re: Systemd 250 Released

#170

Post by esarbe »

guywhocodes wrote: post #151
esarbe wrote: post #120

Earlier quoted context omitted.

While PA in the beginning certainly wasn't manna from heaven, it still was a godsend; pulseaudio exposed all the inconsistencies, flaws and straight out bugs in the alsa driver implementations. The reason so many people had issues with PA was not PA but the brokenness of the underlying system that PA exposed for the first time when trying to use all these drivers in a systematic way and build functionality on top of…

I'm grateful we got a reasonable system out of PA eventually but damn it took time and I agree it is today better than what we had with ALSA. But as I remember it audio sucked with ALSA until it didn't and then we had about two good years of audio before PA came about. Then we had 8~ years of crap again and yes a lot of it was definitely due to really bad drivers and masked inconsistencies in the past. That's not my…

> in fact it at first pushed us back A LOT

That argument I don't quite follow. Would you consider rephrasing it? My question is; how did PA set back Linux sound if it did expose all those flaws in the audio driver in the first place?

Post reply on HN