Email or username:

Password:

Forgot your password?
Top-level
Ariadne Conill 🐰

@dysfun pulseaudio failing to route audio doesn’t mean that pavucontrol wasn’t a well designed mixer 😂

47 comments
extreme organic gay

@ariadne lol maybe you'd like to bring up avahi while we're going through his greatest user interface innovations 😬​

Ariadne Conill 🐰

@dysfun avahi doesn’t have any UI of its own, it hooks into gtk and qt file choosers. distributions also misconfigured avahi in many cases. i can’t actually put that one on him because i’ve seen how the sausage was implemented.

extreme organic gay replied to Ariadne Conill 🐰

@ariadne it has a dbus interface. i'm not very fond of dbus either.

Ariadne Conill 🐰 replied to extreme organic gay

@dysfun i mean, same? but that ship sailed well before lennart entered the picture

jade replied to Ariadne Conill 🐰

@ariadne @dysfun it also replaced ... CORBA. and I don't think anyone missed CORBA.

Rich Felker replied to jade

@leftpaddotpy @ariadne @dysfun And it was all modelled on COM by folks who thought Windows was doing things that made sense...

Ariadne Conill 🐰 replied to Rich

@dalias @leftpaddotpy @dysfun well, DCOM really, which is an entirely different animal

Rich Felker replied to Rich

@leftpaddotpy @ariadne @dysfun There is really a clash of two *philosophies* here:

One that believes software systems should be tightly coupled with every piece of software interacting with the events and data of one another, mediated through object oriented abstractions.

And one that believes software should be decoupled, staying out of each other's way and exchanging data and reacting to events only through standard data formats and system interfaces.

Rich Felker replied to Rich

@leftpaddotpy @ariadne @dysfun The former is largely seen as "polished" and "professional looking" and "user-friendly" by techies and industry UX folks.

But it also enables a lot of really user-hostile behavior.

Raito Bezarius replied to Rich

@dalias @leftpaddotpy @ariadne @dysfun Can you cite user hostile behavior of systemd?

Rich Felker replied to Raito

@raito @leftpaddotpy @ariadne @dysfun The post you're replying to is not even particularly about systemd. It's about systems where software is tightly coupled.

One obvious place it ends up being user hostile is in the presence of low-trust or untrusted applications which get visibility into what other applications you have running and what you're doing in them (Android), partly via the IPC/RPC system.

Raito Bezarius replied to Rich

@dalias @leftpaddotpy @ariadne @dysfun why tight coupling cause what you're describing?

Ariadne Conill 🐰 replied to Rich

@dalias @leftpaddotpy @dysfun i don’t think this really applies to systemd. you can just use the parts you want, without the others. you can even replace the parts you don’t want with other implementations. all of that is possible.

it just happens to be a bunch of projects worked on by the same people in a monorepo with a unified release schedule, but the projects are actually fairly independent of each other.

Rich Felker replied to Ariadne Conill 🐰

@ariadne @leftpaddotpy @dysfun Is it actually possible to run systemd the service manager without systemd the udev controller that decides how it wants to rename all your devices?

Sertonix replied to Ariadne Conill 🐰

@ariadne
@dalias @leftpaddotpy @dysfun
I don't see the independence:

To replace udev with a different device manager you need libudev-zero in most cases. Even then udisk2 and other don't work since they rely on udev internals (source libudev-zero).

Ariadne Conill 🐰 replied to Sertonix

@sertonix @dalias @leftpaddotpy @dysfun the fact that libudev-zero exists kinda proves my point. yes, if you are reimplementing an API, then you have to reimplement the API. i know, shocking.

Rich Felker replied to Ariadne Conill 🐰

@ariadne @sertonix @leftpaddotpy @dysfun I was only aware that you could use libudev-zero as a udev replacement on a non-systemd system, not that you could opt not to use the systemd-integrated udev behaviors on a systemd-based system. I'm still not convinced the latter is practical unless someone demonstrates it.

Sertonix replied to Ariadne Conill 🐰

