[TUHS] 3 essays on the ujnix legacy

[Larry McVoy via TUHS]

These are definitely rose colored glasses versions of history.
I'd argue that SunOS was far closer to a perfect kernel than Solaris.
Solaris wanted to have that title but never did.  It tried but the soul
of the OS sort of left when they switched to System 5.

As for ZFS, I'm the guy that hired Bonwick away from Stanford to
come to Sun and I'm personal friends with Bill Moore.  ZFS is a giant
disapointment to me.  Why?  It undid _years_ of work to have a reasonable
architecture for the page cache.  In BSD, before mmap() came along,
there was just the buffer cache, blocks, inodes, directories were all
in the buffer cache.  mmap() introduced the concept of a page cache,
similar to blocks but not quite the same.  Blocks were read/write
and pages were mmap().  This model sucked because you could have two
copies of a page, one in the page cache and one in the buffer cache.
Creates the classic cache coherency problem, I can stuff in an mmap()ed
page and someone else can change the buffer cache copy of the page at
the same time.

Sun didn't like that model so they did a shit ton of work to redo the
VM system and the I/O system so that there was just one copy of the 
truth: the page cache.  Read/write/mmap all worked on the same pages.
The buffer cache stuck around only for inodes and directories.

ZFS kind of messed with the model because they allowed for compressed
files.  All of the rest of the system knew the size of page.  For example,
in the block list in the inode, it's assumed that each entry (other than a
possible frag at the end which is handled by ino->length) is block sized.
Compression kills that idea, you need more information.

ZFS decided that it was too hard to have compression on top of a page
cache and put back their own buffer cache.  Unforgivable in my mind
after SunOS did such a nice job of unifying everything around the page
cache, ZFS reintroduced a known coherency problem.  I'd give ZFS credit
for a lot of other stuff, but I would have flunked it in the OS course
I was teaching at Stanford.

I get to say that because in BitKeeper we implemented the compressed
(and CRCed and XORed) layer underneath mmap().  We proved that it could
be done, you needed 2 ints per block rather than 1, but there is a body
of code that shows it can be done and it works for read/write/mmap (not
on Windows, that was a shit show).  So when I talked to Bill about it
and he said it was too hard I was hugely disappointed.

These days, there doesn't seem to be anyone who cares enough about clean
OS architecture and wants to fix it.

