[SOLVED] what is going to happen now that eudev is not going to be mantained?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Having used systemd and learned some of it, the main thing I've taken away from it is that it makes simple things difficult/complicated. Sure, it works well and has many features, but I personally can't stand it. But hey, if there was ever constroversy about --gnu-longoptions, then I'm sure you will be just dandy using what should actually be called SystemD, because that's how everything is expressed there. Not only long options but capitalization as well.
Just wait until SystemD jails the mount command and becomes the imperator of that as well. You will use:
SystemD-Mount --partition-type=Ext4 --more-options=SomeOption /dev/sda1 /mnt
Building and packaging udev from the systemd sources is relatively trivial. I had done it long ago, and after looking at it and the other options, we switched to eudev since it appeared to be the best option. I've currently got udev-249 built, packaged, and running on a couple of test machines, and I suspect that we'll all discuss and weigh our options after 15.0 is released, and a decision will be made, and we'll go from there.
I don't know about anyone else, but this kind level-headed pragmatism and quiet authority based in experience, along with a complete absence of drama, is why I use and trust Slackware so much.
So thank you Robby (and Pat, and the rest of the team) :-)
You do have the source for the mount application. Most distro's provide their source code. Why couldn't you just compile it yourself and always have it at your disposal instead of having to use it through SystemD, if they do consume mount? That can be applied to any application consumed. E.g. cron
I won't explore that myself soon, rather try to steal Artix' implementation of dbus-broker coexisting with dbus' launcher for Slint as if I am right this allows to use dbus-broker without its own launcher (which needs systemd).
Last edited by Didier Spaier; 09-03-2021 at 09:13 AM.
All of this is fundamentally because a bad decision around deprecating devfs in the kernel was made. What is really needed to solve this problem correctly in my estimation is something like devfs + a proc/sys interface for registering event handlers; which could be binaries, scripts, or a unix socket to invoke with some defined set of args, or write args to in the case of a long lived process listening on the socket. Those things can be implemented by anyone or distro maintainers according to their needs, they just have to follow the basic interface spec. Actually you probably don't even need that - just supporting inotify on (devfs) /dev probably would cover it.
There is no reason the responsibility for creating the dev file system objects should have ever moved back outside the kernel once it was integrated, the kernel fundamentally has all the information needed and is the event source farming out the creation and destruction of device node objects to user space is dumb in the first place.
I'm probably putting out a minority opinion here, but if the simplest and easiest-to-maintain option (for Patrick, not necessarily for sysadmins, as that's a different discussion) is to adopt systemd, I say go for it. The Slackware team doesn't have the manpower to maintain complex software projects that have been deprecated by upstream.
Quote:
Originally Posted by ReFracture
Obviously I can only speculate but it has been my perception that Slackware as it has existed from the beginning only adopts major technologies as necessary...
From the 14.2 changelog:
Code:
Wed Jan 13 00:01:23 UTC 2016
Hey folks, happy new year!
After upgrading to BlueZ 5 recently, everything seemed to be working great,
but then it was pointed out that Bluetooth audio was no longer working.
The reason was that the newer BlueZ branch had dropped ALSA support and now
required PulseAudio. So with some trepidation, we began investigating adding
PulseAudio to Slackware. Going back to BlueZ 4 wasn't an option with various
dependent projects either having dropped support for it, or considering doing
so...
PulseAudio was the boogeyman for quite a while (not entirely undeserving of the reputation mind you), but there came a point where working around the decisions of upstream became impractical.
I don't believe this will be any different. If somebody else steps up to maintain eudev or fork and keeps the quality high, I could see us simply sticking with that.
Slackware lacking systemd likely has much more to do with keeping things simple than it does being part of some anti-redhat/systemd/Lennart crusade... if somebody wants a distro where that's a core philosophy then Devuan might be the ticket.
Personally I don't care if Slackware adopts systemd or not, all I care is that it remains a fully functional and stable operating system.
This is an interesting topic. As far as I am aware, the feeling in the Slackware camp was not that systemd was the Antichrist, moreoever that it was just, at this point, not necessary.
Should it get to a point whereby it becomes more trouble to avoid than to implement, I imagine it will be integrated. If [or when] that time comes, I will most likely move back to Slackware.
PV & co know what's best for the distro going forward.
Last edited by Lysander666; 09-03-2021 at 09:06 AM.
Please stop sd non-sd post. Will see eudev is dead or not. No reason for sd to discuss again. Most of us made their decisions long time ago.
I blame Debian actually. They are suppose to support generic tools, they could have supported all the init systems. It would only take a few big distroes to support these things, to force software generic support, but instead we are all headed for a route where software more and more will become and make dependent on an init system, and so generic functions will be lost, POSIX doomed etc etc.
Dunno about the stance on GNU, but I wouldn't be surprised if many wanted to replace GNU, possibly usurp it and so turn whatever is on top of Linux into another kind of monster like Android or something similar. When the time comes, I don't see that many will stand up for GNU and the principles of free software.
But, we always have FreeBSD, and perhaps Hurd to fall back on
... I mean just because even in worst case that nobody chooses to maintain it why wouldn't it continue to work just as it does?..
This is an excellent question--one that none of the subsequent posts in this thread have even attempted to answer. Now I don't know the answer myself, viz a viz eudev--perhaps enorbet's analogy comparing eudev to LILO is overly simplistic. (Perhaps someone who's more intimately familiar with eudev's source could provide these answers.)
In any event, enorbet's point is well taken: whether or not software has been "orphaned" has no bearing on said software's utility. Short of the software being outright broken, or incompatible with other things in its environment, why not keep on using it as-is as enorbet suggests?
Case in point: four of the five build scripts that I've submitted to SBo are for programs that have been "abandoned" for years. To wit:
zseal v1.0 (2016)
wordbiz v1.8.7 (2012)
xmms-cue v0.2 (2006)!
efax v0.9 (199?)
In spite of their age--and their "orphanedness"--all four carry out their functions the same today as they did the day they were released. (...and continue to do so on slack-current )
Nor am I alone. How many people are shunning the mtx package that Pat still includes in the "a" series, just because it hasn't seen any new development since at least 2009? (Hell, how many of us even need such an arcane piece of software to start with?) But I dare say, if you (or your job) utilizes such a machine (a robotic tape-changer,) you could give less than two flying sh--s whether the software is "maintained" vs. "orphaned." (As someone who has owned and operated such a machine, you guys can take my word on this point.)
So, enorbet's question stands, and I feel it deserves a straight answer--if anyone out there knows it. Perhaps the answer will be "no." Perhaps if eudev became "stuck" in time, it would cease to function--I really don't know, but I'm skeptical that that would be the case.
What I find weird here is that any application or even graphical desktop should depend in any way whatever on what init system you used. I mean, what has that to do with anything? init has only three uses as far as I can see: to get the system up and running, to shut it down, and to take parentage of orphan processes in between. What has that to do with using cups or gnome?
What I find weird here is that any application or even graphical desktop should depend in any way whatever on what init system you used. I mean, what has that to do with anything? init has only three uses as far as I can see: to get the system up and running, to shut it down, and to take parentage of orphan processes in between. What has that to do with using cups or gnome?
Nothing, but that's because systemd cannot be accurately described as just an init system, that's an old and tired viewpoint of what it is. systemd is an entire suite for system maintenance, providing means to accomplish a wide variety of tasks in a standardized manner (not say that hadn't been done already, it's just what it appears to be to me).. Gnome relying on it probably is borne from them appreciating the fact that can implement a function in one way with confidence that it will work on any distro using systemd.. which is most distros at this point.
At least that's my perception. Whether that's a good or bad thing is up to how hardcore you are about the unix/posix philosophy.
If there's one thing I wonder though, if Slackware adopts systemd will that simplify ktown and dropline gnome's work? (I presume dropline might not even need to exist anymore at that point since I believe it's whole point is getting it up and running without systemd).
Last edited by ReFracture; 09-03-2021 at 11:29 PM.
Reason: Bad english
Slackware will die if implement systemd by default, imo. This is the last bastion of the major distributions. Its loyal user base (and me, too) is even willing to put up with its certain inconveniences and roughnesses because of this. The distribution already has a lot of problems, and this will be another one:
- Small (but stable) user base, a little (but worthy) manpower and there are no prerequisites for its increase. Not enough manpower for more frequent releases. The introduction of systemd will only reduce it. But it may be that there will be no alternative.
- Nobody writes new slackbuilds, they just update old ones. Because it's not simple. Simple is "make install" and a double click on .exe.
- The distribution depends on 3-5 key people, and they are not young and some of them are hysterical.
- Eternal problems with bootloaders, UEFI, SecureBoot, microcodes, initrd, Nvidia drivers, kernel modules and with installing complex software. A potential newcomer will not understand why he needs it after more automated systems.
and yes i know cutefish desktop and awesome (a tilling windows not a desktop) dont need systemd to work as almost all desktop doesnt need systemd to work.
gnome 3 needed but can be patched to work without it like others distros did.
Slackware doesnt need to change its init its only my opinion and i dont speak for others. Slackware is one of the most and few most unix like distros why change that?
even Sway that used elogind up to a month or two ago now use seatd (elogind is systemd standalone version)
flatpak doesn need systemd.
so is moving to systemd necessary? i hope not.
Slackware will die if implement systemd by default, imo.
The only way Slackware would die is if Mr Volkerding would stop to maintain it. Those who trust his judgement will be using Slackware no matter of what.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
