3 ms·

PulseAudio also drew a lot of disapproval, until Pipewire appeared and finally did the same thing (and more) well. Maybe systemd (service management, logind, t

by nine_k 1y ago

PulseAudio also drew a lot of disapproval, until Pipewire appeared and finally did the same thing (and more) well. Maybe systemd (service management, logind, the DNS resolver, the loggig system, etc) will eventually be re-implemented in a way that does not have the irritating properties of the original systemd. /* I'd say that systemd feels like typical corporate software. It has a ton of features to check all the requisite boxes, it's not very ergonomic, it does things the way authors wanted and could sell to the corporate customers (who are not the end users), not the way end users prefer. It also used to be bug-ridden for quite some time, after having been pushed upon users. It comes from Red Hat (which is now a part of IBM), so you could say: here's why! But, say, podman also comes from Red Hat, and does not feel like such corporate software; to the contrary, end users enjoy it. */

dralley 1y ago
Pipewire also comes from Red Hat FWIW
- NewJazz 1y ago
  And maybe people didn't hate Pulseaudio because it came from red hat? But maybe people hated red hat after they pressured gnome to depend on it?
  - dralley 1y ago
    Maybe Red Hat didn't actually "pressure GNOME to depend on it", and that's mostly a meme?
    - nine_k 1y ago
      Rather, Gnome stopped supporting ALSA directly around 2007, and Firefox did the same in 2017. Yes, you could use alternatives like JACK or sndio. The point was that a new Gnome broke the reliance on ALSA, as a user, you had to migrate off ALSA which you likely had used for a decade before. Naturally, most users migrated to the best-supported option, the distro's default, which was Pulse Audio both on Fedora and Debian.
WhyNotHugo 1y ago
> Maybe systemd (service management, logind, the DNS resolver, the loggig system, etc) will eventually be re-implemented in a way that does not have the irritating properties of the original systemd. One the topic or an eventual successor, one of the aspects of systemd is how intertwined all of it is. It’s really hard to replace just one part without either (1) replacing it with another which the same general design, or (2) remove all of systemd entirely. Take what op is taking about for example. Instead of relying on small, reusable components for sanboxing, it just re-implement all of it into the monolithic service_manager+service_supervisor_sandboxer+… You can’t even think of replacing the service supervisor or the logging subsystem without replacing all the other parts. Of course, I won’t deny that this design has its upsides: this monolithic approach ships a lot faster than trying to integrate different components to work together.
egorfine 1y ago
> it does things the way authors wanted And let's not forget that the author of systemd is very well known for his arrogance and explicit hatred towards unix philosophy.

by nine_k 1y ago

dralley 1y ago

Pipewire also comes from Red Hat FWIW

NewJazz 1y ago
And maybe people didn't hate Pulseaudio because it came from red hat? But maybe people hated red hat after they pressured gnome to depend on it?
- dralley 1y ago
  Maybe Red Hat didn't actually "pressure GNOME to depend on it", and that's mostly a meme?
  - nine_k 1y ago
    Rather, Gnome stopped supporting ALSA directly around 2007, and Firefox did the same in 2017. Yes, you could use alternatives like JACK or sndio. The point was that a new Gnome broke the reliance on ALSA, as a user, you had to migrate off ALSA which you likely had used for a decade before. Naturally, most users migrated to the best-supported option, the distro's default, which was Pulse Audio both on Fedora and Debian.

WhyNotHugo 1y ago

> Maybe systemd (service management, logind, the DNS resolver, the loggig system, etc) will eventually be re-implemented in a way that does not have the irritating properties of the original systemd. One the topic or an eventual successor, one of the aspects of systemd is how intertwined all of it is. It’s really hard to replace just one part without either (1) replacing it with another which the same general design, or (2) remove all of systemd entirely. Take what op is taking about for example. Instead of relying on small, reusable components for sanboxing, it just re-implement all of it into the monolithic service_manager+service_supervisor_sandboxer+… You can’t even think of replacing the service supervisor or the logging subsystem without replacing all the other parts. Of course, I won’t deny that this design has its upsides: this monolithic approach ships a lot faster than trying to integrate different components to work together.

egorfine 1y ago

> it does things the way authors wanted And let's not forget that the author of systemd is very well known for his arrogance and explicit hatred towards unix philosophy.