It's always fun when my old comments get dug up...
Actually recently I've started thinking about what it would take to create a toolchain to do the minimum to provide the pieces of AROS (for the uninitiated: AmigaOS "reimplementation" though it goes beyond the original in some respects) that might make sense on Linux and provide a compatibility layer to make it work.
AROS itself can run hosted on Linux, but not integrated well with Linux apps, but quite a lot of AROS relies on relatively small subsets of the AmigaOS API, and it'd be a fun experiment to e.g. bring data types to Linux, possibly combined with a fuse filesystem as a fallback to do on the fly conversions for apps with no support.
I'd love to see if some of those things could gain traction if suitably modernized.
I am thinking about what would make something revolutionary today. The only, but very important thing I can think of is that software today has no time constraints. All interfaces feel sluggish at some point.
What if we could make an OS with constraints, or an app store with a vetting process, or both complementing each other, to the effect that:
A widget pressed or touched or interacted with could always be trusted to respond in time - or fail in an understandable manner.
- No launching screens on touch interfaces suddenly being sluggish.
- No waiting for apps to download and install and can not be used during that time. (Solved by having updates installed quietly in the background.)
- No stutter or slowdowns, ever, no audio lags, ever.
the main thing should be that what you are interacting with must never feel like it's sluggish, no more than the water flowing out of a faucet starts to lag or freeze/unfreeze suddenly. The interface should feel so solid and "real", that if it stuttered you would be so shocked as if a thrown ball in real life stuttered in mid air.
Possible means
: Give GUI code very high priority. This will have to involve putting some intelligence in GUI code, or the interface will appear to be unresponsive or do strange things when underlying IO or network is being slow.
: Focus on determinism and time budgets, not raw performance throughput
: Vetting of applications
: Constrain apps to hard RAM budgets
: IO budgets for apps?
: Have apps allocate and bid for network performance and available bandwidth
I have a feeling much of this would not need a ground up rewrite. Probably Android or Linux could be used as a basis for such a system.
The big lesson in this for AmigaOS is to thread everything and make message passing a cheap and easy mechanism, but also to make developers develop but at least test on very low end hardware.
Even a simple button involves half a dozen threads in AmigaOS between the drivers, the handlers "baking" raw events from the drivers into something higher level, the Intuition thread processing the button presses into events related to a specific button etc.. It affects total throughout but increases responsiveness.
I think that if the OS provides responsiveness, and some key apps do, people will demand it. That is what happened with AmigaOS. You didn't get away with making a system sluggish because you'd get compared to apps that were extremely responsive.
Actually recently I've started thinking about what it would take to create a toolchain to do the minimum to provide the pieces of AROS (for the uninitiated: AmigaOS "reimplementation" though it goes beyond the original in some respects) that might make sense on Linux and provide a compatibility layer to make it work.
AROS itself can run hosted on Linux, but not integrated well with Linux apps, but quite a lot of AROS relies on relatively small subsets of the AmigaOS API, and it'd be a fun experiment to e.g. bring data types to Linux, possibly combined with a fuse filesystem as a fallback to do on the fly conversions for apps with no support.
I'd love to see if some of those things could gain traction if suitably modernized.