Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
ARX, Arthur and RISC OS (2012) (jellybaby.net)
58 points by mr_golyadkin on Aug 21, 2020 | hide | past | favorite | 31 comments


A shout out to those involved in Acorn, RISC OS, etc around the late 1980s and throughout the 1990's. Around 1992 or so, our family bought our first computer (when I was around 5 years old) which was an Acorn A3000 running (if I recall correctly) RISC OS 2 on ROM. The school I went to also had Acorn computers (including the RISC PC toward the latter half of the 1990’s).

Nowadays I consider myself extraordinarily privileged to have experienced RISC OS on Acorn hardware in its heyday. I see so many things in modern computing inspired by RISC OS. The taskbar in modern era Windows and Mac OS is remarkably similar to RISC OS 2 which was released in 1988. RISC OS was also an early pioneer of anti-aliasing fonts and had it years before it appeared in Windows.

However, sadly, there are many things now lost to history. A machine running RISC OS 2 booted in literally <3 seconds. It was basically just a console screen with “RISC OS 2048K” (or something along those lines) and a second or two later you were at the desktop. It is near impossible to find any modern computing device that boots as quick as the A3000 running RISC OS did.

RISC OS also had a wonderful file-save dialog which was simply the file icon—which you were to simply drag and drop directly to the folder you wanted to save the file to! Given you usually had the right folder open anyway, it was usually a case of just dragging to your already open folder. So much more sensible than having to search for a folder in a small explorer window.

Thanks to all involved. Acorn and their RISC OS sparked a lifelong interest in computers. Thank you!


I guess because I'm in a bit of a mood thanks to arguing with Linux Desktop evangelists lately, I'd like to point out that Rox Filer implemented exactly this file saving functionality (and many other good ideas RiscOS) on Linux. Then they built Rox Desktop around it. It was great. There were AppDirs, context-menu-only, spacial file management, drag-n-drop to save, etc.

Naturally, the project's reward for trying to improve the Linux Desktop experience was to have all its ideas ignored by the wider Linux community as it faded into obscurity.

If anybody was ever wondering why all these people who have gripes about the Linux Desktop experience never seem receptive to your pleas of "contribute! you can make it better!", this is why.


I also gave up.

With KParts, DBus, Bonomo, GNU/Linux has the pieces in place to have something like Lisp Machines, XDE, Mesa/Cedar, ETHZ, instead replicating a PDP-11 is all that matters.


I make a point of not including any of the components that you mention in packages that I build.

Another comment by the author of the GP one states the problem, everyone who might work on this kind of thing has different preferences.


Faire, but then don't complain (as in the community) that macOS, Android, Windows and ChromeOS get all the nice desktop toys.


I've been thinking for a while that the only way to get a decent desktop experience on Linux is going to be to start from scratch. The graphics drivers and Wayland are probably adequate. But absolutely everything from there on up - window mangers, GUI toolkits, applications, configuration tools - needs to be written from scratch by people who know what they are doing and can build all of it as a cohesive whole.

This would be a huge project, and i don't know who has any incentive to do it. It's hard to imagine that it would be possible to make a business out of it.


>The graphics drivers and Wayland are probably adequate. But absolutely everything from there on up - window mangers, GUI toolkits, applications, configuration tools - needs to be written from scratch

Doesn't projects like Enlightenment [1] do just that? They use Wayland and everything else(WM, Applications, libraries) was developed from scratch over it.

I had used it on Raspberry Pi 3, it was the smoothest desktop experience I've had on a Pi. But, unfortunately RPi wasn't officially supported and so none of the 3rd party softwares worked.

[1]https://www.enlightenment.org


I mean, this is what Android did, right? They use a Linux-based kernel but completely reimplemented the display systems. The real problem is that there isn't anybody who is willing to pay for that sort of work, either on the supply side or the demand one.


Not only that, Android IPC builds on top of Xerox PARC ideas.

Although it is very underutilized, you can compose Android applications (Activities) as Lego pieces, with each one doing just one thing right.


