Hi all, I'm just wondering why is Artix using eudev (which is also lacking behind udev) instead of something like skarnet's mdevd (https://skarnet.org/software/mdevd/) or suckless's nldev (https://core.suckless.org/nldev/)/smdev (https://core.suckless.org/smdev/) (with mdev-like-a-boss (https://github.com/slashbeast/mdev-like-a-boss)) combined with KISS's libudev-zero (https://github.com/illiliti/libudev-zero) or the BSD's libudevd-devd (https://github.com/FreeBSDDesktop/libudev-devd)/libudev-fbsd (https://github.com/jiixyj/libudev-fbsd)?
Is it not possible? I've heard KISS managed to get a working Xorg/Wayland setup with libudev-zero, shouldn't this also be possible on Artix?
In general, Artix tries to be as Arch-compatible as possible, only removing systemd.
I've managed run Artix with nldev+smdev for a long time (you can search -noudev packages in AUR which i've created for it, i've also created a topic "Udev alternatives in Artix"). It is possible but there are some drawbacks:
1) kbd xorg driver is used. It worked fine for me on x86_64 machine but on arm64 only basic keys worked on my keyboard with it (even arrow keys didn't work). I've forced evdev driver for keyboard in xorg.conf but this breaks hotplug capabilities
2) recently i've found that scanner doesn't work w/o udev
However, i've used nldev with stock libudev, maybe other implementations can solve issues.
At some point i've tried to create some tool to send libudev messages but this wasn't enough
That's nice, did you document your journey, or is it just a bunch of scattered posts?
Also I think if you've gone with mdevd (with mdev-like-a-boss) and libudev-zero you would've gotten xorg, wayland and libinput to work.
The main aspects are reflected there. In general, nldev, smdev (reconfigured) and init scripts (openrc/runit) are also on AUR. I've rebuilt xorg to make it work but this didn't work for wayland. Maybe i'll return to it in future and check if libudev-zero solves the problems
There is also a xudev alternative in the repos, which is extracted from systemd source, ie its systemd's udev standalone.
Maybe with mdevd (+ mdev-like-a-boss), s6 and libudev-zero, it'll finally be possible to come up with a working alternative.
How is xudev any different from eudev?
I've tried to read (lib)udev sources to get the idea about what's wrong. To me it seems that in order to make udev alternative work one has to provide libudev events and udev database to libudev clients. So, i think correct libudev (and maybe some triggered script) should do a trick and then it will be possible to do with any alternative
Exactly, and libudev-zero should fill that gap nicely and could finally enable us to use other alternatives, but I've yet to see anyone test it thoroughly other than KISS (and it's working fine for them).
Maybe you could try experimenting with libudev-zero, mdevd/nldev/nlmon/nltrigger/smdev, and s6?
It would've been easier to say that they're two different things...
If I understood correctly, then xudev is closer to upstream (or is the upstream udev) compared to eudev which is lagging behind.
systemd has udev in its source tree. You can actually build udev by itself without any systemd. That's what xudev is. eudev is the gentoo fork.
Why is artix using eudev then and not xudev?
Because when we started it wasn't possible to separate udev from systemd: it wouldn't run without being PID1. And I bet it still wouldn't be possible if not for the existence of eudev.
Now, since eudev is a Gentoo project, which is reliable (and because we don't exactly trust the systemd developers), eudev stays until further notice (i.e. Gentoo deprecates it). People in want of xudev can compile it themselves.
we provide xudev... is in our repo and I use xudev on m computer.
When did that happen? :o Sneaky artoo, one week ago.
Screw that, I'll stick with eudev... 8)
xudev is kind of byproduct of extracting esysusers and etmpfiles from systemd source, which are tiny programs, its all one build. ;)
One week ago? More like 3 months ago. Nous has a time machine :o
You're right, I only saw the latest - not the initial commit.
So xudev is udev + esysusers (or sysusers) + etmpfiles (or tmpfiles)?
How is xudev's esysusers different from esysusers and from opensysusers (same question for tmpfiles)?
No, xudev is just udev from systemd source tree. The thing is, xudev, esysusers and etmpfiles are built from same tree (i.e. one PKGBUILD for all these packages, but each is built separately)
So did you try libudev-zero 8) ?
Not yet. Most likely i won't till summer or even later
Once i have any success with it, i'll make a post in old topic
Exist no reason why we should drop udev. Udev is no evil (there is no reason just because systemd has absorbed it and is not a standalone version).
I'm not saying that udev should be dropped, I'm just asking why aren't there other alternatives provided.
Previously it wasn't possible to provide alternatives like mdev, smdev or nldev due to missing libudev but now thanks to libudev-zero it should be possible to come up with alternatives that could be provided in addition to udev/xudev.
I wish artix would provide support for mdev/smdev/mdevd/nldev/nltrigger/nlmon + libudev-zero/libudevd-devd/libudev-fbsd (that would be great :D).
That will be never happens, sorry.
That's what community is for. I think a better solution will be creating separate [noudev] repo (like already existing [universe]) once it will be proven to provide 100% working setup
why? due compatibily and building lot of programs you still need sources from udev...
who will maintain it and test that all program works correctly?
sorry, but we are enough busy :D
but someone who wants to play with it can easily create their own repo and offer it (outside the official repo) to other users.
Just then please start your own forum, where it will ask questions about non-functional and the like. :D
I thought universe is community-driven
As i understand, projects like libudev-{zero,fbsd,...} are created in order to get rid of using udev sources
[universe] is maintained by some of our team members and contains non-official packages of programs they use themselves and offered as a convenience to our users. Please, don't expect much support for it, but you can surely be more confident in it than using an unofficial user repository that's maintained by the NSA some unknown Arch user.
[universe] is no community-driven
repo and packages are our official, just this repo is created and maintaining on our second server (repos system, world, galaxy are on our first server)
Why was this marked as solved...
Because is solved 🤔 We need no more discuss about this. Eudev is still need and IF will exist another option, which will really works, we will use it, if that will be necessary.
Actually we have Eudev and xudev. Users can use every another alternatives what they want, but we they should not ask here if some not works. We provide no support for alternatives now... Because we need keep stable system 😉
You can play with alternatives so much how you like... But what we use in upstream is business of us and our developers.
If you are really interested to develop udev-free Artix, you can create custom repo with rebuilt packages or at least maintain corresponding packages in AUR
Btw, there was a topic with logind alternative recently, i think, these ideas can be merged in a single repo
That would be a good idea to put all of these alternatives in a single place so maybe one day we can group them together and get something working 8)
EDIT: Can you link to the logind alternative?
There is already a bunch of noudev (marked by this name) packages in AUR, you can maintain them. I didn't update some of them for a while since currently i can't test if they work
https://forum.artixlinux.org/index.php/topic,2269.msg15144.html#msg15144 (https://forum.artixlinux.org/index.php/topic,2269.msg15144.html#msg15144)
Thanks for the link, but it seems that seatd also uses elogind as a possible backend, which leads us to the same conclusion.
Guess there's no alternative other for now?
Any updates on this?
I digged a bit into libudev-zero code. It seems, if someone wants to use it, everything depending on libudev must be rebuilt against it. Also i don't like its design in terms of uevents processing: it uses inotify on some directory where these uevents are put by some extra program. The problem is that there is no mechanism to clean them. Maybe there can be more problems since i only checked the part responsible for hotplug.
Regarding the former, a separate repo(s) will be needed most likely for these packages (unless Artix decides to create libudev-specific packages). Regarding the latter, i have an idea to make alternative "backend" based on bus (https://github.com/maandree/bus/) but it will require patching also. This is no more than just an idea atm.
we tried seatd, unfortunately, as it stands, it doesn't seem very useful. brings more problems than it solves.
It seems, i was wrong about this. A small test in VM with libeudev replaced by libudev-zero (but eudev was still device manager) has shown that X can be started without any rebuilds. It even had mouse working (i didn't test keyboard but i'm sure it will work too) using libinput driver. This means libudev-zero at least provides info about already existing devices. I didn't test hotplug though but i think it will also work then.
it doesn't matter ... we don't plan to remove eudev / xudev, seatd is not an alternative, so there's not much to talk about. who wants to experiment can .. but only on their own computer. ;)
Well well well, looks like "eudev" is getting deprecated...
This looks interesting:
https://sysdfree.wordpress.com/2021/08/30/349/
Artix has already switched to systemd udev (or as it was called, xudev), though the package is still called "eudev" (likely for compatibility reasons). I was like "wait a minute, did I just get systemd'd?" when "Starting version 249.3-3-artix" showed up on boot today...
A somewhat recent commit allows uevents to be rebroadcast using Netlink, which doesn't pollute a directory while still allowing hotplugging to work. This requires special support in the daemon, though (skarnet's mdevd, for instance).
There is also helper script for other device managers. This update is already reflected in the corresponding AUR packages
WOW!!! I am new here, but if so much negativity is tolerated then I don't see why I would want to stick around. I actually installed artix so I can see all those things presented here working, or how far they are working.
From my brief experience I don't see what doesn't. And seatd works flawlessly for what it is intended to do.
We all work on our own computer or the one assigned to us at work, but we can still discuss what else we can do. Preventing people on the same system to discuss among themselves the modifications they like is key to having a healthy community.
This would be understandable in Fedora or Ubuntu talking about replacing systemd, but a non-systemd community to be that narrow minded it is unbelievable.
10 thumbs down for any such comments.
Close the door behind you please.
No point virtue signaling and being outraged by a post made by an inactive team member.
Worse, calling out someone (alium) who isn't able to respond is just cheap. This is the second time these jokers (or one person creating alt accounts?) are trying that.
Haven't seen alium for some time now. They guy is OK?
Looks like it:
https://github.com/alium (https://github.com/alium)
According to Artoo, Alium left due to changing circumstances and a lack of free time.
While perhaps sometimes a little abrupt in manner, which newcomers didn't always understand, I would often see when searching issues reported here that Alium had already listed bug reports and sometimes patches to fix them, so there was a lot more going on than you see in the posts here.
This is the off topic section, and Alium just stated a fact which is still basically true so far as Artix DEFAULT packages go - but not what you choose personally, do what you like and you are most likely going to get helpful advice and discussion on here if you did want to install some other "dev" and some on here have done exactly that.
I think one of the limitations is Artix has to retain some general compatibility with Arch packages and the AUR to meet the majority of the userbase's expectations.
Since alium is inactive, I will not publicly state private reasons, computers are not more important than loved ones, real living humans with a soul. In times of a scamdemic with enforced injections, maybe something to think about.
Locking the thread, since we switched to udev from systemd source for now, but still packaged as eudev