Subject: Linux-Misc Digest #604
From: Digestifier <Linux-Misc-Request@senator-bedfellow.MIT.EDU>
To: Linux-Misc@senator-bedfellow.MIT.EDU
Reply-To: Linux-Misc@senator-bedfellow.MIT.EDU
Date:     Thu, 27 Jan 94 17:50:16 EST

Linux-Misc Digest #604, Volume #1                Thu, 27 Jan 94 17:50:16 EST

Contents:
  Re: Archives of Torvalds/Tanenbaum discussion? (Laszlo Herczeg)
  Re: Slackware needs a shadow package! (Alan Robert Clark)
  RE: Another kind of DOSEMU (horne@leader.pfc.mit.edu)
  Anybody using a UPS? (Scott Barker)
  Re: Solitaire ? (Paal Beyer)

----------------------------------------------------------------------------

From: las@whome.uucp (Laszlo Herczeg)
Subject: Re: Archives of Torvalds/Tanenbaum discussion?
Date: Thu, 27 Jan 1994 11:17:37 GMT

tgm@netcom.com (Thomas G. McWilliams) wrote:
> Gary Shea (shea@hawk.cs.ukans.edu) wrote:
> : Did anyone archive the discussion between Linus Torvalds
> : and Andrew Tanenbaum that apparently took place as
> : Linux was being developed?
> : I'm curious what they had to say.
> 
> I believe that the comp.os.minix group is archived at James Madison
> University but I don't have an address. Ask in comp.os.minix
> 
> Thomas

The complete discussion is available at nic.funet.fi -- in directory
/pub/OS/Linux. However, I can't remember the exact title. I believe
it has "obsolete" in it, so I recommend you run archie with this
regex.
 
 
 I am enclosing the highlights of the discussion. Andrew Tannenbaum
 had a few good points about distibution of Minix through Prentice
 Hall, but overall, Linus Torvalds came through as a more generous, more
 open minded person. 
  
 I also followed Linus's posts to comp.unix.wizards regarding the development
 of an OS, an if anyone wishes to get those articles, they are in volume
 1992 of the comp.unix.wizards. (the group is archived at usc.edu :archives/
 usenet, among many other places.)
  
 --------------------snip snip ------------------------------------------
 
 
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: LINUX is obsolete
Date: 29 Jan 92 12:12:50 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam


I was in the U.S. for a couple of weeks, so I haven't commented much on
LINUX (not that I would have said much had I been around), but for what 
it is worth, I have a couple of comments now.

As most of you know, for me MINIX is a hobby, something that I do in the
evening when I get bored writing books and there are no major wars,
revolutions, or senate hearings being televised live on CNN.  My real
job is a professor and researcher in the area of operating systems.

As a result of my occupation, I think I know a bit about where operating
are going in the next decade or so.  Two aspects stand out:

1. MICROKERNEL VS MONOLITHIC SYSTEM
   Most older operating systems are monolithic, that is, the whole operating
   system is a single a.out file that runs in 'kernel mode.'  This binary
   contains the process management, memory management, file system and the
   rest. Examples of such systems are UNIX, MS-DOS, VMS, MVS, OS/360, 
   MULTICS, and many more.

   The alternative is a microkernel-based system, in which most of the OS
   runs as separate processes, mostly outside the kernel.  They communicate
   by message passing.  The kernel's job is to handle the message passing,
   interrupt handling, low-level process management, and possibly the I/O.
   Examples of this design are the RC4000, Amoeba, Chorus, Mach, and the
   not-yet-released Windows/NT.

   While I could go into a long story here about the relative merits of the
   two designs, suffice it to say that among the people who actually design
   operating systems, the debate is essentially over.  Microkernels have won.
   The only real argument for monolithic systems was performance, and there
   is now enough evidence showing that microkernel systems can be just as
   fast as monolithic systems (e.g., Rick Rashid has published papers comparing
   Mach 3.0 to monolithic systems) that it is now all over but the shoutin`.

   MINIX is a microkernel-based system.  The file system and memory management
   are separate processes, running outside the kernel.  The I/O drivers are
   also separate processes (in the kernel, but only because the brain-dead
   nature of the Intel CPUs makes that difficult to do otherwise).  LINUX is
   a monolithic style system.  This is a giant step back into the 1970s.
   That is like taking an existing, working C program and rewriting it in
   BASIC.  To me, writing a monolithic system in 1991 is a truly poor idea.


2. PORTABILITY
   Once upon a time there was the 4004 CPU.  When it grew up it became an
   8008.  Then it underwent plastic surgery and became the 8080.  It begat
   the 8086, which begat the 8088, which begat the 80286, which begat the
   80386, which begat the 80486, and so on unto the N-th generation.  In
   the meantime, RISC chips happened, and some of them are running at over
   100 MIPS.  Speeds of 200 MIPS and more are likely in the coming years.
   These things are not going to suddenly vanish.  What is going to happen
   is that they will gradually take over from the 80x86 line.  They will
   run old MS-DOS programs by interpreting the 80386 in software.  (I even
   wrote my own IBM PC simulator in C, which you can get by FTP from
   ftp.cs.vu.nl =  192.31.231.42 in dir minix/simulator.)  I think it is a
   gross error to design an OS for any specific architecture, since that is
   not going to be around all that long.

   MINIX was designed to be reasonably portable, and has been ported from the
   Intel line to the 680x0 (Atari, Amiga, Macintosh), SPARC, and NS32016.
   LINUX is tied fairly closely to the 80x86.  Not the way to go.

Don`t get me wrong, I am not unhappy with LINUX.  It will get all the people
who want to turn MINIX in BSD UNIX off my back.  But in all honesty, I would
suggest that people who want a **MODERN** "free" OS look around for a 
microkernel-based, portable OS, like maybe GNU or something like that.


Andy Tanenbaum (ast@cs.vu.nl)


P.S. Just as a random aside, Amoeba has a UNIX emulator (running in user
space), but it is far from complete.  If there are any people who would
like to work on that, please let me know.  To run Amoeba you need a few 386s,
one of which needs 16M, and all of which need the WD Ethernet card.

0, unseen,,
*** EOOH ***
From: meggin@epas.utoronto.ca (David Megginson)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 29 Jan 92 14:12:12 GMT
Organization: University of Toronto - EPAS
Nntp-Posting-Host: epas.utoronto.ca


I would like to at least look at LINUX, but I cannot, since I run
a 68000-based machine. In any case, it is nice having the kernel
independent, since patches like the multi-threaded FS patch don't
have to exist in a different version for each CPU.

I second everything AST said, except that I would like to see
the kernel _more_ independent from everything else. Why does the
Intel architecture _not_ allow drivers to be independent programs?

I also don't like the fact that the kernel, mm and fs share the
same configuration files. Since they _are_ independent, they should
have more of a sense of independence.


David

#################################################################
David Megginson                  meggin@epas.utoronto.ca
Centre for Medieval Studies      david@doe.utoronto.ca
University of Toronto            39 Queen's Park Cr. E.
#################################################################

0, unseen,,
*** EOOH ***
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 29 Jan 92 18:03:01 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes:
>
>Why does the
>Intel architecture _not_ allow drivers to be independent programs?

The drivers have to read and write the device registers in I/O space, and
this cannot be done in user mode on the 286 and 386. If it were possible
to do I/O in a protected way in user space, all the I/O tasks could have
been user programs, like FS and MM.

Andy Tanenbaum (ast@cs.vu.nl)

0, unseen,,
*** EOOH ***
From: gt0178a@prism.gatech.EDU (Jim Burns)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 03:39:48 GMT
Organization: Georgia Institute of Technology

in article <12605@star.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) says:

> The drivers have to read and write the device registers in I/O space, and
> this cannot be done in user mode on the 286 and 386. If it were possible
> to do I/O in a protected way in user space, all the I/O tasks could have
> been user programs, like FS and MM.

The standard way of doing that is to trap on i/o space protection
violations, and emulate the i/o for the user.
-- 
BURNS,JIM (returned student)
Georgia Institute of Technology, 30178 Georgia Tech Station,
Atlanta Georgia, 30332            | Internet: gt0178a@prism.gatech.edu
uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a

0, unseen,,
*** EOOH ***
From: joe@jshark.rn.com
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Summary: Is this for real?
Date: 31 Jan 92 12:55:21 GMT
Organization: a blip in entropy

In article <12605@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes:
>>
>>Why does the
>>Intel architecture _not_ allow drivers to be independent programs?
>
>The drivers have to read and write the device registers in I/O space, and
>this cannot be done in user mode on the 286 and 386. If it were possible
>to do I/O in a protected way in user space,

[[We must be talking about protected mode]] *THIS IS UNTRUE*

The Intel architecture supports independent tasks, each of which can be
given a "i/o privilege level". The convenient approach, used by iRMX(?), is
to "build" a load image ("root" device driver, kernel, MM and FS). Once
booted, these could be replaced by loadable tasks from disc (or network...)
and given a suitable privilege level.

The '386 additionally allows each task to have an "i/o permissions bitmap"
which specifies exactly which ports can be used.
(See "80386 Programmers Reference Manual", chapter 8)

>                                            all the I/O tasks could have
>been user programs, like FS and MM.

Do you really mean "user programs" and not "separate tasks" ??

Separate tasks, possibly privileged, I'll agree with.

User level programs may be ok for teaching operating system principles, or on
toy computers :-)  But a "production" system?  Not on my machines!

>Andy Tanenbaum (ast@cs.vu.nl)

joe.
-- 
joe@jshark.rn.com
uunet!nstar!jshark!joe

0, unseen,,
*** EOOH ***
From: drew@anchor.cs.colorado.edu (Drew Eckhardt)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 2 Feb 92 12:17:44 GMT
Organization: University of Colorado, Boulder
Nntp-Posting-Host: anchor.cs.colorado.edu

In article <12605@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes:
>>
>>Why does the
>>Intel architecture _not_ allow drivers to be independent programs?
>
>The drivers have to read and write the device registers in I/O space, and
>this cannot be done in user mode on the 286 and 386. If it were possible
>to do I/O in a protected way in user space, all the I/O tasks could have
>been user programs, like FS and MM.
>
>Andy Tanenbaum (ast@cs.vu.nl)

Every 386 TSS has an iopermission bitmap.  If the CPL is of a lower priveledge
level than IOPL, the io permissions bitmap is consulted, allowing protection
on a port by port basis.

 

0, unseen,,
*** EOOH ***
From: jonathan@ukmug.uk.mugnet.org (Jonathan Allen)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 3 Feb 92 07:43:00 GMT
Organization: MUGNET UK Backbone (UKMUG)

In article <12605@star.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) wrote:
> In article <1992Jan29.141212.29636@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes:
>>
>>Why does the
>>Intel architecture _not_ allow drivers to be independent programs?
> 
> The drivers have to read and write the device registers in I/O space, and
> this cannot be done in user mode on the 286 and 386. If it were possible
> to do I/O in a protected way in user space, all the I/O tasks could have
> been user programs, like FS and MM.

Surely this could have been done by a minute task just to read/write a
given port address in one message ?  The security could have been checked
like everything else using the process table ...

Sure it would not have been at all efficient, but would have given
the independance at a price.

Jonathan

0, unseen,,
*** EOOH ***
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 7 Feb 92 01:30:59 GMT
Organization: The Portal System (TM)

Andy Tanenbaum (ast@cs.vu.nl) writes:
> The drivers have to read and write the device registers in I/O space, and
> this cannot be done in user mode on the 286 and 386. If it were possible
> to do I/O in a protected way in user space, all the I/O tasks could have
> been user programs, like FS and MM.

On the 386, you could run the drivers in V86 mode, which sort of counts
as user mode and allows access to I/O registers if the kernel sets things
up to allow this.

                                                        Tim Smith

0, unseen,,
*** EOOH ***
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 29 Jan 92 23:14:26 GMT
Organization: University of Helsinki

Well, with a subject like this, I'm afraid I'll have to reply. 
Apologies to minix-users who have heard enough about linux anyway.  I'd
like to be able to just "ignore the bait", but ...  Time for some
serious flamefesting!

In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>
>I was in the U.S. for a couple of weeks, so I haven't commented much on
>LINUX (not that I would have said much had I been around), but for what 
>it is worth, I have a couple of comments now.
>
>As most of you know, for me MINIX is a hobby, something that I do in the
>evening when I get bored writing books and there are no major wars,
>revolutions, or senate hearings being televised live on CNN.  My real
>job is a professor and researcher in the area of operating systems.

You use this as an excuse for the limitations of minix? Sorry, but you
loose: I've got more excuses than you have, and linux still beats the
pants of minix in almost all areas.  Not to mention the fact that most
of the good code for PC minix seems to have been written by Bruce Evans. 

