linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Rychter <jan@rychter.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4 future
Date: Wed, 03 Dec 2003 13:26:56 -0800	[thread overview]
Message-ID: <m2k75dzj6n.fsf@tnuctip.rychter.com> (raw)
In-Reply-To: Pine.LNX.4.44.0312011212090.13692-100000@logos.cnet

[-- Attachment #1: Type: text/plain, Size: 4637 bytes --]

>>>>> "Marcelo" == Marcelo Tosatti <marcelo.tosatti@cyclades.com>:
 Marcelo> The intention of this email is to clarify my position on 2.4.x
 Marcelo> future.

 Marcelo> 2.6 is becoming more stable each day, and we will hopefully
 Marcelo> see a 2.6.0 release during this month or January.

 Marcelo> Having that mentioned, I pretend to:
[...]
 Marcelo> - From 2.4.25 on, fix only critical/security problems.

I find your statements on 2.6.0 being stable enough for users rather
alarming. I'll use this occasion to write about my gripes with Linux
development, with hopes that perhaps this will help some developers
understand people's needs better.

On my notebook, I have spent the last two years going through regular
painful kernel patching and upgrades. I have never had a fully working
system during that time. At various times, various parts failed to work
correctly: ACPI, software suspend, USB, sound. Also, the kernel is
incomplete and I have had to patch each new release or compile
additional drivers for (at least): ACPI, cpufreq, cryptoapi + loop
driver fix (for reasonable IV calculation), orinoco wireless card,
spectrum24 wireless card, ALSA sound modules and software suspend.

I've seen ABI's change from under me (the tun/tap interface being
changed around 2.4.9 AFAIR). I've seen bugs being ignored [1]. I've seen
2.4 kernels being plain unusable on my hardware (a non-working ACPI
implementation means the hardware will overheat).

Overall, the state of affairs has been rather sad. It is improving now,
with ACPI and software suspend becoming mature. Some of the USB bugs
were fixed around 2.4.21/22 (I think). I finally have a reasonably
stable system to work on [2].

I am terrified of the following scenario, which is extremely probable to
happen soon:

  1) 2.4 is being moved into "pure maintenance" mode and people are
     being encouraged to move to 2.6.
  2) While people slowly start using 2.6, Linus starts 2.7 and all
     kernel developers move on to the really cool and fashionable things
     [3].
  3) 2.6 bug reports receive little attention, as it's much cooler to
     work on new features than fix bugs. Bugs are not fashionable.
  4) In the meantime, third-party vendors are confused and do not
     support any kernel properly [4].

IMHO, Linus should try to enforce a *long* 2.6 testing period after the
"real" 2.6 kernel is out. Starting a new series immediately is a recipe
for disaster, as with the 2.4 kernels.

Also, please remember, that for some people the move to 2.6 is not that
easy. My personal checklist of things that have to work (and some still
do not, for various reasons) for me to migrate:

  -- support for my hardware (of course),
  -- stable software suspend,
  -- crypto support that can mount my filesystem,
  -- VMware kernel modules,
  -- ATI drivers [5].

What are my suggestions? Two main points, I guess:

  1) Please don't stop working (and that does include pulling in new
     stuff) on 2.4, as many people still have to use it.

  2) Please don't start developing 2.7 too soon. Go for at least 6
     months of bug-fixing. During that time, patches with new features
     will accumulate anyway, so it isn't lost time. But it will at least
     prevent people from saying "well, I use 2.7.45 and it works for
     me".

I hope this posting will help some of you understand how some users
feel. I think most of those people who run into these kinds of problems
are not very well represented on this list. I know of at least several
people who have tried installing Linux on a laptop and failed
[6]. You'll never hear from those people here.

--J.

== 
[1] Yes, I think a "please retest with 2.5.69" response is equivalent to
    ignoring a bug report.  I was also rather disappointed by people
    saying they don't care about bug reports from people who are not
    willing to resend them regularly. 2.4 does not have a bug-tracking
    system, which means many bug reports get lost or ignored.

[2] On hardware that's two years old.

[3] I really, really couldn't care less for a new scheduler that makes
    my machine 2% faster overall. I will trade performance for
    correctness at any time. I am willing to think about performance
    when my machine works without freeezing or crashing.

[4] Vendors such as VMware, ATI or NVidia.

[5] Please don't tell me to buy an open-source supported 3D card. I've
    seen such answers before and they are ridiculous. There is no such
    card on the market if you want anything like reasonable performance.

