Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
You can't have it both ways.
The eudev project launches
Posted Dec 17, 2012 4:57 UTC (Mon) by Ford_Prefect (subscriber, #36934)
Posted Dec 17, 2012 5:02 UTC (Mon) by rahulsundaram (subscriber, #21946)
Posted Dec 17, 2012 12:24 UTC (Mon) by Ford_Prefect (subscriber, #36934)
Posted Dec 17, 2012 12:39 UTC (Mon) by Ford_Prefect (subscriber, #36934)
Posted Dec 17, 2012 13:58 UTC (Mon) by bagder (subscriber, #38414)
Posted Dec 17, 2012 10:30 UTC (Mon) by ovitters (subscriber, #27950)
Anway, the entire announcement to me is funny. The "Gentoo", but not really, then all the comments about udev. Things which have been pointed out and explained before. Yet still repeated in this announcement.
eudev: the project which is confused and confusing :P
Seems not much was learned after Greg criticized this.
Posted Dec 17, 2012 23:41 UTC (Mon) by rich0 (guest, #55509)
Is eudev officially part of Gentoo? Yes. Does that mean it will ever be the default replacement for udev? Not necessarily.
Eudev does have the official support of Gentoo, but that really amounts to little more than some hosting. They could of course apply for financial support like any other Gentoo project, but such requests are rare, and honestly I'm not sure what it would be needed for here.
Gentoo is a volunteer organization. If somebody wants to work on something, they can. If others think that what they're working on is dumb, they can work on something else. As long as nobody is breaking the law we're fine with that.
Posted Dec 17, 2012 11:52 UTC (Mon) by HelloWorld (subscriber, #56129)
Posted Dec 17, 2012 12:28 UTC (Mon) by Ford_Prefect (subscriber, #36934)
Posted Dec 17, 2012 16:59 UTC (Mon) by HelloWorld (subscriber, #56129)
Posted Dec 17, 2012 23:50 UTC (Mon) by rich0 (guest, #55509)
Something being part of Gentoo simply means that at least one Gentoo developer has decided to work on it.
Gentoo is about choice. There are lots of things that are a part of Gentoo that the average user following the installation handbook will never see. And that's fine.
If you want to run systemd on Gentoo just follow the appropriate howto.
I personally doubt that eudev will ever be the default, but Gentoo users are better off having it as an option.
Posted Dec 18, 2012 0:23 UTC (Tue) by HelloWorld (subscriber, #56129)
Idiocies like the eudev project have nothing to do with offering more (sensible) choices, they have to do with bickering, NIH syndrome, stupidity and people being small-minded and generally pathetic.
Posted Dec 18, 2012 0:52 UTC (Tue) by gfa (subscriber, #53331)
upstart is older than systemd
mkinitramfs is older than dracut
systemd+udev merge does not make any sense, they are just pushing systemd everywhere
/usr on a separate partition has worked for ages (and still works everywhere !fedora)
Posted Dec 18, 2012 1:55 UTC (Tue) by rahulsundaram (subscriber, #21946)
Posted Dec 18, 2012 2:16 UTC (Tue) by HelloWorld (subscriber, #56129)
upstart is older than systemd
mkinitramfs is older than dracut
Whether a project makes sense or not has nothing at all to do with whether it's younger or older than some other project. systemd is a good and useful project despite having been started after upstart because it's technically superior and one couldn't have altered upstart to provide the same functionality without essentially rewriting it from scratch.
eudev otoh is useless. udev works perfectly fine without systemd, and while it's true that udev doesn't support old kernels, it doesn't really matter. Because why would you run a long-obsolete kernel, and yet require a brand-new version of udev?
systemd+udev merge does not make any sense
they are just pushing systemd everywhere
/usr on a separate partition has worked for ages (and still works everywhere !fedora)
Posted Dec 18, 2012 2:50 UTC (Tue) by gfa (subscriber, #53331)
i will just say, Adam Jackson and Poettering on many ocation accused ubuntu (or other distros) to fragment the comunity, while they suffer from NIH sindrome. i haven't see any proof that systemd is better than upstart
the dracut documentation on freedesktop suggest not to implement another initrd maker because dracut is here, the same rationale could be applied to mkinitramfs which is older, extensible and better tested than dracut.
i don't care what fedora/rh guys think about how linux should be. just don't bother us with your bloat, many of us are very happy with sysinit, shell scripts and such. leave our tools alone
udev+systemd is not fine
bye, have a nice life (i do)
Posted Dec 18, 2012 3:03 UTC (Tue) by rahulsundaram (subscriber, #21946)
If you want to understand, the differences between mkinitramfs and dracut, refer to https://lwn.net/Articles/317793/. There is a reason why several distributions have adopted Dracut by default now
If you want to continue using a older init system and shell scripts, you are welcome to.
Posted Dec 18, 2012 3:09 UTC (Tue) by HelloWorld (subscriber, #56129)
Posted Dec 18, 2012 17:51 UTC (Tue) by nix (subscriber, #2304)
Because why would you run a long-obsolete kernel, and yet require a brand-new version of udev?
Posted Dec 18, 2012 18:29 UTC (Tue) by HelloWorld (subscriber, #56129)
Posted Dec 18, 2012 19:14 UTC (Tue) by dlang (✭ supporter ✭, #313)
Posted Dec 18, 2012 20:09 UTC (Tue) by nix (subscriber, #2304)
Posted Dec 18, 2012 22:21 UTC (Tue) by HelloWorld (subscriber, #56129)
Posted Dec 18, 2012 7:02 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Well, udev developers do appear a little bit unstable and it looks like they enjoy conducting cruel medical experiments on unsuspecting users. So maintaining official stable _branches_ of udev with backported fixes and updates would be great idea. Perhaps even a branch with some additional patches for a separate build system, etc.
But that's not what eudev does. Its developers basically took udev, made a few dumb changes (kmod revert), changed license and sticked their names all over the project.
Posted Dec 18, 2012 9:24 UTC (Tue) by GhePeU (subscriber, #56133)
If they think Linux is about choice and they want to spend their time to allow other to choose, who are you to tell them they can't?
Posted Dec 18, 2012 18:44 UTC (Tue) by HelloWorld (subscriber, #56129)
Posted Dec 19, 2012 7:50 UTC (Wed) by GhePeU (subscriber, #56133)
Posted Dec 18, 2012 13:38 UTC (Tue) by nye (guest, #51576)
Then use Windows and strop trolling FFS.
(BTW I think Adam Jackson's poisonous opinion expressed there is probably the single most damaging thing that has been done to Free Software in history; at the very least it is utterly, insanely, disastrously, self-destructively, indefensibly wrong.)
Posted Dec 18, 2012 13:56 UTC (Tue) by nye (guest, #51576)
If we look at the four freedoms defined by the FSF, they are *all* about choice and control - control being essentially the ability to exercise one's choice.
By disavowing choice, one rejects the fundamental ideals of Free Software; by spreading that idea, one is engaged in an attack on the entire concept of Free Software.
This very thread contains numerous examples of attacks on a project for choosing to exercise those freedoms, and it is typical of the 'Linux is not about choice' meme that has been spreading like a cancer for the last few years.
Posted Dec 18, 2012 14:16 UTC (Tue) by rahulsundaram (subscriber, #21946)
Posted Dec 18, 2012 16:29 UTC (Tue) by hummassa (subscriber, #307)
That is the part of the "Linux is not about choice" meme that I don't understand. No distro is made at gunpoint to bear the burden of all the different choices; just the popular ones.
And besides that, if we want to reduce maintenance burden, let's stay with sysvinit (that is, or at least was, pratically stable) and udev (that was pratically stable too, before being integrated into systemd), and try to develop other stuff. But nooooo, wee iss enviousss of OSX's init system, my precioussss....
Posted Dec 18, 2012 17:53 UTC (Tue) by rahulsundaram (subscriber, #21946)
Posted Dec 18, 2012 20:12 UTC (Tue) by nix (subscriber, #2304)
It doesn't hurt you, and it helps others. Why are you so opposed?
Posted Dec 18, 2012 20:29 UTC (Tue) by rahulsundaram (subscriber, #21946)
Posted Dec 20, 2012 15:01 UTC (Thu) by daniels (subscriber, #16193)
I agree, but I also define the ABI as pretty much the entire consumer-visible behaviour of the stack, rather than what's in a header file. Even if you do a straight like-for-like reimplementation, you're bound to end up with subtle differences in behaviour that will trip up unsuspecting users.
Posted Dec 19, 2012 9:13 UTC (Wed) by anselm (subscriber, #2796)
And besides that, if we want to reduce maintenance burden, let's stay with sysvinit (that is, or at least was, pratically stable)
One of the more important selling points of systemd is that it replaces the baroque shell scripts sysvinit uses to control daemons, which are usually distribution-specific and a major nuisance to maintain, with fairly simple declarative configuration files that distributions generally do not need to customise. This has the potential to reduce the maintenance burden in a noticeable way.
Sysvinit is only »stable« because it is essentially dead.
Posted Dec 19, 2012 11:00 UTC (Wed) by hummassa (subscriber, #307)
Neither systemd nor upstart are required to do that. This could have been done by an external tool, something like a streamlined version of start-stop-daemon, or ANYTHING but systemd/upstart. ANYTHING but something that replaces good old stable PID 1 /sbin/init with something not as good nor as old nor as stable.
I would even concede for a streamlined version of sysvinit (like s6 or some other?), something that has LESS funcionality and so, LESS opportunity for bugs.
> Sysvinit is only »stable« because it is essentially dead.
Yes! And as our colleague, nix, tried to say many times on this threads lately, that is A GOOD THING. Dead and stable, that's how you want your PID 1. No old bugs, no new bugs, no bugs. Just work, respawning services, keeping the "current system level", well, level, as it has worked for the last ten years or so, the whole time the machine is turned on. For each and every machine. Everything else is cruft.
Posted Dec 19, 2012 14:57 UTC (Wed) by nix (subscriber, #2304)
That is a *good* property -- even if, as others have pointed out to me, it really does more than a PID 1 needs to, and thus more than it should. Fixing that would also be churn, thus bad, for largely theoretical benefit.
Posted Dec 19, 2012 15:51 UTC (Wed) by andresfreund (subscriber, #69562)
Sure, I also want more emphasis on reliability in critical pieces of software and I think there's quite something going wrong around that atm, but I find the extent of the argument youre making somewhat absurd.
If we were to follow this line of thought the kernel couldn't be developed either, its even more critical to the stability of the system than init.
And we all would be using microkernel designs. We know how well that one went.
Posted Dec 19, 2012 16:16 UTC (Wed) by nix (subscriber, #2304)
Posted Dec 19, 2012 16:43 UTC (Wed) by andresfreund (subscriber, #69562)
But you *do* run new kernels, right? I think where I am left behind is the focus on init stability where that has to mean years of essentially not being touched at all while other essential parts are allowed to change in non-fundamental ways.
Note that for now I strive to avoid running systemd on essential systems as well as long as it doesn't mean significantly diverting from what the distro I have to use normally uses (and tests for) or what the local admins know well. Both has a higher chance of causing critical problems in my experience... But thats because it is - like btrfs - "fundamentally new" and not yet "incrementally new".
Posted Dec 19, 2012 17:00 UTC (Wed) by nix (subscriber, #2304)
I run new-ish kernels, I have to to get security fixes unless I want to run an ancient distro kernel or backport the fixes myself: I don't as a rule run anything that hasn't come out of the stable tree, on the grounds that this has had a lot more people running it than something that's just emerged from -rc: and even so it goes wrong about a third of the time when jumping to a new major kernel release and I have to scramble back down and submit a bug report, so if I could I would upgrade less often. (And sometimes it goes wrong on non-major upgrades within a single stable series, e.g. the ext4 corruption flap, though even that was actually introduced over a major version hop and I was just lucky not to get bitten for a few major releases. I have been bitten by typos and other bugs within stable series repeatedly, too.)
Upgrading the kernel brings not only security fixes -- so I have no choice but to upgrade -- but brings other advantages with it; right now, I'm seeing substantial increases in performance of my desktop's graphics card on every kernel release due to improvements in the Radeon KMS code. Changes to init bring what advantages? init does everything I need of it. Indeed, as I said, it could be argued that it does too much.
(For that matter, even if I had run a distro kernel until recently, I'd have been forced to stop, because e.g. Debian is still on 3.2.x and most distros are even older, and those kernels are too old to support said graphics card so I'd have lost X support, which I value rather a lot.)
Posted Dec 19, 2012 18:57 UTC (Wed) by man_ls (guest, #15091)
Posted Dec 19, 2012 19:33 UTC (Wed) by nix (subscriber, #2304)
Posted Dec 19, 2012 20:04 UTC (Wed) by andresfreund (subscriber, #69562)
That attitude makes me hell of a lot more forgiving/accepting when facing problems or not totally thought through designs.
Posted Dec 21, 2012 2:45 UTC (Fri) by mathstuf (subscriber, #69389)
I have less issues than that running Rawhide. Is this on your development machine(s) or some special use-cased machine (e.g., database server, heavily loaded machine, etc.)? Do you typically do development closer to the kernel such that it matters more? The things I use constantly that depend highly on the kernel tend to be VirtualBox-OSE or GPU drivers. Other than that, GCC, Python, and Boost are probably my biggest on-upgrade problem causers.
Posted Dec 21, 2012 9:35 UTC (Fri) by nix (subscriber, #2304)
I'd say that 90% of the issues on that machine have been NIC related. If I could have gone back in time to the time I bought the box and picked something other than an e1000e, I would have -- not only did this allegedly server-class box (with ECCRAM and hardware RAID) come with what turned out to be workstation-class 82574Ls wired into the motherboard, the things have had at least two nasty (link dead after a while, reboot required) unfixable firmware bugs requiring driver workarounds, and have had at least three bugs in the drivers breaking things like jumbo frames (which doesn't seem too bad until you realise that the *other* machines on the same subnet will still be using jumbo frames, whoops). I actually have to keep an eye on the log for drivers/net/e1000e these days to make sure that nothing *else* broke on each release. Probably as many as 75% of my upgrade problems come down to that one model of NIC on that one machine. (And yes, I report these problems when uncovered unless someone else has done so first.)
Perhaps the out of tree drivers would work better, but I have a general rule never to use out of tree drivers unless absolutely unavoidable -- the pain factor is just too high, particularly since I prefer non-modular kernels, especially for something critical to system function like the network card.
The question is, are there any gigabit NICs out there which don't suck? r8169 seems OK at first sight but has had rumours of very bad performance in the past, and even security problems where people able to send arbitrary Ethernet packets can cause the card to DMA over arbitrary memory.
'cos it's sort of stupid that with all this advanced and complex hardware in modern machines, and with rarely-used stuff like an Areca RAID card in one machine, the piece of hardware which causes me most trouble is not any of that but a widely-used model of NIC.
Posted Dec 21, 2012 17:50 UTC (Fri) by mathstuf (subscriber, #69389)
I did had to keep building the rtl8192se drivers from staging to get my netbook to do much of anything with wireless (and they were flaky, but that's better than nothing). Luckily it's upstream now and the only problem has been that I had a wired interface listed first in the list of interfaces wpa_supplicant was to manage (who knew that wired interfaces didn't support WPA2 :) ). Other than that, things have been fairly solid from kernel land.
As for non-sucky gigabit NICs, I think my desktop machines have the support, but I don't think the rest of the stuff I use supports it, so maybe the gigabit-ness parts never got tickled.
Posted Dec 19, 2012 18:08 UTC (Wed) by hummassa (subscriber, #307)
This is statistically equivalent to saying "no bugs"; it's like saying "today a meteor will not end all life on Earth" when the rigorous phrasing would be "with 99,99% certainty, there is a probability of less then 0,00001% that a meteor will today end all life on Earth".
But re-reading my post, I understand that it can be construed as saying "nix said that sysvinit has no bugs at all". And, for the record, you didn't, so I stand corrected!
Posted Dec 19, 2012 19:41 UTC (Wed) by nix (subscriber, #2304)
Posted Dec 20, 2012 15:50 UTC (Thu) by hummassa (subscriber, #307)
Posted Dec 18, 2012 19:44 UTC (Tue) by HelloWorld (subscriber, #56129)
Now this is something that most people don't seem to grok: Just because it's a good thing we're allowed to do something doesn't mean it's a good idea to do it. There are dozens of examples for this, both within and outside of software development. I leave it up to you to think of a few.
And this applies here. Being allowed to fork is a good thing. But there's a cost associated with forks and it's larger than most people seem to realise, and thus people should think long and hard before forking. The eudev maintainers don't give me the impression of having done that.
Posted Dec 18, 2012 15:45 UTC (Tue) by Wol (guest, #4433)
The fact that far too many people with a voice but no ears started screaming "4.0 - new - shiny - but where are the apps?" wasn't KDE's fault. Maybe they should have called it 3.99.
Posted Dec 18, 2012 20:17 UTC (Tue) by HelloWorld (subscriber, #56129)
> Maybe they should have called it 3.99.
Posted Dec 20, 2012 19:40 UTC (Thu) by Jandar (subscriber, #85683)
KDE got a huge amount of flak even though the beta-status of 4.0 was announced beforehand.
excerpt from http://www.commit-digest.org/issues/2007-12-30/ :
Before everyone starts to spread their opinion about KDE 4.0, let me spread some reminders:
KDE 4.0 is not KDE4 but only the first (4.0.0 even non-bugfix) release in a years-long KDE 4 series to come.
KDE 4.0 is known to have missing parts or temporary implementations (eg. printing, PIM, Plasma).
Most changes happened under the surface and cannot be discovered in a "30 minutes usage" review anyway.
User interfaces being unchanged in 4.0 compared to 3.5 may be still changed/improved during KDE 4 life time.
KDE 4.0 will not be the fastest KDE 4 release - like for KDE 2 most speed optimizations will happen later during KDE 4.
Most applications (many are not even fully ported yet) will take only advantage of new features which the new Qt/KDE libraries offer later.
Don't measure portability success (eg. MS Windows) by current availability of application releases, they will come.
KDE 4.0 is only expected to be used by early adopters, not every KDE 3.5 user (and IMHO KDE 4.0 shouldn't be pushed onto other user types like planned for Kubuntu ShipIt (which by the way is said to have only 6 months support for its packages)).
KDE 4.1 development will not require the same amount of time as the big technology jump of KDE 4.0: expect KDE 4.1 later this year.
Last, again: KDE 4.0 is not KDE 4.
Posted Dec 20, 2012 20:02 UTC (Thu) by bronson (subscriber, #4806)
The KDE4 lesson is simple: if something's not ready for release, don't put a .0 on it.
People don't read disclaimers. Nor should they have to.
Posted Dec 20, 2012 22:14 UTC (Thu) by Jandar (subscriber, #85683)
Average people shouldn't forced to read disclaimers but distribution maintainers should. Distributing KDE 4.0 was a irresponsible decision for any distribution catering normal users.
Posted Dec 20, 2012 21:07 UTC (Thu) by HelloWorld (subscriber, #56129)
Posted Dec 20, 2012 21:12 UTC (Thu) by HelloWorld (subscriber, #56129)
> KDE 4.0 is only expected to be used by early adopters
An early adopter is *not* a beta tester and shouldn't be treated as such.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds