WiFi Wanderings at ROUGOL, Mon 17th June 2024

Really? In the ROM image and HardDisc4?

I took “RISC OS Pi” to mean the SD card image, which does indeed include it. The standalone ROM/HD4 do not.

Or ROOL could stop wasting their time, and other people’s money, and just use the ROD stack instead.

Personally, I totally agree. The market is far too small for this type of duplication. But ROOL seem to prefer anything added to the RO sources like this must be based on NetBSD, but the ROD stack is based on OpenBSD. RISC OS is supposed to be “Open Source”, but is it really?

ROOL claim because someone claimed the bounty they must do it well no, they could propose they work with the programmer at ROD, and jointly work on the project to get it fully developed quicker, and even maybe expand it to include BlueTooth, a much better use of the combined limited resources we have left in the RISC OS world, I think.

must be based on NetBSD

I think the fact that the ROD stack simply loads, and works, with existing software is more than enough to demonstrate that the actual code origin is less important than “does it work” and “is the licence compatible”.

a much better use of the combined limited resources

It’s what some of us have been saying for quite a while now. Two competing solutions instead of one more complete solution just doesn’t make sense.

I’m starting to wonder if it’s a case of NIHS.

RISC OS is supposed to be “Open Source”, but is it really?

Yes. Open Source doesn’t mean that you get to dictate what goes into a project. It means that if you don’t agree with a project’s direction, you can fork it and develop your own project which contains whatever features you want.

they could propose they work with the programmer at ROD, and jointly work on the project to get it fully developed quicker

They could, but given that the bounties are well below what a developer could earn on contacting rates, it’s very much “pocket money in exchange for fun” and if the claimant doesn’t consider working with ROD to be “fun”, that’s unlikely to fly.

Given ROOL’s professional silence on a lot of the details where third parties are involved, I strongly suspect that there’s a lot that we don’t know about the background to this situation and how we ended up where we are now.

Yes. Open Source doesn’t mean that you get to dictate what goes into a project.

So you are saying the actual owners of RISC OS have no say (ROD) in what goes in to the RISC OS source only ROOL can!! That is not Open source, i.e. it is not open. Opensource.com say, Open source software is software with source code that anyone can inspect, modify and enhance.

They could, but given that the bounties are well below what a developer could earn on contacting rates, it’s very much “pocket money in exchange for fun” and if the claimant doesn’t consider working with ROD to be “fun”, that’s unlikely to fly.

Do you know if they discussed the option even, or considered as the ROD stack was at least in part paid for by a commercial customer, they might have been able to offer more money.

Given ROOL’s professional silence on a lot of the details where third parties are involved, I strongly suspect that there’s a lot that we don’t know about the background to this situation and how we ended up where we are now.

While I take your point, I think ROOL and to some extent ROD need to sort out what the ground rules ROOL has to work too to allow people to enhance RISC OS and much better communication between the various parties, so we do not get anymore duplicate like this happening again. Like the 2 versions of NVMe drivers we also now have! Again the right hand not talking to the left hand.

I know I will not be popular with some people for saying these things.

So you are saying the actual owners of RISC OS have no say (ROD) in what goes in to the RISC OS source only ROOL can!! That is not Open source, i.e. it is not open.

That’s a separate question to Open Source.

The short answer is “No, they don’t”, for the reason below. In reality, there may be a separate agreement in place, but that’s nothing to do with the Open Source-ness of the code.

The whole point of Open Source is that once you’ve released code under such a licence, the only control that you have over it is what you can achieve with the licence (such as copy-left). Whilst remembering that the licence needs to meet the requirements of Open Source, which limits the control that you can apply.

And that’s before we even try to work out what “owning RISC OS” actually means, several years after the purchase…

Opensource.com say, Open source software is software with source code that anyone can inspect, modify and enhance.

That’s correct. If you wanted to modify CashBook tomorrow, in a way that I didn’t agree with, you would be completely within your rights to fork the code and release your own competing version. But you couldn’t force me to include those changes in my source tree against my wishes.

And after that, you get to become custodian of your version. I can do nothing to control what you do with it (aside from preventing you from suggesting or implying that I endorse it). And, of course, someone else could take your version, fork it, and do stuff that you don’t like with it…

you would be completely within your rights to fork the code and release your own competing version

And that’s why the Linux distribution graph looks worse than the All Branches of a shared git repo.

wow this thread took off…

firstly thanks to Bryan, Paolo and other up laters for hanging around long enough for me to join the meeting after attending to other things….it’s kind of nice to be able to go to a RO User Group meeting again (did 1 other previously where Andrew R was speaking), the last RO User Groups that held physical meetings disappeared down here some 20 years ago as far as I know.

thanks for initial suggestions Andrew and others… have not been able to respond or play around with the setup recently… real work dragged me away.
Quick responses…
Overclock – only overclocked to 1800Mhz and with active cooling
Geminus – no not using this although it does sound good for use on the Pi, especially if it eventually enables dual monitors
Alignment Exceptions – IRIS turns these off automatically (if selected)

Think I may have been loading both ROOL drivers and the ROD stack and this may be why was experiencing drop outs and lock ups.
The system running just ROOL WiFi and netsurf did lock up at about the 80 hour point and had to be power cycled.
Next step will be a fresh install using only the ROD stack and see how that goes – maybe ROD’s updated beta WiFi will come out too and will try this.
Assuming get a stable install will then revisit VNC server again both wired and wireless.
Think the VNC access issue may have been the result of the ROOL stack dropping and re-starting WiFi.

Re James’s mention of Linux above… in the Linux news on phoronix today:
Longtime Linux Wireless Developer Larry Finger Passes Away
https://www.phoronix.com/news/Larry-Finger-Linux-Wireless

and from the comments…
“One could go all the way back to the abacus or the harnessing of electricity. But I think it’s safe to say that modern day computing really only became ubiquitous and truly personal with the advent of wireless. Wireless finally allowed the invention of things like laptops to truly be what they were envisioned by thought leaders as far back as the 70s when miniaturization of components was still sci-fi. And WiFi has been a particular thorn in the side of Linux development over the years. Thanks to Larry and many others for tackling this issue vis a vis Linux and helping to make Linux more viable and useful for us all.”

Swap out Linux for RISC OS…
So thanks to both ROOL and ROD for bringing WiFi (amongst other things) to the platform

Fun Fact:
The WiFi we know today was initially developed by the CSIRO (Commonwealth Scientific and Industrial Research Organisation) of Australia.
CSIRO invented a chip that greatly improved the signal quality of Wi-Fi.
Fun Fact 2:
Acorn BBC DFS was initially developed in Australia by Barson Computers (to help it win a government supply contract).

mmm… now i’m digressing.. is it time to move this thread?

I think Steve has covered the ‘open source’ point pretty well. And as he also said, there is probably more to this than is so far public. Clearly, not everyone wants to air their dirty laundry in public!

A key ROOL commitment seems to be in the open source and collaboration (see GitLab). There may be a little murkiness in bounties until bits hit GitLab, but perhaps that is to be expected when you offer (even small) financial rewards and are also relying on spare time. The ROOL team have been doing this a while, and worked with the codebase enough to have realistic proposals for how to move things on (at least I think so).

I cannot imagine there is a giant ‘ROOL effort’ machine which is pouring man-hours into the TCP/IP bounties just to stick fingers up to ROD. ROOL have stated repeatedly that they are merely the custodians, and they rely on other people to contribute. No-one is in a position to strong-arm developers, surely?

Finally, here is no reason why there couldn’t be a fork of ROOLs git, but with the ROD TCP/IP & Pinboard2 etc., perhaps with a build process for ‘RISC OS Direct nightly’. That this doesn’t exist makes me wonder if there are different views on ‘open’.

Chris mentioned the two NVME drivers, but I think that’s a very different situation, and is more in the style of open source development – i.e. two people/companies wanted NVME, so they went away and developed them, and both were then made available for free. That’s absolutely fine, I’ve no issue with that.

The TCPIP stack situation is very different. ROD decided they (or rather, their client) needed a new stack with IP6, so they went off an developed one. This was announced in January 2020 and demonstrated in December 2020. It was made available to users to beta test in 2021 and was shown to be a simple drop in replacement for the existing stack, compatible with existing applications and hardware drivers. Fantastic.

Then six months later in February 2022, ROOL announce that the bounty has been claimed and that they are going to spend £20000 of other people’s money developing another network stack. This did not need to happen. It is not normal open source development, because ROOL get to decide if and when a bounty is claimed or not, so they could have simply said “Thanks, but we don’t need this now”.

£20000 is a lot of money in RISC OS land and ROOL could have reallocated it to other bounties. We still don’t have partition support, 12 years after it would have been very helpful when the Pi arrived. Or maybe they could have added SMBv3 or NFSv4 support, etc. Things that we need, unlike a second network stack which we definitely don’t.

ROD decided they (or rather, their client) needed a new stack with IP6, so they went off an developed one. This was announced in January 2020 and demonstrated in December 2020. It was made available to users to beta test in 2021

in February 2022, ROOL announce that the bounty has been claimed and that they are going to spend £20000 of other people’s money developing another network stack.

Not sure that’s entirely fair. When were the TCP/IP bounty descriptions first published? (when donations could start being collected). Another way of looking at it is asking why ROD didn’t decide to deliver upon the bounties, rather than do their own thing. Just to stress, I am not saying that they should have done this – there is no obligation.

I think if people have donated to TCP/IP stack bounties, then they would reasonably expect that money to be spent on them.

Addendum: Actually, I have some of the dates: Bounty step 1 was (I assume) prior to March 2018, step 2 (modernise) was March 2018 and step 3 (wifi) was June 2019. I can’t find out anything about step 4.

Ok have been able to revisit and start a couple of tests – will join the existing thread in ‘Community Support’ called ‘Wi-Fi in 5.30’

Am I understanding this correctly – RISC OS actually needs to reboot after configuring the wi-fi (or wired network interface)? I thought this was some kludge that dated back to Acorn when they brought in the internet panel into Configure? Back in RO3.7 days it was perfectly possible to reconfigure the network interface without rebooting if you opened a task window and used *ifconfig manually.

Come on, even Windows doesn’t need a reboot nowadays after you change the wi-fi settings.

Or have I missed something?

Or have I missed something?

Yep, about 20 years of development by Microsoft with a price tag of lots, and meanwhile 20 years of not-a-lot done or spent on RO

As you point out, even Microsoft can get something right given enough time and money.

Or have I missed something?

Yes :-)

The reboot is only really required on initial installation. After that, simply pick the WiFi hotspot from the iconbar menu.

However on the ROOL stack, switching between wired/wifi does need a reboot, whereas with ROD’s Network Manager it is all dynamic and you can have multiple wired and even multiple WiFi connections active simultaneously and it all configures automagically.

you can have multiple wired and even multiple WiFi connections active simultaneously and it all configures automagically.

Including the interface metric(s) and default route?

The reboot is only really required on initial installation.

The reboot is only required because the Configure app doesn’t rerun the !Internet start-up script after writing it, instead opting to prompt for a reboot – which is a throwback to when NIC’s were Podule based.

However on the ROOL stack, switching between wired/wifi does need a reboot

Again, that isn’t strictly the case, you can switch between NIC / WiFi by manually running the start-up script again – provided it’s written to support both, which isn’t currently supported by the Configure app. I’ve included an example section below.

All it really needs is a small app that monitors if WiFi is connected and if not try a DHCP on the NIC in the background. Ideally ROOL/ROD need to agree a standard for supporting multiple network interfaces so we don’t end up with multiple bespoke solutions. I’d start by adding SWI to both NIC and WiFi drivers to determine if they are connected and possibly further SWI to allow them to perform a DHCP action in the background when they detect a connection. The DHCP Module also needs rewriting so it’s threaded.

| DHCP pre-interface initialisation
|
RMEnsure DHCP 0.22 RMLoad System:Modules.Network.DHCP
|
| Host name
|
Set Inet$HostName ...
Set Inet$LocalDomain ...
Set Inet$EtherIPAddr dhcp
Set Inet$EtherIPMask default
|
| Interface: BCM43 WiFi
|
RMEnsure WLanBWFM 0.05 X RMLoad System:Modules.Network.WLanBWFM
|
| Interface: Ethernet over USB or Broadcom GENET
|
IF "<Inet$EtherIPAddr>"="dhcp" THEN Set Inet$EtherDevice EtherUSB
IF "<Inet$EtherIPAddr>"="dhcp" THEN RMEnsure EtherUSB 0.0 Set Inet$EtherDevice EtherGENET
IF "<Wimp$State>" = "commands" AND "<Inet$EtherType>" <> "" THEN Echo Contacting DHCP server
If "<Inet$EtherType>" <> "" THEN X DHCPExecute -e -b -w -p <Inet$EtherType>
CheckError
If "<Inet$Gateway>" <> "" Then do /Inet:bin.route -e add default <Inet$Gateway>
CheckError
IF "<Wimp$State>" = "commands" THEN Echo <11><23><8><5><6><0><0><0><0><0><0><11>
|
| Loopback

All it really needs is a small app that monitors if WiFi is connected and if not try a DHCP on the NIC in the background.

Or vice versa, generally speaking wired connection should be the preferred option¹ as it presents better bandwidth, especially so in a busy wireless environment.
A dual active interface setup is suboptimal for general network use.

¹ Most laptops have an option to disable the wireless interface when wired is active – you may need to look in the BIOS settings

Just an update to say that the beta I mentioned earlier is now available to testers (a large group, and anyone is welcome). All being well it’ll be on the ROD website later this week.

Headline feature is support for hotel/restaurant wifi portals (aka login pages) so you can literally take your computer to a Premier Inn, connect to wifi, and it will show the login page and connect to their wifi. Once logged in, it then remembered me for the rest of the day.

Additionally, since NetManager is now included inside !OBSD (the stack folder), there’s a !configure option to allow it to be in charge of networking. Choosing this will allow dynamic, “no reboot” networking for RISC OS just as you’d see on other operating systems.

I believe (unconfirmed because the programmer is on holiday this weekend) it also has a basic implementation of interface prioritisation as discussed in this thread, too.

Just an update to say that the beta I mentioned earlier is now available to testers

A thumbs up from here then, an easy, quick install that “just worked”.

One could go all the way back to the abacus or the harnessing of electricity. But I think it’s safe to say that modern day computing really only became ubiquitous and truly personal with the advent of wireless.

It was in July 1925 that the BBC started long wave wireless transmissions from Daventry covering most of the population. A bit early for computers!