Re 1: you doing minix as a hobby - look at who makes money off minix,
and who gives linux out for free.  Then talk about hobbies.  Make minix
freely available, and one of my biggest gripes with it will disappear. 
Linux has very much been a hobby (but a serious one: the best type) for
me: I get no money for it, and it's not even part of any of my studies
in the university.  I've done it all on my own time, and on my own
machine. 

Re 2: your job is being a professor and researcher: That's one hell of a
good excuse for some of the brain-damages of minix. I can only hope (and
assume) that Amoeba doesn't suck like minix does.

>1. MICROKERNEL VS MONOLITHIC SYSTEM

True, linux is monolithic, and I agree that microkernels are nicer. With
a less argumentative subject, I'd probably have agreed with most of what
you said. From a theoretical (and aesthetical) standpoint linux looses.
If the GNU kernel had been ready last spring, I'd not have bothered to
even start my project: the fact is that it wasn't and still isn't. Linux
wins heavily on points of being available now.

>   MINIX is a microkernel-based system. [deleted, but not so that you
> miss the point ]  LINUX is a monolithic style system.

If this was the only criterion for the "goodness" of a kernel, you'd be
right.  What you don't mention is that minix doesn't do the micro-kernel
thing very well, and has problems with real multitasking (in the
kernel).  If I had made an OS that had problems with a multithreading
filesystem, I wouldn't be so fast to condemn others: in fact, I'd do my
damndest to make others forget about the fiasco.

[ yes, I know there are multithreading hacks for minix, but they are
hacks, and bruce evans tells me there are lots of race conditions ]

>2. PORTABILITY

"Portability is for people who cannot write new programs"
                -me, right now (with tongue in cheek)

The fact is that linux is more portable than minix.  What? I hear you
say.  It's true - but not in the sense that ast means: I made linux as
conformant to standards as I knew how (without having any POSIX standard
in front of me).  Porting things to linux is generally /much/ easier
than porting them to minix.

I agree that portability is a good thing: but only where it actually has
some meaning.  There is no idea in trying to make an operating system
overly portable: adhering to a portable API is good enough.  The very
/idea/ of an operating system is to use the hardware features, and hide
them behind a layer of high-level calls.  That is exactly what linux
does: it just uses a bigger subset of the 386 features than other
kernels seem to do.  Of course this makes the kernel proper unportable,
but it also makes for a /much/ simpler design.  An acceptable trade-off,
and one that made linux possible in the first place.

I also agree that linux takes the non-portability to an extreme: I got
my 386 last January, and linux was partly a project to teach me about
it.  Many things should have been done more portably if it would have
been a real project.  I'm not making overly many excuses about it
though: it was a design decision, and last april when I started the
thing, I didn't think anybody would actually want to use it.  I'm happy
to report I was wrong, and as my source is freely available, anybody is
free to try to port it, even though it won't be easy. 

                Linus

PS. I apologise for sometimes sounding too harsh: minix is nice enough
if you have nothing else. Amoeba might be nice if you have 5-10 spare
386's lying around, but I certainly don't. I don't usually get into
flames, but I'm touchy when it comes to linux :)

0, unseen,,
*** EOOH ***
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 13:44:34 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

In article <1992Jan29.231426.20469@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>You use this [being a professor] as an excuse for the limitations of minix? 
The limitations of MINIX relate at least partly to my being a professor:
An explicit design goal was to make it run on cheap hardware so students
could afford it.  In particular, for years it ran on a regular 4.77 MHZ PC
with no hard disk.  You could do everything here including modify and recompile
the system.  Just for the record, as of about 1 year ago, there were two
versions, one for the PC (360K diskettes) and one for the 286/386 (1.2M).
The PC version was outselling the 286/386 version by 2 to 1.  I don't have
figures, but my guess is that the fraction of the 60 million existing PCs that
are 386/486 machines as opposed to 8088/286/680x0 etc is small.  Among students
it is even smaller. Making software free, but only for folks with enough money
to buy first class hardware is an interesting concept.
Of course 5 years from now that will be different, but 5 years from now 
everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5.

>Re 2: your job is being a professor and researcher: That's one hell of a
>good excuse for some of the brain-damages of minix. I can only hope (and
>assume) that Amoeba doesn't suck like minix does.
Amoeba was not designed to run on an 8088 with no hard disk.


