student project

pants

OTT.

I notice that you chose ridicule rather than an proper answer.

You misquoted me, and made no sense to boot. That deserves ridicule.

John

Well, it's a bigger project than the OS/360 project was.

I recall reading somewhere that, at some point, os/360 was 3000 man-years behind schedule.

John

John Larkin expounded in news: snipped-for-privacy@4ax.com:

Given that OS/360 was all assembly language, I think of _that_ as a much bigger undertaking than the linux kernel. Certainly I think in terms of man hours, it was.

If you strip away all the device drivers, the plethora of file systems and Gnu stuff like GCC etc. (which isn't kernel anyway), there isn't all that much to the kernel itself, by way of comparison.

Warren

Utter nonsense.

Depends on your metric. I was just comparing the code size. The OS/360 sources were about a million lines of assembly code, while the Linux kernel is over 13 million lines of C code, with each line of C being equivalent to a few assembly instructions.

Also, OS/360 only took about 4 years to produce (1963-1967). The first two years, the staff for the kernel was limited to about 150 programmers, and later peaked at about 1000, but those include technical writers, managers and secretaries.

The Linux kernel has thousands of contributors, although most of the code is produced by a much smaller, but very productive, core group.

What metric are you using ?

Yikes! A decent RTOS could be a few thousand lines. The listing for a DECs timeshare OS could be held in one hand and read in an afternoon.

A really good OS would be hardware, in an FPGA.

John

Depends on your purpose. Linux is not an RTOS. It is mainly targeted towards full-featured, high performance desktops and servers, and that's impossible to achieve in just a few thousand lines.

Of course, the 13 million lines in the Linux kernel include thousands of different device drivers, dozens of file systems, and a bunch of different networking protocols. On a typical system, you'd only use a few.

For small embedded systems, the scalability that you get from Linux is overkill, and you may be better of with an RTOS of only a few thousand lines. For bigger embedded systems, Linux may be attractive if you want easy networking support, a web server, USB host support with various client devices, a journaling flash filesystem, and such things.

Linux, like Windows, is a "big kernel" design. It sure didn't have to be.

And they could be outside the kernel.

Sure. But all that junk doesn't have to be in kernel space. It shouldn't even run on the same CPU.

John

Minimal RT-11 might have been about that size but ISTR DEC TOPS-10 was around a 10MB binary which I would conservatively put at about 50 boxes of printer paper for the printed source.

Small compact RTOS supporting basic I/O can be much smaller, but the OS needed for big iron hardware was never especially compact or all that well written. A few top universities had access to the sourcecode for OS/360 on condition that any refinements were offered back to IBM.

You had to love IBM's workhorse FORTANG1 which because of the way a string had been miscounted and cost benefit analysis prevented it from being fixed would report "NO DIAGNOSTICS GENERATED?" for a successful compilation. The "?" was actually a NULL 0x00 byte if memory serves.

It doesn't need to be in hardware. In can be done by applying hardware methodology or better formal methods and mathematical proofs to the relatively small software needed for the most highly priviledged kernel. Viper attempted to do this but ultimately came unstuck.

I was trying to find a better reference to what went wrong with VIPER - I recall it ending in acrimony but not why. In the process I stumbled on this web page at Staffs Computing dept that may be of historical interest to anyone here interested in the development of early radar.

Regards, Martin Brown

If you care about scalability, like many desktop and server users do, the "big kernel" design is the only realistic approach. Without a "big kernel" you'd end up doing distributed computing, which is very tough to get right, especially if you want good performance.

For smaller, real-time embedded stuff, where scalability isn't much of an issue, the "microkernel" approach is certainly feasible. QNX is an example of a reasonably successful product that does that.

On a sunny day (Fri, 10 Dec 2010 04:39:21 -0800) it happened John Larkin wrote in :

You can pretty much put in 'kernel space' what you want, when compiling the kernel. You can often choose things to be a module,

Even with the essentials compiled in, this is one of my oldest Linux disk: grml: ~ # mount /dev/fd0 /mnt/fd0 mount: block device /dev/fd0 is write-protected, mounting read-only grml: ~ # l /mnt/fd0 total 330 drwxr-xr-x 2 root root 32 1992-09-23 05:27 mnt/ drwxr-xr-x 2 root root 32 1993-03-10 07:47 proc/ drwxr-xr-x 2 root root 32 1993-03-10 07:47 user/ drwxr-xr-x 2 root root 2000 1993-07-01 12:17 dev/ drwxr-xr-x 2 root root 608 1993-07-04 17:57 bin/ drwxr-xr-x 2 root root 80 1993-08-01 19:32 lib/

-rw-r--r-- 1 root root 326148 1993-08-03 12:12 zImage

I was thinking about RSTS/E. All the user interface stuff was loadable "runtime systems", one of which emulated RT11. It's just a matter of where you draw the line around "kernel", and how much code you allow the priviliges of crashing the system.

Windows was originally a small(er) kernel design; read "Showstopper!"

John

Actually a lot of things are being moved out of the Linux kernel.

No. Linux supports hundreds of different platforms and millions of different hardware configurations. No wonder the source code is so large. For an average system only a small portion of the code is used.

Nico Coesel expounded in news: snipped-for-privacy@news.kpnplanet.nl:

..

Not only that, it took 20+ years to balloon to that size. IBM's z/OS is still being revised with each passing year but nobody's counting that.

The initial Linux kernel was way way smaller. On the same order of magnitude of minix, though perhaps larger. There must be an archived version of that somewhere for precise numbers.

Warren

Of course:

Cheers! Rich

programmers,=20

code=20

There are many possible metrics. Here is some interesting info from one of my linux installs that includes the sources (for all supported architectures)

du -h --max-depth=3D1 /usr/src/linux/

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

the original linux kernel was considerably smaller than that.

this is the oldest version I could find on kernel.org. the first distro (SLS) came with an older kernel (0.93.7 IIRC)

$ zcat linux-1.0.tar.gz | wc -l 176250

the above 176250 slightly overestimates the number of lines, and includes all the documentation too. it doesn't include the compiler or other build tools. The CREDITS file lists 80 contributors.

linux development began in 1991, Version 1.0 was released in early 1994