bug history; stability vs features [LWN.net]

bug history; stability vs features

Posted Jul 10, 2006 18:33 UTC (Mon) by sanjoy (subscriber, #5026)
In reply to: rats... by joey
Parent article: Survey: Linux kernel quality

I just filled in the bug report history section by searching bugzilla.kernel.org to see what I'd reported: 21 bugs! A few are fixed or are duplicates; a couple have patches that fix them waiting to go into mainline (5000, 5989); a few are perhaps unfixable with the current design (4928, 5069); one I still need to report test results, whoops (6293); and several are still open. 5989 (s3 suspend hanging on the second suspend) involved tons of debugging and testing, so I'm especially glad that it has a candidate patch.

Suspend/resume have been the most buggy areas for me, probably because they are hard to debug and ACPI is incredibly complex. There's a saying that every Unix program grows in complexity until it can order pizza or maybe read email. The ACPI specification (an interpreter running in the kernel, who would have thought) seems well beyond that point!

I'd like to see a bug-sqashing-only release and perhaps have it recur every odd minor number (e.g. 2.6.19 then 2.6.21 ...). Stability and correctness are more important than features, not least because correctness implies making the internal designs robust and that gives a good platform for adding features.

I try to teach my physics students to "consider extreme cases" as a way of reasoning. On this issue, the two extremes are Windows, which is full of features and cruft; and TeX, which is rock solid. TeX admittedly solves a different problem and has different requirements than an OS does. But users appreciate that the base is rock solid. I think Linux needs to move towards the TeX side of the extreme.

(Log in to post comments)

bug history; stability vs features

Posted Jul 11, 2006 4:29 UTC (Tue) by xoddam (subscriber, #2322) [Link]

Thankyou Sanjoy for reporting your bugs and seeing through the process of
getting them analysed and fixed. It is users like you who make Linux
stable and usable for the rest of us (lazy freeloaders that we are :-).

> TeX, which is rock solid.

> I think Linux needs to move towards the TeX side of the extreme.

TeX is rock solid because it takes a well-defined input and produces a
well-defined output, and those basic requirements have not changed in
decades. It differs in sophistication but not in kind from filters like
cat, awk and grep, which are similarly solid.

Software which serves such ill-specified requirements as 'support every
piece of junk hardware in the world', 'run the buggy binary ACPI scripts
on laptop X without turning it into a brick' and 'placate the pundits
who claim Free Software is not ready for the desktop' are necessarily
rapidly evolving and therefore more error-prone.

It is unfortunate that the Linux kernel core falls into this category and
not that of a stable filter, but unavoidable. Users who require a
rock-solid base to their systems always have the alternative of sticking
to their old hardware and older kernels, or even switching to another OS
which is developed with solidity, and not features, as first priority.

Bug-squashing only releases

Posted Jul 13, 2006 2:46 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link]

I'd like to see a bug-sqashing-only release and perhaps have it recur every odd minor number (e.g. 2.6.19 then 2.6.21 ...)

Well, considering that a 2.7 kernel has been roundly rejected, it appears that 2.6.x.y will be the value for the rest of time. Therefore, `2.6' no longer contains any useful information, and should be dropped, leaving kernel version numbers of `x.y', so the suggestion reduces to

I'd like to see a bug-sqashing-only release and perhaps have it recur every odd [...] number (e.g. 19 then 21 ...)

Hmmm, sound familiar?

Bug-squashing only releases

Posted Jul 14, 2006 5:21 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

if the cycle was fast enough it wouldn't be a problem, however when the cycle got to multiple years between stable kernels the result was that kernels shipped by distros were significantly incompatable with each other.

right now they are haveing trouble keeping the cycle to a couple of months. give them a little time to stabilise that (and hopefully speed it up a bit) and then they can try a stabilization-only kernel without the preasure for other improvements being too big

even with the current cycle there are things being posted today that are being debated as 2.6.19 or 2.6.20 pushing those out to .22 or so is hard on the people developing the idea.

it's also frequently hard to draw a line between a fix and a new thing, in many cases the best fixes (long term anyway) are drastic departures from what was there before.