2 ms·

I'm more interested in the MS-DOS part about this than the OpenClaw part. That thing about reworking OSes from the ground up, it seems like we're overdue for th

I'm more interested in the MS-DOS part about this than the OpenClaw part. That thing about reworking OSes from the ground up, it seems like we're overdue for that on the desktop side. Of course people have tried, but each time it was part of making some mobile-desktop Frankenstein UI nobody wanted, not fixing the problem by itself. Using my Mac or Windows PC, it's very rare that I actually want an app to access files on its own that it didn't create. Like if I write a doc in Word, I'm only going to edit it in Word. I might want to email a copy to someone, but that doesn't mean Mail needs RW access to the original. I might copy a video clip into editing software, but again it doesn't need to touch the original. Programs often need their own dirs for caches, settings, etc, and those don't even need to be read by other programs. It's also annoying how they can write anywhere in ~/ and end up scattering stuff in random places. The iPhone sandboxing system works great for all that, where apps have to explicitly share to others. The Mac file access rules tried to address this but still seem like Swiss cheese while also getting in the way of normal usage, and there's seemingly nothing in Windows or Linux (unless you're going out of your way with jails). Other APIs besides file are a bigger challenge. That was gated away from the start on iPhones but not on desktop OSes. If they don't find a solution, web and mobile apps are going to keep taking over.

kccqzy 6mo ago
Your worldview aligns very well with what Apple is doing anyways. All you need to do is to use macOS, and only download apps from the Mac App Store (because they are sandboxed). And millions of non-technical Apple users are doing just that. It seems like what you describe is basically already a reality, so why is there a need for a reworking from the ground up?
- traderj0e 6mo ago
  It's still not like the iPhone sandboxing, it's a bandaid. Many of them genuinely need wide access to function, so just asking for permission doesn't really solve the problem. Like when you open a file in the picker, that's actually granting RW access to the entire dir permanently. On top of fixing the technical side, they need it to feel safe to the user, which right now it doesn't. Separately, idk if anyone is only installing from the Mac App Store. You can't even get Chrome that way. It's also just bad, like it bothers you about login, then apps get stuck in half-downloaded state. But yeah if anyone can pull this off, it'd be Apple, seeing how frequently they'll break apps by requiring new APIs.
  - kccqzy 6mo ago
    Well on iOS if you grant an app Files & Folders permission it also has permanent RW access to all your files visible in the Files app. I could use for example Möbius Sync (Syncthing) to sync all my documents from my desktop, then use PDF Viewer to annotate a PDF that was stored in the Möbius sync app. Users want this behavior which is why Apple finally relented and added the Files app and associated APIs. Why wouldn’t users feel safe?
    - traderj0e 6mo ago
      It's a niche feature that most apps don't need to function. If apps relied on that harder and people were constantly managing important files in there like on a desktop, they probably wouldn't feel safe with the permissions. I had to look to see what's even in my phone's Files app... looks like WhatsApp saved its received photos in there and I accidentally downloaded a couple of files in Safari. Except I didn't give WhatsApp permission, so idk what the rules are with that.
- ieie3366 6mo ago
  All 3 of the big OSes have extreme amounts of business critical code from the 90s and 80s. Code that is complete spaghetti, with no automated tests, no peer reviews, no changes for decades, and written in C of course (objective C in case of apple) That alone is a reason to start over with a from-scratch mes desktop OS implementation Microsoft and Apple both have more than enough money to do it. It would be a ~10 year project. It would not make money which is why it’ll never be done.
  - traderj0e 6mo ago
    Then again iOS is underpinned by a lot of that same code. I don't know if it needs to be that deep of a rewrite.
    - ieie3366 6mo ago
      iOS is something of a ship of Theseus I believe, all the code has already been rewritten over the years, only the core architecture itself is unchanged from the 90s but with a modernized codebase
  - tjwebbnorfolk 6mo ago
    Ok but if "it has a lot of ugly code" is the best reason to re-invent the OS, then we're not off to a very good start. It needs a purpose that the user can relate to.
  - daotoad 6mo ago
    1. Starting from scratch is rarely a good idea. 2. It always sounds like a better idea than it actually is. 3. Item 2 is true even if you think you've accounted for item 1. Is there something specific that you want that cannot be implemented reasonably on existing systems? Unless you have a specific compelling benefit that only a rewrite can grant, focused narrow rewrites are the way.
20after4 6mo ago
https://flatpak.org/ https://flatpak.org/ does this on Linux and someone else already pointed out, MacOS does this with app store apps. I don't like handing control to Apple so I much prefer the FlatPak solution - you get very detailed and fine grained control over what each app can see and it works fairly seamlessly. It's still a bit technical - but not far from being user friendly even for a less tech savvy user.
- com2kid 6mo ago
  Linux has Snap, and Flatpak, and sometimes an app works with one or not the other. It is the worst of both worlds. I especially love how flatpak has its own version of graphics drivers, which results in my browser flatpak updating to a version that has a mismatch between my system drivers, flatpak, and the browser. Too many bloody layers of abstraction.
  - traderj0e 6mo ago
    But say the Flatpak strategy were adopted fully, would it solve this? I've never noticed the permission difference between using (Snap or Flatpak) vs not, but I need to try it more.
notnullorvoid 6mo ago
> there's seemingly nothing in Windows or Linux Linux has flatpak
ryandrake 6mo ago
> Using my Mac or Windows PC, it's very rare that I actually want an app to access files on its own that it didn't create. Like if I write a doc in Word, I'm only going to edit it in Word. I might want to email a copy to someone, but that doesn't mean Mail needs RW access to the original. I think this depends on your definition of an app. When I write a text file in vim, I definitely want grep and sed and awk to have access to it. When I edit a source code document with VSCode, I want Python to be able to read and interpret it. To me, the core of computing is documents that are passed along from app to app, gaining value at each step.
- traderj0e 6mo ago
  vim, grep, sed, and awk would need to inherit permissions from the shell for this kind of sandboxing to be reasonable there, maybe on account of being child processes. I wouldn't want to sacrifice any usability there, I do everything in CLIs.

kccqzy 6mo ago

Your worldview aligns very well with what Apple is doing anyways. All you need to do is to use macOS, and only download apps from the Mac App Store (because they are sandboxed). And millions of non-technical Apple users are doing just that. It seems like what you describe is basically already a reality, so why is there a need for a reworking from the ground up?

traderj0e 6mo ago
It's still not like the iPhone sandboxing, it's a bandaid. Many of them genuinely need wide access to function, so just asking for permission doesn't really solve the problem. Like when you open a file in the picker, that's actually granting RW access to the entire dir permanently. On top of fixing the technical side, they need it to feel safe to the user, which right now it doesn't. Separately, idk if anyone is only installing from the Mac App Store. You can't even get Chrome that way. It's also just bad, like it bothers you about login, then apps get stuck in half-downloaded state. But yeah if anyone can pull this off, it'd be Apple, seeing how frequently they'll break apps by requiring new APIs.
- kccqzy 6mo ago
  Well on iOS if you grant an app Files & Folders permission it also has permanent RW access to all your files visible in the Files app. I could use for example Möbius Sync (Syncthing) to sync all my documents from my desktop, then use PDF Viewer to annotate a PDF that was stored in the Möbius sync app. Users want this behavior which is why Apple finally relented and added the Files app and associated APIs. Why wouldn’t users feel safe?
  - traderj0e 6mo ago
    It's a niche feature that most apps don't need to function. If apps relied on that harder and people were constantly managing important files in there like on a desktop, they probably wouldn't feel safe with the permissions. I had to look to see what's even in my phone's Files app... looks like WhatsApp saved its received photos in there and I accidentally downloaded a couple of files in Safari. Except I didn't give WhatsApp permission, so idk what the rules are with that.
ieie3366 6mo ago
All 3 of the big OSes have extreme amounts of business critical code from the 90s and 80s. Code that is complete spaghetti, with no automated tests, no peer reviews, no changes for decades, and written in C of course (objective C in case of apple) That alone is a reason to start over with a from-scratch mes desktop OS implementation Microsoft and Apple both have more than enough money to do it. It would be a ~10 year project. It would not make money which is why it’ll never be done.
- traderj0e 6mo ago
  Then again iOS is underpinned by a lot of that same code. I don't know if it needs to be that deep of a rewrite.
  - ieie3366 6mo ago
    iOS is something of a ship of Theseus I believe, all the code has already been rewritten over the years, only the core architecture itself is unchanged from the 90s but with a modernized codebase
- tjwebbnorfolk 6mo ago
  Ok but if "it has a lot of ugly code" is the best reason to re-invent the OS, then we're not off to a very good start. It needs a purpose that the user can relate to.
- daotoad 6mo ago
  1. Starting from scratch is rarely a good idea. 2. It always sounds like a better idea than it actually is. 3. Item 2 is true even if you think you've accounted for item 1. Is there something specific that you want that cannot be implemented reasonably on existing systems? Unless you have a specific compelling benefit that only a rewrite can grant, focused narrow rewrites are the way.

20after4 6mo ago

https://flatpak.org/ https://flatpak.org/ does this on Linux and someone else already pointed out, MacOS does this with app store apps. I don't like handing control to Apple so I much prefer the FlatPak solution - you get very detailed and fine grained control over what each app can see and it works fairly seamlessly. It's still a bit technical - but not far from being user friendly even for a less tech savvy user.

com2kid 6mo ago
Linux has Snap, and Flatpak, and sometimes an app works with one or not the other. It is the worst of both worlds. I especially love how flatpak has its own version of graphics drivers, which results in my browser flatpak updating to a version that has a mismatch between my system drivers, flatpak, and the browser. Too many bloody layers of abstraction.
- traderj0e 6mo ago
  But say the Flatpak strategy were adopted fully, would it solve this? I've never noticed the permission difference between using (Snap or Flatpak) vs not, but I need to try it more.

notnullorvoid 6mo ago

> there's seemingly nothing in Windows or Linux Linux has flatpak

ryandrake 6mo ago

> Using my Mac or Windows PC, it's very rare that I actually want an app to access files on its own that it didn't create. Like if I write a doc in Word, I'm only going to edit it in Word. I might want to email a copy to someone, but that doesn't mean Mail needs RW access to the original. I think this depends on your definition of an app. When I write a text file in vim, I definitely want grep and sed and awk to have access to it. When I edit a source code document with VSCode, I want Python to be able to read and interpret it. To me, the core of computing is documents that are passed along from app to app, gaining value at each step.

traderj0e 6mo ago
vim, grep, sed, and awk would need to inherit permissions from the shell for this kind of sandboxing to be reasonable there, maybe on account of being child processes. I wouldn't want to sacrifice any usability there, I do everything in CLIs.