Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Is there a way out of RISC OS version number hell?

Published: 28th Apr 2009, 23:49:33 | Permalink | Printable

With the two streams of RISC OS being developed separately by RISC OS Open and RISCOS Ltd, the version numbering of the operating system's modules needs to be brought back into check as well as ways of allowing software to determine which features are present in any given OS release. ROL and ROOL are said to be cooperating on how to coordinate this and tonight ROOL staffer Andrew Hodgkinson opened the issue to the community to discuss the technicalities.

Click here to visit this news quickie

Previous: RISC OS Open 5.14 now available for free download
Next: Text editor StrongED 4.68 available for download


Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

There is a solution - fork the two versions properly and develop them separately, each with their own version numbering. They are moving away from each other anyway, why bother trying to keep them "compatible"?

 is a RISC OS UserGulli on 29/4/09 9:41AM
[ Reply | Permalink | Report ]

They already have their own version numbering.

"why bother trying to keep them "compatible"?"

So that a single application can work on both (and have some ability to determine whether or not a feature is supported based on more than just a number, which has been reused for different purposes on two branches)

 is a RISC OS Userflibble on 29/4/09 10:40AM
[ Reply | Permalink | Report ]

I meant the question of "compatibility" a bit as rhetorical although your answer was good for those who don't understand the issue at hand.

My point was actually that the two branches have already started breaking away from each other. Some kind of "branch recognision" can then easily end up as a waste of time and energy since it can actually become easier to maintain two separate branches of an application rather than filling the code with all sorts of branch checking to turn a host of features on and off.

 is a RISC OS UserGulli on 29/4/09 1:44PM
[ Reply | Permalink | Report ]

I apologise for my mind going blank there, it was of course supposed to be "branch recognition".

 is a RISC OS UserGulli on 29/4/09 9:10PM
[ Reply | Permalink | Report ]

I have a come here, now and then, for old times sake and this article caught my eye. My immediate reaction to some of the comments was "are you mind numbingly mad". RiscOS has been dying since the OS fork. "Supporting" the continuation of the fork instead of merging it will bring about its death even quicker.

The volume of sales for an application developer is pretty poor as it is. Now you want them to code two different copies?!?! Oh , unless you want them to code for a common module call API in which case nobody needs to develop anything since this was the case prior to the OS fork!!!!!!!!!!!

Get a grip, you are on a suicide trip with a forked OS.......

 is a RISC OS Usermripley on 7/5/09 11:31PM
[ Reply | Permalink | Report ]

I agree that the fork is crazy, but that is the situation we all find ourselves in with RO whether we like it or not. If different decisions had been made several years ago, then perhaps things would have been different...

However, now that ROOL are now progrssing with getting the RO5 branch out in the open available to all to improve, fix and port to other ARM devices, a question soon arises - Will ROL be able to survive against a 'free' version of RO?

There is a very good chance that within a year or two, ROL's income is so low that they simply cannot provide a service any more.

 is a RISC OS Usernx on 8/5/09 10:17AM
[ Reply | Permalink | Report ]

and what then happens when the current RO5 maintainers get bored it and go of to do other more interesting things? You are then left with a dead commercial branch and a stagnant shared source branch. Either way, not good.

 is a RISC OS Usersa110 on 8/5/09 4:32PM
[ Reply | Permalink | Report ]

Maybe the fork itself wasn't the real problem, maybe the fact that everyone kept pretending that the fork didn't exist was the real problem.

 is a RISC OS UserGulli on 8/5/09 11:53AM
[ Reply | Permalink | Report ]

It's a shame you didn't bother to try and understand it Mr Ripley.

"unless you want them to code for a common module call API in which case nobody needs to develop anything since this was the case prior to the OS fork!!!!!!!!!!!"

Even if you do this the VERSION NUMBER of the modules can be different. The required API may be provided by V0.08 of the ROOL module but V1.14 of the ROL one.

Currently it's near impossible to try and get around this. This is what ROOL are trying to fix.

 is a RISC OS UserIvanDobski on 8/5/09 2:37PM
[ Reply | Permalink | Report ]

Even if both strands of OS development were to merge tomorrow, there are still plenty of machines in the field which run older versions. As long as you're trying to target somewhere between 4 and 6, you have a problem, whether you like it or not.

If you charged for upgrades to a merged version (which the business model of ROL would require and, in turn, mandate closing down public access to the source code) then lots of people would not upgrade (it's a hobby / can't justify the cost, etc.).

Even if you managed to make upgrades free, lots of people would fail to upgrade if it was only a softload option. Softloading a ROM knocks out a chunk of at least 4MB of RAM, which on some machines will be too big a price to pay for an OS update. Softloading also makes life very difficult if wanting to use ADFS F+ features from the softloaded OS on a hardware ROM which only supports ADFS F.

Producing a hardware ROM is expensive and again, some people would not upgrade because swapping out ROM chips is a relatively arduous process. Besides, would you offer 32-bit or 26-bit ROMs to people? What about incompatible 26-bit code in podules?

Only if you provided a service which upgraded the hardware ROM of any Risc PC, A7000 or later class machine to merged "RISC OS 7" ROMs completely free of charge including shipping (!), might you have any chance of making a substantial dent into the installed incumbent userbase of versions 4, 5 and 6. You still wouldn't have settled on all-26 or all-32-bit code, since some people on older machines wouldn't want the incompatibility of 32-bit while others would (due to hardware) require it. We then have issues like making RISC OS 6 work on the A9 at all, then merging it with RISC OS 5 and making sure the result is still viable; and so-on, and so-on.

When you step back and look at this mess, you realise that you have no choice but to deal with making your code run across all the different versions and variants around if you want significant market share; but that's a significant share of not very much. On this basis alone, it's little surprise that the number of viable commercial RISC OS applications on sale today is so small.

The split exists, it will always exist historically whatever happens in the future and, given that the milk is long since spilt, it strikes me that the best approach is to make it as easy for application authors to deal with the differences as possible. One facet of this is ease of feature detection and a solution to that is what ROOL, ROL and the community are now discussing.

 is a RISC OS Useradh1003 on 8/5/09 4:44PM
[ Reply | Permalink | Report ]

That's the simplest form of the proposed solution, in essence, by the looks of it - basically there are two features (ROL and ROOL) and a module will only load if it has the right feature i.e. it's designed for the right branch. The currenty method of deciding if modules are compatible just by comparing a version number obviously isn't enough any more, if the branches are incompatible.

I guess this is also a bigger issue for ROOL now since there may well be development versions of the OS popping up here and there. If the granularity of features can be broken down sufficiently, it should give users of those OSes more of a guarantee that they can use module x as it comes, while module y is dependent on a feature which isn't present (or has a new API) in their OS. As Andrew says in his post, 'It's not just about branches'.

 is a RISC OS Userninja on 29/4/09 10:46AM
[ Reply | Permalink | Report ]

To clarify, this isn't about making version numbers the same across the OS branches. It's about making version numbers irrelevant across _any and all_ OS branches and variants by giving code a way to announce and determine specific features, rather than using an assumption of increasing numbers to check features are present at or after a particular version.

A related issue is that of trying to cut through the RISC OS module equivalent of DLL Hell a bit. By giving modules a way of stating a preferred OS branch and letting the OS enumerate a selection of possible candidates to load from disc, it becomes able to choose from this selection in a more intelligent manner than just "the one with the highest version number".

 is a RISC OS Useradh1003 on 29/4/09 10:52AM
[ Reply | Permalink | Report ]

The suggestion was "ROOL" and "ROL" flags, which are, as said, far to similar. I remember when I rejoined Riscos about two years ago, hadn't a bloody clue what was going on with who and what because of things like this.

How about "CASTLE" and "ROLTD"?

 is a RISC OS UserMonty on 29/4/09 11:55AM
[ Reply | Permalink | Report ]

CTL[00] and ROL[00] may be better - I think it's best to fit the identifier into a 32-bit word rather than worry about strings and variable length fields.

 is a RISC OS Useradh1003 on 29/4/09 12:14PM
[ Reply | Permalink | Report ]

Are APIs registered centrally in a similar way to filetypes?

If so, couldn't an approach be based on that?

A system to request availability of an an api (or an individual call) and how the system provides it is up to the system.

 is a RISC OS Userjess on 29/4/09 12:42PM
[ Reply | Permalink | Report ]

APIs are not registered centrally.

 is a RISC OS UserIvanDobski on 29/4/09 3:30PM
[ Reply | Permalink | Report ]

Why not just use 3 extra bits in the 32 bit compatibility flag. eg bit 1234 0000=ROL 0001=ROL 32 bit 0010=CTL 0011=CTL 32 bit 0100=ANOTHER 0101=ANOTHER 32 bit ETC. This gives 8 possible company slots. Or even use more and include target platform/hardware.


 is a RISC OS Usertank on 29/4/09 4:30PM
[ Reply | Permalink | Report ]

You need at least one new bit to be set for all modules supporting this new standard. Other bits could then indicate the branch but the first tells you that it's not just an old (32-bit) module which has a flags word.

 is a RISC OS Userriscosopen on 29/4/09 4:53PM
[ Reply | Permalink | Report ]

That pollutes the flags word. It would become flags plus sundry information, which is _IMHO_ a bit of a hack and bad engineering practice. I reckon it's cleaner to signal the availability of a new header field using a flags bit and keep the header field separate (assuming one subscribes to the overall mechanism in the first place).

It's not like we're that stuck for finding an extra 4 bytes of space on disc or in RAM these days and I doubt an extra cycle or two fetching the additional identifier word is going to hurt very much either, given the frequency with which these kinds of events will occur.

 is a RISC OS Useradh1003 on 29/4/09 6:08PM
[ Reply | Permalink | Report ]

Um, possibly I'll get shot down in flames for this:

How about ROL & ROOL getting together & merging the two branches? Both have worthwhile features to bring to the party and we'd all be better off.

 is a RISC OS UserCharlie on 30/4/09 7:21PM
[ Reply | Permalink | Report ]

Charlie: I could not agree more. Although I accept that there may be some parts that cannot practically be merged again due to low-level incompatibilies, there MUST be many parts that could be merged. RISC-OS can ill-aford duplication of development effort, especially as it leads to user confusion, and application developers only using common OS facilities and rarely the better facilities available in only one branch or the other.

As a user and developer, I don't care what happened before between the main parties: I just want them to start to find *some* common ground where code can be merged. Toolbox, Clib and Basic would be a good start.

PLEASE can some common sense prevail?

 is a RISC OS UserMartinA on 30/4/09 9:02PM
[ Reply | Permalink | Report ]

Right, let's put this one to bed again. Merging the Castle and RISCOS Ltd branches of the RISC OS sources is _impossible_. It's highly impractical from a technical standpoint, but for other, it is simply NOT possible.

Therefor, someone has to show some leadership and make a choice between a number of bad options to try and arrive at the least worst solution. Inaction is not the answer.

 is a RISC OS Userriscosopen on 30/4/09 9:27PM
[ Reply | Permalink | Report ]

Wasn't this part of what you were talking about on Saturday evening with PM? From the bits I heard it sounded as if you are ROL are trying to go forward in some areas to ensure compatibility. I hope you are both able to come to an agreement on this.

 is a RISC OS Usersa110 on 30/4/09 9:46PM
[ Reply | Permalink | Report ]

Yes, RISCOS Ltd and ROOL are often talking about how we can best resolve the problems that users and developers experience at a result of the branched development. That doesn't mean we are able to merge the two source trees back together - we have to think a bit more laterally, but we're pretty confident that there are still going to be ways to tackle these issues.

 is a RISC OS Userriscosopen on 30/4/09 10:34PM
[ Reply | Permalink | Report ]

Forget about ROL, as they aren't really developing their OS anyway. Continue tweaking your [...] version. Both are just as irrelevant. [edited by drobe for legal reasons on 30/4/09]

 is a RISC OS Userimj on 30/4/09 10:07PM
[ Reply | Permalink | Report ]

The comment I made above has been edited by Drobe staff. I did not say "continue tweaking your version". I do not condone ROOL in any way. They complained to drobe and drobe changed the comment to make it look like I was agreeing with ROOL's development. My opinion is, apparently, libellous. And there's me thinking we live in a society with free speech and freedom of expression. It seems we don't. ROOL didn't see fit to question /me/ about this comment however, suggesting they do, after all, just want to paper-over the chequered and questionable heritage of their source code.

 is a RISC OS Userimj on 2/5/09 6:40PM
[ Reply | Permalink | Report ]

We've not lived in that sort of society for some time :-/ Unfortunately, nagging your MP or similar about anything like this will get you no where.

 is a RISC OS Userrjek on 2/5/09 6:59PM
[ Reply | Permalink | Report ]

imj: "The comment I made above has been edited by Drobe staff."

Was the comment really edited without any indication of the edit taking place?

If so, I don't think that's a very sensible thing to do; much better to either delete the whole thing or, better, redact some portion of the message with an indication of why it was done. Best of all would be to leave the comment intact and allow other posters to respond.

Do we have to start digitally signing our comments, now?

 is a RISC OS UserStoppers on 2/5/09 8:33PM
[ Reply | Permalink | Report ]

Oooh, cool idea. Something trivial should be easy to throw together that uses RSA and SHA-256. Although it won't be nice in JavaScript >:)

 is a RISC OS Userrjek on 2/5/09 8:34PM
[ Reply | Permalink | Report ]

Was it edited without indication? Yes. I definitely agree that if it was, as apparently believed, problematic, it should just have been deleted rather than distorting my words. Now, it seems, I'm unable to air my opinion about the heritage of ROOL's source, making their further comments below complete nonsense since nobody can tell what they're referring to as they set the law on drobe to remove said comments. Nice move again, ROOL.

 is a RISC OS Userimj on 3/5/09 10:38AM
[ Reply | Permalink | Report ]

imj>For an OS that you have described (to use your *own* words) as "irrelevant" you sure have a lot to say about it don't you!

Sort of raises questions as to how well disposed (or otherwise) you are towards RISC OS (and either ROL or ROOL) and exactly how helpful one could consider *any* of your comments - let alone the alledgely libellous ones.

I always find it interesting when someone rarely posts except when there's good news and then to make a negative contribution as *you* consistently seem to do.

So what's your favourate OS then imj since RISC OS obviously isn't?

 is a RISC OS UserAMS on 3/5/09 12:10PM
[ Reply | Permalink | Report ]

I use Linux and Windows and OSX and a good slew of embedded OS's. I have no favourite. Each has strengths and weaknesses. RISC OS used to be good, but its dire lack of worthwhile updates and lack of decent hardware to run it on means I don't use it any more. The RiscPC is in the cupboard for historical amusement now, but even freebie RiscPC emulators beat that now.

 is a RISC OS Userimj on 3/5/09 4:32PM
[ Reply | Permalink | Report ]

The OS choices you make are up to you of course.

The thing I find interesting is that you single RISC OS out for a beating round the head every time particularly when a bit of good news occurs - but why? What does this acchieve?

You provide critism - but not in enough detail to allow anyone to address it - nor suggested solutions that (if practical) might improve things - even to a level where *you* might be happy enough to return to using RISC OS (or at least not constantly faulting it).

Critism comes in two flavours - constructive and destructive. It sadly appears yours is of the latter category. The very fact you posted something that may well have been *libellous* in a *short* single damning sentence shows that.

How can damaging the reputations of people who are developing the OS advance anything? How can that possibly address your complaint about RISC OS having a "dire lack of worthwhile updates". You can see that if you drive away developers your complaint will become difficult if not impossible to address?

But then maybe your point is not about fixing RISC OS as much as killing it.

Only you can answer that one.

 is a RISC OS UserAMS on 4/5/09 10:49AM
[ Reply | Permalink | Report ]

I think you're terribly uninformed or perhaps just stupid if you think that after all I've done for RISC OS over all the years of its life could be in any way considered destructive. I think you're just trying to have an argument now. Shoo.

 is a RISC OS Userimj on 4/5/09 1:29PM
[ Reply | Permalink | Report ]

He's not saying anything about RISC OS; he's saying things about the people using it :)

Also, discounting somebody's (educated, involved, and informed, in imj's case, I imagine) simply because what they have to say is not positive is a cheap and meaningless shot.

For the most part, *I* don't feel there's a lot positive to talk about. Wooyay, Tablemate needs a new maintainer. Earth shattering!

 is a RISC OS Userrjek on 3/5/09 8:22PM
[ Reply | Permalink | Report ]

Posting what appatently is libellous material about people is I would say a "cheap and meaningless shot".

I've read what Imj has had to say.

It suggests no solutions.

It does not provide enough information to tackle the problems in RISC OS (and I freely admit there are some problems and they *do* need to be addressed).

It seems to spew out bile against anyone trying to fix the platform (both ROL and ROOL got a clubbing if I recall correctly).

I am not sure what its purpose is but it doesn't look helpful to me.

Now I've not discounted *anything* Imj has said only pointed out that it isn't constructive.

 is a RISC OS UserAMS on 4/5/09 11:24AM
[ Reply | Permalink | Report ]

Before this turns into a storm in a teacup, here's how this all unfolded:

Imj posts a comment while I'm out having dinner, having a drink and watching some terrific comedy - Stewart Francis is hilarious, btw.

I pop back home and find ROOL has reported the comment via the 'report a comment' link. On immediate reflection there is one word in the post that renders Imj's comment potentially libellous. I quickly dive into the database and remove that one offending word while I've got a moment. I go out again and continue my evening in pleasant company.

I wake up the following morning, reply to Imj's email about why the comment had been edited, make a quick post to usenet about PV's websites being (hopefully temporarily) down, briefly glimpse at the drobe.co.uk front page to make sure it's still ticking over and then wait to get a lift to London and spend the night there, getting back again at about 4.30pm on Sunday.

I check drobe.co.uk and find all this. Why am I going over this in such detail (to the best of my memory)? Other than to highlight that this is all done in my free time as a distraction from work and the pub, I want to make the point that there is nothing nefarious going on. There isn't some plot to subversively edit comments. I quickly stopped a problem happening, as a publisher, and then had a weekend away from computers. I'm not in the habit of censoring people randomly or with some kind of hidden agenda. I love free speech.

In hindsight and I thought about it afterwards, I should have marked the comment as being edited (one word taken out) and I do this on the very rare occasions I have to. In this instance I didn't have time but, because Imj's a friend, I didn't think Imj would mind and that he'd understand why I removed the word. I didn't delete the whole comment because the rest of what Imj said was fair comment and I didn't want it all removed just because someone complained.

Part of my day job is spotting legal problems in articles. I'm aware of what can be published and what can't. Here's a quick 101 on libel: everyone is entitled to an opinion. Calling a product 'irrelevant' is fair comment, provided it's an honest opinion. The law is with you on this one. Where the law stops is when an opinion or other statement is expressed when there is no provable factual basis behind it. For example, calling a car dealership owner 'foolish' because his prices are 'outrageously expensive' is fair comment if the cars are expensive in the eyes of a reasonable, right-minded person. Calling that businessman 'a crook' when it can't be proved the guy has done anything unlawful (within the time limits of the Rehabilitation Act) is not fair comment, it isn't simply an opinion - it's an assertion, and is therefore defamatory.

But, yes, in this country you get free speech. You just have to be able to back up your assertions in court if it comes to that. What Imj posted could not be backed up by himself or by me. Under current libel law and contrary to popular belief, website owners /are/ responsible for comments published on their websites even if they are written by third-parties. But under section 1(1) of the Defamation Act, website owners can seek a defence that protects them from writs if a defamatory comment is posted - but only if a website publisher takes "reasonable care" in relation to the publication of comments and was not aware a defamatory statement had been published on a site. If a publisher is alerted to a potentially libellous statement, it must be removed (unless the publisher is willing to support it and keeps it public). That's why the 'report comment' link is there and why Imj's comment was edited.

Am I being over the top? Well, it's not nice being threatened with a libel writ (not that ROOL got anywhere near this point) but Drobe has been threatened in the past and I never want to go there again. There's times when I've stood my ground and times when we've had to accept that something can't be proven true in court. I recently met up with a friend who is a lawyer and he admitted he had once sent a threat of a libel writ to a little parish council newsletter that dared criticise a local yet rich business man, with the additional threat that the church would have to pick up the substantial legal bill. This is reality.

In summary, I'm sorry I didn't mark the comment as edited when I usually do but I was in a rush and, to be honest, didn't think Imj would mind the tweak. I don't agree that I changed the tone of his comment - that his opinion is the two OS streams are 'irrelevant' speaks volumes. I could have just dropped the whole comment but I was uncomfortable with doing that. Also, opinion: fine. Assertions: fine if they can be proved.

Hope this helps. Thanks for commenting on drobe.co.uk articles and polls :)

Chris, drobe editor.

 is a RISC OS Userdiomus on 3/5/09 5:37PM
[ Reply | Permalink | Report ]

Perhaps a solution is to have a flag to quickly make the comment invisible until you have time to study it, rather than editing it with no admission of such. (ie, if you're logged in as an admin, you can hide/unhide comments.)

 is a RISC OS Userrjek on 3/5/09 8:24PM
[ Reply | Permalink | Report ]

I cannot see why merging Basic would be 'highly impractical from a technical viewpoint', so presumably the reason for not doing it must be 'other'. <sigh> But I applaud that you are talking to ROL, and are trying to do something. Don't give up!

 is a RISC OS UserMartinA on 30/4/09 10:51PM
[ Reply | Permalink | Report ]

I'm not saying merging any single component as "highly impractical"; I'm saying merging the lot is. Any yes, the main blocker is other rather than the enormous technical challenge (think of how hard just the Kernel merge would now be).

 is a RISC OS Userriscosopen on 30/4/09 10:57PM
[ Reply | Permalink | Report ]

Thanks for taking my comment seriously...

I wonder: If the OS's are too far apart for genuine merging & the two organisations are collaborating a little might this extend to merging as much as is practicable?

ie: module, by module ROL & ROOL saying to each other: 'hmmm, your's is better than mine, we'll standardise on that one' where functionality is fairly interchangable...

...followed by: 'where it's too much hassle to standardise or rewrite we'll agree to aim @ functional convergence'...

...followed by: 'we'll agree on a standard HAL API' so once there's a HAL for a platform users get to choose what OS they want to run on it.

Would that be a fair compromise that wouldn't be too taxing to implement while reducing many of the difficulties that have sprung up as a result of two branches?

 is a RISC OS UserCharlie on 1/5/09 4:32PM
[ Reply | Permalink | Report ]

Your comment was not only libelous but was actually incorrect by law. Further to that, we at ROOL have 100% confidence that everything we're doing is legal and correct.

We didn't contact you directly because what kind of message would that send? "Back off or we'll set the lawyers on you!" - plus you have no ability to edit or remove your foolish statement.

So we reported it. That is what the "Report" mechanism is for, after all. Problem solved; you're no longer breaking the law or making false claims about myself and my colleagues.

I don't believe the Drobe edit (over which we had no control) changes the meaning of your statement much; it still says you think our unpaid efforts over the past few years are "irrelevant". We have no objection to you voicing that kind of opinion - that is the point of free speach.

 is a RISC OS Userriscosopen on 2/5/09 9:09PM
[ Reply | Permalink | Report ]

Forgive me for asking; Maybe it's me being dumb. Is there a way of making it more obvious who's replying to what message in these threads?

The reason I ask is at first glance it looked to me like riscosopen's obviously upset reply was aimed @ my last comment. (especially as the reply found its way into my email) I couldn't for the life of me understand how my last post could possibly deserve such a response... ...reading further up the thread I guess it was actually in reply to another (edited) comment.

I came fairly close to firing back an equally upset response which may not have helped the general 'karma' round here.


 is a RISC OS UserCharlie on 3/5/09 12:18AM
[ Reply | Permalink | Report ]

Use the threaded view, and hope people don't click on the wrong "Reply" link?

 is a RISC OS Userrjek on 3/5/09 12:32AM
[ Reply | Permalink | Report ]

Yes, my fault... I forgot I wasn't viewing in the threaded view.

 is a RISC OS Userriscosopen on 3/5/09 2:31AM
[ Reply | Permalink | Report ]


Hey, easily done. Glad it wasn't me that upset you.

FWIW: Fantasticwork with RO5, I look forward to future developments.

 is a RISC OS UserCharlie on 3/5/09 12:25PM
[ Reply | Permalink | Report ]

Just get this discussion back on topic... I wish there was a way out of "This version Hell" As a user, admittedly using VA, I have RISC OS Adjust 4.39. Can I safely use the updates produced by ROOL? all of them? some of them? which? Or as I perceive they are only for Iyonx users?

Some guidance from someone would be helpful and neither the ROOL site or the ROL site are much help in this respect!

 is a RISC OS UserMart on 4/5/09 3:27PM
[ Reply | Permalink | Report ]

I thought we WERE on topic :-) As I see it the fighting factions in this frankly miniscule OS war have such contrary positions and such different levels of investment (in terms of both time and folding) that a coming together is pointless, meaningless and basically very unlikely. Either stick completely with the variant with the archaic features bolted on a HAL on modern hardware, or the unarguably greatly more developed version on old dead hardware. Don't attempt to marry the two together as it's of no benefit. The real solution is to begin bringing pieces of one OS in to the other -- I absolutely do not buy the "impossible" notion from Mr Revill, at a technical level - only at a business level.

 is a RISC OS Userimj on 4/5/09 6:15PM
[ Reply | Permalink | Report ]

Before attributing quotes to me, please reread what I said so you can at least get them right. I have said it is "impossible" not on technical grounds, but on other grounds. I have also stated it is "highly impractical" on technical grounds.

 is a RISC OS Userriscosopen on 4/5/09 8:49PM
[ Reply | Permalink | Report ]

And I've stated it's not impossible. :-)

 is a RISC OS Userimj on 4/5/09 9:25PM
[ Reply | Permalink | Report ]

Either stick completely with the variant with the archaic features bolted on a HAL on modern hardware, or the unarguably greatly more developed version on old dead hardware.

'greatly more developed version' (in my experience of system development) does not always mean better.

I think for many people the prospect of RO5 running on one of the up and coming generation of Cortex-A8 based netbooks is far more exciting than the possibility of bunging a Vpod in their now disused RiscPC (witness over 10000 views on the ROOL forum thread 'Let's get started with a Pandora port'). Regards Stan

 is a RISC OS Userblahsnr on 8/5/09 10:54AM
[ Reply | Permalink | Report ]

The problem is that there's no clear answer to your question. It would take a long time to work out which modules/applications you could load and would work and, of course, to work out whether or not you'd actually be gaining or losing functionality in so doing.

To a degree, the question you ask is one of the things which the proposals on the ROOL site are trying to answer from a technical standpoint. The software itself - "software" being anything from complex applications to individual modules beneath - determines if the underlying collection of ROM and !Boot contents are capable of supporting its requirements and only runs if so.

Doesn't tell you if you'll get any advantage from running something but at least it might help prevent people hosing their systems by loading a ROOL component on a ROL release when it won't work, or vice versa.

 is a RISC OS Useradh1003 on 4/5/09 6:21PM
[ Reply | Permalink | Report ]

So in essence the ROOL software is Iyonx only unless it states otherwise. So for 80%? of the RISC OS market ROOL has no relevence.

Even if the foregoing is a simplistic statement and "some" of the ROOL software is usable on non-Iyonyx systems there are only a few clues as to any functionality improvements that may make it worth taking the risc [sic] of potentially hosing your system.

I apologise for what appears to be a ROOL bashing exercise - that was not intended. I applaud those people who are able to do this kind of work but weep when all these manhours are wasted for want of clear, meaningful guidance.

 is a RISC OS UserMart on 4/5/09 7:48PM
[ Reply | Permalink | Report ]

ROOL's work currently may work with only Iyonix machines, but part of the ROOL strategy is to have one stream of RISC OS across all machines (that includes Risc PC's).

No work at ROOL is being wasted. You simply cannot use the fruits of their labour... yet!

I agree with you though - ROOL and all contributors deserve lots of kudos for their work.

 is a RISC OS Usernx on 4/5/09 10:55PM
[ Reply | Permalink | Report ]

As the ROOL work offers the possibility of getting RISC OS on newer hardware, it has relevance to all users.

I would be willing to sacrifice some OS features to be able to use newer, faster hardware.

 is a RISC OS Userhelpful on 5/5/09 1:40AM
[ Reply | Permalink | Report ]

"So in essence the ROOL software is Iyonx only unless it states otherwise. So for 80%? of the RISC OS market ROOL has no relevence."

How on Earth did you get that idea from the comment to which you are replying?

"Even if the foregoing is a simplistic statement and "some" of the ROOL software is usable on non-Iyonyx systems there are only a few clues as to any functionality improvements [...]"

Functionality improvements over what?

"[...] weep when all these manhours are wasted for want of clear, meaningful guidance."

Since our main focus up to and including right now is just to make the source code to the RISC OS 5 branch of RISC OS available to the general public, I'm not sure what you mean here either.

 is a RISC OS Useradh1003 on 5/5/09 9:16PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • An introduction to IP networks
    Part one of masking the 'net
     10 comments, latest by Umair on 9/9/04 10:11PM. Published: 4 Sep 2004

  • Random article

  • RISC OS Ltd. update toolbox modules for future ARMs

     Discuss this. Published: 22 Mar 2001

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "I used RISC OS and all I got was this lousy emulator"
    Page generated in 0.4188 seconds.