Tech Insider					     Technology and Trends

			      USENET Archives

Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!seismo!mcvax!botter!ast
From: a...@botter.UUCP
Newsgroups: comp.os.minix
Subject: Misc. comments and a proposed protocol
Message-ID: <>
Date: Fri, 6-Mar-87 17:26:49 EST
Article-I.D.: botter.1089
Posted: Fri Mar  6 17:26:49 1987
Date-Received: Sun, 8-Mar-87 16:29:08 EST
Reply-To: (Andy Tanenbaum)
Distribution: world
Organization: VU Informatica, Amsterdam
Lines: 110

For those of you who don't subscribe to news.groups, Brian Reid of DEC 
collects statistics on USENET.  Sites send him reports about groups read
locally, and he has software that prints the TOP 40 and BOTTOM 20 in
order of readership, traffic, etc.  These reports are posted monthly.
For February, comp.os.minix was # 36 in readership out of 224 news groups.
There are an estimated 10,000 readers worldwide, which ties it with  Within one month of its inception, MINIX has become as
popular as sex.  The drawing of conclusions is left as an exercise for the 

Let me explain the command line limit problem exactly.  It was explained in
an earlier posting by someone else, but it wasn't quite right (but it was
close).  The logical way to handle the exec system call in MINIX would be
to pass the arg and envp pointers to MM and let it fetch all the args and
strings.  This is slow in MINIX, so I wrote exec(2) to build the initial
stack frame inside the calling program, and just send a pointer to it to
MM.  MM Then picks it up in one operations.  The buffer in which the initial
stack frame is built is 1K.  This means that a command like "ls *.c" in a
directory with a few hundred .c files will generate more argument strings
than fit in 1K, and the exec call fails, so the shell says ls: can't execute.
The fix is to make the 1K buffer into a 2K buffer, and fix the size in MM.
This makes all programs using exec 1K larger.  I didn't think it was worth
it, but if you want to change it, now you know how.

I haven't finished checking out the new -i flag to asld to support separate
I & D space, but so far it seems to work.  I have compiled the whole
operating system with kernel, MM, and FS using -i and it works.  I will keep
testing it and when I am done will distribute the new asld binary.

P-H has promised me that that they will be shipping diskettes by March 13.
Sorry it has taken so long to get geared up.  You wouldn't believe how
complicated it is.  P-H has farmed the manufacturing out.  One company does
the diskettes, another does the diskette labels, another does the plastic
box they come in, ...  

As large numbers of people get the code, people will find bugs.  
I would like to propose a bug protocol to make the reporting and fixing of
bugs less confusing.

1.  If you find a bug in the file prog.c, post a message with subject line:
    Report of bug in prog.c

2.  If you have a fix to some bug (including a bug that you yourself are
    reporting), make the subject line:
    Fix to bug in prog.c

3.  Only one bug report per posting.  Many people will keep the bug reports
    in mailboxes.  By typing h a to msg you get a list of all the subject
    lines, so with these conventions it will be easy to find things.

4.  Once a bug fix has been reported, it would be nice to have it referreed,
    like journal articles.  If you feel like installing a fix and testing it,
    by all means do so, and then report back with a posting, one bug per
    posting, with the subject line like:
    Smith's fix to prog.c is ok

    Smith's fix to prog.c doesn't work

    The body of the message can be quite short, telling, for example, on
    what machine you tried it, if that is relevant (e.g., for a printer
    driver fix, which printer you used).  After you have seen half a dozen
    people confirm that Smith's fix is indeed correct, don't post any more
    confirmations.  When testing a fixed program, be sure to test all its
    features and options, because the fix may correct one bug but introduce
    another one.

6.  UNIROT has offered space for an archive.  I would suggest that only
    fixes refereed in the above way be archived.  It would be nice if the
    machine could have an archive server that works like Brian Reid's server.  You send it the bug number and it sends you a
    message containing the bug report, the fixes, and the referees reports.
    Bug 0 should be a list of all the subject lines of the bug reports,
    numbered with their archive number.  If any one else wants to run an
    archive service like this, it would be very useful. Anyone interested
    should ask Brian Reid about the availability of his archiving software.
    It is very clever, with automatic features to prevent any one person
    from using up too much bandwidth (the more you request, the worse your
    response time, and breaking up a big request into many little requests
    doesn't help).  His address is

7.  As MINIX gets distributed, it would be very helpful to have people report
    on their experiences on various clones.  A subject line like:
    MINIX on the Southern Wombat 1000
    would be appropriate here.  In these reports, tell what you configuration
    is, how many megahertz you have, printer type, etc.  Anyone interested in
    collecting these and posting the results as a nice clean table later?
    I have gotten hundreds of pieces of mail on MINIX, and many queries about
    whether it works on some particular machine.  I rarely know, but at some
    point if we have a single file telling where it works and where it doesn't
    I am sure that would be helpful.

I am going for an airplane ride again.  I will be keynote speaker at the
Sixth Symposium on Reliability in Distributed Software and Database Systems
in Williamsburg Va. on March 18.  That talk will be about "Reliability in ..."
I am also going to be at Georgia Tech March 10, Yale March 12, and Stony
Brook March 16.  When I get back on March 20, I am going to France a couple
of hours later.  Conclusion:  I won't be answering any mail until April,
and if my previous trip is any guide, the overflow bit on my mailbox will be
set when I get back.  

For those of you going to the EUUG conference, I will also be keynote speaker
there on May 13.  That talk will be about MINIX.  The EUUG conference will be
held on a boat sailing between Helsinki and Stockholm.  This will be one of
the few UNIX conferences with its own taxfree shop selling intoxicating
beverages.  If the talks get boring, you can go get drunk.  Stockholm and
Helsinki are both beautiful cities and well worth visiting.

Andy Tanenbaum (

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or

Electronic mail:			       WorldWideWeb: