Slashdot Log In
Video Interview With Linus On Linux 2.7
Posted by
kdawson
on Tue Jan 16, 2007 10:01 PM
from the surprising-stability dept.
from the surprising-stability dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Too bad Flash 9 isn't released for linux yet (Score:3, Insightful)
Ummmm (Score:5, Informative)
Parent
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Re: (Score:3, Funny)
Duh! Everyone knows Mr. Trovalds develops on a PPC/Linux machine but his home machine is still a Wintel one
*runs*
Re: (Score:2)
Yes, it was and I installed it because of how horribly outdated Flash 7 was, and it was pre-alpha quality. If you navigated to another page before the current one was done loading, your browser would freeze 50% of the time with no recourse but to kill it.
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
* Auto installing 32bit plugins...
*** NSPlugin Viewer *** WARNING: Flash Player 9 beta 1 detected and rejected
*** NSPlugin Viewer *** WARNING: Flash Player 9 beta 1 detected and rejected
This is an awesome program nonetheless.
Re: (Score:2)
Re: (Score:2)
i believe it autodects your OS based on your user agent, you insensitive anonymous coward. why are you in windows??
Re:Too bad Flash 9 isn't released for linux yet (Score:5, Funny)
Maybe he uses the user agent switcher [mozilla.org] to work around broken websites, you insensitive... logged in user
Parent
Re: (Score:3, Interesting)
True, but that would really blow their minds. Sometimes progress happens in baby-steps.
Re: (Score:2, Informative)
On a somewhat related note, hopefully by August the nouveau project will deliver an open source 3D driver for NVidia cards; between nouveau and Gnash, I'll soon be able to completely eliminate binary blobs on this machine. Here's hoping it happens sooner rather than later
Re: (Score:2)
well (Score:5, Funny)
It certainly works when dual-booting.
Another interview with Linus? (Score:4, Funny)
Translation (Score:4, Interesting)
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.
Re:Translation (Score:4, Insightful)
Parent
Corporate development OWNS the 2.6 kernel (Score:3, Insightful)
If anyone wanted to seriously break the Linux kernel ABI, I don't think corporate interests or major distros would support it or follow.
OSes or platforms seem to change rapidly up until the point they reach a critical mass - at which point, the next ABI change is cause for general revolt. After that, $ENTITY learns their lesson and vows to never significantly break backwards compatibility again.
Re: (Score:2, Informative)
Re:Corporate development OWNS the 2.6 kernel (Score:5, Informative)
The ABI rules haven't changed at all: the user-kernel ABI (system-call interface) is supposed to be backwards compatible indefinitely; the internal ABI (e.g. for drivers) changes without warning whenever it's convenient.
What's changed is the release cycle--we no longer have this odd-numbered fork where the kernel's half-broken for years at a time.... Which is a good thing.
Parent
Resilience? (Score:5, Insightful)
explaining why the unexpected resilience of kernel version 2.6 has delayed the move to 2.7.
Uh...resilience?
2.6 releases have "shipped" numerous times with some serious bugs, probably because Linus and company have let lots of people slip major new features into the 2.6 kernel, when it's supposed to be stable. 2.6 kernels regularly make it SEVERAL "point" releases into each point release:
Go and look at the timestamps on 'em on ftp.kernel.org. Some of the sub-versions are just a few days apart. How the hell are end-users supposed to know when the kernel is ACTUALLY useable, if there are THIRTY SEVEN bug-fix releases?
One of the more amazing bugs involved a bug in md that would hose raid partitions, and I assure you, it was not the only serious filesystem bug. I lost a reiserfs partition thanks to a half-baked 2.6 release.
Re:Resilience? (Score:5, Informative)
The 2.6.16 kernel is a special case. One of the core kernel devs decided to try an experiment to maintain a kernel release for an extended period of time. He continues to provide small fixes at a very regular rate without porting in the newer features of the more current kernel releases. This has only happened for 2.6.16 and there are no plans that I know of to offer extended maintenance on any other kernel release.
Parent
Re:Resilience? (Score:5, Interesting)
Parent
Re:Resilience? (Score:5, Insightful)
Parent
Re: (Score:2)
They release those pretty frequently; each often consists of very few patches. But the kernel does have tons of bugs--it's a complicated piece of software.
That doesn't mean any one user is likely to hit any of them--most are in drivers, most triggered only by particular work
Re: (Score:2)
This is just from memory, someone with a better memory could probably be more specific. But anyhow, the 2.6 releases have been pretty smooth.
Re:Resilience? (Score:4, Insightful)
The people that go to kernel.org to choose a kernel to download and compile hardly qualify for what most people will call a "user".
What Linus is calling "unexpected stability" is probably due to the distros intermediating between the kernel devs and the actual users. To put it another way, what's really happened is that the "stable" kernel is now being maintained by the likes of RedHat and Debian, while the "unstable" kernel is what you find at kernel.org.
We'll see how this plays out - but for the real world, this leaves Linus doing what he does best - develop and oversee cool developments - while the more rank-and-file organizations lead by the distros intermediate for the end users.
I've been using CentOS and Fedora Core, it's been at least 5 or 6 years since I felt the need to go to kernel.org!
Parent
Re: (Score:2)
Re: (Score:2)
bad website (Score:4, Insightful)
Some 2.7 ideas (Score:5, Insightful)
VFS probably needs to be addressed. Reiserfs4 sort of exposed some of the issues. There are others though. To my knowledge ext2/3 are the only OSes that actually code strcitly against VFS and the other layers. XFS, JFS, Reiserfs, etc.. are all hacked in to it. If you follow the kernel list, you'll see nobody uses JFS and XFS seems to have regular crash reports. Upon using it myself (for 5 years) it has memory leaks, it routinely has trouble with new kernels. There have been regular performance regressions. Now, I don't really care about the filesystem itself that much but it seems fundamentally broken to me that a non-experimental filesystem has such routine problems. Either the API is uses is broken, the filesystem is broken or both. I'm becoming more inclined to think that it's VFS. This creates a circular sort of problem, you don't need VFS if ext2,3,4 are the only filesystems that are really supported, it's not nearly as important as it is treated. Either that or the process of having something included and non-experimental needs to include some kind of support aspect and maybe be rethought. So far as I can tell, IBM isn't really doing much more with JFS and nobody uses it, let's move to remove it (bummer too because it's a quite clean and elegant FS, much better than reiserfs or xfs in terms of code and design quality and cleanness.) There isn't a clean process for removing stuff from the kernel. Reiserfs is a prime example, Reiserfs3 isn't supported, time to move to remove it; it has known bugs and design flaws which are not being addressed. This particular area is more complex also because selinux depends on filesystem support, LVM behaves differently with different filesystems, different filesystems have different and variable tools support.. System filesystems need some work too, what's debugfs? configfs? How is sysfs different than configfs or procfs?
Filesystems are just an easy to see and expose portion of this problem there are other APIs which have the same issues. We retooled the build system a few years back, it's much better but there are major flaws still. There are drivers which cannot work unless loaded as a module and yet they can be linked in. There are a huge number that depend on other subsystems and you can easily misconfigure them (SATA depends on parts of SCSI. So I can static link some SATA modules in and dynamic link parts of the SCSI system in and the build system won't complain. Worse, if I break it just so, I can actually get it to build cleanly and freak out at runtime) I'm not advocating making it more difficult to hack on the kernel or add new modules to the build but it's fucked if it doens't catch that stuff. Worse, the driver is fucked if it can't be statically linked and if that's an acceptable limitation then it should be an option. (the Fusion series of RAID/SCSI/SAS type drivers is one that suffers from this problem) At the same time the build system is holy, good luck changing that without pissing off half the free world, and I don't even want to think about what would have to happen if it required a change to a .config file to take it to the next level. Part of the beauty of Linux in this regard is that it is remarkably simple to build and get involved with, there really aren't any tricks or anything to building it. This is something else where there needs to be a support component. There are good companies with well supported drivers and there are orphans. I'd rather have modules marked as supported or unsupported than whether or not they are GPL clean or tainted, I'd like to see that
Re:Is flash player 8 available for linux? (Score:4, Funny)
Parent
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:3, Funny)
Re: (Score:2)
Not that I'm a fan of Adobe's flash player. I still open a 32 bit browser whenever I absolutely need flash, and use
Re: (Score:3, Informative)
Add this line: FIREFOX_DSP="aoss" (remove FIREFOX_DSP=)
Install the alsa-oss package.
Restart FF, and you are playing sound!
Re:9 sucks as bad as any other version (Score:5, Insightful)
Add this line: FIREFOX_DSP="aoss" (remove FIREFOX_DSP=)
Install the alsa-oss package.
Restart FF, and you are playing sound!
Parent
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
ALSA is not only desired by high-end audio users. All users want basic features such as the ability for two programs to use the sound card at the same time. ALSA provides this (part of alsa-lib) and OSS does not.
ALSA is not necessarily Linux-specific. As far as application programs are concerned, ALSA is merely a stable program library
Re: (Score:3, Insightful)
Changing one line in a text file, then typing "apt-get install alsa-oss" is at least as simple as operating a coffee machine.
I don't have to anything like that with any other OS I have used. I don't have to go around installing weird stuff and editing text-files just so I could get frigging sound working in a web-browser.
And yes, I use Linux (among other OS'es). Have been using it since 1999, and I'm a card-carrying member of a national LUG. But anyone who says that "It's easy, just edit this text file and install these apps and you are all set" is totally, 100% missing the point. Tasks like that are way beyond the capabilities
For anyone who can't watch the video (Score:5, Informative)
Parent
Why backport? (Score:2)
How about 2.9 then. Blue sky how would you design an OS for all the cheap commodity hardware around.
Re:Why backport? (Score:4, Informative)
That scheme ended when 2.6 came out. The new system consists of 3 or 4 numbers formatted as:
a.b.c
or
a.b.c.d
a changes only when there is a massive restructuring of the kernel
b changes when there are large sweeping changes, but not of quite the same order as a. (linus, in the interview, says they'll do a 2.7 when and if they need to make changes large enough that they will be breaking everything.)
c changes when new features and/or drivers are added
d changes for small bug fixes and security patches. after a new c release the d number is ommitted when the c number has just changed.
Parent
Re: (Score:3, Interesting)
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
Re: (Score:2, Insightful)
Re:Video interviews (Score:5, Informative)
Parent