Castle considering open sourcing RISC OS | RISC OS news and information from Drobe


Beta! \| About us \| Contact \| Submit news \| RSS \| Twitter	Webspace \| Tech docs \| Downloads \| BBC Micro \| Gallery \| Wallpaper

Castle considering open sourcing RISC OS

Published: 15th Aug 2006, 01:45:30.

So close yet so far whisper sources [Updated]

The developers of RISC OS 5 are prepared to open source 'elements' of the operating system, acccording to a report in Archive magazine today. Castle boss Jack Lillingston reportedly told Archive editor Paul Beverley on-the-record that the company is "very seriously considering making RISC OS open source".

Jack went on to say that Castle will expect "a small royalty" per use in order to fund an engineer to maintain a central source code tree, although this would be a matter of 'a few pence'. Castle would then become consultants for organisations that wish to investigate and employ RISC OS 5 - Paul reports that Castle rely on writing software for RISC OS-powered STBs these days, rather than shipping Iyonixes and other kit.

The revelation is seen as a surprising u-turn given Castle's previous stance against open sourcing RISC OS; they were even upset at RISCOS Ltd open sourcing parts of the printing system. However, just a few weeks ago, Castle director Peter Wild spoke out with his personal opinion that RISC OS 5 'must be open sourced to survive'. Peter is also selling his electronics company's shareholding in Castle.

In this month's editorial, seen by drobe.co.uk as Archive went to press, Paul wrote: "What is it about me and predictions? What did I say last month? 'Don't get too excited because Jack Lillingston and John Ballance have always been implacably opposed to releasing RISC OS as open-source.' And what did Jack say to me today? 'We're very seriously considering making RISC OS open-source'.

Indications
"If they do decide to go that way, and the indications are getting stronger by the minute, then I'd say it's very good news for the RISC OS community.

"There is still a lot of very positive feeling towards RISC OS, but what we don't have is vast resources to do the development. So, if we can club together and share our developments of RISC OS instead of each company selfishly fighting to keep things in house, it will be better for all of us."

Jack's comments came as Paul interviewed Castle to get their response to an opinion article printed recently in a rival magazine linked to VirtualAcorn. The piece trashed Castle, alledging, "One has to wonder what is going on at Castle. The company has lost its full time developers and all the support staff, and is now operating out of a complex that rents offices by the week. That doesn't sound too promising does it? Is [Peter Wild's] share in Castle up for sale now because it's shortly going to be worthless?"

Minefield
Meanwhile informed sources told drobe.co.uk say that some 20 organisations and third parties have contributed to RISC OS since its birth in the early 1990s, with each component understood to be distributed under a closed license. For instance, a Taiwanese set top box manufacturing giant, rumoured to be MSI, is understood to have licensed the RISC OS 3.7 source code from Acorn, with changes and developments fed back into NC OS - the forefather of Pace's RISC OS 5. Several other organisations, besides Pace Micro, licensed the OS before and after the dismantling of Acorn in 1998.

It's also understood that ANT Plc contributed components to RISC OS, such as ShareFS, a memory management module, and various networking applications. These programs, and many others, were licensed to Acorn and later RISCOS Ltd under binary-only agreements, although the source code may have been supplied for reference. Sources claim that although Acorn, Pace and now Castle may have the source code to these components in their vaults, they do not necessarily own them nor have the right to re-license them.

Supporters of open sourcing RISC OS believe that even if some key components are made available, such as the RISC OS 5 Unicode font manager, then the platform as a whole will benefit. But a well placed contact said opening the source code to RISC OS would be too much of a legal minefield, and that it is written into the licensing paperwork that the operating system remains firmly closed and restricted.

He said: "In my view, Castle don't actually have the right to open source the OS. Acorn and Pace were given code by other parties to bring RISC OS up to standard, but with the intention for it to stay closed source for commercial reasons.

"Open sourcing it without considering the impact this will cause to other companies using the operating system is pretty crap."

Castle were unavailable for comment.

Update at 13:55 19/8/2006
This article originally reported rumours of claims that Tematic staff were owed money by Castle, with access to the RISC OS source code being a possible means of repayment. Castle have informed Drobe that this is not the case, and no money is owed to them. Ex-Tematic staff are said to have had access to portions of RISC OS as contractors.

Ex-Tematic staffer Andrew Hodgkinson said: "Speaking for myself, Castle don't owe me anything. Having to shut down part of a business is never an easy decision to take or an easy thing to do, but to the best of my knowledge Tematic ws shut down in an entirely honourable fashion."

Drobe is happy to clarify this point.

Links
Castle Iyonix website
Archive magazine website - subscribe today. The latest issue is in the post today hot off the printers, and should be in subscribers' hands by the end of the week. Pint-sized Archive is also to undergo a face-lift to mark the start of the magazine's 20th volume

Discussion

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

It is interesting how someone can hold a licensing arrangement and not use it actively while at the same time deny others who could use it. I understand the commercial nature of things but when they have utilised part of it you would think that they would contribute it to the whole, especially if it isn't a threat to their commercial operations.

rmac on 15/8/06 7:17AM [ Reply | Permalink | Report ]

This is all very interesting. And I really hope it all pays off for castle!!

highlandcattle on 15/8/06 8:53AM [ Reply | Permalink | Report ]

I look forward to seeing how ROL react to this. Certainly, RO4 Select has more features and bug fixes than RO5 (IMO) but now that RO5 could be open sourced and attract increased development it would be a serious threat to ROL's survival.

Interesting times we live in.

nx

nx on 15/8/06 8:57AM [ Reply | Permalink | Report ]

Surely CTL cannot open source RISC OS, without getting the approval of all current license holders. Afterall open sourcing RISC OS could pull the rug from underneath the feet of the current license holders.

sa110 on 15/8/06 9:23AM [ Reply | Permalink | Report ]

Excellent news for Virtual Acorn as the licence fee will become 'pence' rather than the high fee currently charged by RISC OS Ltd., making the Virtual Risc PC software much cheaper with no less profit.

CKH2 on 15/8/06 9:56AM [ Reply | Permalink | Report ]

sa110: I note the article refers to open-sourcing 'elements' of RISC OS: presumably those over which Castle holds complete and untrammelled licensing responsibility?

George

bucksboy on 15/8/06 10:07AM [ Reply | Permalink | Report ]

Couldn't certain areas of RISC OS be open-sourced, and others left in binary-only form? For example: if they can't get permission to distribute ShareFS source straight away, that doesn't stop it being available in assembled-module form. I'm sure that just starting to open RISC OS would create a productive tidal wave - any modules with lost or unavailable sourcecode could be replaced with other people's versions anyway. In some cases, it may help remove the "dross" - old legacy code that was in need of replacing anyway.

Congrats to Castle for making a very bold move. Chris' (unnamed) "well-placed contact" sounds like a glass-half-empty sort of person.

krisa on 15/8/06 10:10AM [ Reply | Permalink | Report ]

There is a huge amount of naivety about the open source movement, not necessary by the direct contributors, but by others who hold it up as some sort of panacea – believing and as soon as you make something open source flocks of developers suddenly appear out of nowhere and have an infinite amount of time to work on it. Certain open source projects targeted at a large markets where there are over priced and entrenched commercial rivals such as for a clone of UNIX and web servers are amazingly successful, but for there are tens of thousands of smaller projects which wilt and die through lack of interest or lack of co-operation and leadership. The notion that RISC OS will be transformed by open source is about as realistic as the fairly tail "The Shoemaker and the Elves" – leave the RISC OS source code out over night, and you won’t find the wish list magically implemented in the morning.

Equally there is a misunderstanding of the way the closed source software industry works. Its not all wicked commercial enterprises tightly clasping their closed sources whispering "my precious" like Gollum from The Lord of the Rings. There is a lot of co-operation between suppliers of various parts of the OS and application stack, and they are willing to contribute code to each other in order to implement features that give them a commercial advantage over their rivals. They will not be always willing to make such contributions to an open source OS (or allow one to become open source) as this can give away key information to those rivals. Contracts may even specify API details aren't provided to other users of the OS.

Taking something that's the product of decades of closed source development and contributions from 3rd parties and making it open source, is not a light undertaking, and a potential legal mine field. Sun had to spend thousands of man years of development resources re-writing parts of Solaris before it was in a state where it could be released under an open licence. RISC OS would also require a significant effort to make the entire OS open source, which would be another diversion of our limited resources away from where its needed, which is application development.

Realistically if RISC OS 5 was open sourced, there would only be interest in small parts of it, so it would be better just to make these parts available. I suspect most interest would be in copying the existing Select features such as icon cut & paste in to the window manager, and making the Unicode font manager available for RISC OS 4.X. Things that should have been done by co-operation between Castle & RISC OS Ltd years ago, but show no signs of ever happening. That would be both achievable and a real benefit to all RISC OS users. As for all the grandiose plans of major restructuring of the OS, a lack of resources and focus is likely to make these peter out with in a year or so. Although undoubtedly there will be someone plugging away to make it a "perfect OS" years after the last user has departed through lack of any application development.

druck on 15/8/06 10:12AM [ Reply | Permalink | Report ]

So who are the licence holders?

MikeCarter on 15/8/06 10:14AM [ Reply | Permalink | Report ]

Archive and RISCWorld (strangely the name of the magazine being quoted wasn't mentioned in this article) are not rival magazines. Indeed RISCWorld was set up specifically not to be a rival to Archive. One is published monthly in printed format, the other bi-monthly on CD.

The two magazines actually co-oeprate quite closely, as an example the Archive On Line mailing list is set up for subscribers to either Archive or RISCWorld. Further to this, APDL, the publishers of RISCWorld, also manufacture the Archive CD.

VirtualAcorn on 15/8/06 10:40AM [ Reply | Permalink | Report ]

With luck, it could mean some progress could be made, but it sounds more likely that Castle have simply had enough of RISC OS development, and may just be the death throes.

SimonC on 15/8/06 10:44AM [ Reply | Permalink | Report ]

The unanswered question for me is the following: it might well be that relicencing of parts of RISC OS is not easy or even not allowed (I heard much the same from a variety of people). But is there a need to relicence? The real question is whether there is a restriction on the group of people allowed to see and change the source. One could think of various "pseudo open source" arrangements like Castle operating a CVS server, people who want to have access have to apply and are given the status of a Castle employee.

Also, licencing could be the same as it is now, with vastly reduced prices. As Jack put it: "a small royalty". I doubt that the licencing restrictions on most of RISC OS would preclude an arrangement like this.

hubersn on 15/8/06 11:20AM [ Reply | Permalink | Report ]

Just a thought; Could the mysterious RISC OS Open Ltd be behind Castle's sudden 'change of heart' regarding the legal status of RISC OS 5? I particularly like to quote the following lines from the article:

"In a further twist in the story, there are rumours that RISC OS Open Ltd, a new company backed by ex-Tematic and Pace staff, are to be given access to the RISC OS 5 source code from Castle. The engineers are believed to be owed cash from their time at Tematic, and the hand over of RISC OS source code could be one form of payment open to them."

Furthermore I like to agree with druck about the 'open source fairy tale' - the wellspread success stories of Firefox and Linux have probably contributed to such a misplaced belief. However, on balance I believe open sourcing various parts of the OS may give it a better chance of enjoying development than the current state of affairs allows. Therefore I hope they proceed with it and all parties, not just end-users, may share any benefits coming from this move. Contrary to what some people may think, simply open sourcing a software project does not necessarily mean no money can be made from it anymore. Perhaps this move may even force the likes of Castle and ROL to cooperate more. Keeping my fingers crossed...

hEgelia on 15/8/06 11:25AM [ Reply | Permalink | Report ]

I think open-sourcing RISC OS and possibly a "pence" license fee would tempt me back to the fold, assuming that the VirtualRPC-SE or or -SA prices would plummit when you take the RO4 fee out - although aren't they ROL licenses, not Castle - or is that just the Adjust versions? Mind you, there's still not a Linux version is there?

Not sure how Castle opening RO5 would affect ROL's Select/Adjust, being based on RO4. I would expect the first thing after going open would be someone would develop RO5 HAL's for the A9/RPC/VA and completely kill Select/Adjust.

I wonder if a GPL or BSD license would be favoured, or some made-up thing so Castle could maintain control.

Hey we could even see Xara Xtreme ported back to RISC OS!

That said, with a lack of new hardware (A9 is nothing wonderfully new, and Castle has no XScales after their current stock) even an open OS couldn't last much longer via emulation, I wonder if anyone would have enough interest to port an open RISC OS to x86?

simo on 15/8/06 12:27PM [ Reply | Permalink | Report ]

Unfortunately I tend to agree with SimonC's comment, that this could signal Castle's final loss of interest in RO development, and by extension, RO hardware development. Since they produce the only fully-developed RO ARM computer to appear since Acorn's demise, this, if true, is concerning.

bucksboy on 15/8/06 12:58PM [ Reply | Permalink | Report ]

simo: A license fee wouldn't be enforceable with any of the traditional open-source licenses such as GPL or BSD [link]

For those commenting that open sourcing it won't necessarily sort out all the problems or be perfect what's the alternative? If the article is correct and Castle no longer have their engineers and with ROL output of Select completely absent for years, what is there to lose?

flibble on 15/8/06 12:59PM [ Reply | Permalink | Report ]

The one thing that worries me about RISC OS (and I'm sure this would have been one of the reasons many people left the platform, before the release of the Iyonix/A9) is whether there will be any further development of both the OS and the hardware to run it on. If open sourcing RO makes it more likely that Castle and others will be able to get OEM work (as suggested by Peter Wild) then it would presumably be a positive development.

But whether or not open sourcing drives more development, from the desktop perspective it does at least mean that the OS cannot disappear suddenly if the owning company (like Castle or ROL) disappear, as almost happened with Acorn. Moreover, it opens the possibility for RO to be made to work on any of the many interesting ARM devices that are already out there, which would be great.

So I'm with flibble on this. Open sourcing won't necessarily solve all of RO's problems, but there may not be a great deal to lose. The only possible danger is that there might be massive branching, and maybe this could be controlled by Castle/ROL? I think it could well be a very positive thing from the users' perspective.

flypig on 15/8/06 1:28PM [ Reply | Permalink | Report ]

fibble:

You can dual license code under a commercial and GPL license so that most commercial clients would have to use the commercial version. This is what MySQL do very successfully.

markee174 on 15/8/06 2:01PM [ Reply | Permalink | Report ]

simo: I am mystified by your comment regarding Xara Xtreme. What does that have to do with RISC OS being open source?

If you want to port Xara LX to RISC OS you are welcome to start any day.

Incidentally, XaraLX is most of Xtreme, except unreleasable third-party closed source code components - which may sound like a familiar problem and brings us back on topic :-)

wuerthne on 15/8/06 2:11PM [ Reply | Permalink | Report ]

markee174: "so that most commercial clients would have to use the commercial version", if it's dual licensed there's nothing you could do to stop a commercial client using the GPLd version (or any other license that follows the open-source definition [link]).

flibble on 15/8/06 2:31PM [ Reply | Permalink | Report ]

fibble:

Not if you GPL your code. But if you want to keep it commercial you would want the commercial license.

GPL license is very different from DSD license. The term Open-sourced is so vague as to be meaningless really.

markee174 on 15/8/06 2:34PM [ Reply | Permalink | Report ]

flibble: Commercial clients are probably not going to be want to held to the GPL restrictions on what it does to their stuff. The commercial license will probably give fewer restrictions, but will cost*.

I think all we really want is an indication that there is going to be a future, whoever and however it's developed.

* based entirely on assumptions, I've no idea how MySQL do it.

SimonC on 15/8/06 2:36PM [ Reply | Permalink | Report ]

Support is also a motivator for taking a commercial licence: your open source licenced version will be only supported by the community, but by selling support alongside your commercial-licenced version[1] you can add value for your clients.

Copyright attribution becomes an important factor here, though: for Castle (say) to sell a closed source version and maintain an open source version, anyone submitting code to the open source one would in practice have to transfer the copyright to Castle for them to do with as they wish. Once it's open sourced, though, it can never be closed again: even if future development only happens in the closed branch, the open version can live on.

[1] Of course, you can still sell support and services without having a closed source version.

Jaffa on 15/8/06 2:46PM [ Reply | Permalink | Report ]

But wouldn't an open source version, minus the bits that can't be open sourced just create yet another version of RISC OS for the few remaining developers to contend with?

sa110 on 15/8/06 3:01PM [ Reply | Permalink | Report ]

markee174: If Castle were to grant me code under the BSD license (I presume the DSD was a typo) I would still be able to do what I wished with it without paying them a fee. Read the license here, [link] Dual licensing allows people to choose which of the two licenses to be bound by, it would not allow Castle to say, use this one when I tell you, or this other one when I tell you. The other 57 licenses listed here [link] would also not allow Castle to charge a license fee.

What is suggested above in the article is a commercial software model which uses public contributions, in which the code is viewable but contributors have no guaranteed rights to it, it is not an open source model. Microsoft has released the source code to several programs under terms similar to this.

If Castle want to Open Source RISC OS, they should. If they want to keep it commercial, they should. But by confusing the two whilst making up 'Yet another license' will confuse and limit contributions, the 'Open Source' community [1] is very vocal and will have no issues vilifying Castle if Castle were to claim their commercial license was 'Open Source'. Whereas that very community is the one you wish to engage if you want to leverage their huge skills base [2].

[1] The FSF, OSI, OSDN, Sourceforge, Slashdot etc etc etc. [2] I know of several former RISC OS programmers that currently work on Open Source projects that could be temtped back in to the fold if RISC OS were to be open sourced.

flibble on 15/8/06 3:02PM [ Reply | Permalink | Report ]

Personally, I don't care if there's another version of RISC OS to contend with. If it's regularly developed, openly; moving forward and easy/cheap for users to migrate to it'll become the "standard" version *very* quickly.

If the options are two stagnant branches, or two stagnant branches and a developed one; I know which choice I'd go for.

To prevent multiple forks, proper community and leadership which listens and responds constructively will be required. No, it won't be as big as Linux, but looking to see the problems and successes there will be helpful in setting up an open RISC OS.

Jaffa on 15/8/06 3:05PM [ Reply | Permalink | Report ]

SimonC: MySQL sell support services related to their product, and fully certified versions that large enterprises need to make the their risk management people happy.

sa110: In theory it might solve some of the compatability issues, if freely redistributable versions of some of the code that is different between versions 4 and 5 was available as a softload on the other, programmers could write to one API and all versions would be able to run their code.

flibble on 15/8/06 3:11PM [ Reply | Permalink | Report ]

fibble:

If Castle release the code under A BSD license you can do whatever you want with it. You could use huge swathes in your program and never even mention it. BSD licenses only work as commercial entities if there is a large consultancy business ontop (as with say Samba) or you have commercial companies funding it as with many of the Apache foundation projects.

If the license is under GPL you would have to release your code under a GPL license if you used a single line of it. So in practise many companies would prefer to have a commercial license on it. That would be the revenue source, along with support.

That is why many commercial companies in the OS sector release code under a dual license.

markee174 on 15/8/06 5:18PM [ Reply | Permalink | Report ]

markee174: Your last post is entirely correct with regards for licensing. But it's worth remembering tha a GPL license hasn't prevented Linux becoming probably the most popular embedded OS out there (even though there might be more suitable choices), and it has no commercial version for those that want to avoid the GPL. This is because although the GPL requires changes to the kernel to be made available under the GPL, the applications, where most companies work exists (in the embedded market) do not have to be licensed under the GPL. Lots of commercial companies are willing to put up with submitting the few hundred lines of changes they made to the kernel for free in exchange for not having to pay a license on each of the thousands of units they ship.

It's difficult to argue for a pure open source RISC OS without saying "what's in it for Castle"

It's difficult to argue for a non pure open source RISC OS without saying "what's in it for the contributors"

flibble on 15/8/06 5:52PM [ Reply | Permalink | Report ]

fibble:

I don't understand your point. Open Source is a meanless term because it means potentially lots of different things depending on license type.

Castle would release their code under a GPL license to address the issues raised by Peter Wild and to try to create a much bigger target market of which they could take a slice with support and commercial licensing. I cannot see Castle releasing it under a BSD or Apache style license.

They do this because it makes better business sense than keeping the code closed - no other reason.

markee174 on 15/8/06 6:05PM [ Reply | Permalink | Report ]

markee174: 58 licenses including all the ones you mention fit this definition, [link] have you read it yet, I've mentioned it 3 times now?

There are aditional responsibilities with some licenses, but they do not contradict the points in that definition.

The complexity of commercial and open source licensing comes from this, "If Castle were to accept code from members of the public under the terms of an open source license, Castle would not own the copyright on those contributions, they would have to ask permission to distribute them in a commercial product".

The OpenOffice project gets around that issue by asking contributors to assign copyright to Sun (who own the rest of OpenOffice) so Sun can sell their StarOffice product. As you'd expect with your work that you provided for free being used to make a company profit, it's not universally liked.

flibble on 15/08/06 6:22PM [ Reply | Permalink | Report ]

fibble:

Yes I have read it, but when you translate it into actual practise, there are major differences between LGPL, GPL, Apache and BSD licenses (to mention just the most common).

MySQL also asks for copyright so they can dual license their code base.

What I think most interesting is what Castle see as the business model behind an OS version. That is what drives everything else.

markee174 on 15/08/06 6:40PM [ Reply | Permalink | Report ]

They are considering open sourcing "elements" of RISC OS. I would very much like to have a go at two of these elements: the CDFS driver, and the USB podule stack. I'm sure some of you can come up with more such elements to add to the list. I have suggested to John Ballance the idea of open sourcing those two.

With a suitable license, it is possible to open source appropriate parts without giving away the whole lot.

davehigton on 15/08/06 9:58PM [ Reply | Permalink | Report ]

I agree with flibble here: people in the RISC OS scene (with a relatively low level of awareness in such matters compared to other communities) seem to think "open source" has some vague meaning related to seeing the sources, when in fact the term is precisely defined in terms of various fairly well-established guarantees. Certainly, you can sell open source software - indeed, you can sell GPL-licensed software as long as you uphold the terms of the licence - but the notion of people paying Castle on a per-use basis shows an element of ignorance that would suggest that Castle merely want to offer the code under some kind of "shared source" agreement. If that's the way all this goes, we'll see a "shared source" licence which is actually less free than some of Microsoft's licences.

But seeing as the "few pence" per use will go towards some kind of central repository maintainer (I guess we'll see elements of current revision control trends appear in the RISC OS scene in about 2015), it looks like Castle isn't in a position to procrastinate forever on this: if the RISC OS Open people are still owed salary and Castle still needs to raise small sums which are presumably not being levied on some point of principle, my guess is that the RISC OS Open people have a stronger hand than most people previously believed. RISC OS may end up as a genuine open source project whether Castle like it or not.

guestx on 15/08/06 11:05PM [ Reply | Permalink | Report ]

I'm genuinely pleased about the news that RISC OS might be open source, but I hope that it is more than just a token gesture. To be able to attract the amount of contributors needed for the large amount of OS development which is needed, a license with sufficient freedom must to be chosen.

I also hope that whoever joins the development party is willing to co-operate. If the same silly attitudes which we've been putting up with for the last few years go on, Open Sourcing is only going to make things worse (writing replacements for proprietary modules which already exist and could be open sourced, for example).

Although you could say this is bad news for ROL, it could also be a godsend. If the time it has taken them to complete Select 4 is anything to go by, we are going to be waiting ten years until their next major release comes about. If they do choose to go down the line suggested by Peter Wild (developers of Premium Desktop Enhancements) and they incorporate developments from the Open Source community, then there should be more releases more quickly, since they wouldn't be doing *all* the work.

A suggestion on how they might continue to offer similar products: ROL develops Premium Extensions compatible with Open RO which are initially closed source. The Select scheme continues, allowing users access to bleeding-edge, premium updates. ROL sell ROMs of their latest stable Premium version in parallel to open-source ROMs. When next Premium version is due to be released, remaining proprietary features are open sourced. ROL could also offer Paid Support to other customers in addition to supporting Select subscribers and Premium ROM customers.

timephoenix on 16/08/06 09:41AM [ Reply | Permalink | Report ]

If Castle's initiative goes forward I hope it will help to revive the platform, and as others have said above, there are reasons to hope this might be so. But let's not lose sight of the fact that the main reason why RO is now a borderline standalone computing solution for a home user such as myself has nothing whatever to do with the OS or, for that matter, with hardware: it is the lack of a satisfactory browser. Since Peter Naulls stopped work on Firefox, the only ongoing development is to Netsurf. I have been using this for several months and it is a nice fast, lightweight browser, but you can't do internet banking, order airline or theatre tickets, or interact with any site requiring Flash or javascript, so I carry on with Firefox, cumbersome and underdeveloped as it is. Will we ever see Oregano3? I doubt it. While this state of affairs continues the platform will continue to leak support regardless of developments to the OS or the hardware IMO.

bucksboy on 16/08/06 10:52AM [ Reply | Permalink | Report ]

George:

Definitely the browser remains the weak point.

Especially as a lot of software is now appearing which effectively runs inside a Browser window or has a broswer option).

markee174 on 16/08/06 12:12AM [ Reply | Permalink | Report ]

guestx:

"...the notion of people paying Castle on a per-use basis shows an element of ignorance that would suggest that Castle merely want to offer the code under some kind of 'shared source' agreement."

Perhaps I'm misunderstanding what you're suggesting here, but I don't see why (as others have suggested) Castle can't be talking about some kind of dual licencing agreement. Lots of open source vendors do this, allowing them to release the source under a genuine open-source licence, whilst at the same time charging commercial users who choose the commercial licence: [link]

Timephoenix makes a good point about the ROMs. There's nothing to stop RO Ltd carrying on in exactly the same way they already are even with RO open sourced. They just use the commercial licence or charge for putting the open source version into ROM.

flypig on 16/08/06 12:22AM [ Reply | Permalink | Report ]

ROL carrying on the same way - you mean getting people to pay 3 years subscriptions for nothing? Well at least if RO5 was open sourced that damaging disgrace to the RISC OS market would end. The handfull of really useful Select UI features could be easily incorporated in to RO5, and thats an end to the stupid will they wont they game they continue to play over Select on the Iyonix.

With an open source release of the HAL and Castle created drivers, even if a core of the OS had to be supplied as a binary for licencing reasons, it would still be extremely easy to port to any ARM device. So why would anyone like STD then go to ROL for their version.

druck on 16/08/06 1:34PM [ Reply | Permalink | Report ]

druck:

Yeah, when I said "carrying on the same way" that's not quite what I meant!

Having said that, whilst I personally think the situation relating to ROL and the Iyonix is crazy at best (damaging ROL as much as anyone else) and have complete sympathy with Select subscribers, I nonetheless personally don't think that open sourcing would necesarilly make ROL redundant. After all, STD could have gone to Castle rather than ROL anyway. Presumably ROL brought expertise that STD valued?

If making RO open source damaged ROL, then I imagine it would never happen at all, since it would just result in yet more potential legal action. That would not be good.

flypig on 16/08/06 3:04PM [ Reply | Permalink | Report ]

Flypig:

"After all, STD could have gone to Castle rather than ROL anyway. Presumably ROL brought expertise that STD valued?"

Or else STD were (understandably) reluctant to license a vital component of their product from a direct competitor - which is, after all, why Acorn span off ARM. It's also possible that they approached both companies, and ROL said they could make RO4 fully 32bit for less money than Castle thought it would cost to make a RO5 HAL for the A9. Or something else in a similar vein....

chrisj on 16/08/06 3:23PM [ Reply | Permalink | Report ]

To flypig: "I nonetheless personally don't think that open sourcing would necesarilly make ROL redundant." Surely not, since with their current track record they seem to try to achieve that goal by themselves ;-)

To flypig/chrisj: "After all, STD could have gone to Castle rather than ROL anyway. Presumably ROL brought expertise that STD valued?" AFAIK they asked CTL and ROL and then the decision was based on the reply/offering they got in return ... and perhaps to a certain amount that STD/Ad6 are closer to ROL than to CTL.

To druck: I agree!

hzn on 16/08/06 3:40PM [ Reply | Permalink | Report ]

I remain to be convinced *any* of this is going to happen.

We have Peter Wild originally suggesting that RO be open sourced, the inference being that if *his* shares were bought that somehow Castle would be "persuaded" to open source RISC OS. Point is he had *plenty* of oppertunity to make Castle see the "wisdom" of that course while *he* held the shares yet RO5 is still *closed*, so how come? Was it (i). He couldn't persuade them (ii). 25% just don't cut it ? Either being the case I don't see why changing the ownership of 25% of the voting stock and handing it to RO Open will make much difference. I asked this question before and NO ONE bothered to answer.

As to the central contention that Castle are "considering" opensourcing it - well I am considering winning the Lottery - but that doesn't mean it's going to happen ;-)

. No company with any nouse would *not* consider all its options - this does not necessarily translate into any considered course being taken though.

If (and this is a conjecture) RISC OS were to be open sourced - then I'd suspect some parts would be open while others would be "binary only* (as others have suggested). Regarding the nature of the license it doesn't need to be (and probably shouldn't be) GPL. Possibly LGPL or perhaps even a license "concocted" for the RISC OS release (and this could be open enough to allow code sharing and development without damaging RO's commercial prospects (e.g., restricting use to native ARM hardware (no emulation), non-porting to other OS'es and so on - all measures to prevent any useful bits being stripped from RO by "oppertunists" who'd take without giving back to the platform).

That all being said I still think there are elements of Drobian speculation at work - and would be more comfortable hearing the outcome of Castle's consideration from the horse's mouth (as it were). In short let's all wait and see what happens.

As for ROL, I think Nelson of the Simpsons says it best "Ha, Ha...."

AMS on 16/08/06 7:45PM [ Reply | Permalink | Report ]

I reckon we will see RO5 sources become available as some sort of open-source. If you remember back to how RO5 came about, it was down to Pace engineers somehow getting the source code when they left Pace plc.

Now that Castle have effectively got rid of all their hardware and software engineers I reckon the same thing is going to happen all over again. We'll have another variant of RO.

Lets hope something good comes of it. RO6 anyone?

nx

nx on 16/08/06 9:10PM [ Reply | Permalink | Report ]

AMS:

"I asked this question before and NO ONE bothered to answer."

Probably because any answer given would just be speculation. Oh, hang on... ;-)

"well I am considering winning the Lottery - but that doesn't mean it's going to happen ;-)

"

The difference between that and CTL considering an open source release being that you can consider winning all you like - but you can't actually decide to win.

"If (and this is a conjecture) RISC OS were to be open sourced - then I'd suspect some parts would be open while others would be "binary only" "

Umm. Quite. That would be why the article refers to 'elements of RISC OS'

VinceH on 16/08/06 9:13PM [ Reply | Permalink | Report ]

VinceH>Actually I deliberately put off winning the lottery for three weeks....

As to my original point it still stands, considering something doesn't mean it will happen. My point about why changing the ownership of 25% of Castle's voting shares should make a difference also stands. I mean Peter Wild has written at some length as to *why* it would be a good idea to open source RISC OS, he has the 25% of the shares - surely if that *means* anything then he'd have recommended that (and had that outcome already). Simply handing that 25% to someone else I don't believe will make any difference. But I'd be happy to be proven wrong.

nx wrote>"Now that Castle have effectively got rid of all their hardware and software engineers I reckon the same thing is going to happen all over again. We'll have another variant of RO."

Have they, or is that just another Drobe "look the Iyonix CPU is out of production", "the EU has banned the Iyonix" type rubbish is it?

If that were true then it would mean no more new native hardware to run RISC OS. Might as well shrug my shoulders and content myself with writing C# code on windows as effectively RISC OS would be dead. When RISC OS becomes something you emulate on a PC (and only on a PC) then I see little point in continuing with it. Feel free to disagree, I'll refer you to Monty Python's dead parrott sketch which adequate would sum up that situation if it were to occur ;-)

AMS on 16/08/06 9:38PM [ Reply | Permalink | Report ]

AMS:

If you stopped not winning the lottery you could buy the code, put it out under a BSD license and hire 100 developers to work on it ;-)

markee174 on 16/08/06 9:42PM [ Reply | Permalink | Report ]

AMS:

I agree with Mark. Do you realise how utterly inconsiderate you are being to the RISC OS community by not winning the lottery?

But seriously, yes, I agree their considering it doesn't mean it will happen - but my point was that it could, and that outcome is entirely up to them (subject to contractual/licencing issues already mentioned). All the speculation in the world - positive or negative - will not change that.

VinceH on 16/08/06 9:48PM [ Reply | Permalink | Report ]

AMS:

I'm quite intrigued by what you're suggesting. Unless I've misunderstood, you're saying that Peter Wild thinks that by selling his shares, he can induce Castle to OS the OS? Personally, I (genuinly) can't see where you've got this interpretation from.

From my reading of earlier articles, I understood that Peter Wild intended to sell his shares due to a disagreement with the other shareholders. I think we can only speculate as to what this disagreement really relates to, except to say that Peter wanted Castle to grow quickly in the STB area and then be bought up, whereas the others had other ideas.

Drobe seems to imply that Peter's enthusiasm for open sourcing the OS might be so that he can "make use of the IPR without being tied to Castle". Alternatively it could be simply that he thinks this will help promote the platform in embedded markets (as he said in his post here on drobe).

Either way, I don't see where the implication that selling his shares is intended to make the open sourcing more likely comes from.

Perhaps, as an alternative theory, the threat of selling his shares and the surrounding coverage has simply made Castle more serious in considering it as an option. Agreed, there's no guarantee at all that it will happen, but the article claims that they are not just "considering" it, but "very seriously considering" it, so it surely is a possibility?

Please don't take this as an attack, I'm just curious as to how you came to the interpretation you did, as I've clearly missed/misunderstood something.

flypig on 16/08/06 10:19PM [ Reply | Permalink | Report ]

If Castle Open Source they still own the copyright on their code. And they could release it under several licenses. How other people can use it depends on which OS license they adopt. Nobody can revoke their license or rights.

markee174 on 16/08/06 10:22PM [ Reply | Permalink | Report ]

Mark/Vince>You're right what was I thinking of... and there I was worried about winning the lottery interfering with my social schedule, I deserve to be criticised. I'll make appropriate arrangements forthwidth :-)

AMS on 16/08/06 10:23PM [ Reply | Permalink | Report ]

flypig>Man it's all speculation isn't it anyway. PW seemed to be keen on OpenSourcing RO, yet was trying to sell his shares which would remove his ability to influence that decision surely. It was also hinted (I believe) on Drobe that RO Open might be buying the shares. Surely the best way for PW to influence Castle's deliberations surely would be to do so *while he held onto the shares*, once sold his influence would be zero. If on the other hand he was actively promoting Open Sourcing RISC OS then this had got us no further than having Castle "consider" doing so, I can't believe anyone else purchasing the shares would do any better.

And in the end, in any event, Castle could *still* decide to say "nope we're fine with things as they are", 25% of shares don't outvote 75% of shares last time I checked.

AMS on 16/08/06 10:31PM [ Reply | Permalink | Report ]

AMS:

Thanks for the explanation. I can see what you're saying then, and of course you're right: PW is surely going to have more influence while he's still a shareholder. Guess we'll just have to wait and see... (and maybe speculate a bit more in the meantime

flypig on 16/08/06 11:38PM [ Reply | Permalink | Report ]

AMS:

I thought the article implied RO Open might get access to ther source code in lieu of backpay.

markee174 on 17/08/06 05:56AM [ Reply | Permalink | Report ]

If PW did convice Castle to Open source while he had his shares, then there would be no incentive for RO Open to buy the shares after the event - why bother? RO would already be Open sourced.

nx

nx on 17/08/06 09:15AM [ Reply | Permalink | Report ]

flypig > No problem !

Markee wrote >"I thought the article implied RO Open might get access to ther source code in lieu of backpay."

The article does indeed imply that that's the case, but is that substantiated anywhere independantly, and surely if Castle feel obliged to "open source" RO as a means of "paying" RISC OS Open/Tematic former employees then what PW (or his shares) says doesn't matter a jot does it? Which brings me back to my original question about the whole shares/open sourcing mallarkey.

nx wrote >"If PW did convice Castle to Open source while he had his shares, then there would be no incentive for RO Open to buy the shares after the event - why bother"

Indeed, which was the whole point of my line of argument. Buying/not buying the shares has (IMHO) *no* effect if the current article is correct. In fact in one prior Drobe article it appeared as if one of the RO Open participants wasn't even aware of PW putting his shares up for sale when they started their little endeavour.

I quote - When asked if there was any connection between Pattotek [Peter Wild's company] selling off its Castle stake and the appearance of RISC OS Open, Steve [Revill] added: "I don't know what the rumours are but I only learned about the proposed sale of shares by Pete Wild on Thursday July 6. I can't really think of any way that this will affect what RISC OS Open is planning."

[extract from Drobe article [link]]

Safest thing to do for the moment (IMHO) is to wait and see what Castle decide, speculation gives me indigestion ;-)

AMS on 17/08/06 8:03PM [ Reply | Permalink | Report ]

From the article: "Open sourcing it without considering the impact this will cause to other companies using the operating system is pretty crap."

Why does the unnamed mystery source in the Drobe article assume that Castle wouldn't talk to any relevant third parties first? Meanwhile, would any company still using RISC OS today that will have its business influenced by open sourcing please raise their hand? Yes? Anyone? Anyone at all?

(Tumbleweeds roll past, only one hand is raised...)

RISC OS Limited will of course see an impact if the operating system source code were to be released to the public under some kind of licence(s), but not necessarily a negative one. Given this article, we don't know anything about the amount of source code either - it could be a long way from a complete operating system.

All in all, a disappointing article in my opinion - a small amount of fact from Jack, then a lot of inaccurate guesswork. For example, I can't speak for anyone else at Tematic, but I'm quite happy to state that as an ex-Tematic engineer, I'm not owed anything (well, not as far as I know!). Not that anybody bothered to do some research and, say, *ask me* about it before going to press. Sigh ;-)

adh1003 on 17/08/06 8:56PM [ Reply | Permalink | Report ]

If Castle’s finances are so bad that not only have they got into the position of owing back-pay, but are also looking at having to pay it ‘in kind’, then the discussion may be academic since they may not last long enough to open-source anything.

dms on 17/08/06 8:58PM [ Reply | Permalink | Report ]

David: "owing back-pay, but are also looking at having to pay it ‘in kind’"

See above. Speaking for myself, Castle don't owe me anything. Having to shut down part of a business is never an easy decision to take or an easy thing to do, but to the best of my knowledge Tematic was shut down in an entirely honourable fashion.

adh1003 on 17/08/06 9:00PM [ Reply | Permalink | Report ]

Andrew> Ok, so (somehow) Drobe have inferred that Castle *didn't* pay Tematic staff their due, yet you as one of said staff have just confirmed that "to the best of your knowledge" Tematic was shut down in an entirely honourable fashion.

Ok, so Drobe seem to have got it wrong.

Ah but then it is an article about Castle, that explains it ;-)

AMS on 18/08/06 6:39PM [ Reply | Permalink | Report ]

Which would suggest that at least that element of the article was guesswork/speculation.

Opensourcing (in whole or in part) would have several impacts. 1. Increased software development options. 2. Increased hardware development options (including the possibility of porting code to other platforms) 3. Remove development overheads from Castle so it can concentrate on its STB business whilst (possible) keeping a revenue stream depening on the RO licencing arrangments. 4. Put ROL in the tricky position of continuing (allegedly) to develop RO4 via Select, or supporting an Open Sourced version that is updated by a wider community.

Number 4 is probably of the most interest here (and links in with no 1), as it means that ROL could maintain a RO 'Core' build while managing Open Sourced projects for other parties. It remains to be seen if they would fork the OS. I suspect there would be no more RO5 development per-say, and that the 32 bit version of RO4 would be ported to the Ionyx to merge the forks. This allows ROL to control the full RO (ARM) market.

Sorry there's a lot of of 'ifs' and 'buts' in there, but its the most logical path (IMHO), should Open sourcing go ahead.

JDC on 18/08/06 6:55PM [ Reply | Permalink | Report ]

JDC>In my humble opinion probably the only part of the article that *isn't* speculation is the part where the Archive article is quoted as saying that Castle is *considering* open sourcing RO.

And that is still no more or less than *considering*. It *may* or *may not* happen.

If one were to assume that Castle *were* to open source RISC OS (and remember it's RISC OS 5 - they don't have full source for Select as parts of that are ROL's baby) your assertion that RO5 development would cease is no less speculative than the whole article.

If RO5 were open sourced programmers would be free to add to it User Interface features that parallel those in Select (without using Select Sources either). The end result would be a more portable/modern RISC OS that users could use *instead of select* and yet not lose the Select UI features yet gain all of RO5's advantages. Programmers could enhance CDFS and other bits and pieces... in short rather than having a limited development resource there would be a rather broad one supporting RO5.

The question then would be what of ROL and Select ? Indeed......

AMS on 18/08/06 7:27PM [ Reply | Permalink | Report ]

Agreed, although I should point out that there were no assertions there, it was my opinion.

JDC on 18/08/06 9:26PM [ Reply | Permalink | Report ]

I am more concerned about the disappearance of Hardware Developers. If Castle are too busy building enbedded RISC OS based set top boxes, who is going to build the replacement for my Iyonix when it eventually goes to silicon heaven in five or six years time. Will anybody be interested in building a box that uses a minority interest Open Source operating system. With Linux, all you have to do is buy a bog standard PC and replace Windows. RISC OS requires ARM based chips that will work in a desktop machine, and porting RISC OS to devices that run mobile phones will have no use if those deviced cannot be made to run a desktop computer.

JWCR on 18/08/06 11:41PM [ Reply | Permalink | Report ]

@JWCR: We have already discussed a number of options to make an open sourced RISC OS less dependent on ARM hardware.

JGZimmerle on 19/08/06 02:07AM [ Reply | Permalink | Report ]

JDC>Yep, it's to a large extent all speculation - just (to a large extent) like the article.

JWCR>Indeed I agree with you on many of your points. The thing is RISC OS runs *best* on ARM, no emulation required etc. I'd also caution that open sourcing RISC OS has *no implication* for the availability (or otherwise) of Castle's hardware. The OS and the Hardware are *separate issues*. In fact if open sourced it may be possible for Castle to better leverage the hardware designs that they have. In fact they *could* have a bit of a renaissance (selling the motherboard and access to the source to "enthusiast" developers). This (and sales of the C/C++ tools) and "minor" license royalty charges may be enough to keep the development going. Be sure that if Castle *do* open source RO - they *still* have to make money somewhere (consultancy and hardware) that being the case I'd suspect *more* hardware development will happen *not* less.

And before our Linux inclined friends pipe up - I'll add the comment that Open Source (in it's fullest sense) could have RISC OS running (under a free emulator or after some form of "translation") on Windows. Think of it as a free alternative to Virtual Acorn. Open sourcing RISC OS may just move more people to Windows.... (personally after the Native on Arm option, the next most favourable option would be Linux - but there is *no* guarantee of that).

If RISC OS were open sourced I'd suggest that it use its own specific license (there is precidence for this in things like the Mozilla License). The license could explictly forbid the reuse of the source in other OS'es (to stop "cherry picking"), restrict use to ARM or compatible hardware - but otherwise leave people free to contribute and obtain source.

Julian>Come on man, you used to be a big supporter of Omega and *now* rather than fall in behind the most advanced remaining RISC OS compatible machine (Iyonix) you'd rather support moving us all to Linux and x86 - is it *really* that difficult to encourage people to support native hardware even if it happens to be from Castle ? Really ?

Anyway I don't know why everyone is getting so worked up about a largely speculation based article. All or none of the above may occur, we've seen all the horror stories already (e.g., Iyonix CPU out of production, EU bans Iyonix, Castle ate my hamster) so just take it all with a pinch of salt - wait and see.

AMS on 19/08/06 4:56PM [ Reply | Permalink | Report ]

All the commentls about open source imply that RISC OS would be made into some sort of freeware. But this doesn't follow.

The sources could be made available, without giving the OS away for free. The licensing for the OS could remain the same as it is currently. But it would still mean that modifications could be made more easily (and presumably distibuted as patches, and if appropriate included in the main distribution).

It would still make it easier for different hardware to be supported.

With respect to RISC OS on other architecture, I think that would be OK as long as the system included an ARM emulator.

Programs would still be arm code. Modules could be either native or ARM, the OS would be native.

I believe this would protect the potential for native machines, since all programs would remain compatible.

jess on 19/08/06 6:05PM [ Reply | Permalink | Report ]

AMS: "If RISC OS were open sourced I'd suggest that it use its own specific license (there is precidence for this in things like the Mozilla License)."

The motivation presumably being the desire to establish a community where independent developers are not equal to the corporate developers, perhaps.

"The license could explictly forbid the reuse of the source in other OS'es (to stop "cherry picking"), restrict use to ARM or compatible hardware - but otherwise leave people free to contribute and obtain source."

Previous "shared source" initiatives of which you write have generally not been very successful, mostly because potential developers have seen through the pretense and have noticed that they're being invited to do work for some company where they not only get no reward for their own work, but they also have retain no control over their own work, either. Most people either for business or for ideological reasons would rather spend their time on genuine open source projects, understandably.

jess: "All the commentls about open source imply that RISC OS would be made into some sort of freeware."

The term "freeware" belongs in the 1980s. Most of the comments about open source from people who know what they're talking about are precisely about "open source", not some kind of ill-defined "no money involved" hand-waving exercise.

guestx on 19/08/06 7:38PM [ Reply | Permalink | Report ]

GuestX: I should have said "many of" rather than "all". But the assumption in a lot of posts is that Open source = GPL or similar. This does not have to be the case.

jess on 19/08/06 7:52PM [ Reply | Permalink | Report ]

jess: "But the assumption in a lot of posts is that Open source = GPL or similar."

No, but the use of the term Open Source refers to something specific and (generally) well-understood.

[link]

I get the impression that large numbers of commenters both here (and, at other times, in csa.*) really don't quite *get* it, mainly due to the lack of understanding of a) what it means vs. "shared source"; and b) viable business models based around it.

In fact, many seem to be of the same opinion about OSS as Microsoft - ironic given the often vitriolic stance taken against their software ;-)

Cheers,

Andrew

Jaffa on 19/08/06 8:09PM [ Reply | Permalink | Report ]

In reply to Jess Hampshire:

"All the comments about open source imply that RISC OS would be made into some sort of freeware. But this doesn't follow."

It does follow if 'open source' is taken to mean 'compatible with the Open Source Definition'.

If that isn't what you mean then it really would be better to use another term. The OSD is a very well established definition now, and using 'open source' to mean something else can only lead to equivocation and confusion.

gdshaw on 19/08/06 8:41PM [ Reply | Permalink | Report ]

fwiw, here's my opinion:

RO only runs best on ARM because it can't run natively on anything else. I would happily see it ported to run natively on other hardware, which in practice means (or at least includes) Intel's x86 line because its cheap, readily available and - importantly - is much faster than any ARM-based hardware.

If RO, or at least the key parts, were open sourced then it could save a lot of time by allowing porting rather than complete reimplementation, or at the very least serve as a reference implementation to answer the "what does RO do in this case?" questions without writing a lot of test code.

With a dwindling market making commercially viable development impossible, and us programmers only able to chip in with what we can do in our spare time, I believe it's our best path forward.

adrianl on 19/08/06 8:50PM [ Reply | Permalink | Report ]

graham shaw: Isn't the Royalty that Castle would expect at odds with the OSI definition?

Please don't take my comments as being against the idea of Open Source (OSI) of RISC OS, just that I think it is too much to expect at present.

But making the sources available would still be of major benefit I think.

(It would also be good if the RO 3.1 ROM image was made freely available for emulators.)

jess on 19/08/06 9:14PM [ Reply | Permalink | Report ]

adrianl: Do you feel that programs should be ported to the new processors or run under emulation or have both options available?

jess on 19/08/06 9:17PM [ Reply | Permalink | Report ]

Jess:

If yopu GPL the source code you have users who use it within the rules of the license (who do not have to pay anything but may want support) and those who find the GPL too restirctive who would want an alternative commercial license.

That gives 2 potential income streams....

markee174 on 19/08/06 9:26PM [ Reply | Permalink | Report ]

adrianl: I agree, despite the many technical challenges to it. An open source RISC OS would at least give that option with a couple of committed OS experts working on it.

jess: with the core OS running natively on a multi-GHz dual-core chip (a la the recent Apple line), I don't see any reason why applications couldn't run faster than native on some nebulous RISC OS/x86, using Rosetta-like emulation.

It's hard to believe exactly *how* much faster other chips are than current RISC OS hardware (even this 1.42GHz G4 in a 2 year old Mac mini), and what that gives in terms of capabilities of software. No, it's not needed for emails, but Java and Flash both enhance the web experience and faster's always better there. Ripping DVDs, whilst playing back smooth high resolution DivXs becomes possible, editing video on consumer hardware etc. etc. Desktop RISC OS on ARM has no future apart from absolutely tiny niches at best. Personally I don't care what software my STB runs, as long as it does the job.

The other *big* advantage to an x86 port of RISC OS would be the binary-only software which theoretically could be run in an appropriate container. This is done by mplayer on Linux (for example) to get full codec support by dropping the Windows DLLs in an appropriate folder.

Jaffa on 19/08/06 9:26PM [ Reply | Permalink | Report ]

In reply to Jess Hampshire:

Correct, requiring a royalty would not be compatible with the Open Source Definition [1]. If that is what Castle intend (if indeed they intend anything at all) then I would strongly suggest that they too find a term other than 'Open Source' to describe it.

[1] although requiring a royalty for some parts and releasing other parts as Open Source would be quite possible.

gdshaw on 19/08/06 9:38PM [ Reply | Permalink | Report ]

@AMS: The reason I supported the Omega, was that in its finished state it would have offered a hell lot more processing power than any standard PC workstation (through the use of user-programmable FPGA-space) and back then we might have stood a chance to turn that into native software development. Now we are long past that point. The only way we can hope to get back to a state where RISC OS might be considered a fully-featured desktop/workstation computing platform, is by utilising the vast amount of open-source code out there and stick RISC OS frontends on it. The main problem with this approach is the lack of processing power to run all of this highly-abstracted code and the fact, that a lot of the speed-optimized open-source code is optimized for x86. Don't get me wrong, I still like ARM a lot, but I don't think that we can get by with ARM-only machines, we will need x86-CPUs as well, and we need an API and hardware abstraction layer to make use of them within RISC OS. This way we could integrate the x86 into all popular RISC OS machines in different ways: RiscPC: make use of the second processor. Omega and Iyonix: x86-PCI-cards. PCs: ARM code would be run through emulation or on a ARM-PCI-card, x86 code would be run on the host processor.

@all: The most important reason why RISC OS must become open source software to survive as a desktop platform, is that no-one in their right mind would invest into it in its current state, simply because its future is so uncertain. The reason why Windows and Linux are so successful, is that there is a guaranteed future for the two. If my company decides to invest in Linux or Windows, it is safe to say, that this investment will not become worthless through discontinuation of the development of the underlying hardware or the operating system. The same can not be said for RISC OS, not even if it becomes open source. But if it was open source, companies would at least have the guarantee, that they could implement missing features and fix existing bugs themselves, if official development should cease.

JGZimmerle on 19/08/06 9:48PM [ Reply | Permalink | Report ]

Damn, drobe reformatted my post in all the wrong places. Just ignore all the "In reply to"s.

JGZimmerle on 19/08/06 9:50PM [ Reply | Permalink | Report ]

Personally I think the initial development focus should be on OS features rather than ports to other architectures. After all, if RISC OS has enough selling points, then people won't move to another OS which runs on their machine, even under emulation. If we then abandon ARM altogether, the bread and butter income of STB development is gone, while the trickle-down of those developments to desktop users is lost.

Julian: Do you still have that XScaled Omega, and is it actually as functional as an Iyonix? I'd hate to think it was a garden ornament in DA's community project ;-)

timephoenix on 20/08/06 01:34AM [ Reply | Permalink | Report ]

jess> Both. It clearly makes sense to run a native build where available but ARM executables must be supported so that we can run what software we do have, and that definitely includes modules such as bits of the OS that have not been converted.

adrianl on 20/08/06 02:23AM [ Reply | Permalink | Report ]

Is the format of the program header that caused a fuss with the A9 flexible enough to declare that programs are written for processors other than arm 26 or 32?

jess on 20/08/06 02:32AM [ Reply | Permalink | Report ]

No, but it could be extended if necessary, and in a backwards compatible manner.

adrianl on 20/08/06 03:15AM [ Reply | Permalink | Report ]

Would it also be possible to work out a subset of x86 commands that parallel arm instructions, so that any code that restricted itself to it, would be able to be cross compiled or emulated on arm systems easily?

jess on 20/08/06 10:01AM [ Reply | Permalink | Report ]

@timephoenix: No, I had to give the Xscale prototype back after about a month. I got a production machine instead.

JGZimmerle on 20/08/06 4:14PM [ Reply | Permalink | Report ]

Julian wrote>"The reason I supported the Omega, was that in its finished state it would have offered a hell lot more processing power than any standard PC workstation (through the use of user-programmable FPGA-space)"

As it was never finished that would be a safe bet wouldn't it ?

As to a hell of a lot of processing power the *actual* Omega out there in processing terms is not much better than a RISC PC (other than faster memory access and disk access). The Iyonix would have more processing power (and it too has an FPGA - albeit a simple one) - so why not support it?

Julian wrote>"The only way we can hope to get back to a state where RISC OS might be considered a fully-featured desktop/workstation computing platform, is by utilising the vast amount of open-source code out there and stick RISC OS frontends on it"

While I would have sympathy with that viewpoint it doesn't really address the glaring problem inherent in this. Most OSS code is pure C or C++ it is often written to be portable (in other words *not* optimised for any particular platform). The end result of this is the more complex OSS code when converted for the RISC OS environment is (sad to say) bloated and slow. While Firefox is a good advertisement of what *can* be acchieved it, subjectively, it appears slower to me than say Origano 2 (which itself is pretty slow even on an Iyonix).

The fastest, most useable applications on RISC OS tend to be a mix of C or BASIC and ARM Assembler. OSS from the Linux or BSD camps won't be that - it'll usually be pure C/C++ and designed for machines that run somewhat faster processors, have more RAM and less resource constraints.

Given the choice would you prefer to run Firefox on a RISC OS machine or a PC ? In short side by side people would (I believe) opt for running such Open Source code on a PC running Windows or Linux over a RISC OS machine running the same app.

The best solutions IMHO are either (a). Faster RISC OS machines that would allow "slow complex" code like that to be run effectively or (b). More "native" RISC OS application development - that makes use of OSS where possible but is optimised for ARM RISC OS use where required.

AMS on 20/08/06 5:21PM [ Reply | Permalink | Report ]

AMS: "The best solutions IMHO are either (a). Faster RISC OS machines that would allow "slow complex" code like that to be run effectively or (b). More "native" RISC OS application development - that makes use of OSS where possible but is optimised for ARM RISC OS use where required."

And where on earth are either (a) or (b) going to come from? The trouble with them as "solutions" is that without any realistic chance of feasibility, they're at best pipedreams :-(

Jaffa on 20/08/06 6:02PM [ Reply | Permalink | Report ]

@AMS:

I don't support the Iyonix, because it does not offer enough processing power. And if it will do so in the future (say via a PCI-FPGA-card) it would now be way too late. For the same reasons I would no longer support the finished Omega, if it was to be released now. And as for the Iyonix having an FPGA: Is it user-programmable? Is there an API and some kind of OS module that prevents different applications competing for the use of this FPGA to mess up the system? I thought not. And even if all this existed, there are not enough software developers left in this market, for it to actually make a difference.

What you are saying about OSS code usually not being optimised for a specific platform, is of course very true. I said much the same thing in my post, where I mentioned, that it often is highly abstracted. Abstraction often leads to bloated code. Modern processors are so fast, that this does not matter, however even the fastest ARM processors are very, very slow compared to modern PowerPC or x86 processors.

There is also a lot of OSS code out there, wich is highly optimized for specific processors, simply because even the fastest processors available today are only just about fast enough for some tasks. These tasks tend to be the ones that power-users lust after (like video-encoding) and bring all the prestige.

Personally, I don't see why we should choose between the two options (a and b) you mention. I think the only chance RISC OS has to survive on the desktop is a combination of both options.

JGZimmerle on 20/08/06 6:14PM [ Reply | Permalink | Report ]

@Jaffa: The simple answer is this: By open-sourcing RISC OS. Hopefully such a step would lure back a few of the developers that once developed for our platform. They might want to run RISC OS on their current hardware, wich is most likely x86-based. So we might end up with RISC OS being ported to faster machines (giving us option a: faster RISC OS machines) and more developers, especially once RISC OS runs on the hardware wich most OSS-developers have at home: x86 and PowerPC (giving us the resources for option b).

JGZimmerle on 20/08/06 6:20PM [ Reply | Permalink | Report ]

Julian> Thanks for your considered reply.

You wrote "I don't support the Iyonix, because it does not offer enough processing power."

But at one time both Iyonix and Omega *co-existed* yet you supported Omega - yet Omega's CPU is slower and its FPGA was largely used to implement a "RiscPC" like environment rather than any sort of processing acceleration. The Omega when I seen it did not seem to run rings round the Iyonix so for all the difference the FPGA made it seem (other than easing the design) it seemed to acchieve little.

I can't imagine MD would have been too keen on people "reprogramming" the FPGA (given the disasters that users might inflict on themselves...). The small FPGA on the Iyonix is reprogrammable - but dedicated to machine functions - I only mentioned it as having an FPGA does *not* mean extra performance - that in fact it's an indicator of nothing in particular.

I'd agree with you that performance of native ARM RISC OS machines *need* to improve. If that were to happen then using OSS code (as it stands - unoptimised for RISC OS) would become more feasible - and also the second option of more native RISC OS might become more attractive to developers.

The key thing is that newer hardware comes - and perhaps open sourcing RISC OS *might* encourage others who have not considered writing for RISC OS to do so. But as with much else here it's all speculation....

AMS on 20/08/06 6:48PM [ Reply | Permalink | Report ]

JGZimmerle: Indeed, and I agree. My point was that AMS seemed to be advocating faster *ARM*-based hardware running RISC OS and/or more RISC OS/ARM native development (i.e. not ports).

Jaffa on 20/08/06 7:54PM [ Reply | Permalink | Report ]

Well, for me the first basic production version of Omega never looked like a very "attractive" machine. But I saw the potential in the design. MicroDigital had plans to produce (and prototypes for) upgrades to the basic machines via the ARM-Twister interface, wich had the potential for getting us up to, and beyond, the performance of PCs. This would have included, among other things, the user-programmable FPGA with four embedded PowerPC cores and the XScale chip. Of course they never intended to make the basic system-FPGAs user-programmable.

Unfourtunately MicroDigital had all these set-backs in development. In the end the Iyonix was first to market and the Omega lost too many sales.

JGZimmerle on 20/08/06 7:59PM [ Reply | Permalink | Report ]

@Jaffa:

Well, I'm advocating a more flexible RISC OS, wich could make use of different processors at the same time. Faster native ARMs are certainly one component wich should be used to speed up the platform. Personally I think the best way to utilise faster ARMs for RISC OS would be via a PCIe-card for standard PC hardware.

JGZimmerle on 20/08/06 8:05PM [ Reply | Permalink | Report ]

Since first making public comments re open sourcing RISC OS, and my company’s interest in selling it’s stake in Castle a very interesting and positive set of discussions have taken place. For the first time in a long while, I’m far more optimistic about the future of RISC OS as there is now a clearly emerging consensus within Castle and related companies that Open Source is the way to go, and how this may be achieved, echoing Jack’s quoted comment.

It’s sad that Drobe’s latest contribution has been so negative, based on untrue and unsubstantiated rumors whilst following that great journalistic adage, “never let the truth stand in the way of a good story”. For a website supposedly interested in promoting RISC OS you should be ashamed of yourselves.

I note Drobe has now retracted its initial claims, but, I must still set the record straight. As the person directly responsible for managing Tematic I can categorically state that none of the employees were owed anything and, as already stated, the shut down of operations at Tematic was orderly and honorable. Moreover, all the engineers were immediately engaged by another organization to continue working on IPTV and Set Top Box projects, contrary to the bleak Castle bashing conducted on Drobe at the time: www.drobe.co.uk/riscos/artifact1461.html

As to the claims in another magazine that “trashed Castle” these appear ill informed (N.B. I haven’t read the article), and I assume inspired by certain individuals who’ve always been anti Castle and invidious of its ownership of RISC OS. Sorry to disappoint, but I can state authoritatively that Castle will turn a healthy profit this year (not least thanks to Jack’s excellent efforts controlling costs, and his inspired choice of new premises

) Moreover, STB royalty revenues have been good, vastly exceeding the paltry sums received from certain other licensees.

Then there is the statement, “Open sourcing it without considering the impact this will cause to other companies using the operating system is pretty crap." Suggesting Castle wouldn’t consider all the ramifications and legal issues is naïve in the extreme. However, since Andrew H’s comment on this point many tumbleweeds have gone past and no more hands got raised. Of course, making wild guesses about the contents of confidential legal agreements and licenses seems to be a regular pastime for Drobe users, long may it continue

, enjoy!

PeteWild on 21/08/06 1:57PM [ Reply | Permalink | Report ]

Given the nature of discussions on Drobe regarding Castle’s possible plans for RISC OS I think some clarification of the facts would help, supplemented by my own PERSONAL opinions regarding the direction in which I believe we are headed:

1. There are no insurmountable legal barriers to Open Sourcing RISC OS. Castle has mechanisms available which allow it to do this if it wishes. Though no doubt the legal profession will get richer at the expense of money that could be better spent on software development

2. I fully acknowledge RISC OS contains some third party code, but no one has ever suggested this code would ever be open sourced without the permission of the owners. Where the sources cannot be distributed those modules could generally still be provided in binary form (The RISC OS build environment has been specifically structured to enable a subset of the sources to be released to third parties if required). This is an issue that is fully understood and catered for.

3. When referring to “elements of RISC OS” it should be borne in mind there are some commercially sensitive/valuable components that probably wouldn’t be released. IMO the publicly released sources should be those necessary to provide a general purpose build of the OS on typical hardware. They won’t be every bit of code in the CVS.

4. Interesting comments about Taiwanese Set Top Box vendors, but no one was ever suggesting such issues wouldn’t be resolved (BTW, AFAIK the company Drobe inferred fed back contributions to the sources I don’t believe is actually the one mentioned, several other STB vendors were licensed the OS by Acorn/Pace, and indeed have been by Castle). Incidentally, I’m currently in Taiwan talking to Set Top Box manufacturers………..coincidence?

5. Open Source licensing of RISC OS would almost certainly be under a bespoke licence with appropriate terms for use, charges and feedback of sources. These may, or may not, follow accepted definitions of Open Source. Sorry to spoil the enjoyment guys, but speculating about which form of exisitng licence will be used is a little pointless. That said, positive contributions on what form the licence should take would be welcome. My view is it would need to include: a. Minimal royalty for personal use b. Per unit Royalty structure for commercial use c. Feedback of sources in such a way that it can be re-licensed by Castle (i.e assignment of ownership of Derivative works to Castle) d. Prohibition of use in certain areas, e.g. Only for use on ARM processor hardware, certain excluded/controlled application areas.

6. There have been several negative posts concerned about the future of new hardware for RISC OS desktop use. Surely the benefit of open source is that others can port the OS to existing commercially available platforms expanding immediately the range of products available? There are plenty of third party products out there running various X-scale processors for example which would be tempting targets for RISC OS ports without the need to invest in bespoke hardware development. Moreover, the Open Source availability should encourage other companies to develop new hardware safe in the knowledge they have unfettered access to the OS sources and an easy route for licensing.

7. Whilst I note with interest the debate on porting RISC OS to non ARM hardware. I really don’t think this is practical, or will be legally allowed. The OS architecture is intrinsically linked to the ARM, and large amounts of assembler embedded in the sources would require major re-engineering.

PeteWild on 21/08/06 2:14PM [ Reply | Permalink | Report ]

PeteWild: Interesting posts, thank you.

However, both (5) - "royalties"/"prohibition" - and (7) - "legally allowed" - would preclude it being considered "Open Source" in any accepted or meaningful sense of the term.

Whether Castle can be the *only* company to *ever* have a succesful shared source scheme remains to be seen, but the body of evidence isn't on their side. The licence you describe sounds like Castle getting the rewards without any of the risks - hardly likely to attract a legion of talented OS-tinkerers.

Jaffa on 21/08/06 3:28PM [ Reply | Permalink | Report ]

<rant> We'd like contributions from the public, we won't pay you for it, we will expect the (c), we'll not give you all the source to make something usable, we expect you to pay to use the OS you're writing, we won't let you use the code in things we consider bad. </rant>

And the scary thing is, there are some RISC OS fans who like it so much, you will get help.

flibble on 21/08/06 3:29PM [ Reply | Permalink | Report ]

Well, considering just about every PC has an ARM core somewhere (were they not used in many HDD controllers?), the legal requirement, that the system must have an ARM, would not be such a big problem for porting to x86. However I still believe, that it would make a lot more sense to make a cheap PCIe-card or Firewire-device with an ARM processor to run RISC OS on PC hardware.

I don't see point (c) as such a big problem, as long as Castle has to publish any changes they make to the open-source-components as well. IIRC that is what MySQL AB does.

JGZimmerle on 21/08/06 8:22PM [ Reply | Permalink | Report ]

PeteWild: "Open Source licensing of RISC OS would almost certainly be under a bespoke licence with appropriate terms for use, charges and feedback of sources."

Then it won't be open source. Not even Microsoft labels such licences as open source, and any pretense that such licences are open source will be met with ridicule and, in a slightly different world, a trademark infringement lawsuit: the OSI probably haven't asserted their rights aggressively enough to get misusers of the term (in the manner suggested) into immediate trouble, but such misusers would be courting distaste if not danger at the very least.

"a. Minimal royalty for personal use"

Bzzzt.

"b. Per unit Royalty structure for commercial use"

Bzzzt.

"c. Feedback of sources in such a way that it can be re-licensed by Castle (i.e assignment of ownership of Derivative works to Castle)"

Actually, you could get away with asking contributors to license their code in different ways, but since the community is apparently just there for donkey work, you want them to give you their work for whatever future purpose. Suggested licence name: Fanboy Special Helper Source Licence.

"d. Prohibition of use in certain areas, e.g. Only for use on ARM processor hardware, certain excluded/controlled application areas."

Bzzzt.

To sum up: not anywhere close to open source; even some Microsoft shared source licences are more open than the above.

JGZimmerle: "I don't see point (c) as such a big problem, as long as Castle has to publish any changes they make to the open-source-components as well. IIRC that is what MySQL AB does."

Companies like MySQL probably either pay for contributions that they want to offer commercially (under a proprietary licence) or they rewrite the functionality in-house. Way before the OSI, there were licences in circulation (perhaps more like permissions statements, actually) which requested or demanded modifications to be made available to the author, but this is actually incompatible with even "strong licences" like the GPL - possibly contrary to popular belief. Even if (a), (b) and (d) were dropped and such a clause were introduced in favour of (c), people would still shun the project... and deservedly so.

guestx on 21/08/06 11:44PM [ Reply | Permalink | Report ]

I for one don't care about any of that tbh. If Castle licence RISC OS along the lines Peter Wild has stated above then I would say it was a massive step forward. If they want to call it open source, whether it follows the accepted definition or not, noone can stop them. If they own the IPR to the OS, it's theirs to licence as they see fit. Some people will always want the moon on a stick.

Cogs on 22/08/06 01:26AM [ Reply | Permalink | Report ]

MySQL have a joint commercial/GPL license. Their income stream is the commercial version and they will not accept code contributions without the copyright.

The simply the licensing scheme, the more likely you are to get involvement. Sun was ridiculed for introducing their own Open Source licenses when there are already lots, including the GPL and the AFPL if you want to stop commercial use.

markee174 on 22/08/06 07:33AM [ Reply | Permalink | Report ]

In reply to Dan Maloney:

"If they want to call it open source, whether it follows the accepted definition or not, noone can stop them."

I wouldn't be so sure about that (thinking trades description law here), but even if they could I don't think you have any conception as to how hostile the reaction of the real Open Source community would be if anyone were to try that.

"If they own the IPR to the OS, it's theirs to licence [sic] as they see fit."

True, but if they want their project to be attractive to Open Source developers then they do not have that freedom. The OSD is the standard against which they will be judged, and I for one would be very reluctant to work on anything which did not meet that standard.

A far better strategy would be to release selected parts of the OS (the bits that need work) under a truly free licence, and leave the remainder proprietary.

gdshaw on 22/08/06 08:01AM [ Reply | Permalink | Report ]

Peter Wild:

Are you enthusiastic that you are reviewing 'previous decisions'?

markee174 on 22/08/06 08:50AM [ Reply | Permalink | Report ]

Not everyone is an open source purist, stipulating that if it isn't GPL its not worth touching. We've all donated larges amounts of time and effort to companies such as when beta testing, the result of which they have gone on to commercially exploit without directly renumerating those contributors, so its not a huge difference to dontating source under such as licence as the above. If there is the opportunity to take RISC OS forward in ways which wont happen without open access to the source, and all we can do is bitch about the type of licence, then its time to walk away.

druck on 22/08/06 09:19AM [ Reply | Permalink | Report ]

druck: I don't think anyones suggested that if it isn't GPL it isn't worth touching. A few people, myself included, seem to be worried that the license suggested seem exploitative, unbalanced and very limiting.

What's being suggested isn't an open license, it's a commercial software license where they don't have to pay the developers.

flibble on 22/08/06 11:03AM [ Reply | Permalink | Report ]

In reply to druck: "...so its not a huge difference to dontating source under such as licence as the above..."

If that's fine with you then nobody here is going to stop you from doing that.

"If there is the opportunity to take RISC OS forward in ways which wont happen without open access to the source, and all we can do is bitch about the type of licence, then its time to walk away."

If that's the only license on offer, maybe it _is_ time to walk away.

davidb on 22/08/06 11:39AM [ Reply | Permalink | Report ]

Now hang on a moment! They are willing to release the results of thousands of man-years of work to us. I would see this as a very generous contribution to a community-based development project for RISC OS. And they did have to pay a lot of money for it in the initial acquisition from Pace. If other developers want to contribute source to this project, they are likely to be users of RISC OS, too. They will receive new versions of this OS for next to nothing (I think the figure suggested was a few pennies?) and there might well be a clause in the licence, that developers, who's source has been accepted into the project, will get future versions completely free of charge. The commercial developers in the RISC OS market might want to contribute certain changes to RISC OS wich would enable them to release new products through wich they will get new sales (like ADFS-improvements for CinoDVD). Then there is the possibility of user-funded development like the UPP, only for OS features. Also some of the in-house developments of the STB-developers might be contributed to the "open-source" version.

JGZimmerle on 22/08/06 12:01AM [ Reply | Permalink | Report ]

I've decided to hold off commenting on this further until I see more info from Castle/Whomever. But you can guess from my previous comments that I find the 'offer' so far rather half hearted

flibble on 22/08/06 12:45AM [ Reply | Permalink | Report ]

I think that it is inevitable that there will be these sort of restrictions on the licence, I suspect that they are needed to protect Castle's wider commecrcial interests. If they want to continue to sell licences to their commercial customers, they will need to retain some sort of "Copyright", although in the usual Open Souce models the term "Copyright" is meaningless. For Castle to remain profitable requires them to remain in control of thier product and be able to sell it to their customers. For Castle to remain profitable and therefore able to contnue to support desktop RISC OS is in the interests of every user of RISC OS, so we shouldn't bitch too much their attempts to come up with a licence that will make that possible. To me it looks as if they are trying to do their best to help the desktop enthusiast market without compomising their commercial interests, and they should be applauded for doing so.

mrtd on 22/08/06 12:55AM [ Reply | Permalink | Report ]

mrtd: "If they want to continue to sell licences to their commercial customers, they will need to retain some sort of "Copyright", although in the usual Open Souce models the term "Copyright" is meaningless."

Entirely untrue - all Open Source (and Free Software) licences, including the GPL, *depend* on enforceable copyright.

"For Castle to remain profitable requires them to remain in control of thier[sic] product and be able to sell it to their customers."

The benefits of open source to a company like Castle is that they can concentrate on adding value on top of the open source product, whether that's embeddable components; contract work; documentation; services or support.

Remember Peter Wild's original comments: some of Castle's prospects have been turned off by the fact RISC OS isn't open source. If they use the same definition as everyone else (i.e. more or less the OSD) then open sourcing RISC OS with a licence as described above won't gain Castle many new customers, and won't do anything for the long term future of RISC OS on the desktop.

At best, it'll allow a few of the remaining die-hards to tinker round the edges; but won't gain any traction with a larger OS (both "open source" and "operating system") community.

Jaffa on 22/08/06 1:08PM [ Reply | Permalink | Report ]

In reply to Andrew "Entirely untrue - all Open Source (and Free Software) licences, including the GPL, depend on enforceable copyright. "

Open source is copyright free in the sense that anyone can freely make copies of it and amend it for their own purposes. That is what I meant. I agree that the licence also places restrictions on what can subsequently be done with those copies, so the granter of the licence still retains the right to enforce that!

mrtd on 22/08/06 2:37PM [ Reply | Permalink | Report ]

mrtd: "Open source is copyright free in the sense that anyone can freely make copies of it and amend it for their own purposes."

No no no no no.

The code is copyright the author, this forbids you from making unauthorised copies. You are authorised to make copies if you adhere to the terms of the licence.

If you don't adhere to the terms of the licence, you are not authorised to make copies of the code. Therefore you are distributing copies without the permission of the author. Therefore you are violating the author's copyright.

Any lawsuit involving the non-compliance with an open source licence would be a copyright lawsuit.

Copyright is the *backbone* of open source and free software; not its enemy.

Jaffa on 22/08/06 5:41PM [ Reply | Permalink | Report ]

mrtd:

In many respects OS licenses such as the GPL are more restrictive than closed source licenses!

Mixing all the interests of competing groups can be a problem - hence the problems with the GPL version 3.

markee174 on 22/08/06 6:07PM [ Reply | Permalink | Report ]

David Ruck wrote>"If there is the opportunity to take RISC OS forward in ways which wont happen without open access to the source, and all we can do is bitch about the type of licence, then its time to walk away."

I very much agree with this. I think it is also significant that many of the people critical of the license choice would be fans of Linux. [I'd qualify that by saying there is *nothing* wrong with this - and Linux is a fine Operating system]. The problem is we're discussing the survival of *RISC OS*, last time I checked Linux wasn't on the endangered species list...

That being the case the license chosen should (a). Bolster RISC OS (b). Not aid the competition (c). Protect and where possible enhance the existing RISC OS hardware and software manufacturers. I don't believe this is best acchieved by a GPL style license. The license used, I would argue, should prevent re-use of RISC OS source in non-RISC OS operating systems (to prevent "cherry picking") and should prevent use of RISC OS under emulation/translation on other platforms. The commercial aspects of the license are Castle's business, its *their* software so ultimately it's their choice as to what they do with it - surely ?

And no Julian simply having an ARM on your computer's southbridge doesn't mean it's "ok" to develope and run RISC OS on an x86 (besides not all Southbridge have ARM's and most PC owners wouldn't be able to tell so could not be certain they'd complied with the license). The license therefore should (IMHO) explicitly state that RISC OS can only be used by a *native* ARM processor and that the emulation of or translation of ARMCode to x86 or other binary for execution on a non-native processor is expressly forbidden.

AMS on 22/08/06 6:08PM [ Reply | Permalink | Report ]

Jaffa:

"Remember Peter Wild's original comments: some of Castle's prospects have been turned off by the fact RISC OS isn't open source. If they use the same definition as everyone else (i.e. more or less the OSD) then open sourcing RISC OS with a licence as described above won't gain Castle many new customers"

This is not guaranteed. You do not know who those prospects were, and you do not know how willing they would be to compromise on the strict (and, frankly, anal) definition of open source. It largely depends on _why_ they were put off by RISC OS not being open sourced - and there coule be many different reasons, any number of which could be satisfied with a not-quite-open-source-but-open-enough-to-satisfy-us arrangement.

What you have to remember is that Castle _do_ know who those prospects were, and therefore probably _do_ know what their reasons were, and it's therefore likely that should they proceed with the move being discussed, they would do so in such a way as to take those reasons into account.

VinceH on 22/08/06 8:22PM [ Reply | Permalink | Report ]

In reply to AMS: "I think it is also significant that many of the people critical of the license choice would be fans of Linux."

Well, that's correct in my case. It's hard not to be a fan given the freedom it gives you to learn and experiment, modify and redistribute. Even if you don't want to look at the kernel itself, the fact that it's Free Software means that there's lots of software projects that you can get involved with or build on to create new software.

RISC OS, as it stands today, doesn't enjoy the same amount of interest from the same sort of developers. You can lock it down to a particular architecture and impose all sorts of license conditions on developers and end users, but you have to ask whether it will make it interesting for people to develop for. If it ensures the future of RISC OS as an embedded operating system, where does it leave all the desktop users?

I think we disagree about licenses because you seem to want to support and promote an operating system (and desktop environment) while expecting relatively little in return. I find it strange, but not surprising, that people are still willing to do that. Nonetheless, it is up to Castle to choose a license that suits their needs, and these need not match those of their desktop customers.

davidb on 22/08/06 8:53PM [ Reply | Permalink | Report ]

I just don't see why Castle should limit RISC OS' development by restraining it to a single processor type. If someone was willing to do the work required to make RISC OS run on additional CPU architectures, it would widen their market.

@AMS: I just don't see why you want to limit RISC OS to a single CPU architecture. Its not like a multi-platform RISC OS would prevent you from running it on ARM hardware.

JGZimmerle on 22/08/06 11:32PM [ Reply | Permalink | Report ]

Graham Shaw:

"In reply to Dan Maloney:

'If they want to call it open source, whether it follows the accepted definition or not, noone can stop them.'

I wouldn't be so sure about that (thinking trades description law here),"

I can't see how that can be applied without a universal consensus on the meaning of the word 'open'.

Besides, we don't know what the licence may be officially called. I think it's premature to do the whole leaping down Castle's throat thing.

" but even if they could I don't think you have any conception as to how hostile the reaction of the real Open Source community would be if anyone were to try that."

I could see that being beneficial to RISC OS. It's not as if it is exactly high-profile. The more heat generated, the more interest in RISC OS could be garnered or regained. Not everyone has their head up their arse over this issue. Individuals have been producing RISC OS enhancements for no financial benefit for donkeys' years. With this initiative it would get easier.

It just seems bizarre to me that a) Castle can be criticised by open source advocates for opening up RISC OS more than it is now, and b) there are people who think they are in a position to dictate the terms of a licence to the owner of the IPR.

"'If they own the IPR to the OS, it's theirs to license as they see fit.'

True, but if they want their project to be attractive to Open Source developers then they do not have that freedom."

If you have been following the discussion so far, a major part of the strategy seemed to me to be to make the OS more attractive to STB vendors. A few enthusiasts tweaking the OS as well is a bonus.

" The OSD is the standard against which they will be judged, and I for one would be very reluctant to work on anything which did not meet that standard."

A shame, but who knows what will happen. Maybe the licensing will be relaxed as time goes on. I don't think this is the time to be disparaging.

"A far better strategy would be to release selected parts of the OS (the bits that need work) under a truly free licence, and leave the remainder proprietary."

I can't see where the doom and gloom comes from. To me it just seems to be a case of some people crying "what's in it for me?". But transferal of IPR to Castle can only apply to derivative works. If you write a completely separate and self-contained module from scratch, or maybe even a kernal replacement, the situation must remain the same as now. Opening up RISC OS, even in the manner that has been discussed, allows possibilities for adding hooks into existing OS components to interface with differently licensed self-contained code or even new commercial products.

LAME and its origins spring to mind.

Besides, AIUI the parts of RISC OS that need the most work are ones which could do with a from-the-ground-up rewrite.

Cogs on 23/08/06 00:51AM [ Reply | Permalink | Report ]

In reply to Dan Maloney:

"I could see that being beneficial to RISC OS"

There is a company called SCO who tried the 'all publicity is good publicity' idea and it isn't working out well for them :-)

Seriously, why set out to hijack the term 'Open Source' when you know it will antagonise the very community you want help from?

(After all we know what it is like to be on the receiving end of such a manoeuvre, with the recent attempt to repurpose the 'Acorn' brand.)

"I don't think this is the time to be disparaging"

On the contrary, there would be little point in having this discussion after the decisions have been taken.

"I can't see where the doom and gloom comes from."

There are three distinct issues here: (1) Whether release of the source code under a non-free licence is better than the status quo. While this is possibly not as clear-cut as it seems, it is not a point I am inclined to quibble about. (2) Whether there are better ways to release the source code without compromising Castle's commercial interests. I think there are, and see no harm in saying so. (3) Whether it is a good idea to choose a restrictive licence and then try to present it as 'open source'. Sorry, I'm with doom and gloom all the way here: this is a terrible idea, and one I think we would live to regret.

gdshaw on 23/08/06 04:01AM [ Reply | Permalink | Report ]

JGZimmerie> Perhaps because their business relies upon selling ARM-based hardware that runs RO? Were somebody to modify RO to run, by whatever means, on other hardware, they run the risk of losing a big part of their income.

adrianl on 23/08/06 04:10AM [ Reply | Permalink | Report ]

AMS: "(b). Not aid the competition"

I'd be very interested to know what you think RISC OS' competition is, and what they could/would "cherry pick" from it.

Jaffa on 23/08/06 09:08AM [ Reply | Permalink | Report ]

Jaffa: The antialiasing? It still looks better than any alternative I've seen.

As far as I can see most of the rest that's good about the system would have to be reimplemented from scratch anyway - like ROX does.

jess on 23/08/06 09:29AM [ Reply | Permalink | Report ]

jess: freetype2, free to use in commercial products, portable in C across a huge range of OSs and platforms, real open source. People already have a more suitable alternative to the RISC OS font rendering system. Whether you debate over which is the 'better' antialiasing system, most people can't tell and don't care.

flibble on 23/08/06 11:04AM [ Reply | Permalink | Report ]

Most other anti-aliasing systems also offer sub-pixel rendering for LCDs, which are increasingly common and give a cleaner look in the same number of pixels.

Jaffa on 23/08/06 11:46AM [ Reply | Permalink | Report ]

flibble: That's true, I've seen people happily using LCDs in non-native modes and thinking it's sharp, it would give me a headache in 5 minutes. I think I'm ultrafussy about displays.

jess on 23/08/06 12:30AM [ Reply | Permalink | Report ]

David Boddie>Actually, please don't get me wrong, I make *no* criticism of Linux or the GPL. In fact Linux has acchieved a quite substantial degree of development in the face of Windows - which is no mean feat. My comments are more of the nature of how to sustain RISC OS on ARM and advance it as far as *we* can. I am not sure that the GPL route will do this, given where RISC OS is at and who its userbase and likely commercial customers are.

It, in a sense, is the difference between selecting the right strategy to suit RISC OS and that of picking a strategy and hoping it works for RISC OS.

Julian wrote>"I just don't see why Castle should limit RISC OS' development by restraining it to a single processor type."

Let's see. The bulk of RISC OS is written in densely written ARM Assembler (a specific processor), the effort to recode it to either another Architecture (x86 ?) or even to a High Level Language (C/C++) so as to gain portability would be - to be frank - a complete waste of what limited resources are available.

Additionally the only *real* advantage RISC OS has is (IMHO) the fact of this close, frugal, efficient "closeness" of the OS and CPU. Yes it makes the OS tied to one processor (that is a weakness I'll concede) but at the same time gives you the massive gain of performance that allows what should be a treakle slow processor (600MHz) in many instances gives a responsiveness of CPUs clocked much quicker. And there are faster ARM's in the wings (see the other article on Drobe about the new IOP from Intel)

To simply "port for the sake of porting" is absurd, if people want portability they'd be better advised taking an existing portable OS (e.g., Linux) and using that to it to *its* fullest extent on commodity hardware (e.g., x86) rather than trying to batter RISC OS into a space it doesn't really suit or belong in. RISC OS is RISC OS, it is close to the ARM and runs optimally on it.

Andrew Flegg asked >"I'd be very interested to know what you think RISC OS' competition is, and what they could/would "cherry pick" from it."

Any of the applications (e.g., Draw, BBC BASIC), the range of fileformats and utilities that come with RISC OS. The antialiasing system. Core technologies within RISC OS that are optimised for ARM (IRQ/FIQ handlers, Arithmetic functions).

RISC OS's competition is basically any OS that can draw away RISC OS's users. That would definitionally be Windows, Linux and possibly Mac OS X.

It's difficult for RISC OS to exist and keep its userbase I don't see how letting the whole world have free and unfettered access to the RO source will help RISC OS, especially given that many of the potential developers who might wish to use the OS under (say) GPL terms might be more inclined to simply use any useful RO features in their favoured OS rather than necessarily helping RO itself (- that again is *not* a critism of those developers they'd be entitled to do this under a GPL style license).

But guess what my interest in *the survival of RISC OS*. If someone can show me how opening RO to GPL use can actually *save* RISC OS (and not simply transfer features to another OS with no benefit to RO) then I'd enthusiastically support it.

AMS on 24/08/06 10:35PM [ Reply | Permalink | Report ]

AMS wrote: "Actually, please don't get me wrong, I make no criticism of Linux or the GPL. In fact Linux has acchieved a quite substantial degree of development in the face of Windows - which is no mean feat."

I appreciate that. I was just pointing out where I was coming from.

"My comments are more of the nature of how to sustain RISC OS on ARM and advance it as far as we can. I am not sure that the GPL route will do this, given where RISC OS is at and who its userbase and likely commercial customers are."

Ironically, the GPL, while wrongly perceived to be an anti-commercial license by many people, might be more appropriate than other more permissive licenses, such as the modified (or new) BSD license, simply because it doesn't allow the code to be forked then closed. Of course, being able to misappropriate code in this way might be just what potential commercial customers want!

[What could be cherry picked?]

"Any of the applications (e.g., Draw, BBC BASIC), the range of fileformats and utilities that come with RISC OS. The antialiasing system. Core technologies within RISC OS that are optimised for ARM (IRQ/FIQ handlers, Arithmetic functions)."

I'm not entirely convinced that some of the core technologies are as far ahead as you would have us believe. If those are the major advantages that RISC OS has over its perceived competition in the desktop arena then it's in trouble, especially given its weaknesses.

I asked myself what I would like to see the sources to. Certainly, to me, some of the more interesting pieces of software are the applications, and these wouldn't necessarily be part of any open source RISC OS! But, thinking about it, which bundled applications are in any way interesting? To me, probably only Draw, and with the source code to DrawPlus and Vector already out there, what would open sourcing Draw really offer?

In the end, I'd be more interested in seeing the source to various applications so that I could figure out their file formats and convert my data to open formats, rather than looking at the WIMP source, for example, and trying to figure out how I could get RISC OS applications running on another system using a compatibility layer.

"But guess what my interest in *the survival of RISC OS*. If someone can show me how opening RO to GPL use can actually save RISC OS (and not simply transfer features to another OS with no benefit to RO) then I'd enthusiastically support it."

I applaud your enthusiasm, but I think you've set your standards too high. Keeping the OS strongly tied to the ARM architecture out of choice, for example, would be an affordable luxury if the adoption of RISC OS matched that of ARM processors. As it is, it's a necessity because there is neither the resources nor the will to port it, and perhaps rightly so. As for new ARM-based desktop machines running RISC OS, it may be that the only way to see more of them is to open source the OS; that way, the companies making RISC OS machines might actually be able to concentrate less on maintaining the software and more on making hardware.

davidb on 25/08/06 00:27AM [ Reply | Permalink | Report ]

AMS: "Let's see. The bulk of RISC OS is written in densely written ARM Assembler (a specific processor), the effort to recode it to either another Architecture (x86 ?) or even to a High Level Language (C/C++) so as to gain portability would be - to be frank - a complete waste of what limited resources are available."

If you have the source you can feed it in to a cross assembler and have that spit out code for any other architecture. With a couple of passes you can even optimise the nasty 2 operand register poor x86 junk resulting from our beautiful ARM instructions, although going straight to the slightly less crap x86/64 would be a better idea. This would result in a factor of 5x-15x better than the best emulator JIT, or around 1/3/ to 1/2 the speed of hand coded native assembler, which would compare very well to the result of re-writing it in C.

druck on 25/08/06 10:23AM [ Reply | Permalink | Report ]

In reply to druck:

Portability isn't the only advantage of being written in a high-level language: it also makes the code easier to modify and enhance.

I can't see loss of speed being a serious problem even if most of RISC OS were re-written in C: even in an operating system, most code is not performance critical. The impact on object code size could be more serious if there is a requirement for the result to fit within the flash ROMs of existing machines.

A cross-assembler would be an option to port large amounts of code relatively quickly, but beware that Acorn were quite keen on trampolines.

gdshaw on 25/08/06 1:06PM [ Reply | Permalink | Report ]

David Boddie wrote >"Ironically, the GPL, while wrongly perceived to be an anti-commercial license by many people, might be more appropriate than other more permissive licenses, such as the modified (or new) BSD license, simply because it doesn't allow the code to be forked then closed."

If RO [source] were forked and then closed that might not be a particularly good thing, in such a circumstance yes perhaps GPL would be better. Thing is arriving at a situation where the future of RISC OS is assured and that it continues to run on native hardware (as this gives best compatibility and performance IMHO) is I believe the best outcome. If that were by using GPL, BSD, some bespoke license or even just remaining closed so be it.

David Boddie wrote>"In the end, I'd be more interested in seeing the source to various applications so that I could figure out their file formats and convert my data to open formats, rather than looking at the WIMP source, for example, and trying to figure out how I could get RISC OS applications running on another system using a compatibility layer. "

I can understand that, but you do see how that might give some people a bad case of jitters. The phrase "get RISC OS applications running on another system using a compatibility layer" - how does that help RISC OS ? Does it simply give another OS the ability to run RISC OS programs (in a fashion) and further weaken RISC OS ?

Yes if you're a big fan of that other OS and don't (ultimately) care what happens to RISC OS that might make sense - but for us RISC OS adherents it sounds very much like appealing.

David Ruck wrote>"If you have the source you can feed it in to a cross assembler and have that spit out code for any other architecture."

Perhaps I was a little rash - but ok I'll accept that.

David Ruck wrote >"With a couple of passes you can even optimise the nasty 2 operand register poor x86 junk resulting from our beautiful ARM instructions, although going straight to the slightly less crap x86/64 would be a better idea"

Still though it is difficult to hold back the tears isn't it !!!!!

If your speed estimates are even close to being right (and given your expertise I'd be prepared to accept them on face value) then that would allow RISC OS "on" x86 to be a possibility, trouble is what OS would it run on Windows/Linux or would it in fact be "stand alone" (but that would need a lot of work surely). Thing is it all sounds like a recipe where the coffin has another nail hammered in..... is that *really* where we want to go ?

Just because something is technically feasible does not make it the right thing does it ?

AMS on 25/08/06 6:11PM [ Reply | Permalink | Report ]

Gad zukes I should learn to write dagnabitt.....

The line "Yes if you're a big fan of that other OS and don't (ultimately) care what happens to RISC OS that might make sense - but for us RISC OS adherents it sounds very much like appealing. "

Should end on.. but for us RISC OS adherents it sounds very much *less* appealing.

You can all stop blinking and rubbing your eyes now

AMS on 25/08/06 6:14PM [ Reply | Permalink | Report ]

AMS: "I can understand that, but you do see how that might give some people a bad case of jitters. The phrase "get RISC OS applications running on another system using a compatibility layer" - how does that help RISC OS ? Does it simply give another OS the ability to run RISC OS programs (in a fashion) and further weaken RISC OS ?"

Why would that be a bad thing? The only thing I like about RISC OS is the UI and (some) of the applications. If these can be ported to another system, with more stability; better hardware compatibility and greater room for growth, why should I care?

RISC OS is an OS. It's a tool. It's not some idol to be placed on a pedestal and worshipped. Other systems can do almost everything RISC OS can do, but better and faster. Something radical needs to happen. If open sourcing RISC OS "infects" those other systems with RISC OS concepts which make them better/easier to use/more RISC OS-like, surely - as an end-user - that can only be a good thing?

Jaffa on 25/08/06 6:37PM [ Reply | Permalink | Report ]

Andrew Flegg>It all depends on what your specific needs and wishes are. If you a keen fan of Windows (or Linux) then having RO features on these might well be all you need.

Andrew Flegg wrote>"RISC OS is an OS. It's a tool. It's not some idol to be placed on a pedestal and worshipped."

Yes but then neither are Linux or Windows.

So why should we welcome porting RO to either of those ?

Andrew Flegg wrote>"If these can be ported to another system, with more stability; better hardware compatibility and greater room for growth, why should I care? "

Well I am not sure that that would happen or if it did that any of the above would be true. Yes Linux is more stable than Windows (and RO), but I am not sure it offers greater hardware compatibility (Windows tends to do this - as much of the newer hardware technology is "closed" and not always available in any reasonable timeframe on Linux). Given that I am not particularly keen on going down the windows route that would leave me stymied.

What I am driving at is the notion that it is preferable to have the maximum possible control of the platform and OS we operate on. If we simply port bits of RO to Linux (or windows) we hand the responsibility for the OS to others who may not have the interests of RO users at heart.

The radical thing that needs to happen is that RISC OS users should get behind *their* platform, support its hardware manufacturers and stick with it. In our small little pond we have some influence - the same can't be said in the much larger Linux (or Windows) pool.

My own opinion is if I couldn't use RISC OS on native hardware, I'd move completely over to Windows and leave RO behind. This is *not* an indorsement of Windows but rather a recognition that MS has (IMHO) and will in future target Linux and will ultimately defeat it. I don't want to move from one OS failure immediately to another that will be killed at some future date - it makes more sense to admit defeat in that circumstance and opt (much as I would hate to do this) for the envitable winner, Windows (you can't even imagine how much I galls me to say that!).

AMS on 25/08/06 7:08PM [ Reply | Permalink | Report ]

AMS wrote: "I can understand that, but you do see how that might give some people a bad case of jitters. The phrase ''get RISC OS applications running on another system using a compatibility layer'' - how does that help RISC OS ? Does it simply give another OS the ability to run RISC OS programs (in a fashion) and further weaken RISC OS ?"

I was saying that it *wouldn't* appeal to me to do that, and that's the most interesting project I could conceive of doing! The best you could hope for is that the applications would run as they did on RISC OS, and that isn't interesting to me.

"What I am driving at is the notion that it is preferable to have the maximum possible control of the platform and OS we operate on."

Right, but even Castle don't have that much control over the underlying hardware platform. Once Acorn spun ARM off into a separate entity, it never had all that much control over the available hardware.

"The radical thing that needs to happen is that RISC OS users should get behind their platform, support its hardware manufacturers and stick with it. In our small little pond we have some influence - the same can't be said in the much larger Linux (or Windows) pool."

I think it's only an illusion of influence within the small pond. Although it seems counterintuitive, you have a much better chance to influence others in the Linux or BSD communities, mostly because you don't have to negotiate with a single Acorn-style vendor to get what you want. Whether you ultimately influence other users is up to you, but you can at least get your hands dirty and write code if you can't persuade people to adopt your vision. If you look carefully, you can see former RISC OS users getting involved in open source projects.

"I don't want to move from one OS failure immediately to another that will be killed at some future date - it makes more sense to admit defeat in that circumstance and opt (much as I would hate to do this) for the envitable winner, Windows (you can't even imagine how much I galls me to say that!)."

Then we might as well all give up now. The thing is: I can't see RISC OS getting as popular as Linux now is in the wider world, even on desktop machines. I think Linux is going to be around for a while.

davidb on 25/08/06 8:01PM [ Reply | Permalink | Report ]

There seems to be a lot of opposition to getting RISC OS onto other architectures. I was having a discussion with a non-RO using friend of mine about the issue and he made a very good point. "Wouldn't you like to see RISC OS being able to be run on any desktop computer?" Now might not be the best time to be concentrating on a serious x86 port or whatever but I can't understand why you wouldn't want this flexibility. To me, the 'holy grail' would be RO getting to a point where it had the features/software to draw large amounts of users from other OSs, who could simply buy some off-the-shelf hardware and run it. And if things ever came to that stage, what is there to stop Castle developing x86 or PPC machines?

"The only thing I like about RISC OS is the UI and (some) of the applications. If these can be ported to another system, with more stability; better hardware compatibility and greater room for growth, why should I care?"

Perhaps because in such a case, Castle, current owners of the OS, would lose all their income from selling desktop ARM hardware, and desktop RISC OS itself would disappear.

"RISC OS is an OS. It's a tool. It's not some idol to be placed on a pedestal and worshipped. Other systems can do almost everything RISC OS can do, but better and faster."

If RISC OS hadn't been treated as an idol I wouldn't be using it now! My first experience with RO was using Acorns daily for DTP at my work. I came to love the intuitiveness and simplicity of the GUI, and it certainly looked better than anything else at the time (early 2000). Had there not been a fanatical userbase which put RO on a pedestal and actively promoted its benefits, companies which continued to develop and support the users, then I would've said "Oh, nice OS, but Acorn is gone. What a shame," assumed that nobody would bother developing things anymore and went off and bought a Power Mac.

"The radical thing that needs to happen is that RISC OS users should get behind their platform, support its hardware manufacturers and stick with it. In our small little pond we have some influence - the same can't be said in the much larger Linux (or Windows) pool."

This is crucial. RISC OS is lucky to still have a small but fiercely loyal userbase which is enough to keep desktop development ticking along. This needs to continue if the OS is to survive in a dignified form (i.e. a complete OS, not just UI functionality bodged onto KDE in Linux). In an open source situation, we need a community who actually give a toss about RO, so meaningful development gets done, rather than people who would rather take bits away and use them in other OSes.

timephoenix on 27/08/06 07:57AM [ Reply | Permalink | Report ]

timephoenix:

The problem with trying to run it on any hardware is the number of hardware combinations and device drivers. Unless RISC OS can use any Windows device driver, you are going to end up with lots of unimpressed people. Apple focuses on their own hardware and they seem to be doing rather well at the moment....

markee174 on 27/08/06 09:36AM [ Reply | Permalink | Report ]

I wrote: "The only thing I like about RISC OS is the UI and (some) of the applications. If these can be ported to another system, with more stability; better hardware compatibility and greater room for growth, why should I care?"

timephoenix wrote: "Perhaps because in such a case, Castle, current owners of the OS, would lose all their income from selling desktop ARM hardware, and desktop RISC OS itself would disappear."

That's why open sourcing RISC OS is a good idea for *users* - there's no dependency on Castle (or anyone else) maintaining a viable business and RISC OS being lumped in with other assets when administrators or bean counters sell off the bits.

markee174 wrote: "Unless RISC OS can use any Windows device driver, you are going to end up with lots of unimpressed people. Apple focuses on their own hardware and they seem to be doing rather well at the moment...."

Apple is a wonderful example here: they've moved to commodity hardware, but are still building it themselves. They can get the benefits of the speed on x86, and users are increasingly seeing the benefits of running on x86: proprietary drivers without porting, Windows running at full speed in a virtualised environment etc. etc.

Jaffa on 27/08/06 11:11AM [ Reply | Permalink | Report ]

This may be of some interest, although there's nothing to download yet.

[link]

"ROLF is a GUI framework using the framebuffer device on Linux to provide a look and feel similar to that of the RISC OS operating system."

At the moment, it runs from a virtual console in Linux with no X running, and you have to be careful it doesn't make the system unusable (although I've come up with a simple watchdog timer mechanism that seems to usually be successful).

Andrew Flegg (Jaffa): "...open sourcing RISC OS is a good idea for users..."

That would be my opinion, as well, but I'm not interested in any of the RO code.

Simon

Stoppers on 27/08/06 3:53PM [ Reply | Permalink | Report ]

Jaffa:

Using commodity chips inside your own hardware is totally different to making it run on any commodity hardware. You still need MAC drivers for hardware even though its running under x86. The big advantage of the x86 is being able to run Windows without emualtion (with Parallels you can run Windows inside Windows) and faster MAC laptops (although mine does get a bit hot).

Apples success is in persauding that their machine is a better proposition to a lot of customers than a Standard PC, and managing to maintain a perception as 'cool' and 'better'.

Its also what Castle have done by using generic video csrds, etc whle Microdigital tried to do much more inhouse. Indeed, Iyonix is pretty much commodity hardware....

markee174 on 27/08/06 7:27PM [ Reply | Permalink | Report ]

I always used to play the 'cool and better' card when showing off RISC OS to other people, but it's pretty impossible to do that now. OK, we've got great font rendering, but then other OSs have comparable solutions now, and the stoney textures aren't as impressive as they were back in 95. Quick bootup, quiet operation and drag'n'drop are still things to rave about though.

To take an Apple approach now would need considerably better hardware which was capable of running XGL or similar 3D desktop, proper multimedia support & web browsing, decent video editing and image editing software, interesting cases, lots of marketing money... etc etc.

If the web browsing and media player issue is sorted, at least then you could aim at general entry level users who want just that - the net, DVDs and some WP.

timephoenix on 28/08/06 08:19AM [ Reply | Permalink | Report ]

Maybe drobe should run a survey on where people think the limited effort available should be focussed. I would agree on broswers as the priority....

MArkee

markee174 on 28/08/06 1:19PM [ Reply | Permalink | Report ]

Timephoenix: 'If the web browsing and media player issue is sorted, at least then you could aim at general entry level users...' Absolutely right, and more than that, you might stand a chance of keeping current users like myself on board as well. However, Castle, ROL and the remaining RO s/ware publishers seem to be completely disinterested in the browser issue, and I suspect that for many of the more capable user/programmers RO is now simply a hobby platform of no perceived serious usefulness. But I do believe, on the browser at least, that one more sustained effort comparable to Peter Naulls' last year (probably on Firefox, and including Flash support) would actually deliver a modern browser which owners of 32-bit hardware at least would find sufficiently speedy and capable to keep them going. I for one would be prepared to contribute financially to this.

bucksboy on 28/08/06 1:22PM [ Reply | Permalink | Report ]

George:

Same here. I would much rather be able to use RISCOS for most tasks and the Browser is the weak link.

MArkee

markee174 on 28/08/06 1:41PM [ Reply | Permalink | Report ]

In reply to George and Mark

I couldn't agree more. In the absence of Oregano3 then Firefox is about the best option. I was a little saddened that no one took up the development once Peter had left these shores. Even now the beta versions surpass the other RISCOS browers and I think that some effort on Firefox combined with the completion of Netsurf would be ideal. I suspect that Firefox has not been finished as all the available resource is being put into Netsurf at the moment.

bluenose on 28/08/06 1:46PM [ Reply | Permalink | Report ]

A modern webbrowser is quite a complex piece of software. It's not just about supporting webstandards like CSS or Javascript, but also letting it work with poorly designed, MSIE aimed websites among many other issues. Especially on a platform such as RO it requires a lot of work. I believe NetSurf is the best we can hope for in a market barely able to sustain itself commercially, as NetSurf need not be financially viable or commercially rewarding. Also by nature, it can utilise certain other open source 'tools' which simply cannot be used by a commercial closed source browser such as Oregano 3, aiding considerably in its development.

Oregano 3 will probably not be released for similar reasons as to why CinoDVD is 'on hold'. Marketsize and viability; like the price of a standalone DVD player, it is slightly more expensive than free to install Linux on an old PC and run Firefox on it. So why would any commercial developer take a risk by putting a relatively expensive product on a tiny market, when that same product is arguably better and free on just about any other platform?

A Media Player is almost the same as the browser - it is an essential on any modern computer. Again, a media player is a lot of work, especially when dealing with RO / ARM machines. Let's just keep our fingers crossed for Cineroma, but as long as the author intends to keep it a personal spare-time project and only release it at decent quality (perhaps v1.0), it can take from several months to years.

RO users need to come to terms that our small little platform can no longer be fairly compared to the likes of modern PC's (Windows / Linux / etc.) and Macs, especially what can technically be expected from ARM based RO machines. The exception being ofcourse its GUI, which remains outstanding and an inspiration to others. When Linux picks our GUI up, and ROX is rapidly gaining popularity, I believe that's about it - the ARM / RO machine may gracefully take its place next to the Amiga, Atari, NeXT, etc. machines in the museum. Open sourcing the OS in whole, or in part, may hopefully be what it takes for it to survive. In the meantime, try to appreciate what we already have accomplished, which is quite amazing really, when you consider the amount of resources we've had at our disposal - I believe it's been almost entirely due to a distinct love for the platform and its community.

hEgelia on 28/08/06 6:44PM [ Reply | Permalink | Report ]

hEglia:

A browser is a complex piece of software but given the discussion over porting RISC OS to foreign platforms its a simpler proposition surely?

Which is going to be easier - porting Firefox versions to RISC OS (where Chockys tools/libraries provide an increasing degree of automation) or porting RISC OS to x86?

RISC OS and Amigas OS are still being developed so I am not sure they can be compared to Atari and Next. Indeed Next has mutated into one of the most high-profile OS of the moment at it became OS X....

markee174 on 28/08/06 7:04PM [ Reply | Permalink | Report ]

markee174: "Which is going to be easier - porting Firefox versions to RISC OS (where Chockys tools/libraries provide an increasing degree of automation) or porting RISC OS to x86?"

It's also a question of which is going to garner more interest; port something which already runs faster and more reliably on better hardware to an obsolete platform, or move an obsolete platform to something which millions of people can run and try simply and easily.

A quick browse of LWN and OSNews comments shows there are lots of people out there willing to tinker with "toy" operating systems. Any of these people could be interested in porting RISC OS to x86; the number with the skill, time and interest to continue the Firefox port to RISC OS are slim.

Jaffa on 28/08/06 9:15PM [ Reply | Permalink | Report ]

Jaffa:

But there is a proven interest in Fireforx for RISCOS while the other scenario is purely hypothetical.

markee174 on 28/08/06 9:26PM [ Reply | Permalink | Report ]

Surely porting RISC OS to X86 or other alternative platforms is pointless, unless you also port all the apps as well?

BrianH on 28/08/06 9:44PM [ Reply | Permalink | Report ]

(nt)

davidb on 29/08/06 00:07AM [ Reply | Permalink | Report ]

Mark Stephens wrote: "RISC OS and Amigas OS are still being developed so I am not sure they can be compared to Atari and Next. Indeed Next has mutated into one of the most high-profile OS of the moment at it became OS X...."

And, in case you hadn't noticed, it's now running on x86 as well. ;-)

davidb on 29/08/06 00:08AM [ Reply | Permalink | Report ]

IMO Castle / ROL need to stand up here. If they want to prevent RO become a hobby platform then they should be investing money in these two necessities. I'm sure a Select-style scheme from either company would become a better proposition to people if it were to include browser and media player development.

timephoenix on 29/08/06 01:59AM [ Reply | Permalink | Report ]

markee174: Yes, there's a proven interest from users in Firefox for RISC OS; however almost all of the people with the skill and inclination to continue the port (which now, let's face it are the boring bits of fixing bugs etc.) will have another machine available on which they do the majority of the web browsing. Indeed, they'll even need one to do the building with gccsdk as the current RISC OS hardware is inadequate.

Without the need to scratch their own itch, it's not particularly alluring.

Also, as has been made clear many times before, getting Firefox working won't magically bring with it Flash or Java - two of the things which people often criticise RISC OS for lacking.

timephoenix: "If they want to prevent RO become a hobby platform [...]"

Anyone who thinks RISC OS isn't already a hobby platform is living in a dream world (or living in the real world without much money).

Jaffa on 29/08/06 08:43AM [ Reply | Permalink | Report ]

Daviddb:

Apple always had a parallel version of OS X running on Intel as a Plan B which is a lot easier than having to port it across.....

Jaffa:

Java is used a lot less in Applets on the web now. Javascript in a broswer would be far more useful.

markee174 on 29/08/06 09:53AM [ Reply | Permalink | Report ]

BrianH: Unless you have an Arm emulator.

Jaffa: If RO firefox worked as well as the the mac version works on My G3, it would seriously cut down the time I spend using the mac version, even if it only had the same flash that we currently have, presumably extensions like flashblock which i use on the Mac would still run. The only sites where a new flash would be required for me is youtube and occasionally myspace. Am I correct in thinking even Linux doesn't have a suitable flash version?

jess on 29/08/06 10:58AM [ Reply | Permalink | Report ]

hEglia: Oregano 3 (and 2 and 1) do use Open Source components, the JPEG/GIF/PNG libraries, the font renderer, the Javascript libraries are all off the shelf open source components.

timepheonix: What if they have no money to invest?

flibble on 29/08/06 12:46AM [ Reply | Permalink | Report ]

flibble: Indeed, thank you for correcting me there! I do have a copy of O1, which contains OpenSSL and some OSS libs... I'll try to be more accurate next time

hEgelia on 29/08/06 1:33PM [ Reply | Permalink | Report ]

markee174: "Java is used a lot less in Applets on the web now. Javascript in a broswer would be far more useful."

Indeed, I was careful to say that Java [in a browser] is something *people* claim is lacking.

Personally, I think Java on the desktop is much more important. People developing J2EE applications don't need anything on a platform above and beyond Java and a compiler: whatever's nicest to work in is best.

jess: yes, your analysis is spot-on.

Jaffa on 29/08/06 1:36PM [ Reply | Permalink | Report ]

JAffa:

It would be nice to run Java on RISCOS and Sun look likely to Open SOurce the language. But is the Arm chip going to deliver what most people expect in terms of performance (especially as Java likes lots of memory).

RISC OS should play to its strengths of a great UI with some good, innovative software with full support for cross-platform standards. But this needs to include a good browser and multi-media support.

markee174 on 29/08/06 1:59PM [ Reply | Permalink | Report ]

markee174: "But is the Arm chip going to deliver what most people expect in terms of performance"

Ahh, if only there was some vague notion of a proposal to run RISC OS on faster, cheaper, more available kit?

"RISC OS should play to its strengths of a great UI with some good, innovative software with full support for cross-platform standards. But this needs to include a good browser and multi-media support."

A great UI's nothing without software, which is increasingly missing; so I agree entirely. It's just a question of how RISC OS gets there: ARMs are being left in the dust, the costs of bespoke hardware are great (in terms of time and money) and there's little to no commercial development.

I can't see how opening it all up and hoping/guiding a port to x86 - including a Rosetta-like compatibility layer for existing apps - can really be any worse than the dead-end road it's on at the moment... (from a desktop user point of view, I don't care about STBs - for all the talk of STBs funding desktop development, where's the real proof?)

Jaffa on 29/08/06 5:05PM [ Reply | Permalink | Report ]

Jaffa:

Surely the cost on RISC OS hardware is not the actual harware (compare the price of Arm chips to Dual Cores) but the 'share' of the development costs for the software?

If you want to run it on a PC, Virtual Acorn gives you a visualisation.

What we really need is ONE unified version of the OS, so people are more likely to develop apps or port it??????

markee174 on 29/08/06 7:56PM [ Reply | Permalink | Report ]

"Surely the cost on RISC OS hardware is not the actual harware (compare the price of Arm chips to Dual Cores) but the 'share' of the development costs for the software?"

Arm chips maybe cheap but with Risc OS you have to get the design, development and testing costs back from a small market. Thats why the overall machines are not cheap. It will be interesting to see if Castle decide to dip their toes in again with a new Lyonix or not.

Jwoody on 29/08/06 9:23PM [ Reply | Permalink | Report ]

Jwoody:

They could include RISC OS 6 so we could then have 3 versions :-(

MArkee

markee174 on 29/08/06 10:26PM [ Reply | Permalink | Report ]

4. Most software developers (myself included) still support RISC OS 3.7 as well!

Jaffa on 29/08/06 11:58PM [ Reply | Permalink | Report ]

Markee174:

Virtual Acorn does not give virtualisation, it is emulation. i.e. It runs on top of a host OS replicating a limited set of legacy hardware, where as virtualisation gives you shared access to the full native hardware. Its an important distinction, and the difference between being a dead toy OS, and a proper operating system. If RISC OS is going to run on non ARM hardware it has to be on top of a virtualisation hypervisor, and not dependent on any other OS as an emulator is.

druck on 30/08/06 10:14AM [ Reply | Permalink | Report ]

druck: So what you would like to see would be something like this?

A cross-compile / recompile of the OS to x86.

An ARM emulator doing a similar job to Aemulor (pro) for Arm programs and modules.

Target platform (drivers) Parallels Desktop, VMware or any machine of the same specifications.

jess on 30/08/06 5:48PM [ Reply | Permalink | Report ]

jess: In my opinion, moving to a target platform with x86 architecture is the only way RISC OS will survive as a desktop operating system in the long run. It may be possible to postpone the inevitable by developing a new computer based on the new XScale design from Intel but for a long time survival the OS has to move away from the underpowered and overpriced ARM based computers. The ARM platform maybe suitable for embedded systems but is becoming a bigger and bigger millstone around the neck of the desktop operating system. Without serious performance increase and extreme cut in prices ARM based hardware is a dead-end. A desktop OS that can't playback a DVD, run an up-to-date webbrowser without taking a serious performance hit or support use of Java applications and/or Flash (I'm talking performance here) will not be taken seriously in today's world, except by a few die-hard purists that have yet to wake up from 1995.

Trouble is though, I think RISC OS has missed the chance already. Rewriting the parts that are in ARM code would probably take a couple of years by which time I'd guess those that are willing to spend money on new hardware will already have done so and moved to pastures new, be it Windows, Linux or MacOS. Even if the ARM code would be rewritten in C for example the OS itself would still have serious issues regarding multi-threading and pre-emptive multitasking which would be required to fully use modern processors, even the XScale is now moving towards multi-core which RISC OS will not be able to make serious use of even if a computer were built on that today.

Instead of making the RISC OS source hardware independent, time has been spent on making the OS 32 bit ARM compatible which would have been useful around 2000 but is of very little help today. For Pace and Castle this was and still is probably the best way for them in terms of development of embedded systems but for the desktop OS this seems to be little more than a longer rope in the gallows.

I've said it for several years now that in order to survive RISC OS must move to x86 based hardware. Nothing I've seen in the past five years has convinced me that by sticking to ARM it will ever be more than a very limited hobby OS for die-hard enthusiasts. If the numbers of users that have been thrown around here are close to the actual number the really sad thing is a new OS, written completely from scratch for the x86 computers would probably outsell that userbase in a couple of months, if only because of curiosity.

Gulli on 31/08/06 10:41AM [ Reply | Permalink | Report ]

@Gulli: You are probably right, but I don't think that everything written in ARM assembler has to be re-written. There are various other ways, for example cross-assembler or emulation (wich would be needed for legacy software anyway), to make it run on x86-64.

JGZimmerle on 31/08/06 10:52AM [ Reply | Permalink | Report ]

Of course the OS would need a new name if it ran on x86, unless it were to only utilise a small subset of the x86 instruction set. (Would cross assembly utilise a restriced set of instructions?)

What I would dislike would be if a move to x86 were as a replacement to RISC (as with Apple) as opposed to an alternative that runs in parallel.

jess on 31/08/06 12:30AM [ Reply | Permalink | Report ]

As someone has mentioned earlier, either in this or a different thread, a change of processor from ARM to x86 would automatically require a change in the OS name.

I believe that RISC OS stands for Reduced Instruction Set Computer Operating System. If we started using x86 processors the OS name would be wrong for that processor.

This would then produce a split, some people running RISC OS on ARM and others running XXXX OS on x86.

ajb on 31/08/06 1:38PM [ Reply | Permalink | Report ]

Sorry, I started my entry before Jess' entry appeared.

I was distracted by work before I finished, so it has appeared late.

ajb on 31/08/06 1:42PM [ Reply | Permalink | Report ]

People often say that 'real' OSes are not architecture-specific. But how true is this really?

Clearly Linux is, but isn't that the exception? The other Unixes appear to be mildly incompatable and architecture dependant. Windows has only ever been available for x86. Macs are migrating from PowerPC to x86; presumably they will at some point become exclusively the latter, perhaps with some legacy emulation for old apps. In contrast, mobile phone development is apparently a nightmare of different hardware specs, making each machine a different platform in practice, even though the OS might be the same. And this is holding things back.

Obviously, software manufacturers like to distribute binaries rather than sources, and as few as possible of those.

It seems to me that in some sense commercial operating systems become single-architecture due to this normalising force. Macs are not becoming multi-architecture, but transitioning from one to the another. Linux gets away with this by distributing sources and having sysops as users, who know how to type 'make'. Even if ROS were open-sourced, this wouldn't happen for commercial apps.

So. Sure the hard-coded ARM nature of RISC OS means that it isn't easy to transition to another chip architecture. But the processing-power dominance of x86 is likely to be transitory. It would make more sense to try to migrate to multi-core ARMs than non-ARMs. By hudge or by kudge, providing that it can be made elegant in later revisions.

Loris on 31/08/06 6:42PM [ Reply | Permalink | Report ]

Loris: 'real' OSes are not architecture-specific.

Windows (NT4 the precursor to 2000 and XP) ran on Alpha, Mips, and Sparc, later versions run on Itanium too. Macs have run on 68000, PowerPC and x86 Linux The BSDs Solaris (Sparc and x86) AIX (Itanium, Power PC and others) HP-UX (PA-Risc and Itanium) Amiga OS (68000 and PowerPC)

And in the embedded market Nucleus Epoc/Symbian WinCE/Pocket PC Linux (again)

I think the trickier question is to ask, which 'real' operating systems only supports one architecture?

flibble on 31/08/06 7:31PM [ Reply | Permalink | Report ]

VMS?

Jaffa on 01/09/06 00:05AM [ Reply | Permalink | Report ]

No, VMS was ported from VAX to Alpha.

druck on 01/09/06 09:59AM [ Reply | Permalink | Report ]

and then to itanium

flibble on 01/09/06 11:45AM [ Reply | Permalink | Report ]

In reply to flibble: Windows - does it still run on those? If I bought a windows CD from PCw*rld could I install it on any of those, and then install, say, Office on any of those? Macs - I mentioned that - you should read more carefully. The point here is that they are *transitioning*, ie moving from one to the other, not broadening their architectures covered. This is critical because it is the crux of my argument.

Linux - mentioned again. An exception. For the reason why, see the previous post. BSDs - OK, another Linux-like OS. Not a commodity OS. Solaris - a UNIX, not a commodity OS AIX whats that? (A unix IIRC) I assume not a commodity OS HP-UX - hmmm, isn't that a UNIX variant? </sarcasm> Not a commodity OS. Amiga OS. Don't know much about that, perhaps that is transitioning too.

I also don't think you can really count itanium in there as a separate architecture from x86, for a couple of reasons: 1) It runs x86 code. While chip people quite reasonably consider different internal structures as different architectures, from the OS vendors view supporting something which works already, however slowly, is an easy tick for the back of the box. 2) It was expected to be a replacement for the old cores, then bombed. I'm not suprised various OS vendors looked at supporting it, as a *transition* from the old-style x86.

Also if you claim that I can claim RISC OS is already multi-architecture because it can run on many different types of ARM.

I mentioned the embedded market, briefly as well. That is interesting in that it has the same or similar OSes on many hardware variants (although often the same processors), and yet they are not compatable from the consumers point of view. Nevertheless, I guess these count. Why don't you get them for desktops though? Maybe they've switched one set of constraints for another.

I think what is clear is that the 'big' OSes end-users use currently have to align all their (current, actively purchasing) users into one binary-compatible group. Transitions, like Apple did recently, may be painful, but less painful than trying to maintain two or more separate groups on different chips.

Loris on 01/09/06 4:51PM [ Reply | Permalink | Report ]

Are you taking the piss?

flibble on 01/09/06 6:13PM [ Reply | Permalink | Report ]

...maybe a little.

Do you just not like to read beyond the first sentence?

Loris on 01/09/06 9:13PM [ Reply | Permalink | Report ]

Your point of "won't developers moan if they have to develop for more than one architecture" is a tad moot. In autumn 1992 Acorn estimated there were 200,000 active RISC OS users. In spring 2006 Paul Middleton estimated there were 6,000 active RISC OS users. If that number never goes higher than 6,000 it's not worth the effort of developer doing *any* development. If supporting more than one architecture gets them more sales, developers will support more than one architecture.

I also note with amusement the changes in your argument between your two large posts.

Oh and by the way Itanium isn't an x86 architecture chip, it is its own, it also has x86 compatability instructions as well as the IA-64 ones, but the OSes that were compiled up for Itanium use the IA-64 ones not the x86 ones.

flibble on 02/09/06 02:04AM [ Reply | Permalink | Report ]

Theres no need to get snippy. I think my basic point has remained constant - although I concede I may have different assumptions, leading to my glossing over different areas.[0]

I also take your point about the reduction in prevalance of ROS users. I don't think that affects my underlying argument though. Let me try to put it another way though, and see if you agree.

* 'Many' OSes are capable of being compiled for different architectures.[1] * However, in practice, for commodity OSes [2] at any one point in time, there will be a single preferred architecture.[3] This is demonstrated by Macs migration from one architecture to another. This is a support issue at several levels[4]. * There don't seem to be the resources to make ROS easily portable. * As architectures vary in relative power and the current leader may in a sense be maxing out, it may be wise to try to target where general processing power increases are to be had.

I you read my previous posts carefully I think you'll see this position in them. I'm not saying that it wouldn't be nice to have completely portable sources for ROS. Just that it isn't necessarily something to panic about.

[0] I may also be wrong of course, but humour me.. [1] Yes yes I know, although most of those are UNIX. Also note I'm writing about practice, not theory. [2] Windows, Macs, RISC OS, (perhaps) Amiga OS etc.. [3] This needn't be the case, even for proprierary software, if a secure universal system of compilation on installation existed. Obviously this system would itself need to be portable. [4] not just (third party?) developers as you imply. Hardware is affected by the CPU. To give a far-reaching example, RAM requirements vary dependent on code density.

Loris on 02/09/06 11:07AM [ Reply | Permalink | Report ]

The impression I get is that making RISC OS run on x86 wouldn't be ridiculous. (If you stick to one set of hardware.)

If ROL or Castle had access to the tools Druck mentioned, I suspect they could roll out a proof of concept x86 version pretty quickly. Of course that wouldn't be much use to anyone without any programs.

If such a system were to move beyond the realm of specultation, would a combination of Aemulor and the red squirrel engine be a straightforward solution?

jess on 02/09/06 1:00PM [ Reply | Permalink | Report ]

In reply to Jess:

Pretty quickly? How long did it take for them to go to 32-bit addressing? It will be more difficult than that.

In response to your last question: No.

Cogs on 02/09/06 2:15PM [ Reply | Permalink | Report ]

cogs: ROL are now in the position that they can produce 26 bit and 32 bit systems from the same sources. Could these sources not be fed into a cross-assembler as Druck suggested? (or the correct compiler, as relevant).

I also said proof of concept - ie running but not salable (eighty twenty rules and all that), but enough to generate interest.

jess on 02/09/06 9:29PM [ Reply | Permalink | Report ]

In reply to Jess Hampshire:

Whether they can do this or not, some would argue that finishing Select 4 and the A9 ought to be higher priorities.

gdshaw on 03/09/06 08:53AM [ Reply | Permalink | Report ]

Graham:

Agreed. And getting it onto the Iyonix.....

markee174 on 03/09/06 09:59AM [ Reply | Permalink | Report ]

markee174: Unfortunately I'm beginning to wonder if an x86 port is more likely

jess on 03/09/06 11:00AM [ Reply | Permalink | Report ]

In reply to Jess: "ROL are now in the position that they can produce 26 bit and 32 bit systems from the same sources."

This distinction is going to be meaningless on the x86. The only advantage I can see is that if Castle and ROL have macros for saving processor state etc, then these can be easily adapted for the X86.

"Could these sources not be fed into a cross-assembler as Druck suggested? (or the correct compiler, as relevant)."

You'd have to write the cross-assembler first, unless Druck has something in mind that already exists. Even then, I don't think it's as easy as putting all the RISC OS source through a magic program and then suddenly beaing able to boot it on an X86 motherboard...

It seems clear to me that quite a lot of stuff would have to be hand-written natively. Certainly any self-modifying code. Also probably everything to do with the MMU, cache flushing, timers, interrupts, trap handlers, etc. Hopefully some of these things are abstracted and exist entirely in RISC OS 5's HAL (eg: probably timers, but probably not the MMU).

Would a cross-assembler know how to translate SWI handlers? How about the way in which SharedClibrary calls are made by branching to a negative address? Maybe some of this could be automated once the corresponding APIs are dreamt up for the X86.

Hardware drivers would need to be written - or obtained and then adapted to "CISC OS". Castle has an advantage here in that they have more experience of RISC OS on commodity hardware (graphics cards, UDMA, etc). It won't be a good proof of concept without being able to access the hard disc!

"I also said proof of concept - ie running but not salable (eighty twenty rules and all that), but enough to generate interest."

If "proof of concept" just means running one or two command-line programs on x86, it's already been done with riscose. If it means a full OS not running on top of Linux or anything and getting as far as displaying a desktop without using any emulation, then, cross-assembler or not, it's going to be a lot of work for some poor bastard.

I think, once a cross-assembler exists, porting apps etc would be easier than the core OS.

Incidentally, is cross-assembler the right term? I thought a cross-assembler just generates for the same target as the source is intended, but just the assembler itself runs on another architecture.

Cogs on 03/09/06 2:38PM [ Reply | Permalink | Report ]

cogs:

""ROL are now in the position that they can produce 26 bit and 32 bit systems from the same sources."

This distinction is going to be meaningless on the x86. The only advantage I can see is that if Castle and ROL have macros for saving processor state etc, then these can be easily adapted for the X86. "

I wasn't meaning there was any relevance to 26/32 bit, but if they've got the sources into a state where didfferent instruction setset can be supported, much of the work is done, subject to the correct cross compilation tools.

I was going on the theory that if Druck suggested cross assemblers, then it is probably a viable thing.

What I was thinking of for proof of concept was be some of the desktop running native on a PC in say 16 colour VGA mode

jess on 03/09/06 6:56PM [ Reply | Permalink | Report ]

(nt)

druck on 04/09/06 10:42AM [ Reply | Permalink | Report ]

jess: 26bit and 32bit sources aren't different instruction sets, everything in C will be exactly the same, and of the assembler its 99% the same ARM instructions and 1% conditional macros in places where a couple of different instructions have to be used on 26bit machines to maintain the expected flag preserving behavior. As said it doesn't help one iota in making it portable to other architectures.

If you feed the ARM assembler in to a cross compiler you would get the same result as the output of an emulator JIT, native instructions but something that still needs an emulation of specific legacy hardware. So you either still need to provide this, or more likely recode the hardware specific parts. As mentioned in RISC OS 5 most of the low level processor and main bus bit twiddling (including timers) is in the HAL, which would be recoded for the native architecture. The higher level hardware specific module would need adapting for the specific southbridge and video card, or more likely the unified model provided by a virtualisation layer.

Even with suitable tools there is no free lunch, it would be a lot of work, and even after you've done all that, you still need to provide an ARM JIT emulator to run all the legacy RISC OS applications which will never be converted for the new architecture.

druck on 04/09/06 10:42AM [ Reply | Permalink | Report ]

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

Create a new account
Forgot your password?

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