Castle and ROS Open reveal plans for 2007

Published: 20th Jan 2007, 13:28:04 | Permalink | Printable

Vetoes non-ARM port, will release Javascript Browse, and more

On Monday night, Castle and RISC OS Open popped down to SE1 London to chat to users about their shared source plans - although the only source we could find that night was the sauce in our curry afterwards.

To be fair, ROOL's Steve Revill said he had at least some of the RISC OS 5 blueprints on his Microsoft Windows laptop, neatly and aptly tucked away in an Acorn-badged carry bag. However, he had to scoot to catch his train back to Cambridge before any of it could be revealed as a small gaggle of coders began encircling him at the end of the evening. One even brandished a camera, ready to take snaps of any code like a war time spy taking copies of military plans on microfilm.

Castle's Jack Lillingston opened the presentation with a brief run through of his company's products before outlining the shared source initiative - which is designed to get the source code to RISC OS 5 out into the open for free, and encourage third party developers to improve it. Steve then took over to explain more about how the project will be organised, and how they need donations to keep going.

Summary
In short, the following points were raised during the talk.

RISC OS Open are using the source to RISC OS 5.12 as a base. They said it will take 12 months to get all of it released.
If you change the source and redistribute your efforts for free, you must make your modifications public, and allow Castle to merge it with their source code. If you redistribute the OS for commercial purposes, you must pay a royalty fee but you don't have to publish your source code to anyone.
Effectively, work that you do must be made available for all, unless you pay to keep it closed.
Changes handed to Castle will be fed to RISC OS Open, who will appraise and QA source code updates. If the patches are then accepted into the ROOL repository, it will become part of the next ROM build.
ROOL said they will produce periodic RISC OS 5 ROM builds for punters to download from the website and use them to upgrade their computers.
Castle has vetoed non-ARM ports. They said they want to focus development work on ARM-powered systems only, and developers will be banned from porting the operating system to another architecture.
The first components to be released under the shared source initiative will include the 'ROM applications', such as Paint and Edit, the printing system, the font manager module, and a Javascript-enabled version of Browse codenamed Phoenix.
Developers must equip themselves with the Norcroft C/C++ compiler toolkit, available from Castle, to build the operating system. ROOL said they were not against people using the GCCSDK, but any changes submitted must not be incompatible with Norcy.

Jack spoke briefly about RISC OS 5.12, which punters have to pay for - unlike previous Castle point releases. He also mentioned that Iyonix Ltd, a separate company run by himself and his fellow Castle director John Ballance, now resells Iyonix hardware.

He said: "RISC OS 5.12 is a culmination of four years of RISC OS 5 releases. Unless you have RISC OS 5.12, you won't be able to move on any further. It provides a good bed rock for further development.

"It supports a wide range of GeForce graphics cards, which gives you much higher screen resolutions and refresh rates and the start of access to the DVI output - this isn't supplied right now, but it will come. We've also put USB 2 support into the FlashROM and this speeds up the boot-up sequence."

He also added that RISC OS-powered set top boxes have outsold RISC OS desktop computers over the years. The STB kit has been shipped as far as North America and Asia, according to Jack.

Shopping for an OS
Moving onto the shared source plans, Jack said it is hoped people can download the source code and pay up front for royalties via a website. It removes the administrative burden of having to do deals and sign contracts with firms and individuals - they want to make it as easy, and therefore as cost effective, as possible, just like buying music from iTMS at 79 pence a pop. Plus, a website is open 24/7, which is handy if you're pushing the product to organisations on the other side of the world.

Jack said: "Castle own RISC OS, but RISC OS Open will be responsible for the shared source initiative. RISC OS is going to be made available through the world wide web, rather than doing a deal with people individually.

RISC OS Open cog logo

"Users are to have direct access to all the RISC OS sources, although it's not aimed at just RISC OS users; we want people through out the world to use it, particularly users in the Far East. We hope the community will grow and grow as others find out what RISC OS is all about.

"It will be easier to take RISC OS over to the Far East, and explain all the useful stuff that the operating system can do, and show them the pedigree of the system, answer their questions, and raise the profile of RISC OS. This is one way to get RISC OS more widely used.

"There's some set top box stuff that can never be published under our shared source licence, but there will be enough to build an Iyonix ROM. Modifying it to build a VirtualRiscPC or RiscPC ROM should be possible too."

Fig leaf to ROL
He added: "What we're doing shouldn't impinge on what RISCOS Ltd are doing. They are the experts at developing and moving on desktop RISC OS. We don't want, and are trying to avoid, duplication of their work. We've effectively provided them access to our sources. I have a lot of respect for [ROL boss] Paul Middleton, who has done a lot of good work in a difficult job. We've disagreed about things, but that's usual in business."

Jack avoided answering a query from the floor as to whether or not RISCOS Ltd's licence to redistribute and develop RISC OS is time limited and due to expire. Jack said: "I don't want to discuss other people's licences."

Open source advocates have often asked why Castle didn't opt for an existing and true open source licence for the project. Jack explained that it was essential that Castle retained overall control over their operating system.

He said: "We looked at using the GPL in great deal, and we had to select and modify it a lot to suit us and the situation we are in. We do need to protect our intellectual property, and have a degree of control over it. Our approach is to make the license flexible, and the controls in place can be relaxed if we feel this is necessary in future."

He also acknowledged that RISC OS 5 could somewhat fork into different favours, like GNU/Linux more or less quickly did, but said said he hoped "we can move it as one lump forward, and not have bits and pieces spread out everywhere."

Grey areas
The main road block with their custom licence at the moment is defining, in legal terms, the point when redistribution of RISC OS 5 becomes commercial. This is why, we're told, the licence is being batted back and forth between Castle and its lawyers. For instance, selling a CD with RISC OS 5 on it is clearly a commercial product, but someone could in theory give away said CD for free, but charge people separately for support and documentation - thus avoiding paying a royalty to Castle.

Jack said: "It's very difficult to define. There are grey areas of providing a service and the source code separately. We've had to look at past cases, and that's clearly been the main difficulty in defining what is and what isn't commercial. Basically, if you make money from RISC OS 5, then it's commercial, in my opinion."

Another rule in the licence will be to block coders from porting the operating system to another architecture, such as the Intel x86 compatible world.

Jack said: "There will be a restriction to make development work ARM-only. We also don't have a problem with emulation, provided it's emulating an ARM-powered system. It would take a huge effort to move to a new platform, and we feel it's best if they spent their efforts on something other than porting the OS to another architecture.

"We might change that clause, but not right now."

ROOL's Steve Revill said his organisation was being run by ex-Acorn, ex-Pace and ex-Tematic engineers in their spare time, and required the help of volunteers to help moderate source code submissions and donations from users. He also feared each download of a RISC OS source code batch could cost him up to a quid in bandwidth fees. Jack also mentioned that some of the money from RISC OS 5 royalties will be pumped back into RISC OS Open Ltd.

Steve said: "We rely on public donations to pay for our running costs. We aim to put Castle's sources on our website, and hopefully keep everything together in the same place. The source is specific to the Acorn C/C++ compiler, although we don't have anything against people using the GNU tools provided their changes don't break the source code with Norcroft.

"We want to offer enough source code to allow people to put RISC OS into a new computer. We also want people to use the RISC OS Open website to report faults and bugs into the online fault database, and use the forums to make suggestions, and talk about feature requests.

"There will be a team of moderators who will look at the source code changes submitted by developers, decide if it's good enough to go into our repository, and plug it in.

"The source code is 2GB in size, and it's hard work going through it all to check that it's code we can release, and remove the swear words from it. I did have a top 20 list of swearing in the source, but I don't think I'll be making that publicly available.

"There's only one or two of us doing this on a part-time basis, so volunteers are welcome. It will take us 12 months to release RISC OS 5.12 in full."

We also heard that commercial releases of RISC OS 5 from Castle, such as RISC OS 5.13, are likely to be fed back to RISC OS Open - but the shared source repository is expected to lag behind Castle's commercial releases by several months. Andrew Hodgkinson has also been working away at Browse in his spare time for years, we were told, and the web browser is expected to be released in the first source code batch.

Steve said they would move BSD-licenced code out of the RISC OS 5 tree and into a separate repository. He is on the look out for GPL-licensed code, which would also need to be removed, but admitted that it is difficult to know whether or not code checked in by a developer years ago came from a GPLed project.

He added that he felt that if people want to re-implement features found in RISC OS 4 and 6, they are more than welcome.

He said: "If people want to add RISC OS Adjust features to RISC OS 5, then go for it."

