Slashdot Mirror

You can get it to boot straight into BBC Basic, though: https://www.riscosopen.org/content/sales/risc-os-pico

Ready to use OS (I guess Raspberry Pi could be considered to have that with Raspbian)

RISC OS is the operating system for ARM since 1987.

It is still available today for the Raspberry Pi.

He's... not even wrong. It's rather impressive, the number of misconceptions and sheer volume of ignorance he manages to cram into just six short paragraphs.

It was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.

Except that it wasn't by default. You logout, your shell gets the HUP signal. That signal gets propagated down to all of the shell's children, and all of their children, and their children - all the way down to the end of the chain. By default, HUP terminates a given process. If it doesn't terminate a process as described, it's because one of three things has happened. First possibility: the process has deliberately severed its child-parent relationship with the shell, as any program designed to run as a daemon will do. Second possibility: the process has explicitly set a signal handler to trap (or ignore) the HUP signal. Third possibility: the process has been launched with the nohup command (which effectively is the same as the second possibility).

If a program hangs around after logout that isn't supposed to, that's a bug in the program, not in the operating system. The defaults are all set up properly; if a program deliberately sets out to ignore them, presumably that's for a good reason.

It has never been the default that a program will just hang around forever for no good reason.

we should consider it our duty as Fedora developers to improve the Linux platform

Right. That's it. I'm done. I'm out. I've been involved with Linux in some form or another since the days of the a.out to ELF transition - over ten years. I've been grumbling about systemd breaking a whole bunch of conventions for no good reason since I first laid eyes on it. This? This is the straw that broke the camel's back. Any operating system that quietly introduces a breaking change like this - something that is a fundamental part of the design of the Unix operating system, that is a basic assumption that every long-term Unix user is aware of - is not an operating system I want to have to deal with. Sure, it's easy to change the configuration setting for this thing. What about the next change that breaks something fundamental? Or the one after that? Or the one after that?

This isn't good enough. Sure, sometimes change is necessary - the a.out to ELF transition was done for good reasons; swapping out telnet to ssh was done for good reasons - but this kind of subtle breakage is a huge time sink to any halfway serious systems administrator.

Well, at least there are alternatives out there.

Eh?

Risc OS runs on it, for crying out loud.

There are tutorials for running your own bare metal code on the thing *and* using the output. (How much more lightweight do you want?)

Already, the GPU more-or-less runs a blob at the moment - but it also means you get a higher level of access to the facilities on it. (And anybody pointing out that it has access to the entirity of RAM gets asked if they realise how the DMA in a standard PC works (The work on slightly tricked out firewire iPods unlocking screensavers on Windows machines that didn't have drivers springs to mind))

A couple of points to bear in mind:

- You can now buy a Model B Pi bundled with a fast 8GB SD card for $40 from both our primary distributors.
- Most other cheap boards use the Cortex A8 core, which is rather a primitive implementation of the ARMv7 ISA. In particular, while it's great at memcpy() and reasonable at integer operations, it has rather poor floating point performance; for a floating-point performance comparison of ARM11+VFP, Cortex A8 and the (more modern and capable) Cortex A9, see:

https://www.riscosopen.org/forum/forums/5/topics/466?page=7

In other news, the FreshPaper guys are amazing. Definitely the stars of the show here in Copenhagen.

And if it goes onto Kickstarter I probably will. Why? I had ARM desktops back in the 1990s, they're really nice chips for a range of reasons. If you program close to the metal they're really nice chips with a very clean instruction set; they're very low power and run cool, so battery life is good and noise level should be low. An ARM laptop - particularly if it could dual boot RISC OS and Linux - would be a very nice machine. Also, I believe in the value of open source hardware; it keeps us - the users - in control, which becomes more important as the walled gardens grow.

Yes, it isn't pure open source. But purists are missing the point. You can't actually buy an OpenSPARC chip, and as I don't own my own chip fab I can't make one. You can't (currently) get a GPU with an NDA-free data-sheet, and while the ultra-purists will say, well, you can do without a GPU, actually having a GPU is pretty nice. Also, if we demonstrate that there is a market for a more open GPU, someone may come along and offer one.

IN summary: yes, this specification represents a machine that is a compromise. All engineering is about compromise. But in my view this looks like a good compromise. I'd buy it.

Oh, and, the idea of a little analog power meter appeals to me.

There is one already. It's called RISCOS. Sure, it needs some work (like pre-emptive multitasking and SMP, okay a *lot* of work), but it's small (the OS uses 6Mb of RAM) and it's very fast. And there's already a reasonable amount of software available for it, plus a working GCC implementation, so more can be ported.

RISC OS needs throwing away. I'm sorry, but it does. It was good at the time but these days we know so much more about writing operating systems that you simply cannot get to a real OS from there.

Examples? Memory is protected except when it's not, giving you the worst of both worlds. No threads. No preemption. User code runs in supervisor mode (and supervisor mode code on ARM isn't guaranteed to be portable). The GUI is great --- if you have a mouse; it can't be driven from the keyboard, at all. There is a single byte of public workspace at 0x00000108 which means that the bottom page of memory has to be mapped. Yes, this means that null pointer dereferences don't trap! There are about fifteen different APIs for doing anything, with slightly different semantics, some of which pass flags in the top eight bits of addresses. There are roughly five different system heaps, none of which overlap, all of which suffer from fragmentation.

The real jewel of the crown, though, the point at which I went from being a fan to wanting to kill it with fire, was when I discovered the code in the system memory allocator which looks up through the caller's stack trying to figure out whether it's being called reentrantly. If it is, it allocates the memory from a special small heap. Why? So that it could do memory allocations from inside interrupt handlers.

(Just to show my credentials: I discovered all this while working on a RISC OS kernel reimplementation.)

That said, if you want a 1980s grade utterly non-Posix OS, RISC OS is a good one, and if you have a Raspberry Pi do check out the bootable RISC OS image. It's interesting and works well.

But Haiku is a real, modern operating system, and RISC OS isn't.

There is one already. It's called RISCOS. Sure, it needs some work (like pre-emptive multitasking and SMP, okay a *lot* of work), but it's small (the OS uses 6Mb of RAM) and it's very fast. And there's already a reasonable amount of software available for it, plus a working GCC implementation, so more can be ported.

RISC OS needs throwing away. I'm sorry, but it does. It was good at the time but these days we know so much more about writing operating systems that you simply cannot get to a real OS from there.

Examples? Memory is protected except when it's not, giving you the worst of both worlds. No threads. No preemption. User code runs in supervisor mode (and supervisor mode code on ARM isn't guaranteed to be portable). The GUI is great --- if you have a mouse; it can't be driven from the keyboard, at all. There is a single byte of public workspace at 0x00000108 which means that the bottom page of memory has to be mapped. Yes, this means that null pointer dereferences don't trap! There are about fifteen different APIs for doing anything, with slightly different semantics, some of which pass flags in the top eight bits of addresses. There are roughly five different system heaps, none of which overlap, all of which suffer from fragmentation.

The real jewel of the crown, though, the point at which I went from being a fan to wanting to kill it with fire, was when I discovered the code in the system memory allocator which looks up through the caller's stack trying to figure out whether it's being called reentrantly. If it is, it allocates the memory from a special small heap. Why? So that it could do memory allocations from inside interrupt handlers.

(Just to show my credentials: I discovered all this while working on a RISC OS kernel reimplementation.)

That said, if you want a 1980s grade utterly non-Posix OS, RISC OS is a good one, and if you have a Raspberry Pi do check out the bootable RISC OS image. It's interesting and works well.

But Haiku is a real, modern operating system, and RISC OS isn't.

The fixed hardware and low power of the Pi is just begging for a lightweight, low footprint OS

There is one already. It's called RISCOS. Sure, it needs some work (like pre-emptive multitasking and SMP, okay a *lot* of work), but it's small (the OS uses 6Mb of RAM) and it's very fast. And there's already a reasonable amount of software available for it, plus a working GCC implementation, so more can be ported.

It just needs volunteers. Preferably ones who will happily write hand optimised ARM assembler...

Little is known to date about a RiscOS (open) port to the Pi, but this I find fascinating. The dated OS could be a reasonable match to the limited hardware.

http://www.riscosopen.org/forum/forums/5/topics/783?page=12#posts-11917

A few years back I wrote an experimental RISC OS kernel workalike (obligatory link). In the process I found myself delving way too deeply into the core of how RISC OS worked and it's really not pretty. It's got such misfeatures as: a memory allocator that allows you to allocate small blocks of memory from inside interrupt handlers --- it does this by tracing the stack to try and figure out whether it's been called reentrantly; hardware-specific hacks built into what should be generic operating system modules (FileSwitch runs programs by fiddling with the supervisor-mode registers); no real device driver model; about half a microkernel to address the fact that there's no real driver model; global variables everywhere (pretty much everything expects to read a byte at 0x00000108 in order to test interrupt status); APIs which pass flag bits in the upper two bits of addresses; and hysterical raisins everywhere, such as having multiple concurrent system heaps. Plus of course, the whole thing is an unreadable mess of uncommented ARM machine code.

That said, it does all work, and some dedicated lunatics have RISC OS running on the BeagleBoard, so a Raspberry Pi port shouldn't be too hard. (Bear in mind that RISC OS is not open source, though; it's got a look-but-don't-touch shared source license.)

What most people think of when they talk about RISC OS is the GUI, which is a work of genius, although now very dated. (There's no keyboard accessibility, for example. Without a mouse you don't use it. This is something Microsoft got right from the very first, and the early versions of Windows were a joy to use with the keyboard.) I wish that modern systems were half as consistent and elegant as the RISC OS GUI. There have been a few attempts to recreate it with modern systems --- ROX Desktop, for example --- but they never got anywhere, alas...

The OS itself is still around today, after a fashion. But time has not been kind.

IMV, a fast boot cannot compensate for a spectacular lack of features you'd expect to find in a modern OS. It's a single user OS with co-operative multi-tasking rather than pre-emptive, there's no protected memory or swap support, it's single-user.

