6 ms·

I'd love to see an OS like this take hold for people who don't need all the backward compatibility and server goodies in Linux and who don't want to deal with M

I'd love to see an OS like this take hold for people who don't need all the backward compatibility and server goodies in Linux and who don't want to deal with Microsoft or Apple. Something like Chrome OS but not so locked down.

ryanjshaw 3y ago
I want to see this, but with a user friendly capabilities-based security design so that downloading an app from the internet can't steal my credentials and documents. That's the biggest issue people face today and yet there seems to be no real interest in trying new OS-level approaches as far as I know.
- gjsman-1000 3y ago
  Well, there's macOS which has a very capabilities-based design (Documents folder? Pictures folder? Contacts? Desktop? Screen recording?) but most people just see it as annoying.
  - hot_gril 3y ago
    Eh, those are just folders. iOS has proper app sandboxing, but it could be taken a step further with VMs.
    - gjsman-1000 3y ago
      Ah... No? https://support.apple.com/en-asia/guide/mac-help/mchl211c911f/mac https://support.apple.com/en-asia/guide/mac-help/mchl211c911... https://youtu.be/sxgYBi-PuGI?t=298 https://youtu.be/sxgYBi-PuGI?t=298
      - hot_gril 3y ago
        Doesn't seem bulletproof. I made a .sh script that touches a file in each of those dirs and ran it. It didn't ask for permission. Privacy settings don't have full disk access or individual file access granted to iTerm2, in case that matters. Edit: Nothing has full disk access either. I even see bash listed as explicitly not having access.
        gjsman-1000 3y ago
        That's because the Terminal app has an exemption for Full Disk Access, so as to not break anything. Edit: OK, iTerm2, not sure what's going on there.
        hot_gril 3y ago
        Yeah, maybe something is weird about every Mac setup I've used, but I've barely even noticed these restrictions. Pretty sure CLIs and shell scripts in general have full disk access by default. Almost seems like the restrictions require some cooperation from the apps, idk. Besides disk access, there are all sorts of other ways I don't trust random native apps on my Mac. At least camera access is locked down now (I think).
        mike_hearn 3y ago
        They don't. But you almost certainly click through the prompt the first time you cd into Downloads without noticing. Prompt blindness is real.
        hot_gril 3y ago
        I just reset all folder access perms to "no" and killed both Terminal and iTerm. Tested in Terminal, and it did protect the downloads, desktop, and photos library folders, but not any of the other ones in the home dir (pictures etc) or the Music lib. Weirdly, iTerm did ask for permission when I cd'd to ~/Desktop, and I said no, but it was still able to cd and edit/view/delete anything inside; the only thing I can't do is ls. BUT in ~/Downloads, I can only mess with files created within iTerm, not pre-existing ones. At this point I double-checked iTerm still doesn't have access to either (or full disk access) in my sysprefs, restarted iTerm, and reproduced this. So yes it still feels like Terminal is willingly complying while iTerm is not totally, or something is just broken. And even if both were actually enforced fully, the permissions carry over to anything you run in there, and they don't protect very many things to begin with. Like, it can delete my entire Music lib without permissions either way. Ventura 13.5.2, 2019 Intel MBP
  - mikewarot 3y ago
    MacOS doesn't do capability based security, it does permission flags instead.[1] A permission flag is the clunky thing we all have learned to hate that smartphones do, instead of the elegance that is capability based security.[2] Let's say you want to buy an ice cream cone, and pay for it. Think of permission flags as signing a "Power of Attorney" letter, and handing that over to Dairy Queen. Every time you get a cone, they just take the money out of your account. But they could also sell your house. You can't limit the side effects of the permission you give, it's all or nothing. On the other hand, capability based security is like taking a $5 capability out of your wallet (in the US, a piece of paper with Lincoln on it), and paying directly for that transaction, one time, at the time it is needed. The most you can lose is that $5. You're not risking your home, just to get ice cream. The OS market is deranged. Capability based security is something that's been required since persistent internet connections became a thing. Clearly blaming everything else, the users, admins, programmers, compilers, language design, hasn't worked. [1] https://support.apple.com/en-asia/guide/mac-help/mchl211c911f/mac https://support.apple.com/en-asia/guide/mac-help/mchl211c911... [2] https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security
    - astrange 3y ago
      This is not a useful distinction because it'd be the same UI. If you grant an app a more specific capability, that just means a more specific permissions dialog. If you don't change the dialogs, the capabilities are going to be the same access it is now. I don't think users want to deal with much more fine grained dialogs. And it does have more specific capabilities called "security-scoped bookmarks".
    - jamwil 3y ago
      What would this look like in use? A permission dialog for every interaction? If you bury the user in those, it doesn’t take long before they just mindlessly smash buttons to make the pain stop. The infosec community never read The Boy Who Cried Wolf.
      - mikewarot 3y ago
        >What would this look like in use? It would look almost exactly the same thing you already see. Instead of "file open" actually just being a suggestion to the application, the OS would actual enforce the permissions so that the application couldn't do anything else. The usability of such a system wouldn't really ever take a hit. It certainly wouldn't result in excess permission dialogs. You don't see permission dialogs every time you take cash out of your wallet, or when you turn on a light switch. The infosec community is weird, and I'm not part of it. I strongly disagree with them these days.
- IshKebab 3y ago
  Fuchsia is probably the best chance of getting a real world capability based OS.
  - Findecanor 3y ago
    Genode seems more mature as a desktop OS at the moment. It has been going on for much longer.
    - IshKebab 3y ago
      It seems to be aimed more at uber-geeks and people that have to work with secure networks than ordinary people. I think Fuchsia is intended to be a general purpose OS.
- akyuu 3y ago
  If you mean restricting filesystem access to random programs, I think that's already possible on macOS (with TCC) and Linux (with Flatpak), but the underlying mechanisms aren't very robust and can be easily bypassed by malicious code. If you mean a true capability-based OS, there is Fuchsia, which doesn't seem to be used yet, and RedoxOS, which is in development.
  - throeaaysn 3y ago
    Easily bypassed how for Flatpak?
- zzo38computer 3y ago
  My own ideas of operating system design, I have made many ideas relating to them, and one of the important features it involves is capability-based security. My project does not currently have a name, though. Note that proxy capabilities are actually useful for many things rather than only for security, though; however they are good for security too.
  - vacuity 3y ago
    Could I bother you to elaborate? I'm interested in OS design and capabilities too :)
    - zzo38computer 3y ago
      A program can receive capabilities from kernel and from other programs, and can also make up its own capabilities (which can proxy existing capabilities, so they are called "proxy capabilities") which can then be sent in messages to other capabilities; all messages are sent to and received from capabilities and messages can contain both bytes and references to other capabilities (allowing the program that receives them to use those capabilities). (This is a bit similar than SCM_RIGHTS, although there is a bit difference.) One thing that can be done with proxy capabilities is to run programs with any instruction set whether or not it is the instruction set on the computer that it is running on; the programs will just work. This is because an emulator can provide a proxy of the execution capability and can detect the instruction set required and emulate it. (Of course this only works if the program that spawns it is given the proxy capability, although it doesn't know that it is a proxy capability.) (It could also emulate specific instructions, e.g. if you are using x86 without BMI2 extensions and you want to run a program that uses BMI2 extensions.) Another thing that can be done is to run a program on another computer just as though it is local (or vice-versa); a program can, when sending/receiving messages through the network service, make IDs for any capabilities it send/receives and use those to handle passing the messages. So, capabilities can be shared between computers, and a program can use a combination of capabilities from multiple computers. (Multiple locking will be a bit more complicated.) Or, you can use proxy capabilities for testing what a program might do ten years from now (by proxying the date/time capability), or simulated disk errors, etc. Or, if you do not have a camera, you can make a program that expects it to be given the contents of a video file instead. There are many more possible uses, too. The kernel need not know what proxy capabilities are used for, in order to work. When a program starts, it receives an initial message, which will contain any capabilities it is allowed to use (and, depending on what capabilities they are, might be able to use those capabilities to request further capabilities). (If the initial message contains no capabilities, then the program is immediately terminated (unless a debugger is attached to it), since it would not be able to do any I/O and is therefore worthless.) (Note that there are no command-line arguments, environment variables, etc; only the initial message.) Files can contain links to other files in their stream as well as bytes, and links to files can also be made into capabilities which can be sent in messages too. A link can be either to the latest version, or to a fixed version (in which case copy-on-write is used if it is accessed and written through a link that is not to a fixed version). Another feature is that locks and transactions can involve multiple objects at once, instead of having to lock each one individually. (This is helpful for many kinds of synchronizations. For example, a program might write to (or read from) two files and avoid a race condition of another program reading (or writing) the two files and receiving (or sending) inconsistent data.) I also have many ideas of the high-level design (of stuff other than the kernel); most of the above is about low-level design. There will be common conventions for formats of messages, including endianness, etc; this way programs written for different instruction sets can communicate with each other without being confused. One high-level feature is the "common data format", which is a binary structured format, used for most of the system. This can include plain lists, key/value lists, rich text, diagrams, zoned spreadsheets, time series, typed arrays, extensions, and others. The command shell has some ideas similar than Nushell, although using the binary structured format instead of text, using Extended TRON Code instead of Unicode, and others. It can also be used as a programming language, can be used to control other programs (if having access to the appropriate capabilities) (a bit similar than ARexx ports), etc. You can also just as easily move and copy data and objects between the command shell and GUI, so they are designed to work well together, rather than independent. The file system is strange, not having file names and not having directory structures (except for a root directory with 256 numbered entries, mainly used for some low-level startup stuff; not all entries need to link to a file). A file can have several numbered forks (not necessarily consecutively numbered; perhaps 32-bit numbers); some of the low numbers have specific conventional uses while higher numbers can be used for your own use. There is journaling needed, including of transactions of multiple files at once. A POSIX compatibility library is also possible. This is a user program that a C program can link to, and a set of conventions for messages to use with POSIX (e.g. command-line arguments, environment variables, etc), which can be used to run programs that are designed for POSIX. (However, designing the program for this system instead would make it much better suited for this system in many ways, since it can then take advantage of many of the helpful features of this system.) My intention is that it is not a single implementation of the operating system, but a specification that multiple implementations would be possible. Some implementations might run by themself while others might be able to run inside of another operating system (similar than Inferno). A program for this operating system could then run on any of the available implementations. The kernel and the higher-level parts of the operating system need not match (other than stuff such as drivers), although usually would be expected that they would match.
kwanbix 3y ago
Try haiku-os.org.
- faefox 3y ago
  Lord, what I would give to see Haiku gain real traction. BeOS was something truly special and I often wonder what the tech landscape would look like today had Apple chosen to acquire them instead of NeXT.
  - chrsw 3y ago
    Or if Microsoft hadn't used anti-competitive practices to ensure a system like BeOS would have trouble getting traction. Bundling agreements with OEMs and whatnot. >Lord, what I would give to see Haiku gain real traction I think the only thing we can give right now is our time and money. Porting applications, porting to different hardware platforms, spreading the word, etc.
    - xp84 3y ago
      Indeed. It’s interesting that apparently there was room in the marketplace for another commercial consumer desktop operating system — we can see that it’s true with the rise of chrome OS. We could maybe have had that competition 10 years earlier.
      - hot_gril 3y ago
        I don't know if there was room back then. Suppose Microsoft made no agreements with OEMs. I guess OEMs would have to agree on some open standards to fairly support a broad range of OSes efficiently, which would've been hard but doable in theory. Even then, apps would be OS-specific, and one OS would win the market, at which point hardly anyone would have a reason to use the others. Cause the apps matter far more than the OS to end users. And now the web browser matters more than the native apps or OS to many users. And Chromium has dominance there.
        3y ago
npteljes 3y ago
What do you think about the BSDs, or 9front, the Plan 9 fork?
binkHN 3y ago
You can always easily add the Linux environment to ChromeOS.
joshmarinacci 3y ago
I’ve been planning and building this for years. But regular life always takes priority. This could change if there was a viable business model for an operating system that didn’t rely on hardware sales (the Apple model) or on advertising (the Android and increasingly Windows model). One day when I’m independently wealthy maybe.

ryanjshaw 3y ago

I want to see this, but with a user friendly capabilities-based security design so that downloading an app from the internet can't steal my credentials and documents. That's the biggest issue people face today and yet there seems to be no real interest in trying new OS-level approaches as far as I know.

gjsman-1000 3y ago
Well, there's macOS which has a very capabilities-based design (Documents folder? Pictures folder? Contacts? Desktop? Screen recording?) but most people just see it as annoying.
- hot_gril 3y ago
  Eh, those are just folders. iOS has proper app sandboxing, but it could be taken a step further with VMs.
  - gjsman-1000 3y ago
    Ah... No? https://support.apple.com/en-asia/guide/mac-help/mchl211c911f/mac https://support.apple.com/en-asia/guide/mac-help/mchl211c911... https://youtu.be/sxgYBi-PuGI?t=298 https://youtu.be/sxgYBi-PuGI?t=298
    - hot_gril 3y ago
      Doesn't seem bulletproof. I made a .sh script that touches a file in each of those dirs and ran it. It didn't ask for permission. Privacy settings don't have full disk access or individual file access granted to iTerm2, in case that matters. Edit: Nothing has full disk access either. I even see bash listed as explicitly not having access.
      - gjsman-1000 3y ago
        That's because the Terminal app has an exemption for Full Disk Access, so as to not break anything. Edit: OK, iTerm2, not sure what's going on there.
        hot_gril 3y ago
        Yeah, maybe something is weird about every Mac setup I've used, but I've barely even noticed these restrictions. Pretty sure CLIs and shell scripts in general have full disk access by default. Almost seems like the restrictions require some cooperation from the apps, idk. Besides disk access, there are all sorts of other ways I don't trust random native apps on my Mac. At least camera access is locked down now (I think).
        mike_hearn 3y ago
        They don't. But you almost certainly click through the prompt the first time you cd into Downloads without noticing. Prompt blindness is real.
        hot_gril 3y ago
        I just reset all folder access perms to "no" and killed both Terminal and iTerm. Tested in Terminal, and it did protect the downloads, desktop, and photos library folders, but not any of the other ones in the home dir (pictures etc) or the Music lib. Weirdly, iTerm did ask for permission when I cd'd to ~/Desktop, and I said no, but it was still able to cd and edit/view/delete anything inside; the only thing I can't do is ls. BUT in ~/Downloads, I can only mess with files created within iTerm, not pre-existing ones. At this point I double-checked iTerm still doesn't have access to either (or full disk access) in my sysprefs, restarted iTerm, and reproduced this. So yes it still feels like Terminal is willingly complying while iTerm is not totally, or something is just broken. And even if both were actually enforced fully, the permissions carry over to anything you run in there, and they don't protect very many things to begin with. Like, it can delete my entire Music lib without permissions either way. Ventura 13.5.2, 2019 Intel MBP
- mikewarot 3y ago
  MacOS doesn't do capability based security, it does permission flags instead.[1] A permission flag is the clunky thing we all have learned to hate that smartphones do, instead of the elegance that is capability based security.[2] Let's say you want to buy an ice cream cone, and pay for it. Think of permission flags as signing a "Power of Attorney" letter, and handing that over to Dairy Queen. Every time you get a cone, they just take the money out of your account. But they could also sell your house. You can't limit the side effects of the permission you give, it's all or nothing. On the other hand, capability based security is like taking a $5 capability out of your wallet (in the US, a piece of paper with Lincoln on it), and paying directly for that transaction, one time, at the time it is needed. The most you can lose is that $5. You're not risking your home, just to get ice cream. The OS market is deranged. Capability based security is something that's been required since persistent internet connections became a thing. Clearly blaming everything else, the users, admins, programmers, compilers, language design, hasn't worked. [1] https://support.apple.com/en-asia/guide/mac-help/mchl211c911f/mac https://support.apple.com/en-asia/guide/mac-help/mchl211c911... [2] https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security
  - astrange 3y ago
    This is not a useful distinction because it'd be the same UI. If you grant an app a more specific capability, that just means a more specific permissions dialog. If you don't change the dialogs, the capabilities are going to be the same access it is now. I don't think users want to deal with much more fine grained dialogs. And it does have more specific capabilities called "security-scoped bookmarks".
  - jamwil 3y ago
    What would this look like in use? A permission dialog for every interaction? If you bury the user in those, it doesn’t take long before they just mindlessly smash buttons to make the pain stop. The infosec community never read The Boy Who Cried Wolf.
    - mikewarot 3y ago
      >What would this look like in use? It would look almost exactly the same thing you already see. Instead of "file open" actually just being a suggestion to the application, the OS would actual enforce the permissions so that the application couldn't do anything else. The usability of such a system wouldn't really ever take a hit. It certainly wouldn't result in excess permission dialogs. You don't see permission dialogs every time you take cash out of your wallet, or when you turn on a light switch. The infosec community is weird, and I'm not part of it. I strongly disagree with them these days.
IshKebab 3y ago
Fuchsia is probably the best chance of getting a real world capability based OS.
- Findecanor 3y ago
  Genode seems more mature as a desktop OS at the moment. It has been going on for much longer.
  - IshKebab 3y ago
    It seems to be aimed more at uber-geeks and people that have to work with secure networks than ordinary people. I think Fuchsia is intended to be a general purpose OS.
akyuu 3y ago
If you mean restricting filesystem access to random programs, I think that's already possible on macOS (with TCC) and Linux (with Flatpak), but the underlying mechanisms aren't very robust and can be easily bypassed by malicious code. If you mean a true capability-based OS, there is Fuchsia, which doesn't seem to be used yet, and RedoxOS, which is in development.
- throeaaysn 3y ago
  Easily bypassed how for Flatpak?
zzo38computer 3y ago
My own ideas of operating system design, I have made many ideas relating to them, and one of the important features it involves is capability-based security. My project does not currently have a name, though. Note that proxy capabilities are actually useful for many things rather than only for security, though; however they are good for security too.
- vacuity 3y ago
  Could I bother you to elaborate? I'm interested in OS design and capabilities too :)
  - zzo38computer 3y ago
    A program can receive capabilities from kernel and from other programs, and can also make up its own capabilities (which can proxy existing capabilities, so they are called "proxy capabilities") which can then be sent in messages to other capabilities; all messages are sent to and received from capabilities and messages can contain both bytes and references to other capabilities (allowing the program that receives them to use those capabilities). (This is a bit similar than SCM_RIGHTS, although there is a bit difference.) One thing that can be done with proxy capabilities is to run programs with any instruction set whether or not it is the instruction set on the computer that it is running on; the programs will just work. This is because an emulator can provide a proxy of the execution capability and can detect the instruction set required and emulate it. (Of course this only works if the program that spawns it is given the proxy capability, although it doesn't know that it is a proxy capability.) (It could also emulate specific instructions, e.g. if you are using x86 without BMI2 extensions and you want to run a program that uses BMI2 extensions.) Another thing that can be done is to run a program on another computer just as though it is local (or vice-versa); a program can, when sending/receiving messages through the network service, make IDs for any capabilities it send/receives and use those to handle passing the messages. So, capabilities can be shared between computers, and a program can use a combination of capabilities from multiple computers. (Multiple locking will be a bit more complicated.) Or, you can use proxy capabilities for testing what a program might do ten years from now (by proxying the date/time capability), or simulated disk errors, etc. Or, if you do not have a camera, you can make a program that expects it to be given the contents of a video file instead. There are many more possible uses, too. The kernel need not know what proxy capabilities are used for, in order to work. When a program starts, it receives an initial message, which will contain any capabilities it is allowed to use (and, depending on what capabilities they are, might be able to use those capabilities to request further capabilities). (If the initial message contains no capabilities, then the program is immediately terminated (unless a debugger is attached to it), since it would not be able to do any I/O and is therefore worthless.) (Note that there are no command-line arguments, environment variables, etc; only the initial message.) Files can contain links to other files in their stream as well as bytes, and links to files can also be made into capabilities which can be sent in messages too. A link can be either to the latest version, or to a fixed version (in which case copy-on-write is used if it is accessed and written through a link that is not to a fixed version). Another feature is that locks and transactions can involve multiple objects at once, instead of having to lock each one individually. (This is helpful for many kinds of synchronizations. For example, a program might write to (or read from) two files and avoid a race condition of another program reading (or writing) the two files and receiving (or sending) inconsistent data.) I also have many ideas of the high-level design (of stuff other than the kernel); most of the above is about low-level design. There will be common conventions for formats of messages, including endianness, etc; this way programs written for different instruction sets can communicate with each other without being confused. One high-level feature is the "common data format", which is a binary structured format, used for most of the system. This can include plain lists, key/value lists, rich text, diagrams, zoned spreadsheets, time series, typed arrays, extensions, and others. The command shell has some ideas similar than Nushell, although using the binary structured format instead of text, using Extended TRON Code instead of Unicode, and others. It can also be used as a programming language, can be used to control other programs (if having access to the appropriate capabilities) (a bit similar than ARexx ports), etc. You can also just as easily move and copy data and objects between the command shell and GUI, so they are designed to work well together, rather than independent. The file system is strange, not having file names and not having directory structures (except for a root directory with 256 numbered entries, mainly used for some low-level startup stuff; not all entries need to link to a file). A file can have several numbered forks (not necessarily consecutively numbered; perhaps 32-bit numbers); some of the low numbers have specific conventional uses while higher numbers can be used for your own use. There is journaling needed, including of transactions of multiple files at once. A POSIX compatibility library is also possible. This is a user program that a C program can link to, and a set of conventions for messages to use with POSIX (e.g. command-line arguments, environment variables, etc), which can be used to run programs that are designed for POSIX. (However, designing the program for this system instead would make it much better suited for this system in many ways, since it can then take advantage of many of the helpful features of this system.) My intention is that it is not a single implementation of the operating system, but a specification that multiple implementations would be possible. Some implementations might run by themself while others might be able to run inside of another operating system (similar than Inferno). A program for this operating system could then run on any of the available implementations. The kernel and the higher-level parts of the operating system need not match (other than stuff such as drivers), although usually would be expected that they would match.

kwanbix 3y ago

Try haiku-os.org.

faefox 3y ago
Lord, what I would give to see Haiku gain real traction. BeOS was something truly special and I often wonder what the tech landscape would look like today had Apple chosen to acquire them instead of NeXT.
- chrsw 3y ago
  Or if Microsoft hadn't used anti-competitive practices to ensure a system like BeOS would have trouble getting traction. Bundling agreements with OEMs and whatnot. >Lord, what I would give to see Haiku gain real traction I think the only thing we can give right now is our time and money. Porting applications, porting to different hardware platforms, spreading the word, etc.
  - xp84 3y ago
    Indeed. It’s interesting that apparently there was room in the marketplace for another commercial consumer desktop operating system — we can see that it’s true with the rise of chrome OS. We could maybe have had that competition 10 years earlier.
    - hot_gril 3y ago
      I don't know if there was room back then. Suppose Microsoft made no agreements with OEMs. I guess OEMs would have to agree on some open standards to fairly support a broad range of OSes efficiently, which would've been hard but doable in theory. Even then, apps would be OS-specific, and one OS would win the market, at which point hardly anyone would have a reason to use the others. Cause the apps matter far more than the OS to end users. And now the web browser matters more than the native apps or OS to many users. And Chromium has dominance there.
      - 3y ago

npteljes 3y ago

What do you think about the BSDs, or 9front, the Plan 9 fork?

binkHN 3y ago

You can always easily add the Linux environment to ChromeOS.

joshmarinacci 3y ago

I’ve been planning and building this for years. But regular life always takes priority. This could change if there was a viable business model for an operating system that didn’t rely on hardware sales (the Apple model) or on advertising (the Android and increasingly Windows model). One day when I’m independently wealthy maybe.