| ▲ | travisgriggs a day ago |
| This actually is kind of cool imo. There are things I like about systemd, and things I don’t. And this seems to fit much more closely around the things liked. Wish I had the time to play more with it on Linux. Would love to see Debian switch to something like this. Always felt like Debian was stuck between “all in” or “go without”. This would have been a nice middle ground choice to have had back in those days. |
|
| ▲ | cf100clunk a day ago | parent | next [-] |
| > Always felt like Debian was stuck between “all in” or “go without” Debian can be configured at installation to go ''all in'' with systemd or ''go without'' if you prefer. The latter option pretty well mooted the purpose of the Devuan spinoff. In the Bullseye version it is possible to change a running system from using systemd to sysvinit or OpenRC. I agree about seeing how Debian reacts to how InitWare develops from alpha. |
| |
|
| ▲ | ape4 a day ago | parent | prev | next [-] |
| Yeah, I thought systemd relied very heavily on Linux-native things like cgroups. |
| |
| ▲ | netbsdusers a day ago | parent | next [-] | | Systemd uses groups for two things: for tracking processes other than direct children of the service manager, and for imposing resource limitations. Both can be done with other mechanisms, like kqueue's EVFILT_PROC and login classes respectively. But my experience in any case was that hacking up systemd to build and run under BSD it didn't need cgroups at all for basic running. Supervision of `Type=simple` and `oneshot` services worked fine. It wasn't particularly surprising to see this as cgroups really aren't ideal as a tracking mechanism - under cgroups v1, you only had a "cgroup empty" notification available as far as tracking the lifetime of processes within a cgroup, and even that was unreliable and could be left undelivered! So systemd used them to augment a more traditional process supervisor. That's why Pottering insisted on having it be PID 1, and got subreapers added to Linux for the per user systemd instances so that they could get the more traditional SIGCHLD based notification of process exits. | | |
| ▲ | o11c a day ago | parent [-] | | Okay, but ... if you only get something that seems to work, but isn't actually reliable, what's the point? You seem to be wrong about cgroup v1; freezing works and is sufficient to reliably kill all children. Half-killed services was one of those really annoying problems back in the dark ages of sysvinit (not the most common problem, but perhaps the hardest to detect or deal with when it did come up). | | |
| ▲ | netbsdusers a day ago | parent [-] | | I'm saying that it did work perfectly fine and reliably for the common case of types oneshot and simple services. To expect it to work for type Forking services would be absurd since no mechanism would exist to even try to keep track of them. It's just a point to illustrate that systemd is not as intimately and irretrievably integrated with Linux features as some imagine. Freezers were never used by systemd as part of its process tracking mechanism. And cgroup emptiness notification was unreliable under cgroups v1. So that's not wrong. It used some horrible mechanism where a binary is launched (!) when the cgroup becomes empty. And that can fail to happen under situations of low memory availability. Related read is Jonathan de Boyne Pollard on cgroups:https://jdebp.uk/FGA/linux-control-groups-are-not-jobs.html | | |
| ▲ | o11c a day ago | parent [-] | | My point is that a lot of apparently "simple" services do in fact call fork internally. Just a few things I've seen: * fork to periodically make a snapshot of server state, to avoid slowing down the main server * spawn an external gzip to compress a log file * spawn a handler for some file format * spawn a daemon to actually handle some resource, which might be used by other processes too (this really should be a separate managed service, but in the anti-systemd world this is often not the case) If everything is working fine, you'll only waste a bit of server RAM for a few seconds if you fail to kill the children alongside the parent. But the circumstances in which you want to restart the service are often not "everything is working fine". |
|
|
| |
| ▲ | sunshine-o a day ago | parent | prev | next [-] | | This is what I was wondering when I searched and found this project: was systemd designed in a way it would inevitably leave behind the BSDs? Because we always assume the BSDs rejected systemd but it might just be that they were put in a situation where they had no choice. | | |
| ▲ | netbsdusers 11 hours ago | parent | next [-] | | The idea of using a third party init system has always been quite alien to BSDs, the sames goes for almost all other Unix-like systems, which are almost all developed with a greater deal of integration within the core system. Linux is exceptional in this respect, that it has ever had a diversity of init systems. This war of words between the BSD community and systemd, as far as I've been able to tell, dates back to when Poettering went to the GNOME mailing list to propose making GNOME depend on systemd. He made this request with the proviso that it shouldn't necessarily be a hard dependency, so that needn't have been a problem in itself, but then he made a remark in an interview with linuxfr.org: > I don't think BSD is really too relevant anymore, and I think that this implied requirement for compatibility with those systems when somebody hacks software for the free desktop or ecosystem is a burden, and holds us back for little benefit. and as you can imagine this was ill-received by the BSD community. Could systemd, or at least a useful subset of it, have been made cross-platform from the get-go? It would've taken more work. I don't think the amount of work necessary would have been particularly onerous, which I hope InitWare shows. It would have required making certain compromises like systemd being happy optionally running as an auxiliary service manager rather than as the init system. In the end, though, Poettering has his preference to target GNU/Linux only, and he is entitled to that. | | | |
| ▲ | SoftTalker 21 hours ago | parent | prev [-] | | The BSDs are not in competition with Linux so there's really no concept of being "left behind" |
| |
| ▲ | zokier a day ago | parent | prev [-] | | They implemented their own cgroups-like thing with fuse https://github.com/InitWare/CGrpFS |
|
|
| ▲ | markstos a day ago | parent | prev [-] |
| Yes, I much prefer this more nuanced take of "here's some things I like about systemd and here's some things I don't" then the blanket "everything about systemd sucks" feedback. I wish this project well. I hope it improves compatibility with BSDs for more projects. |
| |
| ▲ | skyyler a day ago | parent [-] | | "everything about systemd sucks" people generally don't understand the problems that systemd is attempting to remediate, in my experience. Just repeating dogma that they heard someone they consider cool say. | | |
| ▲ | toast0 a day ago | parent [-] | | Or perhaps, we don't have the problems that systemd is trying to solve. Or systemd creates new problems that we didn't need or want. Kind of like pulseaudio. | | |
| ▲ | FeepingCreature a day ago | parent | next [-] | | Yeah pulseaudio was like "you need this so you can have two apps playing music at the same time" entirely ignoring the existence of sound cards with mixers or the alsa soft mixer. Similarly, systemd was hyped at the time for, among others, allowing parallel service start entirely ignoring the several init systems that were already managing parallel start quite happily. | | |
| ▲ | GauntletWizard a day ago | parent [-] | | This turned out to be entirely the right approach, though, and it was probably pretty obvious even at the time. Sound Cards with built in mixers have all but died out. Everything they did has been eaten by software, Even at the time, few games used an API where they managed multiple channels directly; Software mixing was commonplace from the 90s. Any game that wanted to play battle sounds was not relying on the mere 6-8 channels that cards from that time could handle. Our modern Pipewire based workflow is remarkably simple and remarkably effective, and it's significantly an evolution of PA. | | |
| ▲ | skyyler a day ago | parent [-] | | I find it indicative of the quality of these complaints that sound cards with mixers were brought up at all. As if that's a good reason to hate PA. | | |
| ▲ | FeepingCreature 19 hours ago | parent | next [-] | | No, I hate PA cause it didn't work properly to the end. (Pipewire was better day 1 than PA ever was.) I just think that "you absolutely need PA to have multiple apps playing sound" was always nonsense, and the same sort of nonsense that was used to push systemd. | | |
| ▲ | toast0 19 hours ago | parent [-] | | Yeah, that was total nonsense. Good cards existed. And if you didn't have a good card, alsa had a soft mixer. FreeBSD added a softmixer to OSS, too, so you didn't even need alsa. Worst case, you could run the Enlightenment sound daemon without Enlightenment and it was compact and just worked (as long as you had a simple sound setup) |
| |
| ▲ | GauntletWizard 19 hours ago | parent | prev [-] | | I'm always happy to discuss sound cards with mixers, though! As a supporter of the Bloop Museum[1], I think that the "What might have been" if we had dedicated hardware for playing dozens or hundreds of sound files at a time is an interesting question. There's a lot of experimentation in the audio space that has kind of died out, because audio is so cheap - While over in in graphics, we're still seeing interesting advancements and dead ends. [1] https://oldbytes.space/@bloopmuseum |
|
|
| |
| ▲ | jeroenhd 16 hours ago | parent | prev [-] | | I do. systemd solves a lot of my problems, actually. Of course all of systemd could be cobbled together by combining a dozen or so independent projects, but that mess is exactly why normal people (even normal computer people) shy away from Linux. And I don't recall a lot of software working well when Pulse isn't available, so I don't know why people still bring it up. Perhaps it's because I wasn't there at the time, but I've only seen ALSA as "that audio system you use when you have nothing else available". I still need the PulseAudio-wrapper for Pipewire to be useful for my systems, so clearly the Linux world has moved to Pulse-first. |
|
|
|