On Sat, Nov 01, 2025 at 10:42:14AM -0400, A. P. Garcia via TUHS wrote:
> I wanted to share three brief essays I wrote on LinkedIn. I hope it's
> appropriate to share them here.
> 
> The Cathedral, the Bazaar, and the Marketplace
> 
> People sometimes say Linux suffers from a ???Not Invented Here??? problem. They
> pnt to technologies like DTrace and ZFS ??? born in Solaris, admired by
> Linux, but never fully adopted. FreeBSD, macOS, even Windows embraced
> DTrace. Linux went its own way, creating eBPF and Btrfs instead.
> 
> At first glance, it looks like stubbornness. But look closer, and you see a
> deeper truth about how different systems and their communities evolve.
> 
> The Cathedral: Solaris and the Dream of Perfection
> 
> Solaris and the BSDs were cathedral projects: elegant, coherent, and built
> to last. Their philosophy was architectural: design it perfectly once, and
> maintain it forever. That stability made masterpieces like ZFS and DTrace
> possible.
> 
> Cathedrals are slow to change. They preserve beauty, not momentum.
> 
> The Bazaar: Linux and the Art of Reinvention
> 
> Linux took the opposite path. Its ecosystem is messy, distributed, and
> loud, a bazaar where competing ideas coexist until one wins by survival,
> not decree. It doesn???t import technologies wholesale. It reinvents them
> from first principles.
> 
> That???s why instead of adopting DTrace, Linux built eBPF, a programmable
> virtual machine for tracing, networking, and observability. It???s more
> complex, less elegant, but more adaptable.
> 
> This isn???t ???Not Invented Here.??? It???s ???Invented Anew, Every Time.??? It???s a
> culture that prizes autonomy over elegance, vitality over symmetry.
> 
> The Marketplace: Microsoft and the Pragmatism of Scale
> 
> Then there???s Microsoft, once the cathedral???s rival, now a marketplace of
> its own. Its genius has never been invention but absorption: taking good
> ideas from elsewhere and integrating them into something cohesive.
> 
> PowerShell drew from Unix shells and .NET reflection. NTFS inherited DNA
> from VMS. Today, Microsoft ships Linux inside Windows, Edge on Chromium,
> and hosts GitHub ??? the beating heart of open source.
> 
> Yet the uptake of Microsoft???s own open-source tools among Linux users has
> been modest. You can install PowerShell on Ubuntu or .NET on Debian, but
> few do. Not because the tools are bad, but because open source isn???t just a
> license, it???s a language.
> 
> Microsoft???s tools still speak in the idioms of Windows. They solve problems
> that feel foreign in Unix hands. You can open-source the code, but you
> can???t open-source the culture overnight.
> 
> Three Philosophies, One Ecosystem
> 
> -  Solaris / BSD: Design it perfectly, then preserve it.
> -  Linux: Rebuild it constantly, and let it evolve.
> -  Microsoft: Adopt it broadly, and make it familiar.
> 
> Each model has its genius, and its limits. Solaris gave us clarity but
> stagnated. Linux gave us chaos but endurance. Microsoft gave us cohesion,
> and at times, a touch of the blas??.
> 
> But in 2025, the walls between them have thinned. Linux runs in Azure. eBPF
> runs on Windows. Solaris???s spirit lives on in every file system that
> promises self-healing storage.
> 
> The world has evolved since ESR first told us about the Cathedral and the
> Bazaar.
> 
> 
> 
> Before the Bazaar
> The lineage of open collaboration from Bell Labs to the AI Lab to Linux.
> 
> In the early days, Unix was a community. Not a corporate product or a
> stealth research project, but a loose fellowship of programmers trading
> code through tape reels. Thompson and Ritchie gave it away for a nominal
> fee, and universities adopted it because it was small, elegant, and
> instructional. The code moved by post and by modem; ideas moved even
> faster. Every new utility carried someone???s initials in the source
> comments, a quiet signature of a gift freely given.
> 
> Meanwhile, at MIT, another tribe of hackers lived by a similar rhythm,
> though they worked on different machines. Their home was the AI Lab, and
> their world ran on PDP-10s under ITS, a timesharing system they had shaped
> to their own image. It was a place where curiosity outranked hierarchy,
> where anyone could read or patch any program, and where a clever hack was
> its own kind of currency.
> 
> For a while, both cultures thrived on openness. But while the Unix world
> diffused into hundreds of campuses and companies, the AI Lab was a more
> fragile ecosystem. When the hardware aged and the market closed in, that
> ecosystem broke. What had been an everyday freedom, editing each other???s
> code, suddenly became trespass.
> 
> The lab was dying, and everyone could feel it. The old PDP-10s hummed like
> relics, and the laughter that used to spill from the terminals had thinned
> to the occasional keystroke. A printer driver had been locked away behind a
> corporate contract; a colleague left for a company that paid him to keep
> quiet. The code that once bound the room together was vanishing into sealed
> disks and nondisclosure.
> 
> Richard Matthew Stallman stood in the middle of that silence and made a
> decision that would outlast the machines. If the lab was gone, he would
> build another. One not bound by walls or employers. One where the source
> itself would be the meeting place.
> 
> For all the talk of freedom you may have heard from rms, GNU wasn???t born
> from utopia; it was born from grief. It was his hope that a community could
> be written back into existence, line by line.
> 
> Before him, long before the Internet turned collaboration into a torrent,
> there was a room at Bell Labs Center 1127. That was the first bazaar:
> quiet, fluorescent, lined with a PDP-11 and teletype terminals. The people
> who used Unix were the same ones who built it.
> 
> When Ken Thompson or Dennis Ritchie wrote a tool, it wasn???t for customers;
> it was for the colleague one door down. Brian Kernighan would stop by with
> an idea for a text filter. Joe Ossanna needed better document formatting.
> Doug McIlroy wanted to teach the machines how to speak in little,
> composable verbs. By lunchtime, half the lab was using the new tool, and by
> evening, someone else had improved it.
> 
> The same impulse stretches now across continents instead of offices. The
> bazaar simply scaled up the Unix room: at Bell Labs, at the AI Lab at MIT,
> and now in your every git pull.
> 
> 
> 
> The Rhetoric of the Bazaar
> 
> How Eric S. Raymond sold open source as a process improvement.
> 
> When The Cathedral and the Bazaar appeared in the late 1990s, it read like
> field notes from a new frontier. Raymond seemed to be explaining why
> Linux???s sprawling, volunteer army had outpaced corporate software. But the
> essay was more than observation. It was persuasion dressed as ethnography,
> a cultural revolution disguised as engineering advice.
> 
> The narrow slogan
> 
> ???Given enough eyeballs, all bugs are shallow.???
> 
> The line became gospel. Short, clever, and apparently scientific, it
> reduced open collaboration to a form of distributed debugging. Many eyes,
> fewer bugs. Collaboration, in this light, was not a creative act but a
> safety net.
> 
> It was a perfect slogan for the audience he needed. Managers could measure
> defects. Executives could chart release velocity. You could sell that to a
> boardroom. ???Open source fixes bugs faster??? sounds like efficiency; ???open
> source changes how humans organize??? sounds like insurrection.
> 
> The trade
> 
> So Raymond made a trade. He gave up the movement???s breadth for credibility.
> The grand claim, that transparency breeds better design and deeper
> understanding, became a smaller, safer one about quality assurance. And in
> doing so, he made the revolution sound replicable.
> 
> It worked. Netscape opened its code. ???Open source??? replaced ???free
> software.??? Corporations joined the bazaar without ever entering the
> community. They adopted the method, not the meaning.
> 
> The diary as proof
> 
> Even the long detour through fetchmail fits the pattern. It reads like
> autobiography, but it???s really evidence: if this model works for me, it can
> work for you. The diary is a case study, not merely an exposition. Raymond
> wasn???t just documenting open development. He was demonstrating it.
> 
> The legacy
> 
> The quiet compromise of the essay is that by focusing on bugs instead of
> ideology, Raymond made the unfamiliar familiar. He turned rebellion into
> best practice. And in doing so, he helped open source escape the lab and
> enter the market???but also stripped it of its soul.
> 
> It split the movement. The free software camp clung to ethics; the open
> source camp to efficiency. Each accused the other of missing the point.
> 
> Perhaps both did.
> 
> The real power of the bazaar wasn???t in its license or its process. It was
> in the way it made people feel seen, the way a thousand strangers could
> build something together and call it theirs. That???s what made the terminals
> hum and the mailing lists sing.
> 
> The real birth wasn???t a method or a manifesto. It was a new community, just
> another example of what happens when people share a common need and work
> together to make it happen. And it didn???t belong to either banner. It
> belonged to everyone who showed up.

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat