Re: Please release a stable kernel Linux 3.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Zoltán HUBERT wrote:
Hello gentlemen (and ladies ?)

As a power-user (NOT a hacker) I kindly ask you to please change the naming scheme and come back to the traditional model, and release a stable kernel while working on a develoment branch.

I'm not on the [lkml] so should you answer please CC my e-mail: [email protected]

Please don't do this. It's very rude. It's one thing to report a bug and say "Please CC me", but it's quite another to ask us to completely change the way we're doing everything without actually observing the process. If you're going to make such sweeping requests like this, at least have the courtesy to subscribe to the list and read a sampling of the traffic for long enough to realize that the current development model, for all its flaws, was developed for very good reasons.

All people who might read this know that traditionally stable releases are even numbered and development branches are odd numbered. This changed during late develoment of 2.6, according to my analysis because of the "invention" of GIT which was itself necessary because of BitKeeper (insert ooooooooold flame-wars here) and which allowed very dynamic develoment. While this has been effective, alternative voices (Mr Morton complaining that more bugs were added than repaired, semi-stable semi-supported 2.6.x.y branches where invented...) come more and more into the front. The upcoming GPL v3 versus v2 debate will make things worse, and we all know this. The un-ending stable ABI argument goes into this same direction.

What argument? Userspace ABI is stable, by rule. Kernel internal API and ABI is not. There is no argument, just people who come along from time to time and ask us to do everything the way they like, without offering anything in return.

So I feel that a turning-point is coming where a really really really (x 15) stable and reliable kernel is NEEDED.

That's what vendor kernels are for. If you don't want to pay the money, just download the source and rebuild it yourself.

You might think it's easy for me to simply "use" Linux and complain while you're doing the hard stuff. As it happens, the current development/stable model makes our life as "users" more and more difficult. I'm using Linux since 1997 on a Mac thanks to LinuxPPC-1997, and I'm a hard pusher of Linux whenever possible, sometimes against the common sense, for example when I favor using National Instrument cards with Linux drivers and custom written TCP/IP server against easy LabView on Windows. While some of you dislike closed source drivers, the choices "we users" face are:
- closed source drivers with closed source OS
- closed source drivers with open source OS
Please consider that we are living in a REAL world, and not Disney-Land.

Closed or open, someone somewhere is probably willing to take your money in exchange for making it work. If you're not willing to spend money, or offer something else in exchange, then nobody has any reason to go out of their way make life easy for you. The community works to help itself, not the freeloaders. Many of us (such as myself) actually get paid to maintain stable releases to ensure a good user experience, so we're well aware of the issues you face.

So I've demonstrated that from a "users" perspective a new stable Linux would be of advantage. I'll now list what I suggest for this new stable branch:

First, there are some fundamental ideas in the pipelines of forthcoming releases which should be part of the next "stable" Linux (Reiser4, the new scheduler from Mr. Molnár, virtualisation...). So any next stable kernel branch should include most of these recent developments, with the goal of stabilising them. May-be a poll on [lkml] as to which feature to include or not would help ?

Actually, the current architecture is flexible enough that adding these things in isn't all that hard. We already have kvm merged, and the scheduler work is proceeding nicely. Please don't start another Reiser4 flamewar.

Second, there was once a suggestion that 2.6 should be 3.0 since a lot of things changed:
- modules called .ko and not .o
- the output of the compile
- ... (I don't remember)
This was a brilliant suggestion and I whish another consideration was given to that idea. You might even go a step further and call kernel modules .kmod. Why on earth call "kernel object" things that are "kernel modules" ? And that every person calls "modules" and not "objects" ? I know I know, in UNIX dynamic libraries are .so "shared objects", so what ? A "module" is a "module" and NOT an "object", call a cat a cat.

These are build trivialities. This is hardly reason to change the development model.

Third, while a stable ABI in a dynamically developed kernel is a difficult/impossible/unwanted feature, it should be possible to implement in a stable branch. This could even be a distinction between "stable" and "development" branches. And it would certainly help vendors of closed-source drivers.

If I submit a patch to a RHEL kernel that breaks kABI, people knife me in the hallways, because I get paid to maintain it.

Fourth, a finnish developper on this list suggested several times that people should be allowed to try stupid things. Well, I'm doing just that.

No, you're asking *us* to do stupid things. If you want a more stable kABI in the upstream kernel, then start submitting patches that implement the hooks you need to do it.

As a conclusion, please, please, consider splitting again the kernel in 2 distinct branches, one labeled "development" suiting your needs and another labeled "stable" for us users.

It's already been done in a few different places. 2.4.x is still maintained. 2.6.16.y is still maintained. Several vendors maintain stable kernels, some even kABI-stable, for many years after release. Since the vast majority of users are running distro kernels rather than upstream kernels, I think it's fair to say that anything post-2.6.16 from kernel.org is a de facto development kernel, at least to users with extreme stability requirements like yourself. Find yourself a distro that's the right balance of modern and stable, and use that kernel. If there isn't a distro that's both modern enough and stable enough, then there are probably some very good economic reasons why this is the case.

	-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux