RISC OS relicensed: now under Apache 2.0!

chat about arc/risc pc gaming & RISC OS software here (NOT the core OS!)Related forum: adventures


User avatar
danielj
Posts: 7317
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by danielj » Tue Oct 30, 2018 7:24 pm

Oh no, I realise that - but the directors still exist so would be in a position to make a decision about what to do with it (if that is indeed a sticking point). Who knows what the real situation with anything is though :D

d.

User avatar
BigEd
Posts: 2528
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by BigEd » Tue Oct 30, 2018 7:27 pm

Let's hope...

User avatar
davidb
Posts: 2413
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by davidb » Tue Oct 30, 2018 7:33 pm

Phlamethrower wrote:
Mon Oct 29, 2018 9:37 pm
Remember that there are still a few closed-source components (at least MbufManager, Resolver and ShareFS). They're on ROOL's list of things to sort out, but until that happens you're going to be left a bit short if you're interested in a fully open-source OS.
Could the old FreeNet Resolver be used as the basis for a Resolver replacement if the sources were available?

Is ShareFS really that critical? I suppose the FS part of it might be useful but there are better alternatives for sharing files and printers.

User avatar
danielj
Posts: 7317
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by danielj » Tue Oct 30, 2018 7:45 pm

ShareFS is quite handy if you're using AUN and want to shunt things from raspberry pi to Arc/RiscPC etc... I'm not quite clear on why those components aren't open though - who owns the copyright on them and why wasn't it transferred to Castle with everything else?

d.

User avatar
davidb
Posts: 2413
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by davidb » Tue Oct 30, 2018 8:55 pm

I think they were originally written by ANT. Richard Brown's talk contained some more information about it. Basically that whoever owns the copyright on them now probably doesn't know anything about them, and palms may need greasing for their lawyer to even look at them.

Phlamethrower
Posts: 103
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by Phlamethrower » Tue Oct 30, 2018 9:11 pm

It was the ROOL talk (or perhaps both talks?)

https://youtu.be/110El6TbMY0?t=1000

User avatar
davidb
Posts: 2413
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by davidb » Tue Oct 30, 2018 9:32 pm

Phlamethrower wrote:
Tue Oct 30, 2018 9:11 pm
It was the ROOL talk (or perhaps both talks?)
Ah, thanks for the correction. Yes, I think it was only mentioned in the ROOL talk in that level of detail. I knew it wasn't in Andrew Rawnsley's talk, anyway. :)

User avatar
paulv
Posts: 3854
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by paulv » Tue Oct 30, 2018 10:51 pm

I know most of the community are "outsiders" regarding RISC OS and the shenanigans that have led us to this point, myself included but as a member of the community, after watching that video I can't help thinking that things are being over complicated with bounties and legalities etc. especially when some bounties are quoted as needing £14k to fund and no-one is sure that it'll ever be reached within the RISC OS community.

For someone to sponsor a bounty of that size would mean that you'd have to have some sort of viable business model to give you a sizeable ROI that was critical for that bounty to be completed AND be something only RISC OS could do. I can't think of any situation that would make that a long term viable investment opportunity for a sponsor because I can't imagine that there's anything that RISC OS could do any better than a Linux or other open source OS solution for that matter where it would be cheaper to spend £14k on RISC OS and wait for the code to be developed than doing it with those other platforms and probably be able to do it immediately.

It seems to me that the only way to make open source work is to go the whole hog and release as much as possible on an open source licence. That for me would include the development suite to encourage people to engage. After all, that's what made the BBC Micro so great, you got BASIC and the 6502 Assembler built right into the machine. It was designed to encourage creativeness and development and you didn't have to buy anything else to be a productive developer. That was part of the genius of the BBC Micro.

There might be a way forward I suppose if the "purchase" is seen as a deposit where, if the dev contributes a *significant* amount of time/resource/code to the code base then that deposit is refunded. It might work for real enthusiasts but it would still put off people that just wanted to contribute an odd bug fix here and there. I still think going free for the tool chain is the way to go, after all, I can even develop for free on Windows using an MS tool chain so why would I pay to develop on RISC OS when I'm already giving up my precious time for free. I can't even chase a bounty for recompense because many of them are not funded and if they're not funded, there's a distinct disincentive to work on those areas of requirement.

I think it'd be far better to go fully open and remove the bounties in the short term. Going this route would leave those businesses that want to make money from RISC OS needing to develop value added services/products and charge for those things. A RISC OS laptop, a RISC OS desktop, a RISC OS niche OS targeted at a specific user group etc., etc.

The "value added" model is tried and tested for a lot of open source projects and by going free for the tool chain you're more likely to expand the developer base and once you've done that, then it might be worth introducing bounties again. By then, those bounties should very much be driven by the requirements of progressing the OS, not just keeping the OS up to date with new hardware requirements. These new bounties driven by progressive requirements could be sponsored by those companies that are using the value added model to make money off of RISC OS. It allows them to feed the community that is helping them to thrive as a commercial entity. A win win.

I understand that navigating the legalities for the parts of the system that are still closed source does present a problem at the moment but if the dev community were enabled by having an open source/free to use tool chain I'm pretty sure people would be happy to clean room re-develop those features without the need for bounties and they'd probably get done sooner rather than later as those components are either critical for modern use or just plain useful to RISC OS users in general.

The other thing I picked up on in that video was that it took two years to get around to doing one weeks work that would have kept RISC OS on Noobs. This seems to be a bit of an odd decision regarding when to do that work. Not being on Noobs meant new Pi users never saw RISC OS as an option for two years. Unless they already knew about RISC OS, that was it, chance blown to attract new users and developers. Being Noobs, I've can't imagine users of Noobs would know about RISC OS without being told about it!

