Bruce Evans' opus
Andy Tanenbaum
Bruce Evans has clearly done a great deal of high quality work in his recent
giant posting and I am sure many people are interested in it. Furthermore,
I hate to be a party pooper, but...
According to P-H's sales figures, the PC version of MINIX is still outselling
the AT version by a wide margin. This means that there are a lot of 8088s
still out there. Consequently, I am going to base V2.x on 1.4a, not on Bruce's
version. I just don't want all that extra complexity on the 8088 (remember,
the goal was a teaching system).
This means that if you convert to Bruce's system now, you may have trouble
converting to 2.x (POSIX-based) later. It is clearly up to you which way you
go, but at least you should be aware that there is a fork in the road here.
The long term plan for MINIX is to wait until not only the 8088, but the 286
has also vanished, and make MINIX 3.x (probably in 4 or 5 years) entirely
a 386/486/585/686/786 based system, assuming these are all architecturally
compatible. The 286's dwarf segments are a real nuisance, and hardly
compatible with the Atari, Amiga, and other versions of MINIX in progress,
whereas on the 386 one can use a single 32-bit segment (Motorola mode) and
implement that fairly cleanly.
Andy Tanenbaum (a...@cs.vu.nl)
Michael Winser
>still out there. Consequently, I am going to base V2.x on 1.4a, not on Bruce's
>version. I just don't want all that extra complexity on the 8088 (remember,
>the goal was a teaching system).
Is this goal still reasonable? I would guess that most of the buyers
are using MINIX to learn about UN*X (but not necessarily from an os design
point of view).
>This means that if you convert to Bruce's system now, you may have trouble
>converting to 2.x (POSIX-based) later. It is clearly up to you which way you
>go, but at least you should be aware that there is a fork in the road here.
^^^^:-)
>The long term plan for MINIX is to wait until not only the 8088, but the 286
>has also vanished, and make MINIX 3.x (probably in 4 or 5 years) entirely
>a 386/486/585/686/786 based system, assuming these are all architecturally
>compatible. The 286's dwarf segments are a real nuisance, and hardly
>compatible with the Atari, Amiga, and other versions of MINIX in progress,
>whereas on the 386 one can use a single 32-bit segment (Motorola mode) and
>implement that fairly cleanly.
Four or five years is a long time to wait for a MINIX that can effectively
use the 386. By that time we may all have moved to i860's or i960's!
I don't want to start yet another intel vs. motorola discussion here, but
to implement MINIX in a single 32-bit segment on the 386 is to ignore much
of the parts capabilities. The 386/486 segments and hardware tasks are
ideal for MINIX. All the messy fork blitting that the Atari has to do is
because there is no mmu.
Michael
P.S.
Isn't it nice to know that the x86 line must stop with the 686. The 786
is/was a specialised graphics part (not very flexible, but pretty cool
nonetheless).
--
/\ no guts michael winser
\/ no glory microsoft corp. (206) 882-8080, mich...@microsoft.uucp
Frank Wortner
I can see the headlines now:
Open Minix Foundation Formed
Minix International Announced
:-)
James da Silva
> outselling the AT version by a wide margin. This means that there are a
> lot of 8088s still out there. Consequently, I am going to base V2.x on
> 1.4a, not on Bruce's version. I just don't want all that extra complexity
> on the 8088 (remember, the goal was a teaching system).
While I personally plan on running Bruce's version, I agree with Dr.
Tanenbaum. `Teaching Minix' as shipped from Prentice Hall doesn't need to
have all the bells and whistles. It also doesn't need to be POSIX compatible
where such compatibility would complicate Minix. Keep it simple!
However, I urge Dr. Tanenbaum to look very closely at Bruce's changes. Many
are bug fixes and improvements that have nothing to do with protected mode.
It would be silly to ignore so many fixes. Bruce documented every change he
made to each source file in the CHANGES file present in every directory; I
would say that this is probably the best-documented Minix update I've seen.
Much better than the 1.2 and 1.3 updates.
> This means that if you convert to Bruce's system now, you may have
> trouble converting to 2.x (POSIX-based) later. It is clearly up to you
> which way you go, but at least you should be aware that there is a fork
> in the road here.
I think that the people of the net will help here as they have in the past.
I did an upgrade kit for Minix 1.2, Vince Broman did one for 1.2 and one for
1.3d. There's no reason to think that others will not do the same in the
future.
This should go without saying, but those people serious about keeping track
of changes that come over the net while making their own mods should be using
a revision control system. I use the SVC system posted here a while back;
there has also been a port of RCS to Minix. I've got Minix 1.1, 1.2, 1.3d,
1.4a and Evans' patches all online and easily accessible.
Those with 386's or better will most likely borrow more and more from the
GNU project; what Prentice Hall does with Minix five years from now just
doesn't seem relevent to me, for OS hacking or `learning Unix cheaply'.
There will still be a need for a teaching OS, and I trust that Dr.
Tanenbaum will provide an excellent one.
> Andy Tanenbaum (a...@cs.vu.nl)
Jaime
...........................................................................
: domain: j...@mimsy.umd.edu James da Silva
: path: uunet!mimsy!jds
bill beebe
>giant posting and I am sure many people are interested in it. Furthermore,
>I hate to be a party pooper, but...
>
>According to P-H's sales figures, the PC version of MINIX is still outselling
>the AT version by a wide margin. This means that there are a lot of 8088s
>still out there. Consequently, I am going to base V2.x on 1.4a, not on Bruce's
>This means that if you convert to Bruce's system now, you may have trouble
>converting to 2.x (POSIX-based) later. It is clearly up to you which way you
>go, but at least you should be aware that there is a fork in the road here.
>
>The long term plan for MINIX is to wait until not only the 8088, but the 286
>has also vanished, and make MINIX 3.x (probably in 4 or 5 years) entirely
>a 386/486/585/686/786 based system, assuming these are all architecturally
I hate to be a party pooper too, but I find Bruce Evan's postings what PC
Minix needs to move into the larger world of the 386. I find it interesting
you base your figures on P-H's sales figures, without qualifying who is
really buying Minix. It would be interesting to see what systems at major
universities are running Minix. I have found that the majority of systems
in U.S. universities are donated ATs, with the switch to 386 AT architectured
machines. And we can roundly curse the "dwarf segments" on the 80286 under
protected mode, but there is something to be said about 80286 PM code; it
run's with little or no modification on 80386 machines. One other thing
you need to think about, Mr. Tanenbaum, and I'll draw a picture to help
illustrate my point.
+-------------------+---+---+---+---+----------------+
| BASE 31...24 |23 |22 |21 |20 | LIMIT 19...16 |
| |G |X |O |AVL| |
+-------------------+---+---+---+---+----------------+
It's a crude picture of the upper 16 bits of the 80386 descriptor quad
word. The high 16 bits were zero in the 80286, but in the 80386 we have
four more bits in the limit field and eight more in the base. If we lave
the base alone, the segment limit is now 1 meg, not 64 K. Using the current
AT Minix architecture, that means programs can span 2 megs; 1 meg for code
and 1 meg for data. It also means that segments have a one byte granularity.
Using the base and setting the granularity bit, we can have segment limits
up to 4 gig with a granularity of 4K bytes. I find your reasoning why
Bruce Evan's work will cause a split to be flawed and technically
imcompetent. I support Evan's work and will do whatever I can to add
to the existing body of PM Minix code. As a matter of perspective one
of our local Minix group here in Orlando, Florida ,Jim Smith, has stated
that he had the least number of problems and glitches patching his version
of Minix with Evan's posting. It has been one of the easiest, if not
the easiest. And Jim has faithfully installed every major posting that
has appeared in the conference. Evan's work was merged with Minix 1.3
purchased from P-H, and is running on a 20 MHz 80386 machine with
4 megs of memory, an Adaptec RLL controller, and an ST277. The 80386
AT bios drive tables were patched so that Minix boots from the RLL drive
with the standard AT wini code. The Adaptec is register compatible with the
WD standard.
I'm sorry for the tone of my message, but Minix is far larger than you
apparently realize. I would strongly recommend you do more research
and deeper thinking about Minix's future path.
James da Silva
> ... One other thing
>you need to think about, Mr. Tanenbaum, and I'll draw a picture to help
>illustrate my point.
>
> +-------------------+---+---+---+---+----------------+
> | BASE 31...24 |23 |22 |21 |20 | LIMIT 19...16 |
> | |G |X |O |AVL| |
> +-------------------+---+---+---+---+----------------+
>
>It's a crude picture of the upper 16 bits of the 80386 descriptor quad
>word. The high 16 bits were zero in the 80286, but in the 80386 we have
>four more bits in the limit field and eight more in the base. If we lave
>the base alone, the segment limit is now 1 meg, not 64 K. Using the current
>AT Minix architecture, that means programs can span 2 megs; 1 meg for code
>and 1 meg for data. It also means that segments have a one byte granularity.
>Using the base and setting the granularity bit, we can have segment limits
>up to 4 gig with a granularity of 4K bytes. I find your reasoning why
>Bruce Evan's work will cause a split to be flawed and technically
>imcompetent.
Bill,
I must be even more imcompetent (sic) than Dr. Tanenbaum, as I don't see
your point at all. Could you draw me another picture?
Seriously, the fact is that it is tricky for a 32-bit kernel to support
16-bit processes. And out of the question for a 16-bit kernel to support
32-bit processes. So what choice do we have? The 16-bit and 32-bit
kernels have to be different binaries, at least. The sources can be
largely the same, if you are very careful. But not entirely the same.
So, should the PC Minixers have to carry around the extra complexity
required to support protected mode, in the base Minix release? I don't
think so. I think this was all Dr. Tanenbaum was trying to say.
Then, should we cripple the 32-bit kernel to increase compatibility with
the PC version of Minix? I hope not!
Should Prentice Hall market ANOTHER version of Minix for the protected
mode? Maybe, but who cares? How would it help you or me?
Now, does this mean that we won't have 32 bit Minix for our 386's until
Prentice Hall and AST decide to do it? No, of course not.
Nit Pick: Bit 21 of the descriptor is not `O', it is `0', as in Undefined.
Charles Hedrick
of compromise here? I'm in a situation that I think is shared by many
of the readers here. I'm a hacker. I'd like an OS for my home
machine that I have source to. I'd also like an OS that I can
recommend for students to put on their PC's. At the moment Minix is
really the only alternative. Gnu OS is the major alternative, but it
doesn't exist yet. Even when it does, chances are most of the people
on this list won't be able to afford machines that run it, since the
Gnu project in general seems to like large software that requires
large machines. Minix does very well in using limited resources.
Just what the home hacker community needs.
But it's possible to have too much of a good thing. 64K programs
carry "small is beautiful" too far. I've collected a lot of software
for my PC (which I currently use under Microport System V). Almost
none of this will run in 64K. There's a middle ground between Gnu
Emacs and ed. That middle ground is occupied by a large amount of
stuff that is posted to the net by hackers for PC's, e.g. various
microemacses, KA9Q TCP/IP, sc, kermit. This is all reasonably
small-scale stuff. It mostly runs fine under MS-DOS. But almost none
of it will run under Minix. I had to remove all the help strings from
kermit to bring it up under Minix, which is an abomination.
The question is what Minix is supposed to be. OK, originally it was
intended as an example for OS courses. I'm sure it still is fine for
that. But I'm much more concerned with producing students who know
how to use OS's than how to write them. And currently they can't
really use Minix. So they end up running MS/DOS, and learning nothing
at all about how an OS should really support their programming.
Can't we do something to lift the curse of 64K from Minix sooner than
4 years from now? Yes, I agree that the 286 is an abortion. The
large model is an obscenity. But I'd much rather see my students
using a slightly scatalogical Minix than MS/DOS. Bruce's 286 patches
are a useful starting point. But what we need most is a large-model
compiler, and the ability to run large-model programs even on the
8088. I might even be willing to work on it if I saw some signs that
you'd accept the results.
Guy Helmer
>>
>>Bruce Evans has clearly done a great deal of high quality work in his recent
>>giant posting and I am sure many people are interested in it. Furthermore,
>>I hate to be a party pooper, but...
>>
>>According to P-H's sales figures, the PC version of MINIX is still outselling
>>the AT version by a wide margin. This means that there are a lot of 8088s
>>still out there. Consequently, I am going to base V2.x on 1.4a, not on
>Bruce's
>[some stuff deleted]
>
>Minix needs to move into the larger world of the 386. I find it interesting
>you base your figures on P-H's sales figures, without qualifying who is
>really buying Minix. It would be interesting to see what systems at major
>universities are running Minix. I have found that the majority of systems
>in U.S. universities are donated ATs, with the switch to 386 AT architectured
>machines.
As a recent graduate with a B.S., I know for a fact that at least in all the
schools I've seen, AT machines are rare. A small Minix based on the 8088
is necessary if undergrad classes are to be taught based on Minix.
> I find your reasoning why
>Bruce Evan's work will cause a split to be flawed and technically
>imcompetent. I support Evan's work and will do whatever I can to add
>to the existing body of PM Minix code. As a matter of perspective one
>of our local Minix group here in Orlando, Florida ,Jim Smith, has stated
>that he had the least number of problems and glitches patching his version
>of Minix with Evan's posting. It has been one of the easiest, if not
>the easiest.
I agree that Bruce's improvements in interrupt handling are useful and should
be included in Dr. Tannenbaum's Minix. I do not believe that Dr. Tannenbaum
should be asked to include protected mode support in Minix. Real Minix is
a teaching operating system. What Bruce's changes do is create a Minix
that is not longer the small teaching system but a step towards a Minix that
could be used in place of commercially marketed un*x.
>I'm sorry for the tone of my message, but Minix is far larger than you
>apparently realize. I would strongly recommend you do more research
>and deeper thinking about Minix's future path.
I believe that Dr. Tannenbaum has Minix on the correct path. The network
is presently creating a new version of Minix, one that the network will
have to support by itself.
-- Guy Helmer
Opinions are mine, all mine.
John C. Archambeau
it in. I commend author the 286 protect mode upgrade kit and its people like
that that make Minix more than what it was originally intended for. I have no
qualms about Dr. Tanenbaum keeping Minix the way it is for educational
purposes, but for those of us that want to make Minix more than an educational
tool and experience with operating systems, we're going to have to pitch in to
make it a reality. Rather than complaining about what Minix lacks, why not
put your head together with people on here on how to make it do what you want?
I have kicked around the idea of how to get beyond the 64K code/64K data
segment problem and have talked to others about how to get around this, and
here's what I have come up with (with help from others). More memory can be
accomplished by the following;
1. Shared libraries
2. swapping code segments
3. full swapping
4. virtual memory
Each of these has its fruits and varying levels of difficulty to implement.
But needless to say that if you want to expand Minix to get beyond its current
limitation of programs, you're going to have to put it in. And putting our
heads together is the whole idea why these Usenet conferences exist in the
first place. I am more than happy to discuss with anybody (as time permits)
on ways to improve Minix. But one thing I must say, don't expect Dr.
Tanenbaum to do it, he's most likely busy enough as an instructor and can't
maintain a wish list of what you want in Minix. If you want something in
Minix (as I've been continually stressing in this article), YOU are going to
have to make an effort to add it yourself or with help from those of us here.
I see the reasoning behind why Minix is designed the way it is and have no
intention of defeating that purpose.
One last thing that I would like to add here, I would like to additionally
commend those who have made contributions to Minix, both Dr. Tanenbaum and
those who have written bug fixes, improvements, and/or ports to other
machines.
JCA
UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
ARPA: crash!pnet01!j...@nosc.mil
INET: j...@pnet01.cts.com
Art Dederick
>I believe that Dr. Tannenbaum has Minix on the correct path. The network
>is presently creating a new version of Minix, one that the network will
>have to support by itself.
And I thought we were getting away from multiple versions of the same
OS. How naive I was. I see the AT&T/BSD wars beginning all over again.
Flames to /dev/null, intelligent comments to felix!art.
Art D.
Bill Beebe
>I must be even more imcompetent (sic) than Dr. Tanenbaum, as I don't see
>your point at all. Could you draw me another picture?
>
>Seriously, the fact is that it is tricky for a 32-bit kernel to support
>16-bit processes. And out of the question for a 16-bit kernel to support
>32-bit processes. So what choice do we have? The 16-bit and 32-bit
[stuff deleted]
>Nit Pick: Bit 21 of the descriptor is not `O', it is `0', as in Undefined.
>
>Jaime
No, the incompetent boob is me, the guy who left his brain on idle while his
hands went wild on the keyboard. If I had thought about the the 16- vs
32-bit kernel problems I would have killed the comment, or at least put more
thought into it. The points I was trying to make are:
1) once you have 80286 protected mode, you can move up to the 80386 and
use the code as-is, assuming that you have the same video, serial, and
mass storage devices on an AT architecture machine. You will have to
remain in 16-bit mode, and migration to 32-bit will be no trivial matter.
But it is not impossible, and is in fact (at least to me) an inviting
challenge.
2) it would be nice to have a teaching 32-bit Minix. Why can't we have some
say-so in the process? Bruce Evan's work is so good, and Dr. Tanenbaum
seemed to slam the door on that work and all it promises. I became very
angry at the apparent tone of the message.
As for '0' vs 'O', I'm suprised I can type at all, considering my
coke-bottle bottom glasses. I'll try to keep my typos to a minimum, or at
least not make them in overly obvious areas.
Paul Allen
protected mode diffs and feel I must comment.
We seem to be standing at a crossroads. We can choose either to
maintain the IBM version of Minix as a toy operating system, or
we can evolve it to support current hardware. The Atari version
of Minix was apparently 'real' at the outset, judging by the
amount of current Unix software that runs on it. The IBM version
is a toy that supports current software either with great difficulty
or not at all.
I fail to see the value in making the current IBM version of
Minix POSIX-compliant, when much of the available POSIX-
compatible code out there won't even compile. The ideal of
a small, simple operating system for teaching purposes is
adequately served by the 1.3 version of PC Minix. The real
value of POSIX compatibility will come when there is a 386
version of Minix that can take advantage of it. An adequate
stop along the way would be a 286 PM version with a large-
model compiler.
In my view, the next version of PC Minix should be a 'real'
operating system, capable of supporting most current software.
While there is certainly a place for a small Minix that fits
on antiquated hardware, the strength and vitality of an
operating system depend upon the efforts of people like Bruce
Evans who are pushing the limits. If we set the limits
artificially tight, we will choke off future innovation.
I sincerely hope that Dr. Tanenbaum will reconsider his
decision not to adopt Bruce's version.
Paul Allen
--
------------------------------------------------------------------------
Paul L. Allen | pal...@atc.boeing.com
Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
marty
and well-documented.
I feel a protected mode implementation of Minix is a most useful thing for
a teaching tool. I regularly use Ms/Dos and Unix machines -- software
development on Ms/Dos generally requires constant booting (I wrote a TSR to
at least break out of an infinite loop).
In college, my OS course dealt with aspects of protection between processes
and stressed the importance of "the system shouldn't crash". Minix ignores
these protection issues. I kinda get annoyed when computers crash -- I
suppose developers trained on Minix may well build the next generation of
Ms/Dos machines (god forbid). I think Andy's desire to ignore protection
issues may be expedient -- how about advanced Minix?
What I would like to see is a graceful way to add more sophisticated
features (i.e. memory protection, swapping, etc) in a configurable manner.
This way Minix can serve as both a teaching tool and a useful system.
One of the problems with Pascal (at least the way I understand it) is it
was never intended to accomplish anything in a production environment -- it
was a teaching tool. So pascal vendors impelemented various extension to
the language (this was the case 8 years ago when I learned C and Pascal).
It is not an easy task to develop an operating system to support multiple
processors with various hardware features (i.e. how context switching takes
place, memory/no memory protection, etc). But I think with some careful
redesign Minix can serve as a teaching tool (in the present configuration)
and a more useful, more powerful system supporting multiple users with
memory protection on 286/386 machines.
One of the problems is the copyrighted status of the source -- the idea of
400k of patches doesn't appeal to me, and the multiple levels of patches
seem to be a pain. If a group of us want to take a protected mode
activity off-line, I'd like to be able to pick up a complete kernel. I've
never been good at applying patches. Also since no source control system
is used in Minix, it's always been hard for me to know exactly what I got.
I'm pretty impressed by Minix. GNUos (if it ever appears) won't have a
chance of ever running on PC XT clones. Minix seems like a seems which has
a path from 8086/80286/80386 in a reasonable way if changes are made. A
few minor extensions would make Minix far more usable to me:
1) support TCP/IP (I'm not going to ask for XNS) -- i.e. ftp/telnet would
give it real world usefulness. I'd be happy to discuss how to do this with
anyone else interested.
2) support 386 protected mode with 32 bit addresses (mainly to run gnu C).
3) Multiple sessions off the console (I implemented a buggy version of
this -- someone else did also I believe. Did it ever make it into the
release?)
4) A larger buffer cache (I don't think 40k can be of much use).
5) Shared text and a sticky bit (this would be most useful addition)
A few major problems I found with Minix which I think limit its usefulness:
1) The C compiler (sorry, I've never been able to accomplish much with it
when I port code). And it's slow. And the benchmarks I've run indicate
it's code generation wasn't competive. (does current minix support split
I&D?) I've did all my Minix development on Ms/Dos using Aztec C.
2) Lack of a clean way to manage more sophisticated memory models (I had to
make major changes to begin to allow this but never got there). I find a
memory model with 64k data, 64k text, 64k stack and N 64k malloced segments
to be most useful (very few applications need > 64k code). It would be
nice if instead of the T, D and S model, a variable number of segments were
supported.
I think it would be a good idea if Prentice-Hall and ast free'd up the
source code to the operating system so people could easily let other
people look at new kernels. I would gladly share my 80286 protected mode
stuff I could distribute it intact -- at the time I was doing it I had no
space on my hard disk to leave a distribution. It seems this would not
jeopardize PH sales since booting a system without the source code to the
operating system is quite a formidable task.
I haven't done a Minix work in a year now. Hopefully I'll have a chance
soon to catch up, look at my work, look at Bruce's work, look at Andy's
latest release. Now that I finally have a sun386i I should be able to run
DOS, Minix and Unix all on the same machine and generate binaries with
various compilers. I would like to see a way to release 88 Minix, 286
Minix and 386 Minix off one distribution source (but not necessarily one
binary).
marty
ARPA: leisne...@xerox.com
GV: leisner.henr
NS: martin leisner:wbst139:xerox
UUCP: hplabs!arisia!leisner
Henry Spencer
>... We can choose either to
>maintain the IBM version of Minix as a toy operating system, or
>we can evolve it to support current hardware. The Atari version
Hey, toy operating systems for toy hardware, real ones for real hardware. :-)
Anything with a cpu whose number ends in "86" is a toy. :-) :-)
--
You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology
but it's not worth it. -Collyer| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Paul Muller
Firstly I apoligise to anyone offended by the summary line....
I think it is rather inconsiderate to talk about Minix as if it was
collectively owned by the netlanders (although much of it would not exist
without them and they all deserve credit), Andrew and PH will differ on
that point no-doubt about it, though as ast so wonderfully put it, there
would appear to be a "fork" in the road after the work of Bruce hit the net.
Minix first and foremost is the poor student's teaching OS. It serves its
purpose above and beyond the call of duty, and that is the point. If you
were a student you wouldn't fancy wading through all those #ifdefs for two
days just to find you made a mistake early on in the code and that's why
none of what the lecturer is saying fits together. I am a student and find
nothing more annoying than conditional compilation, it ruins your day and
often clouds the purpose of the code.
I am not going to propose anything radical in regards as to what should be
done, I will just try and put together some ideas that have floated across
the battle table (and try to foresee new ones).
The first idea is to KISS. Sounds nice huh? ;-) Seriously, the first
thing is to get a standard piece of PC code that will form the kernal (in
the larger sense) of the Minix book. Much as it is now. Students can still
boot up on the two floppy PCs they have at home and happily hand in work
for the teacher with the knowledge that comes from looking at the guts of
an OS. 1.4a contains more or less than what is needed to do this. POSIX
compliance is probably important from the point of view of teaching the
ideas in a real world sense (we can't always patch the C compiler!).
The second is the 'upmarket' Minix that everyone seems to think is so
important, why? Most people who got into Minix for reasons other than formal
education just wanted to 'hack around', you were happy with Minix then, why
not now, the old case of "give an inch take a mile" or more "too much of a]
good thing" :-) The idea then is to produce a bunch of either, patches or
modules (FS,MM,xx_wini,etc) that cater for individual tastes and needs.
People can then make up a Minix system to suit them, you could have a file
in /etc that would list all options loaded or have an internal table hard
coded into Minix that would tell applications if they could use certain
features or not at compile (or patch) time.
If people are so into the idea of 'real life' Unix, then checkout AT&T, SCO,
etc offerings. They produce different BINARIES for each processor they
support, most proabably different sources as well. Xenix (tm) 286 won't
run 386 code, so why all the hoopla about Minix compatibility? What is
needed is some form of arbitration committee to decide what goes in the
upmarket version. This should not just rest on ast's shoulders, I prefer
he gets more time to write his great books! :-)
The whole idea is asking for trouble, but there are sooooo many things that
poeple in the Minix user community want/need/loath/despise in minix that can be
done on paper but fall done trying to fit in with the 'small is beutiful' model
, Virtual memory, windowing, memory model work, swapping and networking just
to name a few.
I like what Bruce and others are doing for Minix, but the seminal idea
of ast's based itself on V7, "because of its simplicity and elegance" and this
is foremost in my mind when I hear talk about changing the listing that will
appear in the back of the second revision of The Book.
What do others feel? The ST was a step in another direction, what do users
of ST AND PC (that is people who have used (are using) both) think about
the differences in the code/machine?
paul
Ken Stailey
>In article <11...@bcsaic.UUCP> pa...@bcsaic.UUCP (Paul Allen) writes:
>>... We can choose either to
>>maintain the IBM version of Minix as a toy operating system, or
>>we can evolve it to support current hardware. The Atari version
>>of Minix was apparently 'real' at the outset...
>
>Hey, toy operating systems for toy hardware, real ones for real hardware. :-)
>Anything with a cpu whose number ends in "86" is a toy. :-) :-)
This was true up until the 386.
Q: What does the 386 call a 32-bit address space?
A: a segment. :-)
INET sta...@iris613.gsfc.nasa.gov
UUCP {sundc ames}!dftsrv!iris613!stailey
Jason Coughlin
> We seem to be standing at a crossroads. We can choose either to
> maintain the IBM version of Minix as a toy operating system, or
> we can evolve it to support current hardware. The Atari version
Pardon me this is NOT a flame, but "we" seem to be saying "WE" a
little too often. I think we should all take a small step back and
realize that Minix is Dr. Tanenbaums baby - NOT ours. I realize we've
all been "guinea pigs" with Minix and we all love it, but still - it's
his creation, not ours.
What's your vote Dr. Tanenbaum?
> ... The Atari version
> of Minix was apparently 'real' at the outset, judging by the
> amount of current Unix software that runs on it. The IBM version
> is a toy that supports current software either with great difficulty
> or not at all.
But the Atari ST isn't exactly the ideal hardware either :-).
>
> I sincerely hope that Dr. Tanenbaum will reconsider his
> decision not to adopt Bruce's version.
(Me too :-)
--
Jason Coughlin
( j...@sun.soe.clarkson.edu , j...@clutx.BITNET )
John C. Archambeau
brain damaged, not a toy really, just a labotomized chip. The 8086 isn't bad
with LIM EMS 4.0. You may regard the 80x86 family as a toy, and that is your
opinion, but just remember, there are those of us who can and have worked out
the brain damaged hardware. Even the best Unix boxes have their problems, the
Unisys 7000 is a classic example with its brain damaged floating point
instructions. So before you go harping on our 'toys', take a good look at
your own hardware first. I have yet to see anything that is perfect when it
comes to hardware.
JCA
/*--------------------------------------------------------------------------*
* That's not an operating system, this is an operating system!
*--------------------------------------------------------------------------*
* UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
* APRA: crash!pnet01!j...@nosc.mil
* INET: j...@pnet01.cts.com
*--------------------------------------------------------------------------*/
#include <disclaimer.h>
Warren Toomey
[ about the future design of Minix, and it's direction ]
Minix definitely is split between two camps of users:
a) Those using it to learn about O/S design
b) Those wanting a cheap, good, O/S with source code.
For the former group, the source needs to be simple, concise, and well
documented. For the latter, anything that's considered `useful'.
I believe that Minix 1.2 & Minix 1.3 very adequately satisfy the demands
of the academic users. For them, any increase in the size & complexity of
Minix would do more harm than good. The IBM-XT here also helps as it is
simple, and cheap for academic departments to buy.
However, for the latter group, much more can be done with Minix to get it
as (current) Unix-compatible as possible. This really means leaving the
IBM-XT behind, and moving on to more powerful machines, with larger available
memories etc. The port of Minix to the '286, and the Atari ST port are the
first steps in this direction.
Therefore, I propose that Minix be broken into two parts. One, a simple
static version of Minix, such as 1.3, to be used to teach about
operating systems, and based on the XT or ST. The other, a continually
evolving system, to keep everybody else happy. This should be ported to
many machines, like the ST, '286 & '386 etc, and hopefully should mean
that all the machine dependencies will reside in only a few files in the
kernel/mm/fs/etc.
> Minix first and foremost is the poor student's teaching OS. It serves its
> purpose above and beyond the call of duty, and that is the point.
This is the `academic' Minix.
> POSIX compliance is probably important from the point of view of teaching
> ideas in a real world sense (we can't always patch the C compiler!).
POSIX compatibility should apply to both versions.
> The second is the 'upmarket' Minix that everyone seems to think is so
> important, why? Most people who got into Minix for reasons other than formal
> education just wanted to 'hack around'.
> If people are so into the idea of 'real life' Unix, then checkout AT&T, SCO,
> etc offerings. They produce different BINARIES for each processor ...
Not only did I buy Minix to play with, but also to have a version
of Unix with almost full source code, and to be a part of comp.os.minix,
where each of us can add to Minix's source code pool, and also help
with design ideas, bug reports etc. This is difficult (nay, impossible)
with real Unix.
At the present point in time, Minix only vaguely resembles current
flavours of Unix, and I would really like to see it become as compatible
with both the ATT and Berkely flavours of Unix. This has already started
with sources such as termcap(3), and the memcpy,bcopy variants. Both
flavours of Unix overlap in many areas, and also have extensions which exists
in only one flavour. If Minix could be a fusion of both flavours, and
keep compatibility with them AND POSIX ( & SVID ?), then we would have
an O/S which would be the best of both worlds AND with source.
> I like what Bruce and others are doing for Minix, but the seminal idea
> of ast's based itself on V7, "because of its simplicity and elegance" and this
> is foremost in my mind when I hear talk about changing the listing that will
> appear in the back of the second revision of The Book.
I agree. The O/S book and `academic' Minix should be kept exactly as
is to make teaching O/S as easy as possible.
However, a more powerful version of Minix should be allowed to develop too.
> What is
> needed is some form of arbitration committee to decide what goes in the
> upmarket version. This should not just rest on ast's shoulders, I prefer
> he gets more time to write his great books! :-)
Yes! Andy, 'though, being the founder of Minix, should have the
final say on the future of Minix. But a committee of some sorts would
take a lot of the load from him.
BTW, speaking of Minix design, what about job control and the extra
Berkely signals for Minix. This will allow shells etc, to have better
control over child processes, and won't be incompatible with the
Version 7 & SysV signals - well, perhaps a few! Any ideas, comments?
Warren Toomey
University of New England
Australia.
(wto...@gara.une.oz)
Rob ten Kroode
>BTW, speaking of Minix design, what about job control and the extra
>Berkely signals for Minix. This will allow shells etc, to have better
>control over child processes, and won't be incompatible with the
>Version 7 & SysV signals - well, perhaps a few! Any ideas, comments?
When Minix was just out I added job control and all necessary signals to Minix.
I had only one problem: testing it :-) I needed some sort of shell with
job control. I had no such (public domain) beast that was small enough to
run under minix, and I had no time to write one.
I asked Andy some advise, and he told me that he didn't like the idea of
job control in Minix. In fact, he isn't too fond of any Berkeleyism (sp?)
at all :-( I guess that these kinds of changes/additions shouldn't appear in
the vanilla Minix version that should be used as a teaching OS.
About the direction of Minix; I think it is impossible to keep only one version.
There definitely should be the OS teaching tool: the current version (should
be POSIX compatible). Besides that version there will evolve a second version:
the Minix for the hackers. A cheap, well written unix system which you can
really use for applications. For the latter version Bruce's patches are a
good step in the right direction.
Comments?
--
|
Rob ten Kroode (rob...@cwi.nl) | Don't read this !!
|
"When they said 'sit down' I stood up", Growing up - Bruce Springsteen
Phil C. Miller
[stuff about protected mode 286 being left out of future releases of MINIX]
[response from Bill Beebe about Andy's comments]
>One other thing
>you need to think about, Mr. Tanenbaum, and I'll draw a picture to help
>illustrate my point.
I am embarassed for you that you feel you need to patronize a prominent
figure in the field of computer science.
[more technocratic discussion]
>[...] I find your reasoning why
>Bruce Evan's work will cause a split to be flawed and technically
>imcompetent.
I find your manners to be astonishingly crude.
>I'm sorry for the tone of my message, but Minix is far larger than you
>apparently realize. I would strongly recommend you do more research
>and deeper thinking about Minix's future path.
Frankly, YOU are much SMALLER than you apparently realize.
It is totally unnecessary to be so abrasive in making your point.
Grow up.
Phil Miller
David Dyck
>
>.......[deleted]
>
>......... If you
>were a student you wouldn't fancy wading through all those #ifdefs for two
>days just to find you made a mistake early on in the code and that's why
>none of what the lecturer is saying fits together. I am a student and find
>nothing more annoying than conditional compilation, it ruins your day and
>often clouds the purpose of the code.
>
To those who do not wish to read conditional compilation directives
there is a great program that was posted to comp.sources.unix a while back.
It is archived in "Volume 3 (Ends Feburary, 1986)" with the index
"scpp (2 parts) A selective C preprocessor - clean up your C files."
I DID NOT WRITE IT. Credit goes to
Brad Needham
Tektronix, Inc.
...decvax!tektronix!tekig4!bradn
Here is the manual page.
SCPP(1) USER COMMANDS SCPP(1)
NAME
scpp - selective C preprocessor
SYNOPSIS
scpp [ -Mmacro ] [ -Dmacro ] [ -Dmacro=def ] [ -C ]
[ -Iincdir ] [ file... ]
DESCRIPTION
Scpp concatenates the input files (or reads standard-in, if
no file is given), interprets all references to given mac-
ros, leaving the rest of the file(s) unaltered, then writes
the result to standard-out. It is helpful in removing con-
ditionally compiled code or misleading macros from a file.
The file name "-" refers to standard-in.
The following options are available. Each option can appear
as frequently as desired.
-M Interpret all references to the given macro. Macro
can be either a single macro name or a
whitespace-separated list of macro names (e.g.
-MMAXINT or -M"MAXINT MININT INTWID"). All
occurrences of the macro and all instances of the
intrinsic macro "defined()" referring to this
macro are expanded. All preprocessor directives
referring to this macro (except #if) perform their
usual function and do not appear in the output.
#if directives are interpreted only if their value
is not dependent on macros which are not to be
interpreted.
-D Define the macro to have the value def, or "1" if
no def is given. Unlike the C preprocessor, scpp
does not implicitly define certain macros that
describe the environment in which the code will be
running (e.g. "vax" or "unix"). -D implies -M.
-C Preserve comments and whitespace in interpreted
macro definitions. Normally, comments and leading
and trailing whitespace are stripped from inter-
preted macro definitions.
-I Add incdir to the list of directories to be
searched for include files. Scpp searches direc-
tories in the same order as the C preprocessor: if
the include filename is enclosed in double-quotes
("...") rather than angle-brackets (<...>), the
directory containing the current file being pro-
cessed; the directories given by -I, left-to-
right; the standard directory, /usr/include.
AUTHOR
Brad Needham, Tektronix, Inc.
SEE ALSO
cc(1).
BUGS
Very long identifiers (those over 100 characters long) will
crash scpp.
Because scpp interprets only the given macros, the meaning
of some code will change. E.g. "scpp -MBOO" of
#define BOO hello,there
#define twopar(a,b) a b
twopar(BOO,folks)
will generate
#define twopar(a,b) a b
twopar(hello,there,folks)
causing an argument mismatch when the output is compiled.
Because uninterpreted "#if"s, "ifdef"s, and "ifndef"s, have
no effect on the output, the following example, when pro-
cessed via "scpp -MLEFT", will generate an error message
complaining about multiple definitions of "LEFT".
#ifdef ZULU
#define LEFT 20
#else
#define LEFT 347
#endif
The C preprocessor macros "__FILE__" and "__LINE__" have no
special meaning to scpp.
Bill Beebe
Mr. Miller, I won't argue the point about my crude display of manners. They
were and I have since made a (weak?) attempt at an apology. I'll accept
dressing downs where necessary, but it would help to follow conversational
threads before forming replies. This small rule applies to all of us.
This is a public apology to Dr. Tanenbaum and all others whom I offended
with my original message.
Henry Spencer
>I asked Andy some advise, and he told me that he didn't like the idea of
Job control is a stupid, poorly-thought-out, ass-backwards excuse for a
window system. It's mostly just a way of interacting with multiple
processes. Window systems do it much better, since they provide central
control of output as well as input, and if done well, it is transparent
to user programs (instead of requiring ugly hacks in each and every one).
No, you do not need a bitmapped display to do a window system.
One of my bigger regrets is that after Ian Darwin and I succeeded in
getting job control excluded from the /usr/group Unix interface standard,
I got busy with other things and didn't keep a sharp eye on POSIX (which
started from the /usr/group standard)... and job control, slimy tentacles
and all, slithered back in when I wasn't watching.
If anyone is interested, I think I still have the scathing commentary on
job control that Ian and I did at the time.
Tim Olson
| In article <81...@boring.cwi.nl> rob...@cwi.nl (Rob ten Kroode) writes:
| >I asked Andy some advise, and he told me that he didn't like the idea of
| >job control in Minix...
|
| Job control is a stupid, poorly-thought-out, ass-backwards excuse for a
| window system. It's mostly just a way of interacting with multiple
| processes. Window systems do it much better, since they provide central
| control of output as well as input, and if done well, it is transparent
| to user programs (instead of requiring ugly hacks in each and every one).
In a related question, has anyone else worked on "virtual terminal"
support for the console? By this, I mean the ability to have multiple
simultaneous sessions, and the ability to flip between them with a
"hot-key", like F3. I have seen this in other systems, and thought it
would be an interesting thing to add.
I'm not quite finished with it, but it appears to drop in very easily to
tty.c, at least on the PC version of MINIX.
-- Tim Olson
Advanced Micro Devices
(t...@amd.com)
James da Silva
>window system. It's mostly just a way of interacting with multiple
>processes. Window systems do it much better, since they provide central
>control of output as well as input, and if done well, it is transparent
>to user programs (instead of requiring ugly hacks in each and every one).
Interesting. I often find myself using job control to stop a process
without killing it. Or doing simple things like putting ftp,
compress, or rm into the background when they are taking longer than
expected. How does your alternative handle things like these? Do I
have to explicitly run each command in a separate window?
>No, you do not need a bitmapped display to do a window system.
Granted. Do you need a fast terminal? How do I do windows at 2400
baud without spending all my time redrawing the screen, or dividing
its 25x80 chars into tiny `windows'?
>If anyone is interested, I think I still have the scathing commentary on
>job control that Ian and I did at the time.
I'm interested. I think you should post to comp.os.minix; Minix is
about learning OS design tradeoffs, after all.
Henry Spencer
>If anyone is interested, I think I still have the scathing commentary on
>job control that Ian and I did at the time.
I'm already getting a steady stream of requests for this, so here it is.
If I were formally submitting it today I'd probably make some small changes,
but I don't have time for that now (so bear in mind that it's old). Also,
I have not consulted Ian about this and cannot say whether his views have
changed or not.
----------
.TL
Comments on Terminal I/O, Specifically `Job Control'
.AU
Henry Spencer
.AI
University of Toronto
utzoo!henry
.AU
Ian Darwin
.AI
University of Toronto
.SH
`Job Control', What It's Really About
.PP
There is no longer any argument that it is desirable to permit orderly
user interaction with multiple processes.
Unfortunately, a whole generation of Unix users has had their view of
this concept warped by the dreadful way it was implemented by Berkeley.
And AT&T, in its recent attempt to address the problem, has taken the
easy way out instead of doing it right.
.PP
The basic concept involved here is multiplexing, not `job control' or
process suspension.
The ideal is something like the environment on the Bell Labs Blit,
where multiple processes run simultaneously in multiple windows,
and the user can switch
his attention and his interaction from one to another at will.
There is a popular misconception that doing this \fIrequires\fR a
Blit or a similar highly-intelligent terminal;
this is simply not true.
.PP
Window-based multiplexed interaction
is harder to do when the terminal is dumb, but even the Blit is not
actually writing things into several windows \fIsimultaneously\fR:
it just looks that way because of the high-speed multiplexing involved.
There is no intrinsic reason why this multiplexing cannot be done at
the other end of the communications line when the terminal is incapable
of doing it.
.PP
The multiplexing can be done in the kernel (albeit at considerable cost
in added kernel complexity) or in a user process (given suitable
interprocess communication).
In either case, the fundamental structure is quite simple: a central
`manager' coordinates terminal i/o to and from `client' processes,
each of which has total control of its own "virtual terminal".
The manager's job is simulating multiple virtual terminals on a single
real terminal,
by routing input to the appropriate process
and placing output in the appropriate area of the screen.
.PP
The basic characteristics of such a multiplexing system are that each
process has what looks (to it) like a private terminal, and that all
i/o to and from the user is centrally supervised.
This is precisely analogous to file i/o under Unix:
simultaneous independent activity by multiple processes,
coordinated by a central manager
which multiplexes physical resources so as to prevent interference.
The benefits are similar:
individual processes neither know nor care about the multiplexing,
and useful high-level abstractions can be implemented in one
central place.
.SH
Job Control and Layers: Half-Baked Approaches
.PP
The existing schemes, Berkeley `job control' and AT&T `layers',
unfortunately are clumsy and incomplete attempts at implementing
multiplexed interaction.
Neither one makes any provision for simultaneous on-screen activities
by more than one process, except for the `cop-out' of permitting
multiple processes to intermix their output at random.
But there are deeper problems.
.PP
Both schemes require that \fIevery\fR \fIprogram\fR which is going
to participate in multiplexed interaction must contain code to allow for
this possibility!
User programs must be prepared to redraw the screen on request,
with the requests coming from the kernel in the Berkeley scheme and
from the user in the System V.2 scheme.
This is an abomination.
.PP
Not only does this demand specialized code in every user program, but
it entirely denies multiplexed interaction to the bulk of Unix programs.
The concept of `redraw the screen' is meaningful only for interactive
programs with full-screen interfaces.
The result of, say, an \fIegrep\fR, once replaced on-screen by (say)
the editing buffer of a \fIvi\fR, is gone for good.
Since \fIegrep\fR is not an interactive program, it is no longer around
to be asked to redraw its output.
.PP
The heart of the problem is that
neither job control nor layers implements the crucial half of a window system:
centralized management of screen updates.
It has long been accepted that multiple processes cannot safely do
updates to disks without centralized management and consistency
control.
The same obviously
applies to terminal i/o:
orderly simultaneous interaction with multiple processes requires
centralized supervision of the interaction.
The existing schemes supervise input but not output.
.PP
It is obvious \fIwhy\fR this deficiency exists: supervising output is
the hard part.
The idea of switching input from one program to another is reasonably
straightforward.
Differences in input handling, such as `cooked' vs. `raw' modes, are
relatively minor problems,
since the user can be conversing with at most one process at a time.
But a CRT terminal permits output from multiple processes to be displayed
simultaneously, and coordinating screen updates isn't trivial.
Furthermore, there is no agreement on the precise user interface that
should be presented for output \(em consider, for example, the religious
debates over overlapping vs. non-overlapping windows \(em and this
discourages attempts to provide a single and relatively inflexible
central solution.
The immense variation in CRT-terminal control sequences puts the icing
on the cake.
.PP
Nevertheless, these problems \fIcan\fR be solved.
There are at least three, and probably several more,
complete window systems in experimental use.
Some of them have performance problems, and most of them are outside the
kernel and hence have interprocess-communication problems, but they do work.
.SH
Standardizing Multiplexed Interaction: A Recommendation
.PP
As mentioned above, several experimental window systems already exist.
(This is quite apart from the `real' window systems on bitmapped
workstations, which are also relevant.)
Experience with these and other implementations of the same concept
will yield a wealth of knowledge on how best to handle this function.
It is important that this experimentation,
and the adoption of the results that come out of it,
not be stifled by further
`official endorsement' of incomplete and badly-designed existing schemes.
.PP
The best approach for /usr/group to take on this matter would be to
reserve some characters, and some flag bits, for implementations of
multiplexed user interfaces,
but not to specify any such interface at this time.
Such an attempt to specify the interface would be premature,
especially when the two approaches under consideration are already
known to be grossly-incomplete botches.
.PP
\fINeither Berkeley `job control' nor AT&T `layers' is an adequate
implementation of a multiplexed user interface.
Neither one should be cast in concrete as a standard at this time.\fR
.SH
A Retraction
.PP
Our previous recommendation was that, if multiplexed interaction \fImust\fR
be standardized, AT&T `layers' would be a better place to start.
The layers system, unlike Berkeley job control, does do input multiplexing
more-or-less correctly, and hence is essentially upward-compatible with
true window systems.
It has several desirable characteristics:
independent tty state for each layer,
suspension/resumption invisible to the processes,
a central manager process which is \fInot\fR imbedded in a shell,
and an implementation that does not have ramifications everywhere.
.PP
Nevertheless, as discussed above,
it doesn't do the hard part: output multiplexing.
It also has some annoying implementation limits, which,
although they wouldn't
necessarily have to propagate into a standard,
might well propagate into most early implementations.
Its major problem is that it's not clear how to extend it to
centralized output management without imbedding said management inside
the kernel.
.PP
We therefore retract our recommendation for standardizing layers as a
second choice.
The proper course is to standardize nothing,
at least until we understand the user-interface issues
and the implementation problems
better.
.SH
Specifics
.PP
A decision not to standardize a multiplexed-interaction scheme
notwithstanding, there are a few useful minor things that can be
standardized.
The \fItermio\fR structure probably should have a reserved character
or two (or room for same) and a few reserved bits (or room for same)
to permit kernel-based implementations of multiplexing.
.PP
In particular, almost any multiplexing scheme using ordinary ASCII
terminals will need a special character to attract the attention of
the multiplexing software.
Without this, it's very difficult to do things like moving between
windows.
Reserving space for such a character might be useful; recommending a
default choice for the character would be very valuable, as it would
forestall unnecessary differences between implementations.
Control-Z would be plausible.
.PP
Implementing supervision of multiplexed interaction in user processes
is difficult in many existing Unix implementations, minimal
implementations of the existing /usr/group standard among them.
The basic problem is that normal user processes are definitely aware
that their output is going to a terminal,
the device-independence of
Unix i/o
notwithstanding.
Screen-oriented programs doing \fIioctl\fRs are the biggest problem.
A less obvious glitch is that \fIstdio\fR adjusts its buffering
strategy depending on whether output is to a terminal or not;
this is a major nuisance with some existing window systems.
Something like the `pseudo-tty' concept would be very useful: an entity
which looks like a terminal from one side,
but whose behavior is under user-process control from the other side.
Some existing systems do implement such things, but the
lack of standardization largely prevents use of them in portable programs.
.SH
Suspending Processes: A Non-Issue
.PP
Several people have objected to AT&T layers, and similar approaches,
on the grounds that `...but 4BSD lets me suspend misbehaving processes...'.
This is silly; a process-suspension facility can be very simple
if it isn't required to double as a multiplexing system.
.PP
If it is thought desirable to standardize process suspension, we would
suggest the following.
Some magic character (control-Y?), when typed as input to a tty/window,
suspends all processes attached to that tty/window.
The suspension can be, and should be, utterly invisible to the processes
involved.
This avoids the sticky problem of how to notify the processes without
doing incompatible things to the \fIsignal\fR mechanism.
The suspension probably should have a permission requirement analogous
to that of signals: if the effective userids of the user and the process
don't match, the suspension doesn't happen.
This is necessary to prevent major security breaches like suspending
\fIpasswd\fR(1) in the middle of an update to the password file.
.PP
Note that this suspension facility isn't very useful in the absence
of multiplexed interaction \(em you can't \fIdo\fR anything to a
suspended process without access to another (real or virtual) terminal \(em
but the two concepts are nevertheless quite independent.
There is no need to confuse them.
.SH
Miscellaneous Comments
.PP
Departing from multiplexed interaction, we'd like to raise again a
couple of minor issues mentioned in the previous paper...
.PP
An ignored hangup signal should not only cause reads to return
end-of-file,
it should also cause writes to be no-ops.
Hangup should, in general, disconnect lingering processes from the
terminal completely,
so they don't hang around to bedevil the next user.
.PP
One extremely useful feature that is missing is terminal pagination.
To quote Rob Pike: ``terminals should not scroll [without
the user's permission]''.
Many people think this a useless frill, but they almost invariably
are people who have never tried it.
Most people who try it seriously, love it.
Even the simplest and crudest implementations (such as the one on the
system this document is being written on) are major improvements on
a terminal interface that lacks this feature.
This is not a new and unknown idea: it has been conceived and implemented
independently at least three times, has been in use for years, and is
generally perceived by its users as a big win.
----------
Ozan Yigit
Job Control (net.unix.wizards: 12 apr 86): [I do not have the whole
article on line anymore]
> My impression is that BSD job control is something that was
> put in by expedient means in order to achieve a certain effect, and the
> effect is excellent, within the serious limitations of the mechanism.
> SV job control was done with a cleaner conceptual foundation, but with
> a less lucid view of what it is for, and less effort devoted to making
> it useful. Indeed, I suspect it is not much used.
oz
--
SomeOS4.n: Brooks was right all Usenet: o...@nexus.yorku.ca
along, but it shouldn't take so ......!uunet!utai!yunexus!oz
large a pie in a face to figure Bitnet: oz@[yulibra|yuyetti]
it out.. anon. Phonet: +1 416 736-5257x3976
Desmond Young
> I'm pretty impressed by Minix. GNUos (if it ever appears) won't have a
> chance of ever running on PC XT clones. Minix seems like a seems which has
> a path from 8086/80286/80386 in a reasonable way if changes are made. A
> few minor extensions would make Minix far more usable to me:
> 1) support TCP/IP (I'm not going to ask for XNS) -- i.e. ftp/telnet would
> give it real world usefulness. I'd be happy to discuss how to do this with
> anyone else interested.
> ARPA: leisne...@xerox.com
> GV: leisner.henr
> NS: martin leisner:wbst139:xerox
> UUCP: hplabs!arisia!leisner
Well....,
I have Phil Karn's TCP-IP (NET) package running under MINIX. But, I have
not posted it for the following reasons:
1. Only the original Version 1.000000 software will compile in 64K code,
the MINIX compiler is AWFUL.
2. I have written the Ethernet driver for the National Semiconductor
DP839EB (Evaluation Board for the DP8390 chipset).
3. The driver, and MINIX is lower performance than I would like.
Now,
The DP8390 Ethernet Controller is the chip set used in MOST PC cards, that's
the good news. For example, the WD Etherplus uses our chipset, later 3com
boards do, lots of clones do. In fact the amoeba code with MINIX is written
for this set.
Now the bad news. Our Eval board uses the two on-board dma channels on the
DP8390 to implement remotely-accessed shared memory. The WD board uses dual-
ported shared memory. However, it should be even easier to have it talk to
our set on the WD card than the EB.
I have taken the V1.0 NET package and put it a load of the "BEST" features
from some later versions of NET. For example, I have added the rmdir, mkdir,
chdir, into FTP. I have also added access permissions, host file address
lookup, and so on. So, NET is pretty usefull.
I stopped work on it since MINIX was so awful at interrupts it was not
possible to write a REALLY high performance driver (I am picky). If anyone
is really interested I could give you a copy on a 1.2M floppy.
The Ethernet driver could be made to support the 3c500 also. This is the
NET packages usual card (but god it is awful).
Anyway, many thanks to Phil Karn, KA9q, and other contributors, the package
is really great. Almost all the problems I had were MINIX, not NET. Also
thanks to Ed Hall, he sent me the V1.0 source he had got working with SLIP
under MINIX.
One last point, NET effectively polls all servers and clients, so it runs
stand-alone on your machine. It does offer multiple sessions, so for example,
I run the echo, discard, telnet, mail, and ftp servers, and offer up to
four clients when I am running NET. The executable (with debugging) is now
about 55+KBytes, so I cannot add much more to it (it really needs the mailer
upgrading).
Sorry about raving on,
Cheers, Des.
Rahul Dhesi
that I will counter briefly:
1. Job control versus multiple windows is a false dichotomy.
2. Each and every program does not need special code to deal with
job control. Only programs that change terminal settings,
and privileged programs that should not be interrupted by
unprivileged users, need such code.
3. Multiple windows are useless at 1200 bps.
4. Multiple windows are useless on a hardcopy terminal.
The best solution is to allow multiple windows, and job control within
each. This lets the user decide which to use: multiple windows only,
or job control only, or a combination of both.
--
Rahul Dhesi <dh...@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
Career change search is on -- ask me for my resume
Desmond Young
> .... The real
> value of POSIX compatibility will come when there is a 386
> version of Minix that can take advantage of it. An adequate
> stop along the way would be a 286 PM version with a large-
> model compiler.
>
> decision not to adopt Bruce's version.
it should not become the defacto standard.
Des.
--
Reply: d...@logic.nsc.com
{decwrl,hplabs,sun,pyramid,amdahl}!nsc.com!logic!des
Des Young, M/S D3635 National Semiconductor, Santa Clara
The light at the end of the tunnel was only a burglar's torch - J.Buffet.
John C. Archambeau
control via the csh and BSD UNIX then arguing that it isn't any good is like a
two year old arguing over what his favorite flavor of ice cream is. Whether
or not you want job control and the csh in Minix is your business, but there
are some of us who do. I hate SysV Unix because of its lack of job control,
there are times when I want to do a ^Z and suspend a job just to find out what
the (*bleep*) is going on with the rest of the system, then I go put it in the
background or do something else. Job control is a nice feature of the user
controlling his/her processes and since enough of us here are fond of BSD
Unix, it's obviously a well used feature of the csh.
Dale Schumacher
>In article <27...@munnari.oz>, mul...@munnari.oz (Paul Muller) writes:
>
> [ about the future design of Minix, and it's direction ]
>
>> POSIX compliance is probably important from the point of view of teaching
I also think POSIX compliance is very important for all versions.
>> The second is the 'upmarket' Minix that everyone seems to think is so
>> important, why? Most people who got into Minix for reasons other than formal
>> education just wanted to 'hack around'.
>> If people are so into the idea of 'real life' Unix, then checkout AT&T, SCO,
>> etc offerings. They produce different BINARIES for each processor ...
>
> Not only did I buy Minix to play with, but also to have a version
>of Unix with almost full source code, and to be a part of comp.os.minix,
>where each of us can add to Minix's source code pool, and also help
>with design ideas, bug reports etc. This is difficult (nay, impossible)
>with real Unix.
I learn an awful lot by hacking, and I don't have time to take OS classes,
so Minix is my vehicle for learning the guts of a Unix-like OS. Having
all the sources is both a boon and a bane. I'm sure you understand how
it is a boon, and the bane is the much stronger temptation to spend lots
of time trying to "just get in there and fix it" rather than finding a
work-around, or being happy with the current limitations. The makes
Minix a tremendous time-sink for me :-)
> At the present point in time, Minix only vaguely resembles current
>flavours of Unix, and I would really like to see it become as compatible
>with both the ATT and Berkely flavours of Unix. This has already started
>with sources such as termcap(3), and the memcpy,bcopy variants. Both
>flavours of Unix overlap in many areas, and also have extensions which exists
>in only one flavour. If Minix could be a fusion of both flavours, and
>keep compatibility with them AND POSIX ( & SVID ?), then we would have
>an O/S which would be the best of both worlds AND with source.
There are many thing in more modern *nixes that are worth looking at as
example of what will and won't work well as a future direction. I think
it's foolish to freeze Minix at the "let's make it look like V7" stage.
>> What is
>> needed is some form of arbitration committee to decide what goes in the
>> upmarket version. This should not just rest on ast's shoulders, I prefer
>> he gets more time to write his great books! :-)
>
> Yes! Andy, 'though, being the founder of Minix, should have the
>final say on the future of Minix. But a committee of some sorts would
>take a lot of the load from him.
I don't know about this design-by-comittee stuff. The sources were made
widely available, if I understand correctly, to make Minix ACCESSABLE
and LEARNABLE to people who aren't going to spend thousands for a source
license. I'd like Andy to comment on how he feels about a net-supported
upgrade path that may deviate from the "teaching OS" baseline. I don't
think an offical non-Andy standards body is really needed, though. If
the net-users collectively like a change, it will continue to be carried
along in future mod-packages, etc. The biggest problem I see is how to
make a certain set of mods into the next "official" version so that new
users can buy the complete package from PH. I don't know the answers
to these distribution problems. I'm just planning to continue working
on changes that I think are useful, and hope they will be used and made
available to other, somehow.
>BTW, speaking of Minix design, what about job control and the extra
>Berkely signals for Minix. This will allow shells etc, to have better
>control over child processes, and won't be incompatible with the
>Version 7 & SysV signals - well, perhaps a few! Any ideas, comments?
Ah.. Lots of ideas. I'm working with the ST version of Minix, but some
of what I'm working on will hopefully port back to the PC verison. Some
will definately not, but that's mostly because I will be working in the
machine dependent code quite heavily. In working on getting uucp going,
(yes, that's still in progress) I've had tremendous trouble with the
rs232 driver, so I've been looking into it and have decided to rewrite a
good portion of it, both to improve the reliablility of the interrupt
routine (which had a few bugs) and to improve overall performance by
letting the clock tick trigger the rs232 task when there is data
rather than processing on every rs232 buffer interrupt. Also, I'm
moving away from the sgtty structure toward termio, probably with the
Sun extension for window sizing (make 25/50 line mode much easier).
Also in the queue, not directly from me, but from someone I'm working
with, is support for PTY's. He says this should be a pretty small
change, and can be very useful.
I've also taken Andy's suggestion on p.184 and implemented direct data
transfer between user processes and the FS/MM. This breaks the modularity
ideal, but results in a good performance increase (20-30%). My code is
conditionally compiled so the "clean" method is still available. In
addition, since this is ST code, a further conditional mod may be the
use of the blitter chip, if you have one, to assist in the copying.
Further down the road I'm looking into implementation of STREAMS and
the X window system. These upgrades will require significant mods to
the core of the kernel, maybe even restructuring the task switching
and message passing code.
I hope that my work will be appreciated by the user community and will
find it's way into the "official" version, but regardless, I'm going to
use the changes, and I expect there are other out there who will also.
--
Dale Schumacher 399 Beacon Ave.
(alias: Dalnefre') St. Paul, MN 55104-3527
...bungia!midgard.mn.org!syntel!dal United States of America
"I may be competitive, but I'm never ruthless"
Tom Poage
have a hard time getting along without job control.
Anyone care to take a crack at writing an AT&T-free ksh? :-) Tom.
Henry Spencer
>without killing it. Or doing simple things like putting ftp,
>compress, or rm into the background when they are taking longer than
>expected. How does your alternative handle things like these? Do I
>have to explicitly run each command in a separate window?
No, just shift to a fresh window when -- and only when -- the one you're
running in is taking too long to finish.
>Granted. Do you need a fast terminal? How do I do windows at 2400
>baud without spending all my time redrawing the screen, or dividing
>its 25x80 chars into tiny `windows'?
At low speeds, typically the best way to organize windows is to make them
the size of the screen and have only one showing at a time. There is no
need for screen redrawing to involve any more characters than sending
stuff to the screen in the ordinary way, unless the window manager is
stupid.
Henry Spencer
>1. Job control versus multiple windows is a false dichotomy.
Please elaborate; looks like a real one to me.
>2. Each and every program does not need special code to deal with
> job control. Only programs that change terminal settings,
> and privileged programs that should not be interrupted by
> unprivileged users, need such code.
And any program for which there is any likelihood that its output might
have to be redrawn. That is, every program.
>3. Multiple windows are useless at 1200 bps.
Then don't put more than one on the screen at a time. The others are still
accessible if needed.
>4. Multiple windows are useless on a hardcopy terminal.
True. How many people work on hardcopy terminals?
>The best solution is to allow multiple windows, and job control within
>each...
Why provide two ways of doing the same thing? See Ken Thompson in the
original Unix papers on the virtues of doing things only one way.
Charles Marslett
> >the best solution is to allow multiple windows, and job control within
> >each...
>
> Why provide two ways of doing the same thing? See Ken Thompson in the
> original Unix papers on the virtues of doing things only one way.
What this all boils down to, I think, is that a window manager has to do
all the things job control does, and some even allow programs written with
no knowledge of the window manager's operation to run. Job control on the
other hand, is a subset of the window manager's functionality, so it must
be either replaced (as I understand the normal scheme of things handles it)
or the duplicate functions trip all over each other when you add a windowing
scheme.
The primary issue I would like to raise is how much of a performance hit do
you get by adding the window manager to the screen output/keyboard input path
over having the simpler job control scheme. I do not mean X11 or whatever, just
an OS/2 style monitor to map I/O to various "logical windows". Has anyone
ever done this?
> --
> You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology
> but it's not worth it. -Collyer| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Charles Marslett
ch...@killer.dallas.tx.us
Brandon S. Allbery
+---------------
| Therefore, I propose that Minix be broken into two parts. One, a simple
| static version of Minix, such as 1.3, to be used to teach about
| operating systems, and based on the XT or ST. The other, a continually
| evolving system, to keep everybody else happy. This should be ported to
| many machines, like the ST, '286 & '386 etc, and hopefully should mean
| that all the machine dependencies will reside in only a few files in the
| kernel/mm/fs/etc.
If you're so interested in working on a PDist "real Unix", maybe you should
send a note to r...@prep.ai.mit.edu. Dr. Tanenbaum has made it clear that
Minix is intended for educational use only.
++Brandon
--
Brandon S. Allbery, moderator of comp.sources.misc all...@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery ncoast!all...@hal.cwru.edu
Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
Rahul Dhesi
Job control versus multiple windows is a false dichotomy because one
does not exclude the other.
>>2. Each and every program does not need special code to deal with
>> job control. Only programs that change terminal settings,
>> and privileged programs that should not be interrupted by
>> unprivileged users, need such code.
>
>And any program for which there is any likelihood that its output might
>have to be redrawn. That is, every program.
No. If a program produces strictly sequential output, you only need to
redraw it if it has scrolled off your screen or been overwritten by the
output from some other screen-oriented program. But this is not caused
by job control, so job control should not be blamed for it.
If you want all output from a program to be always accessible, you need
a virtual screen much bigger than your physical screen. Multiple
windows are neither necessary nor sufficient to give you that.
>>3. Multiple windows are useless at 1200 bps.
>
>Then don't put more than one on the screen at a time. The others are still
>accessible if needed.
It takes too long to redraw the screen at 1200 bps. Switching between
windows is painful at less then 9600 bps, and even at 9600 bps it is an
inconvenience.
>>4. Multiple windows are useless on a hardcopy terminal.
>
>True. How many people work on hardcopy terminals?
I don't know. I occasionally do when I need a record of what I did.
How do you make a log of everything you did in a terminal session in
order while still using multiple windows?
Re job control + windows:
>Why provide two ways of doing the same thing?
One of them doesn't work well under certain circumstances, such as 1200
bps, and the other doesn't let you flexibly handle concurrent jobs that
produce output to the screen. If you value both situations you need
both job control and multiple windows.
For jobs that expect no input from the terminal, I find it most
convenient to redirect all output to a log file. This effectively
gives me a much bigger window into the output than any conventional
windowing scheme would. And at any time I can do "tail -f logfile" and
see the output in real time, and I can even suspend *this* job (running
tail) and resume it later if I wish.
If we all had high-speed links (at least 19.2 kbps), and big terminals
(perhaps 100 characters by 100 lines), multiple windows might be the
perfect replacement for job control. Perhaps in 1995 or so Henry
Spencer's claims will be indisputable.
Glen Overby
>Anyone care to take a crack at writing an AT&T-free ksh? :-) Tom.
Somebody already has. You can FTP it from urth.cc.buffalo.edu. We've tried
compiling it on a 4.3BSD VAX, and it doesn't.
--
Glen Overby <ncov...@plains.nodak.edu>
uunet!ndsuvax!ncoverby (UUCP) ncoverby@ndsuvax (Bitnet)
Chet Ramey
>have a hard time getting along without job control.
I'm one. I use job control and windows all the time.
>Anyone care to take a crack at writing an AT&T-free ksh? :-) Tom.
It's being done, and in more than one place.
Brian Fox, with a little help from the masses (again, I'm one :-), has just
released version 0.99 of bash, the Bourne-Again SHell. This is the GNU
project's Bourne+ Shell. It has the job control, command-line editing,
tilde expansion, etc. that ksh provides in addition to bourne shell
compatibility. It's really a good shell, already an implementation of the
current POSIX shell specification (part of the output of 1003.2), and I
expect it to pick up more ksh features as time goes on. The first I'm
expecting is expression evaluation (the (( )) stuff).
Eric Geisen, at the University of Waterloo, is working on a PD ksh, with full
compatibility as its goal. I picked up an old version from Toronto (don't
even try -- they restricted FTP access to it soon after it was announced as
available). This version had emacs-style editing, job control (both picked
up from the BRL s5r2 shell), nearly full s5r2 sh compatibility, and other
goodies. I'm sure it's being worked on as well, but no version of it is
currently available from either Waterloo or Toronto, and Eric has not been
very good about answering mail about availability.
Chet Ramey Network Services Group, CWRU ch...@cwjcc.INS.CWRU.Edu
"Unix System V: From now on, consider it sub-standard"
Chet Ramey Network Services Group, CWRU chet@{cwjcc,pirate}.INS.CWRU.Edu
"The flagon with the dragon has the potion with the poison;
the vessel with the pestle holds the brew that is true!"
Charles Brown
>>> each...
>> Why provide two ways of doing the same thing? See Ken Thompson in the
>> original Unix papers on the virtues of doing things only one way.
>all the things job control does, and some even allow programs written with
>no knowledge of the window manager's operation to run. Job control on the
>other hand, is a subset of the window manager's functionality, so it must
>be either replaced (as I understand the normal scheme of things handles it)
>or the duplicate functions trip all over each other when you add a windowing
>scheme.
I have not seen a window manager which provides *suspend*.
I occasionally have large simulations which spend several days
running, during which time they spend lots of time swapping portions
to disk. The task already is in the background. I want to be able to
suspend it so it does not slow me down in my daytime tasks (by always
swapping my foreground tasks to disk be cause I stopped typing for a
second). Then each evening before I leave I can restart the
simulation and let it swap away all it wants.
Windows do NOT replace job control.
--
Charles Brown cha...@cv.hp.com or charles%hpc...@hplabs.hp.com
or hplabs!hpcvca!charles or "Hey you!"
Not representing my employer.
"The guy sure looks like plant food to me." Little Shop of Horrors
Brandon S. Allbery
+---------------
| In article <1989Jun7....@utzoo.uucp> he...@utzoo.uucp (Henry Spencer) writes:
| >Job control is a stupid, poorly-thought-out, ass-backwards excuse for a
| >window system.
|
| without killing it. Or doing simple things like putting ftp,
| compress, or rm into the background when they are taking longer than
| expected. How does your alternative handle things like these? Do I
| have to explicitly run each command in a separate window?
I use JSB Multiview at work; if I need to kill a process or want to switch
something into the "background", I just pop up the Multiview menu and select
or open another window to work in. -> If you can't manipulate windows
dynamically, it's a p*ss-poor window system.
+---------------
| >No, you do not need a bitmapped display to do a window system.
|
| Granted. Do you need a fast terminal? How do I do windows at 2400
| baud without spending all my time redrawing the screen, or dividing
| its 25x80 chars into tiny `windows'?
+---------------
"Window system" does not necessarily imply multiple on-screen windows.
I use Multiview with 80x25 (status line on our terminals is also windowed!)
-- and BSD comes with a critter called "screen" which does the same thing,
80x25 "windows". With this setup, it costs little more (only pty overhead)
to run windows as not -- I also use MultiView over the modem, although not
often because it has a rather brain-damaged way of dealing with insert/delete
multiple lines (ANSI ESC [ nnn L, et alia).
+---------------
| >If anyone is interested, I think I still have the scathing commentary on
| >job control that Ian and I did at the time.
|
| I'm interested. I think you should post to comp.os.minix; Minix is
| about learning OS design tradeoffs, after all.
+---------------
Seconded. Although you might cross-post to comp.unix.wizards, assuming you
want to start a flame war ;-)
ne...@sq.sq.com
>have a hard time getting along without job control.
>Anyone care to take a crack at writing an AT&T-free ksh? :-) Tom.
Yup, the gnu project's Born Again Shell ("bash") is an attempt
at bashing all the features of sh together with many of those
from both csh and ksh. It is not subject to any AT&T or BSD license,
nor is it subject to any constraints imposed by segmented architectures,
i.e., it won't run on your PC/XT, period. To wit:
$ size bin/bash
text data bss dec hex
188416 16384 10992 215792 34af0
If you have a reasonable computer to run it on, and a compiler
that isn't hamstrung by historical necessity for compatibility
with segmented architectures, you can get the source (it's free)
and try running it. As with all GNU-ware, THERE IS ABSOLUTELY NO
WARRANTY, etc., etc. See the file COPYING in the source directory
for details.
What does this have to do with the original thread of discussion?
Oh yeah, I almost forgot. Bash has had csh-style job control bashed
into it, along with csh-style history but with Bourne-shell
control syntax (for f in $x instead of foreach f ($x) etc).
Something for everybody?
Ian Darwin | Segmented architecture is great...
i...@sq.com | for platyhelminths. Why are there so many
| worm programs on PC-class machines?
P.S. I don't work for the Free Software Foundation, I just happen
Dave Rivers
> In article <16...@louie.udel.EDU>, Leisne...@xerox.com (marty) writes:
> > 1) support TCP/IP (I'm not going to ask for XNS) -- i.e. ftp/telnet would
> > give it real world usefulness. I'd be happy to discuss how to do this with
> > anyone else interested.
>
> I have Phil Karn's TCP-IP (NET) package running under MINIX. But, I have
> not posted it for the following reasons:
> Anyway, many thanks to Phil Karn, KA9q, and other contributors, the package
> is really great. Almost all the problems I had were MINIX, not NET. Also
> thanks to Ed Hall, he sent me the V1.0 source he had got working with SLIP
> under MINIX.
SLIP - really???!!!
It all sounds *too* good to be true....
A SLIP implementation would be real nice for those of us
without an ether-net card - or to run at home for nightime mail.
Any chance of that making it to the net???
- Dave Rivers -
+----------------------------------------------------------------------+
| Time Sharing is the use of | Dave Rivers: |
| many people by the computer. | UUCP {Backbones}!rti!dg-rtp!rivers |
| | Phone: (919) 248-6137 |
+----------------------------------------------------------------------+
Dave Rivers
> > 1) support TCP/IP (I'm not going to ask for XNS) -- i.e. ftp/telnet would
> > give it real world usefulness. I'd be happy to discuss how to do this with
> > anyone else interested.
> I have Phil Karn's TCP-IP (NET) package running under MINIX. But, I have
> not posted it for the following reasons:
> is really great. Almost all the problems I had were MINIX, not NET. Also
> thanks to Ed Hall, he sent me the V1.0 source he had got working with SLIP
Mike J. Fuller
[Lots of stuff deleted...]
>Windows do NOT replace job control.
Ditto. At the moment, I'm working on sun 4/260 and I can start up
lots of windows plenty quick, but I still use job control within my
windows frequently.
/---------------------------------------------------------------------------\
| Mike J. Fuller |Internet: mfu...@prandtl.nas.nasa.gov|You'd be paranoid, |
|----------------| mi...@vax1.cc.uakron.edu |too, if everyone |
|/\/\/\/\/\/\/\/\|Bitnet: r3mjf1@akronvm |was out to get you!|
\---------------------------------------------------------------------------/
Mike J. Fuller
>In article <1989Jun10.0...@utzoo.uucp>, he...@utzoo.uucp (Henry Spencer) writes:
>The primary issue I would like to raise is how much of a performance hit do
>you get by adding the window manager to the screen output/keyboard input path
>over having the simpler job control scheme. I do not mean X11 or whatever, just
>an OS/2 style monitor to map I/O to various "logical windows". Has anyone
>ever done this?
To a certain extent, yes. A long time ago, I built a program called
"screen" on our suns here. I can't remember where I got it, but it
does exist and work on machines with BSD support. It's README file
begins:
"screen" is a window manager that allows you to handle several
independent screens (UNIX ttys) on a single physical terminal; each
screen has its own set of processes connected to it (typically
interactive shells).
Incidently, I rarely use screen because _I_ have job control. :-) I
only built it because there is no way to escape from and suspend a
decnet login like a telnet or rlogin (sun's dni software s*cks), and
that is rather frusterating when you're logged in from a 80x24
terminal. Also, on PC's, NCSA telnet provides a similar "window"
system. It is rather nice and fast.
Preston Bannister
> In article <17...@mimsy.UUCP> j...@mimsy.umd.edu (James da Silva) writes:
>>Interesting. I often find myself using job control to stop a process
>>without killing it. Or doing simple things like putting ftp,
>>compress, or rm into the background when they are taking longer than
>>expected. How does your alternative handle things like these? Do I
>>have to explicitly run each command in a separate window?
>
> No, just shift to a fresh window when -- and only when -- the one you're
> running in is taking too long to finish.
I partly disagree. Sometimes I'll shift to a fresh window and let the
command run. At other times (usually when there is some state
associated with the current window) it is more efficient suspend and
background the (long running) command.
>>Granted. Do you need a fast terminal? How do I do windows at 2400
>>baud without spending all my time redrawing the screen, or dividing
>>its 25x80 chars into tiny `windows'?
>
> At low speeds, typically the best way to organize windows is to make them
> the size of the screen and have only one showing at a time. There is no
> need for screen redrawing to involve any more characters than sending
> stuff to the screen in the ordinary way, unless the window manager is
> stupid.
The answer to this question depends on how your "windows" are
implemented.
When I dial into work from home, I usually run a version of UW ("Unix
Windows"). UW provides multiple simulated terminals (each "terminal"
screen in it's own window) with only a single serial connection to the
host machine.
I find that 2400 baud is _much_ more livable using UW as my local
(home) machine does all repaints from it's internal representation of
the "screen" in each window.
---
Preston L. Bannister
USENET : {hplabs,oliveb,spsd,zardoz}!felix!preston
BIX : plb
CompuServe : 71350,3505
GEnie : p.bannister
--
Preston L. Bannister
USENET : {hplabs,oliveb,spsd,zardoz}!felix!preston
BIX : plb
CompuServe : 71350,3505
GEnie : p.bannister
Micha Berger
What got added to make 1.3? I'm sort of strapped for funds, and would like to
know if the new version has the features I'm saving up for.
Are the com ports supported (without my inserting my own, somewhat buggy code?)
How 'bout cu? Basically, all I ever return to DOS for is my communications
program. If I could get a good package in MINIX, I'd say goodby to the M word.
--
Micha Berger
"Always should [the children of] Adam have awe of G-d in secret and in public,
admit the truth, and speak truth in his heart."
Jan-Hinrich Fessel
>To a certain extent, yes. A long time ago, I built a program called
>"screen" on our suns here. I can't remember where I got it, but it
>does exist and work on machines with BSD support. It's README file
>begins:
>
Screen was posted some times ago to the comp.sources.unix group.
Anyone giving me sockets, then I will do the cheap rest...
Jan-Hinrich
--
Jan-Hinrich Fessel
Universitaet Dortmund, IRB j...@unido.uucp || j...@unido.bitnet
There's no way to delay that trouble comin' every day... F.Z.
=============================================================================
Henry Spencer
>does not exclude the other.
They merely duplicate each other.
>... If a program produces strictly sequential output, you only need to
>redraw it if it has scrolled off your screen or been overwritten by the
>output from some other screen-oriented program. But this is not caused
>by job control, so job control should not be blamed for it.
Job control can quite fairly be blamed for failing to solve it, however.
>How do you make a log of everything you did in a terminal session in
>order while still using multiple windows?
How do you make such a log with ONE window if you're running screen-
oriented programs, like say a modern editor, whose i/o can't be logged
easily? There just ain't no graceful way.
Ed Hall
>In article <3...@blenheim.nsc.com> des@berlioz (Desmond Young) writes:
>> Anyway, many thanks to Phil Karn, KA9q, and other contributors, the package
>> is really great. Almost all the problems I had were MINIX, not NET. Also
>> thanks to Ed Hall, he sent me the V1.0 source he had got working with SLIP
>
> . . . .
>
> A SLIP implementation would be real nice for those of us
> without an ether-net card - or to run at home for nightime mail.
>
> Any chance of that making it to the net???
>
> - Dave Rivers -
Well, unless there is more of a demand than when I last mentioned it,
I don't think that such a large (~350KB) posting is worth the cost
to the net.
However, I am willing to send anyone the NET program (sources and
binaries) along with my modifications to 1.3 MINIX to add an FIONREAD
ioctl() (any other means of implementing non-blocking I/O should work as
well). Just send me a pre-packaged, postage-paid 1.2MB floppy, and I'll
send you just what I sent Desmond Young. Note that this version does
NOT support anything other than SLIP, and that its support of FTP,
TELNET and SMTP is pretty basic. That said, its TCP/IP implementation
seems quite robust; I've used it for several megabytes worth of FTP
transfers and numerous TELNET sessions without a hitch.
If you are interested, E-Mail me and I'll send you my address.
-Ed Hall
edh...@rand.org
..!uunet!edh...@rand.org
..!decvax!randvax!edhall
Stefan Grefen
> Fuller) writes:
> >To a certain extent, yes. A long time ago, I built a program called
> >"screen" on our suns here. I can't remember where I got it, but it
> >does exist and work on machines with BSD support. It's README file
> >begins:
> >
>
> Screen was posted some times ago to the comp.sources.unix group.
>
> Anyone giving me sockets, then I will do the cheap rest...
>
> Jan-Hinrich
>
I've ported it to run under a SysV Rel.3 with 'only' Internet Sockets.
It think it should work with named pipes or straems also.
If don't want disconnecting normal pipes should do.
The only essential thing is to have pty's or a clone device like ptc
and to have a select system call or a pool system call to wait for
multiple handles too become ready.
I've also added a permanent status line for Terminals that have one.
I don't know if MINIX got this features because I have'nt had time to
look at it close enough.
Stefan
Scott Wiesner
system is a useful tool. Just yesterday, I was doing a large build
on my system, when I decided I wanted to run a timing test on something
else. If I had had job control, this would have been a simple matter
of doing a ^Z, running my test, and continuing the build. Instead,
I had to *kill* the build, run my test, and start a new build. It's
just not the same.
Call it a bug or call it a feature. I really don't care. The point
is, a lot of us find it useful. If you don't, fine, but don't tell
me I'm wrong for using it.
Scott Wiesner
Henry Spencer
>This is all just too much. Job control with or without a windowing
>system is a useful tool. Just yesterday, I was doing a large build
>on my system, when I decided I wanted to run a timing test on something
>else. If I had had job control, this would have been a simple matter
Nobody, including me -- please *read* my postings, especially the long
one -- is arguing that the ability to suspend jobs is not useful. But
that is about 2% of job control. The trouble comes when you stir that
together with screen updating and multiplexing, yielding a big mess.
--
NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology
US government is to freedom. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Rahul Dhesi
writes:
>Nobody, including me -- please *read* my postings, especially the long
>one -- is arguing that the ability to suspend jobs is not useful. But
>that is about 2% of job control.
Using csh under 4.3BSD, job control as seen by the user (not the kernel
implementor) is approximately
50% suspending jobs
50% resuming jobs
(This is a very rough approximation. An argument could be made that
one should also include about 4% checking the status of jobs, 1%
posting Usenet articles about it, etc.)
Dermot Tynan
> > Any chance of that making it to the net???
> > - Dave Rivers -
>
> send you just what I sent Desmond Young. Note that this version does
> NOT support anything other than SLIP, and that its support of FTP,
> TELNET and SMTP is pretty basic. That said, its TCP/IP implementation
> seems quite robust; I've used it for several megabytes worth of FTP
> transfers and numerous TELNET sessions without a hitch.
>
Ooops! I think you're somewhat confused, Ed. The original offer was from
Des. That is what they were asking for. Des took the KA9Q code and ported
it to Minix. He got slip working months ago. His latest version supports
Ethernet on a National Semiconductor chipset (the 3-Com board, I believe).
Des is out of town at the moment, so don't expect any replies from him. I
don't know what this 'NET' program you refer to is, but Des' implementation
is very solid, and very complete. He has added a lot of the standard
Berkeley commands to FTP, etc (such as mkdir, chdir, etc). He spent a *lot*
of time fixing things in the Minix kernel, so that it would do what it is
supposed to do. He has been running it on his own machines for a while now,
and by all accounts, it is pretty good. Of course, the final word is his.
If you want to contact him, about distribution or whatever, try:
d...@logic.nsc.com or d...@musashi.UUCP
Either should work. I think he said he'd be back next week...
- Der
--
dty...@altos86.Altos.COM (408) 946-6700 x4237
Dermot Tynan, Altos Computer Systems, San Jose, CA 95134
"Far and few, far and few, are the lands where the Jumblies live..."
edh...@rand.org
We are talking about variants of the same program, here.
Des did not say whether his version of NET (yup, that's what it's
called) still supports SLIP (though it may well); much of his work had
to do with getting it to function with the ethernet interface, and I
suspect that much of the modification he had to do to MINIX was
related to this as well. My version runs SLIP--and only SLIP--with
minimal (~25 lines) modification to MINIX; I've added most of the
features you mention (chdir, etc.).
Some of us are minimalists when it comes to straying from the
``published'' version of MINIX. This was my approach.
Des did offer, in his original posting, to send his version on a 1.2MB
floppy. I assume that this offer still stands. His version is no doubt
solid--probably more solid than mine, though I've yet to have any real
problems--but it is hardly ``complete'' by his own admission (you DID
read his posting, didn't you?). The current version of Phil Karn's
NET program is about twice as big as the largest program that fits
under MINIX (that durn 64K limit).
Just so no one gets confused: Des has added ethernet support and a
moderate amount of kernel reworking for his version of NET. I did
just the minimum necessary to get SLIP going under MINIX, and improved
FTP and SMTP support a bit (though probably not as much as Des).
Neither Des' nor mine is near to being a complete version of NET.
In any case, a poster asked for my version, so I offered it. Nine
people have requested it. If any of those people would rather have
Des' version, just let me--and Des--know.
Henry Spencer
>>Nobody, including me -- please *read* my postings, especially the long
>>one -- is arguing that the ability to suspend jobs is not useful. But
>>that is about 2% of job control.
>
>Using csh under 4.3BSD, job control as seen by the user (not the kernel
The kernel implementor, and the systems programmer in general, is what
I was talking about.
Paul Allen
-In article <71...@xyzzy.UUCP> riv...@dg-rtp.dg.com (Dave Rivers) writes:
-> A SLIP implementation would be real nice for those of us
-> without an ether-net card - or to run at home for nightime mail.
->
-> Any chance of that making it to the net???
-
-Well, unless there is more of a demand than when I last mentioned it,
-I don't think that such a large (~350KB) posting is worth the cost
-to the net.
-
[Offer to put this neat stuff on a floppy if we send him a disk
in a prepaid mailer]
-
-If you are interested, E-Mail me and I'll send you my address.
-
I think that an implementation of tcp/ip for Minix is important
enough that you should post it even if it's 3.5Mb. 350K is
small compared to the 40-part postings one sees from time to
time in the sources newsgroups. I say go for it! Who agrees
with me?
Paul
--
------------------------------------------------------------------------
Paul L. Allen | pal...@atc.boeing.com
Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
Ross Alexander
Yes, go ahead.
--
Ross
Guy Helmer
>-In article <71...@xyzzy.UUCP> riv...@dg-rtp.dg.com (Dave Rivers) writes:
>-> A SLIP implementation would be real nice for those of us
>-> without an ether-net card - or to run at home for nightime mail.
>->
>-> Any chance of that making it to the net???
>-
>-Well, unless there is more of a demand than when I last mentioned it,
>-I don't think that such a large (~350KB) posting is worth the cost
>-to the net.
>-
>[Offer to put this neat stuff on a floppy if we send him a disk
>in a prepaid mailer]
>enough that you should post it even if it's 3.5Mb. 350K is
>small compared to the 40-part postings one sees from time to
>time in the sources newsgroups. I say go for it! Who agrees
>with me?
>
>Paul
-- Guy Helmer BITNET: HELMER@SDNET
Dakota State College AT&T: (605) 256-5315
Madison, SD 57042
Dirk Husemann
Post it! Post it! Post it! Post it! Post it! Post ...
------------------ Smile, tomorrow will be worse! --------------
Email: dkhu...@immd4.informatik.uni-erlangen.de
Or: {pyramid,unido}!fauern!faui49!dkhusema
Mail: Dirk Husemann, Aufsess-Str. 19, D-8520 Erlangen,
(Home) West Germany
(Busi- University of Erlangen-Nuremberg, Computer Science Dep.,
ness) IMMD IV, Martensstr. 1, D-8520 Erlangen, West Germany
Phone: (Home) +49 9131 302036, (Business) +49 9131 857908
-- Beam me up, Scotty, there's no intelligent life down here! --
--------------- My opinions are mine, mine, mine ---------------
Uri Blumenthal
> 350K, if spread out over say a week or ten days, is mere bagatelle.
> Yes, go ahead.
> --
UNIX? What's your opinion, guys? (Well, I mean, it's easier at least, than
to re-write the whole damn thing from scratch...).
Uri.