Slashdot Mirror
Gentoo Developers Fork udev
In October, Linus Torvalds expressed concerns that udev was making "...changes
that were known to be problematic, and are pure and utter stupidity." Several Gentoo developers were also concerned about the removal of features and uncooperative nature of udev maintained by the systemd developers, so they've announced a fork: "After speaking with several other Gentoo developers that share Linus'
concerns, I have decided to form a team to fork udev. Our plan is to eliminate the separate /usr requirement from our fork, among other things. We will announce the project later this week."
The project name (for now) is udev-ng, and you can grab the code from Github. Update: 11/16 21:29 GMT by U L : One of the developers commented that this isn't yet an official Gentoo project (but hopefully it will be!). There's also an informative flamewar about the fork on debian-devel.
You may want to look into this unix idea of "modularity." The idea is that things in your system specialize and be very good at a few things. Then later you can replace them if necessary. *pats head*
So the distros released an update that makes everyone pay a 60s penalty - which I am seeing daily, til I located some of the drivers triggering this.
2011 was the year of sub-10s boots.
2012 was the year of post-60s boots.
Looking forward to 2013.
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libgudev-1.0.so: undefined reference to `udev_enumerate_add_match_is_initialized' /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libgudev-1.0.so: undefined reference to `udev_device_get_is_initialized' /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libgudev-1.0.so: undefined reference to `udev_device_get_usec_since_initialized' /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libgudev-1.0.so: undefined reference to `udev_device_get_tags_list_entry' /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../lib/libgudev-1.0.so: undefined reference to `udev_enumerate_add_match_tag'
Stick a fork in it, it's not done.
That's not a nice way to treat a project that you've used up to now. Udev isn't gone or obsolete. A fork isn't "-ng". Compete on merit, not marketing.
I doubt anyone will listen to me at this point, but that was not an official announcement. I wrote that email to preempt a policy decision by the Gentoo Council that would have negatively affected the goals of our nascent project. A consequence of doing fully open source development is that with the exception of issues involving the security of our infrastructure, all of our internal emails are public.
Anyway, the official announcement will come later. We are still working on becoming organized. I also probably should register on slashdot.
Uh oh! Lennart isn't gonna like this! His butthurt should be funny nonetheless.
I had trouble with udev 182 and 187 myself, I had no idea they were so widespread.
I had this problem with my eeepc 1215b hanging 30 sec at boot. Spent half a day fixing it, didn't understand why the fix worked. At the time i cursed Broadcom, but it was intentionally done by udev? Wtf?? I say "Forks away!"
for i in `facebook friends "=bday" 2>/dev/null | cut -d " " -f 3-`; do facebook wallpost $i "Happy birthday!"; done
Well, at least there's one distro that's tired of letting Red Hat developers dictate the course of linux component development and marginalize the whole independent distro model. Hello Debian? Ubuntu? SuSE? Are you guys beginning to see a pattern here?
Those idiots are still giving us all grief. Can't we just kick these guys and they're half-assed project to the curb? Systemd was a good idea, but shit implementation and zero admin love. Hell, they are actively admin hostile! Now they plan to Fuck up udev? great.
Hope they have lots of USE flags for us Gentoo ricers! ZRRRROOOOOM!!!
Those idiots are still giving us all grief. Can't we just kick these guys and they're half-assed project to the curb? Systemd was a good idea, but shit implementation and zero admin love. Hell, they are actively admin hostile! Now they plan to Fuck up udev? great.
They didn't just plan it, they DID it.
Linus was on a roll. Read the whole thread:
Stop this crazy. FIX UDEV ALREADY, DAMMIT.
Who maintains udev these days? Is it Lennart/Kai, as part of systemd?
Lennart/Kai, fix the udev regression already. Lennart was the one who
brought up kernel ABI regressions at some conference, and if you now
you have the *gall* to break udev in an incompatible manner that
requires basically impossible kernel changes for the kernel to "fix"
the udev interface, I don't know what to say.
"Two-faced lying weasel" would be the most polite thing I could say.
But it almost certainly will involve a lot of cursing.
The fact is, udev made new - and insane - rules that are simply
*invalid*. Modern udev is broken, and needs to be fixed.
Stop this idiocy.
The kernel doesn't have a lockup problem. udev does.
Yeah, that bugzilla shows the problem with Kay as a maintainer too,
not willing to own up to problems he caused.
and
So now, after you've dismissed the patch that did the equivalent fix
in udev (Ming Lei's patch basically disabled your idiotic and wrong
sequence number test for firmware loading), you say it's ok to bypass
udev entirely, because that is "more robust".
Kay, you are so full of sh*t that it's not funny. You're refusing to
acknowledge your bugs, you refuse to fix them even when a patch is
sent to you, and then you make excuses for the fact that we have to
work around *your* bugs, and say that we should have done so from the
very beginning.
Is Kay Sievers really that dumb?
"informative flamewar"
I literally LOLed.
Endless churn and change.. complexity.. politics..
rh 6.3 turns one file inittab into 59 different files...
Just one example.
Is debian the only sane unix left?
Now udev fork.. wasn't udev supposed simplify some other nightmare?
Every distribution that includes the crappy systemd requires udev (modified to only work with systemd), dbus (modified to only work with systemd), and systemd itself (requires udev and dbus).
Right now they can't even get Fedora 17 to work properly due to the design problems with systemd -
1. it requires too many other services to function
2. it cannot create logs properly (it loses important data)
3. it's basic design is an attempt to create a solution to an NP complete problem.
Linus also said this, "I also call bullshit on your 'it will surely be fixed when we know
what's the right fix' excuses." This excuse pops up A LOT in bug comments of any Gnome project core component that's maintained by a Red Hat dev. In fact, it happens so much and with different RH devs that I have to question whether this attitude is mere developer arrogance or if there is something else going on. It doesn't follow that these guys are so incompetent that they'd need to keep making excuses as to why their code is shit, and/or they reject any patches coming from outsiders because they're so committed to some sort of "purity of vision" that only they know how to fix the bugs they introduce.
Newer versions of fdisk can not create a partition anywhere on the disk. You may remember that all prior versions of fdisk-style software (and all except the current Linux fdisk) can start a partition after the 63 sectors reserved for the MBR.
Current fdisk for Linux, on the other hand, has a minimum sector of 2048. This seems.. absurd. Even on an SSD with 4k blocks, or even 64k blocks, only 128 sectors, max, would be needed for alignment. But fdisk isn't trying to force alignment -- you can start/end on _any_ sector starting with 2048. You can not manually clone an older partition table: you want to dd from one disk to another, resize the partition, and resize the filesystem? Better not start at a sector less than 2048! If it starts at sector 63, and you delete it and try to recreate it, you're going to be missing the first chunk of your filesystem.
2012: the year Linux screwed itself over trying to become Windows.
Why don't you just call it udev.
I like systemd, logind, and journald. But I take serious issue with the fact that they're pulling all of these logically distinct things into the same repository. There's no difference with udev. The innovation is good, but what happened to the Unix philosophy?
Udev should never have been pulled into the same source tree. If there was a lot of code overlap, then it should have been put into a library that both udev and systemd can depend on.
So, forget the -ng. The systemd guys will probably be happy enough calling theirs "systemd-udev" or "udev-systemd"
USE=" -redhat-crap everythingcoolnfast"
the second on my list is Lennart Poettering. Its a three strikes thing, PulseAudio, Avahi, and now udev.
For the first, Miguel de Icaza, it took just one strike to ban. Mono, bad, bad, bad.
The main problem for me seems that the things they do seem to have dependancy fingers all over the place. Just a pain to remove and guard against it finding its way back on how tomboy notes got on any linux system as a default boggles the mind.
A full-of-themselves group of developers pissed off enough people to get a viable fork going. Hopefully systemd-udev gets kicked to the curb by udev-ng.
BTW, Poettering and Sievers are the same characters who wanted a binary syslog with an undocumented format http://linux.slashdot.org/story/11/11/23/1733236/secure-syslog-replacement-proposed The Slashdot summary noted "This is being done as an extension to systemd". Sound familiar? Give them enough time, and those guys will end up rolling the linux kernel into the systemd tarball.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
If you see a project that Lennart Poettering is involved in...............run for the hills. Seriously. There have been many fits of insanity with PulseAudio (something that has set desktop Linux audio back years) and systemd is such a departure from traditional Unix system administration it's just ridiculous. That might not be a completely bad thing is done carefully but this guy is full of his own self-importance and just cannot see the lunatic path he's on. Ulrich Drepper has similar 'issues'.
Seriously, how can you break something so fundamentally that worked for so many years?
.....In the long and broken road to PulseAudio broken Linux drivers are a very recurring theme.................
I completely agree with the Gentoo devs, udev is getting problematic, for starters, there are a lot of gentoo people using AUFS and squashfs to reduce the size of their /usr. Well if /usr is on a different partition, udev freaks out. It got to the point where I didnt' want to update udev but I ended up reverting my AUFS/squashfs /usr partition because of it. Can't wait to go AUFS/squashfs for /usr again!
-- Its survival of the fittest...and we got the fucking guns!!!
Monolithic code bases with feature-creep are never a good idea. I have no idea how Pottering ended up in control of udev.
I'm running arch, reinstalling (which I should never have to do) was faster than fixing the udev mess. Currently waiting for maintainers to make the right choice, drop systemd and give us a sane init that works something like BSD inits. In the mean time, I su on boot and start any daemons that fail to start since I 'upgraded' to systemd manually.
I had code in udev for a while, though it's probably been replaced now. (Moved from multithreaded to singlethreaded and made it way faster at the same time.)
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable request.
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.
Is Kay Sievers really that dumb?
Yes and no.
What the udev guys are suggesting is that in the "module init" stage (where modules are loaded into the kernel) the module should not block waiting for firmware (because there may not be a filesystem yet, especially if the module is actually compiled into the kernel rather than loaded later). Rather the firmware should be loaded at "device open" time.
This is actually a reasonable position to take.
Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.
And binary logs would actually make it *much* easier for programmatic tools to parse the logs for events that they care about.
As it stands it's actually quite tricky to automatically sort through a kernel log stream looking for critical events to raise alarms over.
What amazed and apalled me was what I read when LP wrote in LWN about not caring about the Unix Way.
I'm a Gentoo user and *proud* of the fact that our community has done so much to push back against the systemd elephant.
This is actually a reasonable position to take.
Why? Doesn't the system need some sort of root fs to boot? I am asking out of ignorance and curiosity, nothing else.
...I'm a (Free)BSD fanboy/fool. There is occasional stupidity (witness the recent replacement of sysinstall with some half-assed, half-baked, incomplete alternative), but usually the core team is sane, and the flamewars don't have two people both arguing from flawed foundations. The obviously *right* thing to do with this whole mess is simple: toss it.
Create a standard place for firmware files, allow it to be configured and overridden easily, make judicious use of symlinks/union mounts. Then, let the drivers do the right thing: Load up, determine if a firmware needs to be squirted in, load it if so, and continue. This idea of some entire subsystem tied to a userland daemon being responsible for loading device firmware is plain absurd. Drivers know how to load their own firmware, and with an extremely simple knob (rc.conf, linux equiv to loader.conf, sysctl, whatever) they will know where to look for it as well.
Somebody, somewhere, smoked some serious shit to come up with this udev/systemd fiasco to begin with.
The in fighting and compatibility problems of most linux projects cause us problems. X.org and Wayland should NOT be built on this crap. It's not stable.
No, it doesn't. At boot time (specifically, at the point where execution transfers out of the boot ROM (eg. BIOS)), there just needs to be a blob of executable code at a known location in RAM.
For example, I've got a diskless system that netboots: the kernel image gets passed from the netboot server to the client RAM over a TFTP connection; the root filesystem (served over NFS) doesn't show up until a goodly chunk of the kernel has been initialized. As should be obvious, this means I can't use a network card that requires external firmware.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
You also have to be an arrogant, full-of-yourself preening jackass to act as if your way is right and fuck you for trying to change it.
Don't forget Avahi -- a network-facing daemon included in the default GUI install that has a remote security hole at least once a year. And what it's for? So you can have a link-local chat (compatible only with itself) and some autodetection of rare Apple's printers.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Alas, it is also apparently required to get the MythTV Android remote features to work. I might consider running it but for the fact that I started using the .local domain for my internal network long before avahi came along and I really don't want to reconfigure everything.
Case in point, nginx init script comparison (I'm going to count blank lines and such just because it doesn't really matter and w/e):
Length of the systemd script: 15 lines (http://wiki.nginx.org/FedoraSystemdServiceFile)
Length of the init.d script (for ubuntu): ~300 (http://wiki.nginx.org/Nginx-init-ubuntu)
I use this example as I recently ran into needing to manually create this service file and make a couple modifications for my setup. This was thankfully stupidly easy thanks to systemd. Oh, and my server runs rock solid, up continuously for over a month including system updates about once a week :D
Are you systemd haters really gonna tell me that you prefer the second to the first? Who's really being silly here? I'm assuming that people who would say yes have no experience with mission critical configuration on servers in the dead of night with no coffee left... correct me if I'm wrong. No hate intended, just wondering why all the beef with systemd. Personally I find it quite enjoyable and user friendly even with limited documentation.
Monolithic code bases with feature-creep are never a good idea.
The kernel developers are having a fit and you bring that argument in their favor?
Is this the recursive full-of-yourself preening jackass loop?
And anyone who doubts the wisdom of the move to systemd on the Arch Linux forums gets roasted by the maintainers. Arch Linux maintainers get hostile, and defensive and unbending very quickly. Not attitudes that inspires confidence.
The switch has not been smooth. Documentation is lacking. The latest thing was that a routine update removed the shutdown option from the GUI menu. I've also noticed that journalctl (the replacement for "less /var/log/messages") is slow when one wants to view more of the recent history than journalctl shows with the -f flag. I'm thinking systemd compresses the logs almost right away, then journalctl must uncompress everything from the beginning each time the admin wants to view the latest logs. If so, it doesn't speak well of the systemd developers' ability, to have designed software to proceed in such an inefficient manner.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
avahi is also now required by cupsd :(
That's not fair. Pulseaudio in it's current state is the best goddamned thing that has ever happened to Linux audio. Using its unsteady beginnings to discredit Pottering is just FUD.
Having said that I totally agree on the whole systemd thing.
This whole idiocy is intended to force modules devs to actualy do nothing during init so that udev/systemd can advertise faster boot up times.
Actually, the problem is dependency type.
I'm pretty sure that Scott (keybuk) would agree that one of the major deficiencies for udev, in terms of getting this up and running as fast as possible, is that there is no disctinction between "necessary" and "sufficient".
Basically, you want to signal some conditions after an operation has completed, but that doesn't necessarily mean that you want to block operations which depend on the incomplete operation from proceeding, at least partially.
A good example for this in the Chrome OS arena is that the firmware for the 3G modem should be loaded before you want to use the network, but that doing so shouldn't block other operations from being started while the load is in progress.
Currently, about 1.2 seconds of the Chrome OS boot time are spent in unnecessary stall barriers for lack of being able to specify the firmware load as a necessary requirement that's not sufficient to get something working. Because of this 1:N cardinality on the final step, the intermediate steps end up serialized by udev, resulting in unnecessary delay in the boot process.
Arguably, about 400mS of this is due to user space code being unable to start up before the resources, such as networking, that it requires for functionality, not arriving before it starts, but I'd argue that that's a user space bug, on the order of sendmail needing to be able to look up via DNS the canonical name of the IP address on the network interface it's listening on in order to present the correct greeting to someone connecting to the SMTP port. This was actually first an issue for an employer in 1997, and at the time I wrote it up as "cached data considered harmful", but it's really an issue of needing to use resources before they are available so that you can have the information available when you need it.
But delaying firmware loading until device open is not the answer either: it slows down the device open, and again, you end up with a stall, you've just moved the deck chairs around, and not achieved any latency benefit.
You really want to load the firmwar as soon as you can, and only stall the open if you need to because the load is incomplete. But at the same time, being able to load the firmware doesn't mean that everything else should wait while the load is taking place. On either side of this divide is where both the older udev (and thus udev-ng as it has been envisioned) and the current udev fall flat.
Note that the FreeBSD/NetBSD startup have this same issue, where there is no distinction between necessary/sufficient, with the ability of soft dependencies to be satisfied in parallel -- which is the true solution to the problem.
I'm not sure what the real answer would look like, if it were completely implemented, but to my mind,neither udev approach answers the quandry in a satisfying enough way.
Read Linus's arguments. The issue is that apparently certain types of devices drivers that can't be initialized without loading firmware, as it is not possible for them to identify what kind of devices are present/etc otherwise. So, the system can't tell what kinds of devices to create as a result, and then nothing will ever be able to open it anyway.
In theory the idea was a good one, but in practice it didn't really work out, and simply breaking a bunch of devices with no fix possible just isn't acceptable.
Linus wasn't complaining that they should wait forever for driver authors to catch up. He was complaining that it wasn't possible for them to catch up.
You're WRONG, there's always a rootfs in initramfs (it's mandatory since 2.6). The root dir on NFS you're talking about is the "user"'s root. The early init will switch-root to the user's one. You can always have firmware in initramfs. In fact, most embedded linux system never bother to switch-root to an "user"'s one.
Yes I did. The kernel guys will not maintain stuff in-tree that has no justification for being there. Submit a patch to lkml for something that belongs in userspace and see how you fare.
PID 1 is the parent process, it's a well understood problem space that does not include device initialization, system logging or tcp wrappers. udev now has to be forked just to make it possible to build outside of systemd.
... except that it was Colin Guthrie who stepped in and essentially saved PulseAudio, not Lennart who managed to do almost anything but during his tenure.
This isn't the place to argue, but first of all there was a CALL FOR TESTERS for damn near a YEAR and nobody spoke up. If you're not going to help test you shouldn't be complaining. Very few have serious issues with bsdinstaller and those that do are just people that yell loudly for no reason.
Secondly, if you'd ever looked at the sysinstall source code you'd have seen how it was an unmaintainable mess that should have died 12 years ago. The new one is extremely clean and extensible.
That's not fair. Pulseaudio in it's current state is the best goddamned thing that has ever happened to Linux audio.
It took what worked and made it not work, not too mention turning over a disproportionate amount of CPU time. Pulseaudio was just to get mixing to work basically because some twits decided it couldn't be done in the kernel (it can, and no one apart from OSS has tried). They broke the whole sound system for a very long time to do it. Lunacy.
Using its unsteady beginnings to discredit Pottering is just FUD.
It's not. It was unsteady because of Poettering's attitude and he simply has a big track record on whatever project he has worked on. Pulse has become sem stable down to the hard work of others, not that it isn't still completely the wrong solution for Linux.
Let me grab the popcorn.
In most areas I'm a bit of a unix curmudgeon but I'm happy to be rid of SysV init scripts.
And why would I like systemd?
All the reasons given here: http://0pointer.de/blog/projects/systemd.html
It took what worked and made it not work, not too mention turning over a disproportionate amount of CPU time. Pulseaudio was just to get mixing to work basically because some twits decided it couldn't be done in the kernel (it can, and no one apart from OSS has tried). They broke the whole sound system for a very long time to do it. Lunacy.
You're just spewing contradicting bullshit.
As you wrote, nobody but OSSv4 has ever tried to do mixing within the kernel; largely because the upstream kernel maintainers have made clear several times they won't accept it.
So, before PulseAudio, audio in Linux did not work properly. It got by and mostly worked using either hardware mixing (when those cards were common) or one of a few user space mixing solutions (esd, artds, ALSA dmix).
None of the user space mixing solutions worked quite well, so something else was needed.
Since I started using unix in 1997, Red Hat, to me, was the "Microsoft" of distros. Lots of security bugs, broken modules, etc. They even told companies who bought millions of dollars of RHEL support to 'fuck off' when a bug fix for a networking issue under heavy load turned up, because that usage was not 'common'. Said company got rid of their RHEL support license, and hired their own internal kernel devs.
Red Hat has been arrogant, turning out mediocre distros for a LONG time.
Uh, pulseaudio is still an unstable piece of crap. It's just that its bugs mostly moved out of the core functionality. Now it is stuff like the ALSA->pulseaudio interface that's forced on people that is buggy as shit.
Considering how old that project is by now, it sure isn't a convincing performance.
You're WRONG, there's always a rootfs in initramfs (it's mandatory since 2.6). The root dir on NFS you're talking about is the "user"'s root. The early init will switch-root to the user's one. You can always have firmware in initramfs. In fact, most embedded linux system never bother to switch-root to an "user"'s one.
Nope, not at all.
/dev/sda5 is directly mounted as root. NFS can be used as the actual root with appropriate kernel parameters to set that up basically the same way.
/usr, /home, and similar. It's much better performance and is worth the ~150MB of memory.
The Gentoo system I'm typing this from is running 3.4.9, and does not have an initrd/initramfs. I have support for my sata controller and filesystem compiled straight into the kernel, and
@Carnildo - For a diskless system, unless very limited in memory, you're much better off making a custom initrd that contains the basic root filesystem, and then use nfs for just
I didn't save anything. I just helped out with maintenance and tried to rally the other developers already on board. Lennart's code and knowledge of the audio stuff far, far outweighs my own here. It was Lennart's dogged determination to carry on in the face of unhelpful criticism from the peanut gallery that helped get PulseAudio to its current state of relative stability - including the pushing and poking needed to get the other stuff in the stack fixed too.
Myself and other contributors (more so than me) had a big hand in this too, but credit where credit is due!
So, before PulseAudio, audio in Linux did not work properly. It got by and mostly worked using either hardware mixing (when those cards were common)
Aaah, the golden age. I'd just get a cheapo Soundblaster and everything worked just fine. Well, except for Crossover Office/wine which would occasionally flake out and grab all the resources. That was an edge case though.
Then came the dark ages -- dmix, esd, early Pulseaudio.
Now things are pretty stable, and I'm happy with how Pulseaudio works -- especially with the seamless network sound streaming (use this surprisingly often).
Woo, I'm such a ricer! USE="-pulseaudio -systemd -nepomuk -strigi -akonadi"