×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Gentoo Developers Fork udev

Unknown Lamer posted about a year and a half ago | from the lennart-vows-revenge dept.

Open Source 152

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

152 comments

What is udev? (-1)

Anonymous Coward | about a year and a half ago | (#42005939)

And how do you fork something that's already a part of your OS?? Just don't include it, if it's such an issue

Re:What is udev? (3, Informative)

Anonymous Coward | about a year and a half ago | (#42006021)

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*

You can't not install it. (0)

Anonymous Coward | about a year and a half ago | (#42006833)

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.

Re:You can't not install it. (2)

ardor (673957) | about a year and a half ago | (#42007917)

3. it's basic design is an attempt to create a solution to an NP complete problem.

Which is?

Re:You can't not install it. (0)

Anonymous Coward | about a year and a half ago | (#42008837)

#2: you can start syslog-ng as a systemd service.

Thanks (0)

Anonymous Coward | about a year and a half ago | (#42006025)

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.

Re:Thanks (1)

Gordonjcp (186804) | about a year and a half ago | (#42010857)

If I could only get that sorted out on my laptop, I could save myself as much as five minutes a year!

Compiling Responses... (0)

Anonymous Coward | about a year and a half ago | (#42006039)

/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'

Append NG (1)

Sponge Bath (413667) | about a year and a half ago | (#42006045)

Stick a fork in it, it's not done.

Re:Append NG (5, Interesting)

Paradigm_Complex (968558) | about a year and a half ago | (#42006811)

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.

Re:Append NG (4, Interesting)

Anonymous Coward | about a year and a half ago | (#42009307)

I'm surprised nobody has suggested the -og suffix.

Re:Append NG (-1)

Anonymous Coward | about a year and a half ago | (#42009605)

Somebody mod this nigga up.

Thumbs down on the name (0, Insightful)

Anonymous Coward | about a year and a half ago | (#42006101)

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.

Re:Thumbs down on the name (5, Insightful)

icebike (68054) | about a year and a half ago | (#42006167)

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?

Re:Thumbs down on the name (3, Informative)

LordLimecat (1103839) | about a year and a half ago | (#42006555)

It really does seem like theyve gone a bit crazy.... heres a snippet from a bug report [redhat.com] 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.

Re:Thumbs down on the name (0)

Anonymous Coward | about a year and a half ago | (#42007233)

you are misreading that. you may want to look up the word async, and the concept of blocking.

Re:Thumbs down on the name (2)

segedunum (883035) | about a year and a half ago | (#42007483)

Kay seems to be throwing asynchronous around as a 'solution' very liberally. It all sounds very node.js............

Re:Thumbs down on the name (0)

Anonymous Coward | about a year and a half ago | (#42009489)

Asynchronous = Soy nacho urns sometimes...it's only a good solution when you don't care

http://www.wordsmith.org/anagram/anagram.cgi?anagram=asynchronous&t=1000&a=n

not impossible, but breaks existing drivers (5, Informative)

Chirs (87576) | about a year and a half ago | (#42007747)

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.

Re:not impossible, but breaks existing drivers (1)

rtfa-troll (1340807) | about a year and a half ago | (#42010695)

Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code .

There FTFY. This can never be said loudly enough. If you don't believe me, please at least believe Donald Knuth [w3.org]

I wonder where all these people got the idea that breaking software is a good idea? Apple used to (and probably still does) break backwards compatibility. However they did this; for unpublished interfaces; where they gave warnings not to use them; where they broke them regularly and where they had a reasonable alternative that worked. That is the only exception; you told people from the very beginning, very explicitly not to do the thing that you are about to stop them doing. You also told them explicitly how to avoid it.

You must always make it possible for the old way to work in parallel with the new way. You have no idea how and where your software is used and why someone may need to keep it working in the old way and for how long. You may not be willing to maintain the old way, but you must leave space for someone else to do that.

Re:not impossible, but breaks existing drivers (1)

iive (721743) | about a year and a half ago | (#42010971)

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.

No, this is not reasonable positions and these modules were not broken in any arguable fashion.

First, udev didn't block firmware loading until filesystems are activated. It blocked until the parent module init completes.

The case scenario happened with a dvb-c/t capture dongle. It consist of (among other things) USB multimedia controller (em28xx), demodulator that needs firmware (drx-k) and tuner connected to the demodulator (all with separate modules).
The problem is that in order to finish the initialization, the device needs to know what the tuner is, but it can't init the tuner until the firmware is loaded. However if the firmware is blocked by udev until em28xx finishes init, we just get a deadlock (that is resolved by 30 second timeout). To avoid this deadlock, the driver have to stop init at firmware loading, create the device files pretending that it knows what the actual device is. When it is opened, it would load the firmware, finish the init. The minor problem is what happens if at this point it finds out that the tuner is not supported and thus the whole device is not supported.
There is a reason why device initialization must be done at initialization.

Actually, there is no case where a firmware could be loaded and its loading would cause any kind of problem. Yet udev enforced completely unneeded serialization, that prevented exactly that.

As for having to load only the firmware from the filesystem? Why would you do that? If you compile-in module, then do the same with the firmware. And if you don't, then load the firmware from the same filesystem as the module.

Re:Thumbs down on the name (1)

Anonymous Coward | about a year and a half ago | (#42007781)

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.

Re:Thumbs down on the name (0)

Anonymous Coward | about a year and a half ago | (#42010269)

Nice doesn't enter into it? Thanks for the warning. Wasn't there a discussion recently about kernel developers being an aging bunch? Well, if not needlessly pissing each other off isn't part of the etiquette, who is going to want to work with them? Taking over someone else's name by sticking -ng on the end isn't forking. It's being an ass. You don't have to be loyal and keep using their software if you don't want to. Just don't proclaim that you're the future ("next generation") of a project that isn't yours. A proper fork should distinguish itself by name as well.

Re:Thumbs down on the name (1)

Anonymous Coward | about a year and a half ago | (#42006189)

"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.

Re:Thumbs down on the name (2)

LordLimecat (1103839) | about a year and a half ago | (#42006337)

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.

Re:Thumbs down on the name (1, Offtopic)

Gaygirlie (1657131) | about a year and a half ago | (#42009111)

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.

Re:Thumbs down on the name (2)

dbIII (701233) | about a year and a half ago | (#42009723)

You missed the article here about it not dealing with a large proportion of well known existing malware?

Re:Thumbs down on the name (1)

Anonymous Coward | about a year and a half ago | (#42006447)

Usually, NG is an abbreviation for "No Good".

Re:Thumbs down on the name (0)

Anonymous Coward | about a year and a half ago | (#42006593)

Usually, NG is an abbreviation for "No Good".

...where?

Re:Thumbs down on the name (2)

bipbop (1144919) | about a year and a half ago | (#42006925)

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.

Re:Thumbs down on the name (2)

PReDiToR (687141) | about a year and a half ago | (#42007237)

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".

Re:Thumbs down on the name (1)

mlts (1038732) | about a year and a half ago | (#42006577)

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.

Re:Thumbs down on the name (4, Funny)

Anonymous Coward | about a year and a half ago | (#42006249)

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.

Re:Thumbs down on the name (2, Informative)

Anonymous Coward | about a year and a half ago | (#42006529)

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.

Re:Thumbs down on the name (0)

Anonymous Coward | about a year and a half ago | (#42006979)

-ng is really 'New Gentoo' not 'Next Generation' :)

Re:Thumbs down on the name (1)

dbIII (701233) | about a year and a half ago | (#42009749)

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).

Re:Thumbs down on the name (1)

sjames (1099) | about a year and a half ago | (#42007099)

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.

We have not made an official announcement yet (5, Informative)

Anonymous Coward | about a year and a half ago | (#42006113)

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.

Re:We have not made an official announcement yet (2, Insightful)

Anonymous Coward | about a year and a half ago | (#42006441)

I want to thank Gentoo for not accepting this buggy piece of crap called systemd and all the unholy sh-- it depends on. It's great that there are still people left who have a good understanding how Unix(oid) is supposed to work.

Re:We have not made an official announcement yet (5, Interesting)

Anonymous Coward | about a year and a half ago | (#42008041)

There's plenty of us here watching from afar with large grins on our face.

Hello from FreeBSD, NetBSD, DragonflyBSD, and OpenBSD.

Re:We have not made an official announcement yet (1)

Anonymous Coward | about a year and a half ago | (#42008863)

Ah, yes, does your USB hotplugging works yet?

Re:We have not made an official announcement yet (3, Informative)

m6tt (263581) | about a year and a half ago | (#42009557)

Works great...we even have non-udevd based automount, with custom mount flags...does that still require hacking and a recompile?

How's pulseaudio working out for you?

Re:We have not made an official announcement yet (5, Funny)

Anonymous Coward | about a year and a half ago | (#42010637)

how's pulse audio working out for you?

Sorry. Could you repeat that? I can't hear a damn thing!

Re:We have not made an official announcement yet (2)

Lotana (842533) | about a year and a half ago | (#42011041)

How's pulseaudio working out for you?

Touche.

Re:We have not made an official announcement yet (1)

m6tt (263581) | about a year and a half ago | (#42009577)

Maybe Linux could use FreeBSD's devd...at least it's documented...

Re:We have not made an official announcement yet (2)

A bsd fool (2667567) | about a year and a half ago | (#42010097)

It's also not inexcusably stupid. All it does is match up PCI device IDs and then run a command like.. say.. kldload, which in turn manages all the firmware loading itself without "help" from some bogus daemon.

Re:We have not made an official announcement yet (0)

Anonymous Coward | about a year and a half ago | (#42011029)

Heh, yeah but those are all pieces of shit.

Re:We have not made an official announcement yet (0)

Anonymous Coward | about a year and a half ago | (#42008161)

It's way the fuck faster though, so hopefully people patch it.

Re:We have not made an official announcement yet (1)

Rich0 (548339) | about a year and a half ago | (#42009755)

Well, systemd is in fact packaged and working on Gentoo - in fact I use it on a Gentoo VM. Gentoo is, after all, about choice.

I see the fork as being positive in that regard - keeps everybody honest and gives the end user more choices. As long as somebody is willing to maintain it, Gentoo will accept it.

just call it udev (4, Insightful)

Anonymous Coward | about a year and a half ago | (#42007069)

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"

Re:just call it udev (0)

Anonymous Coward | about a year and a half ago | (#42009283)

I like [...] journald

You've clearly lost the fucking plot then... I was going to write this comment in binary since you stated your preference but concluded that it might be more readable in text form.

Re:We have not made an official announcement yet (1)

Bent Mind (853241) | about a year and a half ago | (#42009431)

I masked all versions of udev above 171 because of the /usr merge. There are some nice things that udev does, mainly ensure consistent matching of device names to actual hardware. However, (for any of my systems anyway) the plug-and-play stuff isn't really needed until after the OS is up and running. I really don't need the system to do anything with random USB thumb drives or game controllers at boot time. The thought had occurred to me to simply go back to a static /dev.

I've looked into alternatives. There is tmpfs-based /udev support in the kernel that seems to work well (minus security settings). mdev, from busybox, seems to work well. I've also looked at mudev [google.com] , though not much past the project page.

If Gentoo devs are forking udev into a new project that supports separate disk partitions for root directories, then I'll fully support and install it.

Lol (0)

Anonymous Coward | about a year and a half ago | (#42006137)

Uh oh! Lennart isn't gonna like this! His butthurt should be funny nonetheless.

Wow, that was harsh even for Linus! (1)

Medievalist (16032) | about a year and a half ago | (#42006147)

I had trouble with udev 182 and 187 myself, I had no idea they were so widespread.

So that's why my system would hang at boot (4, Informative)

semi-extrinsic (1997002) | about a year and a half ago | (#42006185)

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!"

Yea! (4, Interesting)

Anonymous Coward | about a year and a half ago | (#42006257)

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?

Sponsored by Gentoo - not a good thing (-1)

Anonymous Coward | about a year and a half ago | (#42006271)

It's Gentoo!
It will compile forever. I'll come back after Christmas to see if it's done.

Re:Sponsored by Gentoo - not a good thing (0)

Anonymous Coward | about a year and a half ago | (#42006553)

Hope they have lots of USE flags for us Gentoo ricers! ZRRRROOOOOM!!!

Re:Sponsored by Gentoo - not a good thing (0, Funny)

Anonymous Coward | about a year and a half ago | (#42007073)

USE=" -redhat-crap everythingcoolnfast"

Systemd. Still the root of all ... Stupidity (0)

Anonymous Coward | about a year and a half ago | (#42006325)

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.

Re:Systemd. Still the root of all ... Stupidity (5, Interesting)

Anonymous Coward | about a year and a half ago | (#42006603)

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 [lkml.org] :

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?

Re:Systemd. Still the root of all ... Stupidity (1)

Anonymous Coward | about a year and a half ago | (#42006889)

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.

Re: Yes Lennart Realy is that Loony (3, Insightful)

segedunum (883035) | about a year and a half ago | (#42007205)

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?

Re: Yes Lennart Realy is that Loony (3, Insightful)

segedunum (883035) | about a year and a half ago | (#42007255)

.....In the long and broken road to PulseAudio broken Linux drivers are a very recurring theme.................

Re: Yes Lennart Realy is that Loony (3, Interesting)

KiloByte (825081) | about a year and a half ago | (#42009309)

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.

Re: Yes Lennart Realy is that Loony (1)

Rich0 (548339) | about a year and a half ago | (#42009761)

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.

Re: Yes Lennart Realy is that Loony (1)

Anonymous Coward | about a year and a half ago | (#42010953)

avahi is also now required by cupsd :(

Re:Systemd. Still the root of all ... Stupidity (3, Interesting)

Chirs (87576) | about a year and a half ago | (#42007851)

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.

Re:Systemd. Still the root of all ... Stupidity (1)

Anonymous Coward | about a year and a half ago | (#42008123)

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.

Re:Systemd. Still the root of all ... Stupidity (3, Informative)

Carnildo (712617) | about a year and a half ago | (#42009091)

Why? Doesn't the system need some sort of root fs to boot? I am asking out of ignorance and curiosity, nothing else.

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.

Re:Systemd. Still the root of all ... Stupidity (-1)

Anonymous Coward | about a year and a half ago | (#42008649)

...

Unfortunately it breaks a number of (arguably misbehaving) modules, and among most linux kernel developers it is a BIG DEAL to break existing code.

Well, it damn fucking well OUGHT to be a BIG DEAL to deliberately break existing code - especially when it involves going off on your own, after you're told your idea is crazy.

Gotta be an arrogant, full-of-yourself preening jackass to do something like that.

Re:Systemd. Still the root of all ... Stupidity (0)

Anonymous Coward | about a year and a half ago | (#42009195)

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.

Re:Systemd. Still the root of all ... Stupidity (0)

Anonymous Coward | about a year and a half ago | (#42010451)

Is this the recursive full-of-yourself preening jackass loop?

Re:Systemd. Still the root of all ... Stupidity (0)

Anonymous Coward | about a year and a half ago | (#42007589)

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.

Re:Systemd. Still the root of all ... Stupidity (1)

Anonymous Coward | about a year and a half ago | (#42007883)

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.

Re:Systemd. Still the root of all ... Stupidity (0)

Anonymous Coward | about a year and a half ago | (#42010369)

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?

"informative flamewar" (1)

Anonymous Coward | about a year and a half ago | (#42006661)

"informative flamewar"

I literally LOLed.

no wonder M$ survives.. (0)

Anonymous Coward | about a year and a half ago | (#42006721)

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?

Re:no wonder M$ survives.. (0)

Anonymous Coward | about a year and a half ago | (#42007083)

the 2.4-early 2.6 era devfs, which handled basically everything inside the kernel, but had no real configurability, and required per-module changes to make device nodes show up.

Honestly I really loved devfs since it handled everything automagically, but hated it because adding new drives/modules and such could fsck up disk ids for purposes of booting.

My initial dislike of udev appears to have been founded however given the mess that it's turned into since (initially hating it for the lack of backwards compatibility throughout the 2.6 kernel series, making it a nightmare to test for driver regressions since your userspace had to be reverted to an earlier configuration as well.

And fdisk devs break it, too. (0)

Anonymous Coward | about a year and a half ago | (#42006921)

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.

Re:And fdisk devs break it, too. (1)

0123456 (636235) | about a year and a half ago | (#42007673)

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.

Re:And fdisk devs break it, too. (0)

Anonymous Coward | about a year and a half ago | (#42009113)

Current fdisk for Linux, on the other hand, has a minimum sector of 2048.

Is this true? Jesus. Not long ago, I used a years-old version of fdisk to partition a new 4k-block disk. Keeping in mind the alignment issue, I chose to start the partition at sector 64 (instead of the default 63). I realize that 2048 is better suited for SSDs with huge pages (where the kernel can't even reliably determine the page size on many of these devices). But to enforce 2048 as a minimum sector for all devices is absurd.

It would be nice to plonk some developers... (0)

Anonymous Coward | about a year and a half ago | (#42007133)

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.

xfree86 got kicked to curb by xorg (2, Interesting)

knorthern knight (513660) | about a year and a half ago | (#42007137)

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 [slashdot.org] 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.

not an undocumented format (1)

Chirs (87576) | about a year and a half ago | (#42007881)

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.

Re:not an undocumented format (2)

whoever57 (658626) | about a year and a half ago | (#42007999)

As it stands it's actually quite tricky to automatically sort through a kernel log stream looking for critical events to raise alarms over.

Really? Logwatch seems to do an effective job of this.

Re:not an undocumented format (1)

t0rkm3 (666910) | about a year and a half ago | (#42008623)

Huh... That's weird cuz I have stuff that parses about 150,000 syslog/sec without it being a binary format... So WTF?

When I read about journald I about shit my pants that some asshole was trying to make linux more like windows.

Re:not an undocumented format (1)

A bsd fool (2667567) | about a year and a half ago | (#42009775)

I was going to provide an example of a regex demonstrating how impossibly *easy* syslog is to parse, but /. says "use fewer junk characters."

That's not junk, it's perl dammit! :P

Re:xfree86 got kicked to curb by xorg (1)

Anonymous Coward | about a year and a half ago | (#42010361)

Everything Lennart touches turns into a pile of shit. He should be the villain in a bond movie or something.

I trust the Gentoo devs (1)

SealBeater (143912) | about a year and a half ago | (#42007529)

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!

Re:I trust the Gentoo devs (0)

Anonymous Coward | about a year and a half ago | (#42007959)

Oh yeah...the /usr merge is another of the *brilliant* RH ideas. The Gentoo community has been up in arms about this one too.

This is why... (5, Interesting)

A bsd fool (2667567) | about a year and a half ago | (#42008479)

...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.

This is why BSD people hate udev (0)

Anonymous Coward | about a year and a half ago | (#42008993)

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.

Systemd really that bad? (1)

Anonymous Coward | about a year and a half ago | (#42010007)

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.

Re:Systemd really that bad? (1)

Anonymous Coward | about a year and a half ago | (#42010567)

Really? It's one line on FreeBSD, why do Linux admins want to work so hard?

Re:Systemd really that bad? (0)

Anonymous Coward | about a year and a half ago | (#42010699)

Well I see that the systemd file only knows how to start and terminate the service, whereas the init.d script has much more functionality. Plus about 80 lines of comments.

Re:Systemd really that bad? (0)

Anonymous Coward | about a year and a half ago | (#42010839)

And how many extra lines did I need to add that functionality? 5... well most of it, but w/e. I'm just saying its at least some sign of progress. And yea, BSD still wins, so there :P

Re:Systemd really that bad? (0)

Anonymous Coward | about a year and a half ago | (#42010861)

Yes, systemd really is that bad (the implementation anyway). It started with some good ideas then branched out too far.

Re:Systemd really that bad? (2, Insightful)

Anonymous Coward | about a year and a half ago | (#42011027)

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.

Arch Linux switched to systemd (2)

bzipitidoo (647217) | about a year and a half ago | (#42010869)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...