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."
Visit the download page from a Linux browser and you can download Flash 9 for Linux now. And P.S. the beta was out for months before this was...
STOP . AMERICA . NOW
He's basically saying that no one is really developing a 2.7 kernel because 2.6 is extremely stable even with whatever experimentation they've done. He states that theres been times where they've gone over the 2 month release cycle because of the "big changes" they've done on the kernel. He states that unstable next to stable used to be a good model but it isn't good anymore. He states that if there was a 2.7 kernel they'd have to do all sorts of backporting to get whatever fixes on the 2.7 kernel to work on the 2.6 kernel.
Flash Player 9 is avaliable for linux. I was going to gripe about it too, but there are at least two posts above which link to the download site.
WTF are you talking about? The kernel ABI gets "broken" practically every version. It's a bit wacky if you ask me. Make a good design and stick with it guys.
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.
Chernobyl 'not a wildlife haven' - BBC News
The CVS version of Gnash has started getting video playback support; it's only a matter of time before it has full support for YouTube, Google Video, etc. Once this happens, we can happily accept Flash video in the open-source desktop.
:D
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
The point releases (or .y releases as they are sometimes called), are a new feature of the 2.6.x release cycle that's intended to get fixes in the hands of users faster. These are always small changes, usually only a handful of line changes in the diff.
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.
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.
No single raindrop believes that it is responsible for the storm.
It's Easy, I'm assuming you're using Firefox, so fire up Nano and open the file "/etc/firefox/firefoxrc" (as root)
Add this line: FIREFOX_DSP="aoss" (remove FIREFOX_DSP=)
Install the alsa-oss package.
Restart FF, and you are playing sound!
"Free software" is a matter of liberty, not price.
What closing down the Stable/Unstable branches "so everyone becomes a tester" really means is: everyone gets Unstable. This makes life really harrowing if you have an important server running on hardware with buggy drivers in successive kernel releases. You can't backtrack because a previous kernel had some important security updates. You can't go back to kernel 2.4 because it doesn't support this or that. Your only option is to ditch and replace hardware -- which is not always a practical option.
Linus certainly is a smart guy, but, this particular decision has been extremely annoying and frustrating.
Frankly, in this area, "UNIX/POSIX" compatibility can go fuck itself. Does POSIX even specify audio output interfaces? Did "UNIX" (System V? BSD?) even ever have sound output?
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 (libasound.so.2). Nothing stops you from porting alsa-lib to another platform, or implementing another library with the same interface. If would probably be quite easy to get it working today, by configuring alsa-lib to use the pcm plugin that talks to Pulse Audio server, which can output to OSS or many other sound systems/devices/interfaces.
Finally, if you bothered to do the most basic research about the i386 GNU/Linux Flash player, you would have found out that it is Adobe's plan to separate out the GNU/Linux-specific parts of the player into a separate library with a stable interface. Anyone (who uses i386) would then be able to implement their own platform-specific replacement and thus get the Flash player running on their platform.