WiFi: ROOL or ROD?
David R. Lane (77) 766 posts |
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? 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. |
Chris Hughes (2123) 336 posts |
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. |
Rick Murray (539) 13806 posts |
This is why duplication of effort around what is essentially the same thing seems less than useful.
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.
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.
“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. |
Dave Higton (1515) 3497 posts |
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. |
Steve Fryatt (216) 2103 posts |
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 one1, 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 with2, then how hard is it to copy the files over to a Windows, Mac or Linux box, and type
plus an optional
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.
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… 1 I do like to grab source code for stuff, when it’s available. 2 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. |
Elesar (2416) 73 posts |
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. |
Rick Murray (539) 13806 posts |
Rather than casting aspersions, why don’t you just ask?
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.
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 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.
Neither can it be easy to work together with a party who seems blithely unconcerned about the entire point of module version numbers.
Depends how well they know RISC OS. ;)
Ask… |
Chris Mahoney (1684) 2165 posts |
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. |
Dave Higton (1515) 3497 posts |
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.
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. |
Richard Walker (2090) 431 posts |
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? |
Dave Higton (1515) 3497 posts |
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). |
Rick Murray (539) 13806 posts |
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’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. 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. |
Steve Pampling (1551) 8154 posts |
Probably the absence of an easy to install and use client for the current flavour-of-the-era source control options. Speaking as someone who has spent decades “encouraging” people to do “the right thing”1 the best technique is to make it easy for people to do what you want them to do. 1 some call it railroading in my chosen direction, although since those were political and business opposites they don’t count :) |
Steve Fryatt (216) 2103 posts |
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).
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…
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. |
Steve Fryatt (216) 2103 posts |
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! |
David J. Ruck (33) 1629 posts |
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. |
Cameron Cawley (3514) 156 posts |
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.
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).
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. |
Stuart Swales (8827) 1349 posts |
Oh. Well, saves me the bother of trying the new git client out… |