>If this was the only criterion for the "goodness" of a kernel, you'd be
>right.  What you don't mention is that minix doesn't do the micro-kernel
>thing very well, and has problems with real multitasking (in the
>kernel).  If I had made an OS that had problems with a multithreading
>filesystem, I wouldn't be so fast to condemn others: in fact, I'd do my
>damndest to make others forget about the fiasco.
A multithreaded file system is only a performance hack.  When there is only
one job active, the normal case on a small PC, it buys you nothing and adds
complexity to the code.  On machines fast enough to support multiple users,
you probably have enough buffer cache to insure a hit cache hit rate, in
which case multithreading also buys you nothing.  It is only a win when there
are multiple processes actually doing real disk I/O.  Whether it is worth
making the system more complicated for this case is at least debatable.

I still maintain the point that designing a monolithic kernel in 1991 is
a fundamental error.  Be thankful you are not my student.  You would not
get a high grade for such a design :-)


>The fact is that linux is more portable than minix.  What? I hear you
>say.  It's true - but not in the sense that ast means: I made linux as
>conformant to standards as I knew how (without having any POSIX standard
>in front of me).  Porting things to linux is generally /much/ easier
>than porting them to minix.
MINIX was designed before POSIX, and is now being (slowly) POSIXized as 
everyone who follows this newsgroup knows.  Everyone agrees that user-level 
standards are a good idea.  As an aside, I congratulate you for being able 
to write a POSIX-conformant system without having the POSIX standard in front 
of you. I find it difficult enough after studying the standard at great length.

My point is that writing a new operating system that is closely tied to any
particular piece of hardware, especially a weird one like the Intel line,
is basically wrong.  An OS itself should be easily portable to new hardware
platforms.  When OS/360 was written in assembler for the IBM 360
25 years ago, they probably could be excused.  When MS-DOS was written
specifically for the 8088 ten years ago, this was less than brilliant, as
IBM and Microsoft now only too painfully realize. Writing a new OS only for the
386 in 1991 gets you your second 'F' for this term.  But if you do real well
on the final exam, you can still pass the course.


Prof. Andrew S. Tanenbaum (ast@cs.vu.nl)

0, unseen,,
*** EOOH ***
From: feustel@netcom.COM (David Feustel)
Newsgroups: comp.os.minix
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 18:57:28 GMT
Organization: DAFCO - An OS/2 Oasis

ast@cs.vu.nl (Andy Tanenbaum) writes:


>I still maintain the point that designing a monolithic kernel in 1991 is
>a fundamental error.  Be thankful you are not my student.  You would not
>get a high grade for such a design :-)

That's ok. Einstein got lousy grades in math and physics.
-- 
David Feustel N9MYI, 1930 Curdes Ave, Fort Wayne, IN 46805. (219)482-9631
feustel@netcom.com 
=== NBC News: GE's Advertising And Public Relations Agency ===
  
     
      
       
 

------------------------------

From: clark@YingTongDiddleIPo.ee.wits.ac.za (Alan Robert Clark)
Subject: Re: Slackware needs a shadow package!
Date: 26 Jan 1994 18:44:06 GMT

John F. Haugh II (jfh@rpp386) wrote:
{deleted}
: All you have to do to distribute Shadow with your product is license the
: code from me.  Since I've never heard of you, you clearly haven't bothered
: trying.  Don't you think it is rather rude and presumptuous of you to sell
: someone elses property without their permission?  As I've told everyone
: else who has approached me to license the code, for a rather reasonable
: fee you get

:       * Internal documentation
:       * Bug fixes from other platforms
:       * Real support from me, not some hacker in Finland
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
Was this sort of comment really necessary?

I am a happy user of both Linux and Shadow (both obtained free). As aa
community, we do *NOT* need to deprecate one another's efforts. I
certainly have had *Real* support for my Linux system.

(I haave no problem with your other statements -- if you wish to charge,
go ahead, Shadow is a good package) 

: Seems like you want to cut off your nose to spite your face.
: -- 
: John F. Haugh II  [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
: Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ]   @'s: jfh@rpp386.cactus.org
: The P.C. Movement killed the 1st Amendment, the Brady Bill the 2nd, the WOsD
: got the 4th and 5th, political activism the 9th and 10th.  Not much left, eh?

