The eudev project launches

Posted Dec 19, 2012 15:51 UTC (Wed) by andresfreund (subscriber, #69562)
In reply to: The eudev project launches by nix
Parent article: The eudev project launches

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.

to post comments

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.