Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Got an old Raspberry Pi spare? Try RISC OS. It is, something else

theregister.com

Post reply on HN
Print view View original

161–170 of 205 posts

Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else

#161

Post by pjmlp »

appstorelottery wrote: post #95

The most impressive thing to me was the inbuilt BBC Basic, and the availability of every system function to basic with SWI calls. 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 chi…

This was fixed around Visual Basic 5, when it got AOT compilation with VC++ backend, OCX tooling in VB, it got a sweet spot in VB 6. Naturally this was kind of triggered by Delphi's competition, and then .NET came around.

Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else

#162

Post by rbanffy »

lproven wrote: post #155
rbanffy wrote: post #150

Earlier quoted context omitted.

I still think it’d be fun to bring it back to life. I don’t think there are many copies still usable and it was picky about hardware - it wouldn’t run on more modern Acorn boxes.

RISC/ix? 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.

For me, the desktop apps are vitally important to rebuild the experience.

Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else

#163

Post by pjmlp »

lproven wrote: post #142
guenthert wrote: post #102

> 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…

Apple actually needed a little external help, as they were already on the red.

Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else

#164

Post by rbanffy »

tech2 wrote: post #156
rbanffy wrote: post #147

Earlier quoted context omitted.

That sounds like just brutally quartering users into their granular permissions. ;-)

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…

Sorry. I was joking. It feels like you are giving applications small fragments of the user.

Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else

#165

Post by rvense »

josephg wrote: post #152
pjmlp wrote: post #145

Earlier quoted context omitted.

Identity is reflected by who owns the capability.

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.…

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.

Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else

#166

Post by tech2 »

rbanffy wrote: post #164
tech2 wrote: post #156

Earlier quoted context omitted.

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…

Sorry. I was joking. It feels like you are giving applications small fragments of the user.

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.

Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else

#167

Post by RetroTechie »

dusted wrote: post #157
ajb wrote: post #7

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, ef…

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…

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.

Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else

#168

Post by com2kid »

pjmlp wrote: post #84
com2kid wrote: post #74

Earlier quoted context omitted.

> 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…

Unless one works for the games industry, does IT at big corp, embedded devices programming.

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.

Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else

#169

Post by lproven »

pjmlp wrote: post #163
lproven wrote: post #142

Earlier quoted context omitted.

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…

Apple actually needed a little external help, as they were already on the red.

Selling its shares in Arm Ltd kept it afloat at one point, I believe.

Who or what else?

Re: Got an old Raspberry Pi spare? Try RISC OS. It is, something else

#170

Post by lproven »

_akhe wrote: post #159
lproven wrote: post #136

Earlier quoted context omitted.

> simplicity of ... Raspbian 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,678MB » https://www.riscosopen.org/content/downloads/raspberry-pi « Complete SD card images RISC OS Pi 2024-04-28 06:15:00 For Pi Zero & ZeroW & Z…

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?

Post reply on HN