--
Alan Robert Clark, Pr Eng     Computational Electromagnetics
Dept Elec Eng                         Wits University
P.O.Wits                   ``Bugs are later known as features''
2050 South Africa                 Ps 110:11; Ps 37/150
Fax (+27 11)403-1929       clark@YingTongDiddleIPo.ee.wits.ac.za(Pref)
Tel (+27 11)716-5404(24hr)      or clark@odie.ee.wits.ac.za
     **Linux 0.99pl13 - the choice of a GNU generation.**

------------------------------

From: horne@leader.pfc.mit.edu
Subject: RE: Another kind of DOSEMU
Date: 27 JAN 94 15:41:11 GMT

In a previous article, hta@uninett.no (Harald T. Alvestrand) 
asks about ways to make the linux/dosemu interface less clumsy -- 

< lines deleted --> 
>What I would like is something like a single command-line interface,
>more like the WINE idea than the current dosemu:
>dosemu --configuration wpenvironment d:/wp51/wp c:/autoexec.bat
>where DOS would be booted, the application started, and on exit,
>DOSEMU would terminate - all with a minimum of hassle.
>It would be possible to hack something like this (I think) if:
> 
>- the configuration files can be given at dosemu startup, rather than
>  found at a fixed location
>- the command line of dosemu was available within dosemu's
>  autoexec.bat
>- something like "all output from booting to debug file or /dev/null"
>  existed
>- booting was FAST.
> 
>I suspect the last one might be a slightly sticky point....
< lines deleted --> 
>-- 
>                   Harald Tveit Alvestrand
>                Harald.T.Alvestrand@uninett.no
>      G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
>                      +47 73 59 70 94
>My son's name is Torbjxrn. The letter between "j" and "r" is o with a slash.

        I've needed something like this for a "real world" application.
I am developing code for an Intel 8044 microprocessor (8051 + bitbus)
using a dos development package from Intel (cross-assembler, linker, etc).

I set up an autoexec.bat which looked in a specific place for source
an ran the compiler and linker.  This almost worked but was slow and clumsy.
(The assembler had difficulty writing it's work file when running from
a redirected disk; I ran it with default set to b:, the 3 1/2 " drive).
I gave up on this (because I'm not qualified to hack dosemu, and it's not what I'm paid for)
and instead used a 286 we had laying around here, connected via kermit, to do
the builds.  (Works fine -- I type "kermit <script> to linux, and it communicates
with ckermit on the 286 (in server mode); ship a qqq.bat file over and say 
"rem host qqq,bat" to build the application.)

I'm playing around on my linux machine at home (on my time, not MIT's) to try
to get the application to run, but it's not a high priority.

If we could get dosemu to run in a "server" type of mode, with a mechanism
for sending commands from the linux environment into the dos command line 
without having to physically type at the DOS> prompt, then the reboot speed becomes
not an issue.   We should perhaps move this discussion to the DOS mail channel.












------------------------------

From: barkers@cuug.ab.ca (Scott Barker)
Subject: Anybody using a UPS?
Date: Wed, 26 Jan 1994 16:49:39 GMT

I was just wondering how many people out there are using a UPS for their Linux
system. I have one myself, but after upgrading my system numerous times, it is
no longer sufficient. So far, I haven't really noticed a need for it, and I'm
trying to decide whether to buy a bigger one, or just not bother with one at
all. For the most part, I've noticed that Linux recovers pretty well from
crashes, and we don't get very many power failures at all (about once every
six months).

What's the popular opinion? How many people have or feel a need for a UPS?

--
Scott Barker
barkers@cuug.ab.ca

"Remember, wherever you go, there you are."
   - Peter Weller, The Adventures of Buckaroo Banzai Across the 8th Dimension!

------------------------------

From: beyer@alkymi.unit.no (Paal Beyer)
Subject: Re: Solitaire ?
Date: 27 Jan 1994 12:07:09 GMT

The wine Windows emulator now runs solitare (the windows program). It doesn't
run much else and the performance isn't too great. But I think things will
change. Check out fa.linux.wabi.


-- 
==========================================================================================         

    _/_/_/    _/_/_/  _/  _/  _/_/_/  _/_/_/
   _/    _/  _/      _/  _/  _/      _/    _/
  _/_/_/    _/_/_/  _/_/_/  _/_/_/  _/_/_/
 _/    _/  _/        _/    _/      _/  _/
_/_/_/    _/_/_/    _/    _/_/_/  _/    _/ @lise.unit.no

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.misc) via:

    Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Misc Digest
******************************
