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

Might explain those still using RiscPCs.

If I was still using RiscPCs (which I’m not) it would be because IKHG doesn’t work on the Pi, and it was bloody useful. I don’t half miss the ability to make my own keyboard drivers in any powerful, flexible way – or indeed to continue to use the ones I made back in the day.

Yes. If an instruction to change mode is issued on one core, only that core is affected.

So, in theory, if the messaging method to communicate between them existed then a network stack operating in Aarch64 mode on one core and the rest of the OS on another core would work, but the user wouldn’t know about it.

Or take another featured item common on other platforms, write or port the code to an Aarch64 compatible binary run it in the 64bit core(s).

I don’t half miss the ability to make my own keyboard drivers in any powerful, flexible way

Do you still have IKHG, your description, and a handler module that it created? I might understand what you’re saying better by looking at what you were doing back then.

Though, note, my experience with Indian scripts is practically zero.

Oh, and didn’t InternationalKeyboard get in the way? That’s the one that hijacks all sorts of alt key combos isn’t it? Or did your driver simply replace it?

IKHG was International Keyboard Handler Generator – you could make as many different InternationalKeyboards as you liked, and switch between them to your heart’s content.

Steve: I really don’t know much about the details – just the bare fact that mode changes are private matters to cores.

Rick: The main thing from my point of view was the ability to define what the keyboard generated for any combination of modifier keys (shift, alt, control) with any “character” key.

IKHG was International Keyboard Handler Generator – you could make as many different InternationalKeyboards as you liked, and switch between them to your heart’s content.

In theory¹ changing the content of Internat.Intkey.layout.uk changes the effect of the keypress for the keys you edited, changing mappings in internat.intkey.inc.FNKEY (where FNKEY is specified when you run keygen / keyconvert -like the mappings when FNKey = FNLazarus²)

The problems with Alt keys start deeper and I think part of the irritation comes up from the kernel and the way that Alt-“L” is treated differs greatly from Alt-“left arrow”

So for some elements you could create a new keymap by running keygen with the right parameters and offering it a layout.clive but Alt-keys changes might mean scraping some of the BBC MOS cruft out of the lower levels.

¹ In theory I might know what I’m talking about

I’m not sure I’d want to see a 64 bit processor in a toaster. Damn thing would probably run a ten line Perl script for the toast functions, and forty seven other processes for the built in spyware.

At least you wouldn’t need a separate heating element.

But what happens next? Oh, wait, forgive me for thinking ahead…

It doesn’t matter, if they lost interest mid-way through the introductory briefing. They’ve found something else to do, which doesn’t come with such boring rules or such a steep learning curve on so many fronts. The question of what happens next will never arise.

If what they’re doing has the potential to be even vaguely useful¹, you encourage it and then deal with the other questions at a later stage. Or they deal with them for you, because you’ve then split the barriers to entry down into stages which are each climbable on their own.

¹ And realistically, even showing an interest in RISC OS is vaguely useful, given where we’re at for folk to do things.

I, for one, am not criticising.
I’m simply asking what ideas you’ve got, what you would like the limited developer resource to look at.

Sorry, didn’t quite understand that correctly the first time around.

I have no ideas to share now and wouldn’t even pretend to have any right to tell people what to look at. The point of my post was only to tell people what things looked like to me coming from the “outside” 8 years ago. I couldn’t see where people wanted to go and to me it felt like there was a lot of resistance to even discuss where to head, so I decided it wasn’t worth it.

As a developer big part of my work has been refactoring legacy code to more modern toolchains and to better follow patterns and using helper tools like frameworks correctly. I’m no master developer but I could have been useful because I don’t mind the grinding work as long as I can see a point in it but I just never saw it in RISC OS.

Would I join in RISC OS development now? No, that ship sailed those 8 years ago. That doesn’t mean I don’t want to tell people of my experience when I see the very thing that sent me packing repeated yet again.

@ Steve

( To do what?
Locked down, secure, stable and awkward to hack or
Open, insecure and easy to hack for study, learning, development.
Or both, somehow. Off the top of my head I mentioned a woolly idea earlier. )

Great idea! Can we put it to vote please?

I am for B just because the world is missing that while every other major player is going for A. But B will have no money market, because put it in a production environment will pose issues, so B is potentially an “investors-less” option, unless an HW vendor seriously interested in making a MicroBit like device only for learning.

IMHO C would be ideal world, but to achieve that a lot of thinking should be put into place to always make the right choices.

With regards to C, in the real world one shouldn’t sacrifice freedom for security (said better by Benjamin Franklin). I guess something similar ought to apply to operating systems – you can have freedom or you can have security, pick one.

Personally, myself, I’d go for B. If I wanted security, I’d be using Paranoid Linux. Those sorts of things already exist.

If I want something to play with, I don’t want to have to fight the OS every step of the way.

That said, fixing the mess that is the RMA would not be a bad thing. ;-)
Nor would downgrading all modules SWI entries to SYS mode (basically like USR) unless they specifically say they need SVC level.
And… [insert pet bug here]

@ Theo

It’s also worth saying that I have a use case for spending a little work time on RISC OS – if it were AArch64. It isn’t, so it doesn’t work for my purposes.

Same for me, quite a few actually: IoT, AI/ML, Modern Desktop. Then for the crazy ideas (which if people want to contest, please be my guest, but also be ready to be ignored!) Port to ThunderX3, why? because I want to and, even if it may be too much work and take me too much time and have to stop in the middle, for me it would still be worth the learning process.

Just out of interest – how many people here have read Andrew Tanenbaum’s book?

@ Rick

how many people here have read Andrew Tanenbaum’s book?

Which one? I have read multiple of his books back in the days, together with others (similar) from Stallings and others from Patterson (on the same line). On top of that I worked on different OS related projects from adding multi-task features to MS-DOS and FreeDOS, to embedded Linux Distro creation and now I work on Linux Distribution for high network performances and Cyber Security. it has been a long career, but I loved it so far :D

That said, fixing the mess that is the RMA would not be a bad thing. ;-)
Nor would…

and when you’ve finished sliding down the road to option A…

Would you care to join me by modifying it to C.
We could start by implementing a simple encryption/decryption¹ module that opened the encrypted disc area and booted the contents

¹ Plenty of ARM routines for encryption with very little code to them

@ Steve P.

Bq. Would you care to join me by modifying it to C.

I am happy to help with whatever I can, my available time is the weekend, but I am sure I can work some task out in that amount of time. I know it’s almost nothing, but that’s all I have :(

I think the A (fun, hackable, and “pure”) and B (modern, secure, and “pragmatic”) sides are fundamentally incompatible ¹, and that a compromise will inevitably be the worst of both worlds. The only realistic way forwards is the F-word, in the hope that the two “sides” would mutually cooperate once their relationship was less adversarial. (Once again, a fantasy supply of labour is being assumed.)

¹ “That’s a clever trick you’re using there… We’ll make sure to block it in the next security update.”

If there was a common vision for RISC OS

Yep, we have a roadmap. It’s more evolution than revolution, but common things are always like that.

The response is “Have a go"

Yep

But back to 64 bit. Yes we should try to get RISC-OS working on 64 bit.

And all efforts to rewrite RISC OS components in C are little stones on the 64bit road.

Given the above issues, the RISC OS build process needs to start incorporating a new toolchain, and eventually move to it exclusively.

Correct. But as the GCCSDK team could not like some needed changes, perhaps it would be possible to base the new toolchain on a fork ‘as closed as possible to the original’ of GCCSDK? The same way we have our own version of Perl.

Would I join in RISC OS development now? No, that ship sailed those 8 years ago.

I still you use for fun and serious things.

We could start by implementing a simple encryption/decryption1 module that opened the encrypted disc area and booted the contents

Interesting. As RISC OS is not a server OS, easy things can be done for correct security.

1/ Protection from external attacks

• Integrated full disk compression and encryption technology
  (could be done on a second core)
• Hardened networking stack
  (firewall, socket overload protection, ping security)
• A quite good web browser. With or without JS

2/ Protection from internal attacks

• Limit native execution to only signed apps
  You’ll be warned the first time you launch some non signed code
  – Choice 1 : accept the risk = the code will be self signed for future uses
  – Choice 2 : refuse the risk = the code is blocked
  – Choice 3 : transfer the risk = launch the code in a container
• Massive warning if the ROM used is not signed.

To protect an OS is not so complex :)

and when you’ve finished sliding down the road to option A…

Fixing some brokenness does not equate to “security”, it just means things are a little less broken. ;-)

Limit native execution to only signed apps

The problem with signed apps is that it requires some sort of oversight to provide the signing and raises the bar for all third party apps (that would need to be signed to satisfy the OS).
It might work in an environment with some sort of central app store where it can be semi automated (though note that Google’s app store is rife with nasty stuff, and Apple’s famously walled garden isn’t immune either).
Now I’m sure somebody will be thinking “oh, there goes Rick shooting down an idea” so let me preempt that by asking a simple question – what is the point of signing apps when there exists a system call that will happily give full kernel level privileges to the caller and the entry points of most third party modules run with the same sort of privileges…?
Things need attention long before we look at options such as signed apps.

Massive warning if the ROM used is not signed.

Which could put people off rolling their own?

To protect an OS is not so complex :)

Smiley face noted, however I don’t imagine it would be too difficult to sneak in a key logger that sends compressed recordings of keypresses to some sort of server.

The reason it isn’t done is because nobody around here is that much of an asshole, not because it can’t be done.

easy things can be done for correct security.

I see we have different ideas regarding what the word “security” means. The RMA for example, is a place where important system level code and data reside, all intermingled with extension code and data, all freely writeable from any BASIC program.
Basic protection of operating system workspaces from non-operating system code is the sort of security I’m thinking of in the short term. Yes, encryption and such may be a good goal to aim for, but other stuff has to change beforehand.

We’ll make sure to block it in the next security update.”

That’s because the likes of Apple and Google don’t want people to have full control over their devices (granted, in 99.9% of cases that would probably end in disaster).

I think the A (fun, hackable, and “pure”) and B (modern, secure, and “pragmatic”) sides are fundamentally incompatible 1, and that a compromise will inevitably be the worst of both worlds.

Who said compromise? I’ll answer that for you – you did.

I suggested a twin stream where the “open” version didn’t run the encrypt/decrypt and therefore couldn’t read the disc area of the secure version, but the secure version would be able to read both.

In some respects it’s the a logical follow on from the multi-boot stuff done in Select, but with a more secure and sensible build. Back when select was a thing (for some, and ignored by others) disc space was still at a premium and having two areas of disc was unthinkable extravagance, now 4GB isn’t large disc it’s a small, old style, memory stick that could be so small you lose it in the fluff in your pocket.

The only realistic way forwards is the F-word,

Totally lost me on that one, unless you mean Fork as in “Fork Off”
Which is something I don’t see a reason for, if you take my option C wooly suggestion and think about how that could work.

That’s a clever trick you’re using there… We’ll make sure to block it in the next security update.”

In the secure side yes. On the open boot, why?

Interesting. As RISC OS is not a server OS, easy things can be done for correct security.

Seemed like a useful point for a thought exercise.
First what encryption. Well, do a quick query, on the search engine of your choice, for “small encryption ARM” and see how many open licence simple encryption routines you can find.

Fixing some brokenness does not equate to “security”, it just means things are a little less broken. ;-)

There is no single item to work on to fix everything, working with option C the developer can do initial test work on the open OS boot and move over to the secure later. How to make sure dodgy applications don’t appear on the secure side?
Ah someone mentioned signing.

The problem with signed apps is that it requires some sort of oversight to provide the signing and raises the bar for all third party apps (that would need to be signed to satisfy the OS).

And the problem with current applications is that they usually need a filetype allocation which someone has to administer. This is just an extension of that.
A central store for the signed/unsigned applications? I propose we create one and call it something like !Store – oh, someone did that already.

If (big IF) the environment has a clear path for development, of the OS and applications, then developers are more likely to feel they can do something.

what is the point of signing apps when there exists a system call that will happily give full kernel level privileges to the caller and the entry points of most third party modules run with the same sort of privileges…?
Things need attention long before we look at options such as signed apps.

So that drops into the workstream after the initial dual boot secure/nosecure work.

Basic protection of operating system workspaces from non-operating system code is the sort of security I’m thinking of in the short term. Yes, encryption and such may be a good goal to aim for, but other stuff has to change beforehand.

There is no must on the order.
The fact that buggering about with stuff in memory can carry out actions with full privileges does not negate the fact that the only version of the OS able to read the encrypted disc is the secure version and the logical accompanyment to the encryption module is a password module.
Only someone with the password can run the secure version, so only someone with the password can read the data stored by that version. Don’t you think that improves the GDPR compliance somewhat?

Keep arguing, I’m not a tender soul so all the objections do is make me think of possible ways that the objection can be countered. If I can’t think of one offhand, I’m pretty sure someone else will.

see how many open licence simple encryption routines you can find

Not that people should assume that the simple encryption is the final item, unless it happens to be using a fairly solid encryption and even then there’s future development to deal with future hackers.