Modernising RISC OS in 2020: is there hope for the ancient ARM OS?
liam-on-linux.livejournal.com
liam-on-linux.livejournal.com
It got as far as being able to run the RISC OS C compiler, compile and run its own output for a few command line applications.
But then we got to the stage of needing a test suite. Then my friend & collaborator on the project (Chris Rutter) died at the age of 19, then I finished college, had to find work and lost most of my RISC OS connections & nostalgia.
There was definitely a rich seam of RISC OS software in 2000 that Linux desktop could have used - great text editors and word processors and Sibelius. But Linux got most of that pretty fast.
Also I don't think RISC OS would have escaped the trap of most desktop OSes - that a desktop OS with native applications became a niche, expensive taste. By 2010 most desktop computer users were looking for a host for a web browser, and RISC OS itself is still spectaularly unsuited to that - hostile code, multithreading, support for proprietary blobs (at least in 2000) etc. etc.
That doesn't stop me missing it though!
Why?
25 years ago there were dozens of OS's: AIX, Ultrix/OSF-1/Tru64, HP/UX, DG/UX, SCO (yuck), MS-DOS, Dynix/PTX, Solaris/SunOS, Windows, MSDOS, Mac, VMS, RISC-OS, Amiga, BeOS etc. etc. Now we're down to a handful of OSs with a large amount of computing now converging on Intel/Linux -- FWIW, I have nothing against Linux, I've used it since the early Slackware / pre 1.0 kernel days.
But I do believe competition is a good thing and the current trend for OS (and processor) convergence is worrying to me. I'd like to see more innovation and diversity in this space.
Even Crostini and ARC++ execute inside their own VM alongside their own kernel flavour.
With Google turning the Web into ChromeOS, it matters even less, given how many OSes Chrome runs on.
Redox OS
Harvey is Plan 9, which is Unix 2.0.
Redox is xNix redone in Rust, I think because they've never seen anything that isn't xNix.
That's 2 so far. 2.5 if I'm being generous.
Do keep going, would you?
They are all one because the differences between them are trivial compared to their similarities. It doesn't matter if the kernel is monolithic or modular, or if the filesystem is case-preserving but not case-sensitive (NT, macOS). These are hidden technical details.
But most people now have only SEEN Unix and nothing else, so they think that these trivial implementation details -- like what is the default shell, or where are libraries kept -- are important differences. They aren't. They're unimportant decorative details.
When I talk about diversity, let's talk about some real non-xNix OSes I have owned, used, and worked with.
Assumption: shells
Imagine an OS with no shell. No command line at all. Shells are not a given. The idea of typing commands in text at a keyboard, hitting Return to send it for evaluation, getting an answer back, and acting according to that: that is an assumption, and it is one that came from 1960s mainframes.
The slightly more subtle idea that your input is sent character by character, and changing those can interrupt this -- e.g. Ctrl+C to cancel -- that's an assumption, too. It's from 1970s minicomputers, and indeed, the modern version is from one specific company's range: the Digital Equipment Corporation PDP series. The "enhanced" keyboard layout? Not IBM: DEC. The 6-dot-3 then 8-dot-3 letter filename thing? DEC. Filename plus extension at all? DEC.
Alternatives: classic MacOS. Atari TOS/GEM. ETH Oberon. Apple NewtonOS. Psion EPOC16 and EPOC32.
Assumption: configuration held in text files
Config files are an assumption. I have used multiple OSes with no config files at all, anywhere. Not hidden: nonexistent. The idea of keeping config in the filesystem is an artifact of one design school.
Other alternatives to it have included:
- a single global database, part of the OS, not visible in the filesystem at all.
- multiple databases, implemented as different parts of the OS design. One inside the kernel, one inside the filesystem structures of the OS.
- per-app databases, managed by OS APIs. So you don't write files or choose a format: you call the OS and give it things to store, or ask it what's there.
The upshot of these latter two kinds of design is that you get facilities like connecting a storage medium to the computer, and all its programs and data are instantly accessible to the user -- in menus, as associations, whatever. And when you eject a medium, it all neatly disappears again, reverting to previous values where appropriate.
Best example: classic MacOS.
Assumption: there is a filesystem. This is an integrated indexing system that stores data in blocks of auxiliary storage, where they can be found by name, and the OS will read data from them into RAM.
Filesystems are an assumption. Hierarchical filesystems are a bigger one.
Alternatives:
All data is in primary storage (IBM OS/400, AKA IBM i.)
Or, media can contain databases, managed by the OS but not accessible by name (Apple NewtonOS).
Or, the primary storage is objects in RAM, and saving to disk is accomplished by snap-shotting entire system state to auxiliary storage. (Example: Xerox Smalltalk.)
Or, the primary storage is lists of values in RAM, and as above, disks are mainly used for import/export and for holding state snapshots. (Example: Lisp machines.)
When you take a long view, in historical context -- not the narrow parochial one of the last decade or two -- then yes, these are all different implementations of near-identical Unix systems. You've seen one Unix, you've seen 'em all.
What we have today is a biculture: various flavours of Unix, and NT. That's it nothing else.
There used to be a verdant, rich forest here. Now, there is just a plantation, with fruit trees and pine trees. You're pointing at apple trees and pear trees and saying "look, they're different!" And at plums (and cherries and damsons and peaches) and oranges (and lemons and grapefruit and limes).
Well, yes they are, a little bit. But look deeper, and there are hard fruit, stone fruit, citrus fruit, nuts. But all deciduous broadleafed hardwoods.
There used to be creepers and vines and lianas and rattan, and grasses and orchids and bromeliads and ferns, and giant herbs, and little parasitic things, some with vast flowers, and mosses and lichens and liverworts.
There was a forest, and it's gone, and no, you cannot persuade me that a neat tidy little orchard with a handful of fruit trees is the same thing.
I have argued elsewhere on this forum that the environment is ripe for completely new OSes, and that we have advantages over this "previous era." The first is the wide adoption and availability of data interchange formats (think JSON, XML, hell even TCP/IP) that were not as common / didn't exist in the heady days of RiscOS or classic Mac. This gets a new OS much further in the "compatibility problem." Our current "App Culture" also absolves us of the need for true application compatibility. For example, so long as your new OS has a somewhat standards-compliant web browser (no small task), you get perhaps up to 90% of the capabilities most people need.
Another factor is that, while our hardware has really fit itself to C and Unix in often frustrating ways, we have RISCV on the horizon. And though all the writing online about it seems to revolve around getting *nix systems to run (boring), there is enough openness for people to experiment without 40 years of cruft getting in the way.
People really should be asking "what is the point of an operating system? What is actually needed here?" A glance in the direction of Lisp machines or Smalltalk or Oberon would provide a lot of guidance in that regard.
I still believe that one day we can move past the teletype metaphor.
I'm much more concerned about the lack of diversity in hardware space... specifically, the lack of open hardware.
This isn’t true. There are many modern features missing from RISC OS but memory protection isn’t one of them.
Each process sees its memory at the same logical address, it doesn’t have any way of accessing other process’ memory.
The process’ memory starts at the address 0x8000. http://www.riscos.com/support/developers/riscos6/memory/logi...
I'm pretty sure an application could rewrite important kernel tables below &8000. And if you were using any shared libraries, these were all implemented as kernel modules, with no guard rails.
So it was kinda safe against some accidental access errors, but not at all a secure environment, and definitely possible to blow up the whole machine.
Strictly speaking, I don't think this is true - virtual memory and process-based memory protection are separate issues. One could have a single-address-space OS where physical memory is identically mapped in each process' address space, while still preserving memory protection. A privileged process in such an OS might effectively be exempt from memory protection altogether, which would provide compatibility for legacy apps.
The first (MMU) adds virtual memory to the story, while the second (MPU) simply protects certain areas of memory.
https://www.geeksforgeeks.org/whats-difference-between-mmu-a...
OK, I will give you that one. :-)
But they are at least related concepts, no?
On Unix, any time you mmap() or fork(). And loading code from disk looks very similar to the former.
I am interested in the bigger picture.
See my FOSDEM talk for more: https://liam-on-linux.livejournal.com/69099.html
Well, my Archimedes was 8Mhz, and my Pi is 1500Mhz, so we have some room there perhaps?
> Then a rewrite of RISC OS for 64-bit ARM chips would require a 32-bit emulation layer for old apps to run -- and very slowly at that, when ARM chips no longer execute 32-bit code directly. A software emulation of 32-bit ARM would be needed, with perhaps a 10x performance drop.
https://www.research.manchester.ac.uk/portal/files/56078084/...
I am glad to hear it. I like this little OS and I want to see it survive!
A rusty Amiga 2000, with Internet connection could handle like 80% of the stuff I use my 2009 laptop for.
I have RISC OS running on a Pi, and it's not the first one I've had, either.
https://twitter.com/lproven/status/1310304554395860996
http://blog.tynemouthsoftware.co.uk/2015/12/day-8-zx-spectru...
I don't just make this stuff up, you know. :-)
I still have my A305, too, and an A5000 as well.
I’d previously missed this piece of lore. Anyone got any more info on it? I’m trying to picture what critical system built on RISC OS would have required ongoing maintenance and am coming up blank.
But a lot of the better ideas from the operating system should be carried forwards into something else. I’m not talking about sticking something on top of Linux but something completely different. Perhaps a resurrection of ARX and the UI concepts from RISC OS would be interesting.
That is more or less what I was arguing for, you see.
It doesn't seem like it's a niche others are interested in, though.
Get a git client and GCC working with it and you have a pretty nifty real-time development platform.
I know this is not about that actually, just makes me think about it.
But obviously it's for original RISC i.e. ARM. But anyway I still wonder if something like RISC OS could work on RISC V.
I saw a youtube demo of someone running RISC OS on Raspberry Pi and it was very snappy. Something older like that has had less time to acquire features (that can slow it down or just be bloat).
Besides eliminating bloat, I feel like RISC V is an opportunity to start with some new assumptions. So I am interested to hear how operating systems and software evolve for it. Linux is great but I believe that there is always room for a fresh approach after a few decades.
So I wonder if things like Fuchsia or MirageOS or new Rust things etc. will be targeted to RISC V.
Not sure if you actually mean that, but to me it sounds like you're implying that ARM is the "original RISC".
The first RISC processor was called RISC-I and came out of Berkeley research in 1981.
Around the same time came out the MIPS cpu, from Standford university, by a group who shortly after founded a company that by 1985 commercialized the first RISC CPU, the R2000.
ARM, SPARC and PA-RISC came out just about the same time.
The ideas were brewing for some time, but I think it's safe to say historically that the name "RISC" was not invented by ARM and that the R in ARM references a pre-existing term that has been developed at Berkeley.
Sure, the IBM 801, the CDC 6600 and others were forerunners, but it was the Berkeley research project that popularized the acronym IIRC.
So good job on that correction but it doesn't seem necessary to downvote me. I thought I had some interesting comments about the future of operating systems on RISC.
"Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it."
-- George Santayana (The Life of Reason: The Phases of Human Progress)