5 ms·
Answer: 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 sub
by ovi256 3y ago
Answer: 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.
- eru 3y agoThey also didn't care nearly as much about performance. Or to be more precise, they had very different trade-offs to make. Back then, you could have a system call and context switch for every read and live with the overhead. Today we have something like io_uring.
- msla 3y agoBack then, fitting in RAM was a big problem: The PDP-11 (the first kind of computer to run Unix, as opposed to UNICS) had a 16-bit address space, which gives you 64 K of RAM if you ignore the fact peripherals were memory-mapped and so took addresses away from actual memory. Later models had split I+D, or separate address spaces for Instructions and Data, but that's still only 128 K. https://gunkies.org/wiki/PDP-11_Memory_Management https://gunkies.org/wiki/PDP-11_Memory_Management
- shrubble 3y agoLater models could address 18 (256k) or 22 bits (4Mbytes) of memory.
- systems_glitch 3y agoStill restricted to I+D of 128K mapped in at any given time, plus your 8K of I/O space for bank 7.
- dezgeg 3y agoI'd guess that back then system call overhead was lower than with modern CPUs with deep pipelines, speculation and their vulnerability workarounds.
- pixl97 3y agoI'm thinking most stuff was designed around single core performance. Lots of drivers had big'ole gigantic locks which really killed multi processor performance. These days with modern CPUs with a ton of cores the complexity has increased greatly.
- paulddraper 3y agoIt wasn't lower. But people put up with it. Because they had to; there just wasn't a viable alternative
- cmrdporcupine 3y agoFor sure, and up until the mid-to-late 80s RAM speeds were higher than processor speeds. So approaches to architecture were totally different. Most minicomputer class processors were sewn together from multiple chips and transistors; even their register sets for the CPU were often not dissimilar from main memory. Texas Instrument's minicomputer (and later microcomputer) architecture even just put registers in RAM. In the microcomputer world, the 6502 got around having a very small register set by just having a 256-byte "zero page" with slightly faster cycle access than regular memory. There was no need for complicated cache hierarchies. Relative cost of a context switch or interrupt or transition from user space to kernel etc. was way lower than now. And the users of the system were by and large trusted. Security was more of a suggestion.
- pmontra 3y agoWe did care about performance because 1 MHz was slow even back then and data bus were slow too. However we had to care more about memory size because we couldn't fit much in a few kB or 1 or 2 MB for huge machines. Finally, compilation time for substantial programs were... substantial! You could play games as in that sword fighting xkcd.
- bluetomcat 3y agoWith virtual memory and demand paging, memory management (done efficiently) becomes a much harder problem, too.
- tgv 3y agoUnix V7 had virtual memory, at least, I can remember the PDP-11 disk unit throwing itself around violently when somebody started nroff.
- inkyoto 3y ago> the PDP-11 disk unit throwing itself around violently when somebody started nroff. That was the overlays… the early days substitute for the virtual memory proper. If I remember correctly, the first PDP-11 to have the true virtual memory and a MMU was PDP-11/70 which had 18-bit wide hardware addresses.
- thequux 3y agoThe 11/70 had a 22-bit wide memory bus and an 18-bit wide unibus which was mapped to the high 256kb of the 4M physical address space.
- inkyoto 3y agoYou are correct. I have long forgotten about the mapped memory and was thinking about Unibus device registers having long 18-bit addresses. The 11/70 also had separate instruction and data spaces which did not exist in earlier models.
- arethuza 3y agoMany years ago the team I worked out got some shiny new Sun 4 machines and we soon ran out of disk space - solution was to plug a cabinet full of a few old huge disks that I think came from some kind of ancient mini into a Sun 3 and then NFS the new storage onto the Sun 4s. It was truly bizarre to watch the cabinet judder and shake as we accessed stuff - I think there were only 2 disks in it and it was mostly full!
- mdp2021 3y agoLatest 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,000 tools 4.2% 107,971,000 arch 8.3% 943,527,000 drivers 72.2% Based on rough byte count (total 1,306,548,000 bytes in the above).
- uaeu321321 3y agoarch seems pretty essential and it's still at 107m. hardware is complex, no way around it.
- bluGill 3y agoI'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.
- cmrdporcupine 3y agoAs sibling pointed out, to be fair you'd want to somehow restrict arch/ down to one only architecture.
- rurban 3y agoFreeRTOS on the other hand is just two C files. And a proper secure microkernel much less.
- jhoechtl 3y agoThey also did't care that much about * unit testing * framework boiler plate * testing pragmas * mockups
- Conlectus 3y agoIf you’ve read any of the code you’ll also know that early Unix was full of security vulnerabilities. Eg. Statically allocating fixed buffers and not checking input sizes. I’m all for appreciating simplicity, but let’s not pretend we haven’t progressed since then.
- Joker_vD 3y agoNot only early Unix; look at the original inet_addr implementation [0]. It accepts not only "0x" but also just "x" as the 16-base prefix, it doesn't really care about the numbers overflowing, and it parses 09 as equal to 011 (which is decimal 9). And the less said about the coding style, the better. [0] https://github.com/dank101/4.2BSD/blob/master/lib/libc/inet/inet_addr.c https://github.com/dank101/4.2BSD/blob/master/lib/libc/inet/...
- cogman10 3y agoThere were also a lot of practical limitations on the hardware that need to be recognized. These weren't devices that could store megabytes of data for code or memory. Not only that, but the compilers were also a lot dumber (by necessity). So, optimizations you'd normally leave up to the compiler (like inlining) you instead did by hand.
- jandrese 3y agoThis part is frequently lost on people. Bell labs developed a multi-user operating system that supported multiple people logged in at the same time on a machine with 64 kilowords (144kB) of storage. Later development was done on a machine that supported a max of 4MB of memory and had to allow for hundreds of simultaneous logins. Keeping the code compact was a high priority, even over usability in some cases.
- 3y ago
- wkat4242 3y agoBut 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.
- hnfong 3y agoI'm only speaking from impression, but I think early Unix's userland is probably comparable with busybox in terms of code size and features.