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*
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.
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
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.
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.
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?
In this projects IRC channel, someone proposed appending a -pg to it, since the point of this fork is to revert udev to what it was before it went insane. I find this prospect quite amusing and hope it picks up.
"A witty saying proves nothing." - Voltaire
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"
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 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.
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.
Really? Logwatch seems to do an effective job of this.
The real "Libtards" are the Libertarians!
...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.
I'm surprised nobody has suggested the -og suffix.
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?
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"
Answered with no evidence (or even really an example) to support your claim? Oh internets. How exactly, as in practical terms, have they 'branched out too far'? I don't think its perfect by a long stretch but there are serious practical gains to using systemd for servers that require custom configuration and can't rely on stock implementations, saves me time so I guess I'm happy with that.
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.
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.
Ah I see the problem, you're using AUFS ... you should be using Union Mounts since that's the one right way. The code for them will be ready real soon now ...
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!