IRIS XMAS

Not really. The LGPL requires the modified library to be released under the LGPL (and therefore as Open Source). I think something got lost in translation here.

You said GPL :-)

I’ve ported WebKit to many STB manufacturers’ devices, over the years. There’s almost no reason to ever patch it, though we do tend to back port features from newer versions (STB vendors hate upgrading). We supply those as a series of .patch files which the vendors offer for download from their support site (I know most don’t bother).

We have a a few tens of other patches for custom features that are no use on a desktop browser (blitter accelerated flips, larger carets so you can see it from a distance…, and many patches for obsolete compilers that STB vendors love).

For a desktop browser (where you can use a modern compiler and keep the browser up-to-date), I doubt you’d need to patch anything. It’s designed to be linked as a library and the whole UI layer is BSD licensed.

I have the latest JVM version ever released with StrongARM fixes (no idea if you’re refering to this one or something that has never been released). The version I have failed to run pretty much most applets, does run the swing demo

If it can run Swing, then it’s a Java 1.2 demo. That was a different code base, and very much work in progress, and yes, probably would fail to run many applets. 1.0.2 was far more polished, though still massively underpowered compared to a workstation of the time. We also stored the class libraries in ROM on NCs so the startup time was negligible.

My point was simple: RISC OS, in the form and way it’s still designed to this day, is not an ideal (or even average) platform for Internet browsing.

Maybe. I’m skeptical. In the case of Java, it was the hardware, not the OS, that was the (performance) limitation. The memory bus was painful, even with a StrongARM, and no FP. I seem to recall an ARM7500FE was faster than a StrongARM, sometimes. But it was quite usable (with the JIT).

Oh, and the constant wimp polling was because I could never figure out how to determine if the threads were idle. Sun had a C-threading library (gosh – I remembered the name: https://en.wikipedia.org/wiki/Green_thread ) which was incomprehensible. Switching to “native” threads was the intention, but needed 1.2 onwards. It didn’t get started.

Oh, and the constant wimp polling was because I could never figure out how to determine if the threads were idle.

I suspected that. However, the interesting part is that even modern interpreters still present the same issue (Jainja on RISC OS 5, now).

For my VM I have complete control, so it doesn’t happen, but then again Ultima is designed for RISC OS, so a complete different world.

I still think the JVM on RO was an impressive achievement, I think I should make a video of it running on the fastest RPC I have using Kinetic SA 300Mhz + Fast RAM access (Kinetic had local fast memory, fixing the issue you’ve mentioned), but it still feels slow, compared obviously to WS of the time.

There is an OSS project (I have mentioned: Jainja), it would probably benefits from your experience/expertice, althought if it’s a limited JVM, so nothing particularly “game changer”.

and Java briefly thrived on mobile phones with low-end ARMs without JITs

Ah, yes. My little Nokia ran J2ME or something. It ran a very basic version of Opera Mini (because the screen was something silly like 128×160) along with a star chart and a little telnet app that I could use to log into my POP3.

Opera was essential as the built-in browser was WAP. Oh, god, WAP…

Actually “oh, god” was when you realised what the data prices were back then. I think it was something silly like €1 for every 10K. 😱
That’s a mistake you only make once…

I had eBuddy on my Nokia 6275i (how do I even remember that number?), which let me chat via the MSN Messenger protocol. From memory it was $10/MB (which is around 5 Euros).

I think if Nintendo 3ds can get a browser with video playback, Risc OS probably can too.

I think if Nintendo 3ds can get a browser with video playback, Risc OS probably can too.

Except all current browsers require OpenGL… That’s fixable (if you accept no 3D transforms, no WebGL, etc), but it’s work.

Also I suspect IO performance will be a problem for caches. But other than those, I can’t immediately think of any particular blocker issues.

I recall we (Tim D) were going to extend the Wimp to send separate key up/down events, for Java. A browser will need the same, though most things work fine with them faked. And someone really should add network polling.

Maybe I’ll download the Pi Iris image sometime.

I stopped believing in RISC OS as a platform for web browsing long ago.

I’ve benchmarked Iris against Chrome on my Mac, there is a magnitude of differrence in the performance and the scores achieved, but I also benchmarked it against my Amazon Fire 8HD running Chrome and Fire OS 7.X (Android 9), and the scores for a RPi4B (Oc’d to 2100MHz) and the Fire 8HD were virtually identical.

but the browsing experience is far better on the Amazon Fire 8HD, as it is hardware accelerated for the UI, if RiscOS could manage even 2D acceleration the difference would be night and day in terms of usability for web browsing, I know this isn’t a small task and far beyond my abilities but it would make the whole OS far more usable.

I’ve benchmarked Iris against…

Out of interest, what sort of benchmarking? I suppose the best comparison is on a Pi4 running PiOS and a Pi4 running RISC OS, both clocked to the same value.

I’d hope JavaScript benchmarks would perform essentially identically. However, something graphical like MotionMark will never perform well without acceleration (ironically, one canvas sub test will perform better in software because it repeatedly copies a canvas to a JS array, modifies one pixel, and uploads it to the GPU – something with OpenGL is not designed for.) MotionMark is 2D, so could, in theory, work well without OpenGL (I assume SpriteOps are accelerated?).

I keep meaning to do it, but I have a Pi400 which is a long way from the nearest ethernet socket.

I’ve benchmarked Iris against Chrome on my Mac, there is a magnitude of differrence in the performance and the scores achieved

There’s quite a difference between Iris and Chrome running on a cheap tablet that’s not altogether different in spec to a better Pi.

I guess that’s what being able to use all of the cores brings you, not to mention hardware acceleration.

There are things we need here and now before we need an additional 32 bits. ;)

it would make the whole OS far more usable.

It would make certain tasks on the OS far more usable. The whole OS is not that bad really, as it is pretty lightweight. We don’t have rounded windows, title transparency, or any of that crap to worry about.

I guess that’s what being able to use all of the cores brings you, not to mention hardware acceleration.

Honestly, browsers benefit from multiple cores much less than people have been led to believe. Most browsers are almost entirely single core (per tab), with process separation for networking largely for security not performance (though the underlying network IO is probably more efficient on multicore OSs). Image decoding, and half HTML parser (the tokeniser) can be farmed off to a separate thread, but not a lot else.

The whole OS is not that bad really, as it is pretty lightweight.

Indeed, from a performance point of view. 99% of browser execution is within the browser or graphics library. As long as you have modern C and C++ libraries WebKit can run on bare-bones OSes with OpenGL and BSD sockets and not a lot else. Older versions (ie. no longer suitable as a desktop browser) could easily be made to work on a simple memory mapped frame buffer.

We don’t have rounded windows, title transparency, or any of that crap to worry about.

All handled by OpenGL for free (excepting some additional memory) on anything mainstream.

[I suppose it’s Metal on Macs, and everyone else is moving towards Vulkan.]

what sort of benchmarking?

I’ve run MotionMark, and I know its obsolete but it’s interesting to run Octane 2.0 (Single Core), on Octane 2.0 the RPi4B 2100MHz performs virually identically on RiscOS as it does Chgrome on Linux on the RPi4B and slightly slower than Chrome on the Fire 8HD.

On MotionMark the scores are:

RiscOS:
Total: 15.59 -/+ 27.64%

Multiply: 159.50 -/+ 2.12%
Canvas Arcs 1.00 -/+ 500.00%
Leaves 42.06 -/+ 2.50%
Paths 1.00 -/+ 0.00%
Canvas Lines 267.60 -/+ 3.45%
Images 45.20 -/+ 3.83%
Design 1.00 -/+ 2.07%
Suits 43.11 -/+ 2.56%

Fire 8HD:

Total 169.76 -/+39.85%

Multiply 103.14 -/+ 22.33%
Canvas Arcs 629.89 -/+ 4.45%
Leaves 94.43 -/+ 3.99%
Paths 2718.51 -/+ 1.05%
Canvas Lines 2135.71 -/+ 0.68%
Images 8.07 -/+ 4.22%
Design 37.00 -/+ 92.30%
Suits 64.82 -/+ 15.72%

so there are a couple of tests that the RPi4B RiscOS out performs the Android 9 Fire 8HD with Chrome, namely Multiply and Images, but the Fire 8HD out performs RiscOS in all others.

The reason I said far more usable is it would open up accessibility to web applications, you can for example get Google Documents to load but you’ll have had a birthday or two before it fully loads and catches you up with touch typing a paragraph, and this is easily doable on the Fire 8HD.

There are things we need here and now before we need an additional 32 bits. ;)

THIS, VERY, VERY, VERY much this.

Except all current browsers require OpenGL

Yes and RISC OS could have it, statically linked to Iris obviously (so not really RISC OS, but let’s be generous with the definitions). For instance on the Pi 3 we do have Khronos and OpenGL for “RISC OS” (again library to be linked to a single app, not an OS extension), thought we do not on the Pi4…

I’ve benchmarked Iris

You did an amazing job Andrew, so thank you.

But my definition is different. Given RO runs on a Raspberry Pi (max 4), I am not expecting performance on pair with my macs and PC. However, Iris should be able to render and interact with the sites I use or that people that use my tools use, here is some example:

1) OpenAI ChatGPT is not working with Iris
2) A bunch of JS based IDEs (yes we can have a modern IDE on RO just using Iris, no need to “fund” certain folks), worked at the beginning and now they don’t
3) YouTube, have you tried to benchmark youtube videos on Iris ;) (I am being sarcastic)
4) This is not Iris, it’s RISC OS, but still it’s the “sum” that matters here, any website that has sensitive data, DO NOT use ANY browser on RISC OS, they will cache sensitive data in !Scrap… ‘nough said.
5) Many regular sites still present weird behavior, not a biggie per se, but if I need to access them, I certainly won’t use Iris or any other glitchy browser
6) If, by absurd, we accept all of the above as “fine”, then there is the issue (still unresolved) of Iris messing with SharedLibs and so with Python, RiscLua etc…
7) If, by absurd, we accept all of the above (intended repetition here), then there is the fact that on some Pi it still fails to run fine, requires specific configurations etc. (again not a biggie per se, but on top of everything else… well…)

Again, Iris solves a lot of issues too, so let’s not point out only the problems:

1) Hotel/Cafe/Train WiFi access when using wbe proxy is no longer a problem (but security still is and therefore this one I would classify as limited benefit)
2) We can start building JS based apps for RO that in many cases now, thanks to Iris, work, this simplify many things
3) We can browse many (unfortunately not all) modern web sites now on RISC OS, yes it’s slow, but it can do it
4) In the future we’d be able to access and use (hopefully in a fluid way) things like Google Apps etc.

So the discussion is only around the fact that it is an improvement (no doubt about it), however I do not think it gives RISC OS (the OS) the title of “good platform for internet browsing”. Pretty much everything else I own, from my phone to my laptop and raspberry Pi (so the HW for the Pi), do a much better job at it than RISC OS does. This may change in the future and if it does, awesome. So not being negative as an absolute state of mind ;)

In other words there are more issues than just the lack of OpenGL. Things can be fixed with work, a lot of work.

Things can be fixed with work, a lot of work.

Would fixing the copy/paste behaviour be a lot of work?
I have to type the above quote myself.

On MotionMark the scores are:
Images 45.20 -/+ 3.83%
Images 8.07 -/+ 4.22%

Thanks for that. It pretty much matches my expectations.

Images is the subtest that is throttled by OpenGL, so it’s good to see that matching your testing (the images fade away one random pixel at a time, but under OpenGL that’s hard).

Google Docs sounds disappointing. I wonder if it’s switched to compositing mode and drawing more than anticipated. Hopefully that can be accelerated (in 2D).

Yes and RISC OS could have it, statically linked to Iris obviously (so not really RISC OS, but let’s be generous with the definitions). For instance on the Pi 3 we do have Khronos and OpenGL for “RISC OS” (again library to be linked to a single app, not an OS extension), thought we do not on the Pi4…

The current approach is full-screen, isn’t it? It’d be like Arthur. A per-app approach would presumably limit it to one concurrent OpenGL app, and I’m sure that would go on your bug list :-)

4) This is not Iris, it’s RISC OS, but still it’s the “sum” that matters here, any website that has sensitive data, DO NOT use ANY browser on RISC OS, they will cache sensitive data in !Scrap… ‘nough said.

Why would it do that, and how is that the fault of the OS? The browser should honour the HTTP headers, otherwise it’s a bug.

Paul

Would fixing the copy/paste behaviour be a lot of work?

No idea sorry, not sure what is causing it, but I agree that is frustrating.

@ Piers

The current approach is full-screen, isn’t it? It’d be like Arthur.

AFAIR yes, but we can “fake” the visible window area and put it on top of the current RO window, not elegant, but you know… I mean some video player should be doing this already IIRC. There are also software-only ports of Mesa, if one wants to list all available options (but the Mesa lib has no HW accell).

A per-app approach would presumably limit it to one concurrent OpenGL app, and I’m sure that would go on your bug list :-)

Probably yes, but I don’t see an OpenGL integration with the WIMP any time soon. Probably not even in my life time, given the signals we are receiving, like the “direction” is still producing ROM images that fits on a RiscPC and even still keep the old ROM Apps in the ROM image…

Why would it do that, and how is that the fault of the OS? The browser should honour the HTTP headers, otherwise it’s a bug.

To Be Fair I need to check again on the latest release, but for instance, the HMRC site produce sensitive info in the-page itself (we are not talking about passwords, we are talking about HTML content). The caching of pages can be a huge privacy problem on RISC OS, given everything can access cached data (and more). As you know well, there is not permissions system, nor proper memory isolation. I doubt memory is even zeroed out before being released (free()). So, I’d recommend NOT to use RISC OS (in general) for anything sensitive. Although one could argue that, given only a few use it, there is probably little danger.

However, when the Pi became popular, all the OSes (included RO) that were able to run on it, got fully analysed and for a bunch of security tools (including nmap and others), so I would not rely on “security through obscurity” for RISC OS, given it still run on a popular platform.

like the “direction” is still producing ROM images that fits on a RiscPC

To be fair, a “RiscPC” is currently the only way to run the OS on an alien architecture – and there are people who use emulation rather than native silicon.

and even still keep the old ROM Apps in the ROM image…

To be fair, also, unless this is actively causing issues it’s probably best left alone. It isn’t as if having the ROM apps present is taking developer time, they’re just there and automatically included, like the Econet module. ;)

To be even fairer, it can be very useful having Edit present if the system fails to boot. As long as you can get to a desktop you can get Edit for tweaking files, reading logs, TaskWindow, etc etc and it doesn’t need Boot or System or Scrap or a bunch of custom resources (or even a functional disc)…
…I rarely use Edit these days, but when I do I very much appreciate its presence. I would consider its removal from ROM to be a massive step backwards.

the HMRC site produce sensitive info in the-page itself (we are not talking about passwords, we are talking about HTML content).

Load a sensitive page (I used ‘payments’) into Safari or whatever, and look on the inspector’s Network tab. Then reload the page. You’ll see the various js, gif, css… files are all loaded from ‘Memory’, but the document at the bottom is always fetched. This is due to the HTTP headers.

If Iris, or any browser, is caching them (memory or disc), it’s a bug.

[It’s more subtle to spot in Chrome’s Inspector – you need to untick ‘disable cache’ at the top, then reload. The cached pages have their ‘200’ response code greyed out, and their load time is 0ms. The payments ‘200’ response code is black, and in my case, took 98ms to reload.]

To be fair,

To be fair, RISC OS is a vintage OS, and as such it has assumptions and architecture that were valuable when memory was expensive and bandwidth was low. That is the use case for RISC OS to exist and even thrive. That use case no longer applies to modern systems.

To be even fairer, that means RISC OS is nice the way it is for nostalgia people, but, at the same time, isn’t what is supposed to be for modern applications like modern Internet etc. So, I’d leave it as it is, the mentioning of certain things whas just to reinfornce the perception that such an evolution is most likely not going to happen (certainly not any time soon).

What I see, is: The addition of things like WiFi, NVMe support etc. (eventually even a 64bit port), are simply ways to continue to support (aka not evolve) that original paradigm. Hope this makes more sense.

to be even fairer, it can be very useful having Edit present if the system fails to boot.

You can always replace it with a CLI screen editor, but I am not suggesting, given that for me RO is just nostalgia.

Load a sensitive page (I used ‘payments’) into Safari

Or load an entire web site with tools like my CROWler and have a full and detailed analysis of every single bit of information the site does, included its vulnerabilities, scripts (included the in-memory ones) and more:

https://github.com/pzaino/thecrowler

There are also commerical extensions to integrate it with 3rd party tools and (given it’s the new trend) even AI¹ for complete automated analysis of what a browser does (either Chrome, Firefox or Chromium, next I’ll need to integrate with Edge and Safari).

There are commercial rulesets and plugins to have full security analysis of entire web and ftp sites etc. included network security (out of scope in this discussion), tracking side chains and their side chains recursively, WHOIS, DNS, SSL issues etc.

Beside the geek chat on who knows more about browser security, you’ve missed my point: A simple bug in RISC OS can have repercussions that are way more problematic than the same bug on modern platforms, therefore it should not be used for anything that may contain sensitive information. People are obviously free to do whatever they want, but as somone that has worked in Cyber Security for so many years, I can’t avoid pointing this out.

¹ not talking specifically about the madness called GenAI. In this case AI refers to all spectrum of pattern recognitions tools as well as GenAI for content sentiment analysis etc. when it comes down to have an analysis of what a page content is about.

are simply ways to continue to support (aka not evolve) that original paradigm

Certainly. We need to work with what is or simply give up. There’s no (wo)manpower for writing a new OS from the ground up, and even if that happened everybody else in the world would be like “Why didn’t you use <some existing OS that is probably Linux>?”. There’s a lot of things to consider when creating a modern OS and to do all of that and keep something that functions like the RISC OS we’re used to would be, well, non-trivial.

You can always replace it with a CLI screen editor

Why? Edit exists. The Desktop exists. Both are in ROM, both can be easily called up. Plus, note, it’s quite simple to open/examine/edit various files within the Desktop world. Not to much the CLI where it’s potentially a lot of typing getting anywhere, unless the editor includes a pointy-clicky sort of interface like the one in TurboC…
…in which case we’re right back where we started. Edit works. It’s already been written. Quite low maintenance as it’s as old as the OS itself.

Kicking Edit out of ROM seems like a bit of a self-own really. There might be more milage in kicking the internet stack out of ROM, since it’s practically useless without disc-based resources (or somebody fluent in magic incantations) and there are two of them, so one might as well just stick ’em both on disc and load them at boot time…

I see, also, the various bits of CDFS are also present. Do USB CD-ROM drives work with RISC OS? What about the more likely case – DVD-ROM drives?

A simple bug in RISC OS can have repercussions that are way more problematic than the same bug on modern platforms

Bugs are irrelevant. An OS that offers an unvetted command like OS_EnterOS and loads unvetted third-party extensions into the kernel area and has numerous hooks to allow software to hijack all sorts of things (KeyV, FileV, etc etc) cannot be considered suitable for use with actual sensitive information.
And if you use RISC OS in a business context, this may have GDPR implications as well.

as well as GenAI for content sentiment analysis etc

I think you meant “instead of GenAI” there. Given that the GenAI companies are quite notorious for being extremely light-fingered with every byte they can get their grubby mitts on, it would be foolhardy to ask a GenAI to examine anything sensitive. Even more foolhardy than using RISC OS to do it. ;)

Why? Edit exists. The Desktop exists. Both are in ROM

I’d prefer the desktop to be moved out of the ROM images as well and keep as much space for a better kernel, with security by design and a better VFS, threads and full memory protection (possibly having memory protection switchable on/off at build time to make use of the OS on MCU as well). But yes that would fall into re-writing it, which again means “ain’t gonna happen” (at least any time soon, althought if Simon is making progresses on that side I think, that is indeed a very exciting project).

Kicking Edit out of ROM seems like a bit of a self-own really.

Sounds like you’ve got stuck on this thing. Again, for me RO is nostalgia only and fun, so not bothered by the way it is. However to have it modernized, there are quite a few bits that need to be added, so some space will probably need to be made. Doesn’t have to be edit XD

Bugs are irrelevant. An OS that offers an unvetted command like OS_EnterOS and loads unvetted third-party extensions into the kernel area and has numerous hooks to allow software to hijack all sorts of things (KeyV, FileV, etc etc) cannot be considered suitable for use with actual sensitive information.

Sure, semantic here. I mentioned the bug for the chat thread. Rick, we discussed this billions of times and having to list every single time the list of issues is frankly boring, but yes you are correct RISC OS should not be used for anything sensitive information for many reasons.

I think you meant “instead of GenAI” there. Given that the GenAI companies are quite notorious for being extremely light-fingered with every byte they can get their grubby mitts on, it would be foolhardy to ask a GenAI to examine anything sensitive.

You can run GenAI models on your own systems and without sharing anything with 3rd party AI companies. A typical use case for companies (and security researchers) that use my CROWler with GenAI is to use LLAMA 3.2 (runs locally) to analyse sentiment and other characteristics of page content. So, there are options to avoid the data collections. But even if there wheren’t, I have developed foundational neural network library far more advanced than OpenAI ones which are available as AGPL and, given its based on Liquid NN theory, requires much lower spec HW to run than traditional NN, as well as I already did all the work to have HW accell for it on AMD GPUs (cheaper than NVidia), FPGAs, ARM GPUs (and Nvidia via CUDA) and next year I’ll add support for the modern NPUs, so it runs really well on everything, included laptops. On top of that Liquid NN are a lot simpler and quicker to be trained too.

I see, also, the various bits of CDFS are also present. Do USB CD-ROM drives work with RISC OS? What about the more likely case – DVD-ROM drives?

In contrast to previous experiences like “standard Risc PC with standard ATAPI CD-ROM connected to internal IDE”, where you had to be very lucky to get a working combination, USB CD and USB DVD and USB Blu-Ray is very compatible. Works flawlessly in almost all cases.

If a target of reshuffling ROM content is “out-of-the-box compatibility with as many data transfer variants as possible”, I would suggest exFAT and NTFS support as well as MBR and GPT support.