Open sourcing RISC OS won't help says ROL

Plus, corporate ID theft threat prompts action

• Paul apologised for the "protracted release of Select 4", adding that Select 4 is built from the same source code as Adjust 32 - which is still being bug fixed and polished off. Hundreds of changes have been checked into the kernel since RISC OS 4.39, according to RISCOS Ltd, who are keen to stress that work is still on-going. Drobe has learnt that version 4.42, as seen running on A9homes, is also now in the hands of RiscPC beta testers with the latest builds dating from August this year. Paul also added to subscribers that the amount of time the volunteer testers are able to give this year is lower than previous years.
• Subscribers who had paid-up subscriptions as of August 30th 2005 will be allowed to download the first Select 4 release, or be posted a CD if they subscribed with that option. They must re-subscribe though to continue receiving updates. Punters who re-subscribed recently will be rewarded with a bonus three month extension.
• Paul revealed that in May 2002, a number of engineers left Pace but continued to provide contracted support of RISC OS to the corporation while developing the Iyonix product for Castle. Paul said the differences between RISC OS 5 and 4 were already noticeable back then, and now the two operating systems are now very different internally. We understand that RISC OS 4 has become particularly modularised with the introduction of its hardware independence, and the way in which the components communicate with each other is significantly different between RISC OS 5 and 4. The current time table for the Iyonix port of Select is: the 32bit version of RISC OS 4 must first be finished, then Select 4 has to be released, and then ROL will look at doing an Iyonix port. Around 120 Iyonix users have expressed an interest directly to ROL, which Paul says isn't enough to convince them that it is a priority.
• An extra 1000 ROM chips have been sourced by ROL for more RISC OS Adjust impressions, bringing the price down to 79 quid including postage for UK users.
• Paul also expressed frustration with Drobe readers who recently called for RISC OS to undergo a 'facelift', despite ROL coming under fire at the launch of the Select scheme for adding what some described as 'purely cosmetic features'. He said: "You can't win, can you?" Meanwhile, other readers called for an overhaul of the riscos.com website.
• Paul alleged that, of the Drobe readers who "regularly complain about
  the lack of RISC OS development", very few of them have apparently bought RISC OS 4 or subscribed to Select.

Discussion

"Open sourcing RISC OS won't help ROL says ROL" - that's the real breaking news here. guestx on 3/9/06 5:38PM [ Reply | Permalink | Report ]

Or Paul was saying that Open Source on all by itself is not a magic solution which is guaranteed to make everything better. My biggest 'regret' with ROL is that I want to buy Select for my Iyonix but ROL do not yet have a product to sell me.... markee174 on 3/9/06 6:28PM [ Reply | Permalink | Report ]

"He added that Castle's wish to open source RISC OS "would have no effect on RISCOS Ltd's products" Well if Castle Open source then this may be the best way to get back to an unforked operating system. Either Open source works and RISCOS Ltd go bust as unable to compete. Or open source fails and Risc OS carries on it merry old weddling way. Sounds like a good solution to me Jwoody on 3/9/06 6:30PM [ Reply | Permalink | Report ]

If Select for Iyonix is something that ROL either can't (due to fundamental kernel differences) or don't ever intend to (for deep-seated personal/political/religious - delete as appropriate - antipathies) do, I wish Paul M would just stand up and say so. Then we Iyonix users could stop worrying about it and just get on with our lives. bucksboy on 3/9/06 7:56PM [ Reply | Permalink | Report ]

In reply to bucksboy: The fact that Paul M hasn't said that Select for Iyonix can't be done (or is not intended) suggests that it may happen. Presumably you wouldn't like him to rule it out just because it is not 100% certain? thesnark on 3/9/06 8:49PM [ Reply | Permalink | Report ]

thesnark: no of course not, but I'm not holding my breath. It still seems extraordinary that ROL puts supplying a (relatively) large and active sector of the market with a demonstrated willingness to spend serious money on RO hardware at the bottom of the priority list. That said, I have no complaints about RO 5.11, which I have found to be noticeably more stable on this Iyonix than Select 4.37 ever was on its predecessor. bucksboy on 3/9/06 9:06PM [ Reply | Permalink | Report ]

I think Pauls point is that for ROL, the Iyonix sector of the market isn't that large. What I mean by that is that the number of people who own an Iyonix /and/ who would buy Select for it is relatively small. Also, FWIW I always found my RiscPC running RO4.39 to be far more stable than my Iyonix ever was running OS5 but I don't take this as any indication of the stability of either Operating system. Having said all that, I now find Windows to be far superior in every way except GUI, to any version of RISC OS. Ok, you can all start foaming at the mouth now fwibbler on 3/9/06 11:01PM [ Reply | Permalink | Report ]

fwibbler: ROL asked for 100 potential names and they got that.... markee174 on 3/9/06 11:40PM [ Reply | Permalink | Report ]

"To develop RISC OS requires customers, developers and cash.", well one out of 3 ain't bad. Keep up the good work Paul, but just remember the customers might go away if Select 4 never appears. flibble on 4/9/06 12:34AM [ Reply | Permalink | Report ]

In reply to markee174: "ROL asked for 100 potential names and they got that...." And oddly enough, now that they have 120 people interested, that isn't enough. It seems that every time they are in danger of getting enough interest to actually have to *do* something about the Iyonix, they just move the goalposts again. I don't care about the personal feuds; I just want a version of Select that I can buy, please -- is that too much to ask? stevef on 4/9/06 1:13AM [ Reply | Permalink | Report ]

Select for the Iyonix: There are probably many out here like myself who have sat back to see what will happen on this front. Depending on what select offers and the price it is set at will determine if I put my hand in my wallet! This could well be the case for many others. Not ideal but until I know exactly what is on offer how can I be expected to commit or express a real interest. The lack of a 'brochure' (electronic will do), in terms understood by the novice, listing what one is likely to get for the money, coupled with the past performance in 'delivery' of 'the goods' will have made many Iyonix users wary or unable to make a decision one way or the other. rmac on 4/9/06 5:04AM [ Reply | Permalink | Report ]

stevef: +1. And the appearance of moving, as far as the user is concerned, towards a single OS.... markee174 on 4/9/06 9:22AM [ Reply | Permalink | Report ]

His comment about facelifting Risc OS and the new "purely cosmetic features" is targetted at two entirely different groups of people (I very strongly suspect), not the same group as implied by his "can't win" comment. Those who complained about cosmetic features were those expecting more from a new OS release i.e. 32-bit, HAL etc. The other group (like myself) recognise that compared to other OS's Risc OS needs a serious uplift. The welcome cosmetic features merely updated the OS from a 1980's look to a 1990's look. We have a decade and half of catch up to go yet if we wish to attract new users. mripley on 4/9/06 9:26AM [ Reply | Permalink | Report ]

Wow, some positive PR for ROL! I must congratulate Paul - his company seems to be slowly but surely digging themselves out of the terrible mess they were in. I'm interested to know how ROL will affect the Open Sourcing of RISC OS though; I would hope they wouldn't cause the OS fork to continue by not cooperating with the Open Source Community. "It still seems extraordinary that ROL puts (Iyonix Select) ...at the bottom of the priority list." The priority list seems fair enough to me. Considering all the furore caused by ROL working on Adjust32 prior to finishing Select 4, I doubt current subscribers would be very impressed if Iyonix Select was released before the 26-bit version. Having all incarnations originating from the same source is also a big step forward. As for facelifting RISC OS, I think functionality should be a higher priority. Yes, RO does need a makeover sooner or later. But what's the good of a smooth new 3D desktop when you can't play a video, browse the web properly or even run the OS on the fastest native machine? People cite the lack of developers - what will get them back is fixing up the backend of the OS. Finding the balance is difficult, but not impossible. timephoenix on 4/9/06 10:27AM [ Reply | Permalink | Report ]

@ stevef: ROL asked for a minimum of 100 interested people to determine the viability of Select for Iyonix. That does mean, that 100 people are also enough to make it a top-priority. JGZimmerle on 4/9/06 12:16PM [ Reply | Permalink | Report ]

Changing the subject, but still related to this article: is it really a good idea to display ROL's bank account details on a public web site? Why make life easier for the people who indulge in identity theft (yesterday's Sunday Times refers). cables on 4/9/06 12:35PM [ Reply | Permalink | Report ]

"No operating system can be developed solely for free." "People have to make money somewhere along the line," These two statements are only loosely connected. Yes the OS developers have to eat, but their food need not come from license fees on the sale of the OS kernel. Linux, and even Apple, have made this abundantly clear. Companies lile ROL can olny survive in their present form if they can find enough punters willing to pay those fees - and as the OS falls behind that is getting harder and harder in a vicious circle. Guess I am saying that ROL is probably doomed. The time for scraping by one a few more promises and the goodwill of the buyer is long gone. What takes its place will have no real revenue stream for a long time - until the OS is fixed. The example of !printers is not a good one. Where is the romance in hacking a printer driver? And why bother when the rest of the OS is broken and you are forbidden to fix it your way? It's just not a priority. At least if RISC OS itself is opened up, it can survive the death of the old guard and maybe, just maybe, will attract some talent. To all RISC OS businesses I would say, if your personal dreams must crash and burn, please don't feel the need to drag our OS down along with them. steelpillow on 4/9/06 1:03PM [ Reply | Permalink | Report ]

@steelpillow: Well said. IMHO RISCOS Ltd is doomed if they do not embrace the open source idea. They would have a good survival chance if they become a distribution-supplier (like SuSE or Redhat for Linux). In the RISC OS market, the users are willing to pay for a well-configured default installation with good end-user documentation, wrapped in a nice package. JGZimmerle on 4/9/06 1:43PM [ Reply | Permalink | Report ]

I don't care what people say about RISC OS Ltd... Adjust is fantastic, and can only wait till I have enough money to bring my other SA up to line with my main one... "Paul alleged that, of the Drobe readers who "regularly complain about the lack of RISC OS development", very few of them have apparently bought RISC OS 4 or subscribed to Select." Trust me, the stability of Adjust, the ShareFS incorporated into it, AND the ability to use samba server stabily has meant that I currently use it as a web server, and can develop it from my other half's laptop. I say buy adjust! :@P timephoenix: its a starting place isn't it... em2ac on 4/9/06 3:11PM [ Reply | Permalink | Report ]

I was just about to make a long comment, but suddenly the thought came up "why? It just isn't worth the effort". Let ROL come up with a working Iyonix Select first. Announcements just before a vacation seem just smokescreens to me. Ike on 4/9/06 3:33PM [ Reply | Permalink | Report ]

'JGZimmerle:' If only. I think the individual desktop market is now too small to support even this. Remember, RedHat and SuSE built themselves from nothing on the back of vibrant kernel development. From what little that leaks out, I get the impression that the main opportunities are now in the embedded STB/smart box market. Selling to OEMs is thus more important than shrinkwrapping. But OEMs are into convergence, standards compliance and security. It is here that Linux is slowly becoming the beast to beat. steelpillow on 4/9/06 4:17PM [ Reply | Permalink | Report ]

wm2ac: Adjust is 2.5 year old Select code, it what is/isn't happening now thats under discussion. ike: I typed in exactly that last night, but couldn't even be bothered to hit submit. druck on 4/9/06 5:51PM [ Reply | Permalink | Report ]

To pick up on Paul's comment that open sourcing Printers+ didn't attract much attention: do I recall correctly that, shortly after it was open sourced, there were comments from well-placed sources that this was illegal? Because that would surely rule out most chances of help from the rest of us: we would have been working on illegal code, with no chance that any of our work could have been released. To my mind, there is still some mileage in open sourcing /some elements/ of RISC OS, such as the CDFS drivers. davehigton on 4/9/06 10:35PM [ Reply | Permalink | Report ]

Cables: In practice it's not letting people know the account details that's the problem - this is done whenever you give someone a cheque, or pay with a debit card, or give a customer your details so they can pay you by BACS or direct transfer or whatever. The link in the above article, while it's described (and titled) as corporate identity theft, actually talks about bog standard phishing from the point of view of the end customer who's bank account details are compromised - it's corporate identity theft from the point of view of the banks etc. Note that the following is pure speculation on my part: This suggests that someone @ ROL fell for a phish email and as a result gave online banking passwords to a scammer. Judging by what the articule talks about (that the banks etc should register all permutations of their domain names) it's likely that the phishermen probably made it very plausible and actually used a domain name that was a legit looking variation on ROL's bank's domain. VinceH on 5/9/06 10:35AM [ Reply | Permalink | Report ]

Isn't the point of open-sourcing parts of riscos5 that there would be no longer a need for Select on the Iyonix? I personally feel that ROLtd has done more wrong than right for the riscos community. First telling the world that they would never 32bit the OS. (which let to many coders leaving the RO scene ) So Castle searches an alternative route: Pace's riscos 5 Then RO Ltd DOES 32bit their fork of the OS and does this in a way that it's even more incompatible with RO5 and to make mathers worse another shared C lib too. People always seem to blame Castle for the OS fork but in thruth only RO ltd seems responsible. You should read the early year reports of RO ltd.( around 1999). A lot of people got always fired and there seemed to be a lot of arguments all the time. Thus a lot of money being wasted! highlandcattle on 5/9/06 12:01PM [ Reply | Permalink | Report ]

In reply to davehigton: I think you better dig out your dictionary and find the definition for the word "illegal". A typical definition would be "prohibited by law". It seems doubtful that there is a law in the UK preventing someone from open sourcing RISC OS !Printers. Open Sourcing RISC OS components might be a "contractual" issue, but it wouldn't be "illegal". VirtualAcorn on 5/9/06 12:06PM [ Reply | Permalink | Report ]

VirtualAcorn: It might be a breach of copyright if you did not have the original rights to release the code under a GPL license. highlandcattle: Going round the houses again does not really achieve anything. We are where we are, so how are we going to get to where would like to be? markee174 on 5/9/06 1:19PM [ Reply | Permalink | Report ]

markee174: By being more careful and perhaps more questioning towards ROL in future. It'll depend on Select 4 and what it does to further RO in practice. In other words, if Select 4 doesn't convince the majority of (ex-)subscribers, then ROL will have probably lost their business. They can start earning back the respect of the community by providing a comprehensive webpage on Select 4, with plenty screenshots and practical examples of its new features in terms most users can understand, ie. no programmer logs. On this page they may also give a better than vague description of what an Iyonix Select might provide. In a later stage, for example after the release of Select 4, they can start rebuilding their website to make it generally more interesting to look at, up-to-date and a place where interested parties can look up what RO is all about - meaning a bit more 'outsider' friendly. hEgelia on 5/9/06 1:34PM [ Reply | Permalink | Report ]

HEgelia: You may not agree with ROL (and I don't always either), but we are not party to their business. They are presumably trying to stay in business and make money. If they disappear all their work (and they have invested a lot of development time) is likely to be lost so they fork will 'disappear' in the worst way. markee174 on 5/9/06 1:43PM [ Reply | Permalink | Report ]

hEgelia: Surely, if RISC OS were to go out of bussiness, surely they would call in an official Reciever to wind the business up. The Recever would try to sell of the company's assets, wsurely that would include its intellectual properties, ie all its work on RISC OS 4. So, it is possible that someone wluld buy ROS 4 to prevent it disappearing forever. Not that I can see RISC OS Ltd going bust any time soon. JWCR on 5/9/06 5:03PM [ Reply | Permalink | Report ]

In the article was the following *gem*>"Paul revealed that in May 2002, a number of engineers left Pace but continued to provide contracted support of RISC OS to the corporation while developing the Iyonix product for Castle. Paul said the differences between RISC OS 5 and 4 were already noticeable back then, and now the two operating systems are now very different internally. We understand that RISC OS 4 has become particularly modularised with the introduction of its hardware independence, and the way in which the components communicate with each other is significantly different between RISC OS 5 and 4." Ok so RO4 Select is more hardware independent. Then it should be a doddle to port to the Iyonix shouldn't it ! Unless of course hardware independance has nothing to do with portability to other hardware (non-sequitur and all that that is). Also the OSes being "very different internally" is irrelevant - when I call OS_WriteC it works because at the API level *both* OSes are the same - if they weren't code for each one would *not* run on the other (or on earlier platforms either). I don't give 1 or 2 hoots *how* either party implement OS_WriteC (or any of the myriad other SWI's) other than they are documented at the API level. That really is *all* that is required. The other point that had me gagging was the !Printers herring of the long wavelength (i.e., RED) variety. ROL could *not* open source *all* of !Printers because they *had not the right to do so*. They *could* (and did) release the bit *they* had rights to (the UI/Front end). The failure of one "partial" OSS release can hardly be used to verify or refute the applicability of a "wholesale" Open Sourcing (or substantial OSS release of RISC OS). AMS on 05/09/06 8:28PM [ Reply | Permalink | Report ]

And even the partial open-sourcing of Printers could be considered a success, as it allowed for better integration of GimpPrint. JGZimmerle on 05/09/06 9:34PM [ Reply | Permalink | Report ]

I have written some P2P software that is protocol independent (ie it is not tied to JXTA, Gnutella, Pastry, etc). However this does not mean that it is a trivial task to make it run using different protocols - I've still got to create a bridge between the software and the protocol implementation. But what it does mean is that if the protocol changes, I don't have to change the P2P software. The same is true for Select being hardware independent - it will still require a bridge to make it work with different hardware. The only difference is that this bridge is independent of the OS, thus allowing Select to be hardware independent and not needing to be changed each time. So to say that it should be a 'doddle' to port to the Iyonix is an understatement, especially if ROL do not have access to Castle's work on their HAL, etc, and have to build this bridge from scratch. Walks on 06/09/06 01:05AM [ Reply | Permalink | Report ]

Julian>I agree completely. Which of course shows how *bogus* the value of trying to link the outcome of one (probably ROL's *only*) foray into Open Source Software. And (arguably) as it has helped with GimpPrint I'd consider it a success too. James>Well yes - but - I think my point was for all the effort ROL claim to have made it hasn't lead to an RO Select release for Iyonix. No doubt ROL will put that down to insufficient interest by punters (surely that's a function of *how much confidence people have in ROL* and that can't be high considering the ever lengthening delay between Select releases) and someone (other than ROL) having to do the difficult legwork of implementing the hardware dependant bits. At every point ROL can argue it's someone else's fault. Which I think it the point of such spin, the truth (however) may lie elsewhere. AMS on 06/09/06 7:59PM [ Reply | Permalink | Report ]

James> Oh and by the way as the original HAL for Iyonix was based on GPL code the source *is* available, so that's pretty much an invalid excuse as well. Castle have also documented (I refer to their web site and the Iyonix TRM) enough of the hardware so that if ROL had a mind to do it that they could implement *even* hardware support for the Iyonix. Doddle may be an overstatement - but to infer that it is *impossible* to implement Select on Iyonix is just as much an overstatement considering the lame excuses often trotted out by ROL to suggest as much (IMHO). AMS on 06/09/06 8:03PM [ Reply | Permalink | Report ]

AMS: "Ok so RO4 Select is more hardware independent. Then it should be a doddle to port to the Iyonix shouldn't it... Also the OSes being "very different internally" is irrelevant" From what I understand of how modern ROS 4 works: It will be easier now to port RISC OS Select to the Iyonix, since the 32bit work is being wrapped up. The stumbling point is the actual hardware drivers. A hardware absraction layer doesn't take away the need for drivers, it merely allows the upper level of the OS to free itself of worrying about what the underlying hardware is doing. Picture it as.. OS <--> HAL <---> drivers <---> hardware. So, for an Iyonix port, ROL will have to produce an Nvidia driver, USB driver, etc that will work with the Iyonix hardware and the OS 4 hardware abstraction. Ideally, RISC OS 4 could reuse the OS 5 driver modules. Except ROL don't know how the OS 5 modules communicate internally and how they collude to pass around information. For example, the OS 5 kernel may expect a particular line of communications to and from the graphics driver (such as a Vsync ticker) and won't work without such a heartbeat. ROL have no way of knowing how the CTL Nvidia or USB modules work with other OS-level components. That's what ROL mean when they talk about differences internally, and it's also what ROL mean when they called for more information and help from CTL for the Iyonix port - the internal design of OS 5 is not documented publically. As you say, the internal workings of the OS will not affect third party programmers, but it's crucial for the OS-level developers. Chris. diomus on 08/09/06 11:38PM [ Reply | Permalink | Report ]

Chris wrote >Ok, but "ROL have no way of knowing how the CTL nVIDIA or USB modules work with other OS-level components. That's what ROL mean when they talk about differences internally". But the point of adstracting the hardware away is *you don't need to know*. If what you say was true PCITv couldn't be done could it? It accesses the Iyonix's innards yet (I presume) has no particular "inside" information on RO5 (nor would it need any other than that which is publically documented anyway). Why can't ROL do the same? I think part of the problem is that ROL wants to replace *all* of RO5 and yet make use of the existing drivers.... It would make *more* sense to port some of the higher level RO Select features across (giving UI enhancements say) accept that the "Utility Module" and key modules will still be RO5's and that the Select modules will have to satisfy themselves with the same level of access as say PCItv has. It may be more stable (for that read *safer*) to leave as much of RO5 in place as possible and modify the modules ROL *do* have control over (the ones they wrote) and modify them to coexist with the RO5 system. To do otherwise, I believe, creates interdependancies and problems that will create a big mess I fear. A If ROL *want* to do a full replacement of RO5 with Select then yes you're right they'd need drivers - but guess what ROL *claim* to write operating systems - so let them. And if that means writing drivers - fine so be it. When you buy Windows (for example) it's chock full of drivers - all written by guess who (yep Microsoft). Why should ROL be able to avoid doing what MS and CTL have done ? In short ROL should either *produce a FULL Select for Iyonix with THEIR OWN DRIVERS* and dispense with RO5 fully OR accept the presence of RO5 and just add UI enhancements and modules that do not expect (not don't use or rely on) low level hardware features. Given that ROL already claim "hardware independance" for their Select that *should* be relatively easy shouldn't it ? AMS on 09/09/06 8:56PM [ Reply | Permalink | Report ]

You need to go back and look at the structure of RISC OS, and understand how operating systems work. There are many layers involved, and not all of them are obvious. This is beyond the published APIs, this is about what goes on underneath the covers. As I understand things: PCITV will talk to the RISC OS 5 PCI module(s) to locate and access the PCITV hardware. Then it's up to the driver as to how the device is controlled. But interrupts and other things are routed from the PCI hardware to the PCITV driver module via the OS 5 kernel and its support modules. It's how these support modules, the OS 5 kernel, and the Iyonix motherboard hardware work together that isn't known to ROL, and (presumably) it's what they need to know in order to get the OS 5 PCI modules to work with their OS 4 kernel and support modules. As is pointed out time and again, a patchwork quilt of RISC OS 4 modules over a OS 5 base is not going to lend itself towards a quality product. And I think ROL agree. Ideally, they want to run an OS 4 kernel and support modules on the Iyonix hardware, and use OS 5 modules to drive the PCI, ethernet and USB. Then things like PCITV will still talk to the OS 5 PCI modules, and the OS 4 kernel can talk to the OS 5 PCI modules. Everything is happy. Anything else has to be a stop gap to please the 120 people who said they were interested in a port. The chip on your shoulder about Castle and ROL is blinding your ability to see this technical issue rationally. I can't really understand what you're on about. Chris. diomus on 09/09/06 9:47PM [ Reply | Permalink | Report ]

Chris wrote>"As is pointed out time and again, a patchwork quilt of RISC OS 4 modules over a OS 5 base is not going to lend itself towards a quality product." Sounds absurd to me - you can't on the one hand claim running RO4 modules over RO5 is bad yet running RO5 modules over RO4 is good - or have I missed something ? AMS on 10/09/06 11:58PM [ Reply | Permalink | Report ]

You are oversimplifying the OS. Taking RO4 Kernel modules and applying them to RO5, is a totally different kettle of fish to taking RO5 hardware modules and applying them to RO4 Walks on 11/09/06 5:50PM [ Reply | Permalink | Report ]

James>I wasn't envisoning using RO4 Kernel modules *at all*, just using the higher level stuff - and keeping the RO5 Kernel and *its* hardware modules. If RO4 *higher level* modules (things like the Draw module) *demand* that an RO4 Kernel be present then that's daft isn't it ? Such high level modules should make *no* assumptions about lower level or kernel stuff and should access all OS functionality via SWI's in the normal way. Those SWI's being of course *documented*. I don't see why to use *Select* you need to dump lower level stuff from RO5 (e.g., the Kernel) in order to use *much* of the Select functionality which appears to be UI enhancements (things that *should not* be accessing lower level stuff at all - except via defined SWI's). It appears to me that ROL are making their life unnecessarily difficult, they should simply take what *can* be readily ported to RO5 (surely *something* must work, eh?) and make that available as a UI upgrade (a bit like Microsofts' Plus packs on some versions of windows). That way ROL make some money (good) while not fashioning a stick to beat themselves with (as would be the case if they tried to re-write the whole OS or shoehorn RO5 hardware modules onto RO4 Select's kernel. What's more people would *expect* it not to have full Select functionality - so that would make the task less difficult - yet give RO5 users a UI "spruce up" - a good thing surely ? What do you think ? AMS on 11/09/06 7:33PM [ Reply | Permalink | Report ]

Some of the comments above seem very strange. An RO4 kernel with RO5 modules obviously presents different issues from the reverse, but only because the RO4 and RO5 kernels and modules differ. The fundamental programming issues underpinning either task are identical - you are porting software from an OS with one kernel to an OS with a different kernel. Parts of each OS are the same, other parts are different. You have to deal with those parts which are used by the software you are porting but differ in interface or behaviour between the OS variants. There is no immediate reason to say that either one would be more stable than the other. Stability would depend principally upon the competence of the engineers performing the work and the relative stability of the kernels. The latter, to the best of my knowledge, has never been tested through anything other than anecdotal reports. adh1003 on 11/09/06 7:39PM [ Reply | Permalink | Report ]

I'm not sure why we are still discussing IYONIX Select. The last Select newsletter made this IMHO very clear. It said the same as PM has said since the release of the IYONIX: ROL will not commit to producing IYONIX Select. But everyone should subscribe to Select of course because this is the only chance of ever getting IYONIX Select. In other words: give us your money, but don't expect to receive anything for it. Just the same as the last few years of Select. I was a big fan of Select when it was announced: sensible ideas, good release schedule, value for money. Unfortunately, since the release of Select 3, there is nothing left of those qualities. The implementation of Adjust32 for the A9 with the help of the money from the Select subscribers was just the final nail in the coffin. hubersn on 11/09/06 10:19PM [ Reply | Permalink | Report ]

In reply to hubersn: I agree completely with what you write and I was a fan of Select and especially the plans and offerings ROL started out with. And I do wonder how much longer users are prepared to put money forward for subscribing to something ROL calls Select - whatever that might be hzn on 17/09/06 10:11AM [ Reply | Permalink | Report ]

I can't imagine that there are many new sales for major RISC OS applications, like ArtWorks, OvationPro, TechWriter, DataPower and Schema2. The people who need these will already have them. So it is probably down to upgrades as an income stream for the suppliers. I wonder if it might make sence to bundle full, one-year-old versions of these with new machines, so that new users get a complete computing solution for an acceptable price. IMHO it is the only way currently open to us to make RISC OS an attractive solution to newcomers. Cut-down versions just don't do it, as the full packages are already way behind compared to other platforms' software in terms of functionality. This way the price for a complete RISC OS solution would come down to acceptable levels. JGZimmerle on 17/09/06 1:37PM [ Reply | Permalink | Report ]

Yeah... Well I emailed ROL 3 times now asking for a price for a RISC OS rom for my risc-PC.... Must have emailed the first time over 5 months ago now. (I tried sending from work and home in case it was somthing to do with my email address). Do you know I havn't had one email in return... So it doesn't look like customers for current products are a priority either... Go figure but tbh if Open source works and it means someone can come up with Risc OS 5 version that will work on my RISC PC and in the future an A9 etc. I will be a very happy chappy. TBH there is only so many times you try and throw your money at a company when you begin to wonder why they don't want to sell a product... Cheers John mrmac on 03/10/06 5:47PM [ Reply | Permalink | Report ]

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

Login

Search this website

This week's poll

Recent developments have left me feeling... Assured ROS will appear on new hardware 55% Pleased OS desktop features are being developed 10% ROL and ROOL will eventually kiss and make up 5% App developments are critical 10% Dave Holden sleeps easy at night 19% Discuss this | Archives

Featured articles

Wakefield 2009 wrap-up, photos and video
The weekend's RISC OS event has been and gone and we've got the rest of our lives to look forward to. Here's a round-up of extra news and Drobe's show-related coverage and some photos taken from Wakefield 2009 - plus a video from the show floor.
 16 comments, latest by AW on 29/4/09 7:41PM. Published: 27 Apr 2009

RISC OS 5 pictured running on ARM Cortex-A8 kit
Picture exclusive - This grainy photograph shows a port of RISC OS 5, sourced from the RISC OS Open project, running on a Beagleboard - a device powered by a 600MHz ARM Cortex-A8 processor with a built-in graphics chip. The port, developed by Jeffrey Lee with help from Uwe Kall and ROOL staff, is seen as a major breakthrough for the shared-source project as it proves the OS can be ported to new hardware without the need for a large team of engineers.
 75 comments, latest by rjek on 30/4/09 3:15PM. Published: 25 Apr 2009

Open documents from Windows-using pals with handy online tool
It can be a pain when someone sends you a file that can only be opened on Windows, Mac OS X or Linux - but with the help of a free-to-use website and NetSurf, Paul Stewart reveals how these documents can be viewed on RISC OS.
 6 comments, latest by AW on 8/5/09 12:12AM. Published: 19 Apr 2009

Useful links