You can, literally, buy a brand new Intel machine today and run DOS 5.0 and Windows 3.1 on it, unmodified, without emulation.

Theoretically, yes. Realistically, no. That new machine will not have proper hardware support for those operating systems: its sound card and network card will not be supported by either OS.

True, although you can work around this if you're careful. Buy a Core 2 Quad motherboard with ISA slots, and plug in a Soundblaster 16 and NE2000. Of course, this is already super overkill as DOS can't use four cores, but that's kind of my point -- at least it boots and runs after 25 years. There is literally no other consumer platform in history for which you can say this.

Windows will probably not be able to use its keyboard or mouse (assuming it is USB based as I have seen increasingly recently).

Amazingly, this is false. Most BIOSes that I've seen allow hardware-based PS/2 emulation of USB keyboards and mice (and, although you didn't mention it -- USB floppy drives too!). It's usually a BIOS option called "Legacy USB support" or something similar.

Graphics will be limited to VGA mode (either 640x480x16 colours or 320x240x256 colours) under Windows or any graphical DOS programs, because you won't be able to get a driver for it.

The graphics supported by such old software is inherently poor. This is not a huge limitation for the market of people interested in running such old programs. 640x480x16 was at one time considered high-end graphics.

It's also theoretically possible to run an old ARM OS on a modern ARM device. These people have made the OS designed for the original Acorn Archimedes (the first computer to use an ARM processor) work on ARM Cortex A8 devices. The major problem is device driver support for modern systems.

As the URL itself indicates, that's a port of RISC OS. It's not the original, unmodified binary. It uses the original ROM image, but that's hardly the same thing as running the original full OS binary.

You can, literally, buy a brand new Intel machine today and run DOS 5.0 and Windows 3.1 on it, unmodified, without emulation.

Theoretically, yes. Realistically, no. That new machine will not have proper hardware support for those operating systems: its sound card and network card will not be supported by either OS. Windows will probably not be able to use its keyboard or mouse (assuming it is USB based as I have seen increasingly recently). Graphics will be limited to VGA mode (either 640x480x16 colours or 320x240x256 colours) under Windows or any graphical DOS programs, because you won't be able to get a driver for it. Large quantities of software that used to be common under DOS will fail. Anything written using Turbo Pascal or the later Borland Pascal, for example, will fail to start, throwing up a division by zero error message.

It's also theoretically possible to run an old ARM OS on a modern ARM device. These people have made the OS designed for the original Acorn Archimedes (the first computer to use an ARM processor) work on ARM Cortex A8 devices. The major problem is device driver support for modern systems.

The new owners of (one of the branches of) RISC OS has actually released it as shared source, available here if you're interested.

I'll agree that the overall design is very elegant, and the module system is nice, if rather primitive (relocatable code with no fixups! Aaaah!). But we know more about operating systems now, and a lot of Acorn's design decisions are no longer valid: for example, you actually get better performance from a preempting kernel than a cooperative one (because you can do work while other tasks are blocked on I/O).

Some of the misfeatures I found include:

• OS_Heap is vastly more complex than it needs to be because it contains lots of code that scans through your stack looking to see whether you're calling OS_Heap reentrantly. Ew. Why? Because on RISC OS you're allowed to allocate memory inside interrupt handlers. Ew ew!
• Virtual location 0x00000000 has to contain a mapped page. Why? Because there is one user accessible byte of kernel private data there, which most of Acorn's modules insist on referencing. This means you can't detect null pointer dereferences. (And the byte is specific to Acorn's RISC OS kernel. R2 doesn't use it, but it's still got to be there.)
• There are about four different heaps available to modules --- all of which are used for much the same task, and all of which have different APIs. (Historical reasons.)
• Two of the standard modules --- FileCore and MessageTrans, I think --- are mutually dependent. FileCore's startup calls MessageTrans, which calls back to FileCore. It only ever worked at all because both modules were preloaded in ROM. If, like R2, you build your module list dynamically at boot time you're in a world of pain.
• A number of the APIs require you to pass in an address to a buffer, where the top 8 bits of the address contain flag bits. The kernel is at perfect liberty to hand you a buffer at an address greater than 0x00ffffff, and indeed, sometimes does.

That's off the top of my head, and that's omitting some of the plain style issues, such as APIs where the user has to pop a word from the stack before returning to invoke certain behaviour; the merry mixing of supervisor-mode and user-mode code (usually in the same code path. Did you know that supervisor-mode instructions on ARM are not guaranteed to be the same from one architecture to the next?); the bizarre maze of callbacks, service handlers, vectors, system control handlers, and environment handlers by which you get information back from the kernel...

Although, as you say, it did all work very well, although I did find my share of programs that would hang/crash/put the computer into some weird state. And it was impressive what it could do; this was all before the 386 had really hit the market.

But I don't think it's at all useful in today's world --- the big killer is that not having threads or processes or Posix it can't run any modern software. So no Chrome, although I note that some hero has managed to get Firefox 2.0.0.12 working on it.