Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
The eudev project launches
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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (guest, #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 (subscriber, #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 (guest, #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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds