In this edition:

• Graham reminisces on his own experience as a software engineer at Apple and its peculiar methodology choices.
• Adrian points out Apple’s infamous disdain of third-party developers.
• In our Vidéothèque section, we watch Steve Jobs getting trolled during WWDC'97, and then French journalist Sonia Devillers analyzing the terrible “Crush” advertising campaign.
• In the Library section, we review “Apple: The Inside Story of Intrigue, Egomania, and Business Blunders” by Jim Carlton, and “Revolution in the Valley: The Insanely Great Story of How the Mac Was Made,” by Andy Hertzfeld.

Download this issue in DRM-free PDF or EPUB format, and read it on your preferred device. You can also subscribe to our RSS feed, featuring the full content of our articles.

We would like to thank our patrons who generously contribute every month (or have contributed in the past) to our work and help us run this magazine. Thank you so much! In alphabetical order: Adam Guest, Adrian Tineo Cabello, Benjamin Sheldon, Christopher Nascone, Colin Powell, Franz Lucien Moersdorf, Guillermo Ramos Álvarez, Jean-Paul de Vooght, Dr. Juande Santander-Vela, Patryk Matuszewski, Paul Hudson, Quico Moya, Roger Turner, Szymon Licau, and countless more leaving anonymous tips every month.

Enjoy this issue! Please share our articles on social media, or contribute if you would like to support our work with a donation via Liberapay.

Cover photo by Zhiyue on Unsplash.

In many ways, this period coincides with the death of software engineering methodology. Methodology is the study of method; not the engineering of software, but the engineering of software engineering. The people who went on that famous Snowbird skiing holiday that generated the Agile manifesto were a mix of people who make software, people who manage people who make software, people who tell other people how to make software, and people who think about how people go about making software; with that last group being the methodologists. These people compared notes on the ways in which they worked, which were all biased towards so-called “lightweight methods” that optimise for learning what people want, making software that does that, then checking whether anything’s changed. What they came up with was a document that said to do that. Get software out to your customer as quickly as you can, work with them to understand what to do next, and do not be afraid of finding out that they (now) want something else.

That is such broadly applicable (and vague) advice that it has never been superseded. Everyone thinks they are doing that, whether they are following by-the-book Scrum, a poorly understood Scrumbut process, or any of the other Lean, XP, Kanban etc. processes that you come across. The only real attempts at modernising methodology in the quarter-decade since Agile killed it have been devops and continuous delivery, and those have both been restatements of the ideas of agile software development. The core message of devops—that everyone working on software should work on the same thing—is the message about “self-organising teams” that is one of the principles behind agile software development. Continuous delivery is even a phrase borrowed from that same list of principles.

Instead of improvements to methodology, we have tool advocacy—the idea that a new programming language, large language model, or cloud deployment platform is a silver bullet that solves every problem. With no new approaches to software design since OOP, new programming languages offer “post-object” objects that are basically the same thing but with slightly different approaches to memory management or threading. Design itself has embraced the JFDI—Just Fucking Do It—ideology, with design choices being laundry lists of technologies to adopt where the choices are explicit at all.

That means that when I walk into a new software shop—or connect to their group video call, which is much more likely these days—I have a good idea of what to expect. There is going to be a two-pizza team, probably mostly programmers with an “ops person” or two, a “QA person” or two, and a “product owner”. When they describe their architecture, it is actually their technology laundry list, which is mostly open source components with maybe a couple of proprietary bits, commonly Slack, Github, AWS/GCloud/Azure, and perhaps the commercial version of something like MongoDB. They have a long “backlog” of tickets in a task tracker or a virtual kanban board, and once every 1-4 weeks the product owner suggests which ones to work on next. The team work out how many they think they can do, take those away, assign each of them to a programmer, and then when each programmer is done they assign their ticket to the QA, and then it goes to the ops person, and then it is in “staging” or “pre-prod”, and so on.

I also already have a good idea of why that team is getting slower at delivering on expectations from “the business”, why customers are becoming less satisfied with the product, and why a lot of the people are grumpy; and a few solid interventions to turn that around and create a high-performing team. You will find my rates very reasonable, by the way.

While that is my model of how software teams do work and should work, not every team that I join does work like that. And some of the surprises are eye-opening. Take Apple, a company that I have worked for as both a contractor and employee, across multiple cross-functional teams led by sponsors in different divisions. You count up the number of people employed as software engineers and related roles and you are well into five figures. They report to multiple different sub-organizations in the company, with the effect that sometimes the first manager in common between two programmers who need to work together might be the CEO.

You will not find much information about how Apple works, beyond this HBR article that they are happy to share on their website. What it describes is a functional, not geographic or sectoral, division of labour. Each engineer is in a team responsible for a different part of a huge, integrated system, with thousands of components that come together to make about half a dozen operating systems, productivity apps, creativity apps, server components, retail support systems, and so on—products that involve thousands of engineers where any pair might not directly communicate at all during the course of a release. How can that possibly work?

Well, the answer appears to be “very nicely, thank you very much”. They routinely have successful product launches, and a higher revenue or profit per employee than any of those two-pizza teams that are a better fit to my mental model. Fred Brooks and Melvin Conway tell us that communication problems should overwhelm productivity as organizations get larger, and yet here is one of the largest software orgs on the planet also carrying on being one of the most productive. Sure, there are bugs, and people who do not like the products, but that is largely the result of trying to please billions of people with the same products. The list of things that literally do not work, as a fraction of the list of things that should work, is not all that big.

And that is really the lesson I want to communicate when it comes to software engineering methodology: one that is more about you and me than it is about Apple. Any organization that is well outside your comfort zone is not necessarily doing it wrong, they are doing it differently. If my experience over the last 20 years had mostly been at Silicon Valley giants, then I would have a model of software engineering that matches what they do, and I would be very shocked by those little two-pizza teams who try to run a whole business from a single room. Approach new situations with humility, and an eagerness to adapt or discard your model. Of course look for opportunities to improve the system, but also pay attention to the things that do not need improving just because they do not align with your preconceptions. You might find that they work very nicely, thank you very much.

Cover photo by Shelley Pauls on Unsplash.

During those weird times, around the turn of the millennium, Apple was desperately trying not to go bankrupt and forgotten. So Steve Jobs did something that he really hated doing: opening their platform for outside developers to create software for it.

In those long-forgotten days, Apple would have a strong commitment to open sourcing as many software thingies from their ecosystem as possible and touting that through a now largely forgotten web page nobody cares about. It also made sure Java developers felt at home, even allowing them to create Cocoa applications with it, instead of having to use the (ugh!) Objective-C programming language.

But there were clear limits to that unusual love for developers: for example, the iPod, which is celebrating its 25th anniversary as this article hits the web, was famously closed for external developers, and never saw anything resembling an App Store for it. And to be honest, even the iPhone was about to suffer the same fate when it was first released in August 2007; we had to wait until March 2008 to have the confirmation of an upcoming “iPhone SDK,” which turned out to be, ironically enough, quite the cash cow for the company.

Because it is a quite accepted fact by all biographers of Apple and Steve Jobs that the man hated third-party software developers with passion. The man did not want to see software he had not personally approved on those machines he was selling.

It was not always like this. Here is a famous example: in page 34 of the May 1977 issue of BYTE Magazine, Steve Wozniak himself proceeded to describe in astonishing detail the ins and outs of the Apple II, arguably one of the most popular 8-bit computers of all time. His description included various snippets of sample code, board electronics schemas, and various screenshots.

To me, a personal computer should be small, reliable, convenient to use and inexpensive.
(…)
The latest result of my design activities is the Apple-II which is the main subject of this system description article. The Apple-II builds upon this idea by providing a computer with more memory capability, a read only memory (ROM) BASIC interpreter, color video graphics as well as point graphics and character graphics, and extended systems software.

Imagine Apple providing such circuit schemas nowadays, for example for their latest MacBook Pro with PROLED XDR touchscreen and M5 Max CPUs, enabling the Asahi Linux team to finally deliver a proper experience with full driver support. The dream!

But… no. The issue is that the idea of offering an appliance to consumers (a mantra that pretty much defines Apple in its entirety nowadays) is anathema to that of opening their (admittedly crippled) APIs to others to play with, no matter how hard said developers scream.

This attitude is (maybe) also what explains why Apple makes arguably the best computers on the market: fast, lightweight, snappy, and (relatively) secure. But also crippled by what increasingly appears as a bloated operating system, filled with a gazillion features hastily copied from others, exposing an array of quite broken APIs to software developers, and offering a set of programming tools to third-party developers that cannot be called anything else but pathetic.

These days, the only reason a software developer should choose a Mac as a software development tool is, precisely, to build software for the many Apple official operating systems (macOS, iOS, iPadOS, watchOS, tvOS, and whatever runs CarPlay or the recently released HomePod). The rest of the world could not care less about those restrictive APIs, or about the sad programming language (Swift) with which those developers should be fighting all day long to get shit done.

While the rest of the world moves into automation, CI/CD, DevOps, containers, Kubernetes, AI, and whatnot, developers stuck in the Apple ecosystem must still fight against Xcode and its various shenanigans to get anything done. The situation has not improved in a whole decade, which clearly shows that not giving a shit about developers is just about corporate policy at this point.

(Yes, this author knows that Apple has provided an implementation of the OCI standard in the form of the open-source container project on GitHub, but to be honest, I still have to see one of those containers in the wild at this point.)

Apple’s legendary developer micromanagement chromosome has always been problematic, but right now it is ridiculous. Of course, they now own the complete software delivery platform, from the CPUs to the IDEs and the marketplaces, so it is ridiculous to expect any betterment in the developer experience anytime soon.

Sadly, the only way the company could react to this state of things would be a major liquidity and bankruptcy event, but Apple’s cash reserves (unironically generated in great proportion through the hard of indie developers) have never been so humongous at any other time in history, so the recommendation of the author of these lines to any person new to IT is to avoid dealing with Apple-sanctioned developer tools as much as possible.

Cover photo by John Warg on Unsplash.

Maybe-Hamisch opens (in response to an earlier question about the demise of OpenDoc, a technology for building componentised document-centric software instead of monolithic applications) with “more of a comment than a question”:

Mr. Jobs, you’re a bright and influential man. It’s sad and clear that on several counts you’ve discussed you don’t know what you’re talking about. I would like for example for you to express in clear terms how say Java in any of its incarnations addresses any of the ideas embodied in OpenDoc. And when you’re finished with that perhaps you could tell us what you personally have been doing for the last seven years.

This person could have merely waited 29 years to grab a copy of Steve Jobs in Exile and discovered that the answer to the last part is that Steve was raising a kid, running Pixar, and putting in sporadic levels of effort when it came to running NeXT, hyper-focusing on some details while leaving others untouched or even sabotaging parts of the work.

However, he stated the not-question, and the rest is history: Steve pauses, drinks his water, pauses some more, then gives an answer. An answer that simultaneously demolishes the request while also allowing for the possibility that it might be true. That Apple’s responsibility is to start with the customer experience and work back to the technology they need, not to build cool technology and try to work out how to market it. Some mistakes will get made on the way, “and that’s good because it means decisions are being made”.

And it is true; both that Apple became an experience-focused company that first gave us computers that do not crash when you so much as look at them, then as many songs as we could fit in our pockets, then real pocket web browsers. And also that they made mistakes along the way.

Let us go back to the original almost-question, which asked in what ways Java was comparable to OpenDoc. At the time, Apple were huge Java fanboys, and Gil Amelio (then CEO of Apple Computer) reports discussing Java and Rhapsody with Steve in their advisory meetings.

When you run a “beleagured” computer company with a tiny market share, Java offers clear benefits: any software someone writes in Java automatically becomes available on your platform. There are no killer apps for your computer any more, but then there are not any for your competitors’ computers either; everything runs everywhere. But more than that, Java offered the first scaled-up realisation of the object-oriented vision.

Apple had bet on Java with the Mac OS Runtime for Java (MRJ), which supported Java software and browser applets on the classic Mac OS. When they integrated the NeXT technology, they went even deeper, providing Cocoa-Java (née Yellow Box Java) access to the OPENSTEP APIs from the Java virtual machine, and even replatforming WebObjects entirely onto Java.

Launch a developer release of Rhapsody (the transitional, server version of OPENSTEP on the Mac that became Mac OS X) or the early versions of Mac OS X and you are running Java everywhere, because someone at Apple wrote it once. At various times, the TextEdit app, System Preferences, and even Login Window got ported to Java—and then ported back to Objective-C, after people noticed that their Macs ground to a halt for a minute or so while they loaded the Java runtime environment from a slow spinning hard disk.

Further, developers did not really get onboard either. A lot of long-running Mac developers were betting on Carbon (either directly, or indirectly via PowerPlant) to keep their investment in the classic Mac OS technology valid, the refugees from NeXT knew that Objective-C was superior to Java anyway so did not feel the need to switch, and people new to the platform similarly seemed happy enough with ObjC.

So in a way, maybe-Hamisch was correct. It was a mistake to bet on Java. But Steve was also correct: the goal was to make things that customers want, and there are a billion more Apple customers today than there were on that day in 1997.

Cover snapshot chosen by the author.

As part of this reconciliation, in 1991 started broadcasting in continental Europe a new, quite innovative binational TV channel, called “Arte”; a very poetic name that apparently also serves as an acronym for “Association relative à la télévision européenne.” A distinctive feature of this channel, available in most cable TV subscriptions for decades, was that it included programs produced in both French and German languages, with subtitles or dubbing whenever required. Arte quickly gained recognition for the quality of its productions, the depth of its analysis, and the pan-European perspective it brought to otherwise segregated cultures.

A sign of the times, Arte is nowadays arguably the most interesting channel you could watch on YouTube and is also available as a specialized app in most smart TVs and all smartphones on the market. The content showcased therein is nothing short of astonishing, from documentaries to debate to music, and in the latter case, from live classical concerts to the wildest of electronica raves. It could be described as the antithesis to TikTok: a place where you can find “content” (what a horrendous word, really) that makes you think.

Remember thinking? Yeah.

Among those programs, there is this series of shorts called “Le dessous des images,” a French name that translates to “Behind the Scenes” or “The Story Behind the Pictures.” As is the tradition in Arte, the name of the series is also translated to German, in this case “Mit offenen Augen,” or literally, “With Open Eyes.” Both names complement each other and describe the idea very well: in each edition, French journalist Sonia Devillers explains the rationale, the creation, and the cultural impact of a particular photography or video in our world. A simple idea at first, yet a monumental and essential work.

Madame Devillers started her career as a journalist in the French newspaper “Le Figaro” and progressively moved into radio and, finally, in 2022, started hosting “Le dessous des images” on Arte. Initially only available online, the series ended up being broadcasted on the main TV channel from 2023 onwards. In this program she dissects the ins and outs of those images that make our world: those memes that circulate online, those reels on Instagram, those photographs on press outlets. Images that flash into our brain and, in a single sight, tell a whole story about the (sometimes sad) state of our world.

Thus came to be a criticism of a particular advertising campaign from 2024 by Apple, previously available on YouTube, but do not click on that link! The video has been made private since and still is at the time of the publication of this article.

Apple diehards and fanbois will probably remember it well: a massive press, compressing a wide set of objects–a piano, computer screens, a record player, a typewriter, a guitar, books, a lamp, reminiscing of Pixar’s “Luxo,” an arcade game from the 1970s, sculptures, tables, and cans of paint–in a massive and frankly disgusting process, somehow inspired by the wonders of those statistical bullshit machines LLMs, falsely referred to as Artificial “Intelligence.”

And at the end of the video, in a perverse act of magic, all of those things merge and combine and disappear under the weight of the press in the shape of “the new” (at the time) iPad Pro.

I do not think we need to say more.

Apple has a long and fruitful history of advertising feats. Come to mind the canonical examples, like the “1984” Macintosh commercial directed by Ridley Scott himself, the 1999 “Think Different” campaign, or the memorable and goofy “I’m a Mac, I’m a PC” series, a real hit two decades ago.

But this campaign, well, needless to say, it was a miss. And the voices online claimed blood, as is usually the case with social media. In this case, truth be told, this author agrees with their observations. This campaign was a rare event in tasteless production, and even worse, coming from a company that has usually done a better job.

The backlash was such that in a very rare instance of corporate humility and real courage, Apple’s vice president of marketing Tor Myhren publicly apologized for it:

We missed the mark with this video, and we’re sorry.

Apology accepted, Tor.

Some images, like that of Kohl and Mitterand holding hands, inspire a sense of history in the making, of progress, of reconciliation, leaving centuries of animosity behind them and opening the door to new possibilities. Some others, however, like in the case of Apple’s infamous “Crush” advertising, feed a narrative of disdain and hubris that is unnecessary, horrid, and frankly tasteless. Such a narrative opens the door to the dismissal of centuries of work and craft in the name of a sacrosaint “modernity” that is not.

Maybe the most important message in this episode of “Le dessous des images” for those in our industry is that the past must not be crushed, synthesized, or forgotten but studied, cherished, and learned from. A lesson that many easily forget after joining the industry: their eyes blurred by all the hype around those shiny new things surrounding us all the time.

Watch “Apple: la pomme écrasée par sa pub” (in French, but featuring autogenerated English subtitles) on the “Le dessous des images” channel on YouTube.

Cover snapshot chosen by the author.

In fairness, the history parts of the book are accurate as they go. Apple was already on a downturn by the time the Macintosh became a huge hit that turned the company into a multi-billion firm. John Sculley, the sugar-water seller from Pepsi who had successfully turned Apple into a lifestyle brand, had countered a boardroom coup from company co-founder Steve Jobs by turning it into a “him or me” situation, and the board had chosen Sculley.

Unfortunately, it turned out that Sculley did not know as much about turning small electronics devices into desirable customer experiences as Jobs did (and, as NeXT would discover, Jobs did not know as much about it as he thought he did either). Further, while Steve had told the board that he would take a few low-level employees to go and work on his startup, he had actually poached some key people which left gaps throughout the organisation.

Apple did still have some great people, including Jean-Louis Gassée, the man who had clued the board into Jobs’s machinations, but none of the people at the top could agree. Or maybe John Sculley could not get along with anyone. Regardless, Gassée was out soon, having disagreed on how to position the Mac (he thought it was a premium product that should command a premium price; others wanted to extend down into the lower end of the market, including by licensing their technology to partners).

A pattern was established; the director of European operations would move into a key role in the Cupertino HQ. But it was not Gassée who became CEO in 1993, having already been fired and started Be. Ironically, Sculley was also interested in licensing Apple’s technology, and the board could not stomach it, along with his focus on one of Gassée’s pet projects, the Newton; he was forced out and replaced by COO Michael Spindler, who had come from the European office.

“I never was an operations guy”, said Spindler. As you can probably tell, a company that had a “not operations guy” as director of European operations, then as COO, had some problems. Those problems continued when Spindler became CEO. His great idea was a sell-off of the company. In fairness Apple and Sun Microsystems seem to have had a recurring meeting in the calendar about merging, but could never make it stick. Given that this was Spindler’s only idea (the target of the merger being the variable part), he was out.

And so in came Gil Amelio, who only has the position as Apple’s second-shortest CEO tenure because John Ternus needs to last another 438 days (from the day of this article’s publication) to overtake him. Famous as the CEO who tried to point the sinking ship in the right direction, Amelio oversaw an Apple with confusing product lines, directionless engineering departments working on competing products, almost no cash, and inventory that mysteriously moved between warehouses depending on whether Apple or a reseller were preparing their accounts.

He is often derided as the worst person ever to run Apple, but only because the subsequent incumbent was very uncomplimentary. The Apple that Amelio took over had a few weeks of cash in the bank; the Apple that he left had a few months of cash in the bank, and the wherewithal to spend $400M on acquiring cutting-edge technology and expertise. However, part of that money went on hiring the CEO of the acquisition company as an advisor (Steve Jobs again), and the advice was that the CEO needed to go. Jobs himself was uninterested in running Apple, as he was having too much fun over at Pixar.

And that is where the story ends, as far as Carlton’s publishers are concerned. It would be a short while before Apple appointed Jobs as the interim CEO (iCEO), but the book had already gone to the press at that point. Carlton suggests a few potential candidates for 1997’s least-competitive CEO vacancy:

• Bob Frankenberg, formerly CEO of Novell.
• Eric Schmidt, then CEO of Novell, potentially most famous today as the long-time CEO of Google.
• Del Yocam, former Apple COO and CEO of Borland.

He suggests whoever takes the job has their work cut out. With Windows NT being the clear leader in the operating system market, Apple’s strategy of dividing its attention between the legacy Mac OS and the Rhapsody platform based on NeXT’s technology looks hugely risky. Indeed, so bad a poison apple (sorry) is the Apple platform, that even the clone makers are trying to get out of the Mac market and into Wintel machines. Microsoft is already winning accounts in Apple’s key markets, education and DTP, and Intel’s new MMX technology makes their CPUs competitive with the otherwise superior PowerPC architecture for graphics-rich applications.

Carlton suggests that the best thing to do with Apple is to pursue the often-abandoned merger strategy; perhaps with a consumer electronics leader like Sony or Philips, perhaps with a telco like AT&T or MCI. A telco merger would open up the opportunity to sell “smart phones, or portable phones with computer features”.

Let us see how that works out.

Cover photo by the author.

The word “insanely” is highlighted in the previous paragraph, because it is an adverb that was particularly cherished by Steve Jobs. And it is no coincidence that it appears on the title of this month’s Library choice: “Revolution in the Valley: The Insanely Great Story of How the Mac Was Made,” by Andy Hertzfeld, a noted member of the original Apple Macintosh team.

This book was published by O’Reilly in 2005, precisely 21 years after the original Macintosh was released, marking the actual “Twentieth Anniversary” celebration.

Mr. Hertzfeld first poured the memories onto a web page in early 2004, still available at the time of this writing, with the tantalizing and peculiar domain name Folklore.org. The book is simply a beautiful printed copy of the material on that website, and another example of a “coffee table book,” just like “The Computer” by Jens Müller and Julius Wiedemann or “Home Computers” by Alex Wiltshire and John Short, two beautiful and interesting books we have talked about in previous editions of this magazine.

“Revolution in the Valley” is as fun to read as it is to explore, telling the story of the making of the Macintosh in short vignettes. Each of the chapters, which to a large degree can be read separately from one another, focuses on this or that particular aspect of the final product. The making of the software, the signatures of the team inside the enclosure, the clash between Steve Jobs and Adam Osborne, the evolution of the iconography by Susan Kare, the disk drive, Microsoft BASIC (or its lack thereof), Burrell Smith’s passion for pineapple pizza, the meaning of the “Real Artists Ship” mantra, and so much more.

The book expands on the website in one particular aspect, making it a gem and a treasure to hold and explore: the photography. The illustrations are sumptuous, from early paper sketches of various ideas to the development of prototypes to magazine covers and even printouts of drawings made with early versions of MacPaint.

And yes, there are a lot of coding shenanigans spread throughout the book (we know our audience very well, see?), including how Andy Hertzfeld thought that lines of code were a meaningless metric (and rightfully so), the use of the Hungarian notation developed by Charles Simonyi from Microsoft, which was quite on vogue at the time, or how one Bill Atkinson programming year was equivalent, according to Steve Jobs, to six standard man-years of coding (and how Hertzfeld thought this was a modest estimate).

The first Mac was, in hindsight, quite a watershed moment for the industry, so advanced for its time, that it took Microsoft 10 years from that point to release a proper user interface on their own operating system. Simultaneously, Apple was busy becoming almost extinct, only to be spectacularly reborn again in the 2000s, but that is a different folklore for somebody else to talk about.

Cover photo by the author.

In this edition:

• Graham wonders whether the idea of a hierarchical file system makes sense at all in 2026.
• Adrian goes back in time to find the origin of the “everything is a file” moniker.
• In our Vidéothèque section, Adrian reviews a documentary about the Unix file system on the AT&T Tech Channel.
• In the Library section, Graham reviews the Apple Computer, Inc. developer manual explaining the file system in the 1990s.

Download this issue in DRM-free PDF or EPUB format, and read it on your preferred device. You can also subscribe to our RSS feed, featuring the full content of our articles.

We would like to thank our patrons who generously contribute every month (or have contributed in the past) to our work and help us run this magazine. Thank you so much! In alphabetical order: Adam Guest, Adrian Tineo Cabello, Benjamin Sheldon, Christopher Nascone, Colin Powell, Franz Lucien Moersdorf, Guillermo Ramos Álvarez, Jean-Paul de Vooght, Dr. Juande Santander-Vela, Patryk Matuszewski, Paul Hudson, Quico Moya, Roger Turner, Szymon Licau, and countless more leaving anonymous tips every month.

Enjoy this issue! Please share our articles on social media, or contribute if you would like to support our work with a donation via Liberapay.

Cover photo by Maksym Kaharlytskyi on Unsplash.

Early examples of such file systems have a single level of structure; you create directories at the top level, and files in those directories (this actually means that there are two levels of directory, because there must be a top-level index to find the directories you create). These have one of two purposes:

1. Help a person organise their files in a way that makes it easier to find them.
2. Keep multiple people who use a time-sharing system from getting in each others’ way, by giving them separate areas to store their files.

In 1965, someone on the Multics project notices that the laws of physics do not apply to computers, and you can fit a folder inside another folder. The arbitrarily-nested hierarchical file system is born. Now users on Multics and its progeny, Unix, can organise their files, and do so while keeping out of each others’ way! Access control stops any account reading, writing, or deleting another account’s files, unless someone who can change the rules gives that account explicit permission.

Unfortunately, as anybody who ever deleted /vmunix or C:\COMMAND.COM knows, saving user accounts from each other is not the whole story. We also need to save the operating system from the people using the computer. This means a new requirement:

3. Keep multiple people who use a time-sharing system from interfering with the operating system, by making operating system files inaccessible from regular accounts.

But because we already shipped the multi-user filesystem and designed the file-access APIs around it, we cannot add this requirement to the model. So we invent a fiction: the operating system is another user account, or a collection of user accounts, that share the filesystem with the actual people who use the computer. So maybe the mail server has its own user account, and the print spool daemon, and so on.

Unfortunately, even this does not solve the problem, because the person who runs the computer needs to be able to configure, patch, and update the operating system. That person then gets access to an account that can work with all the files on the filesystem, starting at the root of the whole hierarchy: call it the root account.

They get that access, but they do not need that access, and indeed they should not have that access, because a person with the root account can violate requirements 2 and 3: they can get in another user’s way, and they can interfere with the operating system. Ideally the filesystem would help with requirement 1 and strictly enforce requirements 2-3, but the user-permissions model does not lend itself to that possibility. So add another layer to the cake: mandatory access controls stop people from fiddling with particular files, even if their user account has discretionary permission to operate on those files.

Unfortunately, computers no longer exist in isolation (nor did they at the time; but we assumed that someone who connected up a tape drive and spooled the contents of the tape into their local installation had a reason for doing so). People download files from the internet, and they download files from the internet that are programs, and they expect to run those programs, and they do not want for one bad (or well-intentioned but poorly coded) program to break the files they use in other programs, or even to read those files unless that is their explicit intent. Time to add a new requirement:

4. Keep the documents that a person creates using a computer private and intact, even when that person runs arbitrary software.

Mandatory access control no longer cuts it; now the filesystem needs a dynamic level of protection, in which files created by different processes are maybe usable from other processes run by the same user account, but maybe not. It depends on what those processes are, and what the files are, too. And where the files came from, and whether the person using the computer intended to get the file, or whether the process they ran just sorta created it for them without telling them. And also, those processes want to keep their own files, to cache downloads, to store the working set from complex computations, to save configuration options, and for whatever purposes.

5. Keep the files that arbitrary software creates private and intact, even when a person uses that or other arbitrary software.

Oh, and by the way, while all of that is going on, there are now so many files that even requirement 1 is long forgotten. People cannot remember whether that important report due tomorrow is in their Desktop folder, or in Desktop/Desktop.old, or in Desktop/Desktop.old/from_dell, or in their Documents folder, or in some unique folder that is managed by whichever app it is they use to edit the file.

6. Help a person to find documents in a labyrinthine structure of folders that they do not understand.

…it is always possible that they accidentally deleted the file they need, or that they kept the file but deleted a critical section of the report that, on reflection, they realised the audience is actually going to care about.

7. Help a person to browse and restore previous versions of a file, and deleted files.

…or maybe they were just saving the file as the battery on their laptop finally discharged?

8. Provide resilience to common hardware failures that lead to incorrectly or partially committed filesystem changes.

…or, no, wait, I remember, the correct version of the report is on my desktop, I have been editing the version on my laptop, I will get that other version once it syncs via my cloud provider.

9. (to a high number, probably around 94). Act as a cache to a remote file storage system; maintain most recently-used files locally while still evicting files as needed to make space for other files a person requests; resolve version conflicts when the remote version and the local version both have changes since the last sync point; resolve conflicts when one version has changes and the other version is deleted; retain confidentiality and integrity over the remote sync interface…

And we need to go back and redefine the idea of “users of a time-sharing system” that we mentioned in requirements 2-3, and invented in about 1965. You see, those time-sharing systems have changed somewhat. Some are little portable devices, so the person whose “account” is “logged in” gives them to a passing acquaintance to share a fun meme they saw. Some are big wall-mounted devices, so the person is using the system alongside six other people who can all see and interact with it.

But yeah, sure, I guess it is neat that the last time we improved the file system was ZFS circa 2005, and that the other file systems are still catching up.

Photo by Jack Krzysik on Unsplash.

CTSS’s fundamental model of human-computer interaction (…) can still be found today at the heart of MS-DOS, Windows, Macintosh, Linux, and many other operating systems. So can such innovations as CTSS’s “hierarchical” file system, a scheme devised by Corbató and his team to enable individual groups and individual users to organize their personal files into “directories” and “subdirectories” on the 7094’s hard disks. (In modern-day Windows and Macintosh systems, of course, such directories are called folders.)

Waldrop forgot to mention Linux, itself a derivative of Unix, where a quick man 7 hier command will display the complete description of the filesystem hierarchy, finally providing some light on the intricacies of the various /etc, /usr, /home, and /var folders.

Beyond the mere organization of data, the Unix lineage of operating systems took Corbató’s hierarchical concept and elevated it into something akin to an arcane voodoo artiluge. This is true of Linux, macOS, and the BSDs, but not so much Android and iOS, because let us be honest, it is quite tough to use a command line with these last two, and iOS’s “File” application is an absolute clusterfuck of an idea.

This “feature” of a voodoo-like file system is probably one of the most salient aspects of Unix-based systems, and it is captured in a famous, four-word axiom of the Unix philosophy: everything is a file. This is one of those phrases that have echoed throughout the ages, similar to you are doing it wrong or the network is the computer; or at least, it did until file systems disappeared beneath the rugged interface of an S3 bucket somewhere in 2005.

To understand the reason behind this idea, we have to look back to the creators of Unix at Bell Labs: Ken Thompson, Dennis Ritchie, and Douglas McIlroy. When they were building Unix from the ashes of the overly complex Multics project, they sought simplicity. Instead of creating a dozen different APIs to talk to a hard drive, a keyboard, a printer, and a network connection, they created just one.

Scarcity is the actual mother of invention, because nobody needed this, really.

They decided that if an abstraction worked for a text document, it should work for everything. (I know, stay with me.) In their worldview, a file was simply a stream of bytes. Consequently, the same system calls used to manipulate a text file (open(), read(), write(), and close()) could be used to interact with virtually every component of the computer. Because why not.

(See? The world was much simpler back in the day.)

Take a walk through the /dev (device) directory on any modern Linux or macOS machine, and you are no longer looking at data stored on a magnetic platter or solid-state drive; you are looking at the hardware itself, masquerading as files!

It goes even deeper. When you type on your keyboard or watch text scroll on your screen, you are interacting with a TTY device (like /dev/tty), a direct descendant of the physical Teletype machines of the 1970s. If you wanted to send text directly to a parallel-port printer in the early days of Linux, you did not need a dedicated printing application; you simply redirected your text into the printer’s file: echo "Hello World" > /dev/lp0. Of course, you would still need a printer, which can be a problem in and of itself.

There are “block devices” like /dev/sda or /dev/nvme0n1, which represent your actual physical hard drives. You can read them directly, bypassing the traditional file system entirely, simply by pointing a tool like cat or dd at them.

Then there are the esoteric, conceptual devices. Need an endless stream of zeroes to wipe a hard drive? Read from /dev/zero. Need a place to send error messages so you never have to see them again? Throw them into the abyss of /dev/null, the file system’s built-in black hole. Need cryptographic randomness? Just read from /dev/urandom, where the kernel distills the chaotic entropy of hardware interrupts into a stream of random bytes. Try it by yourself: run cat /dev/urandom | hexdump -C | head -n 5 in your nearest terminal (well, do not try it if you are running Windows) and you will see some… well, random garbage printed out.

The “everything is a file” philosophy enters the realm of LSD when we look at Inter-Process Communication, or “IPC”. How do two completely isolated programs talk to each other in Unix? By reading and writing to files, of course!

