Earlier quoted context omitted.
_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 bi…
https://xkcd.com/1200/
Got an old Raspberry Pi spare? Try RISC OS. It is, something else
191–200 of 205 posts
Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else
#192It 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, ef…
> 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 mo…
Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else
#193Earlier quoted context omitted.
This is a very Android centric viewpoint ;)
Unpacking that witty but cryptic comment: 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…
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.
Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else
#194It 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, ef…
I don’t know why, but that’s fucking hilarious
Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else
#195Skimmed the article, didn't see this important bit mentioned: I'm pretty sure the OS is available through rpi-imager, meaning it's trivial to set up on an RPi and presumably has some notion of official endorsement from RPi org.
[Article author here] 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 readin…
Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else
#196Earlier quoted context omitted.
> 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 mo…
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…
Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else
#197Earlier quoted context omitted.
Oh not that tired old lie. :-( 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...
Not only I walk this planet since the 1970's, I lived through this "lie" on all key publications of the time, and I used the Cult of Mac site on purpose, exactly because I was expecting that reply of yours.
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:
Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else
#198Earlier quoted context omitted.
> 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 mo…
> Nowadays computers are almost never shared. 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 logo…
Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else
#199Earlier quoted context omitted.
Apps? So you would use this OS for the amazing consumer experience? And in your mind is that comparable to a Linux distro like Raspbian or Ubuntu in terms of availability of apps? Strange way to gauge simplicity too "this screen has 10x less pixels!"
What's better for a tiny underpowered computer with not much RAM... * 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.
Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else
#200> RISC OS gives applications access to much of the memory map, and so if a program accidentally scribbles over the wrong parts of that address space, the whole computer can freeze up – which in testing our Pi 400 did several times. Enough said.
Yep. There are good aspects and bad aspects to old-school 1980s OS design. 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 kerne…
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.