The eudev project launches

Posted Dec 18, 2012 13:56 UTC (Tue) by nye (subscriber, #51576)
In reply to: The eudev project launches by nye
Parent article: The eudev project launches

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.

to post comments

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.