WiFi: ROOL or ROD?

RISC OS Developments have announced the computers that their first WiFi work will target: Pinebook Pro, Raspberry Pi 4 and hopefully, later, Pinebook (the original one). So, which computers will ROOL be targetting initially, presumably the Raspberry Pi 4 and the Titanium?
What are the pros and cons of each version for the Raspberry Pi 4 or other computers?

Will it be possible to have both versions on a computer and swap between the two when desired? A sort of ‘ROOL with a ROD’ of iron hardware.
Many users will want to know which way to go.

Personally I am sticking with the ROD version, which has been working without the Wi-Fi part for sometime now, and is open source with replacements for the old closed source parts of the Internet stack. It also has IPv6 available, and when hopefully shortly the Wi-Fi addition is made available generally, it will be superb.

Yes the ROOL one is being developed very slowly as far as I can see, but seems to be duplicate effort for no real benefit to our small market, if they had worked together we could have had the best of both worlds. ROOL seem to prefer everything to be based on FreeBSD while ROD who had a commercial customer who paid for the bulk of the development work, went with OpenBSD.

So, which computers will ROOL be targetting initially

This is why duplication of effort around what is essentially the same thing seems less than useful.

So, which computers will ROOL be targetting initially, presumably the Raspberry Pi 4 and the Titanium?

I really really hope that it is engineered in such a way that the low level hardware pokery is separate from the WiFi driver, so that with a bit of luck (and that elusive thing known as communication), ROOL can work on the devices that ROD aren’t doing, and the end result will be low level drivers that everybody can use.

Will it be possible to have both versions on a computer and swap between the two when desired?

Yes and no.

At the moment, with regards the IPv6 stack, the ROD one can be dropped on top of whatever ROOL provides and it’ll run instead. It isn’t quite as simple as a swap-when-desired, it needs to be installed/uninstalled (with reboot), but it is pretty hassle-free. They went to lengths to make it a simple drop-in replacement. I installed it way back when, and haven’t used the ROOL stack built into RISC OS in quite a few months now, simply because the ROD one is simple to get going and unobtrusive. “It just works”.

I would hope the WiFi would be an extension of this, just as I hope the WiFi would be a sort of plug-in to the stack that provides an internet connectivity end point (like SLIP/PPP used to way back when) so they can largely be stack agnostic, but we’ll have to see if it works out that way.

Many users will want to know which way to go.

“The one that works for you with your hardware” is the best answer here.

It’s early days, but things are finally happening with regards WiFi. Let’s see how it comes together.

I installed it way back when, and haven’t used the ROOL stack built into RISC OS in quite a few months now, simply because the ROD one is simple to get going and unobtrusive. “It just works”.

I echo this.

As for targetting various computers: presumably each HAL will need to provide some support for the WiFi hardware, even though the chips will differ.

The ROD version […] is open source with replacements for the old closed source parts of the Internet stack

Yes… It’s apparently CDDL 1.0, and the source code is “available on request”. Presumably I’d have to justify why I want to see a copy if I contact them for one¹, else it would just be a download on the website?

The really baffling thing is that since the first release in April 2022, the website has said that “we are presently preparing the source for a github/gitlab release, but this is still ‘in progress’”… Sorry? What?

Even if we allow that the code wasn’t under Git source control to start with², then how hard is it to copy the files over to a Windows, Mac or Linux box, and type

git init
git add .
git commit
git remote add origin <remote repository at GitWhatever>
git push -u origin --all

plus an optional

git push origin --tags

Two years is what it takes to ready some legacy code which was never Open when it was written, has legal quibbles and is full of fruity comments. If you’ve started from scratch with the intention of it being Open, then all of your files had the correct licence headers from the point that they were created, the comments are written clean and SFW, and there’s nothing in there that shouldn’t be.

if they had worked together we could have had the best of both worlds

I’d be very interested to know on which side the fault lies, however. Being professionals, ROOL don’t tend to air their dirty laundry with other parties in public. So we only really know the perception of one side of this particular story.

And it can’t be that easy to work together with a party who give every impression that they haven’t yet discovered the benefits of source control for collaborative projects. Such projects require a very specific mindset when when you do use source control properly; without it, I can’t imagine it being much fun for the collaborating party…

¹ I do like to grab source code for stuff, when it’s available.

² And that’s a big thing to believe, given that it’s a new stack written collaboratively by two(?) developers and with commercial sponsors. Under those circumstances, I’d expect it to be under source control – and I’m sure that the commercial people putting their cash into it would too. And, in the 2020s, with the intention of Open Sourcing it and no history to make another VCS look appealing, you would use Git because that’s what the world is geared up to use.

So, which computers will ROOL be targetting initially, presumably the Raspberry Pi 4 and the Titanium?

It would be a stunning feat of engineering on ROOL’s part to support the Titanium, a skim of the schematic shows no radio chip, so it’d all need to be emulated in software!

More seriously, the bounty description has listed the aims of the bounty since it was published in June 2019. No special treatment of Titanium there either.

Presumably I’d have to justify why I want to see a copy if I contact them for one

Rather than casting aspersions, why don’t you just ask?

else it would just be a download on the website?

Probably when that was written it was changing more frequently than now so keeping the site up to date would be a hassle. That being said, in the absence of Git, popping a copy on the site would seem to be a logical enough move.

how hard is it to copy the files over to a Windows, Mac or Linux box, and type

Great. You know Git. I don’t. I’m guessing over at ROD they don’t either. There’s actually rather more to it than your example indicates. For instance, how about syncing changes to an existing Git and/or rolling back an update? Usual management stuff.

Two years is what it takes

Two years is what it takes when you’re more interested in making the code work, alongside doing something else as a job, and having “drop it on a website” as a lower priority.

And it can’t be that easy to work together with a party who give every impression that they haven’t yet discovered the benefits of source control for collaborative projects.

Neither can it be easy to work together with a party who seems blithely unconcerned about the entire point of module version numbers.

and I’m sure that the commercial people putting their cash into it would too.

Depends how well they know RISC OS. ;)

I do like to grab source code for stuff, when it’s available.

Ask…

Great. You know Git. I don’t. I’m guessing over at ROD they don’t either. There’s actually rather more to it than your example indicates. For instance, how about syncing changes to an existing Git and/or rolling back an update? Usual management stuff.

I imagine that you’re familiar with this comic :)

My workplace uses Subversion. At one point we were looking into Git, but when we had an actual Git contributor (i.e. someone who has worked on the Git software itself) tell us we were better off sticking with what we had, we listened. Git is well-suited for something big and complex like the Linux kernel (I believe that’s what it was designed for), but for smaller projects it appears to often be overkill, and I think there’s a fair amount of peer pressure around it.

Anyway, veering towards Aldershot here so I’ll shut up.

The really baffling thing is that since the first release in April 2022, the website has said that “we are presently preparing the source for a github/gitlab release, but this is still ‘in progress’”… Sorry? What?

I can make a guess (no inside information – see below). There are at least two goals of the present work: IPv6 and WiFi. There may be more. My guess is that the pressure to keep going on the later goal(s) made them want to keep going instead of stopping for a period to tidy it up and do a release; these things never take zero time.

the source code is “available on request”. Presumably I’d have to justify why I want to see a copy if I contact them for one

I’ve received the source code in the past, so they’re not kidding. This was to try to find and fix a bug that affected the SMC78xx Ethernet chip – now fixed, thank goodness, which is why I posted above that it’s been the normal stack that I use for some time now. I should add that I didn’t even have to ask – it was offered to me.

I don’t have a special relationship with ROD, and I have no secret information. I’m merely pointing out that they are, in practice, more open than some people appear to be implying.

Like Steve, I don’t understand the reluctance to using source control. In fact, I cannot even begin to imagine how more than one person could work on something without it.

Having a zip file of the source code just isn’t the same. The change history provides useful context. Branches provide places to develop features or make emergency patches. Even for a single-developer project, it’s a no-brainer. And I say that as a total hypocrite: I’m well aware I need to try out the ROOL Git client with USBJoystick.

I’m not picking on ROD here. It seems to be an issue in much of the RISC OS market, except of course, for RISC OS itself. :). Please, please, please, if you are making something, then why not publish the source on GitHub/GitLab/whatever. As annoying as GitHub might be, you get a mini home page, issues forum, roadmap, downloads, oh, and source control! Much nicer than a ‘personal home page’, eh?

then why not publish the source on GitHub/GitLab/whatever

Then let’s have a RISC OS Git client that’s freely available to everybody and that does all the ordinary things that developers need to do.

Otherwise it means doing source control with a foreign system that doesn’t understand RISC OS, how it handles file types, and where it puts files (main.c or c.main).

I’ve received the source code in the past, so they’re not kidding.

Ditto. Wasn’t even trying to fix anything, I just asked and got a copy.

There’s no conspiracy here, just – most likely – the usual case of few developers and even less time.

that doesn’t understand RISC OS, how it handles file types

That’s the main issue I have when downloading premade archives from any sort of Git. Have to go through and put all the filetypes back in order.
Plus, it appears that once you leave the domain of Git itself, all version history vanishes. There’s no associated metadata in the archive, it’s either on the live Git system or nonexistent.
[there is, no doubt, some arcane incantation to extract it, but that would likely need one to be running a Git client…]

Yes, source control is a good idea. But we’re not quite at the stage of easy integration into the OS, so the idea of taking a project and pushing it over to an alien system that doesn’t understand RISC OS (Windows) in order to push it over to another alien system that doesn’t understand RISC OS (Git), you can see why it’s probably not a priority when one can simply drop stuff into a zip file and email it and it’ll open just fine.
Sure, it absolutely doesn’t scale, but if there are only two or three people involved and each of them is careful to say what they changed (or have the habit of using Diff) then it’ll work. It’s how things used to be done (when they weren’t just sitting there on a networked floppy).

I don’t understand the reluctance to using source control.

Probably the absence of an easy to install and use client for the current flavour-of-the-era source control options.
People have, generally, not used SC before, so unless it’s an easy change of habit it just won’t happen.

Speaking as someone who has spent decades “encouraging” people to do “the right thing”¹ the best technique is to make it easy for people to do what you want them to do.
RISC OS development channels simply haven’t done that.
If seasoned veterans of a source control tool are sitting on the outside with no easy way in, what hope for the novice with a small idea?

¹ some call it railroading in my chosen direction, although since those were political and business opposites they don’t count :)

Then let’s have a RISC OS Git client that’s freely available to everybody and that does all the ordinary things that developers need to do.

Hmm. What about this, then? I did have other plans for this evening, but I’ve been meaning to take a look since Sprow mentioned it when I was talking to him at the ROOL stand in Bristol. Tonight might as well be the night…

Seems to work… Let’s have a go…

So I had to set up a public/private key to access my GitHub account, but that wasn’t hard. In fact, it was easier than I’d expected it would be – taking about 5 minutes, including remembering how ssh-keygen works (and even that wouldn’t have mattered if I was willing to share keys between machines, which I’m not).

That’s the main issue I have when downloading premade archives from any sort of Git. Have to go through and put all the filetypes back in order.

Let’s have a look, shall we?

It seems to have retained all of the RISC OS types in the application shell! Those were committed from Linux, but I assume that our client is sensible enough to add the standard type suffixes on commit from the RISC OS world.

If you prefer a GUI to the command line, we’ve got one of them, too…

Plus, it appears that once you leave the domain of Git itself, all version history vanishes. There’s no associated metadata in the archive, it’s either on the live Git system or nonexistent.

That’s kind of the point of VCS, though. This stuff is hard to track in a filing system, so you don’t do that. You let the VCS do it for you.

“Domain of Git” sounds muddled, though. Git just shuffles files around in one of the folders on your disc: the working folder. You ask for a version of the files, the folder is updated. There’s no “domain”.

And the RISC OS client is actually quite neat here, as there’s even an ImageFS if you really want…

I don’t honestly see my using this much, however, as I use a VCS to avoid this kind of “version folder hell” nonsense.

tidy it up and do a release

What tidying up is there to do if they’ve been writing it with release in mind from the start? It’s always been Open Source, so release has always been on the cards at some point.

And if they’re happy to send a copy to anyone, then even if Git is a step too far, what difference does it make if that Zip file is put on the website for public download? If it’s there to download, they’re not spending time servicing requests for copies of the source code, either!

The foreign system doesn’t need to understand RISC OS. Copy or keep your source on a network drive and the RISC OS network filing system (LanManFS, Sunfish, etc) will handle all the file types.

git also doesn’t care whether it’s main.c or c.main, it’s only an issue if the sources are multi-platform, and then you would have scripts to translate the source layout in both directions anyway.

I’ve been doing this with various source control programs since long before git came out.

As for targetting various computers: presumably each HAL will need to provide some support for the WiFi hardware, even though the chips will differ.

As I understand it, the on-board radios use standard interfaces like SDIO, so most of the HAL-specific stuff would have been done as part of the SD rework in 2022. The actual chipset drivers would then be separate components similar to the Ethernet drivers.

It would be a stunning feat of engineering on ROOL’s part to support the Titanium, a skim of the schematic shows no radio chip, so it’d all need to be emulated in software!

There appears to be a variety of Wi-Fi PCI/PCIe cards and USB adapters out there, so I wouldn’t completely rule out the possibility of supporting the Titanium (or other machines without on-board radios).

git also doesn’t care whether it’s main.c or c.main, it’s only an issue if the sources are multi-platform, and then you would have scripts to translate the source layout in both directions anyway.

One nice feature of SimpleGit is that it’s able to do this translation automatically when cloning the repository. It didn’t do a perfect job, but it’s still something I miss with the new client.

One nice feature of SimpleGit is that it’s able to do this translation automatically when cloning the repository. It didn’t do a perfect job, but it’s still something I miss with the new client.

Oh. Well, saves me the bother of trying the new git client out…