From: athan...@cs.concordia.ca (Thanassi Michailidis)
Subject: Linux used for a business
Date: 1995/06/27
Message-ID: <3spiau$3il@newsflash.concordia.ca>#1/1
X-Deja-AN: 105269160
organization: Computer Science, Concordia University, Montreal, Quebec
nntp-posting-user: 4555
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
I work at a company where we are using SCO UNIX on a 486DX50 machine. We
current don't have TCP/IP or any development tools. We use it to run
custom software developed in Business Basic. We are currently setting up a
network using Windows for Workgroups. We want to connect the UNIX box to the
server.
I have read that the is a program that will allow us to run our SCO binaries.
Assuming this will run our application correctly, is it worth it for a
company to make the switch to LINUX O/S? What problems might we encounter?
We don't do any development except our custom BASIC program.
Our only other alternative is to purchase SCO open server 5 for $935 CDN and
a new HARD DISK (since our current one is not large enough for the new O/S)
for $600 CDN.
How is hardware compatibilty fir Linux? Is it stable enough to use in a
business environment?
I know that if we can make use of Linux it will be a great benefit because
there are many development tools available which we might be able to use in
the future which do not come with the new SCO O/S (except for an extra
charge).
How stable is Linux in a network environment? We are going to be a maximum of
20 users. Our network cards are INTEL Ether Express Pro.
Any suggestions/ recommendations/comments would be greatly appreciated.
Thanks.
From: smur...@stardust.bln.sub.org (Joerg Mertin)
Subject: Re: Linux used for a business
Date: 1995/06/29
Message-ID: <3sv22u$1b7@stardust.bln.sub.org>#1/1
X-Deja-AN: 105429857
distribution: world
references: <3spiau$3il@newsflash.concordia.ca>
followup-to: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
organization: Stardusts News Host
reply-to: jo...@pc50.zrz.tu-berlin.de
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
In comp.os.linux.networking Thanassi Michailidis (athan...@cs.concordia.ca) wrote:
: I work at a company where we are using SCO UNIX on a 486DX50 machine. We
: current don't have TCP/IP or any development tools. We use it to run
: custom software developed in Business Basic. We are currently setting up a
: network using Windows for Workgroups. We want to connect the UNIX box to the
: server.
: I have read that the is a program that will allow us to run our SCO binaries.
: Assuming this will run our application correctly, is it worth it for a
: company to make the switch to LINUX O/S? What problems might we encounter?
: We don't do any development except our custom BASIC program.
You mean the iBCS. Yes, it runs SCU-Unix Binaries very well. I had
some sco-demo Versions of WP6.0 running on it. Faster than under
native SCO-Unix, but this might be related to the scheduler :)
Never had a problem with :)
: Our only other alternative is to purchase SCO open server 5 for $935 CDN and
: a new HARD DISK (since our current one is not large enough for the new O/S)
: for $600 CDN.
: How is hardware compatibilty fir Linux? Is it stable enough to use in a
: business environment?
Well, a well configured LiNUX system can be more stable than a
commercial server. In fact, we have 2 Servers in University. One using
Vines(Banyan), the other I'm administrating, running LiNUX. Last one
doesn't get rebooted. It's a 486DX2 66MHz with 16 MB Ram, Server for
24 Other Clients, since these PC's are mostly running M$-Windows and I
only got a 50 MB Partition for each client :) 16 MB Swap, rest LiNUX
Native. Runs flawlessly as nfs-client-server System. Very stable, no
problems and never crashes (Contrary to the M$-Network) :)
: I know that if we can make use of Linux it will be a great benefit because
: there are many development tools available which we might be able to use in
: the future which do not come with the new SCO O/S (except for an extra
: charge).
: How stable is Linux in a network environment? We are going to be a maximum of
: 20 users. Our network cards are INTEL Ether Express Pro.
Very stable. Our Server at University is online 24 Hours, mine at home
also :)
: Any suggestions/ recommendations/comments would be greatly appreciated.
Take it. Use It :) At least, whenever you have a problem, you can fix
it since you have sources :)
cu
--
Solong & Happy Hacking
________________________________________________________________________
| Joerg Mertin : smur...@stardust.bln.sub.org (Home) |
| in Berlin Spandau at : jo...@pc50.zrz.tu-berlin.de |
| Stardust's Linux System : Data, Fax & Voice 49 30 3627345 |
------------------------------------------------------------------------
`Fatal Error: Found [MS-Windows] System -> Repartitioning Disk for LinuX...'
From: david...@glacial.tmr.com (Bill Davidsen)
Subject: Re: Linux used for a business
Date: 1995/07/14
Message-ID: <3u5kn6$gf2@glacial.tmr.com>#1/1
X-Deja-AN: 106188682
references: <3spiau$3il@newsflash.concordia.ca> <3sv22u$1b7@stardust.bln.sub.org>
organization: TMR Associates, Schenectady NY
reply-to: david...@tmr.com (bill davidsen)
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
In article <3sv22u$...@stardust.bln.sub.org>,
Joerg Mertin <jo...@pc50.zrz.tu-berlin.de> wrote:
| Well, a well configured LiNUX system can be more stable than a
| commercial server.
He's talking SCO here, not "a commercial server." I find it hard to
believe that any meaningful comparison can be done between these
systems. Properly configured either SCO or Linux will have a mean time
to software failure in the order of 10-20 months, somewhat precluding
meaningful comparison due to lack of enough data.
Let's say that I have clients with SCO and Linux, and run both here,
and don't choose between them on the basis of reliability. Both run
very well, both have the occasional fault never found to be hardware,
software, power or whatever. Both run regularly over a year on a UPS
without a crash.
If the application will run on Linux, and if it supports your hardware,
and if your application vendor will support the product on Linux, you
could make the change.
SCO supports about an order of magnitude more hardware than Linux. They
will run on almost anything. Linux supports mainstream PC hardware with
some unusual stuff. Different worlds.
--
Stupidity, like virtue, is its own reward.
Bill Davidsen (david...@tmr.com) consultant/director
TMR does UNIX and other systems stuff, some real time, network and
system admin, security, C and other good stuff.
From: dma...@eagle.ais.net (Daniel Marks)
Subject: Re: Linux used for a business
Date: 1995/07/15
Message-ID: <3u8gj7$eg0@news.ais.net>
X-Deja-AN: 106188741
references: <3spiau$3il@newsflash.concordia.ca>
<3sv22u$1b7@stardust.bln.sub.org> <3u5kn6$gf2@glacial.tmr.com>
followup-to: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
organization: American Information Systems, Inc.
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
Bill Davidsen (david...@glacial.tmr.com) wrote:
: In article <3sv22u$...@stardust.bln.sub.org>,
: Joerg Mertin <jo...@pc50.zrz.tu-berlin.de> wrote:
: | Well, a well configured LiNUX system can be more stable than a
: | commercial server.
: He's talking SCO here, not "a commercial server." I find it hard to
: believe that any meaningful comparison can be done between these
: systems. Properly configured either SCO or Linux will have a mean time
: to software failure in the order of 10-20 months, somewhat precluding
: meaningful comparison due to lack of enough data.
I hate to flatly contradict Mr. Davidsen, but my two years or so of
experience with SCO v3.2.4, Unixware 1.1, Unixware 2.0, BSDI 2.0, and various
version of Linux from Linux 0.99p8 to the present has led me to believe
that Linux has a long way to go before total reliability is achieved. While
I personally use Linux at home, and would not want to discourage anyone
from using it for educational purposes (kernel sources are very handy),
I would not recommend that someone depend on it for one's livelihood
UNDER CERTAIN CIRCUMSTANCES. In particular, one must design a system
with the most reliable hardware, and the minimum amount of functionality
necessary.
For the Linux machines at my workplace, I have never found a Linux machine
to remain operational without a kernel panic for over 23 days. Similarly,
often Unixware 1.1 and 2.0 and BSDI will only have average uptimes of two
weeks on the average. These are uptimes using recommend hardware, drivers,
and memory configurations from the manufacturers.
Often the bugs I have found are so difficult to reproduce I have had no luck
mailing convincing bug reports to Linux kernel developers so that the
problems can be fixed. I have found that if one uses only certain pieces
of hardware and certain drivers under Linux, and compiles a kernel with
the minimum functionality required for the server task at hand, that month
or so uptimes can be expected.
A reliable Linux system should have at least 16 MB of RAM, and use only
certain types of hard disk controllers. In particular, avoid the current
versions of the NCR SCSI and Adaptec 2740, 2840, and 2940 SCSI drivers.
I have found success with the IDE, Adaptec 1542 and Buslogic drivers. Avoid
running XFree86 (especially XFree86 3.1.1) on the same machine if possible.
Always make sure that you have 1.5-2 times as much swap as RAM, and make
sure that at least 10% of your hard disk is free. Do not use anything
but a SCSI CD-ROM drive (if a CD-ROM is required), and make sure that the
SCSI cabling total length is less than 4 feet. Make sure that only the
ends of the SCSI chain are terminated, and active termination is preferred.
Avoid the NE2000 driver, and use the SMC Ultra or 3c509 ethernet drivers
for maximum reliability.
I have had the best luck with SCO v3.2.4 and uptimes. It has stayed up
for months continuously, and I have found no other operating system
with a reliability record that even comes close. Unfortunately, it is
pretty threadbare in the features department (SCO is reluctant, bordering
on paranoid, to make changes).
However, if a month or so uptime is good enough, I think that using the
more tried and tested hardware and software configurations under Linux
will work. After trying lots of different hardware in many configurations,
this is my conclusion. Minimizing the load on the machine, and minimizing
the number of programs, and the amount of hardware, connected to a Linux
box always helps.
I hope this helps any decision making on how to use Linux. I do not mean
to denigrate Linux, but the fact that Linux attempts to support so many
platforms, hardware, and software means that not every configruation can
be thorougly tested. Linux's development cycle for correcting bugs,
during the 1.0 and 1.2 versions of the kernel, aren't nearly long enough
to be able to produce versions with very long uptimes. I hope that future
development work will concentrate a little more on testing reliability.
Daniel Marks
dma...@ais.net
I don't speak for my employer, and they certainly don't speak for me.
From: j...@Ra.MsState.Edu (Jiann-Ming Su)
Subject: Re: Linux Uptimes
Date: 1995/07/15
Message-ID: <3ua4db$t6l@Ra.MsState.Edu>#1/1
X-Deja-AN: 106295491
references: <3spiau$3il@newsflash.concordia.ca>
<3sv22u$1b7@stardust.bln.sub.org> <3u5kn6$gf2@glacial.tmr.com>
<3u8gj7$eg0@news.ais.net>
organization: Mississippi State University
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
In article <3u8gj7$...@news.ais.net>,
Daniel Marks <dma...@eagle.ais.net> wrote:
>
>For the Linux machines at my workplace, I have never found a Linux machine
>to remain operational without a kernel panic for over 23 days. Similarly,
>often Unixware 1.1 and 2.0 and BSDI will only have average uptimes of two
>weeks on the average. These are uptimes using recommend hardware, drivers,
>and memory configurations from the manufacturers.
Uh, there was a machine at MIT (Imagination.MIT.Edu??), that was up
for over 70 days. Can't finger the machine anymore, so can't tell
how long it's been up.
>
>problems can be fixed. I have found that if one uses only certain pieces
>of hardware and certain drivers under Linux, and compiles a kernel with
>the minimum functionality required for the server task at hand, that month
>or so uptimes can be expected.
>
I thought most most people do compile kernel options for the hardware
they have. It reduces the kernel size so you'll have more RAM free.
>A reliable Linux system should have at least 16 MB of RAM, and use only
>certain types of hard disk controllers. In particular, avoid the current
>versions of the NCR SCSI and Adaptec 2740, 2840, and 2940 SCSI drivers.
I use a NCR controller with no problems. I have access to a machine
with the 2940 and a machine with the 2940W and both seems to work
with no hangs.
--
Jiann-Ming Su mailto:j...@ra.msstate.edu
http://www2.msstate.edu/~js1
MSU SAE http://sae.me.msstate.edu/
From: s...@presence.co.uk (Stephen C. Tweedie)
Subject: Re: Linux used for a business
Date: 1995/07/15
Message-ID: <SCT.95Jul15233135@karen.presence.co.uk>#1/1
X-Deja-AN: 106295511
references: <3spiau$3il@newsflash.concordia.ca>
<3sv22u$1b7@stardust.bln.sub.org>
followup-to: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
organization: Web13 Internet Cafe
reply-to: Stephen Tweedie <s...@dcs.ed.ac.uk>
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
Hi,
In article <3u8gj7$...@news.ais.net> dma...@eagle.ais.net (Daniel
Marks) writes:
: He's talking SCO here, not "a commercial server." I find it hard to
: believe that any meaningful comparison can be done between these
: systems. Properly configured either SCO or Linux will have a mean time
: to software failure in the order of 10-20 months, somewhat precluding
: meaningful comparison due to lack of enough data.
I hate to flatly contradict Mr. Davidsen, but my two years or so of
experience with SCO v3.2.4, Unixware 1.1, Unixware 2.0, BSDI 2.0,
and various version of Linux from Linux 0.99p8 to the present has
led me to believe that Linux has a long way to go before total
reliability is achieved.
For the Linux machines at my workplace, I have never found a Linux
machine to remain operational without a kernel panic for over 23
days. Similarly, often Unixware 1.1 and 2.0 and BSDI will only
have average uptimes of two weeks on the average. These are
uptimes using recommend hardware, drivers, and memory
configurations from the manufacturers.
Interesting. For the linux boxes at my workplace, I have never found
a kernel panic except on two specific machines, identical in all
respects to the others. Replacing the cache ram on one of those
machines cured its problem entirely; the other one has only occasional
problems, and while we suspect faulty DRAM, we currently have no need
to fix it; it gets rebooted much more frequently than its mtbf anyway.
The servers all stay up until told to come down. Our main server with
IDE CDROM, a couple of hard disks, lance PC-NET vlb ethernet and 20MB
ram, has a best uptime so far of 54 days, having dealt with the best
part of a hundred million ethernet packets in that time. After that
time, we decided to move the server downstairs and we rebooted in the
process.
There is no doubt that there have been many unstable kernels in the
1.1 series, but I've seen three hundred day uptimes reported for 1.0.9
kernels. Running 1.2.8 and 1.2.10 here, we simply have no kernel
problems at all. Admittedly we have only been running this
environment for 3 or 4 months, but still, I'm extremely happy with
Linux's stability.
Cheers,
Stephen.
--
Stephen Tweedie, Web13 <s...@presence.co.uk>,
Dept. of Computer Science, Edinburgh University, Scotland <s...@dcs.ed.ac.uk>
From: c...@tower.stc.housing.washington.edu (Craig A. Johnston)
Subject: Re: Linux Uptimes
Date: 1995/07/16
Message-ID: <3ua7bn$2jm@nntp5.u.washington.edu>#1/1
X-Deja-AN: 106295542
references: <3spiau$3il@newsflash.concordia.ca>
<3u5kn6$gf2@glacial.tmr.com> <3u8gj7$eg0@news.ais.net> <3ua4db$t6l@Ra.MsState.Edu>
organization: none
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
In article <3ua4db$...@Ra.MsState.Edu>,
Jiann-Ming Su <j...@Ra.MsState.Edu> wrote:
>In article <3u8gj7$...@news.ais.net>,
>Daniel Marks <dma...@eagle.ais.net> wrote:
>>
>>For the Linux machines at my workplace, I have never found a Linux machine
>>to remain operational without a kernel panic for over 23 days. Similarly,
>>often Unixware 1.1 and 2.0 and BSDI will only have average uptimes of two
>>weeks on the average. These are uptimes using recommend hardware, drivers,
>>and memory configurations from the manufacturers.
>
>Uh, there was a machine at MIT (Imagination.MIT.Edu??), that was up
>for over 70 days. Can't finger the machine anymore, so can't tell
>how long it's been up.
My system ran flawlessly for between 2 and 3 months once. I've never
had it go down on its own, it has always been rebooted. Without a reboot,
who knows how long? (one has to upgrade kernel versions occasionally, no?)
The stability of Linux is at least on a par with any other unix variant I
have come across.
And SCO? If I ran SCO, I'd WANT it to die. *grin*
From: la...@rn.com (Larry Snyder)
Subject: Re: Linux Uptimes
Date: 1995/07/16
Message-ID: <3ubd19$els@trauma.rn.com>#1/1
X-Deja-AN: 106333749
references: <3spiau$3il@newsflash.concordia.ca>
<3u8gj7$eg0@news.ais.net> <3ua4db$t6l@Ra.MsState.Edu>
<3ua7bn$2jm@nntp5.u.washington.edu>
organization: TraumaNet
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
In article <3ua7bn$...@nntp5.u.washington.edu>,
Craig A. Johnston <c...@tower.stc.housing.washington.edu> wrote:
>In article <3ua4db$...@Ra.MsState.Edu>,
>Jiann-Ming Su <j...@Ra.MsState.Edu> wrote:
>>In article <3u8gj7$...@news.ais.net>,
>>Daniel Marks <dma...@eagle.ais.net> wrote:
>>>
>And SCO? If I ran SCO, I'd WANT it to die. *grin*
I don't know if I would go that far -- I personally place $CO in
the same category as DOS. $CO is a kludged up version of SVR3.2
unix that's now what, 10 years old.
At least all of the OTHER major Unix vendors have upgraded to SVR4
based Unix
--
Larry Snyder
la...@rn.com
la...@trauma.rn.com
From: iia...@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Linux used for a business
Date: 1995/07/17
Message-ID: <DBuw4K.Msw@info.swan.ac.uk>#1/1
X-Deja-AN: 106333719
sender: n...@info.swan.ac.uk
x-nntp-posting-host: iifeak.swan.ac.uk
references: <3spiau$3il@newsflash.concordia.ca>
<3sv22u$1b7@stardust.bln.sub.org> <3u5kn6$gf2@glacial.tmr.com>
organization: Institute For Industrial Information Technology
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
In article <3u5kn6$...@glacial.tmr.com> david...@tmr.com (bill davidsen) writes:
>SCO supports about an order of magnitude more hardware than Linux. They
>will run on almost anything. Linux supports mainstream PC hardware with
>some unusual stuff. Different worlds.
The assertion is just a little teeny bit questionable. Linux has support
for devices SCO doesn't, and SCO for ones Linux doesn't. As to the run on
almost anything - make that 'with 32Mb of RAM and a fast disk'.
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
Redistribution of this message via the Microsoft Network is prohibited
From: david...@tmr.com (bill davidsen)
Subject: Re: Linux Uptimes
Date: 1995/07/17
Message-ID: <3uer6m$10ck@usenety1.news.prodigy.com>#1/1
X-Deja-AN: 106437067
references: <3spiau$3il@newsflash.concordia.ca>
<3ua4db$t6l@Ra.MsState.Edu> <3ua7bn$2jm@nntp5.u.washington.edu>
<3ubd19$els@trauma.rn.com>
organization: TMR Associates, Schenectady NY
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
originator: david...@darkstar.prodigy.com
In article <3ubd19$...@trauma.rn.com>, Larry Snyder <la...@rn.com> wrote:
| I don't know if I would go that far -- I personally place $CO in
| the same category as DOS. $CO is a kludged up version of SVR3.2
| unix that's now what, 10 years old.
When I was running machines which were not booted regularly I was
able to get uptimes of over a year with SCO boxes in a network
environment. My office uses a SCO box for a print, mail, news, file
and backup server as well as router to the net. It has gone 13
months uptime, and about double that since the last crash, although
it was rebooted every month or so recently.
From: torva...@cc.Helsinki.FI (Linus Torvalds)
Subject: Re: Linux Uptimes
Date: 1995/07/18
Message-ID: <3ufpco$g40@kruuna.helsinki.fi>#1/1
X-Deja-AN: 106436829
sender: torva...@cc.helsinki.fi
references: <3spiau$3il@newsflash.concordia.ca>
<3ua7bn$2jm@nntp5.u.washington.edu> <3ubd19$els@trauma.rn.com>
<3uer6m$10ck@usenety1.news.prodigy.com>
content-type: text/plain; charset=ISO-8859-1
organization: University of Helsinki
mime-version: 1.0
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
In article <3uer6m$1...@usenety1.news.prodigy.com>,
bill davidsen <david...@tmr.com> wrote:
>
>When I was running machines which were not booted regularly I was
>able to get uptimes of over a year with SCO boxes in a network
>environment. My office uses a SCO box for a print, mail, news, file
>and backup server as well as router to the net. It has gone 13
>months uptime, and about double that since the last crash, although
>it was rebooted every month or so recently.
[ breastbeating mode on ]
I actually know one person who tells me he had a linux box with an
uptime of 495 days. This obviously wasn't a very recent version of the
kernel ;-)
(aside: I'm reasonably sure that Linux/i386 will start doing strange
things just around that time, when the 32-bit "jiffies" variable will
overflow, and it would have been interesting to hear about it. But they
had to bring the machine down due to some major re-organizations and I
didn't hear about the close call until afterwards.)
[ breastbeating mode off ]
Of course, that machine wasn't used on a very busy network, and was
mainly used as a X-terminal, I understand (they probably also had an
UPS, although it's just conceivable that it wouldn't have been needed
here in Finland).
Linus
From: dma...@eagle.ais.net (Daniel Marks)
Subject: Re: Linux used for a business
Date: 1995/07/18
Message-ID: <3uf1ga$gon@news.ais.net>#1/1
X-Deja-AN: 106593984
organization: American Information Systems, Inc.
newsgroups: comp.os.linux.development.system
After receiving well over 20 E-mail replies to my assertion that Linux
may not be as reliable as some commercial UNIX implementations (e.g.
SCO), I think I have hit on an idea that may improve the kernel
author's abilities to track down and detect bugs.
Most replies I received were based on ancedotal evidence. Since there
are probably over 10,000 readers of comp.os.linux.development.system,
having 20 of them that replied to me with uptimes exceeding 30 days
(usually 3-12 months were reported) is not surprising. This is
not denying that these stories are true. However, I think
that careful bug tracking and control, like the type done on commercial
software, could significantly benefit a kernel developer's ability to track
down trends of bugs with kernel versions, hardware, various packages
(such as Xfree or IP Firewalling) etc. Like other people's stories, my
complaints about kernel reliability may be particular to my configuration.
If, perhaps, a Web interface form was created in which people could report
bug reports scored along many dimensions:
1. kernel version
2. CPU type (386/486/586/Alpha/MIPS/PowerPC/680X0)
3. amount of memory (2-3 mb, 4-7 mb, 8-11 mb, 12-15 mb, 16-32 mb, 32- mb)
4. amount of swap (same as above #3)
5. hard disk interface type IDE/SCSI (all supported SCSI types)
6. hard disk manufacturer (Quantum, Seagate, WD, Micropolis, Digital,
HP, Maxtor, other)
7. hard disk size (-100 MB, 101-300 MB, 301-500 MB, 501-1000 MB, 1000- MB)
8. video card chipset
9. kernel compiled options (networking options, SCSI options, etc.)
10. serial ports and type
11. parallel ports and type
12. ethernet card type (if present)
13. CD-ROM type
14. Sound card type
15. commonly used packages (that come with Slackware, etc.)
16. uptime before crash
17. type of crash: kernel panic and lock up, no panic (just lock up),
panic upon booting, etc.
18. filesystem corruption? yes or no
19. hardware damage? yes or no
...and many others...
By collecting bug reports with this data, reports could be generated
that would attempt to match bugs with various versions of the kernel,
kernel compile options, drivers, hardware, or software. These reports
can be summarized and sent to kernel developers, so they have hints
on what to look for when finding bugs. Histogram reports on various
dimensions, or combinations of dimensions, restricting the value
of other dimensions, may provide ways that kernel developers can
summarize the reports of many users, without having to read every
bug report directly.
While this may not be as helpful as one extremely detailed bug report
from an experienced Linux user, it would help to find long term trends.
It would also help consolidate the reports of a lot of Linux users,
most of whom would not bother to report an error, or would be ignored.
I know a lot of people out there are religious about Linux, and I am
a big fan of Linux and use it at home. However, I am guessing my
experience is closer to average, and not the outstanding reliability
that has been found by some. I think there is a lot of room for
improvement, and getting this data would help provide direction
for kernel developers working toward reliability.
Dan Marks
dma...@ais.net
From: mar...@i17linuxb.ists.pwr.wroc.pl (Marek Michalkiewicz)
Subject: Re: Linux Uptimes
Date: 1995/07/19
Message-ID: <3ujkn5$92j@sun1000.ci.pwr.wroc.pl>#1/1
X-Deja-AN: 106593605
references: <3spiau$3il@newsflash.concordia.ca>
<3ua7bn$2jm@nntp5.u.washington.edu> <3ubd19$els@trauma.rn.com>
<3uer6m$10ck@usenety1.news.prodigy.com> <3ufpco$g40@kruuna.helsinki.fi>
followup-to: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
organization: Technical University of Wroclaw
reply-to: mar...@i17linuxa.ists.pwr.wroc.pl
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
Linus Torvalds (torva...@cc.Helsinki.FI) wrote:
: I actually know one person who tells me he had a linux box with an
: uptime of 495 days. This obviously wasn't a very recent version of the
: kernel ;-)
: (aside: I'm reasonably sure that Linux/i386 will start doing strange
: things just around that time, when the 32-bit "jiffies" variable will
: overflow, and it would have been interesting to hear about it. But they
: had to bring the machine down due to some major re-organizations and I
: didn't hear about the close call until afterwards.)
Hmm, how about 64-bit jiffies? The 32-bit value incremented every 1/100 s
will overflow after 497 days 2 hours 27 minutes 52.96 seconds... But this
is for HZ=100, and may not be the case on other architectures (HZ=1024 on
the Alpha?). Faster clock might be good for very fast x86 machines too.
Marek
From: torva...@cc.Helsinki.FI (Linus Torvalds)
Subject: Re: Linux Uptimes
Date: 1995/07/20
Message-ID: <3ukutf$7og@kruuna.helsinki.fi>#1/1
X-Deja-AN: 106593817
sender: torva...@cc.helsinki.fi
references: <3spiau$3il@newsflash.concordia.ca>
<3uer6m$10ck@usenety1.news.prodigy.com> <3ufpco$g40@kruuna.helsinki.fi>
<3ujkn5$92j@sun1000.ci.pwr.wroc.pl>
content-type: text/plain; charset=ISO-8859-1
organization: University of Helsinki
mime-version: 1.0
newsgroups: comp.os.linux.misc,comp.os.linux.questions,
comp.os.linux.development.apps,comp.os.linux.development.system,
comp.os.linux.hardware,comp.os.linux.networking,comp.os.linux.setup
In article <3ujkn5$...@sun1000.ci.pwr.wroc.pl>,
Marek Michalkiewicz <mar...@i17linuxa.ists.pwr.wroc.pl> wrote:
>Linus Torvalds (torva...@cc.Helsinki.FI) wrote:
>
>: (aside: I'm reasonably sure that Linux/i386 will start doing strange
>: things just around that time, when the 32-bit "jiffies" variable will
>: overflow, and it would have been interesting to hear about it. But they
>: had to bring the machine down due to some major re-organizations and I
>: didn't hear about the close call until afterwards.)
>
>Hmm, how about 64-bit jiffies? The 32-bit value incremented every 1/100 s
>will overflow after 497 days 2 hours 27 minutes 52.96 seconds... But this
>is for HZ=100, and may not be the case on other architectures (HZ=1024 on
>the Alpha?). Faster clock might be good for very fast x86 machines too.
On the alpha, you get 64-bit jiffies, and a 1024Hz clock. That will
keep you going for a long time (half a billion years or something ;-)
On non-64-bit architectures, I don't want to go for a 64-bit jiffy
counter, as jiffies are used in various places that really don't need to
be slowed down (kernel timers etc). I may start revising my opinion
when lots of people start complaining that they have to re-boot their
linux machines every 500 days..
Linus