Slashdot Mirror
Is the Stable Linux Kernel Moving Too Fast?
darthcamaro writes "Yesterday the stable Linux 3.10 kernel was updated twice — an error was made, forcing a quick re-issue. 'What happened was that a patch that was reported to be broken during the RC [release candidate] review process, went into the release, because I mistakenly didn't pull it out in time,' Greg Kroah-Hartman said. The whole incident however is now sparking debate on the Linux Kernel Mailing List about the speed of stable Linux kernel releases. Are they moving too fast?"
its moving along just fine. People make mistakes, get over it, its not the end of the world. Considering its current release speed, the amount of changes made over the long term the Linux kernel folks have as good or better track record than most other software houses.
My karma is not a Chameleon.
"Are they moving too fast?""
Compared to what, Windows, IOS, OSX, What?
>known bug that got by review
>caught
>fixed rapidly instead of waiting for the next release
I don't see the problem.
If this was a regular occurrence, yeah, it'd be a problem. But it's infrequent enough to be "news."
Unlike Patch Tuesdays, which aren't.
--
BMO
"the fun thing about a kernel is that there is no good way to test it except to run it" --Greg Kroah Hartman
I work on PostgreSQL, and nothing goes out until it's been validated on the entire buildfarm. It's hard to have such a thing for the Linux kernel though, because it's so easy for a bug to break test machines. You need to catch when machines are responding, do a hardware reset, and then rollback to a known good kernel instead. It's much harder than most software testing to automate.
As indicated in the debate on LKM, rc kernels get hardly any testing, although all of the tests it does get are mostly by highly motivated and astute testers
Most distros are releasing kernels at least one behind the developers tree, with not a great deal of incentive to update the kernel right away, (even if they make it available in a repository for those wanting it). So much of the real world testing on new kernels comes only after its been released, and even then it doesn't hit Joe Sixpack's machine for several months.
So at most, this was an embarrassing incident, and not a bit deal. The amazing thing is that it was caught at all. Some of us remember kernels that got into production distros with serious things broken that should have been caught much earlier.
Sig Battery depleted. Reverting to safe mode.
I mistakenly didn't pull it out in time.
Why do you have to compare it to other operating systems? Just look at what should be the right way to do it, maybe learn from other operating systems, but don't just look at the speed of what others are doing and try and match that. If things go wrong because you're moving too fast, you should either slow down, or fix your methodology so you can deal with the speed. If things don't get adapted by distributions because it's a pain to keep supporting, slow down, or make it easier for them to support it. If things go too slow and you miss essential features that everybody needs, speed it up. It's not that hard to rely on your own merits and not be dependent on other operating systems to determine how fast you should be going.
I was promised a flying car. Where is my flying car?
No, you want a frozen kernel. A stable kernel isn't one without bugs, is one where there aren't massive changes and you get dot releases with fixes
WHAT THE FUCK!
I can't believe this. I've been reading Slashdot since 1998, and I have never seen such a stupid suggestion in all that time.
...
OK, one of those two must be blatantly false.
Thanks Linus, but I think it's an established rule that you can't go releasing new versions of software until the ridicule surrounding your last release has died down. How else are we going to get stories for /.? Microsoft plays along. Why can't you?
The logs of the machines that break are the most important part of the test results here. You can't just throw them away when a VM dies without losing most of the testing value. If you're lucky, a busted kernel will stay alive long enough to create a crash dump when running on dedicated hardware. That's less likely to happen on VMs.
It's also possible to automate hardware resets with IPMI or similar lights-out management code. All of that takes special hardware though, and test code like this is painful to build.
Ah yeah, like kernel.org isn't trusted. Yes I know you said "distribution" but really now.
He wasn't talking about trusting that it didn't contain a trojan or something. By trust he meant vetted for quality.
It is a legitimate concern. The whole reason for having a release cycle is to have sufficient QA to prevent issues like this from happening. Distros provide that service - when Linus/Greg call a kernel done, they call it ready to start being tested. RHEL is still running 2.6 (albeit with backports).
3.10 is the next LTS kernel by Linux standards. The existing long term kernels are 2.6.32 (as used in RHEL6, Debian Squeeze, Ubuntu LTS 10.04), 2.6.34, 3.0, 3.2.50 (used in Ubuntu 12.04 LTS), and 3.4.59.
Only said fuck four times not including subject. Not Linus.
---Up Up Down Down Left Right Left Right B A START
Which rises question of just why are they part of the kernel? Why does a mouse driver need to run at Ring 0?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
For the purpose of release testing, though, the only thing you care about is whether or not there was a crash. If there was a crash, don't release. Back out the busted patch and release the working version. Then you can spend your time debugging the busted patch, which requires the logs and all.
SIGSEGV caught, terminating
wait... not that kind of sig.
You need to do some more reading on how Linux works.
- Michael T. Babcock (Yes, I blog)
From the article :
"At 9 a.m. PT on Aug. 20, Linux kernel developer Greg Kroah-Hartman announced the 3.10.8 kernel update. At 3:44 p.m. PT, Kroah-Hartman announced the Linux 3.10.9 kernel."
So, it was a new release, not a re-release.
God: An invisible friend for grown-ups.
You need to do some more reading on how Linux works.
So do you.
Linux is sort of a hybrid kernel now. Some hardware drivers are in ring 0. Quite a lot are no longer. libUSB for example allows userspace USB drivers. They work great. FUSE allows for user space filesystems which work great where absolute top performance is not necessary (eg sshfs, ftpfs etc).
A good fraction of the bluetooth stack, for example anything above L2CAP (the Bluetooth world equivalent of the IP stack's SCTP) , such as ATT and GATT is all userspace (and the non kernel side sucks donkey balls by the way). That means I could (if it didn't suck massive donkey balls) control all the various profiles with the majority of the code in userspace.
All the printer drivers are mostly in userspace (yay).
The graphics (X11) is largely in userspace for now...
Sound has a large userspace component and all the complex stuff like routing, mixing, and figuring out what to send where is in userspace (pulse or Jack).
The Linux kernel as-is is more than capable of running a mouse driver in userspace.
SJW n. One who posts facts.