Any way to reasonably estimate how long it would take to compile back then? The PDP-11 was 1.25 MHz, Would it be roughly 4000x slower than compiling a 13K-line C program on a modern CPU? Or are computer architectures so much different that CPU speed isn't the primary factor?
How could the early Unix OS comprise so few lines of code?
61–70 of 170 posts
Re: How could the early Unix OS comprise so few lines of code?
#62I feel that most 100K line programs could be rewritten with just 10K lines and end up being more reliable. Feature creep is responsible for some of the code bloat but I can guarantee from experience that, in the vast majority of projects, you could keep all the features and still cut the code to at least 1/10th of its size. I think the reason for this is because developers who focus on development speed do so at the…
If you removed from a complex program any feature that was used by less than 2% of the users the program would be much smaller and simpler. However you also lose each 2%. In many cases every user uses a different subset of what your program does, and so the end result is no users at all because your program is useless.
Re: How could the early Unix OS comprise so few lines of code?
#63Earlier quoted context omitted.
Latest Linux kernel source: 39,000 certs 0.0% 40,000 usr 0.0% 164,000 init 0.0% 240,000 virt 0.0% 250,000 ipc 0.0% 459,000 io_uring 0.0% 664,000 rust 0.1% 980,000 samples 0.1% 1,885,000 block 0.1% 2,850,000 scripts 0.2% 2,953,000 security 0.2% 3,609,000 crypto 0.3% 5,165,000 mm 0.4% 7,156,000 lib 0.5% 12,420,000 kernel 1.0% 33,047,000 net 2.5% 39,916,000 include 3.1% 43,224,000 fs 3.3% 45,001,000 sound 3.4% 54,988,00…
arch seems pretty essential and it's still at 107m. hardware is complex, no way around it.
I'm not familiar with linux, but is arch platforms support for a bunch of different archs - x86, x86_64, arm, arm64, and many more come to mind.
Re: How could the early Unix OS comprise so few lines of code?
#64I feel that most 100K line programs could be rewritten with just 10K lines and end up being more reliable. Feature creep is responsible for some of the code bloat but I can guarantee from experience that, in the vast majority of projects, you could keep all the features and still cut the code to at least 1/10th of its size. I think the reason for this is because developers who focus on development speed do so at the…
First, I think we should use expression count instead of pure LOC because many styles add white space but keep the expression the same. I don’t consider one style “more terse” than another. e.g.
a.map(…).reduce(…).join(…)
a.map(…)
.reduce(…)
.join(…)
Re: How could the early Unix OS comprise so few lines of code?
#65It's really simple - the early Unix kernel had so few lines of code because the machine had so few bytes of memory (180KB I think), and a bigger kernel wouldn't have fit. It's actually worse than that, because the PDP-11 address space was 16 bits, so the kernel had to be It really only had two types of devices - the disk and the serial ports. No network protocols, and a single very simple file system. Basically no virtual memory - it had segmentation, and most memory management was done by swapping processes to disk. More complexity would have to wait for bigger machines with more memory.
Re: How could the early Unix OS comprise so few lines of code?
#66Answer: smaller target to cover! Modern Linux has most code in device drivers to support so many different devices. Then, it supports many targets for other subsystems, like file systems. The original Unix provided one implementation for each subsystem. They relentlessly simplified the problem they were solving to make it doable.
But modern Linux is only the kernel. Early unixes included the userland as well which creates a different balance in types of code. In fact traditional unixes still do, like FreeBSD. Linux is the odd one out with this separation. I think it happened because GNU was not very successful with Hurd but they made great userland so "Linux" became kinda a combo. And for Linus the userland was never really in scope anyway.
I'm only speaking from impression, but I think early Unix's userland is probably comparable with busybox in terms of code size and features.
Re: How could the early Unix OS comprise so few lines of code?
#67[dead]
Re: How could the early Unix OS comprise so few lines of code?
#68Any way to reasonably estimate how long it would take to compile back then? The PDP-11 was 1.25 MHz, Would it be roughly 4000x slower than compiling a 13K-line C program on a modern CPU? Or are computer architectures so much different that CPU speed isn't the primary factor?
C compilers can be very fast. (See for example, https://bellard.org/tcc/tccboot.html )
If I'm not mistaken, much of the work when compiling code these days are optimizations.
Re: How could the early Unix OS comprise so few lines of code?
#69Earlier quoted context omitted.
Latest Linux kernel source: 39,000 certs 0.0% 40,000 usr 0.0% 164,000 init 0.0% 240,000 virt 0.0% 250,000 ipc 0.0% 459,000 io_uring 0.0% 664,000 rust 0.1% 980,000 samples 0.1% 1,885,000 block 0.1% 2,850,000 scripts 0.2% 2,953,000 security 0.2% 3,609,000 crypto 0.3% 5,165,000 mm 0.4% 7,156,000 lib 0.5% 12,420,000 kernel 1.0% 33,047,000 net 2.5% 39,916,000 include 3.1% 43,224,000 fs 3.3% 45,001,000 sound 3.4% 54,988,00…
arch seems pretty essential and it's still at 107m. hardware is complex, no way around it.
As sibling pointed out, to be fair you'd want to somehow restrict arch/ down to one only architecture.
Re: How could the early Unix OS comprise so few lines of code?
#70As mentioned in one of the comments in those threads, a lot of the code in an OS is device drivers, and I'd say that device drivers in the PDP-11 were really simple. You didn't have the multiple layers of serial bus such as PCIe, USB, etc. There was no multiprocessor support, very simple filesystems, probably less than 10% of the POSIX API we know and swear at today was implemented.
Simple I/O was one reason why DEC's minicomputers held their own against the IBM 360, it was easy to make your own Unibus peripherals, whereas peripherals for the 360 required a highly complex "channel" processor; bulk I/O was crazy fast on the 360 but interrupt handling was slow: the PDP-11 could handle individual keystrokes from a serial terminal whereas the 360 would wait until you'd filled out a whole screen of data and hit the SEND key.
I never used Unix on a PDP-11 but I did use RSTS/E and OS of that generation did not dynamically find hardware, instead you would have to rebuild an OS image with the configuration for your setup built in. Thus the PDP-11 expected a control terminal and bootstrap device to be installed on certain ports and you would load some software to build an OS image that you would actually boot up. (Also true of the 360)
https://en.wikipedia.org/wiki/RSTS/E
That dynamism is itself a huge complexity source in modern OS, see Linus' Torvalds comments here
https://www.linuxjournal.com/article/7279
and particularly what he has said about ACPI there and in other places
https://yarchive.net/comp/linux/acpi.html
Before Linux it was common in an OS class to write a boot loader, that was about all you could do in a semester. After Linux you can write a few kernel modules and learn a lot more. If you tried to write a boot loader today it might be an assignment for two semesters for the whole class because today's boot loaders are crazy complex to what they were in the day but you do get some functionality (think of what it takes to be able to boot a live linux distro off a USB stick that has a FAT file system off it.)