Desktop computer systems, especially those based on Linux, are way more complicated than typical personal computers in the 80s and 90s. We can learn by looking back. Can we make a friendly Libre Desktop operating system with focus on simplicity, minimalist elegance, and usability?
Once upon a time, things were easy. Today they are not. Back in time when things were easy, things “just worked” right out of the box and you did not have to configure much. Contrast this with today: Too many things to be configured, and everything that can be configured can go wrong. Back in time when things were easy, everything could be done by drag-and-drop in the file manager, without other tools. Contrast this with today: Too many things cannot be achieved by the file manager anymore.
Some of this is clearly going to be controversial, and people will tell me that some of this is backwards. Still, I would like to point out some things I found much easier in the 80s and 90s compared to today, and I would like to get back some of the original simplicity.
Reduce to the max. — Smart
Decoupling of the hardware from the OS and of the OS from the applications
Back in time when things were easy: In the 80s, your typical personal computer had one or more floppy drives (removable disks). Typically you had a System disk on which the operating system resided, and one or more application disks (where one or more applications resided). These things were decoupled from each other — the personal computer could be used with many different System disks, and each System disk could be used with many different application disks. The same application disks could also be used with different System disks.
Contrast this with today: From that point on, things became more cumbersome all the time because the system disk became tightly coupled to the hardware with the advent of built-in hard disk. All of a sudden it was not so easy anymore to use multiple different operating systems with the same machine. Similarly, applications got installed into the system partition, thus “married” to the operating system. All of a sudden it was not so easy anymore to run the same applications with multiple operating systems, or to run the same operating system instance interchangeably on different physical computers, even of the same type. The absolute worst case is e.g., a Windows computer where the operating system will run only from the built-in disk which is soldered onto the motherboard, and where applications are tied into the operating system by app store and DRM mechanisms. The result is that one can factually use the computer only with one operating system instance, and one set of applications tightly integrated into it. Even most contemporary open source systems are not much better in this regard because there, too, an operating system typically assumes that it has the whole disk (or at least one whole partition) at its exclusive discretion, and applications are closely tied into one operating system instance. What was simple once — choosing which operating system instance to boot, and choosing which applications to run on it, has become really cumbersome.
How could we simplify: Decouple the boot volume from the hardware by using removable media, decouple the operating system from the disk by not having it assume it has one partition of its own for its exclusive use, decouple applications from the operating system by not “marrying” them into the operating system partition. Allow unlimited physical disks to be used with the hardware. Allow unlimited operating systems to reside on the same disk alongside each other (as space permits). Allow applications to work with different operating system instances by keeping them separate from the system.
Booting
Software minimalism. — Me
Early boot
Back in time when things were easy: No bootloader to configure. Just insert one (or more) bootable floppies, bootable SCSI hard disks (think USB) or other bootable devices. Those could be internal to the computer or externally attached.
Contrast this with today: Where do I even start. Everything is so complicated.
How could we simplify: Write a GUI bootloader that does away with all text mode and that just boots the disk that has been “blessed” (e.g., by setting an EFI variable) without further configurability at boot time.
Select boot device
Back in time when things were easy: In the case of multiple bootable disks, a simple Chooser let you select from within the operating system which one the computer would boot from the next time it was restarted.
Contrast this with today: Screens with complicated text which one can only make sense of if one is an operating system developer.
How could we simplify: Write a GUI for “blessing” the boot volume and store the selection in NVRAM. I think EFI has a spec for this, but are there easy GUI tools that match the elegance of the Startup Disk control panel?
Store preferences across boot disks
Back in time when things were easy: You made certain settings (e.g., timezone, keyboard language) once and it would work regardless which boot disk you were booting from, because things were stored in a piece of memory on the logic board.
Contrast this with today: Each operating system manages its own preferences, and they do not share. With the result that if I set things like the timezone or keyboard language in one system, it does not mean that the other systems know about it. Try it yourself, throw 5 operating systems on your computer — chances are 0% that the clock will show up correctly in all of them. Even if the 5 operating systems are all different Linux distributions.
How could we simplify: Standardize on EFI NVRAM variables for things like timezone and keyboard language, and make use of them.
Manageable units
Number of files in the system
Back in time when things were easy: Tens to hundreds of files in a typical system.
Contrast this with today: Hundreds of thousands of files in a typical system. At least a factor of thousand more complex and practically incomprehensible and and unmanageable for normal users.
How could we simplify: Encapsulate complexity by grouping files that belong together into manageable opaque units in the file system. Make each application one file. For example, in the Haiku operating system each application is one package, and each package is one file that is loop-mounted into the filesystem to make its contents accessible. Similarly, AppImage follows the “one app = one file” philosophy. Make the operating system one file. Linux Live ISOs that are loop-mounted for booting come to mind. SystemImageKit shows that it is possible on Linux.
Knowing what every part of the system does
Back in time when things were easy: I was able to tell for each single one what it was doing and where to search if something went wrong.
Contrast this with today: Probably no one knows what each one of them is doing.
File manager
The objects are the real thing, not just a view on the thing
Back in time when things were easy: The objects you saw on the screen gave you the impression that they were the actual things, and each object had one and only one on-screen representation in the system. For example, an application had one icon and existed only once on the system. For example, you used the same icon to launch, move, copy, delete, update an application, or to move it into or out of the start menu.
Contrast this with today: The objects you see on the screen make it apparent that they are not the things themselves, but only views onto the things that actually are going on in the computer. What is especially troublesome is that each object can have multiple on-screen representations in the system. For example, an application can show up in many different locations in the system: On the desktop, in a window that shows the desktop, in the launch, in the start menu, in the package manager. For example, you need to use different representations of the same application depending on whether you want to launch (start menu), move (impossible), copy (impossible), delete (package manager), update (package manager) an application, or to move it into or out of the start menu (start menu editor tool).
How could we simplify: Make sure that each object on the system (e.g., an application) has only one representation that lives in one place, and in one place only.
Spatial file manager
Back in time when things were easy: Each window of the file manager kept the arrangement of objects on the screen. Each file was located in exactly one window, which could have different settings than other windows.
Contrast this with today: No matter how you organize the files, they get shown differently next time you open the window. Each file can be shown in more than one window, which results in a mess (even on contemporary Macs).
How could we simplify: Spatial file manager enabled by default.
Application management
One app = one file (or directory)
Back in time when things were easy: Each application consisted of one file, which contained both the program code and all related resources (icons, menus, graphics). Later “one file” became “one directory” but the basic idea stayed the same — an application could be “managed” by drag-and-drop.
Contrast this with today: An application consists of many files that are scattered all around in the file system, so it becomes difficult to impossible to manage applications by hand, because there is no one file or one directory that one could simply copy, move, delete in the file manager.
How could we simplify: Use AppImage.
Being able to run applications from any location
Back in time when things were easy: You could drag-and-drop an application anywhere, and it would still run. Simple as that. There was no assumption in the system that an application had to be in one certain location in the filesystem.
Contrast this with today: An application gets installed to a fixed location, usually on the system partition. If that disk is full, you can’t just put the application somewhere else easily and expect it to still work.
How could we simplify: Make applications relocatable in the filesystem by default.
Being able to have multiple versions of applications around
Back in time when things were easy: You could have as many versions of applications next to each other as you wanted.
Contrast this with today: Many systems assume that there has to be only one version of an application around.
How could we simplify: Remove the assumption that there should be only one version of each application on the system.
Offline use
Offline by default
Back in time when things were easy: You got an application on physical media, and could be sure the physical media contained all the application needed to run on systems that matched the system requirements. Even decades later, if you have a compliant system and the application media, you can run the application just like you could back in the day.
Contrast this with today: Software is built under the assumption that each machine is connected to the Internet, and that software repositories belonging to the operating system are available. Neither holds true all the time, making it harder than necessary to operate offline (“air-gapped”) machines, and making it next to impossible to run the software we are running now in, say, decades from now when all the repositories will long have gone offline.
How could we simplify: Build software under the assumption that machines are offline. (If they are online, that’d be the exception rather than the rule.) Do not allow third-party software to have any dependencies other than what comes with the system by default. Require that everything else an application needs to run is privately bundled with the application.
QC’d software with few updates
Back in time when things were easy: You could opt into purchasing major (feature) upgrades every 2–3 years, and got minor (quality) updates for free very infrequently (say, 1–2 times a year). You made a conscious decision whether and when to apply upgrades or updates, and to which applications. You usually applied updates only if there was a specific reason (e.g., a feature you wanted or a bug you were running into and needed to be fixed). Systems typically ran on the exact same software configuration for months if not years.
Contrast this with today: Systems increasingly become “moving targets” because both the operating system and the applications change by updating themselves at will, without conscious decisions by the user. The absolute perversion of this are “forced automatic updates” as are common in some organizations, where users have no choice but to accept that updates are installed on the machine (even requiring reboots of the machine) whenever some central system administrator decides that it is time to do so. To a lesser extent, commercial operating systems like Windows are forcing updates onto users in a similar manner, and the trend even is there on some open source systems where there is the assumption that all parts of the system should be “kept current” (I call it a “moving target”) all the time. Today, there is a certain “sloppiness” in QC because the assumption is that you can push updates to users all the time. The result is that applications like Firefox or Chrome have multiple “major” versions every year with factually no user-visible changes. (Agile development methods and continuous releases are one thing but should not be confused with assuming that it is OK to push half-baked stuff to desktop end users all the time.)
How could we simplify: Make all updating happen only on the explicit request of the user. Only update an application if a user actively requests a particular application to be updated. Keep around the old and new version in parallel, so that the user can switch back and forth between them until the user decides to no longer keep the old version. Do not assume that only because the user wants application X to be updated, they also want all other applications or the operating system to be updated as well. Only offer major application updates if there are enough new features that really make a difference that justify an update, and overall try to keep updates to a minimum. Only push out updates to users once software has undergone deep QC. Acknowledge that updates are a burden for users (they cost bandwidth, time, and are sources of potential trouble to formerly working systems) and should be the rare exception rather than the rule.
“Personal” computers
No multi-user, no passwords by default
Back in time when things were easy: “personal” computers were built under the assumption that one machine would serve one user, and there were no passwords or other measures that make it cumbersome to use the system for the sake of “security”. The concept of a “user account” did not exist throughout the 80s and 90s for most personal computer systems.
Contrast this with today: Systems feel like they were made for multi-user operation in large organizations where there are system administrators, rather than individual users with personal machines. You are requested to create an account to log into your own computer, even on tiny hardware like a Raspberry Pi. Making certain changes to the system requires you to know and use an “administrator account”. (I am no administrator, and I have no administrator; I am just a “mere mortal” user.)
How could we simplify: One unrestricted user by default for everything. If you want multi-user and passwords, this should be opt-in and optional.
Privacy
Statelessness
Back in time when things were easy: Using the computer did not produce traces of its usage. If you ran MS-DOS or the Macintosh system from a locked disk, no changes were ever written to the system.
Contrast this with today: Try running Windows from a read-only disk. Is it even possible? On modern systems, using the computer leaves many traces of every action a user does, e.g., in log files that track every launch of an application with a timestamp. Worse, persistent cookies that survive reboots make it possible for online services to track users over time,
How could we simplify: Log files only written to a temporary in-memory filesystem that does not survive reboots. Read-only operating system partition (or filesystem image) by default. No persistent state between reboots, no cookies that survive reboots.
Robustness
Immutability
Back in time when things were easy: If you ran MS-DOS or the Macintosh system from a locked disk, no changes were ever written to the system and you could be reasonably sure that the system was not changing itself and would continue to run for decades. It was easy to build a checksum over the disk to audit its integrity.
Contrast this with today: Try running Windows from a read-only disk. Is it even possible? On modern systems, the operating system assumes that it can change stuff at will, and as a result, things can break. In ever-changing systems, meaningful check-summing to audit the integrity of a system is next to impossible.
How could we simplify: Read-only operating system partition (or filesystem image) by default.
As little configurability as possible
Less, but better. — Dieter Rams
Back in time when things were easy: Each system of a certain type behaved more or less the same, predictable way. On each installation of Word, the third icon in the toolbar was the same icon for everyone. It was easy to give phone support because two systems looked exactly alike.
Contrast this with today: Everything is complicated by the fact that everything can be configured so that as a result, no two systems are identical. You can no longer be sure that the third icon in the toolbar is the same for your neighbor as it is for you. This is amplified by a tendency of elements in the user interface to be reshuffled from version to version.
How could we simplify: Sane defaults that work for the majority of users, as little configurability as possible. Make it trivial to revert to “default configuration”. Avoid reshuffling the location of things in user interfaces from version to version.
Build systems for the long run
Back in time when things were easy: Systems could run unchanged for decades. To this day (2019), I get support requests from Windows XP users. And I still spot the occasional MS-DOS or Windows 2000 boot screen on public kiosk systems.
Contrast this with today: Built-in obsolescence where an operating system is expected to no longer be functional within just a couple of years.
How could we simplify: Build systems under the assumption that they might continue to be in operation for decades.
Summary
Yes, I really want a simple, personal computer system again. No accounts, “security”, constant forced updating. A lightweight system in which the user can know and understand (at least at a high level) all components of the system and is in the driver seat. Not some real or virtual “administrator”. Systems that can sustainably run for decades in offline mode. In this article, I have hopefully made clear what I mean by this — not just some “sugar coating” on the interface, but removing (or at least encapsulating) lot of the baggage and complexity that modern systems have piled up, and re-imagining the simplicity end “it just works” elegance of personal computer systems in the 80s and 90s.
Is it time to make a new personal computer system? Don’t get me wrong, it’d not be about cloning the looks of ancient Mac. It’d be about bringing the spirit , simplicity, and elegance of that system to today’s computing world. The spirit of the original 1980s Mac, reimagined for the 2020s.
The closest system to do this I know currently is Haiku. Is it perfect yet? Hell no. Does it conceptually get things right? Hell yes, in a lot of cases.
The Linux desktop has so much to learn.
Want to do something about it?
Now, Constructive Discontent should eventually lead to action, or else it won’t be that “constructive” after all. Hence the question, can we make a friendly Libre Desktop operating system with focus on simplicity, minimalist elegance, and usability (think Macintosh System 1), without the complexities of Linux distributions?
Head over to the “hello” Wiki to learn more. If the ideas there resonate with you, get in touch: This project will live from YOUR involvement. I have ideas, do you have the time and motivation to implement them? Be sure to contact me.
Also check out my series on #LinuxUsability (part 1, part 2,part 3, part 4, part 5, part 6) and
probono is the founder and lead developer of the AppImage project, and a contributor to hundreds of open source projects. Screencasts were made using the Basilisk II AppImage and the Peek AppImage on a Linux Live ISO booted with SystemImageKit.