[6] Failed for good reasons, not because of stupid errors, but because
    of the limitations of Linux.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

  parent reply	other threads:[~2003-12-03 20:27 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-01 14:25 Linux 2.4 future Marcelo Tosatti
2003-12-01 15:04 ` Ian Kent
2003-12-01 15:33   ` Christoph Hellwig
2003-12-01 21:36     ` Peter C. Norton
2003-12-01 23:54       ` Arjan van de Ven
2003-12-02  1:11         ` Ian Kent
2003-12-02 20:13           ` Peter C. Norton
2003-12-02 20:10         ` Peter C. Norton
2003-12-02 20:18           ` Arjan van de Ven
2003-12-02 20:46             ` Peter C. Norton
2003-12-03  1:23               ` Ian Kent
2003-12-03 10:36                 ` Matthias Andree
2003-12-03 14:49                   ` Ian Kent
2003-12-03 15:00                     ` Matthias Andree
2003-12-04  6:24                       ` Ian Kent
2003-12-02 21:56             ` Bryan Whitehead
2003-12-02  8:17       ` Christoph Hellwig
2003-12-02  1:09     ` Ian Kent
2003-12-02  2:23     ` snpe
2003-12-02  6:39       ` Jan-Benedict Glaw
2003-12-02 18:04         ` Linus Torvalds
2003-12-02 18:45           ` Jan-Benedict Glaw
2003-12-02 19:09             ` Linus Torvalds
2003-12-02 19:13               ` Jan-Benedict Glaw
2003-12-02 19:39               ` Gene Heskett
2003-12-02 20:13                 ` Jeff Garzik
2003-12-02 20:32                 ` Stephan von Krawczynski
2003-12-02 21:48                   ` Gene Heskett
2003-12-02 21:56                     ` Linus Torvalds
2003-12-03  2:36                       ` Harald Arnesen
2003-12-03  9:21                     ` Helge Hafting
2003-12-02 19:59           ` snpe
2003-12-02 22:30             ` Mike Fedyk
2003-12-02 22:43               ` Arnaldo Carvalho de Melo
2003-12-03 14:08                 ` snpe
2003-12-03 13:26                   ` Christoph Hellwig
2003-12-02  8:18       ` Christoph Hellwig
2003-12-01 15:26 ` Norberto Bensa
2003-12-01 23:30   ` 2.6 security patches merged? was: " Mike Fedyk
2003-12-02  0:06     ` Chris Wright
2003-12-02  0:58       ` Måns Rullgård
2003-12-02  1:56         ` Chris Wright
2003-12-02 11:55     ` Marcelo Tosatti
2003-12-02  9:00   ` Matthias Andree
2003-12-02 11:54   ` Ionut Georgescu
2003-12-02 12:03     ` Arnaldo Carvalho de Melo
2003-12-02 13:13       ` Ionut Georgescu
2003-12-02 13:38         ` Ed Sweetman
2003-12-02 14:12           ` Arnaldo Carvalho de Melo
2003-12-02 16:01           ` Ionut Georgescu
2003-12-02 16:08             ` Jeff Garzik
2003-12-02 18:20               ` John Bradford
2003-12-02 20:19               ` Ville Herva
2003-12-02 21:40                 ` Chris Wright
2003-12-02 20:09       ` Stephan von Krawczynski
2003-12-02 20:24         ` Arnaldo Carvalho de Melo
2003-12-02 20:45           ` Stephan von Krawczynski
2003-12-02 21:03             ` Arnaldo Carvalho de Melo
     [not found]       ` <Pine.LNX.4.58.0312021402360.17892@moje.vabo.cz>
     [not found]         ` <20031202131512.GU13388@conectiva.com.br>
     [not found]           ` <Pine.LNX.4.58.0312021433360.8417@moje.vabo.cz>
     [not found]             ` <20031202135423.GB13388@conectiva.com.br>
2003-12-02 20:21               ` Tomas Konir
2003-12-02 18:53                 ` Mike Fedyk
2003-12-02 19:06                   ` Valdis.Kletnieks
2003-12-02 23:13                 ` Jose Luis Domingo Lopez
2003-12-03 18:22                 ` bill davidsen
2003-12-04  1:24                   ` jw schultz
2003-12-04  1:47                     ` Mike Fedyk
2003-12-04  3:45                       ` Tim Connors
2003-12-04  5:41                         ` Willy Tarreau
2003-12-05  0:14                       ` jw schultz
2003-12-01 15:56 ` Marcelo Tosatti
2003-12-01 21:02 ` David S. Miller
2003-12-03 21:26 ` Jan Rychter [this message]
2003-12-03 20:51   ` Jeff Garzik
2003-12-03 21:14   ` Willy Tarreau
2003-12-05 15:33   ` John Jasen
2003-12-05 22:23     ` Mike Fedyk
2003-12-06 15:49     ` Max Valdez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2k75dzj6n.fsf@tnuctip.rychter.com \
    --to=jan@rychter.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).