All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ford <david+challenge-response@blue-labs.org>
To: szonyi calin <caszonyi@yahoo.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org
Subject: Re: A users thoughts on the new dev. model
Date: Fri, 23 Jul 2004 12:39:37 -0400	[thread overview]
Message-ID: <41013F49.7030902@blue-labs.org> (raw)
In-Reply-To: <20040723152421.52282.qmail@web52904.mail.yahoo.com>

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

This is malarkey, 99.9% pure FUD.  I personally use just about every 
kernel revision there is that is "newest", i.e. I use 2.4.x until 2.5 
appears then I switch to 2.5.x.  I may skip a few versions here and 
there due to frequent releases or a known brown bag release.  However by 
far and large even the development or "unstable" line of releases as 
some people have a bad habit of calling them, are far more reliable than 
Windows.

I use odd.x releases even on my servers.  Every once in a while there's 
a significant bug in code that I'll have an issue with that can't be 
worked around.  So I avoid that version.

In short, your statement is pure bullsh*t, because there is very little 
code put out that is actually a messy or unstable release.  Most bugs 
are quickly fixed, worked around, or avoided for that person because 
that feature isn't really such a necessity.  Linux (*nix) gives you a 
LOT of ways to get a particular task done but people have this penchant 
for finding a way that is broken and hyping/harping it up to make a big 
issue out of it instead of just reporting the bug and getting the job 
done in a different fashion.

"Oh my gawd it's a bug, let me piss on everyone's doorstep and make 
caustic remarks on LKML about horribly broken code.  Never mind you that 
I can probably get it done another way."

Give the developers a little credit, we all make mistakes; they happen 
to fix theirs pretty fast and they're downright honest about fessing up 
to them.

David

>>From the LWM story i understood that linux will be like windows:
>lots of "features" but no stability, except if you use a
> distribution kernel. And that seriously made me think about
> using another free *nix for a stable system.  
>

[-- Attachment #2: david+challenge-response.vcf --]
[-- Type: text/x-vcard, Size: 183 bytes --]

begin:vcard
fn:David Ford
n:Ford;David
email;internet:david@blue-labs.org
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard


  reply	other threads:[~2004-07-23 16:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-22 15:04 A users thoughts on the new dev. model Evan Hisey
2004-07-22 22:25 ` Bill Davidsen
2004-07-23 13:58   ` H. Peter Anvin
2004-07-23 15:24     ` szonyi calin
2004-07-23 16:39       ` David Ford [this message]
2004-07-23 19:06         ` Xiong Jiang
2004-07-23 20:00           ` Tim Wright
2004-07-23 21:40     ` Adrian Bunk
2004-07-23 23:04       ` hpa
2004-07-24 10:38         ` Adrian Bunk
2004-07-27 20:08       ` Bill Davidsen
2004-07-22 22:57 ` Paul Jackson
2004-07-27 20:20   ` Bill Davidsen
2004-07-28  7:31     ` Paul Jackson
2004-07-23 19:32 ` Florin Andrei

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=41013F49.7030902@blue-labs.org \
    --to=david+challenge-response@blue-labs.org \
    --cc=caszonyi@yahoo.com \
    --cc=hpa@zytor.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.