I realise there were other competing priorities for the development of RISC OS at the time (when aren't there competing demands for development) but for the sake of a week to maintain and potentially expand the community I would have thought that staying on Noobs would be a higher priority than it seems to have been. If it were done sooner, the other things might have been accelerated too! Spend a week to potentially save months.

On the up side, at least CVS will be replaced with Git.

Paul

hubersn
Posts: 136
Joined: Sun Aug 14, 2016 7:59 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by hubersn » Tue Oct 30, 2018 11:21 pm

This discussion about the "non-free development tools" really confuses me. It seems to be based on a lot of misunderstandings. Like that one:
paulv wrote:
Tue Oct 30, 2018 10:51 pm
I understand that navigating the legalities for the parts of the system that are still closed source does present a problem at the moment but if the dev community were enabled by having an open source/free to use tool chain I'm pretty sure people would be happy to clean room re-develop those features without the need for bounties and they'd probably get done sooner rather than later as those components are either critical for modern use or just plain useful to RISC OS users in general.
The community is already (and for a long time now) enabled to develop any of the not-yet-open-source parts of the OS. GCC is available. Heck, you can even write your replacement for Resolver or ShareFS with BBC BASIC's assembler. The only necessity for the DDE is if you want to rebuild the whole ROM. If you really want to develop one of the OS modules, most of them are compilable for softloading, and this is (at least theoretically) possible with GCC.

There are so many things that anyone could contribute to the RISC OS community. Writing cool applications. Working on porting existing applications from other OSes. Porting libs from other OSes. Writing documentation. Organizing events.

Saying "but I cannot contribute because I don't like to spend 50 UKP on the DDE" is just nonsense. Yes, there are specific areas of RISC OS you won't be able to contribute. But the probability of being able to understand enough of RISC OS to make a meaningful contribution AND not already having invested in the DDE are - in my opinion - very low. My offer of a free DDE for anyone seriously interested in OS development was taken up exactly one time.

Many ways to contribute were always open for everyone. It didn't happen. My take on it is that no change in licensing and no free DDE will change that in any detectable way.

hubersn

User avatar
paulv
Posts: 3854
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by paulv » Wed Oct 31, 2018 12:00 am

hubersn wrote:
Tue Oct 30, 2018 11:21 pm
The only necessity for the DDE is if you want to rebuild the whole ROM. If you really want to develop one of the OS modules, most of them are compilable for softloading, and this is (at least theoretically) possible with GCC.
Theoretically? OK. I've previously developed a soft loadable module for RISC OS 3.x and below so I know these things can be developed without the DDE but my perception and it seems others too when it comes to getting involved with ROOL is/was that the DDE is/was required. If it weren't a common misunderstanding we wouldn't be talking about it in these terms.

So if I did misunderstand then the reason I think is due to a lack of effective communication that the DDE is not required to get involved in working on the OS.

If all it's needed for is to build the ROMs and a few choice parts of the OS, fair enough but there should be a conspicuous documented ways of developing for RISC OS without the DDE and to be truly inclusive I'd argue that you should be able to do it all without the DDE.

As for your offer for free DDE for serious developers, was that before RISC OS was open sourced? I don't know as I never saw the offer.

If it was though, there were other barriers to getting involved other than the cost which may have affected the take up of your offer, namely the perceived semi toxic community and a licencing model where commercial companies were at least perceived as getting development/developers for free.

These things were a showstopper for many so the move to an Apache licencing model at least reduces the potential for toxicity and removes the licencing barrier now.

At the end of the day though, I think the argument that "if you're going to open source a project, go the whole way" is the way to go to maximise engagement with the community and reduce or remove all the significant barriers to make contribution a no brainer.

Finally, I'd love to see a road map that includes a reasonably detailed migration plan to Git and deals with enabling community engagement as well as the usual development requirements and wishlist/far future aspirations for the OS. A road map for the community as much as for the OS itself. That would be cool.

Paul

User avatar
davidb
Posts: 2413
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by davidb » Wed Oct 31, 2018 12:03 am

hubersn wrote:
Tue Oct 30, 2018 11:21 pm
The community is already (and for a long time now) enabled to develop any of the not-yet-open-source parts of the OS. GCC is available. Heck, you can even write your replacement for Resolver or ShareFS with BBC BASIC's assembler. The only necessity for the DDE is if you want to rebuild the whole ROM. If you really want to develop one of the OS modules, most of them are compilable for softloading, and this is (at least theoretically) possible with GCC.
This is true. However, there wasn't an incentive to replace Resolver or ShareFS before now.
hubersn wrote:
Tue Oct 30, 2018 11:21 pm
There are so many things that anyone could contribute to the RISC OS community. Writing cool applications. Working on porting existing applications from other OSes. Porting libs from other OSes. Writing documentation. Organizing events.
Yet some of these may require improvements to the OS to enable them to be done.
hubersn wrote:
Tue Oct 30, 2018 11:21 pm
Saying "but I cannot contribute because I don't like to spend 50 UKP on the DDE" is just nonsense. Yes, there are specific areas of RISC OS you won't be able to contribute. But the probability of being able to understand enough of RISC OS to make a meaningful contribution AND not already having invested in the DDE are - in my opinion - very low. My offer of a free DDE for anyone seriously interested in OS development was taken up exactly one time.
Some people just won't contribute if it means using a non-free toolchain. It doesn't make it "nonsense". Aside from ideological reasons, people might be used to other toolchains and won't mentally shift gears to use something like the DDE. I wonder if that might have been a factor behind the problems recruiting developers to work on a web browser. So there are probably at least two groups of people who might contribute, but won't.
hubersn wrote:
Tue Oct 30, 2018 11:21 pm
Many ways to contribute were always open for everyone. It didn't happen. My take on it is that no change in licensing and no free DDE will change that in any detectable way.
We'll see. There's not exactly a large pool of developers in the RISC OS scene, though many of those who are active have done some incredible things, but something has to be done if it is going to survive in the long term.

Phlamethrower
Posts: 103
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by Phlamethrower » Wed Oct 31, 2018 12:17 am

paulv wrote:
Tue Oct 30, 2018 10:51 pm
For someone to sponsor a bounty of that size would mean that you'd have to have some sort of viable business model to give you a sizeable ROI that was critical for that bounty to be completed AND be something only RISC OS could do. I can't think of any situation that would make that a long term viable investment opportunity for a sponsor because I can't imagine that there's anything that RISC OS could do any better than a Linux or other open source OS solution for that matter where it would be cheaper to spend £14k on RISC OS and wait for the code to be developed than doing it with those other platforms and probably be able to do it immediately.
I think you're mistaken on how the bounty system works. When someone donates towards a bounty, they can donate as little or as much as they like. So although it would be convenient to have a rich benefactor come along and drop £14K in one go, the reality is that you instead get lots of smaller donations. And over time, if we're lucky, the bounty pot reaches a high enough level to attract a developer.

https://www.riscosopen.org/bounty/
I can't even chase a bounty for recompense because many of them are not funded and if they're not funded, there's a distinct disincentive to work on those areas of requirement.
Developers can claim bounties any time they want. The "guide target" shown on the website is just that: A guide. Some developers will be willing to work for much less than the target, others will only be willing to work for much more. Just like how some developers are willing to pay £50 for the DDE while others aren't.

For a long time ROOL didn't even show the "guide target" value on the website.

I think having the value there is a useful indicator of the size of the task, but I do agree that it could have the negative effect of making developers wait longer before claiming it because it's not hit the peak value yet.

sirbod
Posts: 989
Joined: Mon Apr 09, 2012 8:44 am
Location: Essex
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by sirbod » Wed Oct 31, 2018 6:17 am

hubersn wrote:
Tue Oct 30, 2018 11:21 pm
The only necessity for the DDE is if you want to rebuild the whole ROM. If you really want to develop one of the OS modules, most of them are compilable for softloading, and this is (at least theoretically) possible with GCC.
Do ROOL accept GCC code? I was under the impression OS ROM code must use DDE.

Several factors have put me off contributing to the OS to date:
  1. Cost of maintaining DDE (£25 every update)
  2. The DDE learning curve
  3. Lack of ROOL transparency (I've no idea who they are)
  4. Lack of ROOL community involvement (could be down to point 3, but I'm not sure they get that involved in development requests)
  5. Lack of a one-click download development environment (I don't want to read pages of text and manually download monthly code changes)
  6. No documentation on the OS structure (I spend hours trying to find code when tracking down OS issues)
  7. No (public) documentation on core OS features, such as AMBControl
  8. Even worse in-line code commenting, which in my view is essential for assembler code where the intention isn't always obvious. Coming from BASIC, DDE assembler is also really hard to follow due to the way labels are implemented
  9. No (obvious) way to peer review code and test prior to submission to the main trunk
  10. The futility of adding assembler code (the OS needs rewriting in C)
  11. The bulk of what is currently the "OS" should not be in the ROM if it's going to be modernised, the ROM really needs to be striped down to a light weight kernel with everything else softloaded

User avatar
danielj
Posts: 7317
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by danielj » Wed Oct 31, 2018 8:50 am

hubersn wrote:
Tue Oct 30, 2018 11:21 pm
Saying "but I cannot contribute because I don't like to spend 50 UKP on the DDE" is just nonsense. Yes, there are specific areas of RISC OS you won't be able to contribute. But the probability of being able to understand enough of RISC OS to make a meaningful contribution AND not already having invested in the DDE are - in my opinion - very low. My offer of a free DDE for anyone seriously interested in OS development was taken up exactly one time.
The code, as it stands, is designed to be built with that development environment - in working on developing an understanding what's there, having access to the proper build environment would seem to be rather imperative. I don't understand why people *wouldn't* want people to have access to this in order to further things? If it's possible to use GCC then someone needs to write that bit up and get it in a wiki. The ROOL website is quite explicit that DDE is required:
The /RiscOS/Library directory contains many – but not all – of the binaries and tools required to perform a build. You also require the Desktop Development Environment (DDE) to be installed on your development machine in order to build almost any RISC OS component. The RISC OS source code is tightly aligned with the unique features of the RISC OS build tools supplied in the DDE. Once you have the DDE installed, you can run the “Prepare” program (by double-clicking “Prepare.!Run” in the root of your build tree) to initialise your source tree. This only needs to be done once per source tree. Note: you may need to re-run the Prepare program on any build trees you have after a DDE upgrade to ensure that they are using the latest tools.
With regard to offering to buy the DDE for people "who are serious" - we come back to my comments in the hardware development thread. No one wishes to be beholden to anything, as soon as you accept a copy of the DDE in this context, there's an expectation that you're going to deliver. In my experience that's counter-productive for the majority of people.

There's still this sense of exclusivity around RISCOS, that outsiders "don't get it, don't know enough, aren't committed enough, aren't thinking of doing what we want". Relaxing those attitudes would go a long way to creating an inclusive community (much as you see around the retro-8bit-acorn world), and bring lots of people on board. People will contribute, but it has to be accepted that they'll contribute on their terms. Open it up and see what people create/do.

d.
Last edited by danielj on Wed Oct 31, 2018 8:59 am, edited 1 time in total.

User avatar
vanpeebles
Posts: 579
Joined: Wed Nov 28, 2012 10:01 am
Location: UK
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by vanpeebles » Wed Oct 31, 2018 9:06 am

danielj wrote:
Wed Oct 31, 2018 8:50 am

There's still this sense of exclusivity around RISCOS, that outsiders "don't get it, don't know enough, aren't committed enough, aren't thinking of doing what we want". Relaxing those attitudes would go a long way to creating an inclusive community (much as you see around the retro-8bit-acorn world), and bring lots of people on board. People will contribute, but it has to be accepted that they'll contribute on their terms. Open it up and see what people create/do.

d.
I don't think that will ever change. I've said it before, but I think there is a case for having like a classic/retro riscos community, and the modern one separate. If I could go back, I'd set up a site purely for RO3.1 users with a hobby/retro/gaming slant.

Last year or so, I got given a pandaboard set up, and gave myself the noble task of trying to use it as a daily machine. Within a few hours, the weird email set up, with split settings/software combined with tons of settings, had terrified the life out of me, and I gave up :lol:

User avatar
paulv
Posts: 3854
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by paulv » Wed Oct 31, 2018 10:22 am

Phlamethrower wrote:
Wed Oct 31, 2018 12:17 am
paulv wrote:
Tue Oct 30, 2018 10:51 pm
For someone to sponsor a bounty of that size would mean that you'd have to have some sort of viable business model to give you a sizeable ROI that was critical for that bounty to be completed AND be something only RISC OS could do. I can't think of any situation that would make that a long term viable investment opportunity for a sponsor because I can't imagine that there's anything that RISC OS could do any better than a Linux or other open source OS solution for that matter where it would be cheaper to spend £14k on RISC OS and wait for the code to be developed than doing it with those other platforms and probably be able to do it immediately.
I think you're mistaken on how the bounty system works. When someone donates towards a bounty, they can donate as little or as much as they like. So although it would be convenient to have a rich benefactor come along and drop £14K in one go, the reality is that you instead get lots of smaller donations. And over time, if we're lucky, the bounty pot reaches a high enough level to attract a developer.

https://www.riscosopen.org/bounty/
I do understand the crowd sourced nature of the bounty system, but the implication of "finding corporate sponsors" especially when talking about bounties that are so large seems to give the implication that those sponsors would be expected to stump up the majority if not all of the bounty. As the talk made quite clear, crowd funding for just £2k was incredibly difficult for ROOL so how on earth do they think they're going to raise £14k without a rich benefactor? That was my takeaway from that video.
Phlamethrower wrote:
Wed Oct 31, 2018 12:17 am
I can't even chase a bounty for recompense because many of them are not funded and if they're not funded, there's a distinct disincentive to work on those areas of requirement.
Developers can claim bounties any time they want. The "guide target" shown on the website is just that: A guide. Some developers will be willing to work for much less than the target, others will only be willing to work for much more. Just like how some developers are willing to pay £50 for the DDE while others aren't.

For a long time ROOL didn't even show the "guide target" value on the website.

I think having the value there is a useful indicator of the size of the task, but I do agree that it could have the negative effect of making developers wait longer before claiming it because it's not hit the peak value yet.
I guess that's the point, if the tasks aren't or only part funded, psychologically people will look at it and not bother because of the perception of actual demand for the feature based on the level of sponsorship achieved rather than wanting to maximise their claim. Possibly time limiting the bounty and/or removing the value, replacing it with a team/time estimate would be a better way of doing things.

That sort of estimate would give developers a reasonable estimation of time involved and those that are new to the community would see those figures and realise that their learning curve would mean a longer dev time but it wouldn't stop them choosing to get involved quite as much as seeing a bounty that is part or not funded. Right or wrong, people will use the money as an incentive and as an indicator of popularity of the requirement. People like to do things they get recognition for. The stuff that's just as critical but not as glamorous that can't attract sponsorship then gets left for too long.

Projects could also be graded for the complexity of them so could have a "RISC OS experience" level associated with them. Experience levels of, beginner, intermediate, advanced, expert would help devs choose their entry level to the project too.

Not retaining a place on the Noobs installer platform it seems is a case in point for this, it took one developer one week to complete this work according to the video.

e.g.

Estimates
============

Noobs - 1 developer @ 10hrs a week for 4 weeks (advanced/expert)
project X - 2 developers @ 6hrs a week/each for 3 weeks (intermediate)
project Y - 5 developers @ 10hrs a week/each for 8 weeks (expert)
project Z - 1 developer @ 8hrs for 1 week (beginner)

That doesn't look too scary at all does it? Even for RISC OS newbies that have good hardware experience I suspect Noobs would not be far off that sort of time to implement. The point is, it makes each sub project more accessible before people get involved with hard (but the cool sounding) stuff and give up because they realise they don't have the experience with the OS to do what is required for the more complex tasks.

I can write a simple soft loadable module for 26/32-bit compliance but I wouldn't take on Noobs as I know that I don't have enough experience. I'd probably look at taking on project Z or X as part of a team with a more experienced developer as the lead on project X so I could learn and contribute at the same time. That is after all what the community should be about and as my experience progressed I could take on more complex projects and take on the mentor role for newcomers too.

Paul
Last edited by paulv on Wed Oct 31, 2018 10:35 am, edited 1 time in total.

Phlamethrower
Posts: 103
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by Phlamethrower » Wed Oct 31, 2018 2:03 pm

sirbod wrote:
Wed Oct 31, 2018 6:17 am
hubersn wrote:
Tue Oct 30, 2018 11:21 pm
The only necessity for the DDE is if you want to rebuild the whole ROM. If you really want to develop one of the OS modules, most of them are compilable for softloading, and this is (at least theoretically) possible with GCC.
Do ROOL accept GCC code? I was under the impression OS ROM code must use DDE.
I believe that the DDE is the only toolchain capable of building ROMs. There are a number of reasons for this:
  • Some components rely on DDE-specific features, like the C compilers' enhanced inline assembler. So unless those components are modified, or GCC is modified, a GCC-built ROM won't be able to contain those components.
  • The ROM build process (shared makefiles, !Builder, etc.) is geared around using the DDE. There is nascent support for GCC, but nobody's done the work necessary to make it functional (even if "functional" means that 50% of components fail to build because they rely on DDE specific features, or have funky custom rules in their makefiles)
  • C modules which depend on the shared C library (i.e. all of them) may need some changes to GCC itself in order to be able to support the way which the modules are statically linked to the ROM SCL. But I don't think anyone's done any investigation to find out exactly what work (if any) is needed.
But that doesn't mean that work will be rejected if a developer creates a component which is built using GCC. Only that the component may need modifying to allow it the DDE / ROM build system to be used as an alternate toolchain.

Unless you're using GCC-specific features, the work needed to adapt a component to be buildable using the DDE should be quite small (e.g. no more than an hour) - likely insignificant compared to the tens or hundreds of hours that were spent creating the component in the first place.
Several factors have put me off contributing to the OS to date:
  1. Cost of maintaining DDE (£25 every update)
  2. The DDE learning curve
  3. Lack of ROOL transparency (I've no idea who they are)
  4. Lack of ROOL community involvement (could be down to point 3, but I'm not sure they get that involved in development requests)
  5. Lack of a one-click download development environment (I don't want to read pages of text and manually download monthly code changes)
  6. No documentation on the OS structure (I spend hours trying to find code when tracking down OS issues)
  7. No (public) documentation on core OS features, such as AMBControl
  8. Even worse in-line code commenting, which in my view is essential for assembler code where the intention isn't always obvious. Coming from BASIC, DDE assembler is also really hard to follow due to the way labels are implemented
  9. No (obvious) way to peer review code and test prior to submission to the main trunk
  10. The futility of adding assembler code (the OS needs rewriting in C)
  11. The bulk of what is currently the "OS" should not be in the ROM if it's going to be modernised, the ROM really needs to be striped down to a light weight kernel with everything else softloaded
My response to these kinds of criticisms (in my internal monologue, at least) is usually along the lines of "quit your whining".
  • It is what it is.
  • I managed to find my way around just fine. Before starting work on the OMAP3 port I'd never looked at a single line of OS source, never read the OMAP3 TRM, never read the ARM ARM, never owned the DDE, and had little knowledge of using CVS. And £50 for the DDE was a drop in the ocean compared to the ~£1000 Iyonix that I was doing the development on.
  • It's only going to change if people put the effort in to change it.
  • If you're refusing to change it yourself, then you're probably going to refuse to do any other of the hard/boring bits of work that the OS is in need of. Which makes me think that you're either a hypocrite (promising to do work, but then refusing to do work), or you're just not worth my time (we need people who can tackle the big/hard tasks; people who are only capable of small stuff aren't worth me spending tens/hundreds of hours trying to keep happy, especially if I'm already backed up for several months trying to satisfy requests from other people)
Obviously I try and sugar-coat it a bit more than that in my actual responses to people.

But when people come along and (effectively) demand that we give them the moon on a stick, with the promise/implication that delivering the moon-on-a-stick to them will cause an army of developers to descend from the heavens and solve all of our problems, and then the person making those suggestions keeps making excuses as to why they won't help us create the moon-on-a-stick (or refuses to accept that the moon-on-a-stick is hard for us to create), it's very easy for the conversation to get heated. Especially if it's a very opinionated person who will keep banging on about it because they are RIGHT and we are WRONG, or if opinionated community members object to the specific brand of moon-on-stick that's suggested and start voicing their objections.

User avatar
BigEd
Posts: 2528
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by BigEd » Wed Oct 31, 2018 2:15 pm

It would be great if the contributors to this thread could step back and take a breath. Normally the atmosphere here on StarDot is positive and encouraging. There's no doubt RISC OS has taken a step forward in this relicensing, and it's been possible only because of work: work in getting people to act together in their joint interest. Maybe a more difficult kind of work than the work of writing software.

We all have views on what would constitute a perfect world: let's celebrate a step forward and not focus so much on how it might have been done differently.

Anyone who can step up to help, rather than comment, well, that's great too.

User avatar
davidb
Posts: 2413
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by davidb » Wed Oct 31, 2018 4:05 pm

I think it's worth remembering that most, if not all, of the criticism about barriers to contributing to RISC OS is well-intentioned and coming from people who are sincere about contributing, or who have been interested in the past. People who have easily proved themselves capable at developing software and hardware for ARM-based systems, both old and new. (Not counting myself because I'm very rusty in the ARM programming department.)

I've been more interested in doing small projects with RISC OS since the new version of RPCEmu was released. My projects would initially be based around using alternative toolchains to develop software for RISC OS, so perhaps I wouldn't be bringing much to the table in terms of OS development. I'm probably still more interested in the classic RISC OS systems than the modern ones.

The relicensing of the OS means I'm more interested than I was before, partly because I hope it broadens the horizons of some of the regular users of the OS, but also because it makes the OS more legitimately available to groups who might have experienced legal difficulties with the old license. For example, if we can rebuild versions of the OS for RPC-class systems then it theoretically becomes possible to make packages of RPCEmu for Linux distros that can actually be officially shipped, though the ROMs may still be problematic if it's a requirement that they, too, be buildable using Free tools.

So there are possibilities for everyone, and contributors with different aims will still bring something to the table. :)

Coeus
Posts: 1271
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by Coeus » Wed Oct 31, 2018 6:37 pm

Referring back so an earlier point about whether there is any money to be made from RiscOS, what else is there available for embedded ARM? Which of these are actually used?

I am thinking for example, that our Satellite set top box seems to be running some version of Linux, the last NAS I had ran a version of Linux, our broadband/WiFi router is rumoured to run Linux and our Smart TV presumably has some kind of ARM processor in it and they all have one thing in common - they take ages to start up from cold, worse than the days of the waiting for a radio with thermionic valves to warm up.

Would RiscOS be a better choice for any of these applications? Would it be more lightweight?

I should say I like Linux on both server and desktop but I wonder if it is, at least in part, responsible for the long start up times here. Are the manufacturers of these devices guilty of saying "Why should we buy nutcrackers, when sledgehammers are free?"
Last edited by Coeus on Wed Oct 31, 2018 6:38 pm, edited 1 time in total.

User avatar
simoni
Posts: 472
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by simoni » Wed Oct 31, 2018 6:59 pm

Referring back so an earlier point about whether there is any money to be made from RiscOS, what else is there available for embedded ARM? Which of these are actually used?
Software engineers tend to have a limited view of the business dynamics involved in mass production (or even short-run production) when it comes to cost (in my humble experience of 20 years of working within the field). Start-up time (for example) is not a big factor for devices that are rarely turned off, most are simply placed in warm standby. What is a factor is hardware support (there's a lot more than just an ARM in your set-top box), availability of development resources and long-term support - these are the things that control life-cycle costs.

There's a very good reason why embedded Linux is everywhere and isn't going anywhere. It's almost impossible to come up with any reasonable compelling reason to choose anything else since it's GPL and therefore free and will always be free and almost certainly has support for your application (and is easily expanded if not). I'd seriously doubt that the choice of OS is even really discussed any more other than a passing tick-in-the-box. (note: I discount discussion of RTOS environments here, as it's a different subject and RISC OS is not a RTOS).

Maybe, by some magic, RISC OS develops support for 1% of what Linux already supports - wow, maybe even 10%... then you can kiss those fast start-up times goodbye. 10 PRINT "HELLO WORLD" : 20 GOTO 10 - is super-fast; only trouble is, you can't use it for much.

This is why I continue to repeat the view that the Acorn community (on the whole) just wants to boot an A440/1 or RPC600 and have some fun, as that's the point of retro computing as a hobby; a raspberry Pi is a handy spring board for those getting back into retro too. Support for the latest Dowhapawiddy ARM dev board is of very little interest within the community or commercially outside of it. Make it simple, make it open, make it free and people will slowly but surely invest time from their hobby if you let them (and make it easy and friendly to do so). Rule with an iron fist, treat it as a commercial venture and be sure that you are 'right' and other's opinions are 'moon on a stick' and it will fail. As has been demonstrated over the last x years.
Last edited by simoni on Wed Oct 31, 2018 7:15 pm, edited 1 time in total.

User avatar
BigEd
Posts: 2528
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by BigEd » Wed Oct 31, 2018 7:26 pm

As a counterpoint, there do seem to be viable small businesses attending the RISC OS events, and things like ARM-based RISC OS laptops are likely to be built using small dev boards - sometimes Raspberry flavoured, sometimes not.

(I went so far as to buy a RISC OS Pico SD card, and didn't regret it. That's the extent of my participation in the business, so far.)

Coeus
Posts: 1271
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by Coeus » Wed Oct 31, 2018 8:03 pm

simoni wrote:
Wed Oct 31, 2018 6:59 pm
...Start-up time (for example) is not a big factor for devices that are rarely turned off, most are simply placed in warm standby....
But, of course, things change. We had the best practice around standby power, the suggested 1W limit, and the case of the STB that used 22W fully operational and 19W on standby. That was a particularly bad case because they didn't even bother to spin down the hard disc but other equipment manufacturers were caught on the back foot and found that their standby mode consumed too much power so they had to revert to an almost full shutdown with just an IR receiver on in standby and then boot the OS again when woken up. Obviously time has passed since then and our current STB is quite old so maybe things are better now.

Another case where development effort was saved at the expense of another resource applied to a version of MS Windows we use at work where the assumption had been that hard discs were so big that no-one was ever likely to fill them so there was no business benefit in tidying up after installation, removing old cached files and logs etc. and then suddenly a new range of laptops with SSDs, big problems with running out of space.
simoni wrote:
Wed Oct 31, 2018 6:59 pm
There's a very good reason why embedded Linux is everywhere and isn't going anywhere. It's almost impossible to come up with any reasonable compelling reason to choose anything else since it's GPL and therefore free and will always be free and almost certainly has support for your application (and is easily expanded if not). I'd seriously doubt that the choice of OS is even really discussed any more other than a passing tick-in-the-box. (note: I discount discussion of RTOS environments here, as it's a different subject and RISC OS is not a RTOS).
To play devil's advocate, though, Windows seems to be entrenched in another class of devices: point of sale terminals, ATMs etc. as if using standard PC hardware in these devices necessarily implies Windows, i.e. no consideration is given to anything else in just the same way that ARM would seem to imply Linux. No-one there has decided that GPL code would be an advantage. Is it that the financial services industry just need someone to sue if it goes wrong? Or is it more about critical mass and the fact their developers are all geared up for Windows development for other reasons? Or something else? Sure, the OS license cost is going to be a smaller proportion of the final cost of the unit for an ATM that a commercial OS would be for a broadband router by why pay for something if you can have it for free? Linux supports loads of PC hardware.

User avatar
dgrubb
Posts: 158
Joined: Thu Jun 02, 2016 8:36 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by dgrubb » Wed Oct 31, 2018 8:15 pm

Coeus wrote:
Wed Oct 31, 2018 6:37 pm
Referring back so an earlier point about whether there is any money to be made from RiscOS, what else is there available for embedded ARM? Which of these are actually used?
Mostly Linux, but there are a few interesting edge-cases out there too: BSD, FreeRTOS, ZephyrOS and QNX, off the top of my head. Now that ARM is occupying spaces previously owned by 8-bit uCs I've encountered a surprising amount of application-specific bare-metal code too.
Coeus wrote:
Wed Oct 31, 2018 6:37 pm
Are the manufacturers of these devices guilty of saying "Why should we buy nutcrackers, when sledgehammers are free?"
It's not just the technical merits and cost of the operating system itself but the economics of its ecosystem. Linux is kind of a weird fit in the embedded space (a multi-user desktop/server derivative with very questionable real-time attributes) but it's prolific because, of the options available, it's the one where developers - one of the biggest cost centres of a technical project and whose time is very valuable - will be most likely to already have some experience and familiar tooling available from the get-go.
Last edited by dgrubb on Wed Oct 31, 2018 8:19 pm, edited 1 time in total.

User avatar
simoni
Posts: 472
Joined: Wed May 25, 2016 6:18 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by simoni » Wed Oct 31, 2018 8:18 pm

I'll freely admit that I'm using a broad-sweeping brush by way of exemplification; but the underlying point still stands. Linux and Windows are the two biggest OSs out there and Microsoft is manoeuvring for a bigger slice of the embedded market place - right now they are big in applications requiring a GUI - but they have lost much of their original market share to Linux. I guess, underlying, is the question, would you place RISC OS in the same ballgame as Linux and Windows... Do you really see a product meeting where Linux and Windows are discussed and someone at the back of the room says "hey, but what about RISC OS"? The response would either be "What's a RISC OS"? Or, if you're lucky to have a RISC OS fan in the room "Actually it's pronounced RISC Oh-ess". There would then be a chuckle and the conversation would continue around Linux and Windows.

My real point is that a focus on the actual user base (rather than chasing butterflies) would make answering these "difficult questions" ROOL seems to be able to find, quite easy to do. Time to reset, reboot and move RISC OS forward as a retro hobby OS, because that's what it is. The best way to do that has been repeated countless times in this thread already.

User avatar
dgrubb
Posts: 158
Joined: Thu Jun 02, 2016 8:36 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by dgrubb » Wed Oct 31, 2018 8:25 pm

simoni wrote:
Wed Oct 31, 2018 8:18 pm
I guess, underlying, is the question, would you place RISC OS in the same ballgame as Linux and Windows... Do you really see a product meeting where Linux and Windows are discussed and someone at the back of the room says "hey, but what about RISC OS"?
Yeah, I completely agree with what you're saying. It'd get as far as: "RISC OS? Send over the toolchain, a sample of the reference hardware, the Getting Started guide, any API documentation and we'll get the tech-bods to evaluate it. What's the contact for the FAE who'll support us during bring-up?" *vinyl scratch*

Phlamethrower
Posts: 103
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by Phlamethrower » Wed Oct 31, 2018 9:43 pm

BigEd wrote:
Wed Oct 31, 2018 2:15 pm
It would be great if the contributors to this thread could step back and take a breath. Normally the atmosphere here on StarDot is positive and encouraging.
Apologies if I brought things down a bit. I know I have been part of "the problem" at times, and in the long run that's never likely to work out well for me or the community I'm in. I've been trying to keep myself in check more recently, but in this case I felt it was important to give my side of the story (and I should probably stress that I do agree that many of the issues that Jon listed are valid problems)
simoni wrote:
Wed Oct 31, 2018 8:18 pm
Time to reset, reboot and move RISC OS forward as a retro hobby OS, because that's what it is.
I tend to treat RISC OS as a "modern" hobby OS rather than a "retro" hobby OS. It's something I use and work on as a hobby (I'm not under the illusion that I can get rich from the OS), and my focus tends to be on the following:
  • Making sure the OS can run on hardware which is still being manufactured
  • Making the most of the hardware which the OS runs on (VFP/NEON support, graphics acceleration, multi-core, optimisations, etc.) - this includes both new and old hardware
  • Functional changes to the OS to make software development easier (threading, improved memory management & memory protection, etc.)
So I'm wondering, what would the development focus be for a "retro" hobby OS version of RISC OS? Are they incompatible with the above, or have I misunderstood you and your "retro" hobby OS is actually my "modern" hobby OS?

hubersn
Posts: 136
Joined: Sun Aug 14, 2016 7:59 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by hubersn » Wed Oct 31, 2018 11:53 pm

davidb wrote:
Wed Oct 31, 2018 12:03 am
hubersn wrote:
Tue Oct 30, 2018 11:21 pm
The community is already (and for a long time now) enabled to develop any of the not-yet-open-source parts of the OS. GCC is available. Heck, you can even write your replacement for Resolver or ShareFS with BBC BASIC's assembler. The only necessity for the DDE is if you want to rebuild the whole ROM. If you really want to develop one of the OS modules, most of them are compilable for softloading, and this is (at least theoretically) possible with GCC.
This is true. However, there wasn't an incentive to replace Resolver or ShareFS before now.
There already were lots of incentives. Like fixing a few of the ShareFS bugs (or even providing a solid base for making ShareFS-over-TCP/IP possible and therefore much more relaible than it is nowadays). Or providing an Open Source alternative - many people seem to think that this is an important property of RISC OS, so providing a clean-room implementation of those closed parts would have been very welcome. However, it didn't happen. Despite those two examples being very loosely coupled with the rest of the OS and could have been easily developed with completely open and free tools.
davidb wrote:
Wed Oct 31, 2018 12:03 am
hubersn wrote:
Tue Oct 30, 2018 11:21 pm
There are so many things that anyone could contribute to the RISC OS community. Writing cool applications. Working on porting existing applications from other OSes. Porting libs from other OSes. Writing documentation. Organizing events.
Yet some of these may require improvements to the OS to enable them to be done.
Certainly. But only very very few of them. Why pick the most difficult stuff for your first big project?
davidb wrote:
Wed Oct 31, 2018 12:03 am
hubersn wrote:
Tue Oct 30, 2018 11:21 pm
Saying "but I cannot contribute because I don't like to spend 50 UKP on the DDE" is just nonsense. Yes, there are specific areas of RISC OS you won't be able to contribute. But the probability of being able to understand enough of RISC OS to make a meaningful contribution AND not already having invested in the DDE are - in my opinion - very low. My offer of a free DDE for anyone seriously interested in OS development was taken up exactly one time.
Some people just won't contribute if it means using a non-free toolchain. It doesn't make it "nonsense".
I wrote "cannot", not "want not". This was intentional. And additionally clearly related to the many many things that can be contributed without needing the DDE.
davidb wrote:
Wed Oct 31, 2018 12:03 am
Aside from ideological reasons, people might be used to other toolchains and won't mentally shift gears to use something like the DDE.
Look, I don't deny that there are a lot of stumbling blocks in the world of software (and more specifically OS) development. But it was argued that a freely available DDE would change everything and that the 50 UKP were a major entry barrier. Your argument seems to suggest that for many/some people it wouldn't change anything if the DDE is freely available, because people are not used to it.

So why not start with a project of using GCC for RISC OS OS development? Provide documentation in easy-to-follow HowTos to unlock the potential of those thousands of capable developers just waiting for someone taking the lead. And don't forget that RISC OS GCC also needs a few wizards to do the hard work of maintaining that essential Open Source toolchain. I wonder why nobody volunteered for that job?
davidb wrote:
Wed Oct 31, 2018 12:03 am
I wonder if that might have been a factor behind the problems recruiting developers to work on a web browser.
I have no idea who tried what to recruit developers for a web browser - I don't even know any details about that mythical planned browser. However, there is this NetSurf browser. A fine project, GPL, source code in Git, buildable with GCC. The NetSurf developers are always looking for new contributors. But oh dear - not much interest there either. Where are the "GPL and GCC and Git" friends when you need them.

Anyway, anyone who wants to develop a browser and does not use GCC for its development to make it as easy as possible to reuse the myriads of free libraries available is a bigger optimist than I ever was.
davidb wrote:
Wed Oct 31, 2018 12:03 am
So there are probably at least two groups of people who might contribute, but won't.
So who should change what exactly (and at what cost) to encourage those groups so that they might - or might not - contribute something (what?) in the future?

hubersn

User avatar
davidb
Posts: 2413
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by davidb » Thu Nov 01, 2018 1:16 am

Trying to be constructive here. Skip to the end for the constructive bit...
hubersn wrote:
Wed Oct 31, 2018 11:53 pm
There already were lots of incentives. Like fixing a few of the ShareFS bugs (or even providing a solid base for making ShareFS-over-TCP/IP possible and therefore much more relaible than it is nowadays).
I thought ShareFS was closed. How am I supposed to fix something that is closed in a sustainable way? I'm capable of making binary patches for things, but why should I spend time doing so?
hubersn wrote:
Wed Oct 31, 2018 11:53 pm
Or providing an Open Source alternative - many people seem to think that this is an important property of RISC OS, so providing a clean-room implementation of those closed parts would have been very welcome. However, it didn't happen. Despite those two examples being very loosely coupled with the rest of the OS and could have been easily developed with completely open and free tools.
The incentive is greater now if someone wants a completely open OS with completely open components. That may or may not attract a different kind of developer than those who might have been interested before. From my perspective, I was never interested in reimplementing ShareFS on RISC OS, but I was interested in reimplementing the underlying network protocols to allow interoperability with systems using ShareFS.
hubersn wrote:
Wed Oct 31, 2018 11:53 pm
Look, I don't deny that there are a lot of stumbling blocks in the world of software (and more specifically OS) development. But it was argued that a freely available DDE would change everything and that the 50 UKP were a major entry barrier. Your argument seems to suggest that for many/some people it wouldn't change anything if the DDE is freely available, because people are not used to it.
Both arguments are valid, though I don't think anyone was arguing that it would change everything. There are two barriers: some people won't pay £50 up front plus £25 per upgrade, some people won't adjust to using it. So, perhaps using GCC is the solution, but how socially acceptable is it within the RISC OS community to use it for OS code?
hubersn wrote:
Wed Oct 31, 2018 11:53 pm
I have no idea who tried what to recruit developers for a web browser - I don't even know any details about that mythical planned browser. However, there is this NetSurf browser. A fine project, GPL, source code in Git, buildable with GCC. The NetSurf developers are always looking for new contributors. But oh dear - not much interest there either. Where are the "GPL and GCC and Git" friends when you need them.
NetSurf has serious competition from other browsers and many projects lack contributors. Open sourcing a piece of software and developing it in a public repository is not a silver bullet for that problem. I've seen projects languish because the contributors never came, or because users were happy to free-ride on corporate development. It helps to know the culture around your project and what it would take to encourage contribution. Keeping a project closed isn't necessarily a viable alternative, either.
hubersn wrote:
Wed Oct 31, 2018 11:53 pm
So who should change what exactly (and at what cost) to encourage those groups so that they might - or might not - contribute something (what?) in the future?
The first thing is knowing what you want to achieve. I don't necessarily mean just you, but anyone who wants RISC OS to "improve" in some way. Here are some examples.

If a goal is to keep using the DDE for OS development then it might be beneficial to try and make it open source if it seems like that might attract developers who wouldn't or couldn't use it otherwise. If existing RISC OS developers who are happy to buy a DDE license aren't working on the OS, and if this is something to be encouraged, then I don't know what to suggest. Maybe better tutorials or training.

If a goal is to encourage more people to develop applications then maybe just improving GCC for RISC OS is fine unless the DDE has advantages over GCC on RISC OS. Then maybe we are back to calculating whether opening the DDE is worth it.

If a goal is to improve the operating system in fundamental ways, or make it more maintainable/understandable, or port it to other architectures then perhaps switching to GCC or another compiler might be desirable.

If a goal is to make RISC OS interesting for students of operating systems then it might be difficult to justify keeping the DDE closed if it is needed to work on OS internals. I doubt this is a problem for many people in academia because they have other systems to play with but I thought I would mention it.

The most important thing, however, is to ask people what might encourage them to contribute and to accept that their responses are sincere. That's what has happened in this thread. I'm sure that ROOL and ROD, in order to meet their objectives, made their own calculations about the costs and benefits, and perhaps they should have consulted more widely before making any decisions, but they can always adjust to take feedback into account.

User avatar
flibble
Posts: 698
Joined: Tue Sep 22, 2009 10:29 am
Contact:

Re: RISC OS relicensed: now under Apache 2.0!

Post by flibble » Thu Nov 01, 2018 2:17 am

I can only speak for myself here, but my priorities would be related to software compatibility, modern features on older systems and generally fixing things that got in my way.

In the past these are the things I've considered that I would have investigated further with the toolchain available.
  • Compiling/Assembling up modules for including in my custom RISC OS 3.1 build.
  • Investigating attaching a SWP handler to the undefined instruction vector to implement it in terms on STREX/LDREX, to remove the need for everything to be recompiled for the Raspberry Pi 3.
  • Compiling up an IOMD build without the 'RPCEmu' workarounds, so I could have something to test RPCEmu bugfixes against.
  • And something that came up just today, investigate the differences in the HAL and pre HAL kernel that means that current IOMD ROM doesn't seem to call Portable control to power off the machine on desktop shutdown.

Why haven't I bought the DDE and just got on with this? There's a few reasons,
  • This is the only platform I have to buy dev tools for. What's so special here?
  • Commercial software is meant to be good, the Norcroft suite is barely different than 25 years ago. Certainly in capabilities it is miles behind free tools on other platforms.
  • It seems odd that a platform that places such a value on developer effort for the OS (see the bounties) that it seems to actively discourage new developers from learning how to build and work on the codebase. There is a sense of "we're the best people to work on this, give us money", rather than trying to build an active contributor base.
  • I've so many other projects to work on. Ones that I already have what I need to work with.
but probably the largest is
  • 50 quid is a lot to put down on something 'just for fun' when you're not even sure if you'll be able to do what you intend.
I can't commit to being a 'serious RISC OS developer', I've yet to discover if I can even be an 'occasional RISC OS fiddler'.

Several years ago I attempted to build the RO source tree using the copies of Norcroft I still owned, (Acorn C 5, and the Castle 32bit Compiler (Iyonix era), it went incredibly badly. This experience told me that 'hacking' things together with gcc would be an immense task and it would be a long time duplicating build environment work before I actually did anything that I wanted to achieve.

Phlamethrower wrote:
Wed Oct 31, 2018 9:43 pm
  • Functional changes to the OS to make software development easier (threading, improved memory management & memory protection, etc.)
I want to be really careful here, it's not my place to suggest anything that you do as a hobby in your spare time is anything other than a matter for your own whims

But...

I think the ship might have sailed when it comes to RISC OS software development, it's basically dead. I'm aware of 1 new program released in the last year (and a few updates to existing programs). This isn't where the platform was 20 years ago, 10 years ago, or even 5 years ago, I honestly don't think there's *anything* that you could add to the OS that would actually kick-start any more application development.

And with regards to some of the more fundamental OS changes, more software will break than will ever make use of the new features, and as should be reasonably obvious, no new software is being written to take up the slack.

And to drill that final nail in the coffin, I can see no way (within the realms of reality) that RISC OS can survive the transition to running on ARM CPUs which don't have a 32bit mode, of which within the next 10 years is likely to be most of them. (you can come up with some bluesky thinking about technical ways, pretending that time and effort was no issue, to convert massive swathes of 32 bit assembler, but at the end it's basically a new OS and no existing software would run).
So I'm wondering, what would the development focus be for a "retro" hobby OS version of RISC OS? Are they incompatible with the above, or have I misunderstood you and your "retro" hobby OS is actually my "modern" hobby OS?
Probably the retro one would be adding features and bug fixes to existing hardware, maybe resurrecting the 26-bit kernel support, back-porting as many features to the oldest hardware as was practicable, making rom images easily and legally available so people could use the enormous back catalog of software easily.

But probably the most important thing would be that it wouldn't necessarily have a 'focus', it'd just go where people felt tempted to tinker with today.
Last edited by flibble on Thu Nov 01, 2018 2:23 am, edited 1 time in total.

Post Reply