Not a typewriter - old UNIX error messages.
Paul Grayson
I have a customer who has a Banyan server that someone has managed to
created a filename of the name a:log.txt. This causes the backup system to
barf. On attempting to delete the file using rm (with of without escaping
the colon) I get a message such as the following:-
# rm -f a:log.txt
rm a:log.txt not removed
Not a typewriter
Banyan servers run a modified version of AT&T's PC UNIX system. There is
only one shell available, which appears to be some early Borne shell. I can
delete the file, but only by using fsdb.
I wonder if anyone knows what the origin of this error is? Does it come from
early implementations of Unix? Is its derivation as convoluted as "Values of
beta will give rise to dom!"? Will hooking a Selectric to the serial port
allow me to delete the file? :->
Paul Grayson
># rm -f a:log.txt
>rm a:log.txt not removed
>Not a typewriter
>
Further investigation by means of running strings on rm shows the error is
returned by rm. I have deduced by means of the other error messages in this
dump that the call that rm is making is being returned decimal 25 which
translates as ENOTTY. Obviously the error string comes from the days of
teletypes, and the source hasn't been updated.
But why should rm treat the colon as meaning a TTY device? Was this an old
convention from years ago?
And is there any other currently shipping executable around which still
generate errors of this nature. I am certain that the current release of
VINES (8.5) uses the same set of basic utilities. I will have to snarf a PDP
emulator and try some of the UNIX images to see if those versions of rm
contain the same errors.
J. Benz
Paul Grayson wrote:
In my 20 or so years as a Unix developer, I've seen this message many times. I
don't know what it means, except that it is often returned when dealing with
file names that contain special characters (unprintable) (probably why you need
fsdb to remove the file - next time, try quoting the name). The error is still
there in the most modern Unix versions - on our DEC Alpha version 4.0 OSF, the
following line appears in /usr/include/errno.h
#define ENOTTY 25 /* Not a typewriter */
This machine is only a few months old.
The colon has nothing to do with it - the file name a:log.txt is a perfectly
legal Unix filename and rm doesn't bat an eyelash while sending it to the bit
bucket. You can prove this to yourself by creating a file with that name and
then removing it - both the file creation and the rm command happen without a
squeak.
It's easy to create names with invisible characters too. Any C program can
create any file name out of the entire ASCII character set, excepting shell
metas and other obvious ones like '|' or '/'. You can actually create a name
that is completely invisible. I'll bet your file name was actually something
like 'a:log.txt^M', which in a mixed DROS and Unix environment, is very easy to
do (note the ^M, which is a carriage return) - hmm, there's a hint. Carriage
return is a typewriter thing. Could be 'not a typewriter' is complaining about
'carriage return' - something that has no meaning on a terminal screen.
So here's some detective work for you. A DROS program wrote a file containing
this file name a:log.txt. A Unix program read the file, and used the string
from the file, including the trailing ^M (standard in DROS, but not in Unix), as
a file name. Unix obediently created the file 'a:log.txt^M', which you, being a
human and unable to read invisible text, saw as 'a:log.txt'. And when you said
'rm a:log.txt', the shell correctly interpreted the CR as the end of the name
and fed it to 'rm' as a command line parm. 'rm' in your Banyan implementation
saw the extra char, decided it didn't like it, and spit at you.
James W. Birdsall
>
>
>Paul Grayson wrote:
>
>> ># rm -f a:log.txt
>> >rm a:log.txt not removed
>> >Not a typewriter
>> >
>>
>> Further investigation by means of running strings on rm shows the error is
>> returned by rm. I have deduced by means of the other error messages in this
>> dump that the call that rm is making is being returned decimal 25 which
>> translates as ENOTTY. Obviously the error string comes from the days of
>> teletypes, and the source hasn't been updated.
>
>don't know what it means, except that it is often returned when dealing with
>file names that contain special characters (unprintable) (probably why you need
>fsdb to remove the file - next time, try quoting the name). The error is still
>there in the most modern Unix versions - on our DEC Alpha version 4.0 OSF, the
>following line appears in /usr/include/errno.h
>
>#define ENOTTY 25 /* Not a typewriter */
This has been discussed before. IIRC, the consensus is that 1) ENOTTY is
legitimately returned when attempting to do tty-related operations (certain
ioctls, for example) on file descriptors which are not connected to
tty-like items, and 2) seeing "not a typewriter" in a nonsensical context
means that the programmer was using perror() blindly, without caring
whether the failure actually set errno -- and in this case, it didn't, so
perror() is operating on an old and unrelated value in errno.
Why errno seems to wind up with ENOTTY sitting in it so often is a good
question, though.
--
James W. Birdsall http://www.picarefy.com/~jwbirdsa/ jwbi...@picarefy.com
"For it is the doom of men that they forget." -- Merlin
Get the Sun-2 Hardware Reference from ftp.picarefy.com:/pub/Sun-Hardware-Ref
Sun-2 Hardware Reference Web Page: http://sun-www.picarefy.com/
Jan van den Broek
>Paul Grayson wrote:
>> ># rm -f a:log.txt
>> >rm a:log.txt not removed
>> >Not a typewriter
>> But why should rm treat the colon as meaning a TTY device? Was this an old
>> convention from years ago?
>>
> In my 20 or so years as a Unix developer, I've seen this message many times. I
>don't know what it means, except that it is often returned when dealing with
>file names that contain special characters (unprintable) (probably why you need
>fsdb to remove the file - next time, try quoting the name).
Or try "rm a:*" (assuming that there are no other files starting with "a:").
> The error is still
>there in the most modern Unix versions - on our DEC Alpha version 4.0 OSF, the
>following line appears in /usr/include/errno.h
>#define ENOTTY 25 /* Not a typewriter */
>This machine is only a few months old.
Same in FreeBSD 2.2.5. It's likely that there are programs still running
which are using this error. Removing it from newer version would cause
this programs to be broken.
(However, I'm quit aware you already knew this, you're 15 years or so ahead
of me, I just wanted to point it out).)
--
Rozen verwelken, \--------------------\
Schepen vergaan. \ Jan van den Broek \
Een koe moet je melken, \ balg...@xs4all.nl \
Een paard moet je slaan. \--------------------\
Tony Sweeney
> > The error is still
> >there in the most modern Unix versions - on our DEC Alpha version 4.0 OSF, the
> >following line appears in /usr/include/errno.h
>
> >#define ENOTTY 25 /* Not a typewriter */
>
> >This machine is only a few months old.
>
> Same in FreeBSD 2.2.5. It's likely that there are programs still running
> which are using this error. Removing it from newer version would cause
> this programs to be broken.
>
Solaris is altogether more prosaic:
golem% cat foo.c
# include <stdio.h>
# include <errno.h>
int
main(int argc, char *argv[])
{
printf("%s: %s\n", argv[0], strerror(ENOTTY) );
}
golem% cc foo.c
golem% a.out
a.out: Inappropriate ioctl for device
golem%
Paul Grayson
containing
>this file name a:log.txt. A Unix program read the file, and used the
string
>from the file, including the trailing ^M (standard in DROS, but not in
Unix), as
>a file name. Unix obediently created the file 'a:log.txt^M', which you,
being a
>human and unable to read invisible text, saw as 'a:log.txt'. And when you
said
>'rm a:log.txt', the shell correctly interpreted the CR as the end of the
name
>and fed it to 'rm' as a command line parm. 'rm' in your Banyan
implementation
>saw the extra char, decided it didn't like it, and spit at you.
The problem appears to be with rm handling filenames with colons in them - I
have created numerous files with colons in them, including one consisting of
just a colon. rm fails on all with the same error. There are no extra
control characters.
Anyway, fsdb nukes them all - and other bits of the disk too.
Kalle Niemitalo
> And is there any other currently shipping executable around which still
> generate errors of this nature.
I've seen the same message on Linux/i386 when running this command:
lsattr /dev
--
Kalle Olavi Niemitalo <to...@stekt.oulu.fi>, http://stekt.oulu.fi/~tosi/
J.H.M. Dassen
>Not a typewriter
>I wonder if anyone knows what the origin of this error is? Does it come
>from early implementations of Unix?
Very probably. Even recent Unices still have it
(/usr/include/asm/errno.h on Linux:
#define ENOTTY 25 /* Not a typewriter */
).
"dict tty" comes up with a reasonable definition, that includes
: 2. (Especially {Unix}) Any terminal at all; sometimes used to refer to
: the particular terminal controlling a given job (it is also the name
: of a Unix command which outputs the name of the current controlling
: terminal).
Ray
--
Cyberspace, a final frontier. These are the voyages of my messages,
on a lightspeed mission to explore strange new systems and to boldly go
where no data has gone before.
George R. Gonzalez
This is the same message we used to get on a certain rainbow-fruit flavor
of Unix.
If you sent mail to someone whose mailbox was slightly scrozzled, youd
get back a msg:
theirname - not a typewriter.
Once in a while it would say "judy - not a typewriter" which was locally
amusing as judy was our secretary, and her fingers were almost always
clicking away on a Selectric.
Tom Tom Harrington
>The problem appears to be with rm handling filenames with colons in them - I
>have created numerous files with colons in them, including one consisting of
>just a colon. rm fails on all with the same error. There are no extra
>control characters.
Must be a broken implementation, then. Solaris doesn't seem to mind:
$ touch a:b
$ ls -l a:b
-rw-rw-r-- 1 tph 0 Sep 23 12:28 a:b
$ rm a:b
$ ls -l a:b
a:b not found
--
Tom "Tom" Harrington ----- t...@rmi.net ----- http://rainbow.rmi.net/~tph
use Perl || die;
Cookie's Revenge: ftp://ftp.rmi.net/pub2/tph/cr/cookies-revenge.sit.hqx
David K Cornutt
>
> In article <3608a...@news.saqnet.co.uk>, "Paul Grayson" wrote:
> >The problem appears to be with rm handling filenames with colons in them - I
> >have created numerous files with colons in them, including one consisting of
> >just a colon. rm fails on all with the same error. There are no extra
> >control characters.
>
> Must be a broken implementation, then. Solaris doesn't seem to mind:
Here's my pet theory:
Actually I think Paul may have inadvertently hit on what the problem may
be.
The notation "foo:bar" is a syntax that was originally adopted by the
BSD "r-tools" to specify doing things with files on other nodes, as in:
rcp myfile.x frankenix:archive/myfile.x
which would copy myfile.x to a directory called archive on
a network node called "frankenix".
Now, I've never heard of "normal" Unix command utilities being
implemented to recognize the r-tools syntax. But is it possible that
some gonzo programmer on this particular version of the system
implemented rm as an r-tool? Maybe it's going out onto the net
trying to find a node called "a" and delete a file called "log.txt"
there. Presuming that there isn't a node on the network named "a",
then maybe rm at that point is trying to a socket-type operation
on something that isn't a connected socket, and getting the ENOTTY
error. (I didn't realize, though, that there were still systems out
there whose perror() routines still translate ENOTTY to the text
"not a typewriter".)
What ENOTTY means is that an attempt to do an ioctl() was done on
a file or device that doesn't support that particular type of ioctl.
Back in the bad old days, only serial port drivers supported ioctl's,
and so the error was originally defined as "not a serial port"
(since there was nothing else to do an ioctl on). And since back
in the bad old days the device connected to a serial port was nearly
always a Teletype or something of its ilk, the "not a typewriter"
translation of ENOTTY evolved.
Can you use "mv" to rename the file to something that doesn't
have a colon in it?
--
David K. Cornutt, Residentially Engineered, Huntsville, AL
Advice from the B-29 pilot's manual, on dropping cargo via parachute:
"CAUTION: Do not attach static line to any part of one's body when
throwing equipment through the opening."
Longi
: This is the same message we used to get on a certain rainbow-fruit flavor
: of Unix.
: If you sent mail to someone whose mailbox was slightly scrozzled, youd
: get back a msg:
: theirname - not a typewriter.
We used to hack the source to say "not a washing machine", someone on the
UNIX-HATER mailing list had "not a bicycle".
AT&T - You Will (Take Acid).
There was a version of Amix (Commodore's Unix for the Amiga 3000UX) that
came out with some other amusing lines as well.
--
lo...@sekurity.org - In the flesh, on the phone, and in your account. - BOFH
Paul Grayson
>have a colon in it?
No - that fails with a cannot unlink error message.
Paul Grayson
>Actually I think Paul may have inadvertently hit on what the problem may
>be.
>The notation "foo:bar" is a syntax that was originally adopted by the
>BSD "r-tools" to specify doing things with files on other nodes, as in:
>
>rcp myfile.x frankenix:archive/myfile.x
>
..snip..
Very plausible. Banyan VINES is an almost dead UNIX based Network operating
system. It is possible that there was some attempt to perform remote file
operations. There is an undocumented remote copy deamon that appears to be
only avaiable to maintenance personel - it can only be created if the
correct activation code or option dongle is used. Perhaps the rm was to be
used with this? Also the underlying OS is a very old PC based Unix
originally sourced from AT&T which has not really changed in many years, and
Banyan only appear to recompile the standard utilities only when needed.
Peter Seebach
James W. Birdsall <jwbi...@picarefy.picarefy.com> wrote:
> Why errno seems to wind up with ENOTTY sitting in it so often is a good
>question, though.
When stdio opens a stream it typically ioctl's to see whether it's a TTY
(and thus line buffered) or not (and thus fully buffered), so it gets ENOTTY.
-s
--
Copyright 1998, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Seeking interesting programming projects. Not interested in commuting.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Peter Seebach
Longi <lo...@sekurity.org> wrote:
>There was a version of Amix (Commodore's Unix for the Amiga 3000UX) that
>came out with some other amusing lines as well.
What were these? I loved my Amiga Unix box. :)
Tony Sweeney
>
> It's easy to create names with invisible characters too. Any C program can
> create any file name out of the entire ASCII character set, excepting shell
> metas and other obvious ones like '|' or '/'.
The _only_ characters unix forbid are the '/' and the nul ('\0'). The slash
because it is the directory separator, and the nul because it is the end of string
marker. Everything else is allowed, including eight bit characters on som systems,
like the Sun Ultra 2 I'm typing this on.
Tony.
David Simpson
<pgra...@cns.co.uk> wrote:
>
>># rm -f a:log.txt
>>rm a:log.txt not removed
>>Not a typewriter
>>
>
>
>Further investigation by means of running strings on rm shows the error is
>returned by rm. I have deduced by means of the other error messages in this
>dump that the call that rm is making is being returned decimal 25 which
>translates as ENOTTY. Obviously the error string comes from the days of
>teletypes, and the source hasn't been updated.
>
>But why should rm treat the colon as meaning a TTY device? Was this an old
>convention from years ago?
>
The CP/M OS and early MSDOS treated the trailing colon as a device
character. A: was the first disk drive, PRN: was the printer. PRN:
could be attached to LPT: (x is number of port) or COM: CON: was the
console consisting of keyboard and screen. Later MSDOS allowed the
trailing colon to be dropped from PRN. I don't know why this
convention was instigated. Gary Kildall was a programmer so he was
probably following the convention of whatever hardware he was using at
the same time he wrote CP/M in circa 1974.
David Simpson d...@picknowl.com.au
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Anatomy: Something that everybody has, but it looks better on a girl.
chris 'fufas' grace
David Simpson wrote in message <360d5dad...@news.picknowl.com.au>...
>The CP/M OS and early MSDOS treated the trailing colon as a device
>character. A: was the first disk drive, PRN: was the printer. PRN:
>could be attached to LPT: (x is number of port) or COM: CON: was the
>console consisting of keyboard and screen. Later MSDOS allowed the
>trailing colon to be dropped from PRN. I don't know why this
>convention was instigated. Gary Kildall was a programmer so he was
>probably following the convention of whatever hardware he was using at
>the same time he wrote CP/M in circa 1974.
It was quite widespread. the Atari 400 and 800 used the same convention,
(with the interesting feature that the screen could be used as an input
device), and I'm almost certain that the Commodores did as well, although
I never owned one of those and am relying on memory here.
Peter van Hooft
>>So here's some detective work for you. A DROS program wrote a file
>containing
>>this file name a:log.txt. A Unix program read the file, and used the
>string
>>from the file, including the trailing ^M (standard in DROS, but not in
>Unix), as
>>a file name. Unix obediently created the file 'a:log.txt^M', which you,
>being a
>>human and unable to read invisible text, saw as 'a:log.txt'. And when you
>said
>>'rm a:log.txt', the shell correctly interpreted the CR as the end of the
>name
>>and fed it to 'rm' as a command line parm. 'rm' in your Banyan
>implementation
>>saw the extra char, decided it didn't like it, and spit at you.
>The problem appears to be with rm handling filenames with colons in them - I
>have created numerous files with colons in them, including one consisting of
>just a colon. rm fails on all with the same error. There are no extra
>control characters.
You are not using unix, then. As has been mentioned before, unix doesn't
care what characters are used for a filename, except for / and the NUL
character.
>Anyway, fsdb nukes them all - and other bits of the disk too.
If you have to use fsdb often, your system is very, _very_ broken.
peter
J. Benz
Luc Van der Veken wrote:
> Unix doesn't mind, but I know for sure that the version of bash
> I'm using doesn't require spaces as delimiters around redirection
> characters '>', '<' and '|' (well, you can still quote them - but
> I'd probably forget to do that half the time).
>
> Quotation characters can be used for quoting a name, but when you
> try to include them in a filename:
>
> fo"o.ba"r
> is evaluated as
> foo.bar
>
> and
>
> fo"o.bar
> is evaluated as the C style string
> "foo.bar\n" (at least I think the \n is included)
> after which a continuation line is started, because the closing "
> is missing.
The shell isn't Unix. Especially bash. Try building a C program which uses
the example file names you mention. Shells do a lot of pre-digesting of your
input before passing it off to Unix - and bash isn't even part of a standard
Unix release.
John D. Burleson
>
>
> Quotation characters can be used for quoting a name, but when you
> try to include them in a filename:
>
> fo"o.ba"r
> is evaluated as
> foo.bar
This is because you are trying incorrectly. Both
fo\".ba\"r
and
'fo"o.ba"r'
will yield a file name with embedded double quotes. You need to
remember that the shell parser will gobble those quotes _before_ the
token is interpreted as a filename.
>
> and
>
> fo"o.bar
> is evaluated as the C style string
> "foo.bar\n" (at least I think the \n is included)
> after which a continuation line is started, because the closing "
> is missing.
This is true for Bourne shell derivatives, the csh family will produce
an error unless you escape the newline with a backslash, IIRC.
john
Paul Grayson
>care what characters are used for a filename, except for / and the NUL
>character.
Oh yes I am. The unix filesystem itself does not care, but shells and other
applications may. In this case rm is treating the colon in a special way,
and may be attempting to perform some form of remote procedure call.
There is something odd about this implementation of rm. I don't have access
to a C compiler on this system, and therefore cannot try compiling the GNU
version of rm. An earlier version of VINES does not have this problem with
rm, though. The bug was introduced sometime between 1993 and 1996 as far as
I can tell. Installing later releases of the software should help me
pinpoint exactly when it happened. I did attempt to install a copy from
1990, but cannot find a platform that will not cause a kernel panic when
reading the harddisk.
Peter van Hooft
>Also sprach ho...@natlab.research.philips.com (Peter van Hooft)
>on Sat, 26 Sep 1998 18:23:44 GMT to alt.folklore.computers:
>> You are not using unix, then. As has been mentioned before, unix doesn't
>> care what characters are used for a filename, except for / and the NUL
>> character.
>Yes and no, I think (and btw, what variety of unix do you call
>unix?)
Any descendant of the operating system created by Thomson and
Ritchie?
>I know it's not exactly unix, but it's the only manual I have
>within reach - this comes from the Coherent manual:
>" Any character can be used to name a file, including a control
> character. It is recommended, however, that you name files
> using only upper- or lower-case alphabetic characters,
> numerals, and the puctuation marks '.' or '_'.
>"
Well, the first is clearly wrong. You can't use / and nul (although
there was a version of the cap software that _would_ create
filenames with / in it, probably by hacking it in the kernel,
creating interesting problems. The recommendation is reasonable,
except I wouldn't mind the usage of for example the hyphen and %.
>Unix doesn't mind, but I know for sure that the version of bash
>I'm using doesn't require spaces as delimiters around redirection
>characters '>', '<' and '|' (well, you can still quote them - but
>I'd probably forget to do that half the time).
>Quotation characters can be used for quoting a name, but when you
>try to include them in a filename:
> fo"o.ba"r
>is evaluated as
> foo.bar
>and
> fo"o.bar
>is evaluated as the C style string
> "foo.bar\n" (at least I think the \n is included)
>after which a continuation line is started, because the closing "
>is missing.
Yup. Depending on the shell you're using, special characters in
filenames can prove interesting.
peter
Tom Harrington
: >and
: peter
--
Tom Harrington --------- t...@rmii.com -------- http://rainbow.rmii.com/~tph
"...one can get high scores on intelligence tests, but still be unable
to think for one's self." -Revelation X: The "Bob" Apocryphon
Cookie's Revenge: ftp://ftp.rmi.net/pub2/tph/cookie/cookies-revenge.sit.hqx
Tom Harrington
: In <360e384...@news.innet.be> luc...@null.net (Luc Van der Veken) writes:
: >Also sprach ho...@natlab.research.philips.com (Peter van Hooft)
: >on Sat, 26 Sep 1998 18:23:44 GMT to alt.folklore.computers:
: >> You are not using unix, then. As has been mentioned before, unix doesn't
: >> care what characters are used for a filename, except for / and the NUL
: >> character.
: >Yes and no, I think (and btw, what variety of unix do you call
: >unix?)
: Any descendant of the operating system created by Thomson and
: Ritchie?
This doesn't seem like a very good test. Does any current Unix include
code actually written by Thomson and/or Ritchie? And if a Unix
implementation is free of code written by those two, why would its
position on the Unix family tree give it some special status?
If all the code has at some point been rewritten or reimplemented,
then it would seem that it's no more a "true" Unix than systems
completely outside of the Thomson/Ritchie realm like Linux.
Trademark issues aside, it would seem that the important details
are in how a system works, rather than the question of whether a
tenuous descendancy from the original Unix can be established.
FreeBSD has no original Thomson/Ritchie code, for example; does
its ancestry, completely aside from operational issues, make it
more of a Unix than Linux?
--
Tom Harrington --------- t...@rmii.com -------- http://rainbow.rmii.com/~tph
"If you think there is a solution, you're part of the problem." -Zippy
Samael
Tom Harrington wrote in message <6vdctf$cp...@eccws1.dearborn.ford.com>...
I was under the impression that Linux was a Unix variant.
I would say that a Unix is defined by its conformance to the Unix API and
command set.
Samael
Sam Hayes Merritt, III
wrote:
I know I will rot for this one.
>I was under the impression that Linux was a Unix variant.
I was under the impression that it mimics the form and function of a
UNIX system. (http://www.unix-systems.org/what_is_unix/).
>I would say that a Unix is defined by its conformance to the Unix API and
>command set.
unix like, yes. Unix... no. Trademarks are a pain.
Sam Hayes Merritt, III
General Panic
>On Tue, 6 Oct 1998 17:20:10 +0100, "Samael" <sam...@dial.pipex.com>
>wrote:
>
>I know I will rot for this one.
>
>>I was under the impression that Linux was a Unix variant.
>
>I was under the impression that it mimics the form and function of a
>UNIX system. (http://www.unix-systems.org/what_is_unix/).
According to that page the *BSD(I) stuff ain't Unix either.
These are:
* Digital UNIX
* IBM OS/390 OpenEdition
* IBM RS6000 Software
* SCO UnixWare
* SUN Solaris
And Hewlett-Packard's HP-UX would qualify too.
Of these I've used HP-UX and Solaris; I recall the ISP
that used Solaris didn't buy the C compiler -- after
we complained a couple months they installed GCC!
>>I would say that a Unix is defined by its conformance to
>>the Unix API and command set.
>
>unix like, yes. Unix... no.
Even if an OS comes with vi? :-}
> Trademarks are a pain.
So is *paying* for an OS, which I *won't* do.
ObAFC: What's next for the "unixoid" type o' thing, like what
new features/capabilities will it have? (I'm asking for
speculations and educated guesses, not trade secrets!)
David
Tom Harrington
: Sam Hayes Merritt, III <har...@feeding.frenzy.com> wrote:
: >On Tue, 6 Oct 1998 17:20:10 +0100, "Samael" <sam...@dial.pipex.com>
: >wrote:
: >
: >I know I will rot for this one.
: >
: >>I was under the impression that Linux was a Unix variant.
: >
: >I was under the impression that it mimics the form and function of a
: >UNIX system. (http://www.unix-systems.org/what_is_unix/).
But this begs the question: How closely does it need to "mimic" Unix
before it becomes indistinguishable from the real thing? That page
gives no hint as to where Linux might fail in being a real Unix.
: According to that page the *BSD(I) stuff ain't Unix either.
They've also got a financial interest in describing Linux as not being a
"real" Unix system. You can't use the Unix trademark unless you pay the
Open Group somewhere between $25,000 and $110,000 per year. The exact
fee depends on the number of copies sold, which raises the question of
whether a free system could ever qualify. Describing Linux and BSDI as
non-Unix systems is part of protecting the trademark. BSDI is, as they
say, "not a UNIX system", but this has more to do with the fact that
they haven't bought the trademark than with any operational questions.
They never do address the question of what _else_ might separate Linux
and BSDI from the trademarked Unixes. The implication seems to be that
either of them could be Unix if someone came up with the money.
: >>I would say that a Unix is defined by its conformance to
: >>the Unix API and command set.
: >
: >unix like, yes. Unix... no.
But the more Unix-like a system becomes, the harder it is to draw a line
separating it from Unix. I'd agree that there's more to it than APIs
and commands, but if you keep updating an OS to make it more and more
Unix-like, it would seem that eventually it _is_ Unix, or could be if
you get it close enough. Functionally, that is. Trademark issues are
another matter. No system is ever UNIX (tm) unless they pay for the
name.
BTW, the term "Unix-like" is "an abuse of the UNIX trademark, and should
not be used...", according to the Open Group.
--
Tom Harrington --------- t...@rmii.com -------- http://rainbow.rmii.com/~tph
"That which does not kill me makes me stranger." -Larry Wall
Clinton Pierce
t...@longhorn.uucp (Tom Harrington) writes:
>
>BTW, the term "Unix-like" is "an abuse of the UNIX trademark, and should
>not be used...", according to the Open Group.
>
IMHO, the Open Group is an abuse of the UNIX trademark, and should not
be used.
--
+------------------------------------------------------------------------+
| Clinton A. Pierce | "If you rush a Miracle Man, | http://www. |
| cpie...@ford.com | you get rotten miracles" | dcicorp.com/ |
| fu...@ameritech.net |--Miracle Max, The Princess Bride| ~clintp |
+------------------------------------------------------------------------+
GCSd-s+:+a-C++UALIS++++P+++L++E---t++X+b+++DI++++G++e+>++h----r+++y+++>y*
David Wragg
> But this begs the question: How closely does it need to "mimic" Unix
> before it becomes indistinguishable from the real thing? That page
> gives no hint as to where Linux might fail in being a real Unix.
So would Linux pass a "Turix test"
Dave Wragg
lis...@zetnet.co.uk
On 1998-10-09 t...@rmi.net said:
:BTW, the term "Unix-like" is "an abuse of the UNIX trademark, and
:should not be used...", according to the Open Group.
Hmm... perhaps we should all start referring to Linux as "like that
operating system which we can't name because its trademark is owned by
the greedy bastards in the Open Group who keep playing dog-in-the-manger
with a name that started out as a bad pun and has about as much right to
be a trademark as 386"... if it's not too big a mouthful...
--
Communa (so sue) we remember... we'll see you falling
you know soft spoken changes nothing to sing within her...
Neil Franklin
>
> Hmm... perhaps we should all start referring to Linux as "like that
> operating system which we can't name because its trademark is owned by
> the greedy bastards in the Open Group who keep playing dog-in-the-manger
> with a name that started out as a bad pun and has about as much right to
> be a trademark as 386"... if it's not too big a mouthful...
User error: dumping core. Retch.
Why not follow the suggestion in someone heres sig block?
Refer to Linux as Linux (everyone knows waht that is) and the rest as
Linux-like OSes?
--
*** New home Addresses Mail and Web ***
home: ne...@franklin.ch.remove http://neil.franklin.ch/
work: fran...@arch.ethz.ch.remove http://caad.arch.ethz.ch/~franklin/
Microsoft is Software Communism, Fight for GNU Freedom!
Tom Harrington
: lis...@zetnet.co.uk writes:
: >
: > Hmm... perhaps we should all start referring to Linux as "like that
: > operating system which we can't name because its trademark is owned by
: > the greedy bastards in the Open Group who keep playing dog-in-the-manger
: > with a name that started out as a bad pun and has about as much right to
: > be a trademark as 386"... if it's not too big a mouthful...
"The operating systems formerly known as Unix"?
: User error: dumping core. Retch.
If you think that one quote is retch-worthy, you should see the official
trademark usage guidelines....
Fortunately they don't seem to take enforcement too seriously. A quick
check at the OpenBSD and FreeBSD web pages confirms that both are each
described as being Unix, even though they're (of course) not Open Group-
approved.
: Why not follow the suggestion in someone heres sig block?
: Refer to Linux as Linux (everyone knows waht that is) and the rest as
: Linux-like OSes?
As tempting as that is, I'm not partisan enough to want to piss off the
*BSD crown that much. I do like the idea of describing Open Group-branded
Unix systems as, by definition, costly Linux-like operating systems.
Maybe if we referred to official "Unix (tm)" products as either Linux-
like systems or BSD-like, depending on personal preference.
--
Tom Harrington --------- t...@rmii.com -------- http://rainbow.rmii.com/~tph
"I know syllables and I use them in almost every word."
-Steve Winter (stev...@ix.netcom.com)
Kevin Schoedel
> : lis...@zetnet.co.uk writes:
> : >
> : > Hmm... perhaps we should all start referring to Linux as "like that
> : > operating system which we can't name because its trademark is owned by
> : > the greedy bastards in the Open Group who keep playing dog-in-the-manger
> : > with a name that started out as a bad pun and has about as much right to
> : > be a trademark as 386"... if it's not too big a mouthful...
>
> "The operating systems formerly known as Unix"?
Wonderful! My *BSD-slanted rendering of this (as a 3K gif) is at
<URL:http://www.kw.igs.net/~schoedel/formerly.html>.
--
Kevin Schoedel
fpub...@xj.vtf.arg
Tom Harrington
Probably, an BSDI and the various free *BSD implementations probably
would too.
But "Turix" sounds like Unix, implemented on a Turing machine. :-)
--
Tom Harrington --------- t...@rmii.com -------- http://rainbow.rmii.com/~tph
"Television commercials are a form of religious literature."
-Neil Postman
Hannu Rummukainen
> But "Turix" sounds like Unix, implemented on a Turing machine. :-)
Has anyone implemented a C compiler for a Turing machine?
After that, it wouldn't be that hard to implement Unix as well...
Hannu Rummukainen
Foobar T. Clown
>
> Has anyone implemented a C compiler for a Turing machine?
Would that be a compiler that reads a C program as its input and writes
a Turing machine as its output? Or would that be a Turing machine that
reads a C program from its tape and replaces it with the byte codes for
some processor?
> After that, it wouldn't be that hard to implement Unix as well...
O.K., Here's what I'm picturing. The tape initially contains a
description of the entire state of a virtual Unix box -- memory, disks,
the works -- followed by a sequence of inputs. After the turning
machine halts, the tape contains the new state that the box would be in
after processing the given input.
It's just a small matter of programming.
Martin Ibert
>FreeBSD has no original Thomson/Ritchie code, for example; does
>its ancestry, completely aside from operational issues, make it
>more of a Unix than Linux?
Yes, I would say it does. For example, your body replaces all cells
every seven years or so. So you (assuming you are considerably older
than 7 years) probably don't contain a single cell from your original
body (the body you had as a new-born baby).
Aren't you still the same person, just a later (so to speak) "version"
of it?
--
Please visit http://www.snafu.de/~martini/ for contact information!
-------------------------------------------------------------------
|Blind faith in your leaders, or in anything, will get you killed!|
Wilson Roberto Afonso
Martin Ibert wrote:
>
> Yes, I would say it does. For example, your body replaces all cells
> every seven years or so. So you (assuming you are considerably older
> than 7 years) probably don't contain a single cell from your original
> body (the body you had as a new-born baby).
> Aren't you still the same person, just a later (so to speak) "version"
> of it?
That rule does not apply to neurons, and I'd say they do a lot to define
one's identity...
-Wilson
Peter Seebach
Martin Ibert <mar...@heaven7.snafu.de> wrote:
>Yes, I would say it does. For example, your body replaces all cells
>every seven years or so.
Please, post this kind of thing to alt.folklore.urban, not around here.
It's obviously untrue. (Neural tissue doesn't replace so much, and I'm
not particularly sure about bones.)
-s
--
Copyright 1998, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Seeking interesting programming projects. Not interested in commuting.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Tom E Arnold
>
> Maybe if we referred to official "Unix (tm)" products as either Linux-
> like systems or BSD-like, depending on personal preference.
>
--
TEA/
My current neighborhood: http://www.coldspringpark.org
My next neighborhood: http://www.geocities.com/athens/acropolis/9361
`David O'Lantern'
Is this true? And if so whatever happened to the code?
Was it replaced or rewritten beyond recognition?
David
--
"Academia is intellectual foot-binding. Tenure is an anagram for neuter."
--Roly Poly Man, on alt.angst
Dave Vandervies
<thed...@tsoft.com> wrote:
>>>FreeBSD has no original Thomson/Ritchie code
>
>Is this true? And if so whatever happened to the code?
>Was it replaced or rewritten beyond recognition?
I could be wrong (Somebody please correct me if I am), but I think
that the way it worked was that the BSD versions got hacked on by
several contributors and the ``BSD'' version of Unix was distributed
as a free patch to the AT&T version (for which you had to pay license
fees), until somebody realized that there was very little AT&T code
left in the BSD version and a project was launched to redo the parts
of the system that contained the AT&T code so that the entire BSD
system could be distributed freely.
Warren Toomey
`David O'Lantern' <thed...@tsoft.com> writes:
|> >>FreeBSD has no original Thomson/Ritchie code
|>
|> Is this true? And if so whatever happened to the code?
|> Was it replaced or rewritten beyond recognition?
Correct. If you consider that V6 was the last Ritchie/Thompson UNIX
(well, the last that they put their names to), then we have
time ---------------------------------->
replacement of original code ---------->
V6--V7--32V--3BSD---4.0BSD-------------------4.4BSD
\ \ \
Net/1 Net/2 4.4BSD-Lite
\ \
FreeBSD 1.x---FreeBSD 2.X and 3.X
Rough percentages of original code left:
100 10 2-3 0 in 4.4BSD-Lite
Where did the original source go? It fell into the bit bucket at
http://minnie.cs.adfa.oz.au/PUPS/ I have a BIG bit bucket :-)
Cheers,
Warren
Sergej Roytman
Dave Vandervies <daveva#earthling.net> wrote:
>On Mon, 02 Nov 1998 01:04:59 GMT, `David O'Lantern'
><thed...@tsoft.com> wrote:
>>Is this true? And if so whatever happened to the code?
>>Was it replaced or rewritten beyond recognition?
>that the way it worked was that the BSD versions got hacked on by
>several contributors and the ``BSD'' version of Unix was distributed
>as a free patch to the AT&T version (for which you had to pay license
>fees), until somebody realized that there was very little AT&T code
>left in the BSD version and a project was launched to redo the parts
>of the system that contained the AT&T code so that the entire BSD
>system could be distributed freely.
So, FreeBSD is _not_ a clone like Minix or Linux, but the real live
Berkley code, complete with little daemon dude? Cool!
--
Sergej Roytman
Peter Seebach
Sergej Roytman <ft...@engin.umich.edu> wrote:
>So, FreeBSD is _not_ a clone like Minix or Linux, but the real live
>Berkley code, complete with little daemon dude? Cool!
Yes. Same with NetBSD and OpenBSD, as well as the commercial relative
(the black sheep?), BSD/OS.
Disclaimer: I work for BSDi some of the time, and they're a great company,
with a great product.
Wait, that's not a disclaimer.
David O'Bedlam
> So, FreeBSD is _not_ a clone like Minix or Linux
GRRR. I'm holding my virtual tongue.
David
--
"I overstate things to stay alive." -- a Don DeLillo character
David O'Bedlam
So how do FreeBSD, OpenBSD, NetBSD and BSDi's BSD/OS differ?
If this is too complicated or time-consuming to answer here
feel free to email me relevant documents -- I've got a generous
disk quota.
David O'Bedlam
So, hey DENNIS RITCHIE, which OS do you use nowadays, and why?
(I don't expect to get an answer for this frivolous question.)
Peter Seebach
David O'Bedlam <thed...@tsoft.com> wrote:
>So how do FreeBSD, OpenBSD, NetBSD and BSDi's BSD/OS differ?
Well, they're maintained by different people, with different goals.
Way back when, BSD/OS went commercial, and FreeBSD didn't. I believe
the next split was that FreeBSD wanted to make the best possible x86
Unix-like system, and NetBSD wanted to work on multiple ports. (Since
then, NetBSD has made many improvements similar to the ones FreeBSD has
made, and FreeBSD has begun approaching ports to other systems.) Later,
OpenBSD split from NetBSD, once again over design philosophies.
My characterization is that, of the free systems, FreeBSD will generally
be the best performing on the 80x86, and NetBSD is the most portable.
OpenBSD, well, I guess it's a lot like NetBSD in my book, but they're
putting more effort into security fixes.
BSD/OS is aimed more specifically at features ISP's care about. BSD/OS
is really fairly usable "out of the box". (I've done support for them,
so I have some clue how easy it is to get running.) Web server included
and mostly configured, sendmail configured, etc.
Currently, I feel BSD/OS has the best support. Not to trivialize the
support offerings for NetBSD (which, as it happens, I'm the only one of
that I've seen), but BSDI's support team (which I have worked for about
a year of total employment-time in the past) has more people, better
engineering support, and the like. They're a *good* support team. It's
not like the big famous Unix vendors, it's people who actually know the
product and know the kinds of problems people run into.
If I do say so myself. ;)
-s
--
Copyright 1998, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Send me money - get cool programs and hardware! No commuting, please.
J.H.M. Dassen (Ray)
Check out http://www.dejanews.com/getdoc.xp?AN=408976248 .
HTH,
Ray
--
J.H.M. Dassen | RUMOUR Believe all you hear. Your world may
jda...@wi.LeidenUniv.nl | not be a better one than the one the blocks
| live in but it'll be a sight more vivid.
| - The Hipcrime Vocab by Chad C. Mulligan
Andrey Mirtchovski
David O'Bedlam wrote:
> So, hey DENNIS RITCHIE, which OS do you use nowadays, and why?
>
> (I don't expect to get an answer for this frivolous question.)
>
> David
> --
> "I overstate things to stay alive." -- a Don DeLillo character
I believe Dennis Ritchie is using/working on the old/new project that
has been ongoing for quite awhile - plan9 (as in "plan 9 from
bell-labs).
This is supposedly the successor of UNIX, having very little in common
with it. One of the interesting ideas that caught me is the lack of a
_superuser_ or _root_ in the OS :)
If you are interested - plan9.bell-labs.com or for more specialized FAQ
and some inside disscussions - comp.os.plan9
Have a nice day...
Andrey
P.S. I even tried to install the 4 disk distro of Plan9 that was
available and managed to run it, but due to a HDD crash (not caused by
P9) I abandoned my *research* in that area and went back to studying
linux :)
Hope I'm not boring you too much... ;)
Warren Toomey
David O'Bedlam <thed...@tsoft.com> writes:
|> Sergej Roytman <ft...@engin.umich.edu> wrote:
|> > So, FreeBSD is _not_ a clone like Minix or Linux
|> GRRR. I'm holding my virtual tongue.
8-)
FreeBSD is not a clone in the sense that it wasn't written entirely
from scratch, but is derived through a tortuous path from the UNIX
written by Thompson, Ritchie et al. Nonetheless, there is the same
amount of `real'[1] UNIX code in FreeBSD, Minix and Linux: none.
[1] `real' UNIX: that phrase is enough to start a thread of its own.
I offer several alternative definitions:
1. The last version of UNIX that had Ken and Dennis' name on it:
Sixth Edition.
2. The last research version of UNIX before AT&T began to bring out
real commercial versions: Seventh Edition / 32V.
3. Whatever the current owners of the System V source code want to
call UNIX.
4. That undefinable UNIX nature which is so eloquently described in
the various papers from Bell Labs in the 70's, and which has been
so difficult to nail down into a real standard. Call this the Zen
definition of UNIX.
There, that ought to have fed the fires a little :-)
Warren
---
Leave only one s in my mail address
James W. Adams
Warren Toomey <w...@css.adfa.oz.au> wrote:
>In article <V2Q12.127$G45....@news14.ispnews.com>,
> David O'Bedlam <thed...@tsoft.com> writes:
>|> Sergej Roytman <ft...@engin.umich.edu> wrote:
>|> > So, FreeBSD is _not_ a clone like Minix or Linux
>|> GRRR. I'm holding my virtual tongue.
>
>8-)
>FreeBSD is not a clone in the sense that it wasn't written entirely
>from scratch, but is derived through a tortuous path from the UNIX
>written by Thompson, Ritchie et al. Nonetheless, there is the same
>amount of `real'[1] UNIX code in FreeBSD, Minix and Linux: none.
By this point, such arguments are meaningless. Perhaps the last
relevant definition was something which required an AT&T source
license. After that, "UNIX" became a loosely defined de facto
interface definition, at least outside BTL.
By this point every flavor of "UNIX" has replaced the original AT&T
source, and there is no common source tree to define "real" UNIX.
This is like a bunch of great-grandchildren of adoptees arguing over
who is a "real" member of the family.
--
James W. Adams -- jamesa @ cstone.net <-- remove spaces
"I became obsessed with angels and ballerinas,
things of grace and beauty, otherworldly."
Charlottesville, VA 22903 --C. Love
Sergej Roytman
David O'Bedlam <thed...@tsoft.com> wrote:
>Sergej Roytman <ft...@engin.umich.edu> wrote:
>> So, FreeBSD is _not_ a clone like Minix or Linux
>GRRR. I'm holding my virtual tongue.
"GRRR"? Wherefor?
--
Sergej Roytman
Matthew Crosby
James W. Adams <jad...@NO.SPAM.PLEASE> wrote:
>By this point every flavor of "UNIX" has replaced the original AT&T
>source, and there is no common source tree to define "real" UNIX.
Just out of curiosity, in order to see how true this statement actually
is, I just dug up the v7 source code for ed and compared it to that of
Solaris. (Which is presumebly basically straight from sysV, but I don't
have access to a vanilla sys V source tree)
There have definately been changes, for example it has been converted to
ansi C and given locale support, but a lot of it is clearly the same
code. There are a number of functons that are completely identical
except for the declaration.
So I suspect a better statement would be:
"By this point every flavor of "UNIX" has replaced the much of the original
AT&T source, and there is no common source tree to define "real" UNIX."
More interestingly, I tried compileing the v7 ed under solaris with
gcc, and the only problem (aside from warnings caused by lack of typcasts)
is that the semantics of mktmp seem to have completely changed. Once I
fixed that it runs as far as I can see perfectly. Pretty good demo of Unix
portability.
--
Matthew Crosby cro...@cs.colorado.edu
Disclaimer: It was in another country, and besides, the wench is dead.
ca...@jps.net
<aam...@mail.usask.ca> wrote:
Dennis Ritchie had very little (read:zip) to do with plan9. It was
written by a group of young people at Lucent - Rob Pike, Philip
Winterbottom most notably. There was a little input from ken.
James W. Adams
Matthew Crosby <cro...@nag.cs.colorado.edu> wrote:
>In article <72cd9k$m...@jamesa.cstone.net>,
>James W. Adams <jad...@NO.SPAM.PLEASE> wrote:
>>By this point every flavor of "UNIX" has replaced the original AT&T
>>source, and there is no common source tree to define "real" UNIX.
>
>Just out of curiosity, in order to see how true this statement actually
>is, I just dug up the v7 source code for ed and compared it to that of
>Solaris. (Which is presumebly basically straight from sysV, but I don't
>have access to a vanilla sys V source tree)
>
>There have definately been changes, for example it has been converted to
>ansi C and given locale support, but a lot of it is clearly the same
>code. There are a number of functons that are completely identical
>except for the declaration.
Solaris 2.x is derived from SVR4.0. There are few critical elements of
the OS in Solaris 7 which could by any reasonable criterion be considered
"clearly the same code" as any AT&T-branded version of UNIX, particularly
any one prior to 32/V which is the parent of 4.xBSD, which in turn was
the parent of FreeBSD.
If you did a reasonable comparison of the entire codebase, such as was
done between 4.[34]BSD and 32/V in the course of the lawsuit, I think
you will find that any remaining commonality is trivial at best.
The C code for "hello world" is essentially identical on every system.
The philosophical issue was whether FreeBSD is somehow more "Real UNIX"
than, say, LINUX.
In this context, the entire notion of "Real UNIX" is essentially
meaningless.
Peter Maydell
Matthew Crosby <cro...@nag.cs.colorado.edu> wrote:
>gcc, and the only problem (aside from warnings caused by lack of typcasts)
>is that the semantics of mktmp seem to have completely changed. Once I
>fixed that it runs as far as I can see perfectly. Pretty good demo of Unix
>portability.
On the other hand, for a good example of unix *non*-portability, try
the same trick with the v7 Bourne shell :->
Peter Maydell
Dennis Ritchie
> Dennis Ritchie had very little (read:zip) to do with plan9. It was
> written by a group of young people at Lucent - Rob Pike, Philip
> Winterbottom most notably. There was a little input from ken.
>
Well, I gave them money, so to speak, but OK. Ken had much more
to do with Plan 9 than is evident; it really started with
his discussions with Rob about 9P, and Ken wrote the C compilers,
the linker, and the file server, as well as much of earlier
versions of the OS code. That's more than a little. Philw
was a later (though quite vigorous) contributor, along with Pike,
Presotto and others.
Don't hassle me about posting news from Netscape. Just
behind the NS window is a giant one that's the display
for a Plan 9 CPU server.
Dennis
Eric Fischer
> More interestingly, I tried compileing the v7 ed under solaris with
> gcc, and the only problem (aside from warnings caused by lack of typcasts)
> is that the semantics of mktmp seem to have completely changed. Once I
> fixed that it runs as far as I can see perfectly. Pretty good demo of Unix
> portability.
Even the v6 version isn't too hard to port to current systems if you go
through it and change all the =+ operators to += to conform to modern C
syntax. (The v5 version is in assembler, so I haven't attempted to get
it running.) The effort to get v6 ed to work also makes it possible to
try out very early versions of vi, if that's your idea of fun.
eric
Matthew Crosby
James W. Adams <jad...@NO.SPAM.PLEASE> wrote:
>Matthew Crosby <cro...@nag.cs.colorado.edu> wrote:
>>James W. Adams <jad...@NO.SPAM.PLEASE> wrote:
>>>By this point every flavor of "UNIX" has replaced the original AT&T
>>>source, and there is no common source tree to define "real" UNIX.
>>
>>
>>There have definately been changes, for example it has been converted to
>>ansi C and given locale support, but a lot of it is clearly the same
>>code. There are a number of functons that are completely identical
>>except for the declaration.
>
>Solaris 2.x is derived from SVR4.0. There are few critical elements of
>the OS in Solaris 7 which could by any reasonable criterion be considered
>"clearly the same code" as any AT&T-branded version of UNIX, particularly
>any one prior to 32/V which is the parent of 4.xBSD, which in turn was
>the parent of FreeBSD.
>
>If you did a reasonable comparison of the entire codebase, such as was
>done between 4.[34]BSD and 32/V in the course of the lawsuit, I think
>you will find that any remaining commonality is trivial at best.
I wouldn't argue this for a millisecond. However, I was pointing out
that there IS still code in common. The fact that it is very little
code, and completely trivial, is irrelevent, it's still there. I'm
also perfectly cogniscent that sun rewrote most of the Sys V kernel,
for example. But there is still a very small connection. Just like
we share DNA with a very distant relative. Versus Linux, which
has zero descent.
Imagine comparing a planeria, a human, and some hypothetical martian
life form that happened to have evolved bisymmetry, opposable thumbs and a
brain like organism in a protrusion at the top of it's body. There is
clearly a (very distant) relationship between the planeria and the human.
There is zero relation between the martian and the human, EVEN THOUGH
the Martian and the human look much closer then the Planeria. That's all
I'm pointing out. As it happens I agree with you that Linux probably has
as much claim to the title "Unix" as Solaris; I'm just disagreeing that
you can't find any descent from the original Bell Labs code in the latter.
>The C code for "hello world" is essentially identical on every system.
...but this is somewhat more identical. We are talking about many
identical function names, probably at least a couple of hundred lines where
diff shows nothing. It's distant, but it's still there. If I really cared
I'm sure I could dig up some other places where the code is the same. Small,
irrelevent, but still there.
b...@nashville.com
: In article <V2Q12.127$G45....@news14.ispnews.com>,
: "GRRR"? Wherefor?
If you believe what Tannenbaum wrote in his book, Minix has no AT&T code in
it, although he did have a Version 7 work-alike in mind when he wrote Minix.
Since the source to Minix is published, this is an easy thing to verify.
Linux has no AT&T code in it either. Ditto on verification.
Sergej Roytman
>Sergej Roytman (ft...@engin.umich.edu) wrote:
>: In article <V2Q12.127$G45....@news14.ispnews.com>,
>: David O'Bedlam <thed...@tsoft.com> wrote:
>: >Sergej Roytman <ft...@engin.umich.edu> wrote:
>: >> So, FreeBSD is _not_ a clone like Minix or Linux
>: >GRRR. I'm holding my virtual tongue.
>: "GRRR"? Wherefor?
>If you believe what Tannenbaum wrote in his book, Minix has no AT&T
Hm, OK. I believe what Tannenbaum wrote, because as I recall Minix
uses message-passing to do [kernel-interface-type stuff---should
re-read T.'s OS book] and Unix doesn't. What I meant by "clone" was,
something that presents the same appearence but is implemented
differently. Perhaps I selected the wrong word.
>Linux has no AT&T code in it either.
No.
> Ditto on verification.
Verification?
A quick look through a Web-site or two turned up the history of
FreeBSD: the Real Original BSD, with all the remaining AT&T parts re-
written to avoid copyright problems. And heir to the little daemon
dude from all the old BSD books. Linux, I knew, came from Linus and
his kernel that printed a string of 'a's and 'b's.
--
Sergej Roytman
Eric Fischer
> FreeBSD: the Real Original BSD, with all the remaining AT&T parts re-
> written to avoid copyright problems.
Not quite all rewritten, as this notice from sys/kern/tty.c will demonstrate:
* (c) UNIX System Laboratories, Inc.
* All or some portions of this file are derived from material licensed
* to the University of California by American Telephone and Telegraph
* Co. or Unix System Laboratories, Inc. and are reproduced herein with
* the permission of UNIX System Laboratories, Inc.
eric