I love gen Z and how entertaining they are. They have this “we know better” mindset and think they can simple discard everything that was done by previous generations, because they know better.
It is an amazing show when Life slaps their face and tells them they know nothing, exactly everybody else.
Good thoughts and the desktop is overdue for some disruption. Here's a bit of feedback, meant in the spirit of helping out with a shared goal. This post is going to sound super negative, but please don't be discouraged: I really want people to find new desktop paradigms that work!
A lot of these ideas have been not only had before but actually implemented and then thrown away, so it's worth studying why they didn't work out. It turns out there's some common themes that you didn't touch on.
1. What you're calling an item based OS was already implemented by both Apple and Microsoft in the 1990s. Apple's version was called OpenDoc and was a more purist version of the data first idea, Microsoft's was OLE and was less so, but they both attempted to rebuild the desktop OS as a primarily data-focused experience in which the app was less central. In OpenDoc you created a new document and then dropped app components into it, and the document, the UI and the file format were all managed by the OS rather than being owned by a specific app. Instead of apps there were pre-canned document templates called "stationary" (yes more paper metaphors).
This tech didn't work out for a few reasons. One was timing: Apple was bleeding money and OpenDoc got cut when Jobs came back, another was that it was very hard to write components for these systems. Those are fixable: the harder one was it was theoretically elegant but the UX was terrible, and it didn't solve a problem users really had. The app-first metaphor made sense to them.
2. Single-language/single-VM OS. Other than Smalltalk, Sun attempted to build a JavaOS and Microsoft ran a decade+ research project called Midori attempting to do the same thing in C#. These didn't work out because: (a) there's no language that is universally good at every task, in particular when it comes to efficiency, (b) the benefits of being single language was less than the benefits of being highly efficient and supporting existing apps written in any language, and (c) the process abstraction does a lot of different things and once you have it the benefits of a shared language mostly go away anyway.
3. Network transparency. So much has been written about this. Old dream, never worked. Network-exposed services are fundamentally different in several ways to in-process or same-machine components.
4. Tagged files. Already implemented since forever in every OS. It's there in macOS, Win 11 and Linux distros. People don't use it, largely because most don't really understand documents or files as first-class concepts to begin with. Nowadays even young people need remedial lessons in how to work with files when they start at university. The more intuitive interface turned out to be app centric, where the user starts an app and then sees their recent/shared documents along with a search bar.
5. Indexed filing systems. BFS gets lionized more than it deserves: its indexing support was very crude and barely usable. Most people who praise it have read about it but not tried to use it as a developer. I haven't either but I at least read the BeFS API docs, which is more than most people have done. Anyway Microsoft invested heavily in the idea of a powered-up filing system in the early 2000s (WinFS), but the project was a total failure and had to be scrapped. Most files are system files not user files, so indexing is of little value, but apps are hyper-sensitive to file access latencies. Doing any additional work on FS hot paths just makes everything sluggish. Also, UX: see (4).
6. Highly dynamic Smalltalk-style VM. Modern operating systems have gone in the opposite direction and lock everything down against changes. One reason is security, another is that apps that hack their way past carefully designed extension interfaces to modify arbitrary stuff cause a ton of system instability and broken upgrades.
7. Intent-based GUIs. This was the XML vision: full separation of data from presentation. It didn't work out partly for random web-specific reasons, partly because XSL:T sucked and was hard to use, but mostly because you don't get much value from separating the two. XML was justified by reference to future AI; the future arrived and the only markup it uses is Markdown i.e. purely presentational. Search engines don't rely on markup much and screen readers - where semantics matter most - seem to be satisfied with lightly decorated node trees.
Sometimes I like to while away some time and daydream about a better desktop OS, but I'm sure it can't be done without buying in 500% to AI and LLMs. For one, any talk of a new way to write apps or GUI toolkit is DOA without addressing the existence of web apps, which are what your user will spend all their time working with and which won't care about anything your new OS does. AI on the other hand could potentially knock up adapters and screen-scrapers on the fly. And if you have pervasive integration of LLMs then things like tagging or indexing become a lot less important to get right, as a sub-optimal UI is only sub-optimal for the AI which can brute force its way through.
If I were to design a new desktop OS today, I'd try and do an "intelligence first" design that assumed pervasive availability of advanced AI, and ask what that lets you re-imagine. I think the result would look nothing like the Alto.
Damn, someone actually read the thing! How rare.
All of what you say does make sense, I'll ponder about it, maybe we can have an actual discussion sometime.
I think if you were serious about something like this, you would go and sell to businesses first: productivity would be at an all-time high. But yeah, in today's world, AI everything everywhere. But I'd argue that makes an even bigger point for an item based OS, as everything is equally accessible for agents.
On (6), Plan 9 had a solution to a similar problem in file system mounts. All FS mounts were in a per-process namespace. Mounting file systems does not require special permissions like on Unix, because these mounts only exist within the process tree that creates them, rather than modifying global state.
Anyway, I'll think about this later, it's 11pm here.
Pluggable file systems work OK (and are supported by every OS already) because the interface is standardized and clients can't modify the internals of the FS or vice-versa. So the interface is enforced. In highly dynamic operating systems like Squeak VMs everything is up for grabs, so you can't evolve such a system because you can't reason about the state it's in.
The point about LLMs is that in reality you can't say "software should work like this". Maybe that was viable in 1990, but so much software has been written since that the designs, toolkits, paradigms: done. Nothing can be changed due to the massive weight of pre-existing software that will never be rewritten. I'm middle aged, and the only new OS designs in my entire lifetime have been iOS/Android where the immaturity of the mobile space allowed a clean slate start. But that was a one-off.
AI lets us imagine new things again because it's getting close to enabling something like "rewrite this giant codebase to use a new UI toolkit for me", or "take this web app, reverse engineer its backing REST API, combine it with that other web app and combine it into a new UI personalized just for me". And that then enables experimentation again: you don't have to wait for third party devs to support your cool new OS if you can get an LLM to hack in and crowbar a form of support via brute force.
Other thoughts: do files even matter anymore if you interact primarily via a chat box? Or is the only thing that matters recorded notes by/for the LLM which can then render whatever view of the user's knowledge base is appropriate? Do apps even matter anymore, or can good enough logic be assembled and written on the fly to suit any request? A lot of reasons why various ideas did or didn't work were to do with business models, but the low cost of inferencing fundamentally changes what works there.
I love gen Z and how entertaining they are. They have this “we know better” mindset and think they can simple discard everything that was done by previous generations, because they know better.
It is an amazing show when Life slaps their face and tells them they know nothing, exactly everybody else.
Have you read the thing? I'm advocating to going back to the foundations laid out by the Alto and Douglas Engelbart. That is literally the opposite
Good thoughts and the desktop is overdue for some disruption. Here's a bit of feedback, meant in the spirit of helping out with a shared goal. This post is going to sound super negative, but please don't be discouraged: I really want people to find new desktop paradigms that work!
A lot of these ideas have been not only had before but actually implemented and then thrown away, so it's worth studying why they didn't work out. It turns out there's some common themes that you didn't touch on.
1. What you're calling an item based OS was already implemented by both Apple and Microsoft in the 1990s. Apple's version was called OpenDoc and was a more purist version of the data first idea, Microsoft's was OLE and was less so, but they both attempted to rebuild the desktop OS as a primarily data-focused experience in which the app was less central. In OpenDoc you created a new document and then dropped app components into it, and the document, the UI and the file format were all managed by the OS rather than being owned by a specific app. Instead of apps there were pre-canned document templates called "stationary" (yes more paper metaphors).
This tech didn't work out for a few reasons. One was timing: Apple was bleeding money and OpenDoc got cut when Jobs came back, another was that it was very hard to write components for these systems. Those are fixable: the harder one was it was theoretically elegant but the UX was terrible, and it didn't solve a problem users really had. The app-first metaphor made sense to them.
2. Single-language/single-VM OS. Other than Smalltalk, Sun attempted to build a JavaOS and Microsoft ran a decade+ research project called Midori attempting to do the same thing in C#. These didn't work out because: (a) there's no language that is universally good at every task, in particular when it comes to efficiency, (b) the benefits of being single language was less than the benefits of being highly efficient and supporting existing apps written in any language, and (c) the process abstraction does a lot of different things and once you have it the benefits of a shared language mostly go away anyway.
3. Network transparency. So much has been written about this. Old dream, never worked. Network-exposed services are fundamentally different in several ways to in-process or same-machine components.
4. Tagged files. Already implemented since forever in every OS. It's there in macOS, Win 11 and Linux distros. People don't use it, largely because most don't really understand documents or files as first-class concepts to begin with. Nowadays even young people need remedial lessons in how to work with files when they start at university. The more intuitive interface turned out to be app centric, where the user starts an app and then sees their recent/shared documents along with a search bar.
5. Indexed filing systems. BFS gets lionized more than it deserves: its indexing support was very crude and barely usable. Most people who praise it have read about it but not tried to use it as a developer. I haven't either but I at least read the BeFS API docs, which is more than most people have done. Anyway Microsoft invested heavily in the idea of a powered-up filing system in the early 2000s (WinFS), but the project was a total failure and had to be scrapped. Most files are system files not user files, so indexing is of little value, but apps are hyper-sensitive to file access latencies. Doing any additional work on FS hot paths just makes everything sluggish. Also, UX: see (4).
6. Highly dynamic Smalltalk-style VM. Modern operating systems have gone in the opposite direction and lock everything down against changes. One reason is security, another is that apps that hack their way past carefully designed extension interfaces to modify arbitrary stuff cause a ton of system instability and broken upgrades.
7. Intent-based GUIs. This was the XML vision: full separation of data from presentation. It didn't work out partly for random web-specific reasons, partly because XSL:T sucked and was hard to use, but mostly because you don't get much value from separating the two. XML was justified by reference to future AI; the future arrived and the only markup it uses is Markdown i.e. purely presentational. Search engines don't rely on markup much and screen readers - where semantics matter most - seem to be satisfied with lightly decorated node trees.
Sometimes I like to while away some time and daydream about a better desktop OS, but I'm sure it can't be done without buying in 500% to AI and LLMs. For one, any talk of a new way to write apps or GUI toolkit is DOA without addressing the existence of web apps, which are what your user will spend all their time working with and which won't care about anything your new OS does. AI on the other hand could potentially knock up adapters and screen-scrapers on the fly. And if you have pervasive integration of LLMs then things like tagging or indexing become a lot less important to get right, as a sub-optimal UI is only sub-optimal for the AI which can brute force its way through.
If I were to design a new desktop OS today, I'd try and do an "intelligence first" design that assumed pervasive availability of advanced AI, and ask what that lets you re-imagine. I think the result would look nothing like the Alto.
Damn, someone actually read the thing! How rare. All of what you say does make sense, I'll ponder about it, maybe we can have an actual discussion sometime.
I think if you were serious about something like this, you would go and sell to businesses first: productivity would be at an all-time high. But yeah, in today's world, AI everything everywhere. But I'd argue that makes an even bigger point for an item based OS, as everything is equally accessible for agents.
On (6), Plan 9 had a solution to a similar problem in file system mounts. All FS mounts were in a per-process namespace. Mounting file systems does not require special permissions like on Unix, because these mounts only exist within the process tree that creates them, rather than modifying global state.
Anyway, I'll think about this later, it's 11pm here.
Pluggable file systems work OK (and are supported by every OS already) because the interface is standardized and clients can't modify the internals of the FS or vice-versa. So the interface is enforced. In highly dynamic operating systems like Squeak VMs everything is up for grabs, so you can't evolve such a system because you can't reason about the state it's in.
The point about LLMs is that in reality you can't say "software should work like this". Maybe that was viable in 1990, but so much software has been written since that the designs, toolkits, paradigms: done. Nothing can be changed due to the massive weight of pre-existing software that will never be rewritten. I'm middle aged, and the only new OS designs in my entire lifetime have been iOS/Android where the immaturity of the mobile space allowed a clean slate start. But that was a one-off.
AI lets us imagine new things again because it's getting close to enabling something like "rewrite this giant codebase to use a new UI toolkit for me", or "take this web app, reverse engineer its backing REST API, combine it with that other web app and combine it into a new UI personalized just for me". And that then enables experimentation again: you don't have to wait for third party devs to support your cool new OS if you can get an LLM to hack in and crowbar a form of support via brute force.
Other thoughts: do files even matter anymore if you interact primarily via a chat box? Or is the only thing that matters recorded notes by/for the LLM which can then render whatever view of the user's knowledge base is appropriate? Do apps even matter anymore, or can good enough logic be assembled and written on the fly to suit any request? A lot of reasons why various ideas did or didn't work were to do with business models, but the low cost of inferencing fundamentally changes what works there.
FWIW the reasons behind Midori's demise were primarily political
I stopped reading at:
"I say that as someone who used Suckless’ st, dwm, surf with tabbed, slock and dmenu"
As I don't know or even recognize any of that jargon, Perhaps that is the point or the article and I am just old.
It is a minimalist software philosophy described by suckless.org:
https://suckless.org/philosophy/
https://suckless.org/sucks/
Many of the projects and libraries listed (st, dwm, etc.) are shown:
https://suckless.org/
None of that really has anything to do with the rest of the article. I'd recommend reading a bit more than the first paragraph.
I read the first few paragraphs... but it was too painful for me to continue as well.
Well, thanks for the feedback. I've shortened some passages, I always had a feeling it was too long but didn't really think about it.