Fears
It was pointed out that Apple open sourced parts of its Mac OS X operating system, namely the underlying kernel level, first under a restrictive licence, and later using a more liberal one. However, they failed to see any significant take up from the developer community. As one punter from the floor put it: "RISC OS is a damn sight more healthy than other niche platforms, but with all these controls in place, why should we do Castle's work for free?"

Jack said: "If we were to open source RISC OS 5 under the GPL, the STB manufacturers would walk away. They want to keep their changes secret, and not have to hand it over to competitors. If someone in the Far East wants to do something wizard with RISC OS, we shouldn't stop them."

He also said that people who contribute to the source code could get discounts on royalty payments, as will companies who sell RISC OS-powered units in bulk.

Jack added: "It's a fair and reasonable licence, and encourages people to contribute as much as it can. I don't think Castle can do any more than that."

Links

RISC OS Open website RISC OS usergroup of London website

Previous: RISC OS Open licence in hands of lawyers
Next: Programming tools set for price slash

Discussion

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

Sounds like a bunch of people who don't get dual licensing despite there being a number of companies doing it rather successfully. Anyway, here's an interesting bit:

"He is on the look out for GPL-licensed code, which would also need to be removed"

So when Castle talk about protecting their "intellectual property", what they mean is stuff which includes other people's code they've also passed off as their own, violating the licence in doing so.

guestx on 20/1/07 3:37PM
[ Reply | Permalink | Report ]

This is potentially very good news, and I hope it succeeds. I reckon this is RISC OS's last throw of the dice. I'd be happy to contribute financially, but only once there's source on the website and the process has kicked-off. It's a shame there still isn't a clear timetable for the release of the first batch: I appreciate the legal difficulties and the limited time of the active developers, but some firm commitments on timing would encourage more support, IMHO.

Getting the apps out first seems sensible: the printer manager in particular would benefit from some work on Unicode. I hope, however, that Browse does not distract development from NetSurf. There are so few applications developed at the moment that duplication is the last thing we need. Hopefully the technologies in Browse (inc Javascript) can eventually benefit NetSurf, which seems to have an update every week at the moment.

Should open-source RISC OS ever make it to my A9, I'd definitely use it...

lym on 20/1/07 3:40PM
[ Reply | Permalink | Report ]

wonder if thats my pint glass in the photo?

epistaxsis on 20/1/07 3:40PM
[ Reply | Permalink | Report ]

Thanks for this good news!

Offering Phoenix (i.e. Javascript capable 32bit Browse) is very good. Perhaps as time passes by NetSurf and Phoenix can kind of grow into one browser, or as lym suggested, perhaps some of the good parts of Phoenix like the Javascript can be included into NetSurf.

hzn on 20/1/07 4:32PM
[ Reply | Permalink | Report ]

GuestX wrote>"So when Castle talk about protecting their intellectual property, what they mean is stuff which includes other people's code they've also passed off as their own, violating the licence in doing so.

With respect that is to misread the piece - there is (to quote) 2GB of code the fact they are combing it to make sure there *is* no GPL code there is a good thing I would have thought. Additionally you have no way of knowing *when* (if any) GPL code was included was it (a). When Acorn had it (in which case ROL's version may also be "poisoned" in the same way) (b). When Pace had it or (c). When Castle had it.

Anyway overall the release sounds like a good plan and hopefully it will proceed as soon as is practicable.

AMS on 20/1/07 4:45PM
[ Reply | Permalink | Report ]

On merging Browse/Phoenix and NetSurf -

1) Read this [link] 2) If the licences are even remotely compatible, I'll be extremely surprised.

jmb on 20/1/07 4:59PM
[ Reply | Permalink | Report ]

Looks like interesting times ahead and it is good news about Set Top Boxes selling worldwide with RISC OS in them, hopefully some of that will filter down to the desktop users as well.

Revin Kevin on 20/1/07 5:00PM
[ Reply | Permalink | Report ]

Whatever happened to the speech recognition that Acorn were showing off with their STBs? The ones that were supposed to play MPEG2 video etc?

tweety on 20/1/07 9:53PM
[ Reply | Permalink | Report ]

The hardware that RISC OS runs on is boring. It is slow and out of date. A port to a different architecture (x86) would open up access to faster, cheaper, hardware and renew interest in developing support for much needed features like DVD playback.

VisitorQ on 20/1/07 10:36PM
[ Reply | Permalink | Report ]

Until we actually *SEE* even a draft of the licence, we can't say how the limitation on porting effects it. I think it's foolish, anyway - if somebody wants to try, let them. It'll be their wasted effort. However, parts of the OS that are written in C could be almost automatically rebuilt for x86 with the right rig in order to massively speed up emulation. For example, the SharedCLibrary could be executed on the host side. Same with lots of other modules that are written in C. Stopping people from porting it away from ARM removes the possibility of somebody doing this neat hack to considerably increase emulation performance.

rjek on 20/1/07 11:20PM
[ Reply | Permalink | Report ]

Yes and that would reduce RISC OS I'm of no doubt to little more than an emulation "toy". Thankyou Castle.

AW on 20/1/07 11:54PM
[ Reply | Permalink | Report ]

AW>Agreed. If there is a comprehensive limitation of the OS to ARM (or code compatible processors like xScale) that's fine. While it's Castle's decission - the ban on x86 (or other) porting makes sense - simply making it *easier* to emulate/port RISC OS would I feel damage the RISC OS platform. To people who are already x86 fans or Windows/Apple/Linux devotees I expect that argument won't hold much water but then they've no emotional (or practical) need to see our platform survive and such attitudes should not therefore surprise us. They do what best pleases or suits them (fair enough) but the thing is if we enable porting *we* (the RISC OS users) will IMHO lose out. The others will still have their platform to return to while we will not.

VisitorQ>"A port to a different architecture (x86) would open up access to faster, cheaper, hardware and renew interest in developing support for much needed features like DVD playback."

Why?

Surely if you have an x86 machine you'd simply fireup one of the many capable DVD software players that already exist there - why bother with the extra hassle (especially as the DVD player would only work on the x86 RISC OS variant and not the native ARM one). Nope a non-runner I think.

AMS on 21/1/07 12:17AM
[ Reply | Permalink | Report ]

AW: I can't decide if you're pointlessly trolling, or if you actually believe that. It won't reduce RISC OS to an emulation "toy" at all. It'll simply speed things up where it is emulated. It won't damage native use at all, apart from the fact that emulation will be even quicker and cheaper, not to mention less buggy, as you'll suddenly be able to use UNIX's and Windows's far more advanced debugging facilities.

rjek on 21/1/07 12:18AM
[ Reply | Permalink | Report ]

RO as a desktop platform is just a toy now, we need to migrate to other CPUs and IMHO the way to do this is to gradually recompile and reimplement bits of RISC OS for other architectures, running the bits that have not yet been migrated under emulation along with the applications that have not been rebuilt and/or never will be. I think emulating a full ARM-based machine on a non-ARM platform is a dead end, and sadly I think ARM-based desktop computers are a dead end also. If ROOL releases the whole RO source with the license as described in the article I'd be interested in speeding up the FontManager and that's about it, but with permission to migrate to other hw I'd put in a lot more energy to help migrate RO onto readily-available, higher performance hardware and still pay the license fees to Castle for every sale of RISC OS. I can understand them wanting to protect their hardware sales but I fear those sales are very limited in number now.

adrianl on 21/1/07 12:23AM
[ Reply | Permalink | Report ]

AMS: because RO is leaner and faster, it would start up along with a RO DVD player in much less time than other x86-based OSes, give you a nice user interface that's actually fun to use and still have the required performance to decode DVDs in software where graphics card manufacturers have not made their documentation/drivers public?

To make things perfectly clear, I'm talking about running RO (or a RO-compatible OS) unhosted on x86 hardware, which is very different from emulating it on top of an existing x86 OS such as WinXP or a full Linux + X-Window system. I have no interest in the latter.

adrianl on 21/1/07 12:32AM
[ Reply | Permalink | Report ]

Don't port for x86, port for POWER ;o)

These are orphan now that Apple are in x86 world. Could be a number of people hanging onto these vintage systems that may want to "stick it to Apple" by using an alien OS :o)

lostamarble on 21/1/07 6:55AM
[ Reply | Permalink | Report ]

adrianl:My understanding is that porting to x86 would terminally break the vast majority of existing apps - most of which are no longer being developed. That seems a sure fire way to finally kill off the OS to me

.

Adam

P.S. And presumably the same effort would have to be made in a year or two when the rest of the world moves to 64 bit? And the next change after that and so on...

adamr on 21/1/07 10:14AM
[ Reply | Permalink | Report ]

adamr:

Adrian said, "...running the bits that have not yet been migrated under emulation along with the applications that have not been rebuilt and/or never will be".

tlsa on 21/1/07 11:02AM
[ Reply | Permalink | Report ]

lostamarble: Are you trolling?

1. What's the point of swapping one set of marginalised desktop hardware for another? 2. The number of people wanting to "stick it to Apple" would be vanishingly small. 3, What's best for RISC OS is to attract "normal" users, not technical ones (because of the huge ratio of the former to the latter).

Stoppers on 21/1/07 11:04AM
[ Reply | Permalink | Report ]

adamr, i don't see the point of the 64-bit argument there. if you port to x86 you effectively port to x86-64 (aka amd64).

we've only got 31 years until we *have* to move to 64-bit, and seeing how after 17 years we're only partially 32-bitted.....

simo on 21/1/07 11:15AM
[ Reply | Permalink | Report ]

adrianl wrote>"To make things perfectly clear, I'm talking about running RO (or a RO-compatible OS) unhosted on x86 hardware"

In a doomsday scenario situation perhaps that might be the way to go. If RO ran *without* a Linux/Windows kernel hosting it that might retain some of RO's frugality/efficiency and speed. You would still need some emulation of legacy ARM machine code apps.

My one fear is by promoting RO under x86 (or any non-ARM processor) we'd accellerate the native RO platforms demise - especially sadly since faster ARM's are now available. So I'd still say that for the moment a restriction on non ARM use should be maintained (obviously if things took a nose dive in the future an RO run unhosted on other hardware was the only option for it's continued survival that would option would need to be re-evaluated - but I don't think were anywhere near that point yet).

AMS on 21/1/07 11:40AM
[ Reply | Permalink | Report ]

The restriction to use ARM is unfortunate, but legally now, and technically, we're by and large stuck with it, unless we go out an re-write the whole OS without the intervention of Castle. I'd say that was pretty unlikely, so we should make the best of it. ARM is the most popular processor core in the world, surely that must count for something. There are many new portable ARM devices like the Nokia 800, this thing:

[link]

and loads of other devices, most are not very fast, and don't need to be for the job they are doing. Maybe we need to focus on these sorts of devices as the main platform for RISC OS and view the Iyonix and A9 as developer boxes for them. That's not to say desktop RISC OS is dead (no more so than it is now), but we can either lament the lack of CPU power or we can focus on a massive market where CPU power is not an issue, and inexpensive ARM based computers are in abundance. Let's not focus on unrealistic goals for our platform, such as great games, DVD playing etc. let's focus on completely do-able projects like maybe a Jabber client, Flickr client, maybe at J2ME port (it's GPL now, and completely at home on much more limited platforms than RISC OS). These are important and entirely feasible projects, and there are loads more like them.

I know I'm all talk at the moment, but I know if I had time to be working on RISC OS apps (and maybe I will soon) that's what I'd be working on. The DVD effort by Adrian Lees was heroic, but at the end of the day, I just bought a DVD player for £18.99. I've never watched a DVD on a desktop computer, I have on a laptop, on a train, but of course we don't have laptops.

I think sometimes we make too much of the limitations of RISC OS we cannot fix, and ignore the important limitations we *can* fix.

thegman on 21/1/07 12:00PM
[ Reply | Permalink | Report ]

ARM CPUs may not compare with other platforms for power but they are cheap: is there any future in developing a multi-processor version of RO?

bucksboy on 21/1/07 12:44PM
[ Reply | Permalink | Report ]

Yes, AMS, I think it would make native development redundant, unnecessary and obsolete. The first thing that would happen would be the "why bother?" argument - the final death knell to some diversity of choice and the ultimate defeat to narrow-minded conformity and convergence.

AW on 21/1/07 1:30PM
[ Reply | Permalink | Report ]

Having been to the SE Show and ROUGOL last Monday and having seen and heard the description of the license I couldn't in good conscience contribute anything under it, even though I have a few ideas (and a small enhancement to SciCalc already). There are too many other projects deserving of my time with more fair/benificial to users/equal licenses out there to work on.

Of course if the license if released and all the restrictions and weirdness isn't in the final version I'll be happy to change my mind.

flibble on 21/1/07 1:49PM
[ Reply | Permalink | Report ]

To restrict to just ARM processors is not a good thing in my opinion. If somebody ported to x86 say and it was successfully taken up by lots people then that is the natural evolution for Risc OS. Placing legal restictions is just not plain healthy

Jwoody on 21/1/07 2:27PM
[ Reply | Permalink | Report ]

I would like to see ports to other processors. (The only way I can see it appearing on a laptop natively)

The main conflict I can see with an non-arm version of RISC OS is if apps started appearing only for the other processors. Perhaps a better limit might be to restrict the execution of apps to ARM based ones. (While allowing modules to be run natively).

I suspect the possibility of a porting would interest many developers who've been lost to PCs

Whatever, it seems silly to apply the arm only rule to the commercial license

stoppers: I think you are missing something. The XBox 360 uses power processors. Hardly marginalised. A potentially huge market. Also the name RISC OS would not be silly, as it would on x86.

jess on 21/1/07 3:59PM
[ Reply | Permalink | Report ]

Restricting to ARM may stop RISC OS running on a 'proper' laptop, but there are options, like the Psion Netbook, and various tablet devices, which I am sure could accept a USB keyboard. It's not ideal, but it's good enough IMHO.

I think we need to accept that a port to another processor is not going to happen, but hypothetically, if it did, to restrict to POWER/PowerPC, although it's an incredibly popular architecture, would not get us much closer to having a native laptop, except for very expensive portable workstations. Sure there is the Wii, PS3 and XBox 360 all use PowerPC derivatives, but none of these are 100% suitable to be a desktop computer.

thegman on 21/1/07 4:41PM
[ Reply | Permalink | Report ]

I don't see the POINT of the ARM only restriction. As most of the source is ARM asm it would be an enormous task to port the entire OS to x86. Remember, although someone might discover that the released source is only 40% asm (that's a completely made up statistic) what would need to be ported is the core of the OS itself. Many of the ancillary support apps such as !paint might contain significant amounts of portable C code but I suspect that more than 50% of the OS itself will turn out to be asm.

It would probably be just as easy to recreate a RISCOS-like OS from scratch (perhaps making use of some freely available components), and re implimenting the API. I think that this would would be about same amount of work and produce a better result.

Unfortunately, the announcement that Castle won't ALLOW people to port to different platforms has turned a lot of people against the project from the start. And for no real gain from Castle's point of view.

At least this new development offers a new way forward for the OS.

killermike on 21/1/07 5:38PM
[ Reply | Permalink | Report ]

I think Castle's point of view is that if you could run RISC OS on a PC, they can't sell any desktop hardware. It's the same reason as say, Apple, they don't let you run Mac OS X on any old PC, because their sales would suffer, it's that simple.

I think killermike is quite right, it's probably just as easy, if not easier just to rewrite the entire OS, or build it on top of an existing kernel. Of course this has not happened yet, although there is no technical or legal obstacles. It would take a group of very good programmers a long time, yes, but there are many examples of os-rewriting success.

I think what we used to have is two under-developed strains of RISC OS, now we have the potential to unite around one strain of the OS, which could potentially get a lot more development. Personally, I'm not bothered about the licensing of RISC OS. If ROOL will make RISC OS better, and make it available on other hardware devices, which in turn make it more attractive to new users, then it must be a good thing.

The fact is, get a typical geek (that's not an insult, I consider myself a geek), and show him an Iyonix, he's going to think 'cool, but £799, nah, too much', get the same geek and show him a Nokia 800, and tell him RISC OS is optional, he's might think 'That's quite cheap, I'll give RISC OS a go, if it does not work out, I'll just use it with the standard Linux OS'.

thegman on 21/1/07 6:02PM
[ Reply | Permalink | Report ]

I have two questions not related to RISC OS on x86:

1. How realistic is a port of RISC OS for PDAs and Smartphones when the source becomes available?

2. Does anybody know more about the STBs? How do they look like, are there any screen shots (can you recognise it's RISC OS?)?

maikl on 21/01/07 6:39PM
[ Reply | Permalink | Report ]

1) I posted about this on ROOL's forums, specifically asking about the Nokia 770 ( or Nokia 800 nowadays), and they seemed to think that it would be reasonably easy given the right people and time. I think PDAs/tablets like this are a good target, the Nokia 800 has an 800x480 screen, that's not too bad. Smartphones on the other hand frequently have 320x240 screens or even smaller, so a RISC OS desktop would not be so nice. Also, RISC OS could not drive the phone aspect of the device without a lot of work, whereas on a device like the Nokia 770, you've only got to drive a Wifi adaptor, and there are open source versions of Wifi drivers, which could be used or just referred to.

2) Don't know, Castle seem to really keep quiet about these things.

thegman on 21/01/07 8:18PM
[ Reply | Permalink | Report ]

thegman: "I think killermike is quite right, it's probably just as easy, if not easier just to rewrite the entire OS, or build it on top of an existing kernel. Of course this has not happened yet, although there is no technical or legal obstacles. It would take a group of very good programmers a long time, yes, but there are many examples of os-rewriting success."

Yes, but let's look at those examples. There are various BeOS rewrites and BeOS-inspired projects, mostly because the community regarded it as abandoned (despite some commercial continuation of the product), valued various parts of the architecture (which is a lot better than RISC OS), and saw that alternative platforms might not offer solutions that could be considered competitive, although faster hardware and improved alternatives have eroded its advantages. There are some AmigaOS-related projects, undertaken for mostly the same reasons, but arguably with less justification. Even Windows has at least one imitator.

But for all these projects, one major thing they seem to have in common is the stream of applications ported from GNU/Linux or other platforms, as the developers attempt to show that their project has real-world value. The original BeOS had its differentiating features and applications, as did the AmigaOS, but those applications - even if available on the successor platforms - seem not to be compelling, nor are those platforms seemingly producing innovative alternatives to things like Mozilla.

So even if RISC OS got reimplemented, what would the benefits really be? In a sane world, you'd end up with something like "GNU/FreeROS", where the "FreeROS" makes up very little that couldn't be done by Linux or other Free Software operating system solutions.

The problem facing the average Drobe regular is that a continuation of today's RISC OS isn't any better than the first cut of "FreeROS" - a relatively stagnant development scene with aging applications and poor architectural choices - but I suppose the latter would at least be open enough for people to improve, integrate, and have it compete and collaborate widely with other systems, rather than be saddled with a artificially constrained corporate roadmap.

guestx on 21/01/07 9:31PM
[ Reply | Permalink | Report ]

killermike wrote: "It would probably be just as easy to recreate a RISCOS-like OS from scratch (perhaps making use of some freely available components), and re implimenting the API. I think that this would would be about same amount of work and produce a better result."

I think it's important to distinguish between the factors that keep people using RISC OS: the desktop environment and the applications.

Contrary to popular opinion, the look and feel of the RISC OS desktop could be recreated for other desktop environments by skilled developers in a reasonable amount of time. Porting the whole thing, or reverse engineering then duplicating it, only makes sense if you want to use legacy software or want to retain familiar APIs, and that could be done via an emulator.

For most users, the only thing stopping them from moving to another desktop environment that looks and feels the same is the lack of familiar applications. Basically, if you could port the most popular applications to such an environment, you would satisfy many remaining users; the less popular applications would just have to be run in an emulator.

This approach is different to the usual one people fear in this forum: we're not talking about running ex-RISC OS applications on Windows and occasionally firing up an emulator; we're talking about running ex-RISC OS applications in a familiar environment and integrating an emulator to make sure all the niche applications continue to run.

davidb on 21/01/07 9:38PM
[ Reply | Permalink | Report ]

Guest X said:

"Yes, but let's look at those examples. There are various BeOS rewrites and BeOS-inspired projects, mostly because the community regarded it as abandoned (despite some commercial continuation of the product), valued"

I should add that I wasn't suggesting that a complete reimplementation of RISCOS was a good idea. I was just suggesting that porting all of RISCOS to x86 would be nearly as much work as reimplementing from scratch and potentially result in a less useful end product.

killermike on 21/01/07 10:36PM
[ Reply | Permalink | Report ]

(nt)

lostamarble on 22/01/07 05:02AM
[ Reply | Permalink | Report ]

(whoops, bad internet connection, try that again)

Stoppers, you hit the nail on the head. While the discussion has focused seriously on at least having a crack at RO on x86, there are many many 'obsolete' systems out there, I thought slipping under the radar with a port on something that can not be considered a threat to new ARM based hardware sales may be an option for those interested to see development of drivers or architecture improvements that existing ARM systems, or new ones, won't see for a few years. I just cut my post way to far down and it's a troll post. So now I'll go back to waffle mode.

One ancdote about Linux being ported from x86 to another architecture early on was the huge explosion to other systems once the lessons had been learnt... Now that there is PCIe support in the ARM architecture (XScale model whatever), what are the options of support in RO - not good until there is hardware supporting it? So how about hit the ground running by writing support under a x86 version that can be ported back to ARM when the hardware materialises, then the RO community hits the ground running with that new hardware? Of course I know absolutely nothing about porting between architectures, so I understand that we can learn nothing from software on one system before it arrives on the destination platform.

I like to check out www.linuxdevices.com to see ARM powered systems i'd drool over if RO ever made it onto them. There are plenty of options for exclusively developing RO for ARM, so the Castle/ROOL ideal of NOT porting to other CPU architectures is not too far fetched, there is a very fertile market out there. We do have to ask though, there is so much discussion from people who sound like they'd prefer to see RO on x86, can they be prevented by Castle/ROOL from giving it a crack?

lostamarble on 22/01/07 05:04AM
[ Reply | Permalink | Report ]

This raises an interesting legal point. When does the creation of a RISC OS like OS developed for another platform, provided they don't call it RISC OS, become an infringement of Castle's IPR? We already have the ROX filer and desktop that run on Linux, and there is no problem with that to my knowledge. I don't think drag and drop, or context sensitive menus or an iconbar are a problem, or even anti-alised fonts, since all are already used elsewhere. If anyone tried it, I suspect it would be a goldmine for the lawyers and to the detriment of Castle and ayone else involved.

mrtd on 22/01/07 12:33AM
[ Reply | Permalink | Report ]

One of the reasons I believe ROOL don't want to open up Risc OS to non-ARM platforms is that ultimately ROOL/Castle know there is no money in the Risc OS desktop market, and subsequently would rather see effort focused on enhancing Risc OS rather than porting to another platform.

ROOL/Castle are only interested in the embedded/STB market where there is as of yet, no defined standard OS/platform, and where they have a chance of making some money.

Unfortunately, we desktop users just want Risc OS running on hi-spec system, and it seems that the most likely way of this happening would be to port to x86.

Although as a Risc OS user I would love to see Risc OS running on multi-Ghz hardware, the chance of that happening any time soon is very slim. Maybe when some mass market manufacturer releases a piece of hardware using the new Cortex ARM processor it will be a reality, but we shall have to wait and see.

nx

nx on 22/01/07 12:40AM
[ Reply | Permalink | Report ]

I suspect that the only real problems would be with trademarks, or if the (lack of) connection between RISC OS and the new environment was misrepresented to users in some way.

davidb on 22/01/07 12:44AM
[ Reply | Permalink | Report ]

thegman: "Sure there is the Wii, PS3 and XBox 360 all use PowerPC derivatives, but none of these are 100% suitable to be a desktop computer. "

I just looked up the specs on the XBox360, it can plug into a normal (X)VGA screen. Has USB 2, ethernet and Wifi. It even looks like some PCs.

The only difference, were it possible to use as a desktop PC, would be booting off optical disk and needing a USB hard drive.

(And how much would it annoy BG if it got adopted as a desktop system, with someone else's OS)

jess on 22/01/07 12:53AM
[ Reply | Permalink | Report ]

I didn't know the Xbox had a HD15 port, that's pretty good. Although of course Microsoft does not permit running anything else on the Xbox other than it's built in OS. That's not to say it's impossible of course, but if you're deciding to port to another processor, you can choose one which permits every conceivable hardware permutation (x86), or you can go with one which only permits running on non-upgradeable hardware, no laptops etc (PPC consoles). If we were talking about the Amiga, which is already PowerPC native, then the PS3 especially is a no-brainer, particularly as Sony is perfectly happy for you to install another OS on it (and even tells you how).

But as we're talking about RISC OS, a hypothetical re-write to another processor may as well be done in such a way to allow many different CPUs, if you're doing all that work anyway, may as well do it in a cross-platform way with a runtime (like Inferno, Java, Intent etc.) or in a more traditional compiled-for-each-arch way like BSD, OS X, Solaris, Linux etc. That way you can just pick whatever CPU suits you best, regardless of it's architecture.

thegman on 22/01/07 11:06PM
[ Reply | Permalink | Report ]

The x box (old one) can run linux. It is frequently used as a media player OS type thing.

[link]

efforts are underway to get this on the 360.

cheers bob

nijinsky on 23/01/07 09:16AM
[ Reply | Permalink | Report ]

(nt)

nx on 23/01/07 11:55AM
[ Reply | Permalink | Report ]

Yeah and I belive the PS3 has been seen in the wild booting Linux as well....

Not sure how good it works on the hardware, I guess linux would need a lot of tweeking to make use of any of the cut down extra processing units in the CPU...

I would be happy keeping with arm esspecially if we got the OS available on a laptop like device.... As has been said the Netbook pro is an option... There were also a load of other devices. I think Jornada 820 (& the 720 would be a good mini laptop), Nec Mobilepro (the 900 is a 400Mhz cpu version and has amoung other features a VGA out port), Compaq did a CE laptop I think running Arm and as has been said there are plenty of boxes shipped that run an ARM cpu that are tablet devices. Tablets tend to have a PS2 port and I have seen a lot with a light case that held a keyboard effectively making it a laptop like machine. Maybe not many desktop motherboards with PCI expansion but we have the A9, Ionix and it appears from the other article castle is looking at making an Ionix replacement.

John

mrmac on 23/01/07 12:19AM
[ Reply | Permalink | Report ]

It would be great to have RISC OS on any of these devices, however I think there is a problem with providing an OS for an existing system of this sort in the availability of the product.

Would the device still be available when the port is finished?

This would make x86 PCs and consoles the best target, unless the manufacturers themselves are involved.

jess on 23/01/07 12:43AM
[ Reply | Permalink | Report ]

(nt)

thegman on 23/01/07 12:49AM
[ Reply | Permalink | Report ]

Jess: The XBox 360 isn't intended to run alternative operating systems (and I'm pretty sure the threat of Microsoft's legal department would be much greater that that of Castle's). So, you'd be limited to people with an XBox who are willing and able to hack their games console in order to run RISC OS.

Martin Dixon: How like RISC OS would it have to be, do you think?

The Look and Feel should be alright, since that issue was settled in the courts decades ago.

How about the API (SWIs). That, I could see a potential problem with (didn't Acorn copyright it, or something?), but no other processor type uses exactly the same mechanism, and WINE seems to have been left alone by Microsoft, even when it must provide some of the same binary interfaces as Windows.

On the other hand, what if the API provided was (a subset of) the OSLib C API? That doesn't belong to any RISC OS company.

I don't know if any of it would really be a problem for Castle, as long at it didn't use any knowledge of how RISC OS is implemented (let alone use any RISC OS code). As Alan Robertson said, there's a gap between Desktop and STB requirements that's getting bigger all the time, and any implementation of a RO like system using free components could never be as lean as the real thing (for reasons of time available), but that wouldn't be a major problem for a desktop system with many times the processor power available.

Porting RISC OS to x86 is a non-starter, making a RO-like environment on Linux is do-able, as would be getting some RO applications running on that.

Stoppers on 23/01/07 1:24PM
[ Reply | Permalink | Report ]

nx wrote>"One of the reasons I believe ROOL don't want to open up RISC OS to non-ARM platforms is that ultimately ROOL/Castle know there is no money in the RISC OS desktop market, and subsequently would rather see effort focused on enhancing RISC OS rather than porting to another platform."

That, with respect, sounds a little off target. The more logical reason is their hardware business would die/be damaged if RISC OS was ported to another CPU. I'd also point out that the effort to port to another platform would be expended by *others* (it entails *not much* extra effort on ROOL/Castle's part and that would not deter them surely).

nx wrote>"ROOL/Castle are only interested in the embedded/STB market where there is as of yet, no defined standard OS/platform, and where they have a chance of making some money. "

I haven't actually seen them say this anywhere? In any event Iyonix is *not* an embedded device yet they produced it - and there was mention of a follow up. In actual fact A9 is a more architypal "embedded" device (in as much as it doesn't have any expansion ports proper (no PCI bus)).

There are 1.2GHz ARM processors out now (Intel IOP's) that would do nicely (some even dual core) that would fit the bill. IMHO there'd be little point in moving to "unknown" processors when (finally) there are some compable ARM processors on the scene I would have thought.

AMS on 23/01/07 1:28PM
[ Reply | Permalink | Report ]

AMS: The problem is that 1.2GHz IOPs are still going to be much more expensive and not a touch on x86 or even PPC in terms of performance, and require somebody to actually design a motherboard using it still. Plus, RISC OS cannot take advantage of multiple CPU cores anyway.

rjek on 23/01/07 2:04PM
[ Reply | Permalink | Report ]

Linux already runs on the PS3 [link]

Cheers Bob

nijinsky on 23/01/07 2:18PM
[ Reply | Permalink | Report ]

mrmac on 23/01/07 3:04PM
[ Reply | Permalink | Report ]

Sorry had post go missing and then accidently re-submitted my earlier post....

DOH!

mrmac on 23/01/07 3:05PM
[ Reply | Permalink | Report ]

Rob>Yes an IOP 1.2GHz will *not* give the same performance as 3-4GHz 64bit x86 CPU when running the same task natively. However we're not comparing horses for courses here - an ARM CPU run at 1.2GHz with the larger cache (L2) offers the means of running *natively* ARM RISC OS code that'll outpace an x86 based ARM emulator and probably by a margin too.

Yes I'll also concede that they may cost more than an equivalent x86 set up - but then you're paying for the ability to run RISC OS natively (i.e., at it's most efficient and with no reliance on another OS to run).

As to multiple cores yes RISC OS can't natively use them - but surely some "background" or applications specific tasks can be so done. (Ok you won't get x2 times the performance of a single core version of the same CPU and it may not be as transparent or as flexible - but a gain is a gain so let's pocket it eh ;-)

AMS on 23/01/07 11:26PM
[ Reply | Permalink | Report ]

mrmac:

What about availability of such devices? Can you still get them new from the manufacturer in sufficient numbers? Are there localised (especially keyboard, but also small things like power supplies) versions available for all users? What about the pointing device (touchscreen drivers)? Could the final RISCOSified product be sold at a competitive price and the development costs for drivers and other required software be recouped? I guess you are beginning to see why Apple switched to x86 now?

JGZimmerle on 24/01/07 00:43AM
[ Reply | Permalink | Report ]

Touch screen drivers must have existed in some form at some time for the Newspad. If we are very lucky Castle may have the module on a disk somewhere.

As my missing reply went on to say... I am also thining if the device goes out of production as long as you make sure you pick a device that was sold in sufficient numbers to ensure we continue to have a strong 2nd hand market and parts/accessories are available for a number of years. This would mean you could switch from selling the devices pre-installed with risc os to selling ROM upgrades (either a replacement plug-in rom board or a flash upgrade service).

By following the above route it would mean they can still continue to sell the service/product and continue to make money from the investment made to make the OS work on the device in the first place even if the device is no longer available new.

John

mrmac on 24/01/07 10:05AM
[ Reply | Permalink | Report ]

Reply to John Hogg, And also, the more devices RISC OS gets ported to, the more experience will be gained for doing such a thing, and theoretically at least, porting to new devices should get get easier and easier, so long as those devices are not locked down with various protection methods, and the hardware is relatively standard.

thegman on 24/01/07 11:42AM
[ Reply | Permalink | Report ]

John Hogg: I do touchscreen drivers - have been showing them at Wakefield for years. I'll be putting more info up about them when my web site moves.

liquid on 24/01/07 12:05AM
[ Reply | Permalink | Report ]

Alan:

Nice one --- I knew I had also seen them somewhere else before.

by the way the RPC I got from you is going nicely.... Though it's now got 233SA, ROS 4.02, 128MB ram and a few other upgrades since I got it.

Garry: exactly it will allow people to learn how hardware abstraction has been implemented and gain experience to port onto other devices... I seem to think the port of ArmLinux was the learning experience and catalyst that allowed a lot of the other Linux ports to take place off the back of it....

TBH making Risc OS 5 work on an RPC may actually help in this direction as well because it will allow people to learn about the abstraction and the modules/components of the OS that interface with the harware while using hardware that is very farmiliar so it will remove the problem of actually interogating all the hardware specs as well. Not to mention a lot of the mobile ARM devices ran on 200-233mhz strongarms so CPU power may be similar.... And getting Risc OS 5 working on the A9 would also prove very usefull as it's Arm9 will be simmilar to a lot of portable devices.

mrmac on 24/01/07 12:21AM
[ Reply | Permalink | Report ]

In reply to John: I could not agree more, this is an opportunity for us all to be using the same version of RISC OS, whether it's on a RiscPC, A9, Iyonix, or some future tablet device. The similar spec of CPUs is a bonus too.

thegman on 24/01/07 12:39AM
[ Reply | Permalink | Report ]

This is what worries me the most about open source, it will be subverted in to pointless exercises instead of doing something useful to move the OS forward. It is a complete waste of time to port RO5 back to the Risc PC, there is no need for one version of the OS to run on everything, as there is nothing to be gained. Not one additional application will run on a Risc PC because it has RISC OS 5 (and indeed many thousands of 26bit applications will be broken buy it). The only applications that are RISC OS 5 only, are that way because they depend on Iyonix hardware. Familiarity with the HAL and driver model will come with experience of porting it to useful new hardware, not wasting valuable development time reinventing a decidedly square wheel on the Risc PC.

druck on 24/01/07 1:28PM
[ Reply | Permalink | Report ]

druck: "... it will be subverted in to pointless exercises instead of doing something useful ..."

You get the programmers you pay for.

flibble on 24/01/07 1:49PM
[ Reply | Permalink | Report ]

david:

And a lot of software hasn't been updated to 32bit at all....

Have we not already quoted if everyone with an RPC was on 32bit and using the same OS thus making the market a lot bigger and demand a lot bigger for any updated application it may encourage some software to be updated and maybe even have some new features added at the same time (surely this would also benefit ionix users)

You say it's pointless I say it isn't - just continued repeating of it being pointless doesn't make it so. I think the people who think it would help the market have put forward a number of reasons it may help in this discussion so far but I havn't seen any of those reasons countered by any response or explanation. I am very happy to be proven wrong or have a reason given why it won't work but it always seems lacking.

I am not going to spend a large amount of money on an Ionix but I am happy re-learning Risc OS on my RISC PC which is cheap enough that if it doesn't work out I don't loose too much money. Again are there not so many RPC not being used that may have some life brought back...

A lot of people are probablly not capable of trying to make Risc OS work with a totally new device but are farmiliar with the hardware and how to directly interface with the harware in the RPC making it a valuable learning exersize in my opinion. Which will give them some knowledge of what files and code needs adjusted and may give them enough knowledge to make a move to a diffrent ARM device possible... The diffrence between the way I see it and the way you see it is let people learn in stages rather than throwing them in at the deep end. Yes some people may swim at the deep end so let them start at the deep end and go directly for a new device. But why let that stop the ones who would drown and either not try or give up at the deep end start off in more farmilair teritory.

John

mrmac on 24/01/07 1:53PM
[ Reply | Permalink | Report ]

druck: with the greatest respect, who are you to say how someone should spend their spare time? The point of open source is that if someone wants to spend their time backporting RO5 to a RiscPC, good for them.

If you're that concerned about going "forward", consider that someone who scratches an itch by gaining experience (back)porting RO5 to their hardware will make it easier for them to contribute to whatever *you* consider valuable in future.

Jaffa on 24/01/07 1:59PM
[ Reply | Permalink | Report ]

In reply to druck: I think it is very valuable to have all users on one version of the OS, it means that we can use APIs without fear of them not being available on some machines. The 26-bit argument is valid, if you're interested in using apps which are not being developed any more, but IMHO it's better in long run to discard all these applications and encourage the purchase/development of recent and actively developed applications. Clearly there will be some areas in which only legacy app will do, and that's what Aemulor is for. I would hope too that if we all start using RISC OS 5, then the Castle USB stack will become standardized and the farce of having to two USB stacks will go away. Personally I don't care if we use the Simtec or Castle stack, but having two is absurd.

Having two strains of RISC OS just means that the small amount of development going into RISC OS is split unneccesarily, and it means that we end up with stuff on one strain (i.e. the Select Image SWIs for handling different image file formats) which may be very useful, but we can't use as it won't work on the other strain.

Frankly, I don't care which side becomes the 'standard' RISC OS, but I think we can all agree that in an ideal world, if we could turn back time, we'd like to only have one version of RISC OS, and the open-sourcing of RISC OS 5 is an opportunity to achieve that.

I'm not an open source advocate at all, I agree that a lot of work that goes into open source projects is pointless, non-innovative duplication of commercial products and like you say, wheel re-invention. But we can either have practically zero development on two versions of RISC OS like we have now, or we can take a chance, put all our money on one version of RISC OS and see what we can do with it. Right now, left as it is, RISC OS is finished, it has *zero* chance of survival, but the ROOL/Castle plan offers hope, and I think it's important that we all get behind that.

thegman on 24/01/07 2:02PM
[ Reply | Permalink | Report ]

(nt)

nx on 24/01/07 4:46PM
[ Reply | Permalink | Report ]

These (nt) posts are beginning to annoy me. I’ve just typed in a whole message and Drobe loses it. Grrrr!

Any, what I think Druck was trying to say is that effort in back porting RO to the RPC would not really move the development of RO forward. Why spend time and effort in porting to an old and obsolete platform with very few users, when you could spend the effort in getting RO working on a much more recent and viable platform?

Of course, as you say, developers can choose how they spent their time, but I would prefer, even as a RPC user, if developers ported to newer faster ARM systems, else we’re not going to be going anywhere fast anytime soon.

nx

nx on 24/01/07 4:55PM
[ Reply | Permalink | Report ]

Reply to nx: I agree to an extent, the RiscPC is ancient, and should probably be consigned to history, but various surveys and finger in the air guessing would probably indicate most RISC OS users are still on RiscPCs and it would be a shame to exclude them. Also, I understand that RISC OS 5 was primarily developed on RiscPCs and a port would be straight-forward, if not already done.

But yes, new systems should be the priority.

thegman on 24/01/07 5:03PM
[ Reply | Permalink | Report ]

(nt)

chrisrayson on 24/01/07 5:25PM
[ Reply | Permalink | Report ]

Maybe the best-of-both-worlds scenario would be to set to work on independently implementing Select features, and integrating them into RISC OS 5 in an API-compatible manner. That would bring convergence between the two OS branches, whilst still bringing new features to new (rather than ancient) hardware.

It still all seems rather sub-optimal, given that ROL have already put a great deal of effort into implementing Select features the first time, to expend more time and effort doing it all over again, but it looks like the only way they're ever going to get on an Iyonix...?

chrisrayson on 24/01/07 5:25PM
[ Reply | Permalink | Report ]

I think that ROL will probably use parts of the RO5 sources to port their version of RISC OS to the Iyonix, if the royalty payments are indeed only a few pence per copy sold.

JGZimmerle on 24/01/07 10:28PM
[ Reply | Permalink | Report ]

BTW, what is all this talk about developers learning how to port RISC OS to many new and old ARM devices? AFAIK the biggest challenge RISC OS faces is a lack of developers. Do you really think that the prospect of getting RISC OS to run on ancient hardware will draw a significant number of new developers to the RISC OS world? And yes, most of the software developers I know do consider 3 to 4 years old hardware ancient.

JGZimmerle on 24/01/07 10:37PM
[ Reply | Permalink | Report ]

Reply to JGZimmerle, I suppose the idea of running RISC OS on various ARM devices is attractive to because if you compare RISC OS to Vista, Mac OS X or even Linux, RISC OS looked incredibly dated and limited. However, if you compare RISC OS to Windows CE, Palm OS, or an embedded Linux like in the Nokia 770/800, it does not look so bad. Proper multi-tasking, support for multiple CPUs, 3D graphics etc. maybe be present on these types of devices, but it's just not very important like is on the desktop. RISC OS on the desktop is many generations behind the market leaders, on PDA/Tablet style devices it's probably not even one generation behind, in some ways it may even have some advantages.

RISC OS on the desktop is extremely dated, RISC OS on a tablet is not so bad, it's almost like getting free pass to compete in the real world.

thegman on 24/01/07 10:47PM
[ Reply | Permalink | Report ]

thegman: Sorry, RISC OS on a 770 (or my new N800, hopefully arriving tomorrow) would be a nice toy; but I'd rather have a Linux base for my day-to-day operations with Maemo than RISC OS.

Proper multitasking is *incredibly* important on a device like an Internet Tablet: I don't want to have to reboot it just because a single application crashed, or trample over someone else's memory.

Also, what would you use for Internet access on an N800-with-RISC OS? NetSurf for web browsing, I've already done a port of the Linux version, IM - Grapevine? That costs money. Messenger Pro/Pluto for email, would be a step up but you rapidly get to the point where there's a limit to how useful a pretty desktop UI is on such a high density screen.

After the iPhone demos, I'm already of the opinion that the Maemo desktop copies *too many* desktop metaphors blindly, without thinking of the optimal UI for the device's form factor and use cases.

Still, I like toys so I'd still like to see it ;-)

Jaffa on 24/01/07 11:31PM
[ Reply | Permalink | Report ]

Reply to Andrew: Never used Maemo, so can't really comment. I know what you mean about not wanting to reboot because an app crashed, I like real multitasking as much as the next man, but it's just not as crucial on a web-tablet as it is on a desktop computer IMHO. I use Macs at home and at work, I pretty much work them to death in a way that that RISC OS could not handle (not fast enough, can't really do two things at once, lacks the apps, no decent CLI, the list is endless) however, I demand so much less from a portable device, and just a couple of simple apps would make a RISC OS tablet perfectly useable for me.

As for the desktop UI, yes, on a device like the Nokia 800, it would be cluttered, but I think with a little imagination we could work around that, maybe change the window manager to suit it a bit better, allow apps to hidden easily, and I suppose if RISC OS on tablets caught on, people could modify the UIs to be a bit better on smaller screens etc.

thegman on 24/01/07 11:51PM
[ Reply | Permalink | Report ]

Question: Is RISCOS 5 32/26bit neutral or 32bit only? With a RISCPC HAL, could it run in 26bit mode? If so, it could be made to run on that hardware and remain backwards compatible with 26bit software and forwards compatible with newer neutral software.

"What makes a man turn neutral? Lust for gold? Power?"

killermike on 25/01/07 00:54AM
[ Reply | Permalink | Report ]

Why is the RISC PC still popular?

I would say it's because with the things that RISC OS excels at (email and website design for example) a Risc PC does well. The things that RISC OS does not do so well (web browsing for example), an Iyonix is far better than a Risc PC, but still poor in comparison to a recent Mac or (properly working) PC.

So someone with a Risc PC and space for two machines but money for only one, buying a Mac could easily be more productive than buying an Iyonix.

That is why support shouldn't be dropped.

jess on 25/01/07 12:36AM
[ Reply | Permalink | Report ]

Jess, I'm not sure how RISC OS excels at website design, you need to able to preview the site how 99.9% of viewers are going to see it, which you can't do under RISC OS.

But I do agree that support for the RiscPC should not be dropped, if only because it was not that long ago that Castle were still making them. Also, we need to get as many people using the ROOL version of RISC OS as possible, and I think the RiscPC remains the most popular RISC OS box at the moment.

thegman on 25/01/07 2:18PM
[ Reply | Permalink | Report ]

Hmm, wonder if it was trying to do the "In reply to" thing that's giving the nt?

Anyway, what I was trying to say before Drobe attempted to silence me with (nt) was that thegman's point isn't entirely accurate - if you design a page that'll work in Netsurf then it should work OK on other browsers too, so I don't think that that's much of an issue.

SimonC on 25/01/07 3:00PM
[ Reply | Permalink | Report ]

SimonC, Indeed, it should work the same, but the reality is that it does not. And if you're doing Javascript stuff, then Netsurf is not going to work anyway. If you're doing a site, which say, includes a YouTube video, you could put in the code on RISC OS, but you'd just have to assume it worked, as you could not test it. There is also issues like websites which use certain fonts in CSS, there are some fonts which you can assume a PC or Mac has, but not RISC OS.

I'm not criticising Netsurf, I think it's great, but using RISC OS for web design is somewhat like painting a picture whilst wearing spectacles which distort your vision, it might look OK to you, but that's not how 99% of your viewers will see it.

thegman on 25/01/07 3:27PM
[ Reply | Permalink | Report ]

If you design a page that works properly in Arcweb then it will work properly in other browsers too. That doesn't make ArcWeb good to use for web design. In fact if you were to take MacOS, Windows, Linux and RISC OS, RISC OS would probably be the worst for web design and web design isn't even all that demanding, all you need is decent editing software and a decent browser. Ah, hang on....

fwibbler on 25/01/07 3:30PM
[ Reply | Permalink | Report ]

thegman: Web design on a Risc PC

As Simon says if you design a site that works in netsurf (and lynx and validates) then it should work fine on anything.

However you put a Mac (or PC) next to it to view what you are working on you have a very effective system. More effective than an Iyonix, a PC or a Mac on its own.

jess on 25/01/07 4:02PM
[ Reply | Permalink | Report ]

If you are going to write your site-code by hand, then RISC OS is the best choice for that. I have many years of experience doing web-design work on RISC OS, Linux (Gnome and KDE desktops and CLI), Windows, MacOS and Solaris. RISC OS wins because of the many tools available wich are perfectly "integrated" by the WIMP. If you have a RiscPC you can use the PC coprocessor card with Windows98 and the Opera web-browser for testing and viewing. On a modern PC you can work in a similar way with VirtualRPC, although the irritating way in wich the mouse is emulated (with the pointers of windows and RISC OS working at the same time, while the VirtualRPC window is active) is very irritating. IMHO the best way to do web-design work on RISC OS is by networking a RISC OS machine and a x86-Mac (use an A9home and MacMini if space is limited) with a KVM switch. Use an x86-Mac with BootCamp and WindowsXP installed, so you can test your site with both Windows and MacOS versions of browsers. If you want to test for web-standards compliance, use Opera.

JGZimmerle on 25/01/07 4:17PM
[ Reply | Permalink | Report ]

Oh yes, and don't forget BOSE QC-3 noise-canceling headphones to eliminate the noise of the PC's or Mac's cooling fans. Also works great for any other noise like DVD/CD- or hard-disc-drives. They are actually marketed for use on airplanes, but work equally well for most other background-noise like traffic and machinery noise. You can still hear people talking, though.

JGZimmerle on 25/01/07 4:25PM
[ Reply | Permalink | Report ]

JGZimmerle: I code sites by hand using Dreamweaver on Windows. A plain text editor ... with syntax highlighting, error highlighting, validation, reference library, indentation tools, macros, gui method of setting properties and real time previewing. Oh and I can design visually if I so wish.

But where Dreamweaver really comes into its own, and what I could not live without, is the ease with which I can reverse engineer other peoples websites, which is particularly useful in creating minimal test cases of browser bugs (not exactly a common need, but it is very good for it). Of course, I could just be using !Zap or some other text editor and be beating my head against the wall in frustration.

So if you code sites by hand, there are other non RISC OS based alternatives, if you code sites visually you've no choice but to use something else.

flibble on 25/01/07 5:05PM
[ Reply | Permalink | Report ]

I have used Dreamweaver, too, when I had to work on Windows or MacOS. However I still like RISC OS better. I suppose if you don't know XHTML and CSS well enough to write standard-compliant code from your head, it might be a little awkward having to look up the syntax of tags and attributes in the documentation, but that is the case for any language. What I don't like about big, fat applications like Dreamweaver is the fact that you have to adjust your way of working to the way the application works and you have no choice but to accept and live with the shortcomings (including bugs) of these applications. I much prefer to have lots of small tools each working just the way I want it to, all of them integrated via RISC OS' great drag 'n drop GUI. If one of these tools turns out to be buggy or complicated to use, I simply replace it with another one or contact the author so he can fix or improve it. Have you ever tried to contact the development team of Dreamweaver (good luck with that, you'll need it)?

JGZimmerle on 25/01/07 7:11PM
[ Reply | Permalink | Report ]

Let get this clear, when we talk about porting RISC OS 5 we are talking about taking the entire OS accros from the HAL upwards, reimplementing device specific drivers and running in 32bit mode, as would ne necessary for running on any new hardware. This is completely, entirely and utterly a waste of effort for legacy machines such as the Risc PC.

However the "One OS to bind them all" advocates dont seem to realise this is not what they are really asking for. What they want is common API on all supported platforms, and this DOES NOT need an entire operating system to be ported - RISC OS is designed modularly to allow functionality to be added to the OS which is already designed to run on that hardware.

For example take the RISC OS 5 unicode font manager API, once that appears in the ROOL CVS system, it can be compiled and running on a Risc PC in a matter of minutes, and then all applications have API compatibility. There is no need to spend years re-writing drivers and breaking all 26bit software on the RPC to get the rest of RO5 on first.

druck on 26/01/07 12:21AM
[ Reply | Permalink | Report ]

@David Ruck

[recompiling individual components of RO5] An interesting point that I hadn't considered.

However, I am still wondering if OS components need to be recompiled for the RISCPC. If they work on the Iyonix wont they be 26/32 bit neutral and therefore runable on a RISCPC in 26 bit mode?

Obviously, any low-level stuff such as the HAL will need to be rewritten.

killermike on 26/01/07 1:49PM
[ Reply | Permalink | Report ]

Grrr... see *you*, nt!

JGZimmerle wrote, "RISC OS wins because of the many tools available wich [sic] are perfectly "integrated" by the WIMP."

Care to expand on that? HTML editors which just give you nicely coloured plain text with buttons for headings and so on (which is all I've seen for RISC OS) are somewhat old hat and were only "the thing" in about 1995 on other platforms. For a lot of the Web stuff I've done, I've needed to know how the CSS I've written will actually turn out, and regardless of how you write the HTML, this demands a browser that can support recent CSS specifications. So I'd say that RISC OS loses because of the browser situation, although since Firefox is apparently getting there on the Iyonix and presumably builds out of the Mozilla development tree, it's conceivable that one day there'll be a port of Mozilla Composer/Nvu/KompoZer - an application which has come along quite far even in the last few months. Then you might even have a decent browser and something which lets you enter text into a page without having to hit a preview button ten times a minute.

guestx on 26/01/07 2:28PM
[ Reply | Permalink | Report ]

JGZimmerle: I disagree. A second screen is far more useful than a KVM and an old G3 Mac does fine. (I guess using VNCInput would be the ultimate).

But I think my point that a (networked) combination of a Risc PC and a Mac (or PC), is better than a Mac, PC or Iyonix alone, stands.

jess on 26/01/07 4:29PM
[ Reply | Permalink | Report ]

jess: "But I think my point that a (networked) combination of a RiscPC and a Mac (or PC), is better than a Mac, PC or Iyonix alone, stands."

And what was the RiscPC for, again?

guestx on 26/01/07 6:51PM
[ Reply | Permalink | Report ]

Guestx: email and webdesign

jess on 26/01/07 9:38PM
[ Reply | Permalink | Report ]

And the Mac or PC aren't any good for e-mail and Web design? What does the RiscPC have that the others don't? A decent e-mail program and a decent text editor?

guestx on 27/01/07 00:15AM
[ Reply | Permalink | Report ]

Please keep to the topic of the article

druck on 27/01/07 02:49AM
[ Reply | Permalink | Report ]

guestx: "What does the RiscPC have that the others don't? " The Risc PC has a decent GUI. (And a built in vector graphics format)

Many of the things that RISC OS does well are things where the GUI is the limiting factor, not the power of the machine. This is why (I believe) Risc PCs are still popular and should not be dismissed.

jess on 27/01/07 2:36PM
[ Reply | Permalink | Report ]

GuestX:

Are you just trolling or have you simply not read our (jess' and mine) posts on this topic? The RISC OS GUI lets you work with a collection of different small apps and tools as though they were an integrated package. So you have a number of tools that complement one of the two excellent editors (Zap or StrongEd, both of wich have great HTML modes available). I mostly work with server-side content management systems like Joomla where I have to upload code-changes to the server anyway before I can really see what the changes would look like. This is a lot easier on RISC OS, than on most other platforms, because I never manually download or upload anything. I simply open the file in question from a filer-window wich displays the contents of a directory on the server (via an image filing system) and when I save the changes in the editor, they get saved directly back onto the server. I then refresh the page in the browsers I keep running on my MacOS-, Windows- and Linux-Computers to see the changes almost instantly in Opera (Windows and Linux versions), Internet Explorer (MacOS and Windows versions), Firefox (MacOS, Linux, Windows and RISC OS versions) and Safari (MacOS' standard browser).

jess:

For new web-designers the advantage of an x86-Mac is that they don't have to buy a separate PC to test their sites with windows-versions of web-browsers.

JGZimmerle on 30/01/07 07:17AM
[ Reply | Permalink | Report ]

JGZimmerle: "Are you just trolling or have you simply not read our (jess' and mine) posts on this topic?"

Yes I have read them, but aside from drag-saving, where's the usability advantage? Have you not used a modern UNIX desktop which supports WebDAV or FTP-over-SSH? It seems to me that the only supposedly significant benefit being mentioned is the need to use text editors on RISC OS because anything more sophisticated for Web page authoring doesn't exist, and that this forces you to write HTML by hand. Sure, I've manually uploaded and downloaded things on Linux recently, but (1) you don't actually need to use command line tools any more, and (2) which desktop are you actually running on your Linux computers if you think that manual uploading/downloading is the state of the art? Even Windows has had Web Folders since Windows 2000, and I suppose Mac OS X has similar stuff, too.

Meanwhile...

druck: "Please keep to the topic of the article"

Oh, that was how Castle and RISC OS "Open" don't understand how these other platforms have managed to more or less retake the usability high ground from RISC OS - some because the owners of those platforms have lots of cash and monopolistic tendencies, and for others because genuinely open development is the norm on those platforms. Instead we hear about various Far East customers and Castle's inability to understand dual-licensing.

guestx on 30/01/07 6:03PM
[ Reply | Permalink | Report ]

GuestX:

I'm not going to list all the small advantages of the RISC OS desktop, wich make it a better GUI. If you have forgotten what most of them are, why not use RISC OS again for a few months and re-discover usability. Or try to find the list someone once made (i think it got published on the RISC OS products directory) with about 130 ways in wich RISC OS' GUI is superior to most others.

Of course I have used modern UNIX/Linux desktops. In fact I use more modern Linux desktops than most Linux users, because I like to compile bleeding-edge versions myself to try out the newsest features. However the problem with Linux desktops and Linux desktop applications is, that they don't always work very well together. An example that I will never forget (because it took me ages to figure out what it was): I once had a problem with printing from OpenOffice.org under KDE. No-one else had this problem, and after a lot of experimentation, it turned out that OpenOffice would not print via the IPP (Internet Printing Protocol) to network-printers if the ODF-file was loaded from a SaMBa share through Konqueror. Other applications did this fine, though. After one year the OpenOffice.org development team had not fixed this bug, since then I have not checked again, it might still be there. This is just one of hundereds of such cases I have encountered over the years. There are plenty of Linux tools wich don't support WebDAV and why should they? Why is it not possible to mount an FTP share into the filesystem, like it is possible with GNU HURD and RISC OS? That way all applications with support for loading and saving files from and to the standard filesystem would benefit instantly. Also with all these highly specialised solutions, you also need support for them on the server and they usually open up additional security holes as well.

As for writing HTML by hand: Has it ever occured to you, that some people might prefer not be limited by the tools wich are provided by graphical web-design applications and might thus prefer to write HTML by hand?

JGZimmerle on 31/01/07 02:23AM
[ Reply | Permalink | Report ]

BTW, druck is right, we are getting off-topic and since I don't think we will find common ground on this, I won't continue this time-wasting discussion.

JGZimmerle on 31/01/07 02:26AM
[ Reply | Permalink | Report ]

Julian Zimmerle wrote: "Why is it not possible to mount an FTP share into the filesystem, like it is possible with GNU HURD and RISC OS? That way all applications with support for loading and saving files from and to the standard filesystem would benefit instantly."

That's what FUSE can be used for:

[link]

"BTW, druck is right, we are getting off-topic and since I don't think we will find common ground on this, I won't continue this time-wasting discussion."

Close the discussion if you want, but it's exactly this sort of improvement that would have been good to have in RISC OS. I would have been interested to write a user mode filesystem on RISC OS but the tools for doing it in a high level language didn't exist. Maybe people will finally be able to develop them.

davidb on 31/01/07 11:04AM
[ Reply | Permalink | Report ]

When I first heard the announcement, I instantly thought... great I can dig through the ADFS/FileCore code and make the Linux ADFS driver work properly (full read/write), then I start hearing the'll be ARM platform only clauses.. well that's discouraging, and the likelihood that the licence will forbid the adding of GPL code to the RO source or vice versa as castle couldn't integrate the GPL dependent parts back into there closed source tree... I can only hope for the best, and be ready for the worst.

On the nice dual core 1.2GHz xscale chip, there's no cache coherency/SMP, so I'd go for the single-core version, with native PCIX and PCIe, onboard DDR2... it could be made into something. I'm sure even the development boards can be turned into a simple platform with a 1x PCIe graphics card, and a USB PCI card (have to sling the HD onto the USB.. *chuckle*), probably a bit expensive though.

NoMercy on 31/01/07 9:55PM
[ Reply | Permalink | Report ]

Nothing stops you looking at the RISC OS source code and using the knowledge gained to improve the Linux driver, you just can't use any of the code directly, and having seen some of it you probably wont want to.

The only issue with GPL comes if you want to integrate chunks of GPL code in to an existing RISC OS component, which isn't that likely. There's nothing stopping an independent module or application being included with in a RISC OS build and making the source available to meet the terms of the GPL.

As for the dual core as long as there isn't a faster single core version to use in preference, you can always find something to do with it, cache coherency or not.

druck on 01/02/07 09:09AM
[ Reply | Permalink | Report ]

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

+++ Message board +++

Read messages or start a new thread

Search the archives

Today's featured article

Online banking with RISC OS
We thought this would be of high interest

28 comments, latest by devine on 25/9/05 8:30AM. Published: 1 Sep 2005

Random article

Iyonix compatibility database online
Let's see what works

9 comments, latest by Hertzsprung on 28/11/02 6:49PM. Published: 25 Nov 2002

Create a new account
Forgot your password?

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
"There has been some confusing and controversial reporting of Microdigital's presentation"
Page generated in 0.2805 seconds.