Got an old Raspberry Pi spare? Try RISC OS. It is, something else
theregister.com
theregister.com
Amusingly, when you invoked the system console -which was at a lower level than the gui system, effectively pausing it - the command line appeared at the bottom of the screen and the frozen gui scrolled up as you entered more commands; until you exit the system console. (It was also possible to get a command line in a window, which could do slightly less - I forget exactly what)
I hate electron with a burning passion. But at least the web has open standards, good debugging tools and modern, performant, well documented and pleasant to use UI libraries like React, SolidJS and so on.
Just don't ask about rich text editing on the web. Oh god. Its been decades and its still so shit.
Microsoft did this ages ago, they lost a big anti-trust trial over it.
Aside from that, people ship electron because it works the same across different OSs, if you just want to target one OS, you are better off using that OSs native dev toolkit. Although good luck finding anyone who knows how to write native apps for desktops anymore, and if you are on Windows, good luck figuring out what toolkit you are supposed to use now days!
And Linux has had the decades long problem of QT vs GTK.
So really the only platform with a native toolkit is MacOS, although when it first came out there were actually multiple toolkits to choose from there as well, and now days I think there is some argument over using Swift of not still (not sure, don't keep up).
Or you can just use Electron and skip the above mess entirely.
Why does Microsoft build the very VisualStudio installer with Electron then?
To me it seems companies ship electron because it's easy to hire a JavaScript developer.
> To me it seems companies ship electron because it's easy to hire a JavaScript developer.
When I worked at Microsoft, one team I was on, very ironically, had a really hard time finding Windows developers.
We actually resorted to drawing straws to see who on the team would have to learn native Windows development!
IMHO a large part of the problem is that native Windows development is a career dead end, unless you work at Microsoft, there are relatively few well paying jobs for what is now a niche skillset.
They did indeed try to use Electron, and the backslash was big enough they went back to WPF.
Hi :-)
TBH, in a room full of HN regulars, to find a developer to write a native GUI app, you can throw a brick and hire whoever says "Ow!"
Because it's a wrong approach to a problem that was solved decades ago by much smaller and faster system libraries for UI development.
I myself strongly prefer classic desktop GUIs adhering to the 90s Microsoft and Apple design guidelines, also well-designed (rather than chaotically evolved like JavaScript) programming languages too yet the objective reality seems like that's not what the demand is for - real-life companies and people prefer fast-entry non-proprietary languages like JavaScript and virtually-unlimited expression like what CSS gives. The only libraries I know can technically be good alternatives to Electron are Qt Quick, WPF (and its spinoffs) and JavaFX but they all have downsides which limit their adoption.
And you're mixing Apple with NeXT (NeXTSTEP) and Sun (NeWS).
You're describing a system webview, which is a thing on Android, Windows, iOS, and macOS.
For menus, I feel it was the worst of all systems. The Mac and Amiga had menus consistently at the top of the screen, and the Mac was good for discoverability in that it showed you the menus were there without you having to click a button. Windows also did that, but menus were attached to windows (bleh). RISC OS was worst of all, _every_ menu is a context menu, including app-level menus - and you got different menus depending on whether you middle-clicked on the icon bar icon, or you right-clicked on the icon bar icon.
There was no standard file requester, _everything_ was drag and drop; to load a file, you had to drag it onto the application (although yes, default file associations allow you to double-click it). To save, first make sure you've got a filer window of the directory you want to save to open and visible on screen, then middle-click in the window of the file you're working on, navigate to File -> Save -> a tiny box with a file icon appears, you get to type the filename, then you have to _drag_ the file icon to the folder to save. And if you accidentally mouse-out of that box while typing the name, you lose the name.
The OS was also ridiculous in some of its APIs, particularly that there were a million and one things under the calls OS_Byte and OS_Word - yes, really, API calls all clustered together because they return a byte or return a word. It's a design holdover from the original BBC Micro's OSBYTE and OSWORD calls. There's also a pile of crap multiplexed behind "VDU" calls, and much like terminal emulators, there's a lot of behaviour you can invoke by printing specific control sequences to the text screen, including mode-switching.
It had a weird system where _all_ OS calls were either "I'll handle errors" (e.g. SWI XOS_WriteC) _or_ "let the system handle errors" (SWI OS_WriteC), which in most cases means that if the OS call ever had an error, it stopped and exited your entire program. The problem with this approach is lots of programmers chose to write software that falls over at the slightest provocation, rather than think to deal with every error and decide how much to deal with recovering it. So, for example, let's say you've been working in a paint package on your masterpiece, you save to disk, and there's a read/write error. Goodbye masterpiece.
You can get a flavour of its programming environment from http://www.riscos.com/support/developers/prm/
It also had its own filesystem metadata craziness; there were no file extensions, but rather file type metadata saved separately (the Mac also had this madness), and it also saved the "load address" along with the file.
Nonetheless, what I did like about it was:
1. That the whole OS was ROM-resident and you can boot a device with no media needed at all, within 3 seconds of turning it on. AmigaOS was _nearly_ all ROM-resident, but nonetheless required a boot disk to get to Workbench (all you need on that boot disk to get to Workbench is a ~200 byte program that launches it; it was clearly a deliberate choice to insist on a bootdisk, and I think it would've been better if it didn't)
2. That it pioneered "an app is a special kind of directory", so you can keep all your app's assets inside a folder. Mac OS at this time was using the awful resource-fork system to do this, but by Mac OS X it had seen the light and create apps and resource bundles
3. That it had a built-in BASIC interpreter, and this was a very fine BASIC because it had a full assembler built into it and it had fantastic BASIC-to-machine-code interoperability. You could write all the bits that needed to be fast in assembler, while writing the rest in BASIC. There were even a few commercial games released written in BASIC+Assembler.
Overall, AmigaOS was a much better OS than RISC OS, but I do still have space in my heart for the plucky British operating system.
Are you sure you're talking about RISC OS? Because you're got the overview right but your details are weird. Right-clicking never pops a menu in RISC OS. Only the middle button does that. That's why the buttons in RISC OS have names. They're not "left, middle, and right" they are "select, menu, and adjust".
The "everything is an object" drag-and-drop was absurdly powerful. You're not limited to dragging into a directory, you can equally well "save" a file directly into another application, avoiding the middle step of dumping it onto the disk first.
Personally, I find that the trend in making all UIs as easy as possible for the beginner to be a step backwards. Yes indeed, beginners can get going quicker, but then you've very quickly learned everything and there's no where to go. The pro user cannot work faster. The pro user cannot do more. We're all stuck behind fisher price interfaces.
If you treat users as if they are children, they will always use your software like a child.
Having just booted up RedSquirrel, yes, I accept I'm slightly misremembering. Right-clicking doesn't open a menu, it is consistently middle-click.
However, it is still somewhat inconsistent. In several applications (for example, !Maestro or a filer icon), left and right click on the icon bar do the same thing, while in others (for example !Edit), only left click opens a new window and right click does nothing.
Playing around with RISC OS 3.10 again, I'm also reminded of the nonsense that is menu items with arrows on them (indicating sub-menus, or sub-windows like save boxes) require you to successfully slide the mouse through the arrow to open them. Almost all other menus I've seen will open sub-menus as soon as you land _anywhere_ on the menu item.
While drag-and-drop may be powerful, the ergonomics of the UI were atrocious. I don't think anyone at Acorn had heard of Fitts' Law. The tiny save box also required you had exactly the right filer window open, ready and waiting. You couldn't easily change your mind like you can with a file requester (and also with modern MacOS's spring-loaded folders).
I also think the OS was designed with the expectation that overlapping windows would be _normal_, and I don't think that's ever been the case, certainly not how I use computers. Most windows I have open are fullscreen, and I switch between them (most commonly with the alt-tab concept that Windows brought). I might have _internal_ windows inside one app's window (for example, multiple code editing windows and terminals in an IDE, or tools, palettes and layers in graphics editing), but only on special occasions do I have two separate _application_ windows visibly open on the same screen, and when I do, they're usually side by side, not overlapping.
So true!
For sure I was biased when I left RISC OS in favour of Windows 3.1 early 90s, but it took me years to get used to the clumsy COPY-CUT-PASTE metaphors still dominant today.
I believe multi-user systems are actually an ancient, outdated rather than a "modern" concept. It made sense when computers were huge, expensive and many users shared one even at work, let alone at home. Nowadays computers are almost never shared. Even when people used to have just one home PC per family (during pre-Win7 days) they mostly preferred to disable the sign-in screen and share the whole environment.
Nowadays multi-user OS facilities definitely help to build security but they were not designed just for this. Modern security can be done better without an OS-level concept of a user.
Super user is super user. It can always access anyone's files. Allowing unrestricted access to super user essentially destroys any sense of security.
You can very much allow only access to certain commands under super user, e.g. only allow users to run pacman. Of course now you are trusting that said commands won't leak the permissions.
I agree that it's a mess.
My personal and biggest issue is not even across user boundaries, but inside a single user.
What do you mean my Firefox client can read my .ssh files???
Either way you slice it, though, it’s clearly a huge disconnect between what is important to the human using a system vs what is important to the system itself, and the relative lengths gone to to protect those two sets of things.
To some extent, yes. If I can install software of my own choosing on basically any normal desktop OS that will appear to other users of the system as "LibreOffice", "Firefox", etc. then I more or less have access to all their data.
MacOS is starting to sandbox applications but not by a lot, and of course Windows Store sandboxed apps are more or less dead in the water.
Check "Windows 11 Security", "App Isolation", "Sandbox", "Standard User", "Pluton".
https://github.com/dwizzzle/Presentations/blob/master/David%...
I find it ironic that Google TV still does not have this feature, it is the one "computer" that people probably still share regularly.
Sure you can login to multiple accounts and have different "profiles", but that just changes home screen recommendations, all the apps and their sessions are shared. So since I share it with a few roommates, we're constantly having to logout and in to our accounts in different apps to access our watch histories, our plex servers, etc.
On the other hand, my android phone does multiple accounts perfectly, why can't it work the same way on the TV?
No user, just a series of object handles which permit them to perform the task and nothing more.
And they're confusing for users, too. Signal isn't another "user" on my phone. Its still me. I just decide what capabilities I grant it on the day. "Yes, you can use location tracking for now - but only until later in the day."
It is yet another way of managing processes identitities.
Because I suspect if you really want to, you really can think about all "permission systems" as identity systems, and shoehorn in users or something. This cognitive distortion is totally possible. My claim is that its a bad mental model. Its like if you mentally translate all programming ideas into assembler, or java or something, it would make it hard to properly understand and appreciate a lot of higher level programming ideas. Haskell's beauty doesn't make any sense if you mentally translate everything into java. There are programs you just can't write with this mindset, and you would be a terrible haskell programmer.
Its the same with capabilities. They're not user accounts. They're not identities. They can be transient or persisted. Fine grained or coarse grained. A capability can be a function argument - arguably the C FILE struct is a capability object. Or they can be a permission box. Its just, a bigger idea than identity.
It's almost the opposite of a permission model in some ways, permission models restrict access to a global array of functionality where capability models allow access only to what's been provided.
You could maybe model or emulate a user in a capability system by providing the login's session manager an object with read/write access to the configured "user" directory, read and execute access to an applications collection, and full access to the root window. From there, when the user starts a new application it's given an object with access to a window created for it (by calling "createWindow" on the root window object, so it can't even do something like enumerate other windows or whatever), and whichever other requirements were configured as part of its install.
It's capabilities all the way down with no "user" involved.
Yes, you can have privilege-based security without user accounts, if you accept that you do not have control over your own hardware because only the OS vendor has administrative rights.
In other words: yes, you can have no-sign-in and no user accounts, but it's still there and you don't have admin access to your own computer.
Stepping back a level:
Smartphone OSes do not show accounts and permissions, but they are still there, just concealed. Same as they still have complex filesystems, but they are hidden.
Stepping back another level:
This is a bad way to design OSes: when you need to hide away major parts of the functionality, then you shouldn't have that functionality. It should not be in your design in the first place.
Or maybe just that the really in-depth administration and modification of your operating system happens prior to the OS running on your device, when it's being built — as a sort of configuration or specification step that happens prior to even installing the operating system or booting up your computer in the the first place, in a continuous integration system in the cloud perhaps, or on another existing computer? That's kind of how Fedora Silverblue works — almost everything you do is completely in unprivileged space, in a container or with a flatpak sandbox, or through policykit; you basically never use the root account at all, because you can't really do a whole lot of really in-depth customization of your OS internals on the operating system image that's actually installed and running on your system. Instead, you specify the modifications you want to make to an upstream image using something like BlueBuild[1] and then those modifications are automated and happen prior to anything ever hitting your computer in an automated ci/cd system (which could theoretically be self-hosted).
Like, I think there is a way to adapt the security and reliability benefits of the way e.g. macOS works that doesn't take control away from the user, just moves it somewhere else. And I think it's much safer for all of the really deep modification of your system, all of the system administration you do as the root user, to be essentially air gapped from the computer that you're actually running various applications and installing and building things and curling to bash on, on a system that's ostensibly clean.
User based security is usually done by the folder being owned by the database, or an ACL or something. But with capabilities, you don't need to make a database user or set any flags on the folder, or make sure the database's configuration matches the filesystem permissions. The capability is basically a pre baked file handle that can be used directly. And capabilities can do lots more stuff! They can be more fine grained - eg, "Whatsapp can only access these specific photos in my camera roll". And a program can pass a subset of its capabilities to a child process.
You could make the case for removing the concept of users from the kernel and forcing the OS to write some security plugin. The OS could then have a tailored security mechanism for every usecase, but they'd probably end up including users anyway (for the people who do want them).
My desktop computers are designed with this old "user security" model that I don't use at all - since I'm the only user anyway. User security protects ... uh, the operating system I suppose, which I could reinstall in 20 minutes anyway. But we're missing a much more important security boundary - which is between one bad program and all my other stuff. Every program you run today on desktop is inexplicably executed with full permission over all of your private files, and, worse, it has full network access. Its an insanely terrible design.
We /could/ retrofit the user security model to help us isolate applications. But personally I think it would be easier to just design and implement something good from scratch.
(For the security people in the room, the threat model is a bad program, or single bad npm package gets pulled into a program you run. How do we limit the blast radius?)
No memory protection or hardware access, rudimentary virtual memory "page mapping". Any tardy calls to Wimp_Poll() freezing the entire GUI. "Cooperative multitasking" also means it's still impossible to do something useful with more than 1 Raspberry Pi core.
So: lacking in foundations, yes. But multi user, not so much.
I mean, some of us here actually remember MS-DOS. It's not a huge secret to us.
That doesn't seem very accurate, unless you're meaning strictly personal computers?
(What's old is new again with virtualization: IBM took that approach to make time-sharing happen with CP/CMS on System/360 – then VM/370, then z/VM...)
I thought that in the 80s, and even had the same experience with sharing the family PC. Then networking (and the internet) happened, and suddenly multiuser became quite useful again - even at home.
> Modern security can be done better without an OS-level concept of a user.
Perhaps, but I have yet to see a userless model that doesn't have issues on around administrative access control. Even dumb terminals had issues with this where students would change settings and then set the admin password on the terminal... As long as people use computers, users will be users...
I can take or leave shared libraries. They seem to cause a lot of trouble, but so do statics, so I'm on the fence there. But in the context of when this was released it's a non-issue.
I'll give you the CLI thing though. If the CLI couldn't be full-featured in a window that was an oversight.
The OS generally had very little usage of the CLI though, since the GUI was present in ROM and booted to the desktop in about 3 seconds.
Similar to multiuser: Security is important, but as applications get more and more powerful it is not about what individual users can and can't do, but what each application can and can't do.
Containerization for all it's isolation magic has primarily been successful as a way to package "more or less the entire OS dependency" because sharing code is hard. How many containers ship with only one single binary (the active data set) ? None, code sharing is the primary problem that containers solve.
Static linking solves it better. RiscOS approach actually solves it better, too.
Stuffing whole OSes + apps + their dependencies in containers, and running a # of those, is not the solution. That works for single-purpose uses like servers. Not for user-facing OSes that run a # of apps side-by-side.
Solving that "how to share code reliably" problem is the solution. Being a hard problem means it's worthwhile to find a good solution for it.
And yes, stuffing whole OSes + apps + deps into containers is indeed not the solution, it's the symptom.
I don’t know why, but that’s fucking hilarious
After that, well, it basically flatlines and even seems to decrease at times.
https://www.youtube.com/watch?v=5IUj1EZwpJY
There is also Descartes' quote about how a work produced by one master is often better than one in which many are involved, because of the unifying vision.
It takes coordinated effort of many, many people. The same with making a-bomb, the same with making anything bigger in software.
It’s nice that Linus started kernel and GIT but nowadays he’s not writing much code and most likely he would is not able to review personally each and every PR.
Right now, I'm working on my own on a personal project attempting to do something a little novel and I appreciate being able to go back and refine my ideas/previous code based on things I learn and additional thinking (even rewriting from scratch), when I'm more likely to face friction (like "stick to the suboptimal approach; it's not that bad") and cause trouble for teammates if I was working with someone else. So the value of working alone speaks more to me currently than the value of working in teams, but they both have their place.
But this sort of goes with the African proverb, "If you want to go fast, go alone. If you want to go far, go together."
Tbh I think I am slightly bitter about having stuck with Acorn a bit too much, and should have jumped away sooner. It is clear Acorn knew they were toast even before the Risc PC. A lot of these very impressive developments were consequently glorious wastes of time, which is kind of tragic too.
[1]https://en.wikipedia.org/wiki/Network_Computer_Reference_Pro...
In tech, one step ahead is an innovator. Two step ahead is a martyr.
Chromebooks are effectively the modern NC
(WebTV, later purchased by Microsoft, was the more successful product in this space.)
They were just like X dumb terminals that predated them by about a decade: far behind what the technology was offering with storage and computing power becoming cheaper every year. I'm glad they never caught up, and hope the same happens to Chromeboxes/books; I don't want prices of common hardware I use go up because of market shrinkage due to lots of people ditching real computers in favor of dumb terminals where even the simplest service is something that they must access and run remotely with no or reduced local storage/computing power. Sorry for having an unpopular opinion, but to me SaaS is like going back 40-50 years to the mainframes era, and essentially is a way to put everything behind a counter so that users can be charged tomorrow for what today is still free.
Essentially, by 2005 the open internet had won, but the iPhone (or more precisely: the App store) became the dream of a thin client and became the platform NCs had initially targeted — turning the internet into a walled garden with a vengeance.
I disagree that it always means slower time to market - if the individual is empowered and minimum process (no PMs, "grooming", estimates, etc) a sharp individual can run circles around a full team.
Even so, it's heartwarming that people continue to put efforts into operating systems that aren't related to Unix or Windows. I'm happy to see people use this, and AmigaOS, and BeOS, and others. Computing shouldn't be a monoculture.
Note that EL0 (userspace) support is still present, but RISC OS cannot currently run entirely in userspace.
Haiku is the closest of these to being daily runner ready but like a lot of systems, lack of driver support prevents it from that lofty goal. It is pretty much the only reason that Linux has been able to go so far.
There's a pretty good emulator, they've got a bundle fully loaded with all kinds of RISC OS tools.
Modernising RISC OS in 2020: is there hope for the ancient ARM OS? 111 points by lproven on Oct 10, 2020 | hide | past | favorite | 53 comments
• RISC OS: 35-year-old original Arm operating system is alive and well
https://www.theregister.com/2022/06/21/risc_os_35/
• Original Acorn Arthur project lead explains RISC OS genesis – Paul Fellows describes how it beat the overambitious ARX to Acorn's Archimedes computer
https://www.theregister.com/2022/06/23/how_risc_os_happened/
• Bringing the first native OS for Arm back from the brink – Steve Revill of RISC OS Open chats to us about taking the project into the future
https://www.theregister.com/2023/01/17/retro_tech_week_rool/
A machine that you could code up a full GUI application with the BASIC interpreter in ROM, enabling children everywhere to which a C compiler was Unobtainium.
Amazingly you can still buy a copy of TechWriter 9.1 for £85! http://www.mw-software.com/software/ewtw/ewtw.html
I'm going to have to figure out another solution for my idea of turning TVs into cheap workstations. Sadly it seems like nobody is interested in making retro-computing accessible, and my favorite brand of linux seems to be slowly moving on to new hardware support(things seem degraded after updating). It's just that it makes it hard to participate(and contribute) when simple setup is so difficult, and hardware support becomes degraded. Maybe there is some project out there i just haven't seen yet that will fix all my problems, but it just seems less likely the longer i hang around. Actually there are a few options that come to mind, but testing OSs takes time, and so i think i'll just leave it at that for now.
Take care all.
Never knew why it bombed in the marketplace.
So I think the reason Acorn (and Commodore, Sinclair, Amstrad, RadioShack as well as Sun, DEC and SGI) went belly up is primarily that while the market was growing, there simply wasn't enough space in the market to compete with wintel dominance.
Bombed?
RISC OS machines sold for some 15 years in the face of growing competition from Windows and Linux.
Acorn chose to shut it down and span off ARM.
Castle Technologies continued selling it and made a new 32-bit-clean version and new hardware for it.
RISC OS Developments bought Castle and made RISC OS Apache-licensed FOSS.
The OS is still alive and in development nearly 40 years after release. You can buy new hardware running it.
You can buy new releases of the OS for original Acorn hardware and emaulators to run its apps on Windows and Mac OS X.
The CPU family is the best-selling in the world and outsells all x86 chips put together by something like 100:1.
Arm sold 8 Billion CPUs last year: https://newsroom.arm.com/news/arm-announces-q3-fy22-results
Intel sold 50 Million: https://tweakreviews.com/processor---cpu/intel-sold-the-most...
Tell me again about how this platform "bombed"?
But the ARM processor/ISA itself that came out of the original ARM2 on Archimedes is now world dominating.
Both are true.
But in the long run we're all dead (as J M Keynes put it). Step back too far and everything gets lost in the noise.
Archimedes was the reason RISC OS was created... and Acorn was the reason Arm was. But originally Acorn's ARM machines were to run ARX.
https://en.wikipedia.org/wiki/ARX_(operating_system)
Arthur outdid ARX, so ARX was cancelled and Arthur shipped. Arthur became RISC OS.
It closely parallels how CAOS was cancelled and AmigaDOS shipped, and later was renamed AmigaOS.
http://www.bambi-amiga.co.uk/amigahistory/caos.html
Oddly the bit of AmigaDOS 1.x that was ripped out of AmigaOS >= 2.x became its own OS, HeliOS:
https://www.theregister.com/2021/12/06/heliosng/
There are a whole bunch of questions on Quora asking why the Amiga flopped. It did not flop. It sold millions of units for years and derivatives of its hardware and software are still on sale today.
The ST didn't flop. It sold millions too, and both EmuTOS and AFROS/Aranym are still around and maintained.
The Archimedes didn't flop. It sold lots, it established a line of machines and OSes that are still on sale, and an offshoot of the company is still around and worth billions and totally dominates the computer industry. Today its CPUs power the Mac, and iPad/iPhone and Android AND WINDOWS -- and outsell PCs by about 10x over.
The latest version of the native PC OS runs on Arm chips as well and there are Arm-based PCs on sale now.
Do we say the PC bombed because DOS and Windows 3/9x are dead? Of course not!
Do we say the Mac bombed because it killed its OS, bought one in, and then moved to Intel for 15 years? Of course not!
Did the Mac bomb because all new Apple kit runs on that bought-in OS on a chip design that came out of Acorn? Of course not!
So Acorn's original OS largely died out and has little industry relevance now. So what? So did classic MacOS. So did MS-DOS. So did CP/M. So did original Windows.
Windows today is based on the result of a cancelled DEC OS, Mica, and a cancelled IBM OS, OS/2. The bit MS wrote, MT/DOS, is long gone and went FOSS last month.
Apple OSes today are all based on NeXTstep, and that was based on BSD tech.
But the chips they all run on -- not the only chips, but the best-selling ones -- are Acorn designs.
"Bombed," my ass.
RISC OS is a plaything for enthusiasts, a relic if an age where computing was a hobby rather than the corporate monstrosity that it has become.
As a hobbyist and RISC OS user I am fine with that. But Acorn itself got out of the game in 1988 after Phoebe took only 1,400 preorders. Had they continued, Galileo may well have succeeded RISC OS with a more modern foundation.
It actually gave me an appreciate for how computers must be for those who aren't used to them.
Has anyone saved the sources anywhere? Would whoever now owns IXI IP help with the desktop part?
- https://en.wikipedia.org/wiki/RISC_iX
I have memories of drooling over those R series machines or anything MIPS/Sparc/Alpha based in the early 90s for that matter. I think ARM systems at the time were never competitive in terms of speed (compared to SUN, SGI, HP), but they were Archimedes' sexy sisters.
If only it had been given the RISC OS GUI with BSD underneath - that would have been way easier to port to modern Unix-like foundations and may have had a healthier-but-niche future as something 'modern' beyond Acorn's existence.
Before Gnome, Qt, KDE we of course had motif and X with it's license issues. If I remember correctly, early Slackware CD bundles came with motif as well.
IXI’s desktop runs on top of Motif.
GNOME was created because of license issues with QT not being compatible with the GPL, so GNOME used GTK which was created by the GIMP project because Motif wasn't free.
> You mean the Archimedes GUI on top of the BSD kernel?
No. (Although that sounds fun, I never heard of such a thing.)
RISC/ix was Acorn's ARM UNIX. It had nothing of the Acorn GUI -- it was fairly standard X11, I think with Motif or something Motif-like.
Acorn did add some Acornish tweaks to it, including its text editing and its memory allocation, but it looked and ran much like any other late-1980s UNIX, as far as I now. I have never got to try it myself, sadly.
It was based on BSD 4.3. The efforts went into BSD 4.4 and that went into NetBSD and NetBSD 1.2 incorporated Acorn's ARM port.
https://groups.google.com/g/comp.sys.acorn/c/G19nI9eac-o/m/q...
https://www.netbsd.org/changes/changes-1.2.html#port-arm32
I'd say that the bits that matter mostly survived and still do.
Yes it is. I didn't think that was an important bit.
True story. ROOL went to show the RPi foundation their first version. It booted to the desktop, had an Apps folder with text editor, graphics, sound, command prompt, BASIC etc.
Eben Upton asked how big it was.
They told him it was 6MB.
Eben asked "no, not the kernel, the whole OS?"
They said "that is the whole OS. We haven't got SD card reading working yet. This is booted from the FAT partition kernel image."
Upton commented that if he had known the Archimedes OS was still around and it was FOSS, and it ran Python, he'd have made it the Pi official firmware.
Such a giant missed changes. Hundreds of millions of people would have had Pis that booted into RISC OS.
Acorn's own original Unix hardware booted RISC OS from ROM, then you clicked a desktop icon to load RISC/ix, Acorn's BSD.
The Pi was very nearly the same. A 10¢ flash ROM would have held the whole OS as it does on the Raspberry Pi Pico. That is the price Upton gave me personally in an interview.
https://www.theregister.com/2022/01/17/raspberries_pi_direct...
Pis would have booted direct into RISC OS without an SD card needed.
What would be the benefit of using RISC OS over Raspbian, or even Ubuntu Server? Is it pure nostalgia like running Windows XP on a Pi?
It's small - apps are hundreds of KB to a few MBs and it's fast/responsive. The question is what do you want to use it for? There are apps for most things, but as it's not Unix or Windows it doesn't have a lot of ports of bigger open source apps.
Exactly, people replied as if those apps and use cases are actually used today.
So it's just nostalgia right?
Is it nostalgia, or just if it aint broke don't fix it.
I see - yeah I get that, like classic cars, sailboats, SQL, etc.
This allows e.g. interesting graphics programming, and there's very little that gets in the way of immediately testing ideas.
You think Raspbian is simple?
https://www.raspberrypi.com/software/operating-systems/
« Raspberry Pi OS with desktop and recommended software
Release date: March 15th 2024
System: 32-bit
Kernel version: 6.6
Debian version: 12 (bookworm)
Size: 2,678MBhttps://www.riscosopen.org/content/downloads/raspberry-pi
« Complete SD card images
RISC OS Pi
2024-04-28 06:15:00
For Pi Zero & ZeroW & Zero2W, Pi 1 models A(+) & B(+), Pi 2 model B, Pi 3 models A+ & B(+), Pi 4 model B, Pi 400, Compute Module 1 & 3(+) & 4.
Version 5.30 Size 155.1 MB »
2.6GB of code, vs 155MB.
It's nearly twenty times bigger.
17.25x as big. And yes, I chose the image with "recommended software" because that 155MB RISC OS image is packed with dozens of apps as well.
Strange way to gauge simplicity too "this screen has 10x less pixels!"
* A tiny simple OS with a modest selection of really good apps?
* Or a huge slow complicated OS with lots and lots of indifferent-quality apps?
For that reason I thank you for your likely many contributions to obscure open source projects and gosh speed on your endeavors.
I'm a techie turned journalist, who's been using computers for well over 40 years now, with a particular interest in obscure and niche OSes and programming languages.
I've used an exceptionally broad range of computers for someone still active in the industry. Counting the entire field of PC-compatible x86 machines as one, then I'd guesstimate I've used and worked with 30 or 40 different architectures. Counting all forms of Unix-like OS from SCO Xenix to Linux as being Unix, being 1 OS in different implementations, then again, I'd estimate 30 to 40 different OSes.
I remember how small and simple OSes used to be. I remember the era when a multitasking GUI OS fitted easily into a single megabyte of RAM. When a machine with 4 or 8MB of RAM was more than adequate for exploring the Internet.
I am especially interested in OSes that are still around today, still being maintained, that are small enough for a single person to read the entire codebase, all of it, every line, in a matter of weeks and understand the whole thing in months.
There are several such systems.
There seems to me to be a belief today that a serious useful system must inherently be gigabytes of code, tens of millions of lines, and nobody can understand the whole thing. That is simply NOT TRUE and it never was.
No, I am not writing such things. I am writing about them and trying to bring more peoples' attention to them.
There is also ROX Desktop, which has had some recent commits: https://github.com/rox-desktop/
It is a good demo that some of the tech that Unix folks fetishize is actually an optional extra, and if you let it go, you can do more in 1% of the space.
Arm sold 160 times as many CPUs as Intel did last year.
x86 is a rounding error. It's under half a percent of the CPU market.
This contrasts with languages like GW Basic or even commercial QuickBasic (QBX) or Visual Basic: second class citizens when it came to accessing system calls under Windows (or dos).
In fact, I wrote simple basic code to access the undocumented random number generator within the BCM2835 chip - it worked perfectly under RiscOS and even a dedicated BBC Basic emulutor for the Pico.
This is what the code looks like for those that are interested:
REM MAP MEMORY
SYS "OS_Memory",13,&20104000,32 TO ,,,RNG_CTRL%
SYS "OS_Memory",13,&20104004,32 TO ,,,RNG_STATUS%
SYS "OS_Memory",13,&20104008,32 TO ,,,RNG_DATA%
SYS "OS_Memory",13,&2010400C,32 TO ,,,RNG_FF_THRES%
SYS "OS_Memory",13,&20104010,32 TO ,,,RNG_INT_MASK%
REM CHECK WHERE THE REGISTERS ARE MAPPED
PRINT “RNG_CTRL MAPPED AT &”;STR$~(RNG_CTRL%)
PRINT “RNG_STATUS MAPPED AT &”;STR$~(RNG_STATUS%)
PRINT “RNG_DATA MAPPED AT &”;STR$~(RNG_DATA%)
PRINT “RNG_FF_THRES MAPPED AT &”;STR$~(RNG_FF_THRES%)
PRINT “RNG_INT_MASK MAPPED AT &”;STR$~(RNG_INT_MASK%)
REM THESE INTS BECOME REGISTERS R0-R7 RESPECTIVELY
A%=1
B%=RNG_DATA%
C%=RNG_INT_MASK%
D%=RNG_STATUS%
E%=RNG_CTRL%
F%=&1
G%=&4000000
REM GET A RANDOM NUMBER FROM THE RNG
DIM RNG% 30
P% = RNG%
[ OPT 1
SWI “OS_EnterOS”
LDR R0,[R1]
SWI “OS_LeaveOS”
MOV PC,R14
ALIGN
]
REM INIT THE RNG
DIM INIT% 30
P% = INIT%
[ OPT 1
SWI “OS_EnterOS”
STR R5,[R4]
STR R6,[R3]
SWI “OS_LeaveOS”
MOV PC,R14
ALIGN
]
REM LETS INIT…
CALL INIT%
A%=0
X%=0
FIRST%=0
REM KEEP READING RANDOM NUMBERS UNTIL THEY ACTUALLY BECOME RANDOM
REPEAT
X%=A%
A% = USR (RNG%)
PRINT “WARMING UP &”;STR$~(A%)
IF FIRST%<50 THEN X%=A%:FIRST%=FIRST%+1
REM DISPLAY RANDOM NUMBERS (RETURNED FROM R0)
REPEAT
A%=USR (RNG%)
PRINT “&”;STR$~(A%);" ";
Enough said.
On the other hand, the entire PC industry was built on DOS and 16-bit Windows which were exactly like this.
Apple made enough money to buy the dying NeXT from selling classic 68K and PowerPC Macintoshes which were exactly like this.
Early Linux was exactly like this, too. I remember running Red Hat Linux 4.2 on my SPARCstation and having kernel panics right, left and centre. Several a day, every day.
Everything we use today, all the hardware and all the software, was built both on software like this and from software like this.
Who or what else?
It's bullsh1t. It's not true. It wasn't an "investment". Microsoft stole Apple code and used it in Video for Windows. It got caught. Apple took MS to court and was going to win, so it settled. The marketing-lizards span this as "investing" but it's not true.
https://www.zdnet.com/article/stop-the-lies-the-day-that-mic...
It's still a lie, no matter how many people believe it. Compare with the flat earthers, or people who use homeopathy, or all religions.
The code was stolen and used improperly by the San Francisco Canyon Company. It's all a matter of historical record. Read the references here:
No, not exactly like this. Even early versions of Linux used separate address spaces for (each) user process and system memory (like all, but the earliest Unix systems), preventing unprivileged user space processes to clobber system memory. A wayward pointer in an unprivileged application is strictly speaking undefined behavior, but on Unix systems typically causes a segmentation fault signal (by default terminating the offending application), not a crash of the whole system.
That doesn't mean that there were no bugs in the kernel and crashes resulting from those, but even already mid-nineties, Linux, while perhaps not yet comparable with the likes of Solaris and Interactive Unix, wasn't any worse than SCO Unix and much more stable than the 16bit offerings from MS. Linux kernel crashes were rare (not as rare as today, thanks to continuous effort of hundreds of contributors and the prioritizing of the fixing of regressions), more often however users experienced out-of-memory situations, which before the addition of the oom-killer could effectively freeze a Linux system for a long time or even indefinitely. Also the X11-server or rather some graphics card driver (part of the X11 server then) wasn't quite of the same quality and when it crashed, terminated the user's session (all of the user's application started during that session). I.o.w., used as a small server, Linux was reasonable stable early on, used as a GUI desktop system not so much.
Can we at least upgrade the fonts, colors, and negative space to make it look more 2020s?
Of course YOU can, it's open source, feel free to hack away at it.
https://paolozaino.wordpress.com/portfolio/risc-os-desktop-m...
discussion here:
https://www.riscosopen.org/forum/forums/1/topics/17696
Development seems to have stalled / slowed down.
Ew. Please no.
I hate 2020 OS design. It's flat and ugly and confusing.
And this is very much not just me.
https://medium.com/@jared.cyr/is-flat-design-overrated-1b9d4...
https://www.spinxdigital.com/blog/downsides-flat-design-tren...
https://www.nngroup.com/articles/flat-design/
1990s design was clearer, cleaner and better, dammit.
https://twitter.com/RetroTechDreams/status/17860872619535321...