New bounties, additions?

Wasn’t the main problem the with issue the IOMD ROM overflowing when Obey is replaced with CObey?

That was an issue but there have been a couple of space savers since then, there is now 43.42K spare space.

A long descriptors Pi build is a bit tighter with 2.46K spare.

CObey.19 is now running in Titanium, Pi and RPCEmu ROMs. I have used CObey previously without any issues.

There is no licencing problem, its just a small issue of changing the RISC OS tool chain from Norcroft to gcc, as Norcroft doesn’t have C++.
(CFront from 1989 does not count)

My personal preference is for the LLVM based tools as I prefer them to GCC however I agree with your broader point. While Norcroft has served well it is showing its age. CFront may not have been state of the art in 1989 but it was still useful. At this stage it really doesn’t offer much of value.

If there are any optimisations in Norcroft still not supported by other compilers then effort would be better put into implementing, or persuading others to implement them, in a more current compiler.

Dave I do indeed have little understanding of the process or who should do what! From my point of view if you decide to write a module for the OS then you’re also the one that has to do the ‘pushing’. If we are serious about writing more on volunteer time, then I think it would be worth it to have someone dedicated to making sure things are going through, and finding out why not if not, someone who knows who to talk to etc.

AFAICS there is no problem getting stuff into Git. The problem is in getting approval. Perhaps this is the old thing: it’s everybody’s problem, therefore it’s nobody’s problem. Who has sufficient power to approve submissions? Are there enough such people? Do they all get to know that something is awaiting approval? Is there any process for taking ownership? How much evidence do they need of sufficient testing, so that they feel safe to approve it? Does everything need a thorough code review? (Few people volunteer to do that, in my experience.)

FWIW, I favour a relatively relaxed attitude to approving new stuff. If it’s new, we kind of expect that it might have bugs and/or be incomplete, but we can only really find out when a number of people start to use it.

A recent(ish) example that I’ve taken a keen interest in since release is the AcornSSL module. It wasn’t bug free, and it was short of a feature that prevented it from working on some FTP sites. It’s been through several iterations. In fact I can still point to one or two minor bugs now.

But where would we be, had it not been released?

Do they all get to know that something is awaiting approval?

I thought that there was a process involving creating a merge request and assigning it to ROOL, or something along those lines?

I favour a relatively relaxed attitude to approving new stuff

Given the number of people who use the nightly builds, there does need to be some confidence that it’s not going to break the build or people’s machines. The message that odd numbered builds are unstable is still being muddied from some quarters.

I thought that there was a process involving creating a merge request and assigning it to ROOL, or something along those lines?

My concern is what happens after that.

My concern is what happens after that.

I’m fairly sure (from first-hand experience with GitLab elsewhere) that once assigned, whatever constitutes “ROOL” will¹ be kept informed of all commits, comments and status changes made to the request. So presumably we’re then down to the people concerned having the time to review the changes, ensure that they don’t break other things that may have been merged in the meantime, and accept them.

We need to be really careful here, as there’s nothing more demotivating than having people complaining that you’re not doing something that you do for free in your limited spare time fast enough. And a project the size of RISC OS really does need a review process – it couldn’t just be a free-for-all. What might work for application software could be a real problem for an OS.

¹ Assuming notifications aren’t disabled, which would seem to be at odds with the whole point of the assignment in the first place.

Like you, Steve, I’m an engineer – a professional problem solver, if you like. There seems to be an ongoing problem in getting some stuff approved, so I want to solve it. First we have to identify exactly what the cause is, then we can move to solving it. I’m not complaining, I’m trying to analyse the problem.

I don’t want a free-for-all; but is it free for enough?

The key is communication – us mere mortals don’t know how our merge requests are triaged.

I’ve recently begun contributing directly via ROOL GitLab and been pleasantly surprised at how quickly the MRs are reviewed, and received helpful feedback. How quickly they are accepted and merged? I think it depends – certainly one fixing a stack imbalance that would either crash or corrupt the function’s caller was merged very quickly after review, whereas the ones fixing twenty year old inaccuracies in rarely used SharedCLibrary functions, less so, which seems fair!

I don’t want a free-for-all; but is it free for enough?

We do seem to have some hard limits that will bite – imagine if three or four people took up the challenge of rewriting some modules in C and then the ROM wouldn’t fit any more. Who gets to decide which is chucked out?

imagine if three or four people took up the challenge of rewriting some modules in C and then the ROM wouldn’t fit any more. Who gets to decide which is chucked out?

The languishing code issue may be that the approving person(s) are limited in time and may be taking more notice of specific developers, or simply overlooked something that happened while they were busy elsewhere. I would assume that approval consists of more than just a tick in a box and actually involves an element of code checking/testing.

Looking at the issue purely from the point of view of making new modules etc available to a wider audience for testing, I see it as presenting a need for a new download and a feature addition in all builds that allows a new module to be loaded when in test mode and defaulting to the standard module when in normal boot mode.

Julie wrote a menu start up that would possibly fit the requirement.

The feature would present something akin to the poduleroms directory in RPCEmu where simply dropping a module in there allows that version to be loaded in preference to the same name module in the OS ROM, but in a startup menu controlled fashion.

As to which should be chucked out – perhaps we should be asking why any module is in the ROM rather than in a podulerom or in the “HardDisc4” download. Are some in the ROM simply because they fit?

Mumble, mumble, Draw, Paint…

Sure are lots of things that are really nice to be in ROM, such as the DrawFile module, but hey, we all RMEnsure it don’t we. Onto the disc with it! (and packaged, so that punters can get updates without having the palaver of trying to merge HardDisc4 with their current content)

Things that have actually been built optimised for that architecture, definitely keep them in ROM. Like VFPSupport, SharedCLibrary. You don’t really want to be running a softload SCL built for the lowest common denominator for ultimate performance.

But we are generally blind to the requirements of the commercial customers who may need modules x,y,z in ROM in their turnkey systems.

the palaver of trying to merge HardDisc4 with their current content

Thinking of which, has anyone done a suitably interactive HardDisc4Merge application? If not, it could be worth considering. I might be up for this.

As for this one: Faster start-up (Move DHCP interaction to desktop)

Not sure if that is a good one – quite a few current RISC OS systems have no hardware clock and thus rely on NTP to get the correct time during boot from internet.
Question arising ist, if the DHCP can be simply made faster – my impression is that Windows and Linux manage to get an IP address with DHCP quite a bit faster than RISC OS.

As for this one: Faster start-up (Move DHCP interaction to desktop)
Not sure if that is a good one – quite a few current RISC OS systems have no hardware clock and thus rely on NTP to get the correct time during boot from internet.

I would have thought the solution here is to kick of the process during boot, where it feels like it belongs. But return immediately and raise a broadcast message once it has been achieved. Then everyone waiting for connectivity (like NTP) can jump in and do their thing.

Of course this rather requires the messaging system to be taken out of desktop and be made a more fundamental service. As it probably should be.

After all, there’s no guarantee the desktop will be started which causes problems if you’re waiting for that to happen before performing DHCP.

As far as the issue of what happens to things which don’t fit in ROM, well then they don’t go in ROM. Booting from ROM is a great feature, particularly for embedded systems like kiosks but also for desktops as it guarantees a certain level of functionality even without discs being available. But the days of fitting a complete desktop operating system in ROM are gone.

As observed above, a lot of stuff is in ROM which really has no place being there. Only drivers for the currently running hardware, kernel and core operating system components should be effectively hardware. Of course what is “core” is a question bound to lead to a bun fight.

But we are generally blind to the requirements of the commercial customers who may need modules x,y,z in ROM in their turnkey systems.

We have builds specific to hardware platforms, what prevents that being used as a guide for builds for specific commercial customers?

Thinking of which, has anyone done a suitably interactive HardDisc4Merge application? If not, it could be worth considering. I might be up for this

Aren’t you talking yourself into the job of analysing the current HardDisc/Boot structure and altering it to something that better fits current use cases?

Aren’t you talking yourself into the job of analysing the current HardDisc/Boot structure and altering it to something that better fits current use cases?

Analysis (of both the current HardDisc4 image and the punter’s currently installed cruft), yes. Restructuring, no.

Of course this rather requires the messaging system to be taken out of desktop and be made a more fundamental service. As it probably should be.

I think everyone is pretty well agreed that the desktop should not have any involvement in task management, rather task management should tell the desktop when it can do its thing. Presenting an API that all existing software can work with is probably the first hurdle.

I don’t understand why there seems to be a size limit for the “ROM” since it’s actually a file containing an image.

Are we still producing hardware ROMs?

Before the Desktop starts there are service calls sent out, one of which is Service_InternetStatus (&B0) which has a bunch of reason codes to do with dynamic booting, though that does require a module rather than an application to handle the Service calls. NetTime already looks for Service_InternetStatus so it may well cope already with DHCP not being ready when loaded.

Are we still producing hardware ROMs?

The Titanium machines have an 8 MB physical ROM. The 5.28 image is only 5 MB but I don’t know whether there’s some form of compression or whether the remaining 3 MB is unused.

I think most (all?) of the other current hardware uses files.

@Richard Coleman: NetTime already looks for Service_InternetStatus so it may well cope already with DHCP not being ready when loaded.

Sorry my posting was not clear:
Sure, you can boot with no network and then some (quite a few) computers run with no hardware clock and thus far in the past and any file updated or log written will get a useless datestamp.
Due to that I do prefer to rather wait a mo for DHCP to be done and NetTime to set the system clock before the computer does the bulk of the booting.
I thus would prefer the DHCP to simply be more efficient, or at least the OPTION to decide if I want to wait for DHCP during PreDesk phase, or if I prefer to see the destop faster (with the aforementioned side-effects).

@ Stewart

Things that have actually been built optimised for that architecture, definitely keep them in ROM. Like VFPSupport, SharedCLibrary. You don’t really want to be running a softload SCL built for the lowest common denominator for ultimate performance.

IMHO, on the long term, this should be a “job” for Packman. In the sense that Packman should handle the different architectures (it already has the “protocol” for this implemented). So, for example, a SharedCLib compiled for imx.6 should be delivered through that path to the machines that have packman configured to get updates for generic and imx.6.

In other words, IMHO, ideally, on the long term, the ROM image should become minimalistic. Include what really necessary to the RISC OS boot process and then load the rest at boot time.

This has the potentials to:

• Help in making it faster to deliver updates for the OS itself
• Make it easier to tailor the OS for commercial users and for embedded solutions (although if here someone may argue that by having been building ROMs for ages with the old process they find it already easy as it is)

Just my 0.5c