<story><title>Got an old Raspberry Pi spare? Try RISC OS. It is, something else</title><url>https://www.theregister.com/2024/05/02/rool_530_is_here/</url></story><parent_chain><item><author>ajb</author><text>It was ahead of its time in UX, but rather behind in the foundations. It&amp;#x27;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.&lt;p&gt;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)</text></item></parent_chain><comment><author>qwerty456127</author><text>&amp;gt; rather behind in the foundations. It&amp;#x27;s a single user system with no real security&lt;p&gt;I believe multi-user systems are actually an ancient, outdated rather than a &amp;quot;modern&amp;quot; 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.&lt;p&gt;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.</text></comment>
<story><title>Got an old Raspberry Pi spare? Try RISC OS. It is, something else</title><url>https://www.theregister.com/2024/05/02/rool_530_is_here/</url></story><parent_chain><item><author>ajb</author><text>It was ahead of its time in UX, but rather behind in the foundations. It&amp;#x27;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.&lt;p&gt;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)</text></item></parent_chain><comment><author>dajtxx</author><text>Home computers didn&amp;#x27;t need multi-user capability or much in the way of security (other than anti-virus) back then. I&amp;#x27;d argue they still don&amp;#x27;t. I don&amp;#x27;t think these two things were the problem.&lt;p&gt;I can take or leave shared libraries. They seem to cause a lot of trouble, but so do statics, so I&amp;#x27;m on the fence there. But in the context of when this was released it&amp;#x27;s a non-issue.&lt;p&gt;I&amp;#x27;ll give you the CLI thing though. If the CLI couldn&amp;#x27;t be full-featured in a window that was an oversight.</text></comment>