7 ms·

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 librari

• dietr1ch 2y ago
  Sharing code? I like my apps bundling a whole browser to render a couple buttons
  • hedora 2y ago
    The march toward systemd-electron continues.
    • qwerty456127 2y ago
      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.
      • dajtxx 2y ago
        Because I'm old and I'm sick to death of everything being a web app. Because I hate web app programming so it limits my employment options :-)
        • qwerty456127 2y ago
          I feel the same.
        • josephg 2y ago
          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.
      • com2kid 2y ago
        > 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.
        • qwerty456127 2y ago
          > people ship electron because it works the same across different OSs 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.
          • com2kid 2y ago
            > 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.
            • pjmlp 2y ago
              Unless one works for the games industry, does IT at big corp, embedded devices programming.
      • squarefoot 2y ago
        > why not make Electron a shared part of the OS instead of so many apps bundling it. Because it's a wrong approach to a problem that was solved decades ago by much smaller and faster system libraries for UI development.
        • qwerty456127 2y ago
          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.
      • deleted 2y ago
        [deleted]
      • pjmlp 2y ago
        Microsoft already did that with Windows 98, it was called Active Desktop. And you're mixing Apple with NeXT (NeXTSTEP) and Sun (NeWS).
      • idle_zealot 2y ago
        > why not make Electron a shared part of the OS instead of so many apps bundling it You're describing a system webview, which is a thing on Android, Windows, iOS, and macOS.
        • jokab 2y ago
          Isn't Chrome OS a better fit for his description?
      • mixmastamyk 2y ago
        One attempt, XULRunner didn't work out.
• amiga386 2y ago
  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. You can get a flavour of its programming environment from http://www.riscos.com/support/developers/prm/ 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.
• tom_ 2y ago
  A previous bit of discussion: https://news.ycombinator.com/item?id=37796610 https://news.ycombinator.com/item?id=37796610
• qwerty456127 2y ago
  > 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.
  • mikepurvis 2y ago
    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?
    • eddd-ddde 2y ago
      _Technically_ it doesn't have to be. 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???
      • mavhc 2y ago
        https://xkcd.com/1200/ https://xkcd.com/1200/
        • mikepurvis 2y ago
          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.
• dajtxx 2y ago
  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.
  • Symbiote 2y ago
    I don't remember any limitation of the windowed CLI on RISC OS, except it was slower if there was a lot of output. 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.
  • xyzzy3000 2y ago
    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.
• stkdump 2y ago
  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.
• pjmlp 2y ago
  Back in my day we shared code with static libraries, it appears to be quite hip in some Linux distributions nowadays.
• rbanffy 2y ago
  It’s a bit like what happens when you hit Stop-A on a Sun workstation, but in that case you are dropped to the basement under the OS.
• dusted 2y ago
  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.
  • RetroTechie 2y ago
    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.
    • dusted 2y ago
      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.
• flawsofar 2y ago
  > the command line appeared at the bottom of the screen and the frozen gui scrolled up as you entered more commands I don’t know why, but that’s fucking hilarious