@ariadne
@dalias @leftpaddotpy @dysfun
If you want to replace mdev/mdevd/smdev with udev you don't need to create a mock for any software.

And even if you need an api libseatd has shown how to do it right: allow multiple backends.

If libudev would work ok when udev isn't running it could be considered independent.

Ariadne Conill 🐰 replied to Sertonix

@sertonix @dalias @leftpaddotpy @dysfun yes, we all agree that seatd is better.

that was never the point. i have never said systemd is architecturally correct.

i just ponder if this is the issue that we need to focus on, considering we have been trying to replace openrc for years and have not made any tangible progress on doing so.

the graphical environments have, in large part, chosen to follow the systemd APIs.

the implementations of those APIs we provide are largely based on extricated code from old versions of systemd which are not kept up to date with the newer APIs requested by the graphical environments.

therefore, given that we are sinking resources into keeping these stub implementations going, and the stub implementations are deficient, which requires further hacking around at the graphical environment level to keep things working, one must ponder whether it is worth the resource cost to keep openrc (itself barely maintained) and the various forms of extricated systemd code (ranging from not maintained to barely maintained) alive.

how does alpine benefit from this effort, which takes a lot of effort and results in a suboptimal user experience in many cases?

is the benefit that we can say “we don’t use systemd, we’re proud of that”? and if so, how does that talking point make alpine better? because we don’t use systemd? a silly and circular argument, i think.

it is like the people who are upset that X is losing maintainer interest while Wayland is gaining maintainer interest. but they aren’t interested in stepping up and doing the work to keep X as a viable alternative.

the anti-systemd crowd offers the same flavor of argument: here is a bunch of random projects stitched together, and while it works for the proposer, it is more like a 60% solution rather than the 100% solution the proposer sells it as.

oh, you can just avoid systemd with these little tricks! nevermind that when you do that, half the control panel settings in Plasma and GNOME don’t work, because the systemd APIs they call via dbus are just stubbed out.

an interesting observation in this thread is that nobody has advocated to keep openrc. but i have heard about all sorts of projects included in the systemd monorepo that we would never actually use, like systemd-boot or resolved.

interesting that.

@sertonix @dalias @leftpaddotpy @dysfun yes, we all agree that seatd is better.

that was never the point. i have never said systemd is architecturally correct.

i just ponder if this is the issue that we need to focus on, considering we have been trying to replace openrc for years and have not made any tangible progress on doing so.

Thomas Depierre replied to Ariadne Conill 🐰

@ariadne @sertonix @dalias @leftpaddotpy @dysfun As someone that is one the server side, the total lack of service manager that seems to have understood the problems we deal with is... fascinating. Systemd is definitely the easiest to work with and the one with the most hooks we need. It does have sooooo many issues, both in UX and in implementation (and code quality) but at least it... works and allows us to do the job

Thomas Depierre replied to Thomas

@ariadne @sertonix @dalias @leftpaddotpy @dysfun Would I love something better and have ideas for it? Sure. Do any of us have the time and expertise and money to build something better? Nope. Same reason we are stuck with autotools and make....

jade replied to Thomas

@Di4na @ariadne meson, cmake, and others exist and make my life as a packager and developer much less bad. well, cmake is about on par for packaging suffering as make. but still, they're way nicer to write and use.

on the other hand, bazel exists and has caused hours of pain every time I've touched it. but so is the case for googleware of any kind.

Kevin Karhan replied to Ariadne Conill 🐰

@ariadne @sertonix @dalias @leftpaddotpy @dysfun

Because #OpenRC, like #SysVinit and #Xorg are dead ends.

The only reason why anyone ever made #SystemD and #Wayland is because after literal decades of pain and suffering some folks said: "This is junk!" and invested the monumental effort of replacing already neglected Software that barely functioned with something that does!

Were the predecessors of systemd and wayland not #unmaintainable and bordering on #Abandonware before, neither of those would've seen adoption!

