RISC OS

Selling RISC OS to the general public is always going to be difficult; despite some software developements in the last few years, it still lacks features which have long since been ubiquitous on other platforms - especially what might be termed the big three - Windows (more relevantly, WinXP), Mac OS X and Linux.

What naturally compounds this is the near commodity status of PC hardware. For example, recent sale prices have seen entry level laptops in the United States drop as low as 250 GPB., and desktops even lower. I'm sure that similar pricing will soon follow in the UK. This is clearly an impossible situation for RISC OS hardware to match, and it must continue to trade on its other merits of usability.

The mass-market PC still implies, for the most part, WinXP, with of course the significant niche carved out by Apple, not least helped recently by its attention to style and products like the Mac Mini. But what's interesting is that despite all the noise about Linux, and very real and significant usage in server solutions for Linux (even apart from the traditional Apache et al presense on the internet), 2005 failed to be the prophesied "year of the Linux desktop" - at least, in any meaningful way in the mainstream - and it's still very hard to purchase a PC with Linux preinstalled.

As for RISC OS, it clearly has many problems to overcome before it can really gain any wider appeal. But instead of mentioning those in further detail once again, I'd like to cover a topic I hinted at in a earlier article - a ready to go RISC OS demo.

RISC OS Demo

So how would such a thing work? The major problem with providing something that people are able to download and immediately run on their commodity hardware without messing around with extra downloads, or having to pay anything, is licensing. RedSquirrel went some way towards this, but you still had to locate RISC OS, and put together a boot sequence, etc. Similar comments can be made of the other emulators like ArcEm and Arculator.

To demonstrate the strongest point of RISC OS - its GUI, and the way applications interact with that and other applications instead of the semi-typical monolithic approach - doesn't require the latest and greatest. In fact, RISC OS 3.1 will do fine as long as the emulator has a reasonable amount of memory, and a polished boot sequence, and can take advantage of things like long filenames via a host filing system. It would of course need to be furnished with some applications, and some kind of tutorial to really get people involved. Oh, and did I mention it needs to be really easy to get going?

I previously mentioned Damn Small Linux. This is an appealing model, as it is a single, relatively small download (well, 50MB) and within a few seconds you can unzip it, and be running a windowed fully-featured Linux desktop within Windows.

RISC OS Licensing

As I mentioned, and has been debated much in the past, the problem remains with the legal status of RISC OS ROM images - the rest is entirely possible under freely available RISC OS software and RISC OS hardware emulation software.  In particular, with RISC OS 3.1 ROM images, of which the status of I won't begin to speculate about.  What I can agree with is that their value to RISC OS may be greater if freedom is given to pass them around with impunity.  This would allow completion of such an emulated environment, and put an end to the underhand (not to mention illegal) passing around of RISC OS 3.1 ROM images.  It would also gain some karma points and publicity for any companies involved in making this happen.

As for images of later vesions of RISC OS - particularly RISC OS 3.7, 4 and Select - their legal status is arguably much clearer, and I don't advocate making images available except under existing or new commerical arrangments, especially while they may still have value to the companies involved.

The Components
So, a recap of what would be needed to put this together.

An emulator - ArcEm is perhaps the obvious choice.  It runs on Windows, Linux and Mac OS X already, has active developers and development versions boast a hostfs host filing system.  Its source is available for anyone to hack on, or port to a new system.  It still requires some polish before a release could be done, but this is a matter of time.

Boot sequence and applications - this requires someone to take some time to put together a modern boot sequence, perhaps with various patches to provide features not found in a vanilla RISC OS 3.1 setup.  It also requires a selection of apps - these need to be well-chosen to demonstrate the strong points of RISC OS, and should not be an ad-hoc collection of the "usual suspects".  The files would live on the host filing system, rather than under the restrictions of a RISC OS 3.1 filecore image.

Bundled ROM image - as above, a freely distributable version of a RISC OS ROM, probably 3.1.

Conclusion

I am going to pursue this?  Apart from my interest in ArcEm, not particularly.  Indeed, there isn't a great deal of technical detail here that isn't already being taken care of.  This might be a chance for someone to get off their rear, I as talked about previously. Whilst we're on the topic of emulation, I'd like to correct a recent drobe article on mentioning various emulators.  It mentions that the work by Nick Burrett and myself on RISC OS emulation in QEMU (as contrast to hardware emulators such as ArcEM and VirtualRPC) could be used in ArcEm.  In truth, this makes little sense - the QEMU work was an effort to emulate RISC OS APIs - something that has value, but cannot really provide anything close to a comprehensive emulation environment.  In the scenario in this article, the ROMs provide RISC OS itself, and emulation is of the hardware - a much more practical prospect.  What remains true is that integrating the QEMU engine into ArcEm (which was also used by the referred to project) would greatly improve its speed.

If you do wish to pursue this, then good luck.  If you need some advice, then by all means contact me.

I'm of course referring to the recent article on drobe. I wasn't going to comment on this originally, as I felt it was a somewhat shallow article, intended only to generate some journalistic controversy, without conveying anything particularly new.

However, some of the comments are worth responding to in detail, as there's still a huge gap in understanding by users, especially the most vocal ones, in what's involved in software development. This is despite numerous essays on the topic by myself, and endless demonstrations from various quaters on what does and doesn't work.

And despite Andrew Hill's objections, both NetSurf, and all my projects and several other RISC OS projects use identical development models. I won't go into the details of why - I've mentioned it enough before. But the model is open source, collaborative development, minimising effort by reusing systems. This is something we know works, and works exceptionally well - we only have to look at GNU, BSD and Linux for that. It is no accident that we use the same model, the same tools, the same software and the same libraries. Few other approaches are viable for such large projects in a market with so little cashflow.

Even if we look at Martin's developement of ArtWorks, despite being commerical, it is not so different either - skilled development, building upon years of development, and adding several years more. People seem to forget that NetSurf has now taken around 4 years.

Sadly once again, John Cartmell has insisted he has valid commentary on this subject, despite repeatedly demonstrating he has no authority or experience on things which he tries to demonstrate an opinion. Yes, the repetiion in RISC OS is unfortunate - but it's not the application level at which it is the problem. I refer you to my previous article on this subject. The only thing more discouraging when developing RISC OS software than the technical difficulties involved, are false prophets like Mr Cartmell and a small number of his cronies who actively seek to mislead and and misrepesent the real problems that RISC OS has and the work of the people who really are doing things to solve them.

Let's get real. Software development can be hard. Sometimes really hard, and even if it's easy, sometimes it takes a very long time. RISC OS users are often either unwilling, or unable due to numbers,  to provide sufficient funding for more than a very small number of projects. And RISC OS needs lots and lots of these projects to even be considered seriously by the outside world. Only druck's comments on the article in question reflect the situation in any kind of accurary or detail.

Historical RISC OS development has been short-term hole plugging. That's part of the reason there's so much repetition, and little focus on long-term development. We can partly blame Acorn for that, and partly the rose tinted spectacles worn when we view our "superior" OS, which even persists today.

I've said it before, and I'll say it again, because it bears repeating. Firefox wasn't a single project. It was a collection of related projects - GCC, UnixLib, porting tools, ChoX11, autobuilder - all projects under the above mentioned collaborative development model. Moreover, all projects designed to significantly reduce - I'll say that again: significantly (I'm talking orders of magnitude here) - the effort involved in developing new software, and especially to allow conversion of software from other platforms.

And why? Because that was the most practical way to achieve what users wanted - bringing high profile open source technologies to RISC OS that users are so good at going on and on about.  But not in the short-term way I mention above.  Not in a "port and forget" way that's been traditional of some conversions to RISC OS.  But rather in a way that means that any technologies developed or improved for the port could be reused for new ports, and reduce their "time to market".  And in a way that new versions could be generated very easily, in a predictable, repeatable fashion. 

Ultimately, we can only provide the methods and the means.  The motivation must be there also.  For developers, this means finding some reason to bother continuing - whether it be financial or otherwise.  Certainly it doesn't include putting up with the cronies.  For users this means getting involved and adding something positive to the process.  It doesn't mean the slacktivism that's sadly prevalant in the RISC OS community, where slagging off someone and having a strong but basless opinion is somehow considered a worthy contribution.  I don't mind strong opinions - I really don't.  And even if I disagree with it, I'll respect it as long as it has some kind of justifiable basis that you can point to.

Forget "ransomware" or whatever other term you want to apply.  That's not the point.  RISC OS needs focus.  If there's focus, then funding and the means to bring it about can be found.  At present, RISC OS doesn't have very much focus.  It and its users often don't understand  or can't decide what applications it needs, and even when it can, those answers are naturally reactionary, as it tries to match facilities found in Linux, Windows and Mac OS X.

As for actual development, bear in mind that the number of people able to do significant amounts of it due to time or skill constraints is very small, and isn't going to be replaced very fast if they decide to leave due to a perceived lack of focus, or being fed up with people talking our their arse.  Much of the specific technical work will naturally come from them, but I'll again repeat something I've said many times before.  Get involved.  Find ways to get involved.  There's a greal deal to do that anyone with a little imagination and some free time can do.  One irony is RISC OS users have a significant proportion of those who might in fact be expected to have free time - the retired.  I'll be providing something in the next few weeks which may be one step in this, but  it's really up to the users to  do this.

So, the moral?  RISC OS is in trouble - more than it has been in for some years, and 2005 may have been a peak in appication development unless there's an attitude change.  And that will need to occur first before we can talk about funding software, or development models.

As many of you know, there were a number of personal changes during 2005 for me, not least of which was moving country. What probably won't surprise you is that I now how much less time, and will probably never be able to repeat the time I dedicated to RISC OS last year.

Because of this, I believe changes are in order to try and be fair and equitable, especially to subscribers who continue to support the project, and are not presently getting much for their contribution. From today, I'll be indefinitely extending all existing subscriptions, including a number of unprocessed subscriptions back to the South East show in October, and will not be taking any new subscriptions.

Indeed, since PayPal requires closure and reopening of accounts in order to move country, I'll be cancelling all subscriptions handled through their system and the project address.

The good news is that no subscribers will be expired from the project itself, the mailing list will remain open for support issues, and where possible, development will continue.

It is intended to relaunch the project much later in 2006, and you'll probably see some changes in a lead up to that, as well as addressing a number of the shortcomings that presently exist such as the timeliness of processing subscriptions, along with a less complex (and cheaper) pricing model.

I hope this change is the best way I can be open, honest and fair, whilst remaining realistic about the project. If you have any individual queries about your subscription you can mail unix@chocky.org, and I'll be happy to come to an arangement. The last thing I want is to find the project to find itself in a situation like the Select project, where it has dedicated but frustrated supporters who are not seeing any visible output.

Thanks for your support in 2005.