lkml.org 
[lkml]   [1999]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RAID is a matter of availability, not data security
Hello guys,

Since several months I am reading lot of messages of people looking for new drivers

and features covering new controllers going out on the market.

My feeling is that Linux community is entering a race loosed from the beginning.
I repeat this only my own feeling.

Our company is developing and selling a Radiological Information System (RIS)
handling both data and images. As server we are using Linux since 1996. From
1996 till later 1997 we were showing the users how open and friendly was Linux
compared to other Unix and non-Unix servers. We agreed about setting up several
Linux servers with
different kinds of SCSI, Ethernet and Graphic adapters. Result of that were
lot of troubles with these drivers and hardware, and very heavy remote maintenance.

Now we turned back our strategy: we tested Linux 2.0.xx with some mother boards,
graphics, SCSI, RAID5, DLT, SCSI disks, Ethernet adapters and UPS devices.
When installing a new site, we never go out of such tests, whatever the customer is
saying towards
some other adapter 15 cents cheaper.

Now we have a customer base running with an uptime near of 100% and are able to
prove
very easily how Linux is much more stable and fast than other Unix or non-Unix
servers.

This get me to my basic idea: I feel Linux is being now a fact on the field and a
"standard" no
professional software company could ignore. When looking forward seeing Linux being

number one, I would say that rather to spend time trying to setting up new drivers
and drivers
and drivers for adapters having more and more a short time life, system developers
would rather have
to spent their time improving the drivers of a range of adapters and opening Linux
to application development tools. We have to recognize this is a field where Linux
has
to become much more strong.

With the wave on the field in favor of Linux, could this approach force hardware
manufacturers to become much more "open" with Linux community. There are still
examples
of companies providing Linux community with necessary hardware technical
specifications
for fast and robust drivers design, receving benefits back from sales generated by
Linux market

What is your opinion about ?



Rudolf Leitgeb wrote:

> Miquel van Smoorenburg wrote:
> > In article <cistron.37C2FF6D.57FC6B92@heliosam.fr>,
> > Hubert Tonneau <hubert.tonneau@heliosam.fr> wrote:
> > >So what I wanted to express is that if you say the new code is not perfect,
> > >so we don't include it, it has to be balanced with the fact that not
> > >including the code means ignoring hardware failures.
>
> > Including new code in development kernels is fine, but not in maintenance
> > releases of a stable kernel series if it is not backward compatible enough.
>
> > Linus wants 2.4 out by Christmas. So make sure the new RAID code gets
> > into 2.3 if it isn't already.
>
> When the 2.1.x kernels hit around x=44, they were so unreliable that people
> started writing new drivers for 2.0.x instead of 2.1.x because they wanted
> a somewhat stable kernel to base their work on.
> Once the 2.1.x kernels hit x>100 or so they became so stable that many used
> them a "stable" production kernels with more features than 2.0.x would offer.
> Incidentally that's the time when 2.0.x kernels became rock solid.
>
> No we seem to be stuck in the "2.3.x is useless" stage and people cry for new
> features in 2.2.x again. Lots of people were ready to tinker around with 2.3,
> when they suddenly broke FAT and many other file systems. Then we had all kinds
> of horror messages of 2.3 kernels that suffered major instabilities here on
> lk-ml. As a result only true hackers and some newbies who didn't know better
> lay their hands on 2.3 kernels, but throrough real world testing only barely
> happens (I haven't read one article here on lk-ml where someone used 2.3.x on a
> big server. There was not one message so far about a DOS attack against 2.3.x
> kernels, IIRC.)
>
> Although it has been criticized quite often that 2.1.x lasted so long, it
> allowed Linus first to change and break everything (x < 90), then there was a
> long period of real world testing, eventually yielding a reasonably stable
> and reasonably bug free kernel. If experimental file system code goes in 2.2
> now, nobody will test the version for 2.3, and 2.4 will be bug ridden like hell.
>
> Hoping for the best ...
>
> Rudi
>
> --
> | | | | |
> \ _____ /
> / \ B O R N
> -- | o o | -- T O
> -- | | -- S L E E P
> -- | \___/ | -- I N
> \_____/ T H E S U N
> / \
> | | | | |
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.034 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site