Reply to thread I would also like to know how Iyonix select would be supported. With RO5 we get first class support from Castle, and frequent upgrades to fix bugs and support new hardware. Would this continue id ROL were responsible for support? I have no experience of ROL support, having never been a Select or RO4 user, so how does this compare with Castle? As I see it there are three ways that Select could come to Iyonix 1. ROL produce a complete ROM image to replace RO5. This way we would lose Castle's support, and may lose some of the functionality that Castle have added to RO5 as well. For a while at least. Also there would be less motivation for Castle to continue to support RO5 for those who didn't buy Select. 2. ROL to develop replacement modules to be softloaded over RO5. Most of the user facing Select functionality could probably be provided this way, but not the RO4 kernel enhancements. Problem is who to go to for support, will it be up to the users to decide which company is responsible for the bugs? I can see endless wrangling, delaying much needed bug fixes and enhancements. There would also be the problems and incompatibilities that having two different sources for the OS components would bring. 3. Castle to take control, pay ROL to add Select functionality to RO5, or alternatively add Select-like functionality themselves, if this is possible without infringing ROLs IPR. This would IMO be the best solution for Iyonix users, but would be I suspect the most expensive development path, and make problems for Castle with little return for them. Castle would face considerable development cost if they were to go that route. If they released the new RO5 for free, the only return they would get is perhaps a few more Iyonix sales. If they charged for the upgrade, some people would not buy it and so Castle would have to support two streams of RO5, with and without Select. At present it is legitimate for Castle to insist on users upgrading to the latest version of RO5, since it is free, before calling for support. If they charged for the upgrade they could not fo this, would need to support both streams, and their support costs and future development costs would be increased. So ISTM Castle would find it hard to justify doing this, and I am not suprised they were happy to unload Merlin onto ROL. mrtd on 11/10/05 2:32PM [ 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 NetSurf bags GBP10K investment from Google Four uni coders lined up to improve web browser  35 comments, latest by tlsa on 24/11/08 4:19PM. Published: 21 Apr 2008 Random article VirtualAcorn drops VAT and prices Oh, ambassador. You spoil us.  18 comments, latest by justice on 22/9/05 2:38PM. Published: 13 Sep 2005 Useful links News and media: Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News Top developers: RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn Dealers: CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster Usergroups: WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be Useful: RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf Non-RISC OS: The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"Most [articles] are unhealthily subjective, biased and increasingly boring rambles from the same few writers. Drobe is a tabloid. And its writers certainly not 'press'"
Page generated in 0.0288 seconds.