Forked

I was finding this WROCC Bounty Zoom truly informative but towards the end it took an unfortunate and rather unsettling turn.

Where in the video, for those who don’t have an hour and a half to spare?

Edit – reading the transcript of the auto subtitles, it’s at 1h22, yes?

I think you are right. It is just before the “Can we take the politics off line please?”

Hmm. If I were a developer who’d picked up a meaty ROOL bounty, was making progress, hitting targets, I would still expect to be paid fully even if A.N.Other entity announced that they were doing the same sort of thing for a commercial customer so it’s not unreasonable for ROOL to expect a deliverable from me done to their spec.

I debated whether or not to raise this point for a while now and decided not to until now.

Organization Blue announced it was working on and delivering a product; source code available.

Organization Amber told us sometime later it was starting similar work using a pot of donated money.

Amber updated their fundraising page at some point, and I might expect the persons who donated to raise an escalation or complaint. If I recall correctly, a person from the organization Blue funded part or all of the bounty. I could be wrong.

For me, a common sense approach would have been to integrate and merge the work of organization Blue versus seemingly ignoring it and doing something similar. It feels like a duplication of effort and ignoring a general shortage of resources.

Does it feel like Deja Vu to me? Yes.

On reflection, it is sad, as both organizations are delivering.

Does it feel like Deja Vu to me? Yes.

Yup. I think we’ve all been shouty-shouty enough about the network stack issue.

Question is, how to resolve it? Clearly something went wrong, lack of communication or whatever. But what’s done is done. If anybody would care to point fingers to assign blame to somebody else, kindly GTFO, I see enough of that at work. :/ It’s never helpful as it makes everybody defensive.

Therefore, a much more pertinent question might be: What are we going to do with two stacks? Will the RODev one ever be offered in ROMs, for instance?

Additionally, what is the difference between them, both in terms of speed and security and general capabilities?
Or in simpler words, why might a person choose one stack over another?

Finally, will those in charge of both projects be willing to step up to assure us that they will be in communication with each other to do everything they can to ensure complete compatibility (otherwise it risks us programmers picking sides rather than the software just working)?

On reflection, it is sad, as both organizations are delivering.

It’s not sad, it’s dumb. Let’s hope (god, I can’t believe I’m writing this) lessons are learned (ugh, I feel dirty now) on both sides so everybody can work towards a common goal without the unnecessary duplication of effort.

I could totally understand, if I’d taken up a bounty, someone else also trying to work on the same thing. I’ve spent 18 months trying to do something someone else might take 2 months on. Then they’d deserve the bounty, if they’d also signed up for it. Competition is not necessarily a bad thing.

If someone with financial backing signed up, I’d probably turn my attention to something else. If I’d signed up, and a company offered me money to work harder, I’d probably do that, too.

And finally, my friends, let me say just this

it’s at 1h22, yes?

The lead up to that starts at 1hr12m30s, but I would commend the whole recording.

(Auto subtitles comes up with “murdering requests” for “merge requests”, not entirely incorrectly perhaps.)

it risks us programmers picking sides

I think you might be able to relate to the idea of grabbing popcorn, drinks and a comfy seat – if it is deja-vu, then go and weed the veggie patch.

I believe one of the stacks is based on FreeBSD and the other is based on NetBSD. Personally I can’t see the point in having two stacks. Seems like wasting resources, but thats just a personal opinion.

The goal of wireless connectivity is so important for RISC OS that I can see both points of view. If a commercial customer wants it and will pay, then ROD is wise to pursue this option. If a bounty might attract someone to do it then ROOL are wise to offer a bounty and hope for the best. The potential forking will disappear once WiFi is working as that fork will survive and the other will die under the normal principles of natural selection. If this happens before the bounty is claimed, the bounty will obviously be diverted to other projects.

Constructive tension between the two organisations in this single area is not necessarily a bad thing. In other areas there is good co-operation.

then go and weed the veggie patch.

Done, and it’s dark miserable and cold this time of year. 😭

Heated blanket, hot chocolate ¹, and Netflix is about my speed in the arse end of the year.

as that fork will survive and the other will die under the normal principles of natural selection.

That’s either startlingly naïve or startlingly optimistic. ;)

tension between the two organisations

…is something that should be avoided at all costs. This isn’t Microsoft versus Apple, or even Tetley versus Typhoo.

We don’t exactly have sufficient resources around to have ideas like having competitions. People clever enough to port network stacks to the platform would get so much more done working together than at cross purposes. Rinse and repeat for any other examples.

And this isn’t even discussing the big elephant in the room (the one with sixty four pieces).

¹ Actually, I bought myself a jar of Horlicks from Amazon for an extortionate price. I hope it’s as good as I remember. I’m saving it for December. Only one more day to go!

I think it’s a storm in a teacup.

Steve summed it up well by pointing out that this is the nature of open source development. These things happen. And it’s OK. ROOL had a number of people contribute to a bounty, and that is underway. Similarly, ROD had some people willing to pay for IP6 support. Are not both sets of customers getting what they wanted? No problem, is there?

You could say that is’s a bit odd having the competition in such a core area (unlike, say, StrongEd vs Zap, or Impression vs Ovation). But I would put that down to overall communication being poor up-front. The bounty information has been kicking about for years – not sure when the ROD stuff was made public. Where ROOL may suffer is in the lack of clarity on the code submissions process (which I’m sure they will address).

A rough timeline that I posted in the chat of the WROCC meeting, so it won’t be in the video:
- Jan 2020, ROD announce they are working on a new stack, funded by commercial project
- Dec 2020, ROD demonstrate new stack working (Andrew ran a whole ROUGOL presentation using it!)
- Oct 2021, ROD stack in beta test
- Feb 2022, ROOL announce their bounty has been claimed and they are starting work on a new stack. Everyone says WTF?
- Apr 2022, ROD stack released. It works and is back compatible with all old programs.

I think it is important to reflect that ROOL are amateurs doing this work in their own leisure time and have no commercial imperatives. The bounty system is simply an enabling mechanism for other people to volunteer to do work at well below commercial rates for the love of the platform. Inevitably work sponsored via the bounty system will take much longer than work commissioned at commercial rates.

We should not expect too much from it.

ROD stack in its current state makes RISC OS unusably slow over VNC, so I’m glad ROOL are working on an alternative, which I hope will be better. But if the current underperforming stack (compared to Linux on the same hardware) is replaced by anything slower, that will mark the end of my use of RISC OS.

Thanks Bryan, I thought I remember someone saying the ROD stack was started a long time before the ROOL stack was even started.

Druck, You have said this a couple of times about your use of VNC with the new stack. I simply do not see that here! In fact I found it faster and certainly more stable then the old stack when using VNC from RISC OS to Winodws, and also when doing it the other way. Avalanche 0.28 14-Jun-2021), and one of several VNC servers on the PC, and obvious the VNCServer 0.22 also from 2021 and various PC VNC viewers.

For what it is worth my thoughts are this is what happens when you have an open source product as anyone can take it and modify it.

Now RISC OS has a rich legacy with “I shall never use your devils spawn as you have changed x to y” type attitude and I agree that things don’t make sense from a development point of view when we have a limited pot of active developers but we are where we are.

Some seem to think that ROOL should not have started development of a new stack when someone else is doing it but as one who contributed my view is I saw the terms of making a bounty contribution and I understood the risks so I can hardly complain when the money I contributed to a bounty was used exactly for that.

The two approaches seem to have the same aim but slightly different approaches in one is built on a more security minded stack with an empathise on more modern kit with legacy via intermediate layer and the other looks to build on the current stacks heritage so in theory offer a past , present and future approach. Both development stances in my view have their own positives and negatives.

As the old saying says “You are stuck waiting for a bus and two come along together” so rather than celebrating we have two substaintial developments we moan we only should have one.

As to the speed “issue” with the new ROD stack then firstly it is beta and surely stability is better than speed at this stage as you can optimise later and also I’ve not yet seen a speed issue but it could be due to the mix of networks/devices that it is used in that makes it exhibit the issue and that again is something that beta testing is all about exposing.

Anyway as the saying goes “We are where we are” and lets rejoice in two developments rather than none at all.

so in theory offer a past , present and future approach.

A theory amusingly blown away by the ROD stack being a drop-in replacement for the existing one.

we moan we only should have one.

Which one (if not both) is going to be available in ROM releases?

the ROD stack being a drop-in replacement for the existing one.

Depends on if you are a purist or not given the different approaches.

Then again RO5 is devils spawn to some just as 4 and 4.39/6 are to others.

Which one (if not both) is going to be available in ROM releases?

Depends on the distribution and what system(s) it is tailored for I guess would be the reply.

No different to the many Linux ones but as many have pointed out a bit more tricky in our limited market.

“a plague on your devils spawn” seems to be the outcome yet again.

Anyway if Paolo’s initiative gets new people in then we may be having many more interesting discussions on contributions going forward.

Depends on if you are a purist or not

Funny thing is, I don’t give a flying Fudge bar how it works or where it’s derived from. Does it work? Yes. Is it compatible? Yes.
That’s the end of the discussion as far as I’m concerned.

Sure, there may be issues regarding speed as somebody (Druck?) mentions, but this may depend upon machine and workload as I’ve found NetSurf downloads to be a bit faster.
Again, it’s early days.

for I guess would be the reply.

Sadly this risks, indeed, forking the OS because it isn’t “a base OS with different added stuff”, the stack is an integral part. It would be an actual different ROM build.

No different to the many Linux ones

Users of Linux versus users of RISC OS?

“a plague on your devils spawn” seems to be the outcome yet again.

So you feel that two different people (or groups of people?) creating the exact same thing in slightly different ways at more or less the same time when the OS can only include one is a useful endeavour? The USB stack needs updated (bounty open), there isn’t even a bounty for Bluetooth, and even with networking there are plenty of protocols that didn’t exist back in ‘97 that exist now. Does any version of the Resolver module know how to deal with a lookup for “laser.local”? Duplication of work is just illogical. It isn’t as if we are the kind of market where several stacks can be written and sales or popularity will dictate the winner.

just as 4 and 4.39/6 are to others.

For my part, I have no intention of supporting 4.39 (etc). This isn’t because it’s devil’s spawn, it’s simply because I don’t have a copy and it hasn’t been updated in any meaningful way in thirteen years.

Obama was voted President, Michael Jackson died, and the first Avatar was the popular film. The Beagleboard xM didn’t exist, and it’d be another three years before the first Pi.
Remember all that? That’s how long ago it was. And, indeed, one could perhaps take that as a parable of unnecessary duplication of effort (didn’t Gerph 32 bit the OS independently of Castle?).

No different to the many Linux ones…

Maybe not the best example. The Linux internet stack is part of the kernel, so it should essentially be the same for every Linux distribution.

Funny thing is, I don’t give a flying Fudge bar how it works or where it’s derived from

My mention of “purist” didn’t mean that was my view but some may have that view as only one true and validated source.

So you feel that two different people (or groups of people?) creating the exact same thing in slightly different ways when the OS can only include one is a useful endeavour?

So the slightly different USB stack in some ROM distributions shows this already happens..

The situation isn’t ideal but it is where we are at the moment and as you say you have no intention of supporting 4.39 etc and the 32 bitting of that strand can show where things lead too in sadly a dead end and wasted resource but that was when things were a lot more commercial in the market and we all know what the end game was there.

When you open source something then as I said these things can happen and us not liking or agreeing with it doesn’t come in to it unless we want some sort of straight jacket again on what can and can’t be done.

didn’t Gerph 32 bit the OS independently of Castle?

The 32bitting of RISC OS Select was held off for a long time because of discussions with Pace (who did the 32bitting, not Castle) for sharing more of their code, which were intially very promising, so that we did not duplicate work. Similarly, we attempted open sourcing components with the agreement of Pace so that non-core areas could be worked on by others. The 32bitting work itself wasn’t attempted independantly because none of the hardware vendors were willing to commit to producing new hardware. Without new hardware being produced, there would have been no reason to 32bit the system other than it being the right technical choice, so instead work was done to make the transition easier if it were to ever come about – moving components to be C based, incorporating new code into assembly modules in C so that they would be easier to port etc. When CTL came along and took Pace’s 32bit work and started to produce a new machine, under their claimed rights to do so, there were lengthy discussions with them. And legal tat too, which I won’t discuss here. Communications with CTL about anything technical were met with stoney silence and in certain cases implementations which were incompatible, despite having been informed of problems and been given a heads up. Select has many work arounds for CTL behaviour which could have been avoided if they were to have listened to the communications.

When CTL took over the head license agreement, one of the first things they did was to attempt to quosh the open source components. Further discussions were involved with them, but there was no give and take – it was a ‘you will take what we give you’ attitude, despite the RISC OS Select system being significantly superior internally due to the rationalisation or design work which was intended to take the system towards the future. You can still see this within the parts of RISC OS 5 that are a nightmare to work with – the Kernel, Filer, FileSwitch, WindowManager, SharedCLibrary to point to a few specifics. There were attempts to merge the sources, such as trying to share the Toolbox sources, however, these were again a matter of requiring the Select versions to be merged to the CTL versions, despite the CTL versions being the older and largely unchanged ones.

There was work on many of the RISC OS Select components to make compatible such that they might run on a CTL system. These would never be ‘good’ because the kernel features wouldn’t be the same, and ‘you can’t fix those in post’, but this was attempted and demonstrated. With STD interested in producing their machine ¹, there was a need for 32bit, so I made the system 32bit, except for a few modules. CDFS and the ViewFinder video driver were done independantly. ²

Where things have been made publicly available and documented, CTL (and, over the past years, ROOL) have notably ignored them, created incompatibilities with RISC OS Select, and not cared about actually making things compatible. That’s not a problem with duplication or anything to do with things being open source, but of failing to work with others.

That is my experience of how things have been in the RISC OS world and the circumstances of the 32bit work – so yes, there was duplication there, which was enforced because of an inability of parties to work together.

¹ Ok… that isn’t quite the right ordering of events, but it reads better. What actually happened was that I was porting Homeworld and needed a bigger WimpSlot. So I reorganised the memory map and began the porting of the Kernel, C library, BASIC and a number of the support modules so that I could have more memory for it. Then STD came along and said they were interested, and I’d done a bunch of the low level work already.

² Then I felt that it was all too much, and moved on.