RISC OS Southwest Show 2024 - Sat February 24th

it’s time the RISC OS community embraced the nature of open source operating systems a little more and accepted that there will be multiple solutions for the same problem -and this can be a good thing.

It’s good if a common standard is being followed. To the average user this doesn’t matter, but a lot of us here are developers and some have to interact with these things at low-level.

IDEFS is a good example of how not to implement a common standard, I must have spent around 18 months implementing support for it in Partition Manager – not helped by the complete lack of documentation beyond what Acorn provided. Every implementation works in a different way, with different SWIs and different partitioning standards.

there will be multiple solutions for the same problem -and this can be a good thing.

So, two sets of developers worked simultaneously on the same problem and came up with a similar solution: and this is not a wasteful use of scarce resources, when there is SO much else to do? I know commercial competition is supposed to drive progress, but this does seem batty.

Apologies, George,

The narrative of “wasteful use of scarce resources, when there is so much else to do?” is a territory I would not recommend venturing into. Let me explain:

A) If someone wants me to work on what THEY want, then they should be prepared to pay my full salary. Believe me when I say that experienced developers are extremely costly.

B) When working for free, people are entitled to work on what they like, enjoy and/or find themselves confortable doing, or what’s important to them, not the rest of the comunity.

C) The reason there is so much to do is that all the previous “owners” of RISC OS have failed to fully commit to it, opting instead for marginal bug fixing, minor refactoring, and the occasional addition of a driver or small app here and there. They lacked the courage (and I am being kind and polite by saying “lacked the courage”) to completely rewrite the entire architecture to facilitate easier modernizations. Acorn is notably guilty of this.

So, to me, if ROD, ROOL, or anyone else wants to work on their own implementation of NVMe drivers¹, WiFi stacks, network stacks, etc., that’s perfectly fine. Bounties are an exception to this, given they have well defined goals.

What is truly needed is for ROOL to step up and demonstrate competence by defining clear and well-constructed API standards. This would allow everyone to implement (or more accurately, port) their preferred stack without negatively impacting application developers and the rest of the community.

This is one of the major roles for ROOL, although they have been guilty of altering some of the pre-existing API formats in the past. I guess they were learning at the time (since I can’t find any other explanation for those few inconsistencies).

¹ I doubt those NVMe drivers are going to be this different from one another, and certainly the Open Sourced ones can be made to work using the same API. If there are going to be any closed source ones, my recomendation is just ignore them, don’t use them. That is your power to ensure all the parties behave correctly and/or make it possible for mistakes to be fixed.

Every implementation works in a different way, with different SWIs and different partitioning standards.

To be fair, partitions weren’t really “a thing” that Acorn did back in the day, so I’d imagine the vendors went with what worked for them (for example, Simtec has lots of options like password protection and such).
Doesn’t mean it’s not a pain in the arse, but then so’s an operating system with large chunks written in assembler. ;)

These days… I fully agree. The prime reason that I’m using the ROD stack isn’t because “oh shiny!”, it’s because with the exception of the IPv6 stuff it’s pretty much a drop-in replacement for the old Acorn stack. Nothing needed to be rewritten or changed, all the stuff (WebJames, the browsers, etc) “just work”.

These days, that’s how it ought to be.

but this does seem batty.

Yeah, I’m not even.
Especially given as RISC OS is supplied as a ROM image, so while it’s possible to have multiple incarnations of just about anything, only one is going to be “official” and therefore built into the OS.

by defining clear and well-constructed API standards. This would allow everyone to implement (or more accurately, port) their preferred stack without negatively impacting application developers and the rest of the community.

Is there really a need for this? If something behaves differently, then whether or not it’ll be adopted will be down to how many people can be bothered to deal with these differences.
Take ROD again. With their Internet stack, they bent over backwards to get it as hassle-free an update as possible. It even comes with a little installer so nobody needs to fiddle with the chaos inside !Boot. I’m aware of a little change in the resolver response, but I don’t remember the details (is it an IPv6 thing?) as it doesn’t seem to have affected anything here.

Plus, as you stated, one can simply make the choice to shun core OS components that aren’t open sourced. We’ve had to deal with the nonsense that was the closed source Resolver for far too long.
Perhaps if it was open sourced back in whenever, it could have been expanded to handle dealing with .local addresses (mDNS and all that)?

