- This topic has 5 replies, 3 voices, and was last updated Sep 15-6:07 pm by Anonymous.
-
Posts
-
fungalnet
I did the following searches on this young at heart forum, for libudev-zero, mdev, smdev, nldev, mdevd and found nothing, not a single mention, so here is the story:
Can we live without udevd?
Let’s recapitaluta how wide this struggle has been, to not depend on IBM for your open and free software to work.
On the logind front, consolekit2 is not dead, this is old propaganda, especially with all its development from its BSD fork, consolekit2 is alive and well. But you can live well and prosper (as Spok said) without any logind. I have for quite a while. Then there was the silly myth that wayland can not work without systemd/elogind. Myth busted, the guy that made seatd broke that myth right in the myth manufacturer’s face, and once people started considering using wayland without elogind, they also found out it works perfectly fine even without seatd (if compiled as such). That deep of a myth. It is like saying you need a fishing pole to go on a date…. folklore. Also you don’t need X for wayland/wlroots/sway … it works. I still don’t like it, but whether it works is a different story.
And dbus, that decorative snitch, monitoring and communicating your every click and keystroke? It even monitors and snitches on root’s activities. So to whom is this piece of crap in service of? I’ve lived without it for years now. So more folklore spread around by the IBM parakeets.
But we are stuck with a big IBM chunk, we are not out of the hole yet, we love what IBM does for us (like junkies love the pusher) from the second we hit enter on the bootloader screen. udev hooks running and rerunning and eternally running till everything is shutdown and gone to sleep.
IS (not are) there an alternative?
Years ago somebody decided they’ve had enough with udev and wrote smdev. As simple and lean as it can possibly be, with the ability to be enriched by hw modules for anyone that desired more than a simple x86 machine booting, having classic input/output abilities, reading/mounting disks, and a few simple additional hw. It worked, it is simple (suckless) and the great story is that it runs once and ends, doesn’t need to be daemonized (thank anticapitalista for that – if you have to thank anyone – because it takes a few seconds for each run). But as hw get more fancy and multiple in necessity, it wasn’t enough for people to adopt. So it remained.
Then comes this other solution, an intermediary, which can utilize any mdev provider, simulate the ability to be triggered by a change in hw, run the mdev (of choice!), and provide new definitions for hw adder/removed. This project was called nldev, a middle man.
Then skarnet begins work, not yet finished, to provide a true and complete udev alternative, still less than 1/3 of the code of (udev/eudev/libeudev), and it does work if you study the subject in depth and can configure it right. A nice template of a .conf file to uncomment all its abilities that are utilized, would have been nice, but skarnet wants you to do your own research and make your own choices, just like s6 s6-rc, etc. No ground food and chewed ready for swallowing from skarnet, they like to see you in tears before you make their sw work. Their server has been running for a ?decade? with it, with reboots only taking place in leap years, and if there is no pandemic.
BUT!!!
Why aren’t users and distro devs running to adopt such solutions? 1 reason! X is having problems with them, in most cases you can’t get the keyboard and mouse to work properly. That’s a big one … for most people, let’s be realistic. “Some” people don’t need X, they do all their work on console, their greps and cuts and sed and vis, is all they need, and lynx for a fancy browser to relax from coding.
Why is X so peculiar about the specific mdev? Because it was written with the single piece of available to them and looks for its coding.Pop goes the myth of X would only work with IBM’s udev.
libudev-zero
A very young and promising project, getting about 5-6 upgrades just this past week alone, although it worked 10 days ago when I fist tried it.
On the early trials I replaced libeudev with libudev-zero, booted with eudev, then shut down the daemon, then started X. Cursor, cursor theme, keyboard, all working great. Then tried to substitute eudev with one of the alternatives, I admit I don’t have yet the knowledge and patience to configure mdevd right (Sorry mr.Bercot) but smdev worked, run manually once, and then libudev-zero takes over. As soon as smdev runs and throws 30 pages of nasty looking output on your screen, the screen readjusts (just like in udevd activity), net interfaces become available, and all is well.Hmm… not so fast slick, how is your kernel image created with smdev?
That begun being tough, mkinitcpio run aground without eudev/udev available, possibly with the libudev-zero in place of libeudev. Here comes the “middleman” that makes any mdev availability work, nldev. You substitute nldev for udev in mkinitcpio.conf and the image is created properly, nldev is configured to run smdev during the boot hooks, and you get a nice console login: with any parts of e/udev removed from the system.
And of course X started normally and my favorite terminal provided a shell.Not so fast slick! Now that you got linux-lts image booting without udev, what else is there missing?
Ok, Ok, Ok, … (Joe Pesci voice in lethal weapon X) … some things must not work because they were compiled with udev’s existence, which eudev does wonders for substituting because …. IT IS THE SAME CODE!!! Like what, you might ask. lsusb for example, still works but throws some garbage up on top for not being able to get the udev version. The output is still the same as with eudev. /dev/disk/ is empty, but blkid works fine (it doesn’t depend on udev). All mounting/unmounting/ssh/sshfs all work. How about Gparted, does it work? NO! Why? Because it is compiled based on the specific udevd and unless it gets the version number it exits with an error. If you can bypass this, or if you and the coder of libudev-zero figure out a way to fake this functionality, I don’t think there is an issue.
Yet, again, not so fast slick!!! You are tripping over yourself.
libeudev
├─device-mapper
├─eudev
├─libgudev
├─libusb
├─lvm2
├─usbutils
└─util-linux
eudev
├─colord
└─dhcpcdThis is a list of what I have found up to now, that are very base/core parts of almost any linux distro. that depend and ARE built based on udev, and some may work fine, but internally they think that udev is there. So idially they must be rebuilt with the alternative in presence, in my case smdev, nldev, libudev-zero.
This is a little harder to do than I thought, but my abilities are limited. So it is not to say it can’t be done, I’m just passing the torch here for those that understand the importance of doing so and are willing to try it in a test installation.
I can assist with details anyone willing to give it a try, I have a runit script that works with mldev, and a 66/s6 script for not so clear solution for boot@-66, and more.Just to see the light in the tunnel though, it is rewarding and new land will not be discovered unless we all do a little more pushing of the fence we are trapped in.
Because they want us fenced in and dependent to control us. It is our single mission in life to bring those fences down, because on our land we can build autonomy, on their land we will always be slaves. We will not make this mistake again, to allow our land to be purchased for individual use. Am I losing it? No, anticapitalista knows what I am talking about.
A las barricadas!
anti-X - Adélie - obarun - systemd Free Space
olsztyn
A las barricadas!
No pasarán!
Having read this dissertation (Thank you fungalnet!), I have a strong feeling there is a potential for a new era in Linux architecture…
Here and there people are tearing down established myths of dependencies on provided modules, just piece by piece. This analysis is the first one I see that puts all these pieces in one writeup. I hope a coordinated body of ‘Linux re-architecture’ will emerge to accomplish this task in its entirety.Because they want us fenced in and dependent to control us. It is our single mission in life to bring those fences down, because on our land we can build autonomy, on their land we will always be slaves. We will not make this mistake again, to allow our land to be purchased for individual use.
In Linux world this might be realistic. The reason being there is no real estate, money and wealth to be grabbed, whether purchased or just taken over…
Just my two cents…Edit:
The meaning of ‘purchased’ sounds legally serious but is it in reality? Considering various key pieces of land, such as Manhattan was ‘purchased’ from Indians for some beads and trinkets worth $24 and the entire Alaska was purchased from Russia for mere $5 million. Well, perhaps the latter one seems more serious, but on the other hand who gave the right to the Czar to sell such large piece of Russia? Did he got an agreement of Russian people? Of course not…- This reply was modified 1 year, 8 months ago by olsztyn.
Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersAnonymous
Gparted, does it work? NO!
cfdisk (standalone package, or within debian package “fdisk”) does still work in the absence of udev, yes?
gparted implies X11, which doesn’t fit the use case proposed / advocated in the OP ~~ ” some people [who] don’t need X, they do all their work on console, their greps and cuts and sed and vis, is all they need ”Dec2020–Jan2021, while working on slimski (SLiM login manager fork), I earnestly researched the status quo and decided (admitted to myself) that consolekit2’s status was untenable.
Has one of the consolekit forks now surpassed the known-to-me “master” branch? if someone posts an appropriate URL to its sourcecode repo, I’ll take a fresh look.
links, from my earlier notes:
https://github.com/ConsoleKit2/ConsoleKit2/issues
https://github.com/ConsoleKit2/ConsoleKit2/issues/98
https://www.linuxfromscratch.org/blfs/downloads/8.3/BLFS-BOOK-8.3-nochunks.htmlps: I have zero interest regarding pursuit of stripping dbus [IPC, interprocess communication] support from programs used on my system.
fungalnet
On gparted I totally agree with you, and I mentioned as an indication of certain things that may be not working. But I don’t think it is not working because of X or that the gui is failing, but because of this little detail where it wants to verify the version of libudev (which is marked 1.64) but it seems it is not provided in the proper udev way. The aspect of it shows exactly that it is not gparted having the problem, but device-mapper which is part of lvm2. It is just that a silly error like this could have been neglected and the rest of the program would run, but in this case it exits. There is not much you can do to force it ignore unless you fork the project and alter it.
On lsusb it throws a very similar error on the libudev version, but continues to work.Talking with someone who has done extensive work to make this run says that his setup is such that at least the small problems I have witnessed are not there, in a very similar system. Also, there are several modules/parts of smdev that provide it with additional functionality, oen is a uuid module which helps it populate the dev/disk directory.
I just felt that a few people in antiX may be interested to know that such alternatives exist, therefore the post.
The more people become aware of the possibilities the faster they will grow and provide better functionality.Consolekit2 was very specific, I don’t know of other forks, is adopted in BSDs trying to make things work when they are ported from linux, in conscious or unconscious luck of systemd branches. The development ck2 gets from BSD is backported into the linux project. The goals, … to make plasma and gnome work on OpenBSD or NetBSD!!! That’s what the market wants, that’s what some providers sell. Again, the producer and the consumer, a different mode of thought of sharing what you like and use.
There was a long awaited merge of several merge requests back in Dec 2020, only days apart from the decision in slackware to have elogind everywhere…. I’m surprised if vi works in slackware without elogind. And just this past month it was bumped up again to 1.2.4 again.
But opening up one of your links gets my pressure elevated just reading the headers of issues, “pm-utils” is DEAD, provide your own pm-utils. Why are things dead if they are not broken and have no bugs reported?How can runit not be dead but consolekit2 is? When will the mainstream linux dev community brand runit as dead? And when they do, what is antiX and void, and artix, and many others expected to do, return to sysvinit because runit is DEAD!!!
If I begin a project today to produce code for copying or moving files around the file system in a more efficient, fast, accurate, reliable way than cp and mv. And I achieve this, I display how my code is better, every bug ever reported is fixed, and I achieve all the goals, why should I “pretend that I keep devoloping it” by adding this and the other feature when it wasn’t my initial intention. Maybe I can add compression into cp and mv so between networked fs it is even faster, but then the code gets bloated and the intention was to make it better, not worse! So if I remain faithful to the goals and promises, I should let it rest.
The predominant dev mentality is that is DEAD, it hasn’t received updates. If I go in and switch the description of the package from “this is code for copying and moving files around” into “this is code for moving and copying files around”, then OK, it received an update. Most of those numbnuts that brand software dead would be happy!
ConsoleKit2
ConsoleKit2 is a framework for defining and tracking users, login sessions, and seats.
C 100 GPL-2.0 25 16 4 Updated Jul 4, 2021Ohh… wait, what does this mean, that ck can handle seat calls now, what happened, they incorporated seatd into ck2? I thought the reason people dumped it was because it couldn’t handle seats, only systemd did.
Let’s see what other obstacle covered up with eye candy for morons is IBM going to think of next. They can’t buy everyone, there will always be running behind development that takes place in basements, bedrooms, kitchens, and in many cases it has proven to be leading the way for their paid armies of silicon-army design prisons, or new-delhi sweat shops to follow.
anti-X - Adélie - obarun - systemd Free Space
fungalnet
https://www.summertime.tech/dtw.html and https://www.summertime.tech/linux.html
Not that unrelated to the question, but out of curiosity Skidoo, you say:
ps: I have zero interest regarding pursuit of stripping dbus [IPC, interprocess communication] support from programs used on my system.
How is dbus providing functionality that you can’t live without? From the one side you say gparted is X11, you can live well with fdisk/cfdisk from the other side you can’t live without dbus. What exactly fails and how when dbus is absent?
PS Not on antix/debian, but on other linux, I was able to build lvm2/device-mapper yesterday without any use of udev, as per encouragement by the author of libudev-zero who finds the used of udev in lvm2 nonsensical. https://github.com/illiliti/libudev-zero/issues/4 The few errors I was getting with it have now vanished. It is even more interesting to discover that few of the reasons devs have linked udev to lvm2 are discontinued by udev to begin with. At the same time it appears as all those e-substitutes Gentoo was producing and non-systemd distro relied on for some time, seem to have come to an end, as this distro is slamming the brakes and making a U-turn to employing the whole real thing of the IBM trojan horse. You know, how they say, you can buy some people some time, but you can’t buy all the people all the time …. who is paying large 6figure salaries to key-players in “linux”, some close to 7, and some barefooted fools are expecting those same people to be rocks of idealism and not negotiating a sell out?
“there is good and bad software offered by large multinationals, and the criterion is in the technical details”
There is one and only motive for any corporation to produce anything, profit. Profit requires control of the market. Control of the market requires dependency. Dependency requires a condition where you are convinced you can’t live without it.
This is a very different premise where “Joe Smoe” develops code, forks other software, and finally sees some utility in his setup and offers it openly and freely to be shared by anyone who also finds it useful. Hence the abundance of software that were published by a single entity, received some development, and then abandoned for years it lays in some git-server idle.
Smdev and nldev were perceived as useless except for those who strictly had a non-gui console based system. Now with libudev-zero filling the gap they left, they seem pretty damn useful.
anti-X - Adélie - obarun - systemd Free Space
How is dbus providing functionality that you can’t live without?
This question is misguided. It’s analagous to asking: Can you live without ‘the letter T’?
Although I strive to avoid all _serif_ fonts (including T characters), I would not attempt to altogether “live without” the letter T.“dbus” is a too-generic term. We may choose to “live” with, or without, various D-Bus IMPLEMENTATIONS:
“libdbus” (freedesktop.org)
“GDBus” (GNOME)
“QtDBus” (Qt/KDE)
“sd-bus” (component within systemd project)
“DBus-Java”D-Bus, as explained / described by Pennington:
“designed for use as a unified middleware layer underneath the main free desktop environments”We, outside those desktop environment silos, [may choose to] enjoy myriad software titles which were developed by / for those silos.
We, under antiX, already happily “live without” sd-bus and [per the default selection of programs pre-installed in antiX] DBus-Java.
GLib, which provides bindings for many programming languages, utilizes GDBus or libdbus0. Should we therefore eschew any / all GLib -based programs?
> skidoo wrote: “I have zero interest regarding pursuit of stripping dbus”
“dbus” is not nefarious.
To anyone [desktop session users] suffering from “We fear that which we do not understand” worries,
I would encourage you to install “d-feet” and to observe “exactly what traffic, from which programs, travels the bus(es)”.
Takeaway: unless one is engaged in debugging a problem… the nature and content of the D-Bus traffic is quite boring.https://packages.debian.org/bullseye/d-feet
(page also links to screenshots of its gui)d-feet [written in python] is a D-Bus debugger that allow you to:
* View names on the session and system bus
* View exported objects, interfaces, methods and signals
* View the full command line of services on the bus
* Show values of properties
* Execute methods with parameters on the bus and see their return values
- You must be logged in to reply to this topic.