Please, no. One of the biggest problems IMO for Linux desktops is that everyone decides to rewrite most of it from scratch. (e.g. gnome 2 -> 3, Ubuntu's varied and changeable desktop UIs, etc...)

No-one can be bothered to fix bugs in the existing desktop environments because they are all too busy working on a rewrite that will be the new 'perfect' desktop, with its own set of annoying bugs and missing features compared to the previous revisions.

Linux needs desktops that get incrementally improved, fixing the countless minor but irritating 'paper cut' kind of bugs that hinder users. But the problem is, that kind of development work is boring, and the people who spend their free time writing open-source desktops naturally want to work on their own interesting projects instead. Reading and fixing existing code is just not fun.

This all sounds very harsh and unfair on the OSS developers, but it is just a fact of life; if you are volunteering your time and effort on a project, you probably don't want to do the boring and dull bug fixing work.


That is not entirely correct, f.i. there is http://trinitydesktop.org/ which continues to support KDE3 in current systems, respectively porting it to later versions of QT, fixing (security) bugs in the bitrotten external libraries, and so on.

Compared to contemporary DEs it flies!

The question remains if this makes sense, because countless other WMs can be made to fly also, which one could also use, and not lose that much functionality at all, given the lack of available software which would utilize anything that the old KDE3 has to offer. So one way or another, the Linux desktop experience remains ghettoish.


I came to the same conclusion some time ago. There are of course things I find less than ideal about the Kernel, and Wayland, but overall they are adequate and would be a lot of work to replace. Pretty much everything else has to go though.

I've made some notes about how I'd build such a thing, but the truth is I have neither the time nor the skill set necessary to do all the work myself. Worse yet, when I talk to people about what I think a desktop should be like I often find that while we agree on some subset of ideas, we disagree significantly on others in irreconcilable ways. Either I haven't found the right community yet, or it doesn't exist.

There is Probonopd's (of AppImage fame) Hello[0], but unfortunately that also doesn't seem to have a lot of interest.

[0] https://github.com/probonopd/hello


Bit of an aside - but what potential do you think VR has for GUI's? Personally for desktop GUI's, I was happy with CDE affairs in the 90's, but then I'm a terminal baby so, a GUI was just a way to pull-up terminals for most of my needs, of which CDE still ticks that functionality well, albeit it don't have all the modern eye-candy, which I find a good thing distraction wise.


They did, it’s called android


Are you thinking of something like NeXTSTEP ?


You assume ROX was better than anything on the Linux desktop the time, that assumption would be false. Rox didn't do anything extraordinary or better than the desktops or window managers of the day.


> You assume ROX was better than anything on the Linux desktop the time

I don't assume, I know because I was there.

> that assumption would be false. Rox didn't do anything extraordinary or better than the desktops or window managers of the day.

Name a single modern Linux DE that supports drag-n-drop saving, or AppDirs.

An answer of "I don't use those features so therefore they aren't important" is not acceptable.


You can still run it on the Raspberry Pi (up to version 3, the Pi 4 is not yet supported).

It works pretty nicely too, although no doubt it could do with some tender loving care to bring things up to date, as it's somewhat abandonware.

Certainly it makes the Pi hardware feel snappy in a way that desktop Linux decidedly does not.


RISCOS Open is pretty cool, but it's just not the same experience as the Archimedes!


I'm curious, what's the difference in feel?


I had a bit part writing upgrades to the PC emulator, getting Duke Nukem to run.

On the boot time - 2s was only realistic until you owned a hard drive! Then there was a boot sequence that was more like 15s after the drive span up, bringing new OS updates into play etc. And then you probably had some more customisations and apps, so my memory was more like a 30s boot. My cold Windows boot is faster than that now, but suffers from UI sludge for about 60s after I've logged in, so that counts as boot time too :( No post-boot sludge on RISC OS.

The save dialogue was really fiddly and needed some pro-level window management and mouse skills :) but I appreciated not having two UIs, one for loading and one different for saving.


