151–160 of 170 posts
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
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…
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(…) If you can accept that expressions are a better metric for “terseness” then I will categorically say your statement is pretty easy to disprove. Essentially you’re saying…
Most people wouldn't appreciate minimalism if they had to use such software on a daily basis.
It was essentially a "time-sharing" system that multiplexes interactive sessions of multiple users on teletype terminals. The "shell" handles such a session by waiting for user input on the terminal, interpreting it and starting external programs as a sub-hierarchy of user processes. On a teletype terminal, you couldn't even have a cursor-oriented editor like vi, but had to rely on line-oriented editors like ed and s…
In a way it became the complete opposite of how it started. At first one OS for many users, ea with many processes. Now, with containers, micro services etc. we have an OS per service/process. Still the original abstractions work surprisingly well though makes it me wonder how a complete redesign of would look like aimed at modern usage.
Earlier quoted context omitted.
In a way it became the complete opposite of how it started. At first one OS for many users, ea with many processes. Now, with containers, micro services etc. we have an OS per service/process. Still the original abstractions work surprisingly well though makes it me wonder how a complete redesign of would look like aimed at modern usage.
But the question is why did we arrive at containers and one OS per "microservice"? Has memory-to-IO bandwidth, scalability requirements, or whatever really changed (like in orders of magnitude) to warrant always-async programming models, even though these measurably destroy process isolation and worsen developer efficiency? After almost 50 years of progress? Or is it the case that containers are more convenient for c…
I think it makes more sense if you consider the interim transition to other isolation mechanisms like commodity servers instead of mainframes, VMs, then containers as a way to get more isolation/security than traditional multi user model with less overhead than an entire machine.
Obviously cloud providers want to push for solutions that offer higher densities but those same cost/efficiency incentives exist outside cloud providers.
I'd say we've more accurately been trying to reinvent proprietary mainframes on commodity hardware.
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?
The source code was distributed on a tape but it was not customary to compile the kernel from scratch every time.
Earlier quoted context omitted.
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.
Because they had to; there just wasn't a viable alternative
Earlier quoted context omitted.
> 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.
The 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.
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.y…