What is truly needed is for ROOL to step up and demonstrate competence

Let’s start with somebody bashing into them the idea that different binaries need to have different version numbers. No if/but/other-pathetic-excuse.

My little app for the TV listings was failing yesterday. The fetcher code (uses URL/AcornSSL) would happily fetch anything from my site, but when pulling data from the Freesat site, it would get the headers and then stall until the programmed time-out kicked in.

I was using “AcornSSL 1.06 (03 Jun 2020) mbedTLS 2.16.8”.

What fixed it? Upgrading that rather old version to one culled from a Harddisc4 download fixed it.
“AcornSSL 1.06 (27 May 2023) mbedTLS 2.28.5”.

My program does an RMEnsure to check that the relevant modules are loaded before we begin, but there’s a note in the comments that it’s an utterly pointless check for AcornSSL, of which there are outdated and thus non-functional versions around with the same ****ing version number.

Really… <shakes head in utter dismay>

AcornSSL, of which there are outdated and thus non-functional versions around

Looks like we’re spanning around three years and possibly 10 or 11 different builds.

Interestingly it looks like there was a “Switch to the new code style” on the 24th of May 2023 and the mbedTLS built into AcornSSL has seemingly frozen at 2.28.5; the most recent mbedTLS is 2.32 from two weeks ago; but the AcornSSL in the current beta Harddisc4 ¹ is the 27th May 2023 release despite the harddisc4 being dated yesterday…?

Has something come unstuck?

¹ archive → !Boot.Resources.!System.350.Modules.Network.URL.AcornSSL

@ Rick

Is there really a need for this? …

Yes, let me quote a comment from a friend of mine that clearly shows why this is needed:

“The prime reason that I’m using the ROD stack isn’t because “oh shiny!”, it’s because with the exception of the IPv6 stuff it’s pretty much a drop-in replacement for the old Acorn stack. Nothing needed to be rewritten or changed, all the stuff (WebJames, the browsers, etc) “just work”. – Rick Murry

;)

Let’s start with somebody bashing into them the idea that different binaries need to have different version numbers

+1

I think experience teaches us all that every change to a piece of code (included a change in their dependecies), should ALWAYS trigger a version number change. This to at the very least being able to understand what could have been hapening in case of problems.

I was using “AcornSSL 1.06 (03 Jun 2020) mbedTLS 2.16.8”.

What fixed it? Upgrading that rather old version to one culled from a Harddisc4 download fixed it.
“AcornSSL 1.06 (27 May 2023) mbedTLS 2.28.5”.

Indeed, a mistake. The date has always been seen by some in the RO community as “part of the version”, but it isn’t (unless we change the way RMEnsure checks the version of a module). The way a date should be generaly used is to identify a specific build ID, nothing more. But it is a confusing element of RISC OS modules TBH.

Really… <shakes head in utter dismay>

Hmm…

AcornSSL’s date/version has been a total mess for years. There are 25 different (at the binary level) modules numbered 1.06. 18 of them are dated 03 Jun 2020 and 5 claim they are from 27 May 2023. Some of them also have the same mbedTLS version. The last two have 2.28.7, by the way, not 2.28.5.

Yes, let me quote a comment from a friend of mine that clearly shows why this is needed

Ah, but the correlation is that if it doesn’t work, if it’s a pain, then it’ll just get abandoned, which means nobody needs to “oversee”, it’ll sort itself out.

I think experience teaches us all that every change to a piece of code (included a change in their dependecies), should ALWAYS trigger a version number change.

Very much so. And the highlighted part is what I think is going wrong here. AcornSSL is pulling in mbedTLS but since that’s a different thing “somewhere else” the version number isn’t getting the bump it ought to be getting.

The date has always been seen by some in the RO community as “part of the version”

Unofficially, yes. This works in the case of the RISC OS odd/even builds (how many releases of 5.29 have there been?) because it’s a known special case. It makes sense when applied to test versions of the OS as a whole. It doesn’t make sense applied to individual components.

It should never be the “official” way of telling one version of a module from another. The OS provides a facility for that, and it does not pay any attention to the date, it expects the version number to be used sanely.

Of course, the fact that this is a security component that’s a bit of a moving goalpost and the version number mess means it isn’t possible to programmatically tell them apart (without doing icky things like interrogating the module binary ourselves, which is the OS’s job dammit) is an irony that is not lost on me.

Hmm…

Oh, yes. Because letting somebody that has no idea about the build system or Git loose on both is absolutely the right way to fix this issue…

AcornSSL’s date/version has been a total mess for years.

It’s not just AcornSSL. We had that spot of sadness when what I presume was some sort of compiler test was spitting out broken LZW code which broke AcornHTTP which caused stuff to crash. Of course the ones before, during, and after had the same version (1.04). I identified one broken version as being 64,416 bytes long…but that’s just the one I’d seen. There may have been others.

18 of them are dated 03 Jun 2020

What the hell? Eighteen?!?

The last two have 2.28.7, by the way, not 2.28.5.

Sorry, my bad, I was inadvertently looking at the binary of the module on the other Pi (via ShareFS) than the one on this Pi culled from the most recent Harddisc4. It doesn’t help at all that not only was the version the same, so was the date. <facepalm>

Still hasn’t been updated since then, we’re now up to mbedTLS 2.32 but not in AcornSSL.

Ah, but the correlation is that if it doesn’t work, if it’s a pain, then it’ll just get abandoned, which means nobody needs to “oversee”, it’ll sort itself out.

Yes, but what about NEW features? Think of the API needed to connect to a WiFi network. If everyone start implementing their own SWI set, that’s going to be fun! XD

Unofficially, yes. This works in the case of the RISC OS odd/even builds (how many releases of 5.29 have there been?) because it’s a known special case. It makes sense when applied to test versions of the OS as a whole. It doesn’t make sense applied to individual components.

Indeed. Well, let’s hope that the guys at ROOL are listening.

Yes, but what about NEW features? Think of the API needed to connect to a WiFi network. If everyone start implementing their own SWI set, that’s going to be fun! XD

Not only that but the SWIs cover only a small part of the network stuff, most of the code is in inetlib. I presume most, like me, merely used a few of the provided functions but that was enough to notice that outside of the stuff supported by the old stack they are diverging wildly: even the constant AF_INET6 has not the same number in the ROD and ROOL implementations. Even for simple stuff like a shoutcast/icecast client it was a real pain to work around the issues and as it stands it will make it very difficult to port network oriented applications.

Regarding the NVMe drivers, except for formatting/partitioning, only the system interacts with them through well defined interfaces so I don’t foresee a problem in having 2 implementations. Of course if they had discussed it beforehand in the open one team could have been tasked with other stuff. For those with experience in Filing System matters there are other interesting stuff that could be done like for example:
- support for 64-bit file sizes
- real support for DiscOp64 (I remember Jon complaining that the SWI just redirected to the old DiscOp in SCSIFS)
- central registration of devices so that stuff like HForm, DiscKnight, PartitionManager, CDFS can easily list drives

For those people unable to attend the show (and/or those who were there, but couldn’t sit in on the various talks), the recordings from the show theatre are now on YouTube.

In the order they were recorded, they are:

• Chris Hall
• Andrew Rawnsley / RISC OS Developments
• Andrew Rawnsley / R-Comp
• Steve Revill / RISC OS Open
• Chis Dewhurst / Drag ’n Drop

Or, if you want to watch them all in one sitting, there’s also a 2024 Southwest Show playlist

Many thanks for this, Vince :)

Also useful for standholders who couldn’t leave their stands to listen!

Thanks for the recordings, Vince. Without it I wouldn’t be aware of RComp’s new open source Block architecture. That’s exactly the kind of developments I wished to see for filing systems.

Thank you for uploading the events to YT. I always look forward to these.
Rather hard to physically make these events when living outside the UK.

Also useful for standholders who couldn’t leave their stands to listen!

Indeed! It was a busy day, so not a chance to attend any talk.

Also thanks for releasing the Block architecture pen Source! Very much appreciated.

Also useful for standholders who couldn’t leave their stands to listen

I’m reasonably sure standholders would be people “who were there, but couldn’t sit in on the various talks”! ;)

Anyway, I’ve just updated the playlist link, because I very usefully copied and pasted the one for 2023 originally. Still, not as bad as last year when I actually edited and uploaded the videos for the previous show in a rush to get them up before Wakefield. Ho hum.