Linux History 101 :)
Ragnar Hojland Espinosa
Here's one of the little jewels I have floating in /doc/
Subject: Writing an OS - questions !!
Date: 5 May 92 01:57:05 GMT
Reply-To: na...@td2cad.intel.com (V. Narayanan)
Hi folks,
For quite some time this "novice" has been wondering as to how one goes
about the task of writing an OS from "scratch". So here are some questions,
and I would appreciate if you could take time to answer 'em.
1) How would you typically debug the kernel during the development phase?
2) Can you test the kernel functionality by running it as a process on a
different OS? Wouldn't the OS(the development environment) generate
exceptions in cases when the kernel (of the new OS) tries to modify
'priviledged' registers?
3) Would new linkers and loaders have to be written before you get a basic
kernel running?
4) Was Linux developed in a DOS environment? Maybe Linus could shed some light
on this subject.
Thanks in anticipation.
N. Venkat
From: baz...@mrcnext.cso.uiuc.edu (Jawaid Bazyar)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 5 May 92 03:33:10 GMT
Organization: University of Illinois at Urbana
na...@td2cad.intel.com (V. Narayanan) writes:
Having just written a Multitasking OS, I couldn't resist...
>Hi folks,
> For quite some time this "novice" has been wondering as to how one goes
>about the task of writing an OS from "scratch". So here are some questions,
>and I would appreciate if you could take time to answer 'em.
>1) How would you typically debug the kernel during the development phase?
On my machine (Apple IIgs), we have a machine-language debugger which
has a number of nifty features, the most important here being that it
'turns-on' whenever certain reserved software traps are activated. You
can intersperse these in your code to trace certain locations.
And, there's always the infamous "printf" method, printing out every
value you deem relevant to the problem.
You probably won't be able to use existing source-level debuggers (see
below), but this is just conjecture on my part and indeed depends on how
you initially implement the system.
>2) Can you test the kernel functionality by running it as a process on a
> different OS? Wouldn't the OS(the development environment) generate
> exceptions in cases when the kernel (of the new OS) tries to modify
> 'priviledged' registers?
Yes, and in fact many classes in OS design are taught with this principle.
"Operating System Design" by Douglas Comer implements a Unix-like OS
called XINU. There is source code publically available for a version
of XINU which runs under UNIX systems. This system works by basically
implementing threads (multiple processes inside one real Unix process).
Your mention of the new OS accessing privileged registers is a good question,
and as far as I know there's no good answer except one: you have to get
the basic multitasking and low-level OS features working by sweat alone.
Usually, you have to boot into your new OS, instead of running it from
your development system. This means that you have a really tedious
test, reboot, compile, reboot, test cycle.
>3) Would new linkers and loaders have to be written before you get a basic
> kernel running?
No, the standard technique is to use a cross compiler of some sort.
If the OS you're writing is for the same processor your development system
is on, then most of the problem is solved. All you need to do is avoid
using any library routines that use the development system's OS. Now,
when you get to the point where you want to start using the C compiler
under your new system, you have a bit of a problem (unless your new OS
can run other OS's software, kinda like OS2->Windows, Windows->DOS, etc).
As far as loaders, you probably would want to for later user programming,
but most OS's are written to be loaded into a pre-defined area of physical
memory, and thus you won't need a loader to boot your system. In any
event, loaders are in general fairly simple, and you could probably
emulate existing ones (so as to be able to use existing compilers, etc).
Writing an OS is probably one of the most satisfying things I've done;
I wouldn't recommend it for the faint of heart, however. :)
--
Jawaid Bazyar | Ask me about the GNO Multitasking Environment
Procyon, Inc. | for the Apple IIgs! (314) 334-7078
baz...@cs.uiuc.edu | 1005 N. Kingshighway, Suite 309
--Apple II Forever!-- | Cape Girardeau, MO 63701
From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 5 May 92 07:58:17 GMT
In article <10...@inews.intel.com> na...@td2cad.intel.com (V. Narayanan) writes:
>
>Hi folks,
> For quite some time this "novice" has been wondering as to how one goes
>about the task of writing an OS from "scratch". So here are some questions,
>and I would appreciate if you could take time to answer 'em.
Well, I see someone else already answered, but I thought I'd take on the
linux-specific parts. Just my personal experiences, and I don't know
how normal those are.
>1) How would you typically debug the kernel during the development phase?
Depends on both the machine and how far you have gotten on the kernel:
on more simple systems it's generally easier to set up. Here's what I
had to do on a 386 in protected mode.
The worst part is starting off: after you have even a minimal system you
can use printf etc, but moving to protected mode on a 386 isn't fun,
especially if you at first don't know the architecture very well. It's
distressingly easy to reboot the system at this stage: if the 386
notices something is wrong, it shuts down and reboots - you don't even
get a chance to see what's wrong.
Printf() isn't very useful - a reboot also clears the screen, and
anyway, you have to have access to video-mem, which might fail if your
segments are incorrect etc. Don't even think about debuggers: no
debugger I know of can follow a 386 into protected mode. A 386 emulator
might do the job, or some heavy hardware, but that isn't usually
feasible.
What I used was a simple killing-loop: I put in statements like
die:
jmp die
at strategic places. If it locked up, you were ok, if it rebooted, you
knew at least it happened before the die-loop. Alternatively, you might
use the sound io ports for some sound-clues, but as I had no experience
with PC hardware, I didn't even use that. I'm not saying this is the
only way: I didn't start off to write a kernel, I just wanted to explore
the 386 task-switching primitives etc, and that's how I started off (in
about April-91).
After you have a minimal system up and can use the screen for output, it
gets a bit easier, but that's when you have to enable interrupts. Bang,
instant reboot, and back to the old way. All in all, it took about 2
months for me to get all the 386 things pretty well sorted out so that I
no longer had to count on avoiding rebooting at once, and having the
basic things set up (paging, timer-interrupt and a simple task-switcher
to test out the segments etc).
>2) Can you test the kernel functionality by running it as a process on a
> different OS? Wouldn't the OS(the development environment) generate
> exceptions in cases when the kernel (of the new OS) tries to modify
> 'priviledged' registers?
Yes, it's generally possible for some things, but eg device drivers
usually have to be tested out on the bare machine. I used minix to
develop linux, so I had no access to IO registers, interrupts etc.
Under DOS it would have been possible to get access to all these, but
then you don't have 32-bit mode. Intel isn't that great - it would
probably have been much easier on a 68040 or similar.
So after getting a simple task-switcher (it switched between two
processes that printed AAAA... and BBBB... respectively by using the
timer-interrupt - Gods I was proud over that), I still had to continue
debugging basically by using printf. The first thing written was the
keyboard driver: that's the reason it's still written completely in
assembler (I didn't dare move to C yet - I was still debugging at
about instruction-level).
After that I wrote the serial drivers, and voila, I had a simple
terminal program running (well, not that simple actually). It was still
the same two processes (AAA..), but now they read and wrote to the
console/serial lines instead. I had to reboot to get out of it all, but
it was a simple kernel.
After that is was plain sailing: hairy coding still, but I had some
devices, and debugging was easier. I started using C at this stage, and
it certainly speeds up developement. This is also when I start to get
serious about my megalomaniac ideas to make "a better minix that minix".
I was hoping I'd be able to recompile gcc under linux some day...
The harddisk driver was more of the same: this time the problems with
bad documentation started to crop up. The PC may be the most used
architecture in the world right now, but that doesn't mean the docs are
any better: in fact I haven't seen /any/ book even mentioning the weird
386-387 coupling in an AT etc (Thanks Bruce).
After that, a small filesystem, and voila, you have a minimal unix. Two
months for basic setups, but then only slightly longer until I had a
disk-driver (seriously buggy, but it happened to work on my machine) and
a small filesystem. That was about when I made 0.01 available (late
august-91? Something like that): it wasn't pretty, it had no floppy
driver, and it couldn't do much anything. I don't think anybody ever
compiled that version. But by then I was hooked, and didn't want to
stop until I could chuck out minix.
>3) Would new linkers and loaders have to be written before you get a basic
> kernel running?
All versions up to about 0.11 were crosscompiled under minix386 - as
were the user programs. I got bash and gcc eventually working under
0.02, and while a race-condition in the buffer-cache code prevented me
from recompiling gcc with itself, I was able to tackle smaller compiles.
0.03 (October?) was able to recompile gcc under itself, and I think
that's the first version that anybody else actually used. Still no
floppies, but most of the basic things worked.
Afetr 0.03 I decided that the next version was actually useable (it was,
kind of, but boy is X under 0.96 more impressive), and I called the next
version 0.10 (November?). It still had a rather serious bug in the
buffer-cache handling code, but after patching that, it was pretty ok.
0.11 (December) had the first floppy driver, and was the point where I
started doing linux developement under itself. Quite as well, as I
trashed my minix386 partition by mistake when trying to autodial
/dev/hd2.
By that time others were actually using linux, and running out of
memory. Especially sad was the fact that gcc wouldn't work on a 2MB
machine, and although c386 was ported, it didn't do everything gcc did,
and couldn't recompile the kernel. So I had to implement disk-paging:
0.12 came out in January (?) and had paging by me as well as job control
by tytso (and other patches: pmacdona had started on VC's etc). It was
the first release that started to have "non-essential" features, and
being partly written by others. It was also the first release that
actually did many things better than minix, and by now people started to
really get interested.
Then it was 0.95 in March, bugfixes in April, and soon 0.96. It's
certainly been fun (and I trust will continue to be so) - reactions have
been mostly very positive, and you do learn a lot doing this type of
thing (on the other hand, your studies suffer in other respects :)
Linus
From: sin...@scintilla.capitola.ca.us (Darren Senn)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 5 May 92 18:29:42 GMT
I started an OS called Syrinx in Summer of 1990. It started off being
286 specific (that was what I had), and is now 486 specifc (thank god
for upgrades)! Feeling an overwhelming desire to continue this thread,
here's my 2 cents.
Syrinx was largely inspired by BSD 4.3 and some little hardware experiments
that I did in my Computer Engineering studies.
I started off from scratch, by writing some utilities under Borland C that
allowed me to format a partition with the Syrinx filesystem, and then copy
files to the filesystem, etc.
Once I did that, I pulled up TASM, and started with my bootsector. I wrote
a little bootsector that could multi-boot between DOS and Syrinx. If you
hit return, it would boot Syrinx, but if you typed "DOS", it would go to
the first primary DOS partition and boot that. In order to boot Syrinx,
I loaded a file called "/init" and executed it.
The first version of the boot sector took about a month to write and debug,
(I HATE DEBUGGING BOOT CODE!) and had the location of /init hardwired into
it. The second version actually searched the filesystem for /init by looking
through directories and the inodes, and took another two months.
Linus mentioned his "die loops". I did something very similar to that, though
my die loops started off by creating an exploding window in the middle of the
screen (ok, so I was bored :) ), and putting the values of all the registers
into that window, then it went into a pretty solid loop:
@@die: sti ; Disable interrupts
hlt ; Halt the computer
jmp @@die ; If I get out of the halt, repeat!
So this thing pretty solidly stopped the microprocessor, and I didn't have
any problems with reboots clearing the screen. Very helpful.
I had to deal with the debug/compile/write/reboot/... loop that Jawaid
Bazyar mentioned. It was slow, but it worked...
There were two big things that slowed me down:
a) My filesystem was fully formed from the start, and
b) I switched to protected mode through the BIOS.
I didn't (at that time) know how protected-mode friendly BIOS was, so I
went ahead and used the BIOS function call to switch into protected mode.
That gave me the bonus of getting a descriptor for the BIOS data segment
in my GDT for free. Very helpful. Unfortunately, I really had to go
through loops to keep the BIOS from using my hardware interrupts. Very
ugly.
I never did get as far as Linux has come, so when I found Linux last month,
I jumped in with both feet. Some of my Syrinx stuff is better than Linux's,
but most of Linux is far more advanced than Syrinx ever got.
In general, I think Linus' tactic of getting a bare system up first is a
better bet than trying to make everything fully-formed as you go. I
never did get a C compiler, but I did write an assembler that worked under
Syrinx (I called it Sinas).
One thing that helped my Syrinx development was DOS EXE compatibility. I
checked the header of any files that you tried to execute, and if it was
a DOS EXE header, then I ran it in V86 mode. I could get a number of things
to run, but anything that tried to switch to protected mode would die in
a rather horrible way, so there were a lot of things I couldn't use. I
also didn't support EMS or XMS or DPMI, so those programs were all out.
Basically, what it came down to was that I couldn't run any commercial
programs. :(
Syrinx has now been shoved way back on the burner, however, and I've
gone whole-hog into Linux.
One of the first things I did when I got Linux was to look at the kernel
code (the equivalent to my /init). I was rather surprised to see that
Linus switched to protected mode all on his own, without going through
the BIOS. I also like his little comment in the sources:
! This is how real programmers do it
or something to that effect. :)
From: wo...@neuron.et.tudelft.nl (Rogier Wolff)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 6 May 92 09:51:12 GMT
rh...@cs.uq.oz.au (Rhys Weatherley) writes:
>Thanks for posting that Linus - it's very good to read how it all began. I
>hope that the FTP site administrators save away your message as a piece of
>Linux folklore. I especially liked the bit about you being proud of your
>two AAAA... and BBBB... processes. :-)
>Cheers,
I once "ported" XINU to a PDP 11. (It was written on one, but you don't
get some, necessary software with the book, and you'd need a VAX that we
didn't have to run it. Also some PDP11s have hardware MUL and DIV while
others don't)
Anyway we ran the same test: One process printing "process A" and the
other "process B". This resulted in the following output:
process A
process A
process A
prpocess A
process A
process A
procress A
process A
And we where thinking of bugs in the tty code, when it struck that the
output buffer was filling, and process B was mad runnable untill it
printed exactly one character. This blocked process B, and would wait
until the buffer cleared. Next process A would be made runnable again,
and be allowed to fill most of the buffer again.....
Yes, we where also proud that this worked!
Roger
--
If the opposite of "pro" is "con", what is the opposite of "progress"?
(stolen from kad...@iitvax.iit.edu)
EMail: wo...@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
From: t...@telematics.com (Ted Goldblatt)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 6 May 92 22:46:52 GMT
In article <10...@inews.intel.com> na...@td2cad.intel.com (V. Narayanan) writes:
>
>Hi folks,
> For quite some time this "novice" has been wondering as to how one goes
>about the task of writing an OS from "scratch". So here are some questions,
>and I would appreciate if you could take time to answer 'em.
>
>1) How would you typically debug the kernel during the development phase?
I can only speak from the point of view of building a system on non-PC
type hardware. I don't know how relevent this is to someone who wishes
to build a system on a PC type platform as it normally exists, especially
if it is for hobby type use as opposed to "for real" (i.e., if you don't
have _lots_ of time and _lots_ of money to spend).
The first step was (would be) to build (if not already present) a
"debug monitor". (Actually, I once worked on a system without this,
but that was on a machine that had a "real" front panel :-), so it's
too far in the past to think about.)
The debug monitor is actually a collection of software, normally
resident in a ROM/EPROM. On the system I currently work on, this
includes automatic hardware health checks, stand-alone I/O support
for the console, disk, and network (the equivalent of a PC's BIOS,
I believe), assorted initialization functions, and (most important
for this discussion) a command interpreter.
The command interpreter's commands allow such things as examining and
modifying memory and registers, planting breakpoints, and loading and
running programs (e.g., off of disk). Using the breakpoint capability,
breakpoints can be planted in the O/S (which is just another program
to the monitor), and the examine and modify capabilities can be used
when a breakpoint is hit to see what is going on.
Now (you ask), how do you debug the debug monitor? For that, we use
hardware debugging facilities, principally emulators and logic
analyzers. An emulator gives you capabilities similar to those of
the debug monitor, but totally external to the system (they don't
depend on any of the system's facilities to work). It generally
plugs into the microprocessor socket, replacing the micro.
The tool I use much more often is a logic analyzer, which also plugs
into the micro socket. However, rather than giving you monitor-like
capabilities, the analyzer can just look at what is happening on the
chip's pins. It provides you a way to capture the micro's
interactions with the "outside world" (mostly memory). Its benefits
are that (most) logic analyzers have very elaborate facilities for
conditionally choosing _what_ is captured (triggering and selection)
as well as the ability to watch other things in parallel (bus
activity, I/O chips, etc.) with cross correlation and time stamping.
These gadgets are _very_ useful, especially for watching interactions
of multiprocessors and other concurrent activities. Even with a good
debug monitor available on our system, I still make heavy use of a
logic analyzer for O/S debugging. The major downsides are that they
tend to be low-level debugging tools (assembly level, maybe with
symbols, sometimes with limited support for C), and they are expensive
(the one I generally use is a good one, and supports 3 processors and
a 2 channel digital scope simultaneously, but it cost $45K).
>2) Can you test the kernel functionality by running it as a process on a
> different OS? Wouldn't the OS(the development environment) generate
> exceptions in cases when the kernel (of the new OS) tries to modify
> 'priviledged' registers?
This is very dependent on the underlying H/W (it assumes all necessary
requests would be trapped cleanly, and that the machine model captures
sufficient information). In many cases, for this to work, the
underlying O/S would have to be changed to emulate the required
facilities transparently. This may or may not be possible. Also,
timing would be completely different, so this approach would have
limited benefit in finding timing related problems, and might not work
at all if the system in question was real-time or had timing
constraints of its own. However, this idea _is_ the basis for virtual
machine systems (e.g., VM/370), and (if it can be employed) is very
useful. Note that true virtual machine operation (as opposed to S/W
emulation) cannot be done on all processors. The Moto 68010, 68020,
and 68030 do support this, but the 68040 _does not_. I don't know the
Intel line well enough to tell, but I have heard that the chips can
virtualize lower members of the family but not themselves.
>3) Would new linkers and loaders have to be written before you get a basic
> kernel running?
Certainly not before. Whether they were needed before the system was
useful depends in part on what the system's intended facilities are
and what object module and load module formats were chosen. Linkers
need not be O/S dependent (though they normally are at least
somewhat), and loaders need not be complex (especially in a system
that uses demand paged loading - of course in this case, you just
pushed the work into your virtual memory system :-)).
>4) Was Linux developed in a DOS environment? Maybe Linus could shed some light
> on this subject.
Left for Linus :-)
--
Ted Goldblatt t...@telematics.com (305) 351-4367
Telematics Intl., Inc. Ft. Lauderdale, FL
From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: To Linus, Lions book?
Date: 3 Jul 92 11:35:06 GMT
In article <1992Jul3.0...@athena.mit.edu> J.Ja...@sheffield-city-poly.ac.uk writes:
>
>How did you get all your now how to create Linux?
>Was hands on learning, which books/mags/articles/code
>did you read? Go on Linus, give us a potted life history :-)
Heh. I can't let these ego-building posts go by, so I'll have to answer
it.
Linux started for several different reasons: originally just to learn
the 386, and for this the book "Programming the 80386" by Crawford and
Gelsinger is a must. At least I haven't found anything better (although
admittedly bookstores in Finland probably don't have the plethora of
books available over in the US etc).
The 386 book info has been used for all the 386 details: the lowest
level of the task-switching code, memory manager, floating point
emulations etc. It doesn't even mention the AT hardware, so for device
drivers you'll need more info, but it does contain everything on the
386/387 chips (even if it's a bit hard to read: read it through several
times before starting to look into details).
The device drivers have been written mostly by trial and error: I
haven't found a single good source of info on the standard AT hardware.
Helpful sources have been (a) the AT Technical Reference Manual (notably
the BIOS listing) (b) actual data-sheets for the 8250 etc chips used in
the AT hardware (c) other sources (mach drivers and to a lesser extent
minix drivers) (d) various books like "IBM Microcomputers: a programmers
manual", "The PC Sourcebook" etc.
Even though there are a lot of books on the AT hardware, none of them
seem to approach the information content of the 80386 books. I can't
recommend any of the sources I've used, and the best bet is probably to
have a lot of books and hope they together cover most of it.
Then there is naturally the hardware-independent parts of the kernel:
general filesystem/process/memory management. The two books I
originally used were "The Design of the Unix Operating System" by Bach,
and "OS Design and Implementation" by Tanenbaum. Tanenbaum's book
should be read a couple of times: ignore the details (especially about
minix), but get the general picture clear. The Bach book has a few nice
algorithms in it, and I'd suggest reading them too: many of the actual
ideas on how something could be implemented came from that.
Still, OS design is mostly common sense: it doesn't need complicated
algorithms like a compiler does or similar. A lot of thought, careful
programming and some good decisions. And unix is a very simple OS
really: I first came in contact with it 2 years ago when I did the
"C-kieli ja unix ohjelmointiymp{rist|" course in the fall of -90. By
early -91 I had bought a PC, and linux v0.01 was ready in August -91.
That wouldn't have been possible with some other systems I could mention
(VMS.. arghh).
The most difficult parts are:
- device drivers: you can go crazy trying to find why something doesn't
work on some machines (especially if you can't even test it out).
- filesystem: trying to make it clean and well designed, as well as
getting rid of all race conditions. The current linux vfs layer seems
to work well enough, but my original design wasn't too good. Rewriting
big parts isn't fun when something works.
The kernel proper is pretty simple in fact, although you have to keep
track of a lot of things. The memory manager has also survived pretty
well all the changes, and although I'll have to change it to use
different page directories for different processes some day it will
probably look pretty similar even after that.
>Also could you mail me a few lines, grouping the source code
>files into chunks. I.e., which files make up the lowest most
>basic layer of the OS 'onion', which ones make up the next layer?
>This would make it lot easirt to peruse the code in an orderly fashion
>so I can try to understand it.
Hmm. To get a good general idea of the different pieces, I'd suggest
reading linux/*/*.c - all the memory management sources, the normal
kernel sources and the vfs routines. They are pretty modular: you can
generally understant linux/fs/*.c without having to understand the
kernel and vice versa (for a general picture, that is. For the details
you usually have to read it all).
The linux device drivers (linux/kernel/chr_drv and linux/kernel/blk_drv)
are a pain to read: they don't actually give you any more info on the
kernel itself, so reading them is only needed if you really want to know
how a block is loaded into memory etc. Similarly for the math-emulator
(linux/kernel/math).
The special filesystems (linux/fs/minix and now linux/fs/ext) can be
read if you are interested in the actual lay-out of the disk, or if you
want to see how some of the fs races are handled. Note that most
race-conditions are handled directly by the buffer-cache routines or the
vfs layer, but some races are inherent to the actual fs implementation
(renaming a file etc).
Linus
--
____/| Ragnar Hojland (rag...@lightside.ddns.org) Fingerprint 94C4B
\ o.O| _______________________________________________ 2F0D27DE025BE2302C
=(_)= | 7 Diciembre, manifestacion contra Telefonica! | 104B78C56 B72F0822
U | No faltes!! http://www.internautas.org/7D/) | hkp://keys.pgp.com
-----------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Jim Nance
>
> Here's one of the little jewels I have floating in /doc/
>
> Subject: Writing an OS - questions !!
> Date: 5 May 92 01:57:05 GMT
> Reply-To: na...@td2cad.intel.com (V. Narayanan)
The really scarry thing is that I remember these from when they were
originally posted. I cant believe its been over 6 years.
Jim
--
----------------------------------------------------------------------------
Jim Nance Avant! Corporation
(919) 941-6655 Do you have sweet iced tea? jim_...@avanticorp.com
No, but there's sugar on the table.
Paul Wouters
Benedict? :)
> 0.11 (December) had the first floppy driver, and was the point where I
> started doing linux developement under itself. Quite as well, as I
> trashed my minix386 partition by mistake when trying to autodial
> /dev/hd2.
I feel much better now. I felt bad for doing a filesystem check with
mke2fs (twice!)
Paul
Simon Kenyon
I'm going to start to pull together anything and everything that I can find about
the history of the Linux OS. Could everybody please send me any/all of the
following:
- original and significant email/new messages
- timings of releases
- biographies of contributors to the kernel, utilities
- pointers to web pages containing information
- stories/photographs of amusing and/or significant occasions
I'll put this together on a web site and try to keep it up to date. This OS is
important to a lot of people and we should keep a record of what/why/how happened
and when.
Any and all help appreciated.
--
simon
Riley Williams
> The History of the Linux Operating System
> I'm going to start to pull together anything and everything that I
> can find about the history of the Linux OS.
===8<=== CUT ===>8===
What I'd like to see is some of the early releases of Linux, just out
of curiosity. Problem is, they all appear to be long since filed in
the old circular file...
Best wishes from Riley.
Simon Kenyon
> What I'd like to see is some of the early releases of Linux, just out
> of curiosity. Problem is, they all appear to be long since filed in
> the old circular file...
i'll see what i can dig up
anyone able to help?
--
simon
Riley Williams
>> What I'd like to see is some of the early releases of Linux, just
>> out of curiosity. Problem is, they all appear to be long since
>> filed in the old circular file...
> i'll see what i can dig up - anyone able to help?
I've so far had ELEVEN private emails pointing out that the majority
of the historic kernels can be found in:
ftp://ftp.kernel.org/pub/linux/kernel/historic
I've just had a look at the SunSite-UK mirror thereof, and note the
following kernel tarballs thereon, in various directories:
0.01
0.10
0.11
0.12
0.95
0.95a
0.96a (plus patches 2, 3 and 4)
0.96b (plus patches 1 and 2)
0.96c (plus patches 1 and 2)
0.96c+
0.97
0.99 (plus patches 1 through 9 and 11 through 13)
0.99.1 through 0.99.7
0.99.7A
0.99.8 through 0.99.11
0.99.12 (plus linux-0.99.12.small-patch)
0.99.13
0.99.15
1.0 (plus patches 1 through 9)
1.1.13
1.1.23 1.1.29
1.1.33 1.1.35
1.1.45
1.1.52 1.1.59
1.1.63 1.1.64 1.1.67
1.1.70 1.1.71 1.1.73 1.1.74 1.1.75 1.1.76
1.1.78 through 1.1.95
1.2.0 through 1.2.13
1.3.0
1.3.2 through 1.3.100
pre2.0.1 through pre2.0.14
2.0
2.0.1 through 2.0.36
2.1.0 through 2.1.24
2.1.27 through 2.1.129
Judging by that list, there's still quite a few missing versions, so
if anybody has copies of the remaining versions, I'd certainly be
interested therein...
For comparison, I've extracted the entries for a few of the major
releases thereof, dates taken from the archive contents:
17 Sep 1991 63,362 linux-0.01.tar.bz2
13 Dec 1992 850,885 linux-0.99.tar.Z <=>
13 Mar 1994 1,016,601 linux-1.0.tar.bz2
23 May 1994 1,083,514 linux-1.1.13.tar.bz2
2 Mar 1995 1,849,466 linux-1.1.95.tar.bz2
9 Jun 1996 4,718,270 linux-2.0.tar.bz2
30 Sep 1996 4,897,927 linux-2.1.0.tar.bz2
15 Nov 1998 5,913,353 linux-2.0.36.tar.bz2
19 Nov 1998 10,064,120 linux-2.1.129.tar.bz2
That's an interesting growth in file size over the last 7.2 years, and
really shows how something can change...
Best wishes from Riley.
Gregory Maxwell
> > From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
>
> Benedict? :)
>
> > 0.11 (December) had the first floppy driver, and was the point where I
> > started doing linux developement under itself. Quite as well, as I
> > trashed my minix386 partition by mistake when trying to autodial
> > /dev/hd2.
>
> I feel much better now. I felt bad for doing a filesystem check with
> mke2fs (twice!)
For a long time my mke2fs and mkswap were suid nobody after mkswaping my
root fs. At least you can recover from a mkswap on ext2.
Andrea Arcangeli
>been mostly very positive, and you do learn a lot doing this type of
>thing (on the other hand, your studies suffer in other respects :)
I feel much better now too :). I always asked myself how Linus could
have handled the load of writing Linux and studying at the same time...
Gregory Maxwell
the historic dir on ftp.kernel.org I assume has them. If not I've got a
.12 root/boot someplace..:)
On Sun, 22 Nov 1998, Riley Williams wrote:
> Hi Simon.
>
> > The History of the Linux Operating System
>
> > I'm going to start to pull together anything and everything that I
> > can find about the history of the Linux OS.
>
> ===8<=== CUT ===>8===
>
> What I'd like to see is some of the early releases of Linux, just out
> of curiosity. Problem is, they all appear to be long since filed in
> the old circular file...
>
> Best wishes from Riley.
H. Peter Anvin
By author: Riley Williams <r...@bigfoot.com>
In newsgroup: linux.dev.kernel
>
> I've so far had ELEVEN private emails pointing out that the majority
> of the historic kernels can be found in:
>
> ftp://ftp.kernel.org/pub/linux/kernel/historic
>
> I've just had a look at the SunSite-UK mirror thereof, and note the
> following kernel tarballs thereon, in various directories:
>
> if anybody has copies of the remaining versions, I'd certainly be
> interested therein...
>
We are indeed missing a number of historic kernels (before 1.0). If
anyone has them, I would appreciate a copy.
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables
Pavel Janik ml.
Date: Sun, 22 Nov 1998 13:45:47 +0000 (GMT)
Hi,
> What I'd like to see is some of the early releases of Linux, just out
> of curiosity.
:-) You can see LSD on htpp://lsd.linux.cz - I hope you'll be
surprised...
--
Pavel Janik ml.
Pavel...@inet.cz
aar...@vitelus.com
http://www.dina.kvl.dk/%7Eabraham/Linus_vs_Tanenbaum.html
On Sun, 22 Nov 1998, Simon Kenyon wrote:
> On 22-Nov-98 Riley Williams wrote:
> > What I'd like to see is some of the early releases of Linux, just out
> > of curiosity. Problem is, they all appear to be long since filed in
> > the old circular file...
>
> i'll see what i can dig up
> anyone able to help?
> --
> simon
>
Guest section DW
We are indeed missing a number of historic kernels (before 1.0). If
anyone has them, I would appreciate a copy.
What versions do you have in mind?
I have a
-rw-r--r-- 1 aeb aeb 444413 Aug 17 1992 linux97.taz
(on a xiafs filesystem - good that that is still supported under 2.0 :-)
Checking the contents I find that it is the same as linux-0.97.tar.Z
dated Sep 27, 1992. So, the file dates in the
ftp://ftp.kernel.org/pub/linux/kernel/Historic/
directories are probably not the original ones.
I have 0.99/pl15[a-j], 0.99/pl14[a-z] but from the earlier 0.99pl*
only a few edited by me - no clean copies.
[Am certainly interested in missing fragments.]
But old kernels are fairly well documented.
The remaining fragments of software are more difficult to find.
The oldest binary for libc that I can find is libc2.2.2.
But I have source only since libc-4.4.1.
Any older sources are welcome.
Andries
P.S. I suspect that CDROM manufacturers like Yggdrasil or TransAmerican
or so must have snapshots of fairly old systems - but again perhaps
only binaries?
Johnny Tevessen
> I've just had a look at the SunSite-UK mirror thereof, and note the
> following kernel tarballs thereon, in various directories:
Is there a note about which is the oldest kernel version one can
actually compile using recent tools (gcc-2.7.2+, binutils-2.8+,
make-3.7x+)?
> 1.2.0 through 1.2.13
I once had 1.2.13pl9 and pl10 for m68k Amigas. I'm not sure whether
these pl releases were official kernels which had *then* m68k patches
applied to them.
I also once had at least one kernel which had PATCHLEVEL= or
SUBLEVEL= set to "99" in the Makefile. Not sure which version
this actually was (it was >=1.2.x), but I remember that the
numbers in its tar filename mentioned a slightly different
version. Maybe a lookup in the kernel archive could help.
Do you plan to archive non-x86 kernels, too? Sometimes their
evolution was interesting, too (especially the older/first
ports).
ciao,
johnny
--
Trust no-one.
Simon Kenyon
> Do you plan to archive non-x86 kernels, too? Sometimes their
> evolution was interesting, too (especially the older/first
> ports).
as this contains a question - i'll answer
please don't expect answers to mail messages that contain information
although it is very well appreciated, there are too many to reply individually - i
hope people understand
anyway, i will archive all the kernels that i can find and make them available for
download - but not instantly - this will take some time or organise and it is
incidental to my task of writing a history of the evolution of Linux
looks like i'll have to work out how to get DVD's mastered
i was hoping to put stuff on CD - but a rough
"back of fag^h^h^hcigarette packet"
(another term i cannot use any more because itis not PC)
calculation shows me that a CD or three will not be enough
--
simon
Riley Williams
>> I've just had a look at the SunSite-UK mirror thereof, and note
>> the following kernel tarballs thereon, in various directories:
> Is there a note about which is the oldest kernel version one can
> actually compile using recent tools (gcc-2.7.2+, binutils-2.8+,
> make-3.7x+)?
I havenae had a look, sorry...
>> 1.2.0 through 1.2.13
> I once had 1.2.13pl9 and pl10 for m68k Amigas. I'm not sure
> whether these pl releases were official kernels which had *then*
> m68k patches applied to them.
> I also once had at least one kernel which had PATCHLEVEL= or
> SUBLEVEL= set to "99" in the Makefile. Not sure which version
> this actually was (it was >=1.2.x), but I remember that the
> numbers in its tar filename mentioned a slightly different
> version. Maybe a lookup in the kernel archive could help.
Nodz...
> Do you plan to archive non-x86 kernels, too? Sometimes their
> evolution was interesting, too (especially the older/first
> ports).
I wasnae actually planning on archiving anything yet, as I just don't
have any spare disk space. However, something along the lines of a CVS
archive with all the kernel sources and official patches in order
might not be a bad idea...
Best wishes from Riley.
Riley Williams
>> Do you plan to archive non-x86 kernels, too? Sometimes their
>> evolution was interesting, too (especially the older/first ports).
> as this contains a question - i'll answer - please don't expect
> answers to mail messages that contain information although it is
> very well appreciated, there are too many to reply individually - i
> hope people understand
I understand that...
> anyway, i will archive all the kernels that i can find and make
> them available for download - but not instantly - this will take
> some time or organise and it is incidental to my task of writing a
> history of the evolution of Linux
I've been looking into setting up a CVS tree that will contain the
full kernel source history...
> looks like i'll have to work out how to get DVD's mastered i was
> hoping to put stuff on CD - but a rough "back of fag^h^h^hcigarette
> packet" (another term i cannot use any more because itis not PC)
> calculation shows me that a CD or three will not be enough
Put them in a CVS archive, and you replace "sum of kernel source
archive sizes" with "sum of upgrade patch file sizes", and thus
massively reduce the size of the result...
I would suspect the result will fit on a ZipDisk, never mind a CD, but
I'll not know for sure until I get it set up...
Are there any CVS experts out there?
Simon Kenyon
> I've been looking into setting up a CVS tree that will contain the
> full kernel source history...
> Put them in a CVS archive, and you replace "sum of kernel source
> archive sizes" with "sum of upgrade patch file sizes", and thus
> massively reduce the size of the result...
> I would suspect the result will fit on a ZipDisk, never mind a CD, but
> I'll not know for sure until I get it set up...
> Are there any CVS experts out there?
now we're getting somewhere
trouble is - as the puzzle unfolds, what do you do about the situation where an
intermediate release turns up
say we have 1.1.1, 1.1.3, 1.1.4
put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
can cvs/rcs/sccs (you choose) handle this?
--
simon
Jim Gettys
It is worth digging up the oldest Linux versions you can while it is still
possible.
I have some old X stuff around (somewhere around X1 or X2), but regret
having not been more systematic myself. (would be painful to get up these
days; the display hardware is dramatically different and some of the early
X software was written in CLU; so early days of the X Window System are
unlikely to ever re-emerge from the twilight of history.)
There are a group of people on the net who are preserving old systems
and software.
For example, no one will ever see UNIX before version 5, even though emulators
exist for the hardware they ran on: Dennis Ritchie and others have been
unable to find either a bootable disk image or sources to earlier versions.
V5 and later versions can be played with today under emulators. (Would
be easy to get the PDP-11 simulator running under Linux; I've suggested to
Bob Supnik that it would be a good thing to do).
- Jim
Geert Uytterhoeven
> > anyway, i will archive all the kernels that i can find and make
> > them available for download - but not instantly - this will take
> > some time or organise and it is incidental to my task of writing a
> > history of the evolution of Linux
>
> full kernel source history...
That's indeed a good idea.
> > looks like i'll have to work out how to get DVD's mastered i was
> > hoping to put stuff on CD - but a rough "back of fag^h^h^hcigarette
> > packet" (another term i cannot use any more because itis not PC)
> > calculation shows me that a CD or three will not be enough
>
> Put them in a CVS archive, and you replace "sum of kernel source
> archive sizes" with "sum of upgrade patch file sizes", and thus
> massively reduce the size of the result...
>
> I would suspect the result will fit on a ZipDisk, never mind a CD, but
> I'll not know for sure until I get it set up...
I wouldn't count on the Zip. Just did a `du' on my CVS Linux kernel archive
(containing branches for Linus' 2.1.x releases, Jes' Linux/m68k 2.1.x releases,
lots of vger copies, and my personal tree, all since December 1997 only) and I
saw 157832 KB.
BTW, will you guys do the m68k releases too?
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Simon Kenyon
> For example, no one will ever see UNIX before version 5, even though emulators
> exist for the hardware they ran on: Dennis Ritchie and others have been
> unable to find either a bootable disk image or sources to earlier versions.
> V5 and later versions can be played with today under emulators. (Would
> be easy to get the PDP-11 simulator running under Linux; I've suggested to
> Bob Supnik that it would be a good thing to do).
remember the paper in software p & e where some chap emulated the 11 using a dg
nova and fortran
ran v7 (or was it v6) a 3% of the speed of an 11/34
i remember asking dennis about it
his opinion was that it was quite a feat of engineering
i had a friend who did something similar
he had a 32v tape and was running vms
so he loaded the tape onto disk and wrote code to unpick the blocks and grabbed
the binaries for as and cc and would load them high and trap "change mode to
kernel" (i forget what the instruction is/was) and emulated the unix system calls
with bits for fortran
got the assembler, c compiler and sundry other stuff running
this was in 1979
--
simon
Geert Uytterhoeven
> On 23-Nov-98 Riley Williams wrote:
> > full kernel source history...
> > archive sizes" with "sum of upgrade patch file sizes", and thus
> > massively reduce the size of the result...
> > I would suspect the result will fit on a ZipDisk, never mind a CD, but
> > I'll not know for sure until I get it set up...
>
> now we're getting somewhere
> trouble is - as the puzzle unfolds, what do you do about the situation where an
> intermediate release turns up
>
> say we have 1.1.1, 1.1.3, 1.1.4
> put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
> can cvs/rcs/sccs (you choose) handle this?
That's why we have tags. After checking in 2.1.129, you say
cvs tag linus-2-1-129
After that you can say
cvs co linus-2-1-129
to check out 2.1.129.
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Simon Kenyon
>> say we have 1.1.1, 1.1.3, 1.1.4
>> put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
>> can cvs/rcs/sccs (you choose) handle this?
>
> That's why we have tags. After checking in 2.1.129, you say
>
> cvs tag linus-2-1-129
>
> After that you can say
>
> cvs co linus-2-1-129
>
> to check out 2.1.129.
i obviously didn't explain myself :-)
i have 1.1.1
i put it in rcs
THEN i get 1.1.47
so i put that in rcs
NOW i get 1.1.x where 1 < x < 47
how do i insert that inbetween 1.1.1 and 1.1.47?
not something you would normally do with sccs/rcs
but then again - writing detective stories was not what rcs was designed for
knowing how rcs stores the deltas i really can't see how it would doo it
can bitmover help?
--
simon
Geert Uytterhoeven
> >> say we have 1.1.1, 1.1.3, 1.1.4
> >> put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
> >> can cvs/rcs/sccs (you choose) handle this?
> >
> > That's why we have tags. After checking in 2.1.129, you say
> >
> > cvs tag linus-2-1-129
> >
> > After that you can say
> >
> > cvs co linus-2-1-129
> >
> > to check out 2.1.129.
>
> i obviously didn't explain myself :-)
>
> i have 1.1.1
> i put it in rcs
> THEN i get 1.1.47
> so i put that in rcs
> NOW i get 1.1.x where 1 < x < 47
>
> how do i insert that inbetween 1.1.1 and 1.1.47?
That's exactly the way you do _not_ want to do it. CVS doesn't care about the
internal RCS version numbers. Yes, I made the same mistake some time ago.
If a file isn't changed in between Linux release 2.1.128 and 2.1.129, it will
have the same (internal) RCS version number in both releases.
CVS uses symbolic names (tags) to link the various RCS version numbers with a
global release name.
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Simon Kenyon
>> i have 1.1.1
>> i put it in rcs
>> THEN i get 1.1.47
>> so i put that in rcs
>> NOW i get 1.1.x where 1 < x < 47
>>
>> how do i insert that inbetween 1.1.1 and 1.1.47?
>
> That's exactly the way you do _not_ want to do it. CVS doesn't care about the
> internal RCS version numbers. Yes, I made the same mistake some time ago.
> If a file isn't changed in between Linux release 2.1.128 and 2.1.129, it will
> have the same (internal) RCS version number in both releases.
>
> CVS uses symbolic names (tags) to link the various RCS version numbers with a
> global release name.
then i can see no good reason to stick it in cvs
if i cannot use it to track the changes to a particular FILE as the kernel moved
from version to version (and to be able to ask questions like what changed in mm.c
from 2.0.0 and 2.1.0 for example) what is the point of storing anything under cvs
somebody else has explained to me what i have to do to do the "out of order"
insertions into rcs - it is not a pretty sight :-(
--
simon
Geert Uytterhoeven
> >> i have 1.1.1
> >> i put it in rcs
> >> THEN i get 1.1.47
> >> so i put that in rcs
> >> NOW i get 1.1.x where 1 < x < 47
> >>
> >> how do i insert that inbetween 1.1.1 and 1.1.47?
> >
> > That's exactly the way you do _not_ want to do it. CVS doesn't care about the
> > internal RCS version numbers. Yes, I made the same mistake some time ago.
> > If a file isn't changed in between Linux release 2.1.128 and 2.1.129, it will
> > have the same (internal) RCS version number in both releases.
> >
> > CVS uses symbolic names (tags) to link the various RCS version numbers with a
> > global release name.
>
> then i can see no good reason to stick it in cvs
> if i cannot use it to track the changes to a particular FILE as the kernel moved
> from version to version (and to be able to ask questions like what changed in mm.c
> from 2.0.0 and 2.1.0 for example) what is the point of storing anything under cvs
cvs diff -r linus-2-0-0 -r linus-2-1-0 mm.c
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Guest section DW
I just put all kernel versions since 1.0 up for ftp.
(That is the part I have complete - earlier things are fragmentary.)
Andries
The URL is ftp://ftp.win.tue.nl/pub/linux/kernel.archive
Guest section DW
> Would be easy to get the PDP-11 simulator running under Linux;
> I've suggested to Bob Supnik that it would be a good thing to do.
You can do it yourself. No effort is required.
# unix5
Boot unix with @unix; login as root.
PDP-11 simulator V2.3b
@unix
login: root
# ls -l /bin/sh
-rwxr-xr-x 1 bin 5738 Nov 26 18:13 /bin/sh
#
Larry McVoy
: i have 1.1.1
: i put it in rcs
: THEN i get 1.1.47
: so i put that in rcs
: NOW i get 1.1.x where 1 < x < 47
:
: how do i insert that inbetween 1.1.1 and 1.1.47?
: can bitmover help?
Of course. You can also teach CVS to do this but it would be a pretty
big rewrite and you'd end up with BitKeeper anyway.
Here is how you solve this problem:
Think of each file as a graph, with each node as a delta.
Make an invariant which is that the parent of a node never
changes.
Only add stuff to your file if the parent node is in your file.
So here's the way BitKeeper implements this:
Each node has a unique key which is a string with the following
fields from the delta entry:
user
hostname
date (including minutes west of GMT)
pathname
When you send out the 1.1.47 diffs, it includes the key for
1.1.46. When you try and apply these diffs into your file,
the application program (it's called takepatch) will fail if
it doesn't find the 1.1.46 node.
This generalizes to handling branches, etc. It's very simple graph
manipulations. The place where everyone screws up can always be described
as a violation of the parent/child invariant.
You may not like that you can't apply 1.1.47 as a child of 1.1.1 but
that's the way it has to work. Anyone who tells you differently is
just telling you what you want to hear.
Theodore Y. Ts'o
From: Riley Williams <r...@bigfoot.com>
Judging by that list, there's still quite a few missing versions, so
if anybody has copies of the remaining versions, I'd certainly be
interested therein...
Actually, there aren't that many missing. The Linux version number took
a jump between 0.12 to 0.95, since Linus thought 1.0 was just around the
corner. In reality, things didn't quite work that way, which is why we
started going to 3-part version number.
One obvious way of demonstrating that there isn't much time elapsed
between the 0.12 kernel and the 0.95 kernel is that they are very
similar in size (although of course the 0.95 kernel is a little bigger. :-)
- Ted
Theodore Y. Ts'o
preserved.
What is much less well-preserved is the old original distributions.
That's because they are bigger, and tended to change over time,
sometimes without necessarily having distinct version numbers.
But something which would definitely worth doing is to compile a history
of all of the various distributions, with beginning and ending dates,
when it was the most popular, who was responsible for doing the
distribution, what key feature(s) the distributions introduced, which
distributions were descended from other distributions, etc.
Guest section DW
But now that I looked anyway, I have collected
all kernels I can find, with the earliest time stamps
I can find, in ftp://ftp.win.tue.nl/pub/linux/kernel.archive .
(Added in a few amusing files, like the License for 1.2.)
Additions are welcome.
Missing for example: 0.99pl13X for all letters X except X=k,
and all earlier sublevels of 0.99.
I have a few boot- and root disks from the 0.97-0.99 era.
May try to put up complete systems later.
Andries
Hans-Joachim Baader
> > Is there a note about which is the oldest kernel version one can
> > actually compile using recent tools (gcc-2.7.2+, binutils-2.8+,
> > make-3.7x+)?
>
>I havenae had a look, sorry...
1.0.9 is compilable with some patches.
I have created a "mega-patch" that contains all the patches to 1.0.9
I'm aware of. This kernel actually did run on my Pentium notebook,
without PCMCIA though...
I should perhaps put it on my web page to give it wider testing...
>
> >> 1.2.0 through 1.2.13
>
> > I once had 1.2.13pl9 and pl10 for m68k Amigas. I'm not sure
> > whether these pl releases were official kernels which had *then*
> > m68k patches applied to them.
I have all kernels since 0.99 in case someone needs them ;-)
> > I also once had at least one kernel which had PATCHLEVEL= or
> > SUBLEVEL= set to "99" in the Makefile. Not sure which version
> > this actually was (it was >=1.2.x), but I remember that the
> > numbers in its tar filename mentioned a slightly different
> > version. Maybe a lookup in the kernel archive could help.
Probably 1.99.x, aka 2.0pre
hjb
--
"Every use of Linux is a proper use of Linux."
-- John "Maddog" Hall, Keynote at the Linux
Kongress in Cologne
Harald Koenig
> On Mon, 23 Nov 1998, Simon Kenyon wrote:
> > On 23-Nov-98 Riley Williams wrote:
> > > I've been looking into setting up a CVS tree that will contain the
> > > full kernel source history...
> > > Put them in a CVS archive, and you replace "sum of kernel source
> > > archive sizes" with "sum of upgrade patch file sizes", and thus
> > > massively reduce the size of the result...
> > > I would suspect the result will fit on a ZipDisk, never mind a CD, but
> > > I'll not know for sure until I get it set up...
> > > Are there any CVS experts out there?
> >
> > now we're getting somewhere
> > trouble is - as the puzzle unfolds, what do you do about the situation where an
> > intermediate release turns up
> >
> > say we have 1.1.1, 1.1.3, 1.1.4
> > put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
> > can cvs/rcs/sccs (you choose) handle this?
>
> That's why we have tags. After checking in 2.1.129, you say
>
> cvs tag linus-2-1-129
>
> After that you can say
>
> cvs co linus-2-1-129
>
> to check out 2.1.129.
correct.
but in the above example, 1-1-2 would be stored as a diff relative to 1-1-4,
and if 1-1-5 will be checked in later, it will be stored as diffs relative
to 1-1-2 resuling in a somewhat suboptimal storage method, right ?
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koe...@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
Riley Williams
> I've just had a look at the SunSite-UK mirror thereof, and note the
> following kernel tarballs thereon, in various directories:
This suggests to me that the stated kernel tarballs are missing...so
if you can cross off the ones that never existed, it'd be appreciated.
> 0.01
=> 0.02 through 0.09
> 0.10
> 0.11
> 0.12
=> Linus jumped the kernel version numbers at this point...
> 0.95
> 0.95a
=> 0.96
> 0.96a (plus patches 2, 3 and 4)
> 0.96b (plus patches 1 and 2)
> 0.96c (plus patches 1 and 2)
> 0.96c+
> 0.97
=> 0.98*
> 0.99 (plus patches 1 through 9 and 11 through 13)
> 0.99.1 through 0.99.7
> 0.99.7A
> 0.99.8 through 0.99.11
> 0.99.12 (plus linux-0.99.12.small-patch)
> 0.99.13
=> 0.99.14
> 0.99.15
=> Did 0.99.16 get renamed 1.0 ?
> 1.0 (plus patches 1 through 9)
=> 1.1
=> 1.1.0 through 1.1.12
> 1.1.13
=> 1.1.14 through 1.1.22
> 1.1.23
=> 1.1.24 through 1.1.28
> 1.1.29
=> 1.1.30 through 1.1.32
> 1.1.33
=> 1.1.34
> 1.1.35
=> 1.1.36 through 1.1.44
> 1.1.45
=> 1.1.46 through 1.1.51
> 1.1.52
=> 1.1.53 through 1.1.58
> 1.1.59
=> 1.1.60 through 1.1.62
> 1.1.63 1.1.64
=> 1.1.63 through 1.1.66
> 1.1.67
=> 1.1.68 and 1.1.69
> 1.1.70 1.1.71
=> 1.1.72
> 1.1.73 1.1.74 1.1.75 1.1.76
=> 1.1.77
> 1.1.78 through 1.1.95
> 1.2.0 through 1.2.13
> 1.3.0
=> 1.3.1
> 1.3.2 through 1.3.100
> pre2.0.1 through pre2.0.14
> 2.0
> 2.0.1 through 2.0.36
> 2.1.0 through 2.1.24
=> 2.1.25 and 2.1.26
> 2.1.27 through 2.1.129
Also, of course, kernels post 2.0.36 and 2.1.129 hadn't appeared when
the original list was posted, so can be ignored for the purposes of
this message...
Best wishes from Riley.
Geert Uytterhoeven
> Geert Uytterhoeven wrote:
> > On Mon, 23 Nov 1998, Simon Kenyon wrote:
> > > On 23-Nov-98 Geert Uytterhoeven wrote:
> > > >> say we have 1.1.1, 1.1.3, 1.1.4
> > > >> put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
> > > >> can cvs/rcs/sccs (you choose) handle this?
> > > >
> > > > That's why we have tags. After checking in 2.1.129, you say
> > > >
> > > > cvs tag linus-2-1-129
> > > >
> > > > After that you can say
> > > >
> > > > cvs co linus-2-1-129
> > > >
> > > > to check out 2.1.129.
> > >
> > >
> > > i put it in rcs
> > > THEN i get 1.1.47
> > > so i put that in rcs
> > > NOW i get 1.1.x where 1 < x < 47
> > >
> > > how do i insert that inbetween 1.1.1 and 1.1.47?
> >
> > internal RCS version numbers. Yes, I made the same mistake some time ago.
> > If a file isn't changed in between Linux release 2.1.128 and 2.1.129, it will
> > have the same (internal) RCS version number in both releases.
> >
> > CVS uses symbolic names (tags) to link the various RCS version numbers with a
> > global release name.
>
> (and this is surely sliding OT rapidly) you will end up with a *much*
> larger source-control database if you check revs in the wrong order ?
Yes.
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Neil Conway
Neil
Alex Buell
> I have a few boot- and root disks from the 0.97-0.99 era.
> May try to put up complete systems later.
Question is: Will 0.01 work? Can I just install it and see it run like
shit off a shovel?! :)
This is a question that's been bugging me for a while. What's the EARLIEST
kernel that will still work with all the wonderful stuff that we have
including glibc2? :)
I'll be hornsblowed if 0.01 will run..
Cheers,
Alex.
---
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
Check out http://www.tahallah.demon.co.uk
Linux lo-pc3035a 2.1.129 #9 Thu Nov 19 14:23:26 EST 1998
One Intel Pentium 166MHz processor, 66.36 total bogomips, 16M RAM
System library 5.4.44
Johnny Tevessen
[recent tools]
> 1.0.9 is compilable with some patches.
> I should perhaps put it on my web page to give it wider testing...
I guess these are no "official" patches, so could they be included
in the kernel archive?
> > > I also once had at least one kernel which had PATCHLEVEL= or
> > > SUBLEVEL= set to "99" in the Makefile. Not sure which version
> > > this actually was (it was >=1.2.x), but I remember that the
> > > numbers in its tar filename mentioned a slightly different
> > > version. Maybe a lookup in the kernel archive could help.
>
> Probably 1.99.x, aka 2.0pre
Another thing to mention for the yet-to-write history file.
ciao,
johnny
--
Trust no-one.
-
Guest section DW
From: "J. S. Connell" <an...@canuck.gen.nz>
On Mon, 23 Nov 1998, Guest section DW wrote:
> You can do it yourself. No effort is required.
May I ask where you found UNIX v5 and a PDP-11 simulator?
There are several around.
I think the one I showed was from
ftp://ftp.digital.com/pub/DEC/sim/sources/
Andries
Guest section DW
This suggests to me that the stated kernel tarballs are missing...so
if you can cross off the ones that never existed, it'd be appreciated.
Roughly speaking, nothing is missing since 0.10,
except possibly for testreleases, prereleases, intermediate releases
like 0.99pl12d, and the like.
Go to ftp.funet.fi to find a good collection.
Then look at ftp.win.tue.nl to find an almost identical collection,
with very few things added. (But with the patches only, not the
full kernels, except for the early ones.)