But long-term the best solution wins, and SysVinit as well as X11 were just pulled from #Unix-esque systems that predated #Linux, because back then noone had the time.nor resources nor patience do do something better.

Otherwise we would've gotten systemd and wayland way earlier...

youtube.com/watch?v=o_AIw9bGog

@ariadne @sertonix @dalias @leftpaddotpy @dysfun

Because #OpenRC, like #SysVinit and #Xorg are dead ends.

The only reason why anyone ever made #SystemD and #Wayland is because after literal decades of pain and suffering some folks said: "This is junk!" and invested the monumental effort of replacing already neglected Software that barely functioned with something that does!

Tionisla replied to Kevin

@kkarhan @ariadne @sertonix @dalias @leftpaddotpy @dysfun

Hmmh, depends. If you want your project to be portable to other system platforms like e.g BSD/Unix, relying on linux-only/centric solutions could be problematic.

Sertonix replied to Ariadne Conill 🐰

@ariadne
@dalias @leftpaddotpy @dysfun
I think trying to implement all/most systemd interfaces for compatibility is not the way forward.

Actively developing better designed software and push the use of it is.

And most importantly explain how to use it! The Alpine Wiki tends to include "use this systemd component and it just works(TM)" instead of "you have a choice. One might not work but you can help to improve it here".

Sertonix replied to Sertonix

@ariadne
@dalias @leftpaddotpy @dysfun
If enough people are aware of/develop libudev-zero they would be able to fulfill their actuall goal: Create a libary that supports multiple backends.

27329ed9-2211-a1ba-9371-e2641bf0dcb6 replied to Sertonix
@sertonix never heard about libudev-zero before.

Thank you for mentioning it.I had to patch out udev dependency from kmscon few weeks ago. A stub/minimal implementation would've been ideal there, but I didn't knew about it.
jade replied to Rich

@dalias uhhhhh

> software should be decoupled, staying out of each other's way and exchanging data and reacting to events only through standard data formats and system interfaces.

"standard data formats". do you mean "text", for which you have a "broken handrolled C parser full of CVEs" because it's not actually structured *or* standard? or is there some magical format I have forgot about?

dbus is a standard data format. the systemd-standardized interfaces are a standard, structured format.

Rich Felker replied to jade

@leftpaddotpy Um, you're reading some weird ideas you had in your head into what I said...?

jade replied to Rich

@dalias every time I see people accusing systemd of not using the standard APIs, the so-called standard APIs in question did not exist before, and the functionality was, prior to systemd, achieved by the client software mutating things in such a way that assumes they were the only possible client (e.g. /etc/resolv.conf with VPN software, vs under systemd-resolved)

I simply do not understand your argument.

Rich Felker replied to jade

@leftpaddotpy The post you replied to was not even about systemd. It was about dbus, CORBA, DCOM, OLE & DDE, etc.

Petr Menšík :fedora: replied to jade

@leftpaddotpy @dalias oh, systemd-resolved handling of /etc/resolv.conf is great example how to do it wrong way. Yes, there was maybe resolvconf only, hackish command. But because no other service claimed to be best #DNS cache everyone should use. I am quite confident resolved is broken. It supports only itself, unlike other solutions. Okay, it has decent dbus API. But also unfixed issues. Systemd has excellent integration skills, but fails to export it for use by 3rd party services.

Rich Felker replied to Petr Menšík :fedora:

@pemensik @leftpaddotpy Nobody actually wants resolv.conf to get rewritten based on what network they connect to, with a garbage ns serving fake results with ads injected. They want it statically pointed at 127.0.0.1, 8.8.8.8, or something they trust. That something *should* be on 127.0.0.1, with full dnssec validation & efficient upstream querying, which systemd kinda tried to do, but botched...

Petr Menšík :fedora: replied to Rich

@dalias @leftpaddotpy that depends. If systemd is preventing some features like dnssec or single label queries, then I want working resolvers instead. Statically configured servers won't know site-specific domains. Sure, you want to override DNS servers network has provided *sometime*. But you would want privacy VPN on such networks anyway, if you need to use that network at all. I get broken experience even on trusted networks with resolved.

Rich Felker replied to Petr Menšík :fedora:

@pemensik @leftpaddotpy VPN UX on Linux is just messed up. We now have the tools to do it right (user+net namespaces with their own localhost & own ns running on it with no access to outside-vpn network), but are doing it still with fragile hacks messing up global system network config. 🤦

Petr Menšík :fedora: replied to Rich

@dalias @leftpaddotpy I am not sure, why would you want to lock a process into separate namespace with a VPN. In most cases I *want* site-enabling VPN to modify *global* system configuration. I just want to choose which parts this VPN can provide, for example limiting it to only selected domains. It would be nice to have simpler ways to bind a service to just one network interface, but I don't need it often.

Rich Felker replied to Petr Menšík :fedora:

@pemensik @leftpaddotpy I was speaking more with sn assumption of a privacy providing VPN where you don't want any traffic to leak. But a site-enabling VPN also makes sense to scope only to processes meant to have access. A compromised nobody account shouldn't have access to VPN your user account has access to.

Petr Menšík :fedora: replied to Rich

@dalias @leftpaddotpy I think general assumption is once local machine is compromised, security falls apart. I would say untrusted nobody user (and it's services) should have filtered access to the system network. Especially if you run a code without trusted source from it. Sort of podman solves it. Okay, it would be nice to restrict domains and IP ranges such process can access. I don't know anything simple offering that.

Rich Felker replied to Petr Menšík :fedora:

@pemensik @leftpaddotpy If that's true, sounds like really, really bad news for most Android users...

Petr Menšík :fedora: replied to Rich

@dalias @leftpaddotpy who said VPN server on Android cannot filter out ads or unwanted traffic? I think iptables should be able to filter based on userid or pid. I admit it would be great for flatpaks also. Name resolution usually does not have user or pid information for each request, it would have to use Unix socket instead of IP+port domain. So it would be difficult to apply ACL on those. But having alternative DNS cache on non-default address would be simple.

Petr Menšík :fedora: replied to Rich

@dalias @leftpaddotpy Android apps have good sandbox from other users. Each app is separate user there. Unless given rights to media access, they are well separated. Except network and DNS, correct. I would not expect Google to make ads blocking trivial task for obvious reasons.

Petr Menšík :fedora: replied to Rich

@dalias @leftpaddotpy what I thing we miss is a good implementation of provisioning domains RFC draft, well integrated with the system. And proper support for site-specific domains (discovery), not ~example.com hacks in dns-search.

jade replied to Rich

@dalias @pemensik i think you may have missed the real point of systemd-resolved here:

you no longer have different vpn software tampering resolv.conf and breaking your DNS queries when you change networks (e.g.). resolved proxies even bad software like gpg that ignores NSS into hitting the VPN DNS server for only VPN stuff and the network one for others. there is literally no standard way to do this besides everyone having the same DNS proxy, which has APIs, on their computer.

Rich Felker replied to jade

@leftpaddotpy The dbus protocol framing/transport is a "standardized data format". The addresses you interact with over it are *explicitly named for application software* that you're communicating with. And forget about whether it's standard or not, it's not even a data format. It's a command channel.

Rich Felker replied to Rich

@leftpaddotpy What I mean by "standard data formats" vs tightly coupled applications goes back to the early Windows idea of "inserting a paintbrush object" into your Word document rather than "inserting an image file in BMP format". Or the early Mac idea of resource forks identifying an "owning application" for a file rather than the data format of the file.

Αλαιν Φογτια Αννα Εμιλια

@ariadne @dysfun pulseaudio is okayish (although I don't appreciate that pavucontrol just regularly appears to segfault on my systems, in contrast to pulsemixer)

but PipeWire is awesome (although the APIs are a bit of a mess (at least messier compared to both JACK and PulseAudio))

Be

@ariadne @dysfun I still use pavucontrol regularly with Pipewire-Pulse 🤷

Go Up