Any link to your writing on the emulator and getting duke3d running? I’d at least find it interesting


https://web.archive.org/web/20020806023145/http://www.aleph1... was the announcement but - the main work was adding VESA 2.0 support to the BIOS from the spec, organising sharing the screen memory with the host side. Unlike VESA 1.2, the pixel formats were compatible so DOS could just write direct to the RISC OS hosted screen, getting some good frame rates for Duke, Tomb Raider etc.


The problem with the Archimedes was that it arrived late on the scene and was very expensive. My school purchased only one; and none of us kids got to go anywhere near it. The Atari ST is what I moved to after my BBC micro, in about 86 or 87.


The whole thing is fine, but this passage is GOLD:

> We had a really interesting time with part of that, we had one of the machines that we just could not get this thing to boot reliably. You could boot it, turn it off, reboot it and sometimes it would work and sometimes it wouldn't. It turned out, it would boot fine if you left it long enough, but if you didn't turn it off for very long then it didn't reset properly, and this was because the fan on the board was still spinning and the back EMF on the fan was enough power to keep the ARM running. And that's why you've got an ARM in your phone today, it would take no power to keep a 3 micron ARM with 25000 transistors would run for 30 seconds off the energy stored in the fan.


There's quite a bit of power in that sort of stuff. If you move the steppers on my 3d printer while it's not plugged in it'll light the backlight on the LCD screen very brightly!


I double dog dare you to put your tongue on it!


Hahaha no way :)


Arthur Norman’s SKI Machine was interesting: rather than being LISP (as mentioned in the talk) it was a combinator reduction machine https://en.wikipedia.org/wiki/Combinatory_logic - SK combinators are the way Miranda does lazy evaluation, so the SKI Machine was basically Miranda in hardware. Miranda was a forerunner of Haskell https://en.wikipedia.org/wiki/Miranda_(programming_language)


The development of the first ARM chip is just such an amazing story.

I just wanted to say a bit about why Acorn decided to do this whole RISC thing at all, Acorn was a manufacturer of home computers, why on earth would you be crazy enough to design your own chip?

Sophie did an analysis of the compiler output for a lot of common compilers as part of the process of trying to choose which chip we should use next, we were looking at things like the 68000 and the National Semiconductor 16032, or 32016 as it got renamed. I don't know if you remember, a second processor was done with that 32016 and Nat Semi had produced a poster that said "32016 is not a late 16 bit machine it's an early 32 bit machine", a year later we crossed out 'early' and wrote 'late' on it. This analysis showed that all of the complicated instructions and all of complicated mem-copies, the compilers just don't generate them. They generate Load/Store, add, subtract, and/or, compare, branch, that's about it really, the rest of them, unless you're writing in assembler, you just don't use them, so they're a complete waste.

Now, the aforementioned, Arthur Norman, who had written the LISP interpreter for the BBC Micro, and was in and out of Acorn the whole time, had come up with a design for a machine with 3 instructions called the SKI machine. Whose instructions were called 'S', 'K' and 'I' and it ran LISP in hardware and he built one of these things, it never worked, it was so big and covered in wire-wrap it was always broken. The idea was to prove that you really didn't need very many instructions for a general purpose machine.

...

Tony Thompson, who had done that implementation of BASIC 64, he got to do the core of the operating system, so the real guts of Arthur itself. That brought it out of reset, powered it up, organised all the memory and so forth. We had a really interesting time with part of that, we had one of the machines that we just could not get this thing to boot reliably. You could boot it, turn it off, reboot it and sometimes it would work and sometimes it wouldn't. It turned out, it would boot fine if you left it long enough, but if you didn't turn it off for very long then it didn't reset properly, and this was because the fan on the board was still spinning and the back EMF on the fan was enough power to keep the ARM running. And that's why you've got an ARM in your phone today, it would take no power to keep a 3 micron ARM with 25000 transistors would run for 30 seconds off the energy stored in the fan.


Fabulous read, and a lot of it really made me laugh especially the F0 keyboard bit.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: