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

101–110 of 170 posts

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

#101

Post by gumby »

thequux wrote: post #96
gumby wrote: post #92

It's interesting where peoples' heads are. A number of people talk about device drivers, but back then few OSes ran on more than one kind of machine, and hardware didn't change much. So there wasn't much separation between hardware and software: you wanted a block of data written to disk, well, the filesystem implemented the code to twiddle the disk hardware directly. Unix was unusual in that it was written in a pret…

Normally, the filesystem wouldn't directly twiddle the disk hardware; even on the PDP-11, you had a bewildering array of disk types: fixed head RC disks, single platter RL01/RL02, multi-platter RK01-RK07, RP disks that were a somewhat more advanced RK (but completely different interface), Massbus disks like the RM04, MSCP disks which were a very weird beast (the programming interface was not entirely unlike io_uring)…

Yes but the question was about the original PDP-7 implementation of Unix, not the port/rewrite for a large volume (by the standards of the day) machine like the -11.

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

#102

Post by jhp123 »

hinkley wrote: post #97
MichaelZuo wrote: post #83

Earlier quoted context omitted.

A classic example of diminishing marginal returns.

Toy solutions deal with small data inputs. How many lines of that 20k is just optimizing for large inputs (you can’t have long repeating sections in small inputs).

I've written a linear-time regex matcher in 65 lines of code: https://jasonhpriestley.com/regex

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

#103

Post by vidarh »

dmazzoni wrote: post #86
vidarh wrote: post #76

Earlier quoted context omitted.

Yes, but part of the argument was that you can often cut drastically without cutting features when you take the time to understand the problem properly. Sometimes everyone actually does use genuinely different features, but more often there are different ways of solving the problem that will still be more concise even if you keep everything. To take a somewhat concrete problem from a past job: We had an agency do a b…

Yeah, but do you really think any of that applies to things like the Linux kernel? You think with thousands of talented developers they have problems as simple as duplicate code?

More developers tends to make duplicated code more likely, not less, as people tend to work on percentage wise smaller subsets of the whole and fewer developers will have a semblance of an overview of the whole. Sometimes also even makes duplication sensible for a while if it allows shortcircuiting communications paths.

The vast majority of kernel code is drivers. That's another reason why the Linux kernel code would be far bigger even if optimal. But it's also why it won't be optimal - the effort to figure out all the shared elements of every device out there is 1) not worth it, 2) going to take someone a lot of time to actually figure out commonalities that may not always be obvious.

I've worked on a driver for the Linux kernel. We didn't even start to look at deduping it because the hardware in question would only ever have our device, and nobody else would have our device. But would there be duplication? Sure. The chip we used was common. For others it might be worth figuring out commonalities with other devices and eventually pare down the code. Or not.

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

#104

Post by vidarh »

hinkley wrote: post #97
MichaelZuo wrote: post #83

Earlier quoted context omitted.

A classic example of diminishing marginal returns.

Toy solutions deal with small data inputs. How many lines of that 20k is just optimizing for large inputs (you can’t have long repeating sections in small inputs).

A lot of it is, but the point remains no matter where you set t he bar, you can usually get most of the benefit with a tiny portion of the code. Sometimes squeezing out a tiny bit more performance isn't worth much, sometimes it's worth 10x or 100x the amount of code - the point is not that it's inherently wrong to write all that extra code.

But you should at least be aware when the returns are diminishing to a point where the payoff becomes uncertain.

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

#105

Post by knorker »

ajross wrote: post #88
Veliladon wrote: post #81

Earlier quoted context omitted.

> Some code practices are what we now consider to be terrible, optimizing for the limitations of that time. This. If you went back to 1972 when Dennis Ritchie was working on C and said "String literals should have an extra machine word for their length and strings should have yet another machine word for the capacity of their buffer" you'd be considered a moron for wasting so much memory.

Not really. C was an iconoclast even at the time. Pascal was the en vogue language of the moment, and it used a length-prefixed string format. But sure: it's true that in (a half century of!) hindsight, C strings were probably a mistake. But don't sell null-terminated strings short either. C could play tricks that Pascal couldn't. Iterating over the characters of a string has a natural expression using the same compi…

Pascal strings had the same size overhead as C strings. One using the "byte" for length, the other for size.

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

#106

Post by compiler-guy »

Joel Spolsky has a terrific article about where all the extra lines come from and why mature codebases tend not to feel as clean.

“ Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.”

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

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

#107

Post by elteto »

knorker wrote: post #105
ajross wrote: post #88

Earlier quoted context omitted.

Not really. C was an iconoclast even at the time. Pascal was the en vogue language of the moment, and it used a length-prefixed string format. But sure: it's true that in (a half century of!) hindsight, C strings were probably a mistake. But don't sell null-terminated strings short either. C could play tricks that Pascal couldn't. Iterating over the characters of a string has a natural expression using the same compi…

Pascal strings had the same size overhead as C strings. One using the "byte" for length, the other for size.

But C strings could at least be arbitrarily long, Pascal strings were extremely handicapped. It’s like they understood why length prefix is better, but then picked the worst possible implementation.

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

#108

Post by ipnon »

compiler-guy wrote: post #106

Joel Spolsky has a terrific article about where all the extra lines come from and why mature codebases tend not to feel as clean. “ Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Int…

Things are much easier when you only need it to run on a single PDP-11 at Bell Labs.

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

#109

Post by vidarh »

jhp123 wrote: post #102
hinkley wrote: post #97

Earlier quoted context omitted.

Toy solutions deal with small data inputs. How many lines of that 20k is just optimizing for large inputs (you can’t have long repeating sections in small inputs).

I've written a linear-time regex matcher in 65 lines of code: https://jasonhpriestley.com/regex

That's beautiful. And I think a great illustration of how much more impactful the "next n lines" or so are going to be than the "last n lines"

EDIT: Also, the impact is even greater when looking at your performance improvements with the dfa conversion as well: https://jasonhpriestley.com/regex-dfa

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

#110

Post by compiler-guy »

knorker wrote: post #105
ajross wrote: post #88

Earlier quoted context omitted.

Not really. C was an iconoclast even at the time. Pascal was the en vogue language of the moment, and it used a length-prefixed string format. But sure: it's true that in (a half century of!) hindsight, C strings were probably a mistake. But don't sell null-terminated strings short either. C could play tricks that Pascal couldn't. Iterating over the characters of a string has a natural expression using the same compi…

Pascal strings had the same size overhead as C strings. One using the "byte" for length, the other for size.

And worse for pascal, a 256 byte limit on the length and api shenanigans so that not every string allocated needed to consume all that memory if the string itself was shorter.
Post reply on HN