4 ms·

Honestly I think a lot of ideas about where to go with Desktop OSs these days are just complexity fetishist slashfiction. I don't think we need new complicated

Honestly I think a lot of ideas about where to go with Desktop OSs these days are just complexity fetishist slashfiction. I don't think we need new complicated paradigms, instead we should take a look at our history of what worked and what didn't and build based a simple combination of good ideas we already have. My opinion, short version, hastily written, and incomplete: 1) Applications are self-contained objects that can be simply copied and deleted instead of installed and uninstalled. They should run from any location on any media. AppImage implements this in Linux and modern Mac application bundles are already this, but the concept goes back to almost the beginning of desktop computers. 2) Spacial file manager (MacOS), drag and drop saving (RiscOS), desktop and quick-launch menus are just views of a folder structures (Windows). 3) All applications in their own namespace and they only get access to what the user configures for them (do not do "allow/deny" popups!). 4) Everything scriptable and something like AutoHotKey built into the OS at a fundamental level. 5) Switchable "user profiles" instead of "user accounts", which are an artifact of giant shared computer systems. User profile just contains personalized settings and can be located anywhere, including removable media so you can take yours to other computers. If you want to keep things safe from others, encrypt them. Otherwise there are no permissions except those applied to applications themselves. 6) Sound and video should be routable like you see in DAWs. Plug outputs into inputs, add filters, split, mix, etc. This is of course scriptable so you can make it do what you want on arbitrary events. 7) Backwards compatibility should be a high priority, but accomplished via shim layers and/or emulation and/or vms when clean breaks are necessary. A wide array of such should be included with the OS from the beginning. In 2020, there is no excuse for not being able to run old software.

72deluxe 6y ago
All of these points sound like macos apart from 4, possibly 6 and definitely 7. Your home directory is your profile/account (what's the difference on a single computer?).
- Closi 6y ago
  Although 7 is effectively Rosetta / Rosetta 2.
- AnIdiotOnTheNet 6y ago
  > All of these points sound like macos apart from 4, possibly 6 and definitely 7. MacOS has some good ideas. 1 and 2 actually apply to a lot of OSs from the 90s. Good luck finding a spacial file manager today though. > Your home directory is your profile/account (what's the difference on a single computer?). The difference is that there is no OS concept of an "account". Right now, you can't take your home directory between systems and have it just work because the OS needs you to have a user account. If your user ID on the new system is different from the old one then your file permissions will be broken. The idea is, that the OS doesn't really care about protecting the machine from the user in a personal computing scenario. It does, however, care about protecting the system and the user's data from malicious applications, so that's where the permissions should be.
  - 72deluxe 6y ago
    Thanks for the explanations. I realise that the spatial file manager is missing these days, but I prefer the navigation file manager. Whenever I use BeOS I find the plethora of open windows for each directory unnavigable. You can get Finder to open each item in a new window and hide the sidebar to make it spatial-like, although I am not sure if there is a method of making "open in new window" the default. I think the separation of account and profile is a difficult concept, unless the directory had a specific UUID associated intrinsically with it so that permissions could be applied to objects that didn't know about "users"?
    - AnIdiotOnTheNet 6y ago
      What I'm saying is, you don't need the permissions at all. From the user's perspective, everything is 777. If you happen to have the edge case where more than one user is using a personal computer, and there is a desire to keep things safe from each other, then you should use encryption for this since it actually works. File permissions are easily bypassed with local access and a boot disk. As I recall, Pottering is actually working on portable home directories for Linux. Naturally, the solution is over-engineered and involves a new service and file format.
      - 6y ago
- Volt 6y ago
  >macos apart from 4 AppleScript?
KlaymenDK 6y ago
> modern Mac application bundles I just want to say that OLD Mac applications were exactly that, too -- even the OS was basically just "Finder" and "System", that was it. Dragging those two files to a different floppy (and swapping them 12 times to complete the copy) gave you a bootable disk. Meanwhile Windows apps were hundreds of files ... then eventually Mac apps went the same way, although not as wildly.
- AnIdiotOnTheNet 6y ago
  Yes, it was also used in RiscOS. Even DOS applications were really just a folder. It was a common feature of Desktop OSs of the time.
deleted 6y ago
[deleted]
waddlesplash 6y ago
I know we've debated this point before, but as I don't recall seeing this particular list from you before, I just wanted to point out that Haiku already has (2), (6), and (7), the technical capability for (1) though it is not exposed to the GUI, about half of (4) though there is also no GUI for it (there is a command line tool for it however), and future plans for something like (3) and (5). :)
- AnIdiotOnTheNet 6y ago
  Well, we've had some disagreement over the extent to which (1) applies to Haiku for sure. Maybe there have been some changes there but the way it appeared to be implemented a while back I would say didn't quite meet (1), especially by convention if not by technical limitation. If Haiku actually does (6) as I imagine it, that's actually something I had no idea about and probably deserves its own article. Ditto (4). I'm genuinely glad to hear about future plans for (3) and (5). These are the kinds of features that would make it more appealing to me than a Linux distro despite some of its current shortcomings.
  - waddlesplash 6y ago
    (1) is definitely by convention and not technical limitation, I definitely stated that during our last conversation. Audio & video mixing is done via "Cortex". Looks like we don't have great documentation for it yet, but here's an old screenshot: http://maurice.kaldience.com/wp-content/uploads/2008/03/haikucortex.jpeg http://maurice.kaldience.com/wp-content/uploads/2008/03/haik... Regarding scripting on Haiku, here's a basic introduction to the main CLI tool: https://www.haiku-os.org/blog/humdinger/2017-11-05_scripting_the_gui_with_hey/ https://www.haiku-os.org/blog/humdinger/2017-11-05_scripting...
    - AnIdiotOnTheNet 6y ago
      > (1) is definitely by convention and not technical limitation, I definitely stated that during our last conversation. Indeed, now that I think back I believe that was ultimately what you clarified about my misunderstandings of Haiku and package management. What still baffles me somewhat that it seems normal (non-ported) Haiku applications are actually made less flexible by packaging them because they 1) have no non-base-system dependencies and 2) hpkgs only work from certain locations (IIRC currently hardcoded but could potentially be configurable). Cortex does look a lot like the kind of system I'm thinking of. That's wicked cool. When Haiku supports hardware accelerated video one imagines they could stick arbitrary shaders in the video pipeline to accomplish some useful, or at least really neat, things. I know built-in audio routing functionality would save me a lot of time on the Halloween display each year, maybe I should look at doing that with Haiku next time. I see this quote in the comments about 'hey': "hey is not a tool to send generic BMessages", which seems like a missed opportunity from way out here at 100ft. Otherwise the only thing that seems needed for GUI exposure is a script editor with 'record' functionality and perhaps some kind of manager for how scripts are tied to system events.

72deluxe 6y ago

