No more big 32-bit cores for RISC OS from 2022

Is this some sort of “twist and relaunch” game? Anyway…

Both sides might pause and consider why I didn’t mention BSD.
I know it was not free at first, I know there were legal issues. Basically it has an unfortunate past that caused people to steer away from it long enough for something else to be flavour of the month/year/decade.

In similar vein Linux has the taint of the GPL which seeks to acquire other code by close association.
What was that phrase I saw used in Linux circles?
Ah, yes “viral licence” – they seek to infect other code.

I mentioned anarchic development, that viral licence stuff appealed to the anarchistic streak in various of those techno-geeks that played with the early code (and probably currently)

Ah, yes “viral licence” – they seek to infect other code.

Absolutely correct.
IMHO, that was mainly an anti-ATT reaction. A protection against big companies.
And because of this, almost every UNIX dev switched to Linux and GNU systems :)

and because of the big buzz from Stallman

Stallman – mouthy bully boy riding on the talent of other people.

around GPL (and the fact that with the GPL, the big companies, as ATT, will never try to steal your work)

True, GPL gets there before the big companies and tries to tell you what you can or can’t do. Fortunately there’s enough wriggle room for the coders to relicense without GPL.

Stallman – mouthy bully boy riding on the talent of other people.

I can’t say I like him :)

I remember some legal dispute with one cover of Login: where Stallman believed we tried to compare GPL to Communism. Of course, it was sarcastic/ironical. I did understand then that this guy has simply no sense of humour. Not for me. Fortunately, a lot of big players in the Linux world (Red Hat CEO, SUSE now retired CEO, IBM chief of Open Source) were really very friendly people.

Anyway, the GPL did free a lot of developers. They became more important than companies. Today it’s not really needed any more, since Open Source is widely accepted. And BSD work is very interesting, especially for RISC OS…

@ Chris Mahoney

I hope I didn’t offend; that wasn’t my intention. I was just trying to explain Rick’s argument (or, at least, how I’d interpreted it).

No worries man, not offended or anything.

My original point to Rick was that BSD license (in whatever incarnation) did not help Linux to become the most used Kernel to date. Linux license for example is still feared nowadays by many many companies. So, if something, maybe the other way around (but that is just my opinion).

@ Steve

Both sides might pause and consider why I didn’t mention BSD. …

Actually thanks, I couldn’t have said it better.

I mentioned anarchic development, that viral licence stuff appealed to the anarchistic streak in various of those techno-geeks that played with the early code (and probably currently)

For what concern my personal position on Open Source matter, I’m afraid, but I am very passionate about it and very thankful that it has happened…

Yes GPL may sound viral to some who wanted to exploit some talented work for their own profits without sharing the profits with the actual original talented authors and so the GPL avoided that from happening.

GPL doesn’t block anyone from writing their own OS from scratch and make it copyrighted if that someone is that talented ;)

For me if it wasn’t for Open Source I probably would not have had a successful career as I did. I do not think of myself as a “rebellious developer” and such, I just think of myself as a lucky guy, who’s got in the right place at the right time and Open Source helped me a lot to skyrocket my career.

The knowledge Open Source allowed my generation to obtain is an immense value. Think of FreeBSD, Linux and Minix as our “Youtube” with free coding courses, bootcamps where to experiment directly on a parts of an OS/tool/technique instead of having to write an entire OS just to figure out how to do “process scheduling”.

Before OSS I had to spend nights and nights to figure out how RISC OS/AmigaOS/TOS/MS-DOS/XENIX/MonitorX or Y did things. Everything always resolved to using disassembly and rudimental reverse engineering techniques. Mostly because I come from a very small town in the middle of Italy where basically no one had any idea about how computers works. No bookshop with good books about computers and/or coding techniques, so the only help I had were the manuals that came with the above and some magazine with some tech article ala Archive/Acorn User etc. (but we did not have Archive in Italy!)

So you don’t think your desktop would be snappier response if a different core was handling a file transfer from one location to another?

How would that work with the current setup of RISC OS?

#0  I have this bit of data that needs written to disc.
#1  Okay, point me at it.
#0  Here it is.
#1  Great, thanks.
#0  Done it yet?
#1  Doing it now.
#0  Done it yet?
#1  Still doing it.
#0  Done it yet?
#1  Still doing it.
#0  Done it yet?
#1  Still doing it.
#0  Done it yet?
#1  Still doing it.
#0  Done it yet?
#1  Still doing it.
#0  Done it yet?
#1  Still doing it.
#0  Done it yet?
#1  Yup, it's done, you can continue.
#0  Thank &$%£!
#1  No problems. Seeya!

look at my original list and Rick said no…

[citation needed]

The 2nd time I shortened the list of BSDs available for free as BSD only, my bad I should have said xBSD I think I made a typo and meant to write BSDs.

Your bad indeed, because all those BSD incarnations came from somewhere. That somewhere is the original BSD, that was not free, and was rather messy in terms of licence and legality, as others have mentioned.

My original point to Rick was that BSD license (in whatever incarnation) did not help Linux to become the most used Kernel to date.

I never said it did. What is likely to have helped Linux is a combination of:

• being a ground-up freshly written kernel (so no chance of using somebody else’s copyrighted code, although some detractors have in the past falsely claimed that Linus ripped off Minix, which is comical given that Torvalds and Tannenbaum don’t agree on what sort of kernel is best!) and
• a licence backed by Stormtrooper Stallman that is aimed at keeping the source code available by fair means or foul.

Linux license for example is still feared nowadays by many many companies.

Probably those that actually bother reading it.

Believe me, there’s Linux in a lot of things that do not have any form of source code available. My media sharer? It has open telnet, so I can log in and read the kernel messages. My IPcam? Telnet and serial port. My other IPcam I have not looked at, but given it behaves in a similar manner on a slightly more powerful Realtek chip, I have no doubts. My Livebox? To their credit, Orange did release the GPL’d part of the sources. Eventually. My printer (either the HP inkjet or the Samsung laser)? I’d love to hook something up to a serial port, if I could find one, and see if it outputs anything at boot. I know it’s running a proper OS and not a little custom firmware as it’s the sort of printer with web server interface for setting it up. That sort of thing is better done with a small Linux inside. My PVR? Sources always available, but sadly not for the embedded binary blobs that controlled the video encoding and decoding, which made its promised hackability much less enticing as one could only really fiddle with the UI, not anything like “let’s snarf teletext #888 and make an SRT out of it”, or even really simple things like “adjust the contrast”. The hardware could, there appear to be hooks for both of these (as well as outputting AVI instead of MP4) but given it’s an undocumented blob, there’s not a lot that can be done…

tldr version: Numerous devices known (or suspected) to be running Linux. Not quite so much in the way of actual sources as mandated by the GPL.

without sharing the profits with the actual original talented authors and so the GPL avoided that from happening.

How does that work, exactly? If I was to make a widget, and it used Linux and some other stuff, then the exact wording of the GPL is that I must release the sources used within the widget. Some companies do in fact do this, though you’ll be hard pushed to find complete sources (all the proprietary stuff is omitted, regardless of how or what the GPL linkage thing says). So I could do the same.
At no time is there any obligation whatsoever for me to share any profit, money, or recompense (other than dumping sources onto a website) with the people that actually created the software that I am using.

The GPL is quite happy to allow companies to profit from your work. If you don’t believe me, allow me to introduce you to Android…

GPL doesn’t block anyone from writing their own OS from scratch

Of course not, but it does block using potentially more modern code (everybody devs on Linux these days…) with older existing projects that are not GPL and likely cannot be GPLised.

In effect, it’s a walled garden. The only thing is, it’s fun inside, there’s plenty of beer (which is apparently free – the oft quoted “free as in beer”) so nobody inside the walled garden cares much about what’s going on outside.

The knowledge Open Source allowed my generation to obtain is an immense value.

Oh, I don’t deny that Open Source is, itself of immense value. And as much as I loathe the GPL for the crock of poop that it is, one cannot say it hasn’t had an impact. An impact almost implicity tied to the stratospheric rise of Linux in basically pointing to the old corporates and saying “guys, there’s another way”.

Everything always resolved to using disassembly and rudimental reverse engineering techniques.

Good. I think that the low level stuff is sadly missing from modern lessons. My personal opinion is that a serious course on computing ought to include an entire section on stripping down and 8 bit machine (like a BBC Micro or ZX81) to understand how it works.
Because underlying all of today’s powerful OSes and frameworks and languages where variables don’t have an explicit type but are rather “what they need to be” is a more modern version of exactly the same thing.
You can see some of this in C, where you still get to determine what a variable is, and understand that even if you only need to count to a hundred, a 32 bit word may well be a fair bit quicker than a byte. Why? Because it’s what the processor handles natively.
Also, then things go wrong you’ll often find yourself looking at stack dumps and trace disassemblies. If you don’t have some sort of idea about the low level stuff, that all might look like gibberish.

hopefully we can re-focus on RISC OS now ;)

Yeah, it’s a bit disappointing that a misunderstanding over *BSD* took precedence over all the other points raised.

Other points:

• Security and stability within RISC OS and how it may apply to the IoT/embedded sector.
• It may have been harder to change ROMs, but floppy based OSs suffer from virus infections in a way that ROM based systems don’t.
• Plus DOS has a long history of mucking up its own filesystem. Perhaps why later versions came with SCANDISK as standard?

[etc]

;-)

there’s plenty of beer (which is apparently free – the oft quoted “free as in beer”) so nobody inside the walled garden cares much about what’s going on outside.

Free beer is not. Believe me it isn’t.¹

Other points:

Rather diverged from the fat linux (the warnings in the fat penguin) and slim RO, although being the OS designed for the processor rather than a port of a jack of all trades does give RO an advantage on ARM.

One thing that comes to mind is HATS – those are basically people trying to build in a hardware feature, the Pi lacked, so it was more like a desktop PC and less like a board for experimentation and development of IoT type “stuff”

What exactly would you characterise as the defining aspect of a RO programme with no GUI interaction that differentiates it from an IoT programme?

¹ I speak as the most vocal person in the room when the GBBF Working Party finally acknowledged² that giving the staff beer instead of selling it was good motivation for extremely cheap labour and likely to encourage better behaviour.
Beer consumption per head went down when the staff bar became a free bar.
What the workers missed was that they were more inclined to work longer – for absolutely nothing beyond the beer.

What exactly would you characterise as the defining aspect of a RO programme with no GUI interaction that differentiates it from an IoT programme?

bingo, now if you make that programme send data out using the network stack or control a light you may call it ROHue :D

So the things that RISC OS already has for the “job” are:

• It’s small (slim!)
• RISC OS 5.28 can work with little memory or large memory amount
• has Lua programming language
• has Python programming language
• has C and C++ (via GCC)
• has a network stack
• code can be modularised (user-space modules)
• The OS can be extended where it’s needed (it’s a Slim OS in the end)
• On an RPi Zero definitely beats Linux any time
• could potentially be stored in flash

What it doesn’t have yet are (the bare minimal):

1. needs support for multi-core
2. needs a process scheduler for headless/CLI RISC OS (but this can be added)
3. needs security (although if this one is optional on many IoT devices, sad but true)
4. needs support for WiFi and bluetooth (generally bluetooth is a must have for many IoT applications, WiFi is also wildly used)
5. needs cpuevent_wait() or similar when in CLI (CPU spins when in CLI and higher power consumption is not IoT friendly)
6. needs support for eMMC

Now the last one could be added via the process scheduler.

Security is a tricky one, we could tackle it in multiple phases. Just as an example:

• Phase 1: Add VProtect-like module that intercept all Obey/Run/RMLoad/RMRun calls and uses rules to determine if they are “allowed” and “clean”
• Phase 2: Add a network firewall
• Phase 3: Add support for signed updates (IoT updates can be unsupervised, so there should be at least a minimal mechanism to control and verify if an update is allowed or not). Alternative mechanisms/ideas welcome btw
• Phase 4: Improve FileSystem ACLs (from just protected/unprotected to something a bit more safe), this may require adding UIDs and GIDs support
• Phase 5: Add an auditing module to intercept all SWIs and control if they are allowed or not based on UID/GID and task ID (rudimental SE-RISC OS)
• Phase 6: OS code reviews and implementation of better secure coding practices where applicable

I think each phase may require its own discussion.

The above would also benefits RISC OS Direct and RISC OS Cloverleaf which wants to be daily desktops and so really really need security of some degree, especially with the introduction of Browsers supporting Javascript and, obviously, the traditional RISC OS user “download a zip and run it” activity! :D

just my 0.5c…

3. needs security (although if this one is optional on many IoT devices, sad but true)
4. needs support for WiFi and bluetooth

I think all the ones that do the latter fail the former – basically bluetooth and security don’t belong in the same paragraph.

WiFi is also wildly used

I was going to suggest that you possibly meant “widely used” but considering some of the sloppy implementations “wildly” is probably right. :)

I think all the ones that do the latter fail the former – basically bluetooth and security don’t belong in the same paragraph.

agreed

I was going to suggest that you possibly meant “widely used” but considering some of the sloppy implementations “wildly” is probably right. :)

Dang sorry typing here while doing other stuff as well! but yeah this time kinda works correctly :D

@Pablo (1) (2) and (5) can’t just be bolted on, or RISC OS will continue to lack modern features like (3) (4) and (6), and drastically underperform other OS’s on the same hardware. It needs to have ground up kernel threading like grown up OS’s, so all the other things you mention which assume proper context isolation and blocking I/O can be ported without the ridiculous workarounds needed to do anything on the ancient single context OS we currently have. 64 bit is the opportunity to do this, but will it ever see any applications?

Is there any way we could adapt the kernal from mbed os from arm?? or is that only cortex m cpu’s

@ Druck

(1) (2) and (5) can’t just be bolted on, or RISC OS will continue to lack modern features like (3) (4) and (6), and drastically underperform other OS’s on the same hardware.

So, while I personally would prefer a re-write from the ground up (for many reasons, not just (3) (4) and (6)), there is also the option of approaching the problem by defining APIs and modify things behind them as time allows it to happens, it’s not optimal, but it could be considered eventually.

For (1) I don’t necessarily think RISC OS should follow other OSes path, but that’s just my personal opinion.

64 bit is the opportunity to do this, but …

Concur 100%, 64bit is offering the opportunity to re-write the OS from the ground up and that would not impact the existing 32bit one per-se, but, if it has to be full on rewrite then:

• With which developers? I mean RISC OS has some extremely talented folks, no doubt, but are they enough for the task above?(and so a possible way to gain some interest would be to “hack” it to an IoT like on previous discussions in order to get some more developer interested)
• Have we considered the relationship between the pre-existing 32bit one and the future 64bit?

In other words, if ROOL decides to go for re-writing from the ground up, will it still be “compatible” in terms of :

• User-space APIs
• Programming techniques

Or should they be different? (with this I am talking about requesting memory for a process, SysCall conventions, instantiating threads, accessing resources and so on and so forth)

will it ever see any applications?

Well when AROS project started there was no Application for it, now it runs on a Vampire V4 SA and it has plenty of applications.

So, the way I see this is that a group of developers will unavoidably need to get together and kickstart the effort at least as an R&D initially. You know, just to figure out the best way to preserve the identity of RISC OS at the very minimum in user space. We want RISC OS in the end, not Linux. If someone wants linux it already exists ;)

For what concern existing software:

• Interpreted applications that do not require Supervisor mode (on AArch64 EL2) will only requires the porting of the interpreter.
• Compiled Applications with the same assumptions will required re-compilations, however a debugging phase will also be required due the fact that such applications may still expect the behaviour of a 32bit API (APCS32) which can be ported to AArch64, but there may be some behavioural differences on AArch64.
• I believe we should define a Universal Binary Format to allow the future compiled code to be architecture independent (this is my personal opinion). Such format should be produced by compilers and linkers and then transformed in pure executable by either the OS process loader OR at installation time (I am actually working on a set of R&Ds for this on RISC OS 5 and hopefully I can show something working soon, please no promises due to lack of time at the moment)
• Applications that require to be somehow in EL2 won’t be portable, at least in the initial phases.

I think considering the above and if RO 5 and RO NG (Next Gen) will maintain a compatible user-space set of APIs then RISC OS NG should have applications in the end.

AArch64 is not binary compatible with AArch32, so we all know that the cool tricks/approaches used to modify 26bit binaries to 32bit or like Aemulor won’t work.

AArch32 Applications code to work on AArch64 has to be:

• Binary ctranslated and in this case the APCS32 and RISC OS 5 32bit APIs have to be “emulated”. Basically like WINE does on Linux, so emulated here doesn’t means interpreted
• Re-compiled and adapted where needed to RISC OS 64
• Interpreted (emulation falls in this category)

Before we even endorse such a path, few things needs to be taken care of:

1. The official Compiler and programming language that should be used for the task
2. The overall architecture of the new Kernel, in order to envision how things will work together
3. The internal APIs and conventions that will need to be used in order to achieve better isolation and modularisation (without exceeding as on the Linux Kernel) I think a good assumption for RISC OS is that it will forever stays only on RISC CPU (it would make no sense call it RISC OS and run it on x86_64 I guess)

I personally believe that there is not need to make it right at the first attempt, an agile approach could be used successfully here, given the absence of pre-existing software to be maintained on the AArch64 version. So refactoring to best approaches is definitely viable.

