Email or username:

Password:

Forgot your password?
Top-level
Sertonix

@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).

12 comments
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 :verified: 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 Karhan :verified:

@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.

TSource Engine Query 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.
Go Up