Unlike previous OSes, UNIX provided the pipe facility to allow you to combine the functionality of many small programs.
Ex. ls | grep ... | sort ... | more
Before that every command-line program had to support the full suite of additional functionality like search, filtering, paging, etc.
This UNIX/Pipe approach allowed for greater reuse and much less code.
This is explained and simulated in this video:
https://www.youtube.com/watch?v=3Ea3pkTCYx4
How could the early Unix OS comprise so few lines of code?
51–60 of 170 posts
Re: How could the early Unix OS comprise so few lines of code?
#52I disagree that it’s a human or subjective factor as others imply. Or at least to me it’s a secondary contributor.
Back then, the hardware and peripherals were so much simpler. There was no graphical output for the original PDP where Unix was initially developed. Not even a terminal. There was no networking either.
The features of the system were also rather basic (to us). And security wasn’t even a thing they thought about. Some code practices are what we now consider to be terrible, optimizing for the limitations of that time.
So all in all, things have gotten so much more complex since then, and the size and complexity of the code has grown accordingly.
Re: How could the early Unix OS comprise so few lines of code?
#53Lots of unchecked error conditions and security vulnerabilities, apart from the ubiquitous "bloat".
Re: How could the early Unix OS comprise so few lines of code?
#54Earlier quoted context omitted.
They also did't care that much about * unit testing * framework boiler plate * testing pragmas * mockups
If 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.
Not 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/...
Re: How could the early Unix OS comprise so few lines of code?
#55Earlier quoted context omitted.
Most of the time the OS is just overhead now. Look at unikernels for one possible future.
I'm not sure I think the exokernel/unikernel approach by itself is the path forward. While the library operating system approach makes a lot of sense for applications where raw throughput/performance are crucial, they don't offer as much in the way of development luxuries, stability, or security as most modern operating systems. Furthermore, outside of very specific applications the bare metal kind of performance tha…
There's been research into using Linux as the basis for having a unikernel for performance-critical workloads (e.g. database) while retaining all the development /performance-optimization/etc. tooling for both developing the unikernel and for all the other workloads. Of course that doesn't give you a small OS codebase but it does let you optimize for specific workloads.
Re: How could the early Unix OS comprise so few lines of code?
#56I think mindset plays a role as well. Back in the day, there was a restraint on adding features, at least when they would make the logic more complicated for only a tiny or imagined benefit. Part of that was memory/storage limitations. But I think the pursuit of an abstract idea of elegance was equally important. After all, these systems were primarily written for other computer people. This idea is completely gone f…
> This idea is completely gone from the world of software engineering. Systems become overloaded with the implementation of every crappy idea under the sun -- if a PM in a fever dream can think of it, and an overworked dev can hack it together, it goes in. That's a very developer-centric point of view. Elegance and simplicity are great, but if a program is missing crucial features, it becomes less useful or even usel…
> if a program is missing crucial features
A PM's fever dream is almost never a crucial feature. The PM may think it is, may say it is... but it's not.
I agree that software should be written for the benefit of users. But too much of software becomes baroque ornamentation that fills in check boxes on feature lists but is of little actual usefulness.
Re: How could the early Unix OS comprise so few lines of code?
#57Earlier quoted context omitted.
Ls -l tells you whether it's a directory. (-l flag available in the first edition) If you want colours you can pipe it through a sed script. If you want to sort it in some way you could pipe it to sort or something. No system is ever going to do everything everyone wants. The Unix solution is to allow you to easily add the things you do want.
> The Unix solution is to allow you to easily add the things you do want. And yet here we are, with ls having builtin support for color, sorting and more.
The reasons for GNU bloat are well documented, but instead you are arguing over uhh... colour? ls outputting colour or not? Isn't that the very definition of bikeshedding?
Re: How could the early Unix OS comprise so few lines of code?
#58I think mindset plays a role as well. Back in the day, there was a restraint on adding features, at least when they would make the logic more complicated for only a tiny or imagined benefit. Part of that was memory/storage limitations. But I think the pursuit of an abstract idea of elegance was equally important. After all, these systems were primarily written for other computer people. This idea is completely gone f…
> This idea is completely gone from the world of software engineering. Systems become overloaded with the implementation of every crappy idea under the sun -- if a PM in a fever dream can think of it, and an overworked dev can hack it together, it goes in. That's a very developer-centric point of view. Elegance and simplicity are great, but if a program is missing crucial features, it becomes less useful or even usel…
> the vast majority of software is written for the benefit of its users, not that of its developers.
No, the vast majority of software is written for the benefit of the company that's selling it. There's a very, very clear difference there. A lot of this business rests on advertising to people to convince them that the product is good, rather than actually creating a good product.
Have you actually worked a regular job and spoken to people who use software? The large majority of software have bugs that make the program unfit for purpose. The more widely used it is, the more of a monopoly the company producing the software has on the market, and in turn the more likely the product is to be a hot piece of shit.
Re: How could the early Unix OS comprise so few lines of code?
#59Answer: 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.
They 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.
I'd guess that back then system call overhead was lower than with modern CPUs with deep pipelines, speculation and their vulnerability workarounds.
Re: How could the early Unix OS comprise so few lines of code?
#60Not necessary applicable to this case, but from my experience it is more about performance. If you want a solution that works, the solution is usually quite simple. But if you want something that is fast, you often need to do platform specific things, and use fast paths for 'special cases' that occur more often than the 'general case'. These things together will make your code more complicated, but get better performance.
For example, memcpy can be implemented with a very simple loop, but platforms usually provide a much more complicated memcpy that uses vectorization and cache prefetching to get better performance. Compiler autovectorization can give you better performance, but it still cannot beat the hand-tuned memcpy in general.
Another example would be interpreters. You can write a very simple interpreter that works, but if you want better performance, you will need to throw in various techniques that may or may not be machine independent. And in this case, it is more about the algorithm and global invariant that the compiler cannot reason and optimize.
Note: I am not saying that all the code are necessary, I just argue that sometimes you need to sacrifice succinct code to get better performance, and this tradeoff is worthwhile for such a low level infrastructure that everyone depends on.