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*
Stick a fork in it, it's not done.
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.
I had trouble with udev 182 and 187 myself, I had no idea they were so widespread.
Nice doesn't enter into it.
I owe no loyalty to crappy implementations simply because I used them before.
Lots of software wanders off the reservation from time to time and needs to be replaced, or forked back to a point in time where it was working well. If the Dev's won't listen to Linus, what other choices are there?
Sig Battery depleted. Reverting to safe mode.
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
"Compete on merit, not marketing"?
So? It is an "ng", next generation. So what? Next generations need not be better. Look at Windows 8. That doesn't compete on merit, but marketing.
If udev-ng is bad it won't spread fast enough. LibreOffice spread, the word.
In other news, in response to the recent creation of the udev-ng fork, Lennart Poettering has announced that udev maintainers are renaming their project to uPulseDevKitd in order to better reflect its capabilities.
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?
From everything Ive heard, Windows 8 IS better, they just slapped an inexplicably horrendous UI on it. I havent heard any complaints from a technical perspective.
Usually, NG is an abbreviation for "No Good".
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.
Being a fairly happy Gentoo user for numerous years now (posting AC to avoid the inevitable derisive sneers), that's pretty much how Gentoo's naming scheme goes. If they have a major fork of something, it'll get the -ng suffix on it until they come up with a better name (usually; sometimes the -ng name just sticks). It's not a declaration of obsolescence, it's just a naming convention.
It really does seem like theyve gone a bit crazy.... heres a snippet from a bug report on the issue:
[dev gives reasons why it is impossible to probe for drivers to load prior to loading some pieces of firmware]
All that doesn't matter; do whatever you need to do, but load the firmware
async, and continue to do the rest of the job when the firmware arrives, and
do not block modprobe.
Unless Im misreading that, Kay is saying "i dont care that the thing Im asking you to do is impossible, just do i t anyways, because its more correct".
Im not a software dev, so maybe Im misreading this, but everyone seems to agree that what the udev folks are mandating is simply impossible in many instances.
There are some evolutionary improvements to W8, although Metro seems to kill workflow. The idea of Metro apps with limited access to the filesystem, user context, and resources is a good thing.
Had MS gave an option to just have the backlevel UI and a good mechanism for Metro stuff, W8 would have been a lot more palatable, and would be able to easily compete on merit, just for the added security that having apps in their own cubbyholes provides.
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.
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.
In Japan. It's wasei-eigo, which means "a Japanese-made English word or phrase".
Japanese learners of English commonly make the mistake of using wasei-eigo in regular English, so they use "NG" and "go sign" and "cunning paper" expecting to be understood. Occasionally this confusion extends to English-speaking learners of Japanese, though much less often.
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"
If it can't do what needs doing, it IS obsolete and will be gone once something (like udev-ng) comes along that meets requirements.
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?
Aircrack-ng.
Although whenever I open it I do tend to tap my mouse on my monitor and say "I solemnly swear that I am up to no good".
Do not meddle in the affairs of geeks for they are subtle and quick to anger
.....In the long and broken road to PulseAudio broken Linux drivers are a very recurring theme.................
Kay seems to be throwing asynchronous around as a 'solution' very liberally. It all sounds very node.js............
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!!!
So you're upset about wasting almost 1MB of space on your multi-terabyte hard drive in order to work around stupid disk manufacturer tricks like lying about their real block size? There's even less reason to complain on an SSD because that almost 1MB will never be written to and hence can be recycled for wear leveling.
I can understand the the issue with dd of a disk image, but copying an old disk image and then deleting and recreating the partitions is a pretty unusual use case compared to installing fresh on an SSD or an HDD with 4k blocks that reports 512 byte blocks.
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.
I think it's less "Do the impossible" than "Do something that doesn't really make sense just for the sake of change, and by the way, SURPRISE! We're breaking all your modules in a patch revision! Sucks to be you! Next time, maybe you'll listen to my mailing list of voices in my head!". The major problem seems to be that it's breaking everything without warning, really, for only a marginal benefit, if any.
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.
3. it's basic design is an attempt to create a solution to an NP complete problem.
Which is?
This sig does not contain any SCO code.
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.
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.
From everything Ive heard, Windows 8 IS better, they just slapped an inexplicably horrendous UI on it. I havent heard any complaints from a technical perspective.
I installed Windows 8 on my laptop. I have no complaints from a technical standpoint, really, but just as well I have no praises to give, either: since I only use it in desktop-mode and not a single Metro - application and I even installed Start8 so as to provide a Start-menu I just do not really see anything different other than a slightly altered theme and hot corners.
I installed Windows 8 simply to see if it really is faster at booting up than Windows 7 and because it supposedly consumes less battery. Sure, Windows 8 shaved about 2 seconds off the boot-up time, but...ehh, I find it difficult to get excited about 2 seconds. And there is no difference whatsoever with battery - usage. With these things in mind I don't get the animosity towards Windows 8, but I don't get the praises, either. It's just Windows 7 with different looks.
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.
You missed the article here about it not dealing with a large proportion of well known existing malware?
I've finally started mucking about with FreeBSD with the ports collection and it looks like everything I'd wished Gentoo was a few years ago. Then again, maybe Gentoo has changed a bit since ilast touched it (I last used it on a little VIA system that could actually benefit significantly for binaries compiled especially for it's CPU instead of stock i586).
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.
If I could only get that sorted out on my laptop, I could save myself as much as five minutes a year!
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.
If I could only get that sorted out on my laptop, I could save myself as much as five minutes a year!
It was a little scratched up from falling off a truck, but it was a perfectly usable spare five minutes.
... 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.
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.
This isn't the place to argue
Are we on the same site ;)
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
I'm busy running production environments and don't have a lot of time to pay attention to the mailing lists that aren't relevant to my business. We've been humming along quite nicely on 8.x for quite some time, and I only got around to giving 9.x a first look this week. That said, if you want to get all ANGRY CAPS WARFARE, so be it.
BSDinstall is shit. I don't care how clean the code is. I don't care how many features it promises to give, someday, maybe, if someone finds the time. I *care* that the installer itself sucks ass. What assclown thought following the RH example of going to a single large root partition by default was a good idea? Was it the same jackass that thought people weren't actually using the custom install options? Perhaps this same moron is the one responsible for removing the choice as to installation media, custom install packages, etc? Was it the same fool who thought that bsdlabel needed replaced by some crap-ass 3rd grade "GUI?" All of this is missing or extremely well hidden in 9.0.
What do I know though. I've only been running FreeBSD in enterprise environments for OVER SIXTEEN YEARS and have supported the project it countless ways. I guess since that didn't include reading some mailing list, I don't have a right to complain.
Here's a free clue for you though, as you come off as someone with a vested interest (perhaps even the author), barring the fact that as an AC you probably won't see this or respond.
It's idiotic to replace a working system with one that doesn't even have 10% of the capability. Replacements for something so basic need to at LEAST achieve feature parity.
Thank gorthak for the druidbsd ISO.
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.
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"