The eudev project launches

Posted Dec 18, 2012 0:23 UTC (Tue) by HelloWorld (guest, #56129)
In reply to: The eudev project launches by rich0
Parent article: The eudev project launches

> Gentoo is about choice.
I can't stand this "choice" crap any more. Adam Jackson put it better than I could:
http://www.redhat.com/archives/rhl-devel-list/2008-Januar...

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.

to post comments

The eudev project launches

Posted Dec 18, 2012 0:52 UTC (Tue) by gfa (guest, #53331) [Link] (11 responses)

need to 's/eudev/redhat/' for your comment to make any sense

proof:

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)

The eudev project launches

Posted Dec 18, 2012 1:55 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Can we stop with separate /usr misconceptions already? It works in Fedora as well as it does in other distributions and systemd or udev does NOT affect that in any way. Rest of what you said is basically irrelevant to the discussion.

The eudev project launches

Posted Dec 18, 2012 2:16 UTC (Tue) by HelloWorld (guest, #56129) [Link] (8 responses)

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

This is a development issue and thus should be left up to the systemd/udev maintainers.

they are just pushing systemd everywhere

How so? Udev works perfectly fine without systemd.

/usr on a separate partition has worked for ages (and still works everywhere !fedora)

The "separate /usr" thing has nothing, zilch, nada to do with systemd or udev, both work perfectly fine without /usr. The only difference between systemd and upstart/sysvinit in this regard is that systemd prints a warning (which you can choose to ignore).
There are things that break when /usr isn't mounted during early boot, though perhaps it doesn't affect your system. Do you really think Poettering makes that kind of stuff up just to piss people off?
Fedora supports a separate /usr partition just fine by mounting it inside the initramfs during early boot.

Get your facts straight next time before making random false accusations.

The eudev project launches

Posted Dec 18, 2012 2:50 UTC (Tue) by gfa (guest, #53331) [Link] (2 responses)

i won't reply all your comments, because is boring.

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
http://lists.freedesktop.org/archives/systemd-devel/2012-...

bye, have a nice life (i do)

The eudev project launches

Posted Dec 18, 2012 3:03 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

You haven't provided any reference for your claims about Adam Jackson and I suspect you don't have any and just made that up. Also, you seem to misunderstand the link you have provided which has nothing to do with separate /usr and there isn't any Fedora specific issue here.

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.

The eudev project launches

Posted Dec 18, 2012 3:09 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Ah, trolls. They just don't make them like they used to any more :(

The eudev project launches

Posted Dec 18, 2012 17:51 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

Because why would you run a long-obsolete kernel, and yet require a brand-new version of udev?

Because new versions of udev contain new libudev APIs, and applications can depend on those. Were it not for eudev, we'd be required to upgrade the kernel in order to run such applications. This sort of tight coupling is not good. (Well, OK, some people seem to think that the tighter the coupling, the better, but I very much hold with the traditional viewpoint that loose coupling is to be preferred.)

The eudev project launches

Posted Dec 18, 2012 18:29 UTC (Tue) by HelloWorld (guest, #56129) [Link] (3 responses)

> Because new versions of udev contain new libudev APIs, and applications can depend on those. Were it not for eudev, we'd be required to upgrade the kernel in order to run such applications.
You have a point, but I don't think that this is a good reason to fork udev. As Cyberax pointed out (https://lwn.net/Comments/529570/), that kind of thing can be done within a branch. Git makes this kind of work flow quite easy, and eglibc has shown that such an approach can work.

The eudev project launches

Posted Dec 18, 2012 19:14 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

There's no difference between a branch that's managed by different people and a fork.

The eudev project launches

Posted Dec 18, 2012 20:09 UTC (Tue) by nix (subscriber, #2304) [Link]

Quite. That is to say, there is no difference *at all* -- the version control system model is identical. The people behind this just think that saying 'eudev' is easier than saying 'the Gentoo udev git repository' all the time.

The eudev project launches

Posted Dec 18, 2012 22:21 UTC (Tue) by HelloWorld (guest, #56129) [Link]

I disagree. PREEMPT-RT is a branch, it's not maintained by Linus, but it's not what I'd call a fork either.

The eudev project launches

Posted Dec 18, 2012 7:02 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

It's OK to fork a project if it's dead or if its maintainers are too slow/abusive/unresponsive. Nobody really argued that forking glibc by Debian was a hostile move because glibc's maintainers were well known for their, shall we say, nice demeanor. However, in this case udev's upstream is responsive and mostly sane. I've been following udev's mailing lists and it appears that they have a normal working relationship with distributions.

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.

The eudev project launches

Posted Dec 18, 2012 9:24 UTC (Tue) by GhePeU (subscriber, #56133) [Link] (2 responses)

Who died and made Adam Jackson supreme guide?

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?

The eudev project launches

Posted Dec 18, 2012 18:44 UTC (Tue) by HelloWorld (guest, #56129) [Link] (1 responses)

> 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?
I only said that I think it's a stupid idea. In what universe does that imply I'm telling people what they can or can't do?

The eudev project launches

Posted Dec 19, 2012 7:50 UTC (Wed) by GhePeU (subscriber, #56133) [Link]

Oh, sorry. My delicate sensibility was so distracted by the pile of abuse you showered on the eudev developers that I must have misinterpreted what you were trying to say. Of course you're perfectly ok with other people spending their time how they want, how could I have thought otherwise.

The eudev project launches

Posted Dec 18, 2012 13:38 UTC (Tue) by nye (subscriber, #51576) [Link] (24 responses)

>I can't stand this "choice" crap any more. Adam Jackson put it better than I could:

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

The eudev project launches

Posted Dec 18, 2012 13:56 UTC (Tue) by nye (subscriber, #51576) [Link] (23 responses)

I'll expand upon this a little.

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.

The eudev project launches

Posted Dec 18, 2012 14:16 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (21 responses)

If you are look at the context, we are not talking about individual freedoms to fork which is what FSF is all about but the cost of forks in terms of integration, interface compatibility, bug fixes etc and that is often something that is overlooked. If you are willing to take up all the cost of the fork singularly, that's fine and it's your freedom to do so but when you are asking other developers or distributions to support two or three different alternatives at the same time, that is a maintenance burden and something we need to work on reducing.

The eudev project launches

Posted Dec 18, 2012 16:29 UTC (Tue) by hummassa (guest, #307) [Link] (20 responses)

> that is a maintenance burden and something we need to work on reducing.

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

The eudev project launches

Posted Dec 18, 2012 17:53 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

It is not just the distributions that have to deal with it. It is also developers and ISV vendors and so on. It affects the entire ecosystem. forks in system components often have a serious cost. systemd isn't a fork and you are utterly silly if really think Fedora, SUSE, RHEL, Arch Linux etc are switching to it because of OS X envy.

The eudev project launches

Posted Dec 18, 2012 20:12 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

Forks in system components have a serious cost if they have ABIs or APIs on which a lot of things depend, and if those APIs diverge. Neither of these things are true of udev/eudev, and udev's constant churn and endlessly changing requirements is *already* having a serious enough cost on a lot of people that we have ceased updating some time ago. I am personally glad that some development is being done by people who care about the cost of upgrade to people who may not have Fedora's resources or Fedora's apparent happiness with breaking booting every five minutes when upgrades happen.

It doesn't hurt you, and it helps others. Why are you so opposed?

The eudev project launches

Posted Dec 18, 2012 20:29 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Someone asked why forks can be a problem and I answered that. The concerns over eudev are quite different and has been thoroughly addressed already. Let's not rehash that here.

The eudev project launches

Posted Dec 20, 2012 15:01 UTC (Thu) by daniels (subscriber, #16193) [Link]

> Forks in system components have a serious cost if they have ABIs or APIs on which a lot of things depend, and if those APIs diverge.

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.

The eudev project launches

Posted Dec 19, 2012 9:13 UTC (Wed) by anselm (subscriber, #2796) [Link] (15 responses)

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.

The eudev project launches

Posted Dec 19, 2012 11:00 UTC (Wed) by hummassa (guest, #307) [Link] (14 responses)

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

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.

The eudev project launches

Posted Dec 19, 2012 14:57 UTC (Wed) by nix (subscriber, #2304) [Link] (13 responses)

I'm not willing to go so far as to say that sysvinit has no bugs. It has no bugs that any significant number of people ever encounter, and it is reasonable to say after this long that it never will.

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.

The eudev project launches

Posted Dec 19, 2012 15:51 UTC (Wed) by andresfreund (subscriber, #69562) [Link] (9 responses)

If we were to follow that argument, we a) wouldn't have sysvinit today, b) cannot ever improve upon the status quo?

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.

The eudev project launches

Posted Dec 19, 2012 16:16 UTC (Wed) by nix (subscriber, #2304) [Link] (8 responses)

Er... I didn't say systemd is bad, nor did I say that you cannot develop software that runs as PID 1. I just said I'm not going to run it on any systems that matter because it's not safe enough, just as I wouldn't have run btrfs on important systems until it's had many years to bed down and get the bugs shaken out. Filesystem developers understand this, it is uncontroversial there. I can't understand why it is any less uncontroversial that the same apply to init systems.

The eudev project launches

Posted Dec 19, 2012 16:43 UTC (Wed) by andresfreund (subscriber, #69562) [Link] (7 responses)

Ok. Then I am sorry for understanding it that way.

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

The eudev project launches

Posted Dec 19, 2012 17:00 UTC (Wed) by nix (subscriber, #2304) [Link] (6 responses)

It's a tradeoff.

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

The eudev project launches

Posted Dec 19, 2012 18:57 UTC (Wed) by man_ls (guest, #15091) [Link] (2 responses)

Also, kernel developers take extreme care to maintain backwards compatibility with user interfaces, precisely so that people can upgrade their kernels without worrying about regressions (well, about intended regressions at least). As far as other developers don't do the same, they will not see everyone upgrade as often as they would like to.

The eudev project launches

Posted Dec 19, 2012 19:33 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Exactly. The kernel regresses a lot, but I know that none of those regressions are intentional, and I have never yet reported a regression and had anything but helpfulness from the famously robust and brutal kernel community. Say what you like, but when it comes to regression management, the kernel is not half bad nowadays. (One hardware-dependent network card lockup bug got repeatedly overlooked and headscratched over, but eventually solved -- it just took a year and a half before I figured out a way to get useful debugging out of it so that anyone else stood a chance. I had to make do with an obscure and ugly workaround in the meantime, but the workaround was given to me in only hours after the initial report.)

The eudev project launches

Posted Dec 19, 2012 20:04 UTC (Wed) by andresfreund (subscriber, #69562) [Link]

I totally agree on this. As long as you do your part by far most of the kernel devs are *awesome* in fixing bugs. Up to giving you custom code that could possibly recover your lost data due to a fringe bug...

That attitude makes me hell of a lot more forgiving/accepting when facing problems or not totally thought through designs.

The eudev project launches

Posted Dec 21, 2012 2:45 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

> 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

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.

The eudev project launches

Posted Dec 21, 2012 9:35 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

It's my dev box, yes (or rather the server which runs my development VMs and Emacs, since I don't actually like rebooting that much: it also happens to be a router between two halves of my local net).

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.

The eudev project launches

Posted Dec 21, 2012 17:50 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

If it's related to poorly supported hardware, that makes it more understandable as to why I've not had such issues enough to make me feel like I'm risking weeks of "fixing the machine" stuff by running Rawhide.

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.

The eudev project launches

Posted Dec 19, 2012 18:08 UTC (Wed) by hummassa (guest, #307) [Link] (2 responses)

> It has no bugs that any significant number of people ever encounter, and it is reasonable to say after this long that it never will.

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!

The eudev project launches

Posted Dec 19, 2012 19:41 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Quite. My pedantry is on a high-power kick today, I'm afraid!

The eudev project launches

Posted Dec 20, 2012 15:50 UTC (Thu) by hummassa (guest, #307) [Link]

Not to worry about -- the poisonous atmosphere of this whole discussion and affair kind of warrants it.

The eudev project launches

Posted Dec 18, 2012 19:44 UTC (Tue) by HelloWorld (guest, #56129) [Link]

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.