It was ahead of its time in UX, but rather behind in the foundations. It's a single user system with no real security, and there was no system of shared libraries - to share code between applications, it was usual to put the shared code in a kernel module and call the kernel. Even the standard C library worked this way.
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)
> rather behind in the foundations. It's a single user system with no real security
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.
Having grown up with RISC OS, I never considered lack of multi user an omission. But the lack of process isolation (or simply: lack of processes) was a real head-ache.
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.
Fair. On reflection I agree with all the people that have pointed out that multiuser isn't that important. It was just, historically, the feature that made operating systems become serious about security, which is now essential for other reasons.
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?
Today, the same OS core is used in phones, laptops, desktops and servers. Explicitly making it single-user means giving up on servers and parts of the market for the former three.
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).
One such case is company-issued phones. They require the company-provided apps to be isolated from any user-specific configuration, creating an effective multi-user system where user apps (such as Apple Music) run with different privileges (and network access) than, say, Teams or Outlook.
I think this is a good idea anyway. I love how if I install some dodgy app on my phone, it can't access the private, stored data of other apps. It can't steal my google or facebook credentials. And it can't cryptolocker my filesystem.
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?)
> I believe multi-user systems are actually an ancient, outdated rather than a "modern" concept.
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...
This is what uid and gid are used for in Linux respectively. There is only a concept of "user" and "group" when you add a Unix-like operating system in top such as GNU or Alpine.
No its not. There's all sorts of stuff you can do with capabilities that are really awkward to even think about with users. Like, when a database starts, you can hand it the capabilities it needs to access a specific directory, listen on a specific port and append (but not read) a specific log file.
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.
Capabilities can just be variables. Variables all belong to something, all the way up to the OS. Would you say variables are a type of user permission? Obviously not. Variables are more versatile than that. So are capabilities.
3rd party apps are written (controlled) by other people, and you are effectively granting that 3rd party permission to run their code on your device, so the user concept isn’t that far off the mark. Since ~nobody reads the source code of 3rd party apps, security vetting is usually a matter of deciding to trust the app’s author, same as how you would trust anyone else that you give a user account to.
You grant them capabilities, a handle which permits access to a particular directory, one which allows network access (or possibly even further limited than that) etc.
No user, just a series of object handles which permit them to perform the task and nothing more.
Sure, but capabilities and handles are technical terms of art below the level at which regular users need to understand. The idea that an app is another person using your computer is not a terrible abstraction in terms of helping people make sense of what's happening.
Maybe. But they're a bad mental model for software developers because user based security is way more limited than what you can do with capabilities.
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."
Maybe? I guess the difference is that with a capability object model (or similar arrangement) the _only_ way the application has to interact with the outside world is via those objects/handles it's been granted. There's no risk of escape because they only have access to the handles the process has been provided.
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.
Sorry, I appreciate the joke (really :) ) but I also worry that people keep trying to add the concept of "users" or an existing role or permissions model into capability-based systems when they're unnecessary.
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.
A capability is not an identity. And the difference matters a great deal in how you build software that takes advantage of capability based security models.
Capabilities are often transient. Or in a capability based OS, capabilities are given to a process when it launches and the capabilities naturally go away when the program closes. "Who owns the capability" is the wrong way to think about it. But I'll lose this argument.
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.
You're so obviously correct in this. TBH I think the only reason the term "users" come up when it comes to isolating programmes from one another is because that was the only hammer Unix had, so it was coopted. The original point stands, the actual multi-user aspect is completely secondary and unnecessary to 90% of people. I'm the only person who uses my computer, but still I want to be able to isolate application 1 from application 2.
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.
> 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.
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.
Modern multi-user paradigms also have very weird ideas of what’s shared. Like, installing or updating software is the same permission tier as accessing another user’s documents, wtf?
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???
I almost linked that in my ggp comment, but really I’m making the opposite argument as the comic.
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 me, a "modern multi-user paradigm" is Nix with Home Manager. Where most of my software is installed in my user's environment and not on the system level. Thus, if there were another user on the same machine, we could each manage our own software and updates without affecting the other.
> Like, installing or updating software is the same permission tier as accessing another user’s documents, wtf?
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.
Do not mix Windows Store (UWP) sandboxes, with Windows sandbox, which not only is pretty much alive, is making its way across Windows 11 updates since last year.
I share my desktop PC with my kids and wife (although, TBH, I use the PC 90% of the time and the rest of the family uses the remaining 10%). Although we use the PC one at a time, being able to each have his own environment does help. So multiuser is cool for me.
I think pervasive process/app sandboxing – or at the very least proactively and aggressing limiting process capabilites a la OpenBSD pledge and unveil – is a key development as well that's over the horizon as well.
(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...)
multi user support has other purposes. it means you can turn the OS into a server OS which can be shared across numerous accounts. lacking that capability means you dissociate a desktop OS from a server OS for no good reason.
This can actually make sense - why not make Electron a shared part of the OS instead of so many apps bundling it. As I understand Apple once built its entire GUI system around a flavour of PostScript which was designed for documents typesetting. Now the world just is doing a similar thing with HTML.
I'd be more mad about this if building native applications wasn't super shitty these days. Xcode crashes all the time. SwiftUI is terribly documented and buggy. And lots of standard things you see apple do in their apps are basically impossible to do from 3rd party code. And its impossible to debug anything because its all closed source. And windows has about 8 different native UI libraries that all look and feel different, and they're constantly making new ones instead of making one UI be good and well supported.
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.
> This can actually make sense - why not make Electron a shared part of the OS instead of so many apps bundling it.
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.
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.
Games pays badly, big corp IT pays badly, and unfortunately despite the difficulty, embedded tends to pays poorly unless you are at one of the big tech companies.
Apparently these libraries and the languages they are designed to be used with failed to offer sufficiently easy way to implement the UX people want.
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.
Home computers didn't need multi-user capability or much in the way of security (other than anti-virus) back then. I'd argue they still don't. I don't think these two things were the problem.
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 main limitations of the multitasking command window were that it couldn't be used to drop into a language like the inbuilt BASIC interpreter and then change screen modes in BASIC code, or draw graphics using the BASIC plotting keywords, and so on. The command-line UI foreground and background colours were configured in the host app (typically Edit) rather than being changeable dynamically from within the command-line environment. There may be other limitations that I am not aware of, but for text-based interaction with typical command-line tools or BASIC in text-only mode, it's fine.
Unpopular take but here I go (bye bye karma): Code sharing between applications, beyond what is basic, common and stable enough that it could live in the kernel, is not a good idea in the long run. It served a purpose back when memory was scarce and libraries (and their versions) few.
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.
Code sharing should not be done, because it is a hard problem?
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.
Sharing code runtime is not a hard problem, it's the wrong problem. Code _sharing_ shouldn't be done. Code _reuse_ sure, absolutely, and it's done right by including that exact, specific code at compile time.
And yes, stuffing whole OSes + apps + deps into containers is indeed not the solution, it's the symptom.
Nowadays there is also more and more nothing shared besides the kernel. Look at technologies like electron, docker, flatpak, etc.
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.
I'm not even sure it was ahead in its UX; it had a three button mouse, and daily operations needed all three mouse buttons. I had to use them for years at school and I feel you could never quite be sure what the third button would do. In some cases, it was like what shift-click does today, in other cases it selected menu items without closing the menu, in other cases it moved windows without bringing them to front and in yet still different cases it opened a _different_ menu to the one the middle-click did.
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.
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.
> you got different menus depending on whether you middle-clicked on the icon bar icon, or you right-clicked on the icon bar icon
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.
> 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.
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.
> Because you're got the overview right but your details are weird.
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.
I still have all my windows overlapping, and I suspect it's because my formative years were spent in RISC OS. Also I still find "File Open" dialogs weird - every app having a miniature and less-functional tiny 'Filer' built in...
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)