Unix and Google

What Hacker News said

Strong rec mettamage · 2021-06 · on “Glue: The Dark Matter of Software”

I wrote a non-programmer summary to some of my friends, because my mind is blown. Here it is (warning: it's very informal). This is some next level 80/20 stuff, I'd argue it's even 99/1 (consultant speech for "being efficient" by seeing if you can exploit Pareto's principle [0]). A guy on YT [1] simulates in 7 minutes how the two biggest operating systems were built in the sixties (Multics by IBM and Unix by 2 guys in a garage). Nowadays we only have descendants of Unix, this simulation shows IMO two things: 1. How a chain of command screws up productivity (I doubt that anyone at IBM had the power/autonomy to change complete structure of the product. This was needed, but such change manageme

Strong rec deckard1 · 2021-06 · on “Disasters I've seen in a microservices world”

I was going to comment on this very thing in the other thread about software glue[1]. In that article there is a youtube video on Multics vs Unix[2] which really outlines why microservices were always doomed. Someone should coin a new law for how programmers have to rediscover Brooks's law every 5-10 years. The issue with microservices, as it has always been, is that you need an enormous company to brute force the communication pathways and maintenance overhead for it to all work. And by work, I don't mean function efficiently (as the Multics vs Unix video shows). I mean just function . Just work at all. The Multics team had all the devs and the Unix team was two guys doing laps around the M

Recommends kgr · 2016-06 · on “The Strange Birth and Long Life of Unix (2011)”

This video shows how Unix was mathematically more efficient than Multics, which goes a very long way at explaining its success and longevity: [this video]

Recommends kgr · 2019-01 · on “For the Love of Pipes”

I made a simulation and video which shows why the pipe is so powerful: [this video] I showed it to Doug McIlroy, and while he thought there was more to the story, he didn't disagree with it.

Recommends kgr · 2020-06 · on “Apollo – Funding for Moonshots”

This video explains why UNIX was a moonshot, and why it could be developed by a small number of people because of it: [this video]

Recommends foooobaba · 2022-11 · on “Following the Unix philosophy without getting left-pad (2021)”

Programs/functions like left-pad do not follow the unix philosophy (which the author did say). The idea of the unix philosophy is to write less programs. Not write a ton of tiny programs, but a small number of composable programs. So instead of left-pad, right-pad, middle-pad, and anything else to get specific need you can use sprintf which can format a string in general, one program that can do implement the features of all of those. It is about “coding the permitter, not the area”, so if you have NxM features to build, don’t write N*M individual programs/functions, instead write N+M programs/functions that can be composed together to get all NxM features. This video explains it well: [VIDE

Recommends kgr · 2023-08 · on “Unix is both a technology and an idea”

If we analyze the computational complexity of software architectures the way we do regular algorithms, we see that UNIX was much more efficient than previous OSes/approaches. It's demonstrated in this short video: [this video]

Recommends kgr · 2023-09 · on “How could the early Unix OS comprise so few lines of code?”

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: [this video]