Apologies for the utterly long reply, I do not poses the gift of brevity :(

Apologies for the utterly long reply, I do not poses the gift of brevity :(

“If you want me to give you a two-hour presentation, I am ready today. If you want only a five-minute speech, it will take me two weeks to prepare.”
– Mark Twain

In my opinion, for RISC OS to be much more than retro computing for enthusiasts, the only way forwards is a ground up rewrite incorporating all modern features, but following a similar(ish) design philosophy. This would include a emulation layer to get 26-bit/32-bit WIMP applications running more-or-less seamlessly with the new environment, and non-multitasked applications running in task windows. (For the sake of this exercise, you may assume a fantasy funding source with budget £N.)

…with budget £NaN, shirley? 8~)

In my opinion, for RISC OS to be much more than retro computing for enthusiasts, the only way forwards is a ground up rewrite incorporating all modern features, but following a similar(ish) design philosophy.

As a day-to-day system for regular computers users, this is probably the way to go. You probably wouldn’t want to completely start from scratch but, assuming no shortage of £££s and willing programmers to indulge, why not write a new OS?

This would include a emulation layer to get 26-bit/32-bit WIMP applications running more-or-less seamlessly with the new environment, and non-multitasked applications running in task windows.

Sounds like the approach successfully used by other systems to migrate users from a classic system to something more modern.

Ultimately, it’s more of a spiritual successor to RISC OS, isn’t it? Not that there’s anything wrong with that. I’m sure that if Acorn had done it, people would have been fairly happy with that approach.

In this thread the line “ground up rewrite” for RISC-OS pops up here and there. But now the reality check. The bounty for Ipv6 is still open and IPv6 is at least as important as 64 bit. So how big are the odds that someone will start this endouver ?. I think really small unless indeed some other multi biljoinaire really wants a new RISC-OS on his ( or her ) mega yought.
I indeed think the best to go that we need more and more parts of RISC-OS written in C which will simplify the migration to 64 bits processors. To accomodate 32 bit emulation is I think the way to go. I can run RO 3.1 on my Wintel laptop thanks to emulation.
To put the bat in the hen house why should we improve the OS with security etc I like RISC-OS as it is I can easily fiddle with the OS or hardware. For bank I use other OS.

You probably wouldn’t want to completely start from scratch…

Indeed. You’d probably use some other lightweight OS as the starting point. (Suggesting an OS for this purpose sounds like an excellent way of starting an argument.)

For bank I use other OS.

This, exactly. For all sorts of stuff I use a different computer. I use RISCOS for a few specific purposes, none of which require security – or, for that matter, IPv6…

For me, the only reason to migrate to another CPU is future proofing, against the day when my Pi3b dies and nothing is available that will run RISCOS.

ground up rewrite incorporating all modern features, but following a similar(ish) design philosophy.
This would include a emulation layer to get 26-bit/32-bit WIMP applications running more-or-less seamlessly with the new environment.

Let’s face it. The efficient way to do this is simply to adopt Linux and RPCEmu.
A completely new OS, with all the new technologies from the others, and no native support for RISC OS applications, is simply not RISC OS.
I mean, use Linux, modernize ROX, provide BBC Basic, then provide some “in native window” emulator as Aemulor.

No, really, I think we have other possibilities to grow and take fun:
- Finish RISC OS on Linux to open RISC OS to a maximum of AARCH32 SBC
- Provide RISC OS Neoverse instances on Amazon
- Integrate a better Aemulor directly in RISC OS Open code
- Provide support for multicore, multiscreen and a better Basic
- Be crazy, and make a RISC OS /26 flavor of RISC OS 5 for old computers :)

Or even cooler:
- Port RISC OS 5 to the AMBER soft cores.
- Evaluate the legal issues for the evolution of the AMBER Core
- Modernize the AMBER core and adapt RISC OS 5 to it
- Fund some ASIC “a la” SciFive
- Be happy with AARCH32 and don’t be shy to still code in ASM

I can run RO 3.1 on my Wintel laptop thanks to emulation.

And you don’t need an x86 port of RISC OS to do it. If the idea is to use current apps under RPCEmu, it’s IMHO much easier to simply boot RPCEmu fullscreen on a Windows computer. Why should I need a new RISC OS? For new applications? Most of them are ports anyway.

I presume emulater RISCOS is a hell of a lot slower than RISCOS running on a Pi3b?

For me, the only reason to migrate to another CPU is future proofing, against the day when my Pi3b dies and nothing is available that will run RISCOS.

“Compute Module 4 will remain in production until at least January 2028”. And will probably be available in some stores until 2030. And you’ll probably still find some second hand one or new from old stock until 2035. And you’ll probably need to wait until 2040 before most compute modules 4 will be dead (and 2050 if you make your own safe stock : I still have a working stock of Psion Series 3 at home). And best of all, the Pi5 and the CM5 will perhaps be still compatible with RISC OS too.

Even 2030 is far away. The idea of a desktop OS will be probably forgotten (or legacy) in 2030. Is RISC OS 5 useful as a server OS, or as a workstation OS?

I already told that, but the good idea for now is not a port, but a new best of the best RISC OS platform. A motherboard with native SATA support, parallel and serial ports, dual head and a very powerful CPU. OK, so a Titanium based on the CM4, with strong cooling solution, native overclocking and CM4 boards selected to be able to boot at 2.1 GHz or more. Then just try to unlock the 3 other cores. That’ll be a better progression in term of performances that you could hope with future ARM cores.

I presume emulater RISCOS is a hell of a lot slower than RISCOS running on a Pi3b?

Really a lot.