Why would I want LINUX?
Greg Earle
Olaf Titz <s_t...@ira.uka.de> wrote:
[ Someone else who uses DOS asks why one would want Linux]
>A couple of good reasons:
>...
>7. I am neither able nor willing to spend big bucks on software when I
>can get good material for less. :-) Especially not since Linux is
>actually the best OS you can get for the 386 class of hardware, if you
>consider things like speed, memory usage, availability of software,
>even support (from friendly net.people etc.)
Uh, do you have empirical proof of this? (-:
On the other hand, perhaps you have a point. Back in the early days of Linux
and 386BSD, it seemed (to an outsider; I use a Sun clone and SunOS all the
time) like Linux was an interesting research project (no offense intended to
Linus; when a single person writes a whole O/S kernel, one can't help but have
an initial impression of it being an "interesting research project" (-: - of
course, it has mushroomed considerably since then). And it seemed like 386BSD
was the spirit of BSD & Net-2 reincarnated, and therefore more likely (just due
to that fact alone, with the inherent right-off-the-bat software compatibility
issues that this promised) to become more largely adopted. The fact that it
had the Net-2 networking code and Linux' early support for networking and thus
X were considered suspect no doubt fueled this perception.
Now it seems like (emphasis on "seems like") 386BSD and NetBSD have dissolved
in a hail of acrimony, including bickering with the Jolitz's, a (hostile?)
takeover of the software that smacks of "Hey! That was a great idea! Glad I
thought of it!" Meanwhile, there's the fact that there are more than 7 times
the number of postings to the Linux groups than to the 386BSD/NetBSD groups:
isolar:2:40 % ls -R1 /var/spool/news/comp/os/386bsd | egrep '^[1-9]' | wc -l
226
isolar:2:41 % ls -R1 /var/spool/news/comp/os/linux | egrep '^[1-9]' | wc -l
1593
So, at least, it would appear that Linux has won the "popularity contest".
Whether it is the "best OS you can get for the 386 class of hardware" is still
an IMHO statement, I would think. An interesting turn of events, nonetheless.
Again, these are just the observations of an interested bystander/outsider.
Further comments/observations from an insider's perspective welcomed ...
--
- Greg Earle
Phone: (818) 353-8695 FAX: (818) 353-1877 [Out of order now]
Internet: ea...@isolar.Tujunga.CA.US
UUCP: isolar!ea...@elroy.JPL.NASA.GOV a.k.a. ...!elroy!isolar!earle
Brian D. Carlstrom
isolar:2:40 % ls -R1 /var/spool/news/comp/os/386bsd | egrep '^[1-9]' | wc -l
226
isolar:2:41 % ls -R1 /var/spool/news/comp/os/linux | egrep '^[1-9]' | wc -l
1593
So, at least, it would appear that Linux has won the "popularity
contest". Whether it is the "best OS you can get for the 386 class of
hardware" is still an IMHO statement, I would think. An interesting
turn of events, nonetheless.
i would hardly give the volume of postings any credit for indicating
anything, since i could claim that linux users are often coming from dos
not unix and ask a lot of newbie unix questions ( i would guess) and
since they are playing a lot of catch up with their network software i
could claim that they talk about that while we dont. not that any of
this is true, but given the s/n ratio on usenet as a whole, its hardly a
scientifc mesaure =)
-bri
A Wizard of Earth C
A lot of the FreeBSD and NetBSD traffic has moved off to mailing lists;
for instance, this is Sunday night. The combined traffic on the FreeBSD
mailing list alone on Saturday (14 Aug 93) and Sunday (15 Aug 93) has
been 47 messages (I have hopes for 50 before the night is out -- it's
10:20PM here right now).
The group traffic is not indicative of the level of activity, only the
amount of usenet postings... ie: the group traffic.
This isn't counting the "merge" list traffic or the NetBSD traffic.
Terry Lambert
te...@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Olaf Titz
> >can get good material for less. :-) Especially not since Linux is
> >actually the best OS you can get for the 386 class of hardware, if you
> >consider things like speed, memory usage, availability of software,
> >even support (from friendly net.people etc.)
>
> Uh, do you have empirical proof of this? (-:
Yes. :-)
Okay, while you bring in BSD: I really don't want to restart any
argument of Linux vs BSD. Both can be considered, as far as I observe,
rather equal in power, with some advantages on the Linux side wrt.
speed and memory usage and on the BSD side wrt. networking.
> So, at least, it would appear that Linux has won the "popularity contest".
> Whether it is the "best OS you can get for the 386 class of hardware" is still
> an IMHO statement, I would think. An interesting turn of events, nonetheless.
It is an IMHO statemenmt, of course. But I'm not to draw attention
from BSD people towards Linux, more to draw attention from Windoze
people, if possible :-)
Olaf
--
olaf titz o ol...@bigred.ka.sub.org praetorius@irc
comp.sc.student _>\ _ s_t...@ira.uka.de LINUX - the choice
karlsruhe germany (_)<(_) uk...@dkauni2.bitnet of a GNU generation
what good is a photograph of you? everytime i look at it it makes me feel blue
Herb Peyerl
[ A bunch of a people saying <blah blah blah> deleted. ]
>thought of it!" Meanwhile, there's the fact that there are more than 7 times
>the number of postings to the Linux groups than to the 386BSD/NetBSD groups:
>
>isolar:2:40 % ls -R1 /var/spool/news/comp/os/386bsd | egrep '^[1-9]' | wc -l
> 226
>isolar:2:41 % ls -R1 /var/spool/news/comp/os/linux | egrep '^[1-9]' | wc -l
> 1593
Hmm... MacDonald's sells more hamburgers world-wide than any other chain.
Does this make them the *best* hamburger?
Maybe you ought to talk to Jesus about his formal Logic course....
--
hpe...@novatel.cuc.ab.ca (actual but UUCP) | NovAtel Commnications Ltd.
hpe...@fsa.ca <faster> | <nothing I say matters anyway>
"valloc,malloc, & chmod, founders of the first users' group, arrive at their
meeting place and are surprised by 'slattach', the dreaded barbarian hacker"
Dave Burgess
On the other hand, there are a lot of disk labelling questions in
c.o.3.* that aren't in c.o.l. :-)
Opinions and possibly skewed history follow...
My personal opinion is that there was an active comp.os.minix group that
was eagerly awaiting the release of a Net/2 derived Unix for the 386.
Bruce Evans (I think) released a series of 'unofficial' changes to minix
that allowed it to work pretty well on the 386. Shortly after that,
Linus broke from the fold (with a resounding 'F' from ast for
reinventing the monolithic operating system) and release Linux in it's
original unusable version (no shell??? or something). Then a BUNCH of
people jumped ship from minix to Linux. My resounding opinion is that
none of this would have happened as quickly as it did without Andrew
Tanenbaum's work on minix and the introduction of comp.os.minix.
Lots of people were still waiting for 386bsd to be released while the
rest were writing new code for Linux. By the time the 386bsd 0.0
version was released (I am getting old, memory may be fuzzy here),
Linux was fully on the way to becoming a REAL operating system.
Many people were (and still are) more comfortable with an OS that was
written from scratch than one that had any relationship with USL. There
are MANY factors that people can cite that have a bearing on which OS
people are using. One advantage each:
Linux: Uses shared libraries (crufty or elegant, I don't know but have
heard both) which reduces the amount of disk space required for the
executables, thereby making the software 'cheaper'.
386BSD: Had networking code first. This was a big draw for many early
users that HAD to have a working network available from the start.
One of the other features that seems to seperate the two systems is the
'feel' of the systems. Linux has evolved into a very POSIX compliant
system, which gives it a feel like SysV. *BSD has very much a BSD feel
(duh).
Most of Europe seems to have adopted Linux as their system of choice. I
expect that this is (in part, at least) to the fact that Linus is from
Europe. Why put up with those silly export restrictions and long
distance network connections when Linux is available right there on the
continent.
One final point. The seeming stagnation of 386bsd early in its growth,
while the patchkit was being put together, may have turned many potential
supporters off. Linux was growing virtually before your eyes, while
386bsd was being fixed ever so slowly. Whether that was because it was
an inherently better system of not is just bait for a flamewar.
Whether 386bsd or Linux is a better operating system ultimately boils
down to point of view. Linux has the advantage of not being fragmented
quite as much as the Net/2 derived systems, but the Net/2 derived
systems have the advantage of years of use on other systems before they
were ported to the 386...
--
------
TSgt Dave Burgess
NCOIC AL/Management Information Systems Office
Brooks AFB, TX
John Jackson
: A lot of the FreeBSD and NetBSD traffic has moved off to mailing lists;
: for instance, this is Sunday night. The combined traffic on the FreeBSD
: mailing list alone on Saturday (14 Aug 93) and Sunday (15 Aug 93) has
: been 47 messages (I have hopes for 50 before the night is out -- it's
: 10:20PM here right now).
Could you post the addresses for any/ae
John Jackson
: : A lot of the FreeBSD and NetBSD traffic has moved off to mailing lists;
Could you post the addresses for any/all of these lists? I try to stay
off lists and just use news, but in this case I definitely want to keep
up on the latest developments. Thanks!!
-John
P.S., sorry for the double post (emacs and tin seemed to get confused
somehow??)
A Wizard of Earth C
>
>: A lot of the FreeBSD and NetBSD traffic has moved off to mailing lists;
>: for instance, this is Sunday night. The combined traffic on the FreeBSD
>: mailing list alone on Saturday (14 Aug 93) and Sunday (15 Aug 93) has
>: been 47 messages (I have hopes for 50 before the night is out -- it's
>: 10:20PM here right now).
>
>off lists and just use news, but in this case I definitely want to keep
>up on the latest developments. Thanks!!
The lists are for active participation in developement and discussion of
common issues and the impact of changes (for instance, the new dbm code
for the password file that allows more than 20 or so aliases in the aliases
file). They aren't for release announcements or bug reporting.
Contact information has been provided both in the patchkit documentation
(for FreeBSD) and in the NetBSD documetation (for NetBSD).
I think the only thing I would serve by posting addresses here is a bunch
of "my serial driver doesn't work" and "why don't you implement this"
messages to the lists by people who haven't gotten a satisfactory answer
from the net and don't know how to use "sendbug".
If you care enough to dig the information out and want to code, etc., the
information is available. That's about all I can say about it.
Brett Lymn
Olaf> In article <24m779$b...@isolar.Tujunga.CA.US> ea...@isolar.Tujunga.CA.US (Greg Earle) writes:
Olaf> Okay, while you bring in BSD: I really don't want to restart any
Olaf> argument of Linux vs BSD. Both can be considered, as far as I observe,
Olaf> rather equal in power, with some advantages on the Linux side wrt.
Olaf> speed and memory usage and on the BSD side wrt. networking.
Hmmmm do you have the evidence to back the speed claim??
Out of interest I did a timing on my 386BSD system compiling JGraph,
as per the article by Ajay Shah:
time on my 386BSD 486/25 with 16M (running slip/X and other cruft)
with mixed SCSI/ESDI disk drives: 144 seconds.
for Linux on a 486/33 with 20M: 177 seconds
My tests were done running gcc 2.4.5 whereas Ajay's were done using
using 2.3.3
NOT a flame, just a data point. I will add more data to this later.
--
Brett Lymn
Martin Kraemer
: Most of Europe seems to have adopted Linux as their system of choice. I
: expect that this is (in part, at least) to the fact that Linus is from
: Europe. Why put up with those silly export restrictions and long
: distance network connections when Linux is available right there on the
: continent.
Nope. I ("we europeans") had access to 386bsd as well as to Linux.
[[Also these "export restrictions" on DES etc are really just a joke.
Every mailbox or ftp server offers you a multitude of
better-than-original crypt software packages like ufscypt etc.]] The
reason that I decided to go the Linux way was the sheer size of 386bsd.
In order to get a running system plus kernel sources, you just need a
hard disk with a size multiple of what you need for Linux. When I first
installed Linux (Oct/Nov. 1992), it was so slender that you could get
all the base utilities including cc, emacs and kernel sources into as
much as a 32 MB hard disk!
Plus there is much more support for "cheap" hardware and for two-or-
more-OS's-on-one-harddisk. Traditionally, when you wanted UN*X, you had
to buy the hardware that was supported. And imho, 386bsd still has a
bit of this attitude. Linux goes the other way: it makes the OS run on
the hardware you've already got.
Martin
--
#include <std/dsclm.h> /* SNI SU BS2000 SD124 - Muenchen, W. Germany */
Martin Kraemer [Martin....@mch.sni.de]
------------ Vs lbh ner ernqvat guvf lbh unir gbb zhpu serr gvzr ------------
Ul[r]i[ch] Wendl
In article <24vd7h$f...@horus.mch.sni.de>,
Martin....@mch.sni.de (Martin Kraemer) writes:
>...
>Dave Burgess (bur...@hrd769.brooks.af.mil) wrote:
>: Most of Europe seems to have adopted Linux as their system of choice. I
>: expect that this is (in part, at least) to the fact that Linus is from
>: Europe. Why put up with those silly export restrictions and long
>: distance network connections when Linux is available right there on the
>: continent.
>
>Nope. I ("we europeans") had access to 386bsd as well as to Linux.
>[[Also these "export restrictions" on DES etc are really just a joke.
>Every mailbox or ftp server offers you a multitude of
>better-than-original crypt software packages like ufscypt etc.]] The
>reason that I decided to go the Linux way was the sheer size of 386bsd.
>In order to get a running system plus kernel sources, you just need a
>hard disk with a size multiple of what you need for Linux. When I first
>installed Linux (Oct/Nov. 1992), it was so slender that you could get
>all the base utilities including cc, emacs and kernel sources into as
>much as a 32 MB hard disk!
>
>Plus there is much more support for "cheap" hardware and for two-or-
>more-OS's-on-one-harddisk. Traditionally, when you wanted UN*X, you had
>to buy the hardware that was supported. And imho, 386bsd still has a
>bit of this attitude. Linux goes the other way: it makes the OS run on
>the hardware you've already got.
>
> Martin
Exactly!!
Or maybe the [386]bsd[386] suffer from the
association with one specific instruction set?
[hey, finally I've a 486 now!]
Or are there just so many Linus, Charlie Brown, Snoopy,... fans around? :^)
Uli
--
=================================== \|/
watch out for MouseShit on your PC! (o o)
===================================================oOO==(_)==OOo================
=
Olaf Titz
> reinventing the monolithic operating system) and release Linux in it's
> original unusable version (no shell??? or something). Then a BUNCH of
not quite correct... it did have a shell, some weird pre-release of
bash with half of the documented features not working, but it was
usable. It did not have an init or login, so you could only boot into
single user mode and once you logged out, the only key accepted
further was Reset. :-)
0.12 (or was it 0.11?) corrected this: it had a mini-init inside the
kernel (which is still there, in case there is no user space init
available) which spawns /bin/sh, waits for its demise ('child xxx
died with code yyy' or something) and re-spawns it.
A working init/login package (by Peter Orbaek) was among the first
'third-party' software available for Linux. :-)
> people jumped ship from minix to Linux. My resounding opinion is that
> none of this would have happened as quickly as it did without Andrew
> Tanenbaum's work on minix and the introduction of comp.os.minix.
Right. In fact, the structure of the original Linux kernel was heavily
influenced by minix.
> Most of Europe seems to have adopted Linux as their system of choice. I
> expect that this is (in part, at least) to the fact that Linus is from
> Europe. Why put up with those silly export restrictions and long
> distance network connections when Linux is available right there on the
> continent.
Europeans pull their Linux software mostly from tsx-11 at MIT. :-)
(nic.funet.fi has a terrible connection to the rest of Europe, there
were times when IP traffic from Finland to Germany had to be routed
via the U.S.!)
Mike Haertel
>hard disk with a size multiple of what you need for Linux. When I first
>installed Linux (Oct/Nov. 1992), it was so slender that you could get
>all the base utilities including cc, emacs and kernel sources into as
>much as a 32 MB hard disk!
This has, alas, been fixed in recent versions of Linux, which seems to
have come down with a very serious case of The Bloat. I remember a
time (early 1992) when the Linux kernel was under 25K lines of
code. The 0.99.12 kernel, at 118K lines, is nearly five times
the size. It does not offer five times the functionality.
Similarly, things like the full SLS release have really bloated out--I
helped a friend install SLS last fall, and the full installation with
X came in at around 40 Megs. Just recently tried again, and got
upwards of 80 megs. Yeeow.
(NetBSD kernel: 195K lines. Linux is rapidly catching up. I predict
it will pass NetBSD in bloatedness within 1 year.)
--
Mike Haertel <mi...@ichips.intel.com>
Speaking for myself, not Intel.
David C. Niemi
>In article <24vd7h$f...@horus.mch.sni.de> Martin....@mch.sni.de (Martin Kraemer) writes:
>This has, alas, been fixed in recent versions of Linux, which seems to
>have come down with a very serious case of The Bloat. I remember a
>time (early 1992) when the Linux kernel was under 25K lines of
>code. The 0.99.12 kernel, at 118K lines, is nearly five times
>the size. It does not offer five times the functionality.
Source code expansion is not necessarily bloat -- there is a large increase
in functionality or potential functionality, much of which is #ifdef'd out
for any given compile. The true binary size is a much better indicator.
>Similarly, things like the full SLS release have really bloated out--I
>helped a friend install SLS last fall, and the full installation with
>X came in at around 40 Megs. Just recently tried again, and got
>upwards of 80 megs. Yeeow.
This is with a lot of goodies! Take out the goodies, and it will once
again be small. There are smaller, more minimal flavors of Linux out
there for those who don't want TeX, Emacs, OpenWindows, and/or various
development tools (fortran, pascal, smalltalk, lisp, objective C, etc.).
I still think it is impressive that you can install the SLS "a" set in
12 MB, and it's a fairly reasonable, functional UN*X if a bit minimal.
After that, add what you like!
Linux is still a very lean, fast OS compared to ANY of its competition
(even some versions of DOS!) There are not many OSes that let you run
X-Windows in 4 MB and that can boot multi-user in 10 seconds (DOS takes
longer than that to boot).
---
David C. Niemi: David...@oasis.gtegsc.com
Barneyism is the foolish belief that children are purple.
Hannes Deeken
>Similarly, things like the full SLS release have really bloated out--I
>helped a friend install SLS last fall, and the full installation with
>X came in at around 40 Megs. Just recently tried again, and got
>upwards of 80 megs. Yeeow.
Well, a *BSD system with all the stuff you find in SLS would cost some more
disk space than 80 megs. Time for shared libraries, I guess. ;-)
Anyway, with SLS you don't have to install all and everything. It's split
into packages which are separately installable and deinstallable.
I hope FreeBSD 1.0 and/or NetBSD 0.9 have the concept of 'software packages'
and means to install and deinstall them, at least for 'third party' software
like X or TeX.
Hannes
--
Hans-Christoph Deeken | hannes@flinx.{RoBIN.de,hotb.sub.org} (home)
Gerauer Str. 20 | dee...@iti.informatik.th-darmstadt.de (university)
60528 Frankfurt/M | IRC: Glenlivet
Amancio Hasty Jr
>Olaf Titz <s_t...@ira.uka.de> wrote:
>[ Someone else who uses DOS asks why one would want Linux]
>>A couple of good reasons:
>>...
>
>isolar:2:40 % ls -R1 /var/spool/news/comp/os/386bsd | egrep '^[1-9]' | wc -l
> 226
>isolar:2:41 % ls -R1 /var/spool/news/comp/os/linux | egrep '^[1-9]' | wc -l
> 1593
>
I am not sure that the sheer volume of postings constitutes something
good. In fact, if people have to post all the time it may be because
their is lack of information distribution or something outright wrong.
I have answer numerous postings about XS3 all which are probably
documented somewhere in linux land or because the Linux activits
have not learned the fine Art of looking for an answer to their questions
in their posted newsgroup. Sometimes I am amazed that after I
have answer a question just 5 or more postings later basically
the same question gets posted again by another Linux user.
It appears at least in my case, that Linux users are happy
posters (as in trigger-happy).
We have a news archive in Australis which we telnet to and which we can
do simple greps on subject lines and also we can dowload
subject indexes as well as whole batch of old postings.
It helps both to eliminate mundane postings as well as to
quickly get your answer.
The 386bsd community in terms of development tends to be quiet and
personal mostly due to popular hostile postings against progress
in our newsgroup. For instance, NetBSD is being ported to
different platforms and I hear is up and running on some platforms.
Part of the lack of development effort is due to the syndrome of lets
wait for Bill Jolitz release. This problem has been directly
addressed by FreeBSD and NetBSD.
Cheers,
Amancio Hasty
--
This message brought to you by the letters X and S and the number 3
Amancio Hasty |
Home: (415) 495-3046 | ftp-site depository of all my work:
e-mail ha...@netcom.com | sunvis.rtpnc.epa.gov:/pub/386bsd/incoming
John D. Boggs
>
> I hope FreeBSD 1.0 and/or NetBSD 0.9 have the concept of 'software packages'
> and means to install and deinstall them, at least for 'third party' software
> like X or TeX.
I haven't tried TeX yet, but the X for *BSD is real easy to deinstall:
rm -r /usr/X386
--
John D. Boggs j...@erato.iowa-city.ia.us
or ...!access1!erato!jdb
Linus Torvalds
>
>This has, alas, been fixed in recent versions of Linux, which seems to
>have come down with a very serious case of The Bloat. I remember a
>time (early 1992) when the Linux kernel was under 25K lines of
>code. The 0.99.12 kernel, at 118K lines, is nearly five times
>the size. It does not offer five times the functionality.
No, it doesn't offer 5 times the functionality, but looking at the
kernel, most of the "bloat" is in fact device drivers (and the addition
of networking code since the early versions). The current kernel has
about 95k-lines of C code (and almost 15k+ lines of headers and 5k lines
of assembly), but the breakdown is rather interesting:
kernel proper: 4600 lines
memory management: 2300 lines
virtual filesystem layer: 6200 lines
That's the "essential" services, but you don't get far with just those:
each filesystem at about: 2500 lines (ranging from 1700 to 4000 lines)
character device drivers: 12000 lines
FPU emulator: 7200 lines (+4000 of the 5000 lines of asm)
block drivers: 18600 lines (12000 of which is SCSI supprot)
networking: 21000 lines
+ various other sources, some of them used for the build process, rather
than for the kernel proper.
As can be seen, the real kernel isn't really very big, and has actually
not gotten *that* much larger since the early days. The device drivers
amount for about one third of the kernel (FPU-emulator counting as a
"device driver"), and they have indeed grown a lot (but that's not
bloat: it's mostly just the diversity of PC hardware which makes for a
lot of problems).
The filesystems are about 20000 lines of C code total: about a fifth of
the kernel. The individual filesystems haven't bloated very much, but
there are more of them (minix, ext, ext2, msdos, xiafs, nfs, isofs and
proc-fs). Most of the code bears more than a passing resemblance to the
minix-fs code, so the "new" code is to a large part an adaptation of the
minix-fs code.
Networking is similarly about 20000 lines of C code (this is including
the driver code which is not yet separate as the rest of the drivers).
Back in early 1992 (version 0.12), there was no networking code, only
one filesystem (minix), no scsi devices or CDROM drivers, a much smaller
math-emulator (the one still in use by 386bsd right now?), no mouse
drivers etc. Totally new code since then: at least 60klines of C code
(of 95klines!), mostly drivers.
Linus
Dave Burgess
>In article <24rbb5$t...@hrd769.brooks.af.mil> bur...@hrd769.brooks.af.mil (Dave Burgess) writes:
>
>
>usable. It did not have an init or login, so you could only boot into
>single user mode and once you logged out, the only key accepted
>further was Reset. :-)
>
You are right. I knew it was one of those programs that are hard to
live without. Even with the sh (didn't someone refer to is as
'half-ashed' :) in the state that it was, it presented a cost free
alternative to Minix-386, which still wound up costing around $100 (US).
[good stuff deleted...]
>> people jumped ship from minix to Linux. My resounding opinion is that
>> none of this would have happened as quickly as it did without Andrew
>> Tanenbaum's work on minix and the introduction of comp.os.minix.
>
>Right. In fact, the structure of the original Linux kernel was heavily
>influenced by minix.
>
And the file system and a bunch of other stuff. It was a neat time to
be on the net. It was like watching a shark feeding frenzy :-)
>Europeans pull their Linux software mostly from tsx-11 at MIT. :-)
>(nic.funet.fi has a terrible connection to the rest of Europe, there
>were times when IP traffic from Finland to Germany had to be routed
>via the U.S.!)
>
Oh!
In that case, it must be that Linux is just a better OS :-)...
Maurice S Barnum
In <MIKE.93Au...@pdx800.jf.intel.com> mike@ichips (Mike Haertel) writes:
>In article <24vd7h$f...@horus.mch.sni.de> Martin....@mch.sni.de (Martin Kraemer) writes:
>>hard disk with a size multiple of what you need for Linux. When I first
>>installed Linux (Oct/Nov. 1992), it was so slender that you could get
>>all the base utilities including cc, emacs and kernel sources into as
>>much as a 32 MB hard disk!
hah! I can still do that! well, I think, since I've never even
thought about installing emacs...
>This has, alas, been fixed in recent versions of Linux, which seems to
>have come down with a very serious case of The Bloat. I remember a
>time (early 1992) when the Linux kernel was under 25K lines of
>code. The 0.99.12 kernel, at 118K lines, is nearly five times
>the size. It does not offer five times the functionality.
Yes, but how much of the size increase is due to the several
filesystems, a bunch of SCSI drivers, the networking code (and the
accompanying ethernet drivers), and the 387 emulator that now
comes with the kernel? None of that is part of The Bloat, because
if you choose not to compile those features in, you don't get
them. And if you do configure the world, you deserve a huge
kernel.
I too have noticed that my compiled kernel sizes have gotten
somewhat larger since early '92. Maybe even twice as large
(system sizes are now about 430k pre-compression). Of course, I
compile in xiafs, ext2, procfs, msdos filesystems and (just the
way things have gone) either networking or the 387 emulator. I
have not noted the sizes, but I can almost guarantee you that the
patched-pl12 kernel I'm running now (or the alpha-10, which was
the last one to have 387 code in in) was not 5x bigger than
whatever the current kernel was in early '92.
>Similarly, things like the full SLS release have really bloated out--I
>helped a friend install SLS last fall, and the full installation with
>X came in at around 40 Megs. Just recently tried again, and got
>upwards of 80 megs. Yeeow.
finally, as recently as 3 months ago, I had X (including the linux
xview package), a full set of development tools (no emacs), kernel
source, and various other goodies installed on a little under
30mb on the /usr partition. I didn't use SLS for most of it,
though.
--
Maurice S. Barnum --- I consult, therefore I am:
Ask me, and I shall answer.
Believe me, and I shall laugh.
m...@cats.ucsc.edu, mba...@eis.calstate.edu, mba...@nyx.cs.du.edu
Alan Cox
no silly extra file systems, no SCSI and no SYS5 IPC Linux is still pretty
close to the size it started as (apart from the VFS).
ALan
Piercarlo Grandi
>>> (Hannes Deeken) said:
Hannes> I hope FreeBSD 1.0 and/or NetBSD 0.9 have the concept of
Hannes> 'software packages' and means to install and deinstall them, at
Hannes> least for 'third party' software like X or TeX.
One can get from CMU a rather nice package install/deinstall utility
called 'depot' that does this rather elegantly. Unfortunately it
requires a bit of hand munging of most makefiles, as under it the
installation directory is not the same directory as the directory under
which the program will be run (each package is installed in a subtree of
its own; depot then merges packages into a single subtree for users to
use). As far as I know only perl has the right configuration options
that allow for separate architecture dependent/independent install dirs
and separate install/run subtrees...
Dejan Vucinic
|> Linux is still a very lean, fast OS compared to ANY of its competition
|> (even some versions of DOS!)
Ooops!
Watch out! This implies that DOS, being a single-user-all-the-CPU-you-can-get
OS, is at least as fast as 386 Unices. BUT:
Some time ago, I was talking with a friend of mine, trying to convince
her to switch from DOS to *BSD/Linux. She used her 386 box for (heavy? :)
number crunching with Fortran, she was writing a Ph.D. thesis and was spending
most of her time calculating some fractal motion. So, I needed a little demo
to show her that she could indeed do all that she usually did under messdos
and pay 0.0 for it. I picked 386bsd, version 0.1 it was, when the first bunch
of patches was released, and compiled a tiny fortran->C source compiler I
found on ref.tfs.com. It compiled her programs without a cough, and gcc did
the rest.
Now, the copmarison. Those were EXACTLY THE SAME MACHINES. Bought from
a same vendor, exactly the same equipment inside, 387 FPU in both of them.
Fortran on DOS was an expensive commercial product, it was dos 5.0 if I
remember well, and under DOS the program ran about a minute and five seconds
on both of them. We ran the program on BSD, fifteen seconds. Well, I know
that in real mode 386 emulates 32bit integer operations, but FOUR TIMES
FASTER!? Get real!
All this probably holds for Linux as well. It seems that DOS engineers
used some other mathematics in their time calculations. ;>
Don't trust figures too much. Try and measure. You'll be surprized.
Regards, Dejan
Drew Eckhardt
>In article <24vd7h$f...@horus.mch.sni.de> Martin....@mch.sni.de (Martin Kraemer) writes:
>>hard disk with a size multiple of what you need for Linux. When I first
>>installed Linux (Oct/Nov. 1992), it was so slender that you could get
>>all the base utilities including cc, emacs and kernel sources into as
>>much as a 32 MB hard disk!
When I first installed Linux, (December 1991), it was so slender that I
could get all the base utilities including cc, vi, and kernel sources into
10M of disk (the only error free partition on my 45M MFM drive).
I also built kernels using GCC in 4M of main memory and no swap.
However, Linux didn't run X, didn't have shared libraries, programs had
to be compiled for either hardware or software floating point (which didn't
work reliably), etc.
>This has, alas, been fixed in recent versions of Linux, which seems to
>have come down with a very serious case of The Bloat. I remember a
>time (early 1992) when the Linux kernel was under 25K lines of
>code. The 0.99.12 kernel, at 118K lines, is nearly five times
>the size. It does not offer five times the functionality.
In the kernel, much of the "bloat" is from optional device drivers that
you don't have to install (SCSI drivers, CD ROM, XD disk drivers - about
20k, most of that SCSI) optional networking code (about 25K), and optional
file systems (beyond ext2 as the unix filesystem - about 16K lines of code).
Ie, for many people, as little as half the code will end up in their kernels.
For the people who need some of those features (ie, those with SCSI disks
only), the "bloat" means an infinite increase in functionality, because without
it they couldn't run Linux period.
As to weather the rest of the code increase is worth it : I'd say yes. That
code gets you features like shared libraries, the fully unified buffer cache
vnode based vm, VFS, a full 387 emulator, and other features that make Linux
more flexible, faster, and cleaner.
>Similarly, things like the full SLS release have really bloated out--I
>helped a friend install SLS last fall, and the full installation with
>X came in at around 40 Megs. Just recently tried again, and got
>upwards of 80 megs. Yeeow.
Again, a lot of that is optional. Personally, I wouldn't use Open Look,
f2c, p2c, emacs, and many of the other programs included with it. When
you start getting rid of packages like Common Lisp (2M), unused X servers
(1M each), etc. the space used drops off rapidly.
--
Boycott USL/Novell for their absurd anti-BSDI lawsuit. |
Condemn Colorado for Amendment Two. | Drew Eckhardt
Use Linux, the fast, flexible, and free 386 unix | dr...@cs.Colorado.EDU
Will administer Unix for food |
Hannes Deeken
>From article <deeken.7...@iti.informatik.th-darmstadt.de>, by dee...@iti.informatik.th-darmstadt.de (Hannes Deeken):
>>
>> I hope FreeBSD 1.0 and/or NetBSD 0.9 have the concept of 'software packages'
>> and means to install and deinstall them, at least for 'third party' software
>> like X or TeX.
>I haven't tried TeX yet, but the X for *BSD is real easy to deinstall:
> rm -r /usr/X386
And how do you reverse the changes done by x386install to the rest of your
system (possibly /dev, /etc/ttys, /etc/man.conf) automatically?
(No, I don't consider trying to do this practical. Too complex. ;)
Ok, X was a bad example, because it resides mostly in it's own subtree.
What about a package which installs to /usr/local/bin, /usr/local/lib/<wherever>
and /usr/local/man? Or worse, to /usr/bin, /usr/libexec/uucp and /usr/share/man,
like a new version of UUCP? (Yes, UUCP is part of the base system, but there's
no reason why I couldn't fetch the latest sources for Taylor uucp and install
it myself (done so already). That makes it 'third party'.)
Peter da Silva
> Now, the copmarison. Those were EXACTLY THE SAME MACHINES. Bought from
> a same vendor, exactly the same equipment inside, 387 FPU in both of them.
> Fortran on DOS was an expensive commercial product, it was dos 5.0 if I
> remember well, and under DOS the program ran about a minute and five seconds
> on both of them. We ran the program on BSD, fifteen seconds. Well, I know
> that in real mode 386 emulates 32bit integer operations, but FOUR TIMES
> FASTER!? Get real!
Yep, I can easily see that.
And UNIX disk I/O is better than ANY DOS I've seen, even with superturbocache
installed. CC was about 3 times faster under Xenix-86 than Microsoft C (the
same compiler at the time) under PC-DOS... both on an XT.
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' Hefur thu fadhmadh ulfinn i dag?
'U`
"Det er min ledsager, det er ikke drikkepenge."
Shawn F. Mckay
to have a 386 to run, I'll have little trouble choosing. And IDE
drives are CHEAP and plentiful.
- Shawn
Mark Lord
...
> Now, the copmarison. Those were EXACTLY THE SAME MACHINES. Bought from
>a same vendor, exactly the same equipment inside, 387 FPU in both of them.
>Fortran on DOS was an expensive commercial product, it was dos 5.0 if I
>remember well, and under DOS the program ran about a minute and five seconds
>on both of them. We ran the program on BSD, fifteen seconds. Well, I know
>that in real mode 386 emulates 32bit integer operations, but FOUR TIMES
>FASTER!? Get real!
Most of this speedup is very likely due to the quality of the 386-specific
C compiler used on BSD. But then, that *is* a valid thing to include in
many such comparisms. However, were the program built for MSDOS with a compiler
that generated code of similar quality, the two run-times (excluding any IO)
would then compare much more closely. With a decent MSDOS cache (HYPERDISK)
even the I/O would be as good for DOS as for BSD (if not better).
--
ml...@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
J Wunsch
[for Linux]
>Plus there is much more support for "cheap" hardware and for two-or-
>more-OS's-on-one-harddisk.
Yep, the Linux support for two-or-more-OS's ain't the best. Not that
i hate Linux, but i'm still curious why they decided to have this silly
off-the-standard booting scheme (LILO). With *BSD using a normal dozz
boot scheme (load MBR, and then load the active partition's boot sector),
along with one of the fancy boot managers (i'm using os-bs), it works
like a charm. You could also boot those silly unices requiring their
own partition being marked active. (Another problem of Linux is, they
occupy a full dozz partition for swap instead of sub-partitioning their
primary one.)
Btw., i've been working with my old cheep PC from older dozz times.
A 386SX/16 w/ 6 MB of RAM and a bloody old Trident VGA, i even compiled
the whole XFree86 under 386BSD (approx. time: 24 hours:-).
The really disadvantage of BSD is it's lack of shared libs, thus consu-
ming much more disk space. But the original shared libs from Linux didn't
convince me either: i saw it at a friend, he quickly felt that his Linux
got binary-incompatible to itself. (Since the binaries had to match
exactly the shared libs.)
Last not least: take out all the `unnecessary' things from the BSD
kernel (IP, various file systems, SCSI, Ethernet, SLIP etc. etc.),
you'll get a (IMHO much useless) very tiny kernel:-)
--
in real life: J"org Wunsch | ) o o | primary: joerg_...@tcd-dresden.de
above 1.8 MHz: DL 8 DTL | ) | | private: joerg_...@uriah.sax.de
| . * ) == |
``An elephant is a mouse with an operating system.''
J Wunsch
>more-OS's-on-one-harddisk.
Yep, the Linux support for two-or-more-OS's ain't the best. Not that
Drew Eckhardt
>In <24vd7h$f...@horus.mch.sni.de> Martin....@mch.sni.de (Martin Kraemer) writes:
>[for Linux]
>>Plus there is much more support for "cheap" hardware and for two-or-
>>more-OS's-on-one-harddisk.
>
>Yep, the Linux support for two-or-more-OS's ain't the best.
When my system comes up, my master boot record (winiboot) asks me
which partition I want to boot. If I don't choose something
(with one keypress) within the timeout period, Linux is automatically
booted.. If I press some key for a different OS, it gets booted instead.
How can multi-OS operation be simpler than that?
While this isn't the default installation (with LILO), winiboot is
available as part of the shoelace package, available in source
and binary form.
>i hate Linux, but i'm still curious why they decided to have this silly
>off-the-standard booting scheme (LILO).
LILO is a bootblock replacement for the bootblock within a partition,
there's nothing non standard about that.
As far as the LILO bootblock being different from BSD's - it
was developed under a different set of design constraints. Size
is more limited than with BSD because we don't have things sub
partitioned with an area for the disklabel / bootblock set aside.
This limits the amount of functionality. We can't work like the
BSD bootblock and prompt to boot any file, since users must be
able to boot of more than one type of FS, and we don't have room
to support the proliferation of filesystems in the bootblock. So,
we needed a minimal bootstrap that could locate a block mapping for
various kernel immages and load them as directed.
>With *BSD using a normal dozz
>boot scheme (load MBR, and then load the active partition's boot sector),
That's how Linux + LILO and the master boot record of your choice.
>along with one of the fancy boot managers (i'm using os-bs), it works
>like a charm. You could also boot those silly unices requiring their
>own partition being marked active.
The same thing applies to Linux.
>(Another problem of Linux is, they occupy a full dozz partition for swap
instead of sub-partitioning their primary one.)
Linux supports MS-DOS extended partitions, if you choose to use
them you can have multiple Linux / DOS / etc. partitions in one
physical partition.
>Btw., i've been working with my old cheep PC from older dozz times.
As are many starving college student and unemployed hacker types :-)
>The really disadvantage of BSD is it's lack of shared libs, thus consu-
>ming much more disk space. But the original shared libs from Linux didn't
>convince me either: i saw it at a friend, he quickly felt that his Linux
>got binary-incompatible to itself. (Since the binaries had to match
>exactly the shared libs.)
The key word there is "original". The original implementation of shared
libraries under Linux was deficient in this regard, since they were
statically linked. This got you very low disk space usage, low
memory usage, etc, but none of the benefits of dynamic linking and
ease of fixing library bugs in all your binaries. In other words, it
was still better than no shared libraries.
After that, Linux got the so-called "jump table" libraries, where
the jump table was at a fixed location but the routines could move.
This let us upgrade shared libraries without recompiling anything,
making it easy to fix library bugs.
The currenty Linux shared library implementation is dynamic.
>
>Last not least: take out all the `unnecessary' things from the BSD
>kernel (IP, various file systems, SCSI, Ethernet, SLIP etc. etc.),
>you'll get a (IMHO much useless) very tiny kernel:-)
The same thing applies to all unices. Any good system administrator
will trim out everythign he/she doesn't need to maximize the amount
of free memory and consequently the size of the incore page set.
Mark Sienkiewicz
>used some other mathematics in their time calculations. ;>
>
> Don't trust figures too much. Try and measure. You'll be surprized.
When you look at DOS machines, you have to pay close attention to just what
the benchmarks measure. Often, you will find the Unix-ish system had to
support 32 bit integers and a megabyte of memory, while the DOS system got
to get away with 16 bit integers and 64k.
Your friend probably did a fair chunk of shuffling things around in large
model.
It probably also helped that you used GCC as a code generator. You might
try running the same fortran through f2c and compiling it for DOS with
a good compiler like Turbo C (or whatever they're calling it these days).
jsc...@finbol.toppoint.de
>off-the-standard booting scheme (LILO). With *BSD using a normal dozz
that dos boot schemes are obsolent.( boot from first HD smaler 1GB)
>Last not least: take out all the `unnecessary' things from the BSD
>kernel (IP, various file systems, SCSI, Ethernet, SLIP etc. etc.),
>you'll get a (IMHO much useless) very tiny kernel:-)
... and a DOS-like kernel without features,
I need IP, SCSI, Ethernet, SLIP, ISO9660-FS, MSDOS-FS, ...
BSD is quite good, but you need more knowledge of unix/bsd
for many people Linux is easier to install,
easier in setup,
easier in building new kernels,
easier to get drivers for exotic hardware and ...
faster in development (this includes : find & produce bugs)
and easier to get (SLS, MCC, SLA....)
I think Linux-Distributions are better than comercial-ix-versions.
Joerg
P.S.: If I setup my next unix-system, I install a BSD.
--
+++++++++++++++++++++++++++++++++++++++++++++++++++
Joerg Schlaeger jsc...@finbol.toppoint.de
24113 Kiel Tel.: ++49 431 682210 (voice)
---------------------------------------------------
Amancio Hasty Jr
>In article <252n71$2...@fnnews.fnal.gov> de...@cdfsga.fnal.gov (Dejan Vucinic) writes:
>>
>> All this probably holds for Linux as well. It seems that DOS engineers
>>used some other mathematics in their time calculations. ;>
>>
>> Don't trust figures too much. Try and measure. You'll be surprized.
>
>When you look at DOS machines, you have to pay close attention to just what
>the benchmarks measure. Often, you will find the Unix-ish system had to
>support 32 bit integers and a megabyte of memory, while the DOS system got
>to get away with 16 bit integers and 64k.
>
How long did it take Microsoft to address the functionality provided
by Unix-like system? And, better yet can it compare in terms of
of resource utilization to Unix like systems?
Look now days you can buy a 486 with 64k cache. I don't think
that *BSD systems are attempting to be ultra minimalistic systems.
And, I don't think that anyone is going to bring out and dust off
the earlier versions of Unix which ran in 64k of memory in a PDP-11.
To take it to another extreme, last nite playing around with postgres,
an object-oriented databse, I was amazed at the size for just the
postgres binary, 11MB. Of course, the postgres installation included
other binaries. I wonder how a dos like system would handle such
a program. Oh, I know that it can be done.
Amancio
Andreas Klemm
>In <24vd7h$f...@horus.mch.sni.de> Martin....@mch.sni.de (Martin Kraemer) writes:
>[for Linux]
>>Plus there is much more support for "cheap" hardware and for two-or-
>>more-OS's-on-one-harddisk.
>The really disadvantage of BSD is it's lack of shared libs, thus consu-
>ming much more disk space.
>But the original shared libs from Linux didn't
>convince me either: i saw it at a friend, he quickly felt that his Linux
>got binary-incompatible to itself. (Since the binaries had to match
>exactly the shared libs.)
Oh my goodness. Is that the real truth ? No.
Sorry. You forgot to say, that the new libraries are compatible
to the older ones. I think that's more important !!!
Don't know what problems your friend had ... ?!
An example: I started with SLS 1.01
That was a system with the shared lib release libc.so.4.3.3.
I had gcc 2.3.3, gas 1.38, ... and the kernel 0.99 pl 8 or so.
Then I wanted to compile and install the newer kernel 0.99 pl 11.
What was to to ...
I saw in the README, that the kernel can only be successfull compiled
with gcc-2.4.5. Ok I fetched this one via ftp mailer. No problem.
I saw, that gcc-2.4.5 was compiled with newer shared libs
(I had libc.so.4.3.3, I needed libc.so.4.4.1). NO problem...ftp mail...
The only thing I had to do, to upgrade the shared libs, was
to do an
cd /lib
ln -sf libc.so.4.4.1 libc.so.4
No problem under a running system !!!!
Important is the option f to force the symbolic link.
And what I want to make clear .... the new shared libs are compatible
to the older ones ... I could use every binary, that was compiled and
linked when the old shared libs were in use !!!!!!
--
/-\ Andreas Klemm <and...@knobel.knirsch.de> +-----------------+
|@|########################################################-@ "pay for it !" |
\-/ 41469 Neuss Germany phone +49/ 2137 12609 +-----------------+
Charles Hannum
Some serious comments on your comparison; no flames intended.
In article <1993Aug23....@finbol.toppoint.de>
jsc...@finbol.toppoint.de writes:
BSD is quite good, but you need more knowledge of unix/bsd
I don't really believe this. Linux also requires a fair amount of
Unix-specific knowledge to configure. For the most part, the default
installation works (as it does in NetBSD also), but it is not enough
to actually run a system well. You need to configure the network,
sendmail, getty (for serial ports at least), maybe SLIP and/or PPP,
etc., etc.
for many people Linux is easier to install,
The NetBSD installation process is pretty simple, though it's not what
I ultimately want. I rather like the SunOS and Ultrix installations,
and a similar installation system is being developed for NetBSD.
easier in setup,
See above.
easier in building new kernels,
Meaning it's interactive? BSD in general is much easier to configure
after you learn how to read and write config files. And it's pretty
straightforward. I config'd a SunOS kernel for the first time without
consulting any man pages; I just looked at the existing config files
and did the obvious thing.
easier to get drivers for exotic hardware and ...
It is true that there are some pieces of hardware which Linux drivers
but not NetBSD drivers exist for. Fortunately most of them aren't
very popular (or perhaps that's why we don't have drivers for them
yet), so this is not a major drawback. If I had any of them, I would
endeavour to rectify the situation. (Consider that a hint to anyone
with more money than me.)
faster in development (this includes : find & produce bugs)
That's not clear. There is a fundamental difference between Linux and
NetBSD in this, however; while Linus and others involved in Linux
(Peter MacDonald, the authors of various packages, etc.) are willing
to make new releases very frequently, there is little organization.
In my experience, very few users actually want to update their systems
a few times a month (or for that matter, possibly a new version of
some program or other every single day). We (the NetBSD group)
endeavour to organize more coherent releases. In particular, we like
to make sure everything at least minimally works; SLS releases have
often contained non-functional programs.
For people who want frequent updates, we have our current source tree
available by FTP and SUP. The publicly available sources are updated
nightly from our working CVS tree, and usually work a bit better than
the releases. (The work doesn't ever stop; we've made many changes
even since the 0.9 sources were pretty much frozen.)
and easier to get (SLS, MCC, SLA....)
NetBSD is not as many FTP sites, but it is certainly not hard to get,
for anybody on the net, at least. By the time 1.0 is released, there
will be a CD-ROM distribution.
One serious advantage of NetBSD for me is that it runs on multiple
platforms. I now have a HP 370 (68030-based machine) happily running
a complete NetBSD system, and it's actually significantly faster than
my 386. There are several other ports in progress, some of which are
running. Hopefully we will have a few of them in our common source
tree for the 1.0 release.
Tim Villa
> - Shawn
And it should make no attempt to run on a 286. Apart from the fact that
the things are brain dead, they are 16 bit processors which simply
cannot support a 32 bit operating system.
Tim
Peter da Silva
> the benchmarks measure. Often, you will find the Unix-ish system had to
> support 32 bit integers and a megabyte of memory, while the DOS system got
> to get away with 16 bit integers and 64k.
Oh yeh. On one benchmark (seive) Byte was reporting a factor of *11* slow-
down when the array size got over 64K.
Peter da Silva
> How long did it take Microsoft to address the functionality provided
> by Unix-like system?
They haven't yet.
Peter Holzer
>In article <hastyCC...@netcom.com> ha...@netcom.com (Amancio Hasty Jr) writes:
>> How long did it take Microsoft to address the functionality provided
>> by Unix-like system?
>They haven't yet.
Actually, they did. Before they adapted MS-DOS to the IBM-PC, they
ported Unix (System III?) to a (non IBM) 8086 box and called it Xenix.
Later they ported it to IBM-clones as well.
__
Peter Holzer <h...@vmars.tuwien.ac.at> TU Wien, Real-time systems
It that was long ago and it was far away,
And it was so much better than it is today
(Meat Loaf: Paradise by the dashboard light)
--
| _ | Peter J. Holzer | Think of it |
| |_|_) | Technical University Vienna | as evolution |
| | | | Computer Science/Real-Time Systems | in action! |
| __/ | h...@vmars.tuwien.ac.at | Tony Rand |
Brett Lymn
David> Article-I.D.: europa.250m5t$dmk
David> NNTP-Posting-Host: hengist.lab.oasis.gtegsc.com
David> In article 93Aug1...@pdx800.jf.intel.com, mike@ichips (Mike Haertel) writes:
>In article <24vd7h$f...@horus.mch.sni.de> Martin....@mch.sni.de (Martin Kraemer) writes:
[lotsa stuff about the slenderness of linux deleted]
David> Linux is still a very lean, fast OS compared to ANY of its competition
Have you numbers to back this? I tried compiling jgraph and comparing
the numbers from a Linux machine. I found that my 486/25 (running X
at the time) was faster than a 486/33 Linux machine. Anyone in the
linux world care to try a benchmark, it does not have to be anything
particular, just something that is portable and meaningful on both
Linux and *BSD.
David> (even some versions of DOS!)
You cannot really do a comparison with Mega-Loss as it is not in the
same league. MS-DOS is a single tasking program loader (some people
dispute is being an OS), comparing that to *any* multitasking system
running on hardware of the same power you will lose. Basically
because the task switching will have the effect of increasing the
application time, you may win on the i/o throughput because Linux/*BSD
cache the writes to devices but you are not proving anything really.
David> There are not many OSes that let you run
David> X-Windows in 4 MB and that can boot multi-user in 10 seconds (DOS takes
David> longer than that to boot).
Sure, X will run in 4Megs but can you do anything with it? I think it
would depend on what you expected. Myself, I like having a lot of
xterms open rlogin'ed to machines at work, run emacs (v19 :-), gdb and
compile without having the machine thrash. Do not tell me I can use
other tools that have had features removed to save space, I know about
them but do not like the sacrifices made (this is MHO) to shoehorn
them. If you are going to say X runs in 4Meg, tell us what you use
and what you do with X.
I found X in 8Meg was a bit tiresome when I started doing real
development work, running emacs, a couple of gdb's, some xterms and
compiling would make my system swap, increasing the RAM to 16Meg made
life more comfortable. At that stage I was not running *BSD but a
commercial unix with Xfree (before it was called that).
--
Brett Lymn
Peter Mutsaers
>> said:
JW> i hate Linux, but i'm still curious why they decided to have
JW> this silly off-the-standard booting scheme (LILO). With *BSD
JW> using a normal dozz boot scheme (load MBR, and then load the
JW> active partition's boot sector), along with one of the fancy
JW> boot managers (i'm using os-bs), it works like a charm. You
JW> could also boot those silly unices requiring their
LILO is just very flexible; apparently you are not informed about the
possibilities of its use. I for example, have a very standard LILO
installation, where the original MBR is left untouched, and the active
partition is the one where LILO is in the boot sector. Then LILO
starts through this, and I can select a number of kernels in this
partition, or other operating systems on other partitions. If I don't
touch a key, the default /vmlinuz image is loaded. You *can* also
overwrite the MBR with LILO, but it is not recommended and not
necessary.
JW> own partition being marked active. (Another problem of Linux is,
JW> they occupy a full dozz partition for swap instead of
JW> sub-partitioning their primary one.)
You can use swap files, which reside on a normal filesystem. So you
don't need a partition for swap. But of course, swap on a raw
partition, not bothered by a present filesystem structure, is much
more efficient.
JW> The really disadvantage of BSD is it's lack of shared libs, thus
JW> consu- ming much more disk space. But the original shared libs
JW> from Linux didn't convince me either: i saw it at a friend, he
JW> quickly felt that his Linux got binary-incompatible to
JW> itself. (Since the binaries had to match exactly the shared
JW> libs.)
Since there are DLL libraries everything stays compatible. I have
binaries which run still fine that were compiled months ago, 4 versions
of the shared libs back (for a 'normal' operating system that would be
equivalent to running binaries that are decades old with todays shared
libs :)
--
_______________________________________________________________
Peter Mutsaers, Bunnik (Ut), the Netherlands.
Disclaimer: This reflects the official opinions of my employer.
Bruce Evans
>When my system comes up, my master boot record (winiboot) asks me
>which partition I want to boot. If I don't choose something
>(with one keypress) within the timeout period, Linux is automatically
>booted.. If I press some key for a different OS, it gets booted instead.
Same here. Except 386BSD is booted after the timeout instead of Linux :-).
>While this isn't the default installation (with LILO), winiboot is
>available as part of the shoelace package, available in source
>and binary form.
There are some copyright problems with shoelace, but they mostly don't
affect winiboot. I think LILO was written partly as an overreaction
to the copyright problems.
>As far as the LILO bootblock being different from BSD's - it
>was developed under a different set of design constraints. Size
>is more limited than with BSD because we don't have things sub
>partitioned with an area for the disklabel / bootblock set aside.
This is the main reason why a BSD-style bootblock won't work for
Linux. Linux originally had only the minix fs, which allows only
1K for the boot program where 386BSD's requires 8K.
I't might be good to put multiboot stuff in the 386BSD boot block.
The code is trivial except for mode-switching stuff which the
the "BIOS" 386BSD boot blocks already handle.
Joerg Wunsch writes:
>>(Another problem of Linux is, they occupy a full dozz partition for swap
>instead of sub-partitioning their primary one.)
The 386BSD subpartioning leaves a lot to be desired. It should at
least handle the standard 4 partitions. Then there are extended
partitions. I think DOS allows at most 26 partitions per drive (up to
25 of them in extended partitions), and Linux is normally wired for at
most 8 partitions per drive, but I once supported 32 partitions per
drive in the Minix driver. The 386BSD approach is best except for the
small number of subpartition and lack of support for foreign
partitions. Foreign partitions need to be supported if only to avoid
writing to them.
--
Bruce Evans b...@kralizec.zeta.org.au
Keith Smith
>>off-the-standard booting scheme (LILO). With *BSD using a normal dozz
>lilo works for me and most other, and there may come the time
>that dos boot schemes are obsolent.( boot from first HD smaler 1GB)
I have found booting to be annoying on _ALL_ IBM-PC based hardware. My
old Heath H-8 had software that would allow me to boot at will from
_ANY_ disk partition (And it supported like up to 256), as well as from
floppy. The H-120 used to come up and give you "The Finger" and allow
you to boot either DOS(86) or CP/M-85 from the finger prompt.
My first thought on an AT was "But what if I want to boot something
besides DOS?" Oh, I get to jump thru hoops, nice.
--
Keith Smith ke...@ksmith.com 5719 Archer Rd.
Digital Designs BBS 1-919-423-4216 Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
David Hedley
[ stuff deleted ]
: Now, the copmarison. Those were EXACTLY THE SAME MACHINES. Bought from
: a same vendor, exactly the same equipment inside, 387 FPU in both of them.
: Fortran on DOS was an expensive commercial product, it was dos 5.0 if I
: remember well, and under DOS the program ran about a minute and five seconds
: on both of them. We ran the program on BSD, fifteen seconds. Well, I know
: that in real mode 386 emulates 32bit integer operations, but FOUR TIMES
: FASTER!? Get real!
: All this probably holds for Linux as well. It seems that DOS engineers
: used some other mathematics in their time calculations. ;>
: Don't trust figures too much. Try and measure. You'll be surprized.
I think the real reason for the speed increase lies with gcc. I use gcc v2 under
DOS and it blows Borland C out of the water... I suspect that if you compiled
your C program under DOS gcc, you would find a similar (if not greater) speed
increase.
David
--
Internet email: hed...@cs.bris.ac.uk
or: cs1...@seqa.bris.ac.uk
Bernd Meyer
>In article <hastyCC...@netcom.com> ha...@netcom.com (Amancio Hasty Jr) writes:
>> How long did it take Microsoft to address the functionality provided
>> by Unix-like system?
>They haven't yet.
right! try "dir a.exe b.exe" or "more read.me"
Fascinating error messages...
Bernie
--
We both know that the earth is round | Bernd Meyer, EE-student
So we can't see the way before us to its end | "Nobody is a failure who has
We walk on this way, hand in hand, | friends" (from: isn't it a
And I hope you are still with me behind the horizon| wonderful life?"
Keith Smith
>pe...@NeoSoft.com (Peter da Silva) writes:
>
>>In article <hastyCC...@netcom.com> ha...@netcom.com (Amancio Hasty Jr) writes:
>>> How long did it take Microsoft to address the functionality provided
>>> by Unix-like system?
>
>>They haven't yet.
>
>Actually, they did. Before they adapted MS-DOS to the IBM-PC, they
>ported Unix (System III?) to a (non IBM) 8086 box and called it Xenix.
>Later they ported it to IBM-clones as well.
Actually they never quite got this to work correctly, so a couple of
Hippie Computer guru's in Santa Cruz, CA got together and bought into
Xenix with exclusive distribution rights, and worked all the bugs out of
the Microsoft code. Can you say SCO?
A Wizard of Earth C
[ ... MS getting UNIX functionality on Xenix ... ]
>Actually they never quite got this to work correctly, so a couple of
>Hippie Computer guru's in Santa Cruz, CA got together and bought into
>Xenix with exclusive distribution rights, and worked all the bugs out of
>the Microsoft code. Can you say SCO?
(1) Doug has never struck me as a hippie -- but then again, some of
the people he hires fit that bill. 8-).
(2) The Tandy 6000 is a 68000 based Xenix box; Altos also went the Xenix
route with a number of their boxes, so SCO isn't alone.
(3) I believe the first Xenix ran on Sun 3/60's at Microsoft -- I used
to work for a comm software company, and someone at Microsoft called
and asked if we'd run on this -- then said "Oh, I guess not; that's
an internal product".
Terry Lambert
te...@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Andreas Klemm
>In article <25d4tg$3...@email.tuwien.ac.at> h...@vmars.tuwien.ac.at (Peter Holzer) writes:
>>pe...@NeoSoft.com (Peter da Silva) writes:
>>>In article <hastyCC...@netcom.com> ha...@netcom.com (Amancio Hasty Jr) writes:
>>>> How long did it take Microsoft to address the functionality provided
>>>> by Unix-like system?
>>
>>>They haven't yet.
>>
>>Actually, they did. Before they adapted MS-DOS to the IBM-PC, they
>>ported Unix (System III?) to a (non IBM) 8086 box and called it Xenix.
>>Later they ported it to IBM-clones as well.
>Xenix 1.x was a Version 7 kernel. Come to think of it, "Xenix System V"
>*still* behaves an awful lot like a heavily-hacked Version 7....
That was the first Unix OS I saw 12 years ago: 8086 Microsoft Xenix.
On an original IBM AT 286 with 6 MHz and 512 KB RAM and an originally
20 MB IBM harddisk. 10 MB DOS, 10 MB Xenix ... and we didn't get rogue
compiled with it ;-)
There were 2 Xenix versions available for PC's one from MS and one
from SCO. SCO later offered 80286 versions...laster 80386 versions,
where only 20% of the programs were 80386 code, the rest still
remained 80286 and 8086 code (games, dwb, ...).
SCO Xenix / Unix was a beast .....
The microsoft C-Compiler was a shame for C Compiler ... Years later I got
an Xenix System V. I remember situations where the compiler complains about
"structure too complicate, please simplify ..."
Joe Sharkey
>>pe...@NeoSoft.com (Peter da Silva) writes:
>>
>>>In article <hastyCC...@netcom.com> ha...@netcom.com (Amancio Hasty Jr) writes:
>>>> How long did it take Microsoft to address the functionality provided
>>>> by Unix-like system?
>>
>>>They haven't yet.
>>
>>Actually, they did. Before they adapted MS-DOS to the IBM-PC, they
>>ported Unix (System III?) to a (non IBM) 8086 box and called it Xenix.
>>Later they ported it to IBM-clones as well.
Yes, but really actually, in time-order(?)
Microsoft ported UNIX System III to a (non IBM) 8086 box called a PDP-11
and called it Xenix. Not a lot of room left on an RL-02, and you really
wanted split I/D.
Didn't Microsoft also port to VAX, Fortune, Altos.. ???
>Actually they never quite got this to work correctly, so a couple of
>Hippie Computer guru's in Santa Cruz, CA got together and bought into
>Xenix with exclusive distribution rights, and worked all the bugs out of
>the Microsoft code. Can you say SCO?
Fixing bugs isn't porting, valuable and skilled as it is.
>Keith Smith
joe.
--
Joe Sharkey j...@jshark.inet-uk.co.uk ...!uunet!ibmpcug!jshark!joe
150 Hatfield Rd, St Albans, Herts AL1 4JA, UK Got a real domain name
(+44) 727 838662 Mail/News Feeds (v32/v32bis): in...@inet-uk.co.uk