Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How could the early Unix OS comprise so few lines of code?

retrocomputing.stackexchange.com

Post reply on HN
Print view View original

31–40 of 170 posts

Re: How could the early Unix OS comprise so few lines of code?

#31

Post by Conlectus »

jhoechtl wrote: post #14
ovi256 wrote: post #2

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.

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.

Re: How could the early Unix OS comprise so few lines of code?

#33

Post by msla »

eru wrote: post #7
ovi256 wrote: post #2

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.

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.

Back 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

Re: How could the early Unix OS comprise so few lines of code?

#34

Post by hardware2win »

benj111 wrote: post #27
mrweasel wrote: post #17

Earlier quoted context omitted.

Especially the features we don't consider. Try replacing your "ls" command with the one found in the original Unix, sure it's 90% smaller, or more, but I guarantee that it doesn't do colors.

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.

It reminds me of that dropbox rsync meme...

Re: How could the early Unix OS comprise so few lines of code?

#35

Post by piva00 »

jongjong wrote: post #24

I 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…

Sure they could but we don't work in a vacuum where succinct code is the product, the business need is the product, with that comes a lot of complexity that only increases exponentially with the size of the organisation.

I can avoid to rush code when working in something internal to my team, the moment I need to work on something that is part of a much larger project then all the issues with synchronisation/coordination crop up, and we don't have the time to spare anymore to go through a 30+ teams/5 orgs interdependencies and play chess with all the permutations of interactions between all systems to arrive at an optimal solution which requires the least code possible. I can work to approximate to that as much as possible but it's simply impossible in a large project spanning many teams, systems and organisations inside the company.

At my job we do use RFCs a lot to do pros/cons analysis, play devil's advocate with each other, communicate with others our ideas and check if the proposals make sense in a larger scope, still business needs trump everything else. If my proposal is "it will take 6 months to do this properly" vs "we can make it work in 2 months if we adapt the existing thing to do thing + A" then the shorter timeline will always be chosen, and as a SWE it's my job to deliver the business value, not to write the perfect code I'd like to.

There's never enough time to write code as we wish we could, it sucks, I'd much rather not have to implement hacks that I know will create future pain to myself and to others but I'm not paid to do that, what is under my control is to try to create as little future pain as possible, documenting all the pitfalls, shortcomings, and issues I can already foresee when a hack-ish feature is implemented.

Yes, most experienced/smart SWEs will know that a lot of software could be written with much less code, when you are experienced you also know that it's just a fantasy, reality constraints shape software and the shape it takes is of a monstrosity, in the end it's just a spin-off variation of Conway's Law: we ship code that reflects business constraints and timelines, not engineering ones.

Re: How could the early Unix OS comprise so few lines of code?

#36

Post by arethuza »

tgv wrote: post #16
bluetomcat wrote: post #8

Earlier quoted context omitted.

With virtual memory and demand paging, memory management (done efficiently) becomes a much harder problem, too.

Unix V7 had virtual memory, at least, I can remember the PDP-11 disk unit throwing itself around violently when somebody started nroff.

Many 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!

Re: How could the early Unix OS comprise so few lines of code?

#37

Post by kot-behemoth »

jongjong wrote: post #24

I 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…

> Before I start working on a feature, I simulate how it's going to work in my head and try to identify all the hurdles and alternatives; sometimes several levels down in the hypothetical component/module hierarchy. I do brainstorms, draw diagrams and make lists of pros-and-cons. I use as many visual aids as I can get.

Remarkably, this is how 37Signal's Shape Up (https://basecamp.com/shapeup) encourages defining feature work prior to building.

In particular, the concepts of Rabbit Hole (as explored with senior developers prior to coding), Breadboarding and Fat Marker Sketches (having a high-level but end-to-end map of the feature) are almost identical to what you're describing.

I found this approach both intuitive in my personal development work, and as a tech lead for lean teams. Funnily, quite a few people really struggle with the concept of "thinking through the feature end-to-end", and not just "let's start with one piece and then figure it out". It's great to do development in small chunks with unknowns, but we still need to know what we are all trying to achieve!

(not affiliated with Shape Up / Basecamp, I just feel Jira leads to hugely suboptimal and waterfall-y processes).

Re: How could the early Unix OS comprise so few lines of code?

#38

Post by jcarrano »

jongjong wrote: post #24

I 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…

I agree 150%. I often find myself, after finishing a "big" application, thinking "well, this must have been thousands of lines". Then I run sloccount or wc and I'm always surprised with how few lines of code I have. The thing is, as you say, I spend more time thinking than writing.

Re: How could the early Unix OS comprise so few lines of code?

#39

Post by lproven »

antaviana wrote: post #29
jongjong wrote: post #24

I 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…

Reminds me of Mark Twain's quote "I didn't have time to write you a short letter, so I wrote you a long one."

Blaise Pascal originally, I believe.

https://quoteinvestigator.com/2012/04/28/shorter-letter/

Great line, though. I use it a lot.

Re: How could the early Unix OS comprise so few lines of code?

#40

Post by mrweasel »

benj111 wrote: post #27
mrweasel wrote: post #17

Earlier quoted context omitted.

Especially the features we don't consider. Try replacing your "ls" command with the one found in the original Unix, sure it's 90% smaller, or more, but I guarantee that it doesn't do colors.

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.

Post reply on HN