3 ms·

I tried RISC OS on a single-core Raspberry Pi and I was quite impressed at how well it ran. Significantly faster on this board than the stock Linux desktop envi

I tried RISC OS on a single-core Raspberry Pi and I was quite impressed at how well it ran. Significantly faster on this board than the stock Linux desktop environment based on LXDE. Downsides are the usual, setting a native monitor resolution is not as easy or possible in the era of high resolution screens, the web browser cannot be used for the modern web. I'm always impressed by those early brains that had no problem creating new things for the first time in assembler.

lproven 4y ago
Yes, agreed. And as someone who used RISC OS 2, I should point out that RO2 was significantly smaller, faster, and far more responsive than RO3 -- and that's on an 8MHz ARM2. RO is much smaller and quicker than any other modern GUI OS. I believe, from faint memory, that the first Raspberry Pi version the ROOL organisation demoed to Raspberry Pi founder Eben Upton didn't have drivers to access the SD card yet, so it booted into RAM and then couldn't load anything else. He asked how big it was: they told him, it's about 6MB, compressed. He said, "no, not the kernel, the whole OS." They said "that is the whole OS!" 6MB for kernel, filesystems, GUI, desktop, terminal emulator, core apps (text and image editors, BASIC interpreter, etc.) I've only ever seen 3 OSes that compare at all to RO in terms of snappy responsiveness. 1. Psion EPOC16 (Psion 3, 3A, 3C, 3MX PDAs) and EPOC32 (Psion 5, 5MX, netBook PDAs). 2. The 1990s QNX Demo Disk showed that a desktop PC OS can rival RISC OS in compactness. It's the only one that could, though, and due to heavy compression it wasn't super fast. 3. BeOS was very close to as snappy and responsive, albeit ~2-3 orders of magnitude bigger. BeOS showed that PC hardware could compete: a PC in the hundreds-of-MHz class, with a 3-digit number of megabytes of RAM, could boot in seconds off a spinning rust HDD, and present a desktop with exceptional responsiveness. Today, even a multi-core multi-gigahertz class machine running Windows or Linux or macOS feels like wading in molasses by comparison with RISC OS or BeOS. Sadly, this includes Haiku and M1 Macs. I've had no difficulty setting RISC OS on a Pi to whatever the native res of the connected screen was. Can't reproduce that one. Modern browsers are coming; a WebKit-based browser is in testing now, as is a new TCP/IP stack with IPv6 and Wifi support.
rbanffy 4y ago
> Significantly faster on this board than the stock Linux You need to remember Linux, as did Unix before it, decouple the GUI from the OS (and the programs running on it) through multiple layers of abstraction, It was also designed to be ported to different CPU architectures, not for speed.
- lproven 4y ago
  Unix as it was designed doesn't have any direct support for a GUI at all. Or networking, come to that. They are not so much decoupled, as multiple separate trailers being pulled along behind on a tow-bar. If you're on a Bash prompt on machine called "foo" logged in as user "bar", how do you look at the contents of a file called "readme" in folder "/usr/share/doc/" on a disk labelled "quux" on a machine called "baz"? Assume you have all necessary permissions to do this. (Answer: you don't.) If your terminal is on monitor #2 on machine F, how do you open a terminal on monitor #3 on machine B elsewhere in the lab, without knowing what desktop or display server it's running? (Answer: you don't.)
  - rbanffy 4y ago
    And all those separate trailers impose a performance penalty. You can have a very fast Unix machine that doesn’t have a GUI and doesn’t understand a network, and you can have one where your home is an NFS mount halfway across the globe.
    - lproven 4y ago
      This is true, but it's not my point. My point is that there are very fast OSes which remain portable and have this sort of thing built in and integrated right into the kernel, such as Oberon and A2, or Plan 9, or Inferno. So when you originally said: « ... decouple the GUI from the OS (and the programs running on it) through multiple layers of abstraction, It was also designed to be ported to different CPU architectures, not for speed. » I think you are mixing up cause and effect, and trying to blame an accidental side-effect by making out that it's a core aspect of the design. It's not that the Unix GUI layer is "decoupled" (as in, intentionally kept separate from) the kernel. It wasn't. The kernel was designed without any thought of GUIs or consideration for them. There was no conscious layering or designing for portability here. That's like saying... um... the new government after the French Revolution kept the railway system decoupled from government. It did not such thing. They had no conception or thought of railways; they're "decoupled" because one was bolted on a century later. UNIX didn't decouple the GUI from networking, either. It never entered into the picture. And yet, remember that the first lines of UNIX v1, long before C or anything, were written after Engelbart gave "the mother of all demos". This stuff _was_ happening, it was out there and it was on the radar. Thompson and Richie realised their mistakes and they went on to fix them, in Plan 9, and then improve upon Plan 9 in Inferno. But the Unix community had seized upon the older version by then and it wasn't AND STILL ISN'T interested in breaking what works in the interests of making it smaller, simpler, cleaner, faster and more efficient.

lproven 4y ago

Yes, agreed. And as someone who used RISC OS 2, I should point out that RO2 was significantly smaller, faster, and far more responsive than RO3 -- and that's on an 8MHz ARM2. RO is much smaller and quicker than any other modern GUI OS. I believe, from faint memory, that the first Raspberry Pi version the ROOL organisation demoed to Raspberry Pi founder Eben Upton didn't have drivers to access the SD card yet, so it booted into RAM and then couldn't load anything else. He asked how big it was: they told him, it's about 6MB, compressed. He said, "no, not the kernel, the whole OS." They said "that is the whole OS!" 6MB for kernel, filesystems, GUI, desktop, terminal emulator, core apps (text and image editors, BASIC interpreter, etc.) I've only ever seen 3 OSes that compare at all to RO in terms of snappy responsiveness. 1. Psion EPOC16 (Psion 3, 3A, 3C, 3MX PDAs) and EPOC32 (Psion 5, 5MX, netBook PDAs). 2. The 1990s QNX Demo Disk showed that a desktop PC OS can rival RISC OS in compactness. It's the only one that could, though, and due to heavy compression it wasn't super fast. 3. BeOS was very close to as snappy and responsive, albeit ~2-3 orders of magnitude bigger. BeOS showed that PC hardware could compete: a PC in the hundreds-of-MHz class, with a 3-digit number of megabytes of RAM, could boot in seconds off a spinning rust HDD, and present a desktop with exceptional responsiveness. Today, even a multi-core multi-gigahertz class machine running Windows or Linux or macOS feels like wading in molasses by comparison with RISC OS or BeOS. Sadly, this includes Haiku and M1 Macs. I've had no difficulty setting RISC OS on a Pi to whatever the native res of the connected screen was. Can't reproduce that one. Modern browsers are coming; a WebKit-based browser is in testing now, as is a new TCP/IP stack with IPv6 and Wifi support.

rbanffy 4y ago

> Significantly faster on this board than the stock Linux You need to remember Linux, as did Unix before it, decouple the GUI from the OS (and the programs running on it) through multiple layers of abstraction, It was also designed to be ported to different CPU architectures, not for speed.

lproven 4y ago
Unix as it was designed doesn't have any direct support for a GUI at all. Or networking, come to that. They are not so much decoupled, as multiple separate trailers being pulled along behind on a tow-bar. If you're on a Bash prompt on machine called "foo" logged in as user "bar", how do you look at the contents of a file called "readme" in folder "/usr/share/doc/" on a disk labelled "quux" on a machine called "baz"? Assume you have all necessary permissions to do this. (Answer: you don't.) If your terminal is on monitor #2 on machine F, how do you open a terminal on monitor #3 on machine B elsewhere in the lab, without knowing what desktop or display server it's running? (Answer: you don't.)
- rbanffy 4y ago
  And all those separate trailers impose a performance penalty. You can have a very fast Unix machine that doesn’t have a GUI and doesn’t understand a network, and you can have one where your home is an NFS mount halfway across the globe.
  - lproven 4y ago
    This is true, but it's not my point. My point is that there are very fast OSes which remain portable and have this sort of thing built in and integrated right into the kernel, such as Oberon and A2, or Plan 9, or Inferno. So when you originally said: « ... decouple the GUI from the OS (and the programs running on it) through multiple layers of abstraction, It was also designed to be ported to different CPU architectures, not for speed. » I think you are mixing up cause and effect, and trying to blame an accidental side-effect by making out that it's a core aspect of the design. It's not that the Unix GUI layer is "decoupled" (as in, intentionally kept separate from) the kernel. It wasn't. The kernel was designed without any thought of GUIs or consideration for them. There was no conscious layering or designing for portability here. That's like saying... um... the new government after the French Revolution kept the railway system decoupled from government. It did not such thing. They had no conception or thought of railways; they're "decoupled" because one was bolted on a century later. UNIX didn't decouple the GUI from networking, either. It never entered into the picture. And yet, remember that the first lines of UNIX v1, long before C or anything, were written after Engelbart gave "the mother of all demos". This stuff _was_ happening, it was out there and it was on the radar. Thompson and Richie realised their mistakes and they went on to fix them, in Plan 9, and then improve upon Plan 9 in Inferno. But the Unix community had seized upon the older version by then and it wasn't AND STILL ISN'T interested in breaking what works in the interests of making it smaller, simpler, cleaner, faster and more efficient.