3 ms·

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

by e-topy 1y ago

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.

mike_hearn 1y ago
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.
- e-topy 1y ago
  My point was that modifications to the higher up system (e.g., file mounts) could be isolated per process (and then trickled down to sub-processes). If the process corrupted the OS' function in any way, only that process would feel it, everything above it would be fine. I do agree that AI could be used as a rare reason to actually innovate in the OS space. > 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? I'd say in an itemized OS with loads of links between items, AI would be more useful than in today's OSes. First, RAG would be faster as it wouldn't have to read everything, instead look for items that are relevant and traverse the tree of links, reading the nodes. Again, metadata. Apple has added stuff like automatic photo metadata (e.g., you snap a photo of a beach, and it automatically gets tagged with #beach; this is also being used by malware to exfil only documents) making AI even more useful. > 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. This actually made me think of the secretary metaphor: Sure, a secretary can do a lot for you, but not everything. You still have the knowledge you need to act on, and will always know what you want to do more than the AI. If the itemized OS had a common API between app's backend and swappable views, a universal AI view would be very easy to implement. On the previous comment: (1) OpenDoc failed for a variety of reasons (https://instadeq.com/blog/posts/why-opendoc-failed-and-then-failed-3-more-times/ https://instadeq.com/blog/posts/why-opendoc-failed-and-then-...), but I'd say the major reason why attempts at this fail is that they're another option of developing apps, and a bad one at that. If it was the only way, and was actually intelligently designed and documented, it might have had a better chance of succeeding. (2) From what I've read (https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/), Midori was a research project, and not a replacement. They started with .NET and C# because they own it, but then departed to custom languages. Their research included stuff like language safety (most of it now in Rust, and it seems they implemented some of it into C++ and C#). Also cool concepts like capabilities instead of permissions (2. post), programs that are multiple separate processes (like Smalltalk's; the lessons learned are now in C#'s await keyword), etc. The articles are a nice read. > there's no language that is universally good at every task, in particular when it comes to efficiency I'd say that Rust is now in a position that it is good enough for most tasks (even websites and AI), and is efficient enough for all of those tasks. Having your entire stack in Rust (or Elixir or most other languages) enables you to have more consistent software as everything is defined in one place only. > (b) the benefits of being single language was less than the benefits of being highly efficient and supporting existing apps written in any language The biggest benefit of being a single language is massive parallelism, especially if you're process/message oriented as Smalltalk or Elixir. Most modern software, unless really pushed (e.g., game engines) still do not use all cores available. There is also an argument to be made that context switching between smaller processes only on messages is faster than switching on modern OSes, and therefore would be more efficient. This would probably have to be implemented to be proven, though. (I'm not as confident on this level of OS design, feel free to disprove me) > (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. Yes, but to an extent. It is still hard to write safe concurrent code in a language like C++, and massive parallelism is hard with current black box binaries. (3) My thought process was a) files mounted over a network act like they're local, b) in a Smalltalk system local and networked objects would appear the same, c) since Smalltalk essentially encapsulates a server, the entire stack is already network like communication. But yes, it would probably only work for certain things, like objects or documents accessible over a network. (4 & 5) My point was that with an itemized OS, tagging and searching through items (non-system) would be better than with today's files. There is also a question of UX making it non-viable for most users. Searching files in Dolphin takes seconds, while doing the exact same thing in CLI with fd takes milliseconds. The end result should be a fast, accurate search engine for everything in your computer (local and remote; this would also augment AI to make it more useful). (7) My idea was more swappable views, views shipped by the developer and custom views that a user could make. I'd recommend looking at User-created item views (https://alexanderobenauer.com/labnotes/009/ https://alexanderobenauer.com/labnotes/009/). This also goes hand in hand with bootstrapping - the user changing their environment so it's easier for them to use. That, I think, is enough value to justify it. And if a developer doesn't think it is necessary, nothing should change for them, but the user should still have the option of making a custom UI (this also goes back to accessibility and AI using the apps). Web apps are a problem, but most are easily replaceable or easily recreated. Specialized apps are a bigger problem (e.g., CAD, video editors). But you could also just link to the web, and link from the web.

by e-topy 1y ago

mike_hearn 1y ago

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.

e-topy 1y ago
My point was that modifications to the higher up system (e.g., file mounts) could be isolated per process (and then trickled down to sub-processes). If the process corrupted the OS' function in any way, only that process would feel it, everything above it would be fine. I do agree that AI could be used as a rare reason to actually innovate in the OS space. > 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? I'd say in an itemized OS with loads of links between items, AI would be more useful than in today's OSes. First, RAG would be faster as it wouldn't have to read everything, instead look for items that are relevant and traverse the tree of links, reading the nodes. Again, metadata. Apple has added stuff like automatic photo metadata (e.g., you snap a photo of a beach, and it automatically gets tagged with #beach; this is also being used by malware to exfil only documents) making AI even more useful. > 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. This actually made me think of the secretary metaphor: Sure, a secretary can do a lot for you, but not everything. You still have the knowledge you need to act on, and will always know what you want to do more than the AI. If the itemized OS had a common API between app's backend and swappable views, a universal AI view would be very easy to implement. On the previous comment: (1) OpenDoc failed for a variety of reasons (https://instadeq.com/blog/posts/why-opendoc-failed-and-then-failed-3-more-times/ https://instadeq.com/blog/posts/why-opendoc-failed-and-then-...), but I'd say the major reason why attempts at this fail is that they're another option of developing apps, and a bad one at that. If it was the only way, and was actually intelligently designed and documented, it might have had a better chance of succeeding. (2) From what I've read (https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/), Midori was a research project, and not a replacement. They started with .NET and C# because they own it, but then departed to custom languages. Their research included stuff like language safety (most of it now in Rust, and it seems they implemented some of it into C++ and C#). Also cool concepts like capabilities instead of permissions (2. post), programs that are multiple separate processes (like Smalltalk's; the lessons learned are now in C#'s await keyword), etc. The articles are a nice read. > there's no language that is universally good at every task, in particular when it comes to efficiency I'd say that Rust is now in a position that it is good enough for most tasks (even websites and AI), and is efficient enough for all of those tasks. Having your entire stack in Rust (or Elixir or most other languages) enables you to have more consistent software as everything is defined in one place only. > (b) the benefits of being single language was less than the benefits of being highly efficient and supporting existing apps written in any language The biggest benefit of being a single language is massive parallelism, especially if you're process/message oriented as Smalltalk or Elixir. Most modern software, unless really pushed (e.g., game engines) still do not use all cores available. There is also an argument to be made that context switching between smaller processes only on messages is faster than switching on modern OSes, and therefore would be more efficient. This would probably have to be implemented to be proven, though. (I'm not as confident on this level of OS design, feel free to disprove me) > (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. Yes, but to an extent. It is still hard to write safe concurrent code in a language like C++, and massive parallelism is hard with current black box binaries. (3) My thought process was a) files mounted over a network act like they're local, b) in a Smalltalk system local and networked objects would appear the same, c) since Smalltalk essentially encapsulates a server, the entire stack is already network like communication. But yes, it would probably only work for certain things, like objects or documents accessible over a network. (4 & 5) My point was that with an itemized OS, tagging and searching through items (non-system) would be better than with today's files. There is also a question of UX making it non-viable for most users. Searching files in Dolphin takes seconds, while doing the exact same thing in CLI with fd takes milliseconds. The end result should be a fast, accurate search engine for everything in your computer (local and remote; this would also augment AI to make it more useful). (7) My idea was more swappable views, views shipped by the developer and custom views that a user could make. I'd recommend looking at User-created item views (https://alexanderobenauer.com/labnotes/009/ https://alexanderobenauer.com/labnotes/009/). This also goes hand in hand with bootstrapping - the user changing their environment so it's easier for them to use. That, I think, is enough value to justify it. And if a developer doesn't think it is necessary, nothing should change for them, but the user should still have the option of making a custom UI (this also goes back to accessibility and AI using the apps). Web apps are a problem, but most are easily replaceable or easily recreated. Specialized apps are a bigger problem (e.g., CAD, video editors). But you could also just link to the web, and link from the web.