home *** CD-ROM | disk | FTP | other *** search
/ ftp.muug.mb.ca / 2014.06.ftp.muug.mb.ca.tar / ftp.muug.mb.ca / pub / src / old-linux / info / linux-history < prev    next >
Text File  |  1993-03-12  |  26KB  |  549 lines

  1. To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  2. From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  3. Subject: Birthday (was Re: Uptime found.  Thanks to all)
  4. Date: 31 Jul 92 22:15:20 GMT
  5.  
  6. In article <1992Jul30.211132.20101@cc.umontreal.ca> duperval@ERE.UMontreal.CA (Duperval Laurent) writes:
  7. >
  8. >P.S.  BTW, noone answered yet:  when is Linux's birthday?  Let's have a
  9. >party!
  10.  
  11. I couldn't for the life of me remember when it all happened, and I don't
  12. keep a diary, so I can't give you any exact dates for when linux "was
  13. born".  But I did start to wonder, so I started ftp'ing around for
  14. archives of the comp.os.minix group (where I announced it), and this is
  15. what I came up with (with some editing). 
  16.  
  17. This is just a sentimental journey into some of the first posts
  18. concerning linux, so you can happily press 'n' now if you actually
  19. thought you'd get anything technical. 
  20.  
  21. > From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  22. > Newsgroups: comp.os.minix
  23. > Subject: Gcc-1.40 and a posix-question
  24. > Message-ID: <1991Jul3.100050.9886@klaava.Helsinki.FI>
  25. > Date: 3 Jul 91 10:00:50 GMT
  26. > Hello netlanders,
  27. > Due to a project I'm working on (in minix), I'm interested in the posix
  28. > standard definition. Could somebody please point me to a (preferably)
  29. > machine-readable format of the latest posix rules? Ftp-sites would be
  30. > nice.
  31.  
  32. The project was obviously linux, so by July 3rd I had started to think
  33. about actual user-level things: some of the device drivers were ready,
  34. and the harddisk actually worked.  Not too much else. 
  35.  
  36. > As an aside for all using gcc on minix - [ deleted ]
  37.  
  38. Just a success-report on porting gcc-1.40 to minix using the 1.37
  39. version made by Alan W Black & co.
  40.  
  41. >               Linus Torvalds          torvalds@kruuna.helsinki.fi
  42. > PS. Could someone please try to finger me from overseas, as I've
  43. > installed a "changing .plan" (made by your's truly), and I'm not certain
  44. > it works from outside? It should report a new .plan every time.
  45.  
  46. So I was clueless - had just learned about named pipes.  Sue me.  This
  47. part of the post got a lot more response than the actual POSIX query,
  48. but the query did lure out arl from the woodwork, and we mailed around
  49. for a bit, resulting in the Linux subdirectory on nic.funet.fi. 
  50.  
  51. Then, almost two months later, I actually had something working: I made
  52. sources for version 0.01 available on nic sometimes around this time. 
  53. 0.01 sources weren't actually runnable: they were just a token gesture
  54. to arl who had probably started to despair about ever getting anything. 
  55. This next post must have been from just a couple of weeks before that
  56. release. 
  57.  
  58. > From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  59. > Newsgroups: comp.os.minix
  60. > Subject: What would you like to see most in minix?
  61. > Summary: small poll for my new operating system
  62. > Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>
  63. > Date: 25 Aug 91 20:57:08 GMT
  64. > Organization: University of Helsinki
  65. > Hello everybody out there using minix -
  66. > I'm doing a (free) operating system (just a hobby, won't be big and
  67. > professional like gnu) for 386(486) AT clones.  This has been brewing
  68. > since april, and is starting to get ready.  I'd like any feedback on
  69. > things people like/dislike in minix, as my OS resembles it somewhat
  70. > (same physical layout of the file-system (due to practical reasons)
  71. > among other things). 
  72. > I've currently ported bash(1.08) and gcc(1.40), and things seem to work. 
  73. > This implies that I'll get something practical within a few months, and
  74. > I'd like to know what features most people would want.  Any suggestions
  75. > are welcome, but I won't promise I'll implement them :-)
  76. >               Linus (torvalds@kruuna.helsinki.fi)
  77. > PS.  Yes - it's free of any minix code, and it has a multi-threaded fs. 
  78. > It is NOT protable (uses 386 task switching etc), and it probably never
  79. > will support anything other than AT-harddisks, as that's all I have :-(. 
  80.  
  81. Judging from the post, 0.01 wasn't actually out yet, but it's close. I'd
  82. guess the first version went out in the middle of September -91. I got
  83. some responses to this (most by mail, which I haven't saved), and I even
  84. got a few mails asking to be beta-testers for linux.
  85.  
  86. After that just a few general answers to quesions on the net:
  87.  
  88. > From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  89. > Newsgroups: comp.os.minix
  90. > Subject: Re: What would you like to see most in minix?
  91. > Summary: yes - it's nonportable
  92. > Message-ID: <1991Aug26.110602.19446@klaava.Helsinki.FI>
  93. > Date: 26 Aug 91 11:06:02 GMT
  94. > Organization: University of Helsinki
  95. > In article <1991Aug25.234450.22562@nntp.hut.fi> jkp@cs.HUT.FI (Jyrki Kuoppala) writes:
  96. > >> [re: my post about my new OS]
  97. > >
  98. > >Tell us more!  Does it need a MMU?
  99. > Yes, it needs a MMU (sorry everybody), and it specifically needs a
  100. > 386/486 MMU (see later).
  101. > >
  102. > >>PS.  Yes - it's free of any minix code, and it has a multi-threaded fs. 
  103. > >>It is NOT protable (uses 386 task switching etc)
  104. > >
  105. > >How much of it is in C?  What difficulties will there be in porting?
  106. > >Nobody will believe you about non-portability ;-), and I for one would
  107. > >like to port it to my Amiga (Mach needs a MMU and Minix is not free).
  108. > Simply, I'd say that porting is impossible.  It's mostly in C, but most
  109. > people wouldn't call what I write C.  It uses every conceivable feature
  110. > of the 386 I could find, as it was also a project to teach me about the
  111. > 386.  As already mentioned, it uses a MMU, for both paging (not to disk
  112. > yet) and segmentation. It's the segmentation that makes it REALLY 386
  113. > dependent (every task has a 64Mb segment for code & data - max 64 tasks
  114. > in 4Gb. Anybody who needs more than 64Mb/task - tough cookies).
  115. > It also uses every feature of gcc I could find, specifically the __asm__
  116. > directive, so that I wouldn't need so much assembly language objects.
  117. > Some of my "C"-files (specifically mm.c) are almost as much assembler as
  118. > C. It would be "interesting" even to port it to another compiler (though
  119. > why anybody would want to use anything other than gcc is a mystery).
  120.  
  121. [ editors note: linux has in fact gotten more portable with newer
  122. versions: there was a lot more assembly in the early versions.  Not that
  123. anybody in their right mind would try to port it even now ]
  124.  
  125. > Unlike minix, I also happen to LIKE interrupts, so interrupts are
  126. > handled without trying to hide the reason behind them (I especially like
  127. > my hard-disk-driver.  Anybody else make interrupts drive a state-
  128. > machine?).  All in all it's a porters nightmare. 
  129. > >As for the features; well, pseudo ttys, BSD sockets, user-mode
  130. > >filesystems (so I can say cat /dev/tcp/kruuna.helsinki.fi/finger),
  131. > >window size in the tty structure, system calls capable of supporting
  132. > >POSIX.1.  Oh, and bsd-style long file names.
  133. > Most of these seem possible (the tty structure already has stubs for
  134. > window size), except maybe for the user-mode filesystems. As to POSIX,
  135. > I'd be delighted to have it, but posix wants money for their papers, so
  136. > that's not currently an option. In any case these are things that won't
  137. > be supported for some time yet (first I'll make it a simple minix- 
  138. > lookalike, keyword SIMPLE).
  139. >               Linus (torvalds@kruuna.helsinki.fi)
  140. > PS. To make things really clear - yes I can run gcc on it, and bash, and
  141. > most of the gnu [bin/file]utilities, but it's not very debugged, and the
  142. > library is really minimal. It doesn't even support floppy-disks yet. It
  143. > won't be ready for distribution for a couple of months. Even then it
  144. > probably won't be able to do much more than minix, and much less in some
  145. > respects. It will be free though (probably under gnu-license or similar).
  146.  
  147. Well, obviously something worked on my machine: I doubt I had yet gotten
  148. gcc to compile itself under linux (or I would have been too proud of it
  149. not to mention it).  Still before any release-date. 
  150.  
  151. Then, October 5th, I seem to have released 0.02.  As I already
  152. mentioned, 0.01 didn't actually come with any binaries: it was just
  153. source code for people interested in what linux looked like.  Note the
  154. lack of announcement for 0.01: I wasn't too proud of it, so I think I
  155. only sent a note to everybody who had shown interest. 
  156.  
  157. > From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  158. > Newsgroups: comp.os.minix
  159. > Subject: Free minix-like kernel sources for 386-AT
  160. > Message-ID: <1991Oct5.054106.4647@klaava.Helsinki.FI>
  161. > Date: 5 Oct 91 05:41:06 GMT
  162. > Organization: University of Helsinki
  163. > Do you pine for the nice days of minix-1.1, when men were men and wrote
  164. > their own device drivers? Are you without a nice project and just dying
  165. > to cut your teeth on a OS you can try to modify for your needs? Are you
  166. > finding it frustrating when everything works on minix? No more all-
  167. > nighters to get a nifty program working? Then this post might be just
  168. > for you :-)
  169. > As I mentioned a month(?) ago, I'm working on a free version of a
  170. > minix-lookalike for AT-386 computers.  It has finally reached the stage
  171. > where it's even usable (though may not be depending on what you want),
  172. > and I am willing to put out the sources for wider distribution.  It is
  173. > just version 0.02 (+1 (very small) patch already), but I've successfully
  174. > run bash/gcc/gnu-make/gnu-sed/compress etc under it. 
  175. > Sources for this pet project of mine can be found at nic.funet.fi
  176. > (128.214.6.100) in the directory /pub/OS/Linux.  The directory also
  177. > contains some README-file and a couple of binaries to work under linux
  178. > (bash, update and gcc, what more can you ask for :-).  Full kernel
  179. > source is provided, as no minix code has been used.  Library sources are
  180. > only partially free, so that cannot be distributed currently.  The
  181. > system is able to compile "as-is" and has been known to work.  Heh. 
  182. > Sources to the binaries (bash and gcc) can be found at the same place in
  183. > /pub/gnu. 
  184. > ALERT! WARNING! NOTE! These sources still need minix-386 to be compiled
  185. > (and gcc-1.40, possibly 1.37.1, haven't tested), and you need minix to
  186. > set it up if you want to run it, so it is not yet a standalone system
  187. > for those of you without minix. I'm working on it. You also need to be
  188. > something of a hacker to set it up (?), so for those hoping for an
  189. > alternative to minix-386, please ignore me. It is currently meant for
  190. > hackers interested in operating systems and 386's with access to minix.
  191. > The system needs an AT-compatible harddisk (IDE is fine) and EGA/VGA. If
  192. > you are still interested, please ftp the README/RELNOTES, and/or mail me
  193. > for additional info.
  194. > I can (well, almost) hear you asking yourselves "why?".  Hurd will be
  195. > out in a year (or two, or next month, who knows), and I've already got
  196. > minix.  This is a program for hackers by a hacker.  I've enjouyed doing
  197. > it, and somebody might enjoy looking at it and even modifying it for
  198. > their own needs.  It is still small enough to understand, use and
  199. > modify, and I'm looking forward to any comments you might have. 
  200. > I'm also interested in hearing from anybody who has written any of the
  201. > utilities/library functions for minix. If your efforts are freely
  202. > distributable (under copyright or even public domain), I'd like to hear
  203. > from you, so I can add them to the system. I'm using Earl Chews estdio
  204. > right now (thanks for a nice and working system Earl), and similar works
  205. > will be very wellcome. Your (C)'s will of course be left intact. Drop me
  206. > a line if you are willing to let me use your code.
  207. >               Linus
  208. > PS. to PHIL NELSON! I'm unable to get through to you, and keep getting
  209. > "forward error - strawberry unknown domain" or something.
  210.  
  211. Well, it doesn't sound like much of a system, does it? It did work, and
  212. some people even tried it out. There were several bad bugs (and there
  213. was no floppy-driver, no VM, no nothing), and 0.02 wasn't really very
  214. useable.
  215.  
  216. 0.03 got released shortly thereafter (max 2-3 weeks was the time between
  217. releases even back then), and 0.03 was pretty useable. The next version
  218. was numbered 0.10, as things actually started to work pretty well. The
  219. next post gives some idea of what had happened in two months more...
  220.  
  221. > From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  222. > Newsgroups: comp.os.minix
  223. > Subject: Re: Status of LINUX?
  224. > Summary: Still in beta
  225. > Message-ID: <1991Dec19.233545.8114@klaava.Helsinki.FI>
  226. > Date: 19 Dec 91 23:35:45 GMT
  227. > Organization: University of Helsinki
  228. > In article <469@htsa.htsa.aha.nl> miquels@maestro.htsa.aha.nl (Miquel van Smoorenburg) writes:
  229. > >Hello *,
  230. > >     I know some people are working on a FREE O/S for the 386/486,
  231. > >under the name Linux. I checked nic.funet.fi now and then, to see what was
  232. > >happening. However, for the time being I am without FTP access so I don't
  233. > >know what is going on at the moment. Could someone please inform me about it?
  234. > >It's maybe best to follow up to this article, as I think that there are
  235. > >a lot of potential interested people reading this group. Note, that I don't
  236. > >really *have* a >= 386, but I'm sure in time I will.
  237. > Linux is still in beta (although available for brave souls by ftp), and
  238. > has reached the version 0.11.  It's still not as comprehensive as
  239. > 386-minix, but better in some respects.  The "Linux info-sheet" should
  240. > be posted here some day by the person that keeps that up to date.  In
  241. > the meantime, I'll give some small pointers.
  242. > First the bad news:
  243. >       - Still no SCSI: people are working on that, but no date yet. 
  244. >         Thus you need a AT-interface disk (I have one report that it
  245. >         works on an EISA 486 with a SCSI disk that emulates the
  246. >         AT-interface, but that's more of a fluke than anything else:
  247. >         ISA+AT-disk is currently the hardware setup)
  248.  
  249. As you can see, 0.11 had already a small following. It wasn't much, but
  250. it did work.
  251.  
  252. >       - still no init/login: you get into bash as root upon bootup.
  253.  
  254. That was still standard in the next release.
  255.  
  256. >       - although I have a somewhat working VM (paging to disk), it's not
  257. >         ready yet.  Thus linux needs at least 4M to be able to run the
  258. >         GNU binaries (especially gcc).  It boots up in 2M, but you
  259. >         cannot compile. 
  260.  
  261. I actually released a 0.11+VM version just before Christmas -91: I
  262. didn't need it myself, but people were trying to compile the kernel in
  263. 2MB and failing, so I had to implement it. The 0.11+VM version was
  264. available only to a small number of people that wanted to test it out:
  265. I'm still surprised it worked as well as it did.
  266.  
  267. >       - minix still has a lot more users: better support.
  268. >       - it hasn't got years of testing by thousands of people, so there
  269. >         are probably quite a few bugs yet. 
  270. > Then for the good things..
  271. >       - It's free (copyright by me, but freely distributable under a
  272. >         very lenient copyright)
  273.  
  274. The early copyright was in fact much more restrictive than the GNU
  275. copyleft: I didn't allow any money at all to change hands due to linux. 
  276. That changed with 0.12. 
  277.  
  278. >       - it's fun to hack on.
  279. >       - /real/ multithreading filesystem.
  280. >       - uses the 386-features.  Thus locked into the 386/486 family, but
  281. >         it makes things clearer when you don't have to cater to other
  282. >         chips. 
  283. >       - a lot more... read my .plan.
  284. > /I/ think it's better than minix, but I'm a bit prejudiced.  It will
  285. > never be the kind of professional OS that Hurd will be (in the next
  286. > century or so :), but it's a nice learning tool (even more so than
  287. > minix, IMHO), and it was/is fun working on it. 
  288. >               Linus (torvalds@kruuna.helsinki.fi)
  289. > ---- my .plan --------------------------
  290. >       Free UNIX for the 386 - coming 4QR 91 or 1QR 92.
  291. > The current version of linux is 0.11 - it has most things a unix kernel
  292. > needs, and will probably be released as 1.0 as soon as it gets a little
  293. > more testing, and we can get a init/login going. Currently you get
  294. > dumped into a shell as root upon bootup.
  295. > Linux can be gotten by anonymous ftp from 'nic.funet.fi' (128.214.6.100)
  296. > in the directory '/pub/OS/Linux'.  The same directory also contains some
  297. > binary files to run under Linux.  Currently gcc, bash, update, uemacs,
  298. > tar, make and fileutils.  Several people have gotten a running system,
  299. > but it's still a hackers kernel. 
  300. > Linux still requires a AT-compatible disk to be useful: people are
  301. > working on a SCSI-driver, but I don't know when it will be ready.
  302. > There are now a couple of other sites containing linux, as people have
  303. > had difficulties with connecting to nic. The sites are:
  304. >       Tupac-Amaru.Informatik.RWTH-Aachen.DE (137.226.112.31):
  305. >               directory /pub/msdos/replace
  306. >       tsx-11.mit.edu (18.172.1.2):
  307. >               directory /pub/linux
  308. > There is also a mailing list set up 'Linux-activists@niksula.hut.fi'. 
  309. > To join, mail a request to 'Linux-activists-request@niksula.hut.fi'. 
  310. > It's no use mailing me: I have no actual contact with the mailing-list
  311. > (other than being on it, naturally).
  312. > Mail me for more info:
  313. >               Linus (torvalds@kruuna.Helsinki.FI)
  314. > 0.11 has these new things:
  315. > - demand loading
  316. > - code/data sharing between unrelated processes
  317. > - much better floppy drivers (they actually work mostly)
  318. > - bug-corrections
  319. > - support for Hercules/MDA/CGA/EGA/VGA
  320. > - the console also beeps (WoW! Wonder-kernel :-)
  321. > - mkfs/fsck/fdisk
  322. > - US/German/French/Finnish keyboards
  323. > - settable line-speeds for com1/2
  324.  
  325. As you can see: 0.11 was actually stand-alone: I wrote the first
  326. mkfs/fsck/fdisk programs for it, so that you didn't need minix any more
  327. to set it up. Also, serial lines had been hard-coded to 2400bps, as that
  328. was all I had.
  329.  
  330. > Still lacking:
  331. > - init/login
  332. > - rename system call
  333. > - named pipes
  334. > - symbolic links
  335.  
  336. Well, they are all there now: init/login didn't quite make it to 0.12,
  337. and rename() was implemented as a patch somewhere between 0.12 and 0.95.
  338. Symlinks were in 0.95, but named pipes didn't make it until 0.96.
  339.  
  340. > 0.12 will probably be out in January (15th or so), and will have:
  341. > - POSIX job control (by tytso)
  342. > - VM (paging to disk)
  343. > - Minor corrections
  344.  
  345. Actually, 0.12 was out January 5th, and contained major corrections.  It
  346. was in fact a very stable kernel: it worked on a lot of new hardware,
  347. and there was no need for patches for a long time.  0.12 was also the
  348. kernel that "made it": that's when linux started to spread a lot faster. 
  349. Earlier kernel releases were very much only for hackers: 0.12 actually
  350. worked quite well.
  351.  
  352. That's all I found for 1991 - maybe it answered some questions.
  353.  
  354.                 Linus
  355.  
  356. -----------------------------------------------------------------------------
  357.  
  358. To: Linux-Activists@BLOOM-PICAYUNE.MIT.EDU
  359. From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  360. Subject: Re: Writing an OS - questions !!
  361. Date: 5 May 92 07:58:17 GMT
  362.  
  363. In article <10685@inews.intel.com> nani@td2cad.intel.com (V. Narayanan) writes:
  364. >
  365. >Hi folks,
  366. >        For quite some time this "novice" has been wondering as to how one goes
  367. >about the task of writing an OS from "scratch".  So here are some questions,
  368. >and I would appreciate if you could take time to answer 'em.
  369.  
  370. Well, I see someone else already answered, but I thought I'd take on the
  371. linux-specific parts.  Just my personal experiences, and I don't know
  372. how normal those are.
  373.  
  374. >1) How would you typically debug the kernel during the development phase?
  375.  
  376. Depends on both the machine and how far you have gotten on the kernel:
  377. on more simple systems it's generally easier to set up. Here's what I
  378. had to do on a 386 in protected mode.
  379.  
  380. The worst part is starting off: after you have even a minimal system you
  381. can use printf etc, but moving to protected mode on a 386 isn't fun,
  382. especially if you at first don't know the architecture very well.  It's
  383. distressingly easy to reboot the system at this stage: if the 386
  384. notices something is wrong, it shuts down and reboots - you don't even
  385. get a chance to see what's wrong.
  386.  
  387. Printf() isn't very useful - a reboot also clears the screen, and
  388. anyway, you have to have access to video-mem, which might fail if your
  389. segments are incorrect etc.  Don't even think about debuggers: no
  390. debugger I know of can follow a 386 into protected mode.  A 386 emulator
  391. might do the job, or some heavy hardware, but that isn't usually
  392. feasible.
  393.  
  394. What I used was a simple killing-loop: I put in statements like
  395.  
  396. die:
  397.         jmp die
  398.  
  399. at strategic places.  If it locked up, you were ok, if it rebooted, you
  400. knew at least it happened before the die-loop.  Alternatively, you might
  401. use the sound io ports for some sound-clues, but as I had no experience
  402. with PC hardware, I didn't even use that.  I'm not saying this is the
  403. only way: I didn't start off to write a kernel, I just wanted to explore
  404. the 386 task-switching primitives etc, and that's how I started off (in
  405. about April-91).
  406.  
  407. After you have a minimal system up and can use the screen for output, it
  408. gets a bit easier, but that's when you have to enable interrupts. Bang,
  409. instant reboot, and back to the old way. All in all, it took about 2
  410. months for me to get all the 386 things pretty well sorted out so that I
  411. no longer had to count on avoiding rebooting at once, and having the
  412. basic things set up (paging, timer-interrupt and a simple task-switcher
  413. to test out the segments etc).
  414.  
  415. >2) Can you test the kernel functionality by running it as a process on a
  416. >   different OS?  Wouldn't the OS(the development environment) generate
  417. >   exceptions in cases when the kernel (of the new OS) tries to modify
  418. >   'priviledged' registers?
  419.  
  420. Yes, it's generally possible for some things, but eg device drivers
  421. usually have to be tested out on the bare machine.  I used minix to
  422. develop linux, so I had no access to IO registers, interrupts etc. 
  423. Under DOS it would have been possible to get access to all these, but
  424. then you don't have 32-bit mode.  Intel isn't that great - it would
  425. probably have been much easier on a 68040 or similar. 
  426.  
  427. So after getting a simple task-switcher (it switched between two
  428. processes that printed AAAA...  and BBBB...  respectively by using the
  429. timer-interrupt - Gods I was proud over that), I still had to continue
  430. debugging basically by using printf.  The first thing written was the
  431. keyboard driver: that's the reason it's still written completely in
  432. assembler (I didn't dare move to C yet - I was still debugging at
  433. about instruction-level). 
  434.  
  435. After that I wrote the serial drivers, and voila, I had a simple
  436. terminal program running (well, not that simple actually).  It was still
  437. the same two processes (AAA..), but now they read and wrote to the
  438. console/serial lines instead.  I had to reboot to get out of it all, but
  439. it was a simple kernel.
  440.  
  441. After that is was plain sailing: hairy coding still, but I had some
  442. devices, and debugging was easier.  I started using C at this stage, and
  443. it certainly speeds up developement.  This is also when I start to get
  444. serious about my megalomaniac ideas to make "a better minix that minix". 
  445. I was hoping I'd be able to recompile gcc under linux some day... 
  446.  
  447. The harddisk driver was more of the same: this time the problems with
  448. bad documentation started to crop up.  The PC may be the most used
  449. architecture in the world right now, but that doesn't mean the docs are
  450. any better: in fact I haven't seen /any/ book even mentioning the weird
  451. 386-387 coupling in an AT etc (Thanks Bruce). 
  452.  
  453. After that, a small filesystem, and voila, you have a minimal unix.  Two
  454. months for basic setups, but then only slightly longer until I had a
  455. disk-driver (seriously buggy, but it happened to work on my machine) and
  456. a small filesystem.  That was about when I made 0.01 available (late
  457. august-91? Something like that): it wasn't pretty, it had no floppy
  458. driver, and it couldn't do much anything.  I don't think anybody ever
  459. compiled that version.  But by then I was hooked, and didn't want to
  460. stop until I could chuck out minix.
  461.  
  462. >3) Would new linkers and loaders have to be written before you get a basic
  463. >   kernel running?
  464.  
  465. All versions up to about 0.11 were crosscompiled under minix386 - as
  466. were the user programs.  I got bash and gcc eventually working under
  467. 0.02, and while a race-condition in the buffer-cache code prevented me
  468. from recompiling gcc with itself, I was able to tackle smaller compiles. 
  469. 0.03 (October?) was able to recompile gcc under itself, and I think
  470. that's the first version that anybody else actually used.  Still no
  471. floppies, but most of the basic things worked.
  472.  
  473. Afetr 0.03 I decided that the next version was actually useable (it was,
  474. kind of, but boy is X under 0.96 more impressive), and I called the next
  475. version 0.10 (November?).  It still had a rather serious bug in the
  476. buffer-cache handling code, but after patching that, it was pretty ok. 
  477. 0.11 (December) had the first floppy driver, and was the point where I
  478. started doing linux developement under itself.  Quite as well, as I
  479. trashed my minix386 partition by mistake when trying to autodial
  480. /dev/hd2.
  481.  
  482. By that time others were actually using linux, and running out of
  483. memory.  Especially sad was the fact that gcc wouldn't work on a 2MB
  484. machine, and although c386 was ported, it didn't do everything gcc did,
  485. and couldn't recompile the kernel.  So I had to implement disk-paging:
  486. 0.12 came out in January (?) and had paging by me as well as job control
  487. by tytso (and other patches: pmacdona had started on VC's etc).  It was
  488. the first release that started to have "non-essential" features, and
  489. being partly written by others.  It was also the first release that
  490. actually did many things better than minix, and by now people started to
  491. really get interested. 
  492.  
  493. Then it was 0.95 in March, bugfixes in April, and soon 0.96. It's
  494. certainly been fun (and I trust will continue to be so) - reactions have
  495. been mostly very positive, and you do learn a lot doing this type of
  496. thing (on the other hand, your studies suffer in other respects :)
  497.  
  498.                 Linus
  499.  
  500.