The most iconic manifestation of this is the pipe (represented by the | character in your shell). Conceived by Douglas McIlroy, the pipe takes the standard output (file descriptor 1) of one program and connects it to the standard input (file descriptor 0) of another. But Unix also allows for named pipes: again, you guessed it: persistent files residing on the disk that act as FIFO (First In, First Out) queues. One program opens the file and writes to it, another opens the file and reads from it. To the programs involved, they are just doing standard file I/O.

This abstraction scales up to networking. When you browse the web, your browser communicates over a network socket. In Unix, that socket is treated as a file descriptor. The program writes its HTTP request to the “file” and reads the web server’s response from that same “file.” The underlying networking stack (TCP handshakes, IP routing, Ethernet frames) is completely hidden behind the familiar read() and write() interface. Even complex virtualization tools like Docker rely on this, listening for instructions via a Unix domain socket, usually located at /var/run/docker.sock. Anyone reading this who has ever debugged REST APIs using curl knows this mechanism very well.

If Unix established the “everything is a file” paradigm, the research operating system Plan 9 from Bell Labs perfected it, and modern Linux heavily borrowed from there, taking it from LSD to full-on Ayahuasca level.

Boot up a Linux machine and navigate to /proc. The files you see there take up exactly zero bytes on your hard drive. They exist entirely in the computer’s RAM, dynamically generated by the kernel on the fly. Magic!

The /proc (process) filesystem is an illusion that maps the internal state of the operating system into the file hierarchy. Want to know what CPU you are running? You do not need a specialized hardware diagnostic tool; you just type cat /proc/cpuinfo. Want to see how much memory is free? cat /proc/meminfo.

Every running program on your computer has a dedicated directory in /proc named after its Process ID (PID). Inside that directory are files containing everything from the exact command used to launch the program, to the environmental variables it holds, to the specific areas of memory it is currently using.

Similarly, the /sys (sysfs) directory provides a window into the Linux kernel’s device model. If you are on a Linux laptop and want to check your battery percentage, you do not need a graphical widget. Oh noes, that is for simpleton users. No, you, my dear IT expert, you can simply cat /sys/class/power_supply/BAT0/capacity. Want to change the brightness of your screen? Just write a new number into /sys/class/backlight/intel_backlight/brightness. Und so weiter.

Good luck remembering all of those commands, but hey! Now you know you can.

The Unix file abstraction is considered by many one of the greatest engineering triumphs in software history. Sadly, those “many” are not simple computer users, but actual experts of the industry. Of course, if you look at it closely, yes, it enables composability. Keyboards, displays, network connections, random number generators, and kernel diagnostics all share the exact same interface as a simple text file, making this standard toolkit universally applicable.

I personally think that the Unix file system analogy is not enough. We should be able to listen to Mark Snow’s famous “X-Files Theme” by just typing cat /music/spotify/track/3pDZSfOSszYWMYygDiuPJx. We should be able to swipe Tinder profiles using left /social/tinder/34564576891457. We should be able to search and buy plane tickets with fly /AF/CDG/PPT/business/2027-03-02/2027-04-10. You get the idea. And to be honest, none of the scenarios above would be too complicated to implement (well, except the airline thing, really).

But the truth is that in terms of usability, let us be honest, it is a terrible system. Even for people from the world of IT, it is usually impossible to actually remember all of the myriad combinations available, and which one represents what. You might have a few in mind, or you might create an alias to quickly type one or the other, but the fact that “everything is a file” is barely more than a curiosity to pretty much everyone. Add some complexity points if you switch from Linux to FreeBSD, and suddenly you must cat for files in other locations.

As I said at the beginning, we have not cared about file systems for more than 20 years now. (Remember when you could not have spaces in DOS filenames until circa 1995? If you can, I have bad news for you: you are old.) In Linux, arguably the most nerdy of all operating systems, you might still be choosing between ZFS, EXT, BTRFS, or XFS when formatting a new drive, but nobody cares anymore, really. Windows users are fine with NTFS, Mac users do not even know what APFS is. Gone are the days of using fdisk. Nostalgic OS/2 users might even remember HPFS and shed a tear. Most users probably even use some kind of encryption on top of their file system, just in case. And some ultra-nerd Linux users might be even be interested in Gobolinux, a distribution that literally reorganized the whole hierarchy for… reasons.

These days people are more interested in knowing whether we have a fast SSD in our home computer, or if we have properly configured Ceph, Gluster, or Longhorn within our Kubernetes cluster. And if all else fails, you can always format your USB thumbdrives with FAT32 and make sure that virtually every operating system on Earth can read and write to it.

But whatever you do, remember that this article only caters to systems deriving from Unix, and in particular, do not even think of creating a file named CON on your Windows hard disk. You have been warned.

Cover photo by Alexey Demidov on Unsplash.