Slashdot Mirror
Video Interview With Linus On Linux 2.7
daria42 writes "ZDNet Australia has put up a video interview of Linux creator Linus Torvalds talking about the kernel development process, explaining why the unexpected resilience of kernel version 2.6 has delayed the move to 2.7." From the interview: "One of the original worries was that we would not be able to make big changes within the confines of the development model... I always said that if there is something so fundamental that everything will break then we will start at 2.7 at that point... We have been able to do fairly invasive things even while not actually destabilizing the kernel... Having stable and unstable in parallel: I think it used to be a great model, and I think we may see that the kernel has actually become more mature and stable and it just doesn't seem to be that great a model, for the kernel."
Flash 9 was released for linux today. Enjoy :)
In my opinion, the real reason for no 2.7 is:
If we open up an unstable branch, I have less testers. --Linus Torvalds
I'm not saying the 2.6 series is unstable or anything, either. However as I watch Linux's development from the sidelines, I get the impression that most policy decisions Linus makes are designed to make his life easier. See also: Bitkeeper.
True, but that would really blow their minds. Sometimes progress happens in baby-steps.
On the other hand, try maintaining a module that actually does something useful and works on the latest 10 releases of 2.6 kernel. It's freakin impossible. They change so much shit just on a whim you end up with a big mess -- or your own little API abstraction, which itself is a smaller, but still big mess.
The use of the word experiment is a bad choice of words.... the 2.6.16.y releases are all stable releases but instead of batching up fixes and implementing them maybe weeks or months after discovery 2.6.16 was used to test the idea of rapid fixing of the kernel. The experiment was in the process of kernel fixes rather than experimental code.
--- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
Very good.
:)
I'd add an (e) (Oracle has 5
Seriously (d) would be for bug fixes/security patches in general, e would be for ones that are expected to almost certainly not break anything.
e level upgrades: should be nearly 100% safe
d: should be safe, necessary fixes that could break things (e.g. fix a security hole but certain programs could have issues). NO API CHANGES or ADDITIONS!
c: new features. Usually safe, but not for mission critical servers. NO API drops/deprecations.
b: Major upgrade. System tools may need upgrading, app breakage can occur but not extreme. old APIs deprecated.
a: Extreme upgrade. Only twice so far. Whole system replacement can be expected, old APIs dropped
Just because it CAN be done, doesn't mean it should!