IRIS XMAS

A bit cheeky noting that ROD have made Direct V3 available recently which contains IRIS.
But IRIS seems to be the same version as January 2024.
Is there any chance of seeing a free download standalone version of IRIS (ie can be used on RO not necessarily with RO Direct) maybe as a RO Xmas present ?

A new version of Iris would be most welcome, especially if it supports Copy/Paste again (quite indispensable for use with DeepL or Google Translate).

I dont think were ever going to see a stand alone version of Iris that is free without it being part of something else. After all this time of seven years, I think it is being held back for the commercial advantage it gives one of the owners of RiscOS Devs. What happened to all the £50 payments for the free and genuinely open source Otter Browser that we could buy?

Like much of the stuff coming from there, it is described as open source. But where is the source? Why cant we see the source. I dont think they understand what open source means. Just calling something open source dosent make it open. And just saying it is a beta version for years and years is not an excuse. Even the author has called it version 1, not 0.9 or something. I know they bang on about the support burden of releasing it, but just release it and let the community support it.

I live in hope, and have done for seven years. I’m glad I didnt pay the £150 to be a shareholder now.

Crumbs.

I’ve googled and not found anything from ROD saying they’ll open source their port. I’m not sure they should feel they have to – Google don’t open source Chrome. Apple don’t open source Safari. (Mozilla do open source Firefox). Iris is based on an open source browser, but that’s not saying they’ll open source everything.

I think you’re underestimating the effort of porting a browser engine. Having done so numerous times in my career (to numerous embedded Linuxes, embedded Windows, ST’s OS21 and Symbian), and having ported Java to RISC OS (which in many ways is similar) I can speak from experience.

It is man years of effort to port WebKit to something. RISC OS is even trickier because the compilers weren’t suitable. Updating those is substantial effort – gcc doesn’t support the same procedure call standard as RISC OS, so RISC OS was (rightly) updated to support what gcc generates.

Modern WebKit only supports OpenGL, which RISC OS lacks. So to support software rendering is a huge amount of extra work.

WebKit does not have a frozen API. Updating a port can be many months’ effort for a new version, which is a huge amount of extra development cost.

Given the size of the RISC OS hobbyist market, it’s impossible to fund – we’re talking many hundreds of thousands of pounds, if they had to pay real salaries. If they’re able to sell it commercially to their business customers, that’s great.

I’ve googled and not found anything from ROD saying they’ll open source their port. I’m not sure they should feel they have to – Google don’t open source Chrome. Apple don’t open source Safari. (Mozilla do open source Firefox). Iris is based on an open source browser, but that’s not saying they’ll open source everything.

Ive been laburing under a misunderstanding on this one. I cant find any mention of Iris being open source either. Maybe Ive heard it in one of the RiscOS user group meeting videos Ive watched. Im not going to wade through all those to see if its mentioned. Does anyone else have the same misunderstanding as me? Maybe @RiscOSDevs could confirm it?

I think you’re underestimating the effort of porting a browser engine.

Im not. Im in awe of Lees efforts to pull a browser together for a small hobbyist OS, and I hope he gets the financial rewards he deserves for it – Im hoping that’s where all those £50 have gone.

If they’re able to sell it commercially to their business customers, that’s great.

This has been confusing to me before. Im lead to beleive that RiscOSDevs and RComp are separate entitys but RComp distribute a version of Iris with their computers. I know he does funny things with hats in user group videos to make a silly point, but the waters are muddy, and I cant often work out which bits belong to which. Does ROD have customers or is that RComp?

Does anyone else have the same misunderstanding as me?

I would wonder if open sourcing it would get very far? A browser, especially if that level of complexity, is a massive undertaking and I wonder how many would have the technical skills necessary?

I think if somebody is interested in getting involved, may be better to get in touch directly and see where it goes from there. Open sourcing stuff, even under a nice permissive licence, is not a magical fix (for that you need AI).

I have liaised with Andrew (in ROD mode) previously regarding IRIS and there are 2 options:
1. Download it from !Store for nom 50UKP and use it on whichever RO5 configuration you use.
2. Download it as part of Direct v3 and use it there.

It has been a mammoth effort getting IRIS to its current state even though as punters it has been a very long wait.
Guess amongst others I just want my slice of (Xmas) cake to eat too.

But let’s be happy with what we have got – a decent working browser in RISC OS using a single core of a Pi4 !
Hopefully it will keep seeing development and updates as a decent browser is essential to keep an OS relevant these days.

Certainly don’t begrudge ROD or RComp for anything – they do a lot to keep the platform going including bringing IRIS to us.
With regards to the 50UKP payments – there can’t be that many active users of RISC OS these days and hence the potential earnings for working on IRIS would be pretty slim, it could only be described as a love job.

I also use and like Netsurf for what it is good at – a light weight and fast browser.
Thanks also to Michael for releasing OWB – Origyn Web Browser – another webkit based browser but sadly based on an older version and too much work for Michael to update it further. But it does work fairly well none the less.

I asked in another thread if anyone has had a look at Falcon – the updated Qupzilla browser – it works well on Haiku.
Wondering if in the realm of possibility to port this to RISC OS as well (noting Piers comments re compilers issues, Open GL etc).

with regards to a stand alone version of IRIS i have been advised previously to ‘…be patient’ :-)

Seven years. Patience of a saint.

I thought the point of RiscOSdevs was to benefit the users not one of the directors. It dosent matter how many times you do silly things with hats on videos, its not clear what is what.

But let’s be happy with what we have got – a decent working browser in RISC OS using a single core of a Pi4 !

It might even be easier to spin up an instance of Linux on the other 3 cores, run a native browser on that and overlay it’s output on the RISC OS screen.

It might even be easier to spin up an instance of Linux on the other 3 cores, run a native browser on that and overlay it’s output on the RISC OS screen.

And, whilst you’re there, farm-out the internet connection to that as well – as I’ve been suggesting for years, long before any native wi-fi solution.

Looking forward to it with eager anticipation, David!

I asked in another thread if anyone has had a look at Falcon – the updated Qupzilla browser – it works well on Haiku.

Haiku / BeOS was designed as a modern operating system from the off-set supporting, SMP, Multithreading, etc which makes it easier to port software too, I think one of the problems with the modern Falcon browser is that it uses the Quantum project derived Gecko engine which expects multithreading as standard, which is why some originally Gecko derived browsers have forked Gecko into Goanna which is still a single process engine.

I’ve never tried Falkon, but their website says it uses QtWebEngine, which is Chromium. I’m not sure I’d want to attempt to port Chromium to anything other than an OS that’s very close to Unix.

I think Gecko would still be doable – RISC OS can do single-core threads quite easily (Java did them), and I’d not be surprised if there’s a config option to disable them. However, Gecko requires rust and has a hard requirement on OpenGL (no sensible way to replace it with s/w rendering due its reliance on the GPU to clip), which would be more faff.

But I’d have chosen WebKit, as ROOL did.

However, Gecko requires rust and has a hard requirement on OpenGL

Goanna which is the gecko engine before ethernet quantum project rework doesn’t use any rust and isn’t a strict on the open GL requirements, that’s why it was forked by Palemoon.

I know about Goanna. It’s hard to know where they are with web compatibility as they don’t submit their test runs to wpt.fyi.

I’ve also found WebKit faster than Gecko, and I find it easier to understand its source code.

A note on Iris as Open Source:

To clarify, this is the official WebKit license:
https://webkit.org/licensing-webkit/

This means that if WebKit is “patched” and/or modified to work on RISC OS, the GPL applies retroactively, especially when distributing Iris as a binary. This is independent of ROD’s choices.

However, there are also precedents, such as Apple Safari, which is not open source. This is because Apple does not modify WebKit; they only call it for rendering. This approach is feasible because some portions of WebKit are BSD-licensed, making the “linking argument” less relevant in the context of WebKit.

That being said, I am not judging ROD’s decisions—I’m simply explaining why there is an assumption that Iris should be open-sourced. The reality is that “it depends” on how it uses WebKit and whether WebKit has been modified to run on RISC OS. As for open-sourcing it, I question what the actual benefit would be. No one seems willing to contribute to simpler projects (thanks, Piers, for pointing out the complexity involved here), so how would open-sourcing Iris help?

Aside from all this, I stopped believing in RISC OS as a platform for web browsing long ago. This started with the painfully slow Java port from Acorn (apologies, Piers—this is a critique of the code, not the people), which I still own and have in a running state. Over the years, we’ve seen various browsers, all of which lacked essential features, and the performance of modern browsers like Iris has been similarly disappointing. Time and time again, it has become clear that RISC OS is not a suitable platform for web browsing.

That said, Iris does solve many issues on RISC OS, which is both great and highly appreciated. However, as Paul mentioned, it still lacks basic features like copy and paste, behaves strangely on certain websites, gets flagged as a bot by some WAFs, causes problems with code built using older SharedLibs, and can still crash on certain hardware.

thanks Druck:

It might even be easier to spin up an instance of Linux on the other 3 cores, run a native browser on that and overlay it’s output on the RISC OS screen.

This, very much this. And it’s even possible to run Firefox from Linux natively in the RISC OS desktop via X11 Server, this can give latest and greatest version of something running on RISC OS desktop using unused cores and running Linux on them. Right now, with a working version of an X11 Server on RO, it’s possible to already do that using two separate PIs, but it would be ideal through an hypervisor to make it work on a single Pi.

With the Hypervisor use case it could be possible also to use webcams for meetings and such, without more work on RO.

behaves strangely on certain websites

I discovered this yesterday.

Go to Google. Search for “celebrations chocolate”. Switch to images. Note how long until the web process hangs. Alt-Break will kill it off, but the UI is then orphaned (not to mention DAs etc lingering).

No doubt some icky Google trickery, but still, the modern web is a bit of a hostile place.

[if you think that’s bad, Google script editor (scripts.google.com?) doesn’t even work properly on Android Chrome, so on Iris…? ;) ]

it still lacks basic features like copy and paste

Worth pointing out what passes for a “development team” around here. What is it, one guy and a Teasmade from the 80s?

but it would be ideal through an hypervisor to make it work on a single Pi.

Shared memory? Dump the image into RAM and have something on the RISC OS side pull it out and show it in a window? Sort of vaguely like how the x86 stuff worked on the RiscPC?

Worth pointing out what passes for a “development team” around here. What is it, one guy and a Teasmade from the 80s?

absolutely :)

Shared memory? Dump the image into RAM and have something on the RISC OS side pull it out and show it in a window? Sort of vaguely like how the x86 stuff worked on the RiscPC?

Virtual network drivers. We already have two X11 servers on RISC OS — one from Leo and one from Nauls. They just need to be cleaned up and built for recent RO 5 (and the latest hardware), I believe. Even Nauls, after porting Firefox, concluded that running Unix software on Linux and accessing it locally on RISC OS via X11 was a better choice.

X11 uses networking, and with a hypervisor, we can utilize highly optimized memory-mapped networking for optimal performance. This could even allow some back-end rendering to be handled on Linux using the Pi GPU acceleration without interfering with the RISC OS WIMP. For example, I recently tested this with my clustering protocol and successfully rendered using both OpenCL and CUDA on an NVIDIA 4090 for RISC OS. This is, of course, experimental because RISC OS still only supports 1Gbps networking. However, with higher bandwidth, the clustering protocol becomes a lot of fun to experiment with — especially now that it (experimentally) supports distributed execution for projects like my UltimaVM or QuantumPi, where multiple Pis can simulate a single, much more resourceful system.

I have no idea why the X11 server isn’t being used on RISC OS computers like Hydra and Chimera, to be honest. Perhaps it’s simply due to a lack of time or familiarity with X11? On those systems, it would not only enable Firefox but also OpenOffice, Thunderbird, and many other popular Linux apps to run inside a RISC OS window¹ as if they were native to RO. The appearance would be similar to some of the ported Linux desktop apps, but the system itself would be a lot more responsive, even if the apps might have a sligthely higher latency (depending on network bandwidth and CPU speed).

¹ This is not VNC! The application gets rendered on RISC OS, so there is no Linux desktop and the window fits the app basically, literally like the app would be executed locally on RO, if I am making sense (for who has no idea what X11 is).

Sort of vaguely like how the x86 stuff worked on the RiscPC?

I suppose someone could usefully study the source for that

This means that if WebKit is “patched” and/or modified to work on RISC OS, the GPL applies retroactively, especially when distributing Iris as a binary. This is independent of ROD’s choices.

You’ve misread it. WebKit is not GPL licensed. It is LGPL licensed. Therefore none of your comments about licensing apply.

(You certainly can’t get around the GPL by licensing parts as BSD, but that isn’t what they’ve done.)

This started with the painfully slow Java port from Acorn (apologies, Piers—this is a critique of the code, not the people), which I still own and have in a running state

It was slow, but the ARM was slow. Java was never designed for anything less than a full workstation – its APIs required far more than RISC OS had. It also heavily relied on double-precision floating point. A 233Mhz StrongARM could run WordPerfect at a reasonable speed, but Sun’s stupid decision to write Swing entirely in Java killed it on low-end devices. For 1.2, we had to (under the terms of the licence) only use their vector graphics code which used floating point (albeit it was anti-aliased, but clearly GDraw showed what was possible) to draw every icon. Their font manager, etc. We had to implement APIs that would never feasibly be used on RISC OS, such as JDBC – without them we couldn’t ship.

No other ARM port offered Swing (or even 1.2), and instead used simpler APIs – eg. Symbian, and Java briefly thrived on mobile phones with low-end ARMs without JITs. We had discussions with Symbian/ARM with a view to them using our port, but realistically we had no IP other than RISC OS’s AWT and JIT.

Once we added a JIT, the performance was quite usable, I thought.

Iris is fine for general browsing on RISC OS (I use DuckDuckGo to avoid the ‘Google hang’). Most of the time its rendering is acceptably brisk. I will not use it for online ordering or banking: in the former case, too many times I have got through several screens of data input only to have a fatal freeze at the crucial moment; in the latter case, I get a ‘your browser is out of date’ message (true) and an invitation to upgrade it (would be nice). My solution is Firefox in a desktop window via !Avalanche served by a Wintel laptop.
On the general point of where does RISC OS go from here, I don’t think native multi-core support AND 64-bitting is feasible, even if one of them is, which it may not be. So I think we have to choose where to concentrate resources, and also avoid stupidities like two competitive wifi-enabled internet stacks appearing at the same time. An alternative option would be emulation on Linux; I’m seriously impressed by the latest iteration of RPCEmu, which outperforms a Pi3B on the aforesaid (relatively average, but up-to-date) laptop, the only real downside being lack of RAM compared to native hardware. It even supports scrolling, and is very stable – more so than my Pi4B. From my point of view, the appeal of RISC OS is entirely in the user interface, which remains more intuitive and user-friendly than any counterpart. Much as I’d like to see 64-bit or multi-core native hardware, we’ll be lucky if even one materialises in a reasonable timeframe. The RISC OS GUI sitting on top of an already-capable OS might be a quicker way to go.

It’s probably worth pointing out that almost no commercial WebKit/Blink (which inherited WebKit’s licence) browser are fully open source. A handful of hobbyist browsers are open source, but no one actually uses them :-)

Safari, Chrome, Edge, Opera, Vivaldi, Brave, Samsung… I can’t name any, in fact. I suppose Symbian’s probably was by the time it was closed down.

So I don’t think ROD’s current decision is in any way unreasonable – it’s the same as everyone else.

I just found one! DuckDuckGo’s is.

You’ve misread it. WebKit is not GPL licensed. It is LGPL licensed. Therefore, none of your comments about licensing apply.

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.

Again, if ROD modified WebKit, they are required to release the modified WebKit under the LGPL and, therefore, as Open Source—this is regardless of their own personal choices/preferences. They do not need to release the part that uses WebKit, though.

Generally, to ensure no ambiguity, WebKit is used unmodified and linked dynamically, because that is safe in terms of licensing. Modifying it is a different story.

Quoting a reference (taken from Wikipedia) that should be in better English than mine:
“Any developer who modifies an LGPL-covered component is required to make their modified version available under the same LGPL license. For proprietary software, code under the LGPL is usually used in the form of a shared library, so that there is a clear separation between the proprietary and LGPL components.”

Once we added a JIT, the performance was quite usable, I thought.

Again, mine wasn’t a complaint about your work; it was a remark that RO wasn’t and still isn’t the platform for such types of applications.

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, was still extremely slow (I need to double-check if it has JIT enabled thought), and sucked all CPU cycles even when not interacting¹. It was clearly a demo of what could possibly come next but never fully materialized into something more than a demo, IMHO.

Again, this is not a criticism of the engineers who did the work. RO is an OS that started to show a lack of interest from Acorn themselves since RO 3.50, IMHO, with 3.60 being a slight bump in interest but nothing more, and 3.7x clearly just fixing things for the StrongARM mostly. Contrary to the amount of work it required back then (including migrating to 32-bit, robustness, etc.—we’ve discussed this stuff a billion times, so I’m not going to repeat this entire discussion). The amount of work you had to do in such a situation is certainly ginormous. I recently designed a bytecode interpreter for RO from the ground up, and even on modern hardware, it’s still a pain to strike a balance between performance and control—let alone in your situation, where you also had to satisfy Sun’s requirements, etc. 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. Just my opinion, and I am waiting to be proven wrong.

¹ This exact problem still happens to this day on RO 5 when using Jainja. That is because the execution engine is not designed to play nice with the WIMP.

[edit]

So I don’t think ROD’s current decision is in any way unreasonable – it’s the same as everyone else.

I think we all agree on this, besides, I don’t see the point of open sourcing something for the sake of it. No one here has the time to look into that amount of work and give them some help, so most likely would only add more work on ROD’s hands and for no gain at all

[/edit]