All of these points sound like macos apart from 4, possibly 6 and definitely 7. Your home directory is your profile/account (what's the difference on a single computer?).

Closi 6y ago
Although 7 is effectively Rosetta / Rosetta 2.
AnIdiotOnTheNet 6y ago
> All of these points sound like macos apart from 4, possibly 6 and definitely 7. MacOS has some good ideas. 1 and 2 actually apply to a lot of OSs from the 90s. Good luck finding a spacial file manager today though. > Your home directory is your profile/account (what's the difference on a single computer?). The difference is that there is no OS concept of an "account". Right now, you can't take your home directory between systems and have it just work because the OS needs you to have a user account. If your user ID on the new system is different from the old one then your file permissions will be broken. The idea is, that the OS doesn't really care about protecting the machine from the user in a personal computing scenario. It does, however, care about protecting the system and the user's data from malicious applications, so that's where the permissions should be.
- 72deluxe 6y ago
  Thanks for the explanations. I realise that the spatial file manager is missing these days, but I prefer the navigation file manager. Whenever I use BeOS I find the plethora of open windows for each directory unnavigable. You can get Finder to open each item in a new window and hide the sidebar to make it spatial-like, although I am not sure if there is a method of making "open in new window" the default. I think the separation of account and profile is a difficult concept, unless the directory had a specific UUID associated intrinsically with it so that permissions could be applied to objects that didn't know about "users"?
  - AnIdiotOnTheNet 6y ago
    What I'm saying is, you don't need the permissions at all. From the user's perspective, everything is 777. If you happen to have the edge case where more than one user is using a personal computer, and there is a desire to keep things safe from each other, then you should use encryption for this since it actually works. File permissions are easily bypassed with local access and a boot disk. As I recall, Pottering is actually working on portable home directories for Linux. Naturally, the solution is over-engineered and involves a new service and file format.
    - 6y ago
Volt 6y ago
>macos apart from 4 AppleScript?

KlaymenDK 6y ago

> modern Mac application bundles I just want to say that OLD Mac applications were exactly that, too -- even the OS was basically just "Finder" and "System", that was it. Dragging those two files to a different floppy (and swapping them 12 times to complete the copy) gave you a bootable disk. Meanwhile Windows apps were hundreds of files ... then eventually Mac apps went the same way, although not as wildly.

AnIdiotOnTheNet 6y ago
Yes, it was also used in RiscOS. Even DOS applications were really just a folder. It was a common feature of Desktop OSs of the time.

deleted 6y ago

[deleted]

waddlesplash 6y ago

I know we've debated this point before, but as I don't recall seeing this particular list from you before, I just wanted to point out that Haiku already has (2), (6), and (7), the technical capability for (1) though it is not exposed to the GUI, about half of (4) though there is also no GUI for it (there is a command line tool for it however), and future plans for something like (3) and (5). :)

AnIdiotOnTheNet 6y ago
Well, we've had some disagreement over the extent to which (1) applies to Haiku for sure. Maybe there have been some changes there but the way it appeared to be implemented a while back I would say didn't quite meet (1), especially by convention if not by technical limitation. If Haiku actually does (6) as I imagine it, that's actually something I had no idea about and probably deserves its own article. Ditto (4). I'm genuinely glad to hear about future plans for (3) and (5). These are the kinds of features that would make it more appealing to me than a Linux distro despite some of its current shortcomings.
- waddlesplash 6y ago
  (1) is definitely by convention and not technical limitation, I definitely stated that during our last conversation. Audio & video mixing is done via "Cortex". Looks like we don't have great documentation for it yet, but here's an old screenshot: http://maurice.kaldience.com/wp-content/uploads/2008/03/haikucortex.jpeg http://maurice.kaldience.com/wp-content/uploads/2008/03/haik... Regarding scripting on Haiku, here's a basic introduction to the main CLI tool: https://www.haiku-os.org/blog/humdinger/2017-11-05_scripting_the_gui_with_hey/ https://www.haiku-os.org/blog/humdinger/2017-11-05_scripting...
  - AnIdiotOnTheNet 6y ago
    > (1) is definitely by convention and not technical limitation, I definitely stated that during our last conversation. Indeed, now that I think back I believe that was ultimately what you clarified about my misunderstandings of Haiku and package management. What still baffles me somewhat that it seems normal (non-ported) Haiku applications are actually made less flexible by packaging them because they 1) have no non-base-system dependencies and 2) hpkgs only work from certain locations (IIRC currently hardcoded but could potentially be configurable). Cortex does look a lot like the kind of system I'm thinking of. That's wicked cool. When Haiku supports hardware accelerated video one imagines they could stick arbitrary shaders in the video pipeline to accomplish some useful, or at least really neat, things. I know built-in audio routing functionality would save me a lot of time on the Halloween display each year, maybe I should look at doing that with Haiku next time. I see this quote in the comments about 'hey': "hey is not a tool to send generic BMessages", which seems like a missed opportunity from way out here at 100ft. Otherwise the only thing that seems needed for GUI exposure is a script editor with 'record' functionality and perhaps some kind of manager for how scripts are tied to system events.