> Of course they don't actually have a credible alternative, yet again.
runit just works for me, even on systems with complicated pieces.
systemd gives me problems even on completely vanilla ubuntu installs, much less on arch etc.
I'd suggest that systemd is closer to a non-credible alternative.
@_emacsomancer That's fair, I suppose I should have been clear that I mean a credible alternative for myself, which would be something that at the very least uses a declarative service definition syntax, rather than shell scripts
I have a real problem with initscripts in that their quality and functionality/implementation varies and depends on the scripting skills of whoever wrote the scripts, perhaps the software dev themselves.
In my view .service files are superior here.
@_emacsomancer systemd also takes care of the likes of logind & udev, with other systems either depending on logind or ck, (which is unmaintained), but that's not as big a consideration as the shell scripts angle for me.
@MatejLach But this is the system working they way it should, no? In Unix-like systems, pieces should be somewhat interchangeable, and so re-using logind is that model working. I just wish other systemd components were more modular.
@MatejLach Though, as I recollect, there has been significant downstream work (from Guix, Void) on making elogind work without systemd, so it's not all benevolent systemd maintainers' work trickling down or anything.
@_emacsomancer I guess. My only problem is that the very same people who complain about systemd picking too much up end up re-using one of the major components which they said shouldn't have been included, while at the same time themselves not maintaining consolekit, nor providing an alternative to logind from scratch.
I don't mind it, but I am glad somebody, (be it systemd), started taking care of it, rather than it just rotting.
runit works great for me and I use it more places, but shepherd has also treated me well and from a technical point of view, I find it more interesting than runit. I would think shepherd services could be defined in more declarative ways.
Shepherd's definitely the one out of the bunch I want to look at. I am planning to take a deep dive into Guix/GuixSD, which presents a nice tie in opportunity to look at Shepherd as well.
I just didn't have much reason to look into it as systemd does the job for me, but Guix is defintely on my radar.
@MatejLach As far as I can tell, Guix System (née GuixSD) is the only place where Shepherd is really well integrated, so that would be the place to play with it.
But the standalone Guix package manager is also quite cool. You can nicely integrate on top of another distro (and I do), rather like a Snaps/Flatpak replacement to get software your distro doesn't provide or to act as a fallback for borked packages.
Guix even provides a systemd unit to start the daemon ;)
Is this about AMD's Zen 2?
@Sturmflut It was a different thread on HN, (about the inevitable death of X.org), this seems to be a kernel-level issue? Or at least driver related for sure.
@Sturmflut On related note, I hope this gets resolved soon, Zen 2 looks really on point, but am on Arch so unless this gets resolved, I won't be able to jump on it.
@MatejLach I bought a Ryzen 1600X just after launch, took ~4 months until all microcode/kernel/OS/chipset/firmware bugs had been resolved.
With the current state of Zen 2 - more recent distros crashing, completely new boards, some board firmwares already known to have problems, major compiler and library upgrades necessary to fully use it - I will wait until at least Christmas before an upgrade. Maybe even until Ubuntu 20.04 goes into Beta.
@MatejLach Now that the core issue has been found, Arch and the rest will probably have fixed this before your Ryzen 3000 is in the mail. I hear they're sold out in most places.
@MatejLach Some reports suggest downgrading to systemd 237 makes affected distros boot. Some reports suggest the exact kernel version matters as well.
At least one report mentions they can smh maneuver a working system into a state which will suddenly make it crash after a warm reboot.
Affected distros also seem to crash in VirtualBox if hardware virtualization is enabled. So it's most likely not a chipset issue.
Surprised AMD didn't fix this yet, reviewers have had the CPUs for ~3 weeks.
Hi there! I am a free software developer. I enjoy working on useful software, as well as advocating for software freedom and the use of open standards, promoting data ownership, decentralization and privacy. If this is important to you, I may be worth following. If you like Go, Rust, or Swift, it may be worth following me as well. Besides computing, I enjoy metal, a good read and occasionally some gaming, (not much time for that these days).