riscosopen (+2.1)
4/10/06 12:52AM |
I don't need people; RISC OS needs people. |
druck (+1.0)
4/10/06 9:25AM |
I've put my name down to help in any way I can. Hopefully I'll have a bit more time than in the past 18 months now I've got my PPL  |
Ginger2
4/10/06 10:54AM |
Ask not what RISC OS can do for you, but what you can do for RISC OS. |
Piers (+2.0)
4/10/06 9:23PM |
Well, I think RISC OS should run on top of Minux.
Then you'd get a stable, modern, secure kernel with all the features RISC OS's kernel lacks. You'd inherit all sorts of advanced tools from the unix world, including debuggers far better than !DDT, and ports of FireFox would be far easier.
It's along the lines of what Apple did with MacOS, and it's transformed the OS to a leading-edge design.
Or, at the very least, someone should make (most) modules run in user mode. |
Piers
4/10/06 9:34PM |
Sigh. Minix, not Minux.
http://www.minix3.org/ |
DavidPilling (+2.1)
5/10/06 5:06PM |
I agree, with RISC OS on top of a unix kernel it could be a serious contender. Or to put it more correctly without doing that it is not a serious contender. |
Piers (+2.1)
5/10/06 7:57PM |
Of course, Acorn considered doing this in the early 90s - on top of a BSD kernel (before my time). RISC OS Gold, I think it was called (each RO release had an internal name based on a colour). But the machines didn't have the memory at the time - that's the main disadvantage, really, but memory is very cheap these days.
These was going to be a compatibility window so RO Wimp apps could run - the wimp's message system really enforces co-operative multitasking. Again, this is similar to Win16 emulation on Windows, and MacOS Classic emulation on MacOS X. |
AMS (+1.0)
5/10/06 8:03PM |
Unix does Unix very well.... would Unix do RISC OS well ? I don't think so.
If I want to use Linux I'd fire up Red Hat 7 on my PC at home - why bother with this RISC OS pretense at all then.
Reading things like the above just get me tired beyond belief. Linux has a place, Windows has a place, is no one going to speak up on RISC OS's behalf - or is it just to be treated as another means to coax/cojole or otherwise push the few remaining users onto another platform.
We have feet guys - we're not obliged to shoot them 
|
sa110 (+2.0)
5/10/06 9:11PM |
Why all this talk about porting RO to another platform. One of the main problem,in my opinion, is the lack of software development in general. Not many new applications have been announced/updated since Acorn called time on RISC OS. This I believe is the biggest problem with the platform, not whether or not it runs on the latest version of the most 'in' geeky Unix or similar kernal. |
Jwoody (+1.0)
5/10/06 9:28PM |
The thing about a Linux kernel is that it makes it easier to build the superstructure that allows for easy porting of Open Source applications. Linux has open source applications, Mac OSX has open source applications helped because of its kernel. Windows has Open source applications because people decided to put the effort into porting to the defacto standard. What Open source applications do you see for Risc OS? An old version of Firefox that still incomplete. A version of Gimp that needs X Windows Client again an Alpha release. Your not going to see lots of open source applications unless you make life easier. So you are going to miss out on the Open Offices, The Gimps, Scribus Inkscapes XaraExtreme, Firefox, Thunderbird Ekiga, plus other apps like Skype |
DavidPilling (+2.0)
5/10/06 9:42PM |
The thing about RISC OS at the moment is the lack of true multitasking (much debated over the years but this aspect of Windows is much nicer), and its fragility - poke the wrong place and the whole thing falls over - not what you want in an embedded application.
However if you make RISC OS less fragile, in even the simplest way, you will break most of the existing desktop applications and there are not developers around to fix them. |
JGZimmerle (+2.0)
5/10/06 9:50PM |
Exactly. What RISC OS needs more than anything else is compatibility with other platforms. The Rest of the computing world is working hard to become more compatible with all other platforms, except for RISC OS. Even Microsoft has realised this trend and has heavily invested in its "Linux and open source compatibility lab".
The key do doing it right is to retain the RISC OS GUI and introduce a compatibility layer for legacy apps. |
mrchocky (+2.1)
5/10/06 11:21PM |
In reply to Jwoody:
not true. What we have is precisely most of this functionality to make ported programs possible. That's thanks to the GCCSDK development and the UPP, and all the people who've contributed to that. What we lack is developers and motivation for the developers who are still here. The RISC OS version of Firefox is not old, indeed it's more or less the current version.
In reply to David:
I'm not sure I fully agree. There are a couple of simple things that can be done to RISC OS to improve its stability which STD pursued with Adjust, such as zero page read protection. That breaks a couple of things, but those are easily fixed. |
adrianl (+2.0)
5/10/06 11:46PM |
In reply to mrchocky:
STD's current ROM image does not even protect zero page from USR mode writes, never mind reads. This is something that I sincerely hope will be changed soon. |
simo (+2.1)
6/10/06 12:15AM |
I'm not sure what made RISC OS great anymore, a few killer apps from ComputerConcepts (now surpassed by Scribus, Xara etc.) but mostly the WIMP I guess, certainly not the stability of the OS or ease of programming desktop apps.....
I dunno, I can't see much of a future for RISC OS on ARM hardware, or maybe even RISC OS as we know it (kernel, WindowManager etc). Maybe porting to x86 may save it - VRPCSE has been popular I guess, but native would be nicer than emulation.
Perhaps just doing a ROX kind of thing and porting the Desktop to Linux may be a way to go, imagine the RISC OS desktop running on a stable OS - multitasking, memory protection, being able to use whatever peripherals you like, a huge library of applications available for free, current hardware..... ROX never seemed to catch on though.
Thing is, if you make a Linux desktop or Windows emulator, you're just going to convert people to Linux/Windows in the long term, and they fire up ROX/VRPCSE less and less. |
Piers (+3.1)
6/10/06 12:45AM |
Obviously a contentious issue...
Modules have absolutely no memory protection; Applications have very little. Even something mundane such as wimp applications can easily crash the system - overwrite a menu pointer or window icon string, and you're lucky if you only destroy another application's window, but usually the entire OS falls down in a heap as one heap is shared by critical kernel tasks and application window workspace.
This is because the kernel was never designed, and was just cobbled together to meet a deadline. Acorn always planned to replace it (ARX, RISC OS Gold, TAOS (Intent), Galileo).
The good parts of RISC OS have nothing to do with the kernel. The font manager, GUI, filer, image filesystems etc could all be ported to a modern kernel, keeping the feel of RISC OS, but at the same time adding pre-emption, speed, stability, and creating a much easier platform to develop under - especially when writing drivers.
And comparing a microkernel such as Minix to RedHat is misguided. Minix itself is probably smaller than the existing RISC OS kernel. I'm certainly not suggesting the GUI runs on X11. |
JGZimmerle (+3.0)
6/10/06 3:06AM |
One thing I don't understand, is why people can not understand that using another system's kernel for RISC OS does not mean replacing RISC OS with that other OS. The kernel is only a very small part of the OS and one the user never directly interacts with. All user interaction takes place in things like command-interpreters (the CLI) or GUIs (the WIMP).
And while we are talking about utilising a different kernel in RISC OS: Everyone seems to agree that one of the top reasons for taking this step would be to get better hardware support. So why would we even consider using anything else than the Linux kernel? Linux has by a long way the best hardware support of any operating system ever developed. |
jb (+1.0)
6/10/06 8:26AM |
in reply to GZimmerle: "Everyone seems to agree that one of the top reasons for taking this step would be to get better hardware support. So why would we even consider using anything else than the Linux kernel?"
simply the 'invasive poison' of the linux licence (GPL). Always a matter of opinion, but a licence that requires you to give your competitors your 'goodies' under almost all circumstances does not help innovative development. |
mrchocky (-1.9)
6/10/06 9:59AM |
The GPL is neither "invasive" nor "viral", and you would do well to avoid such language. I agree it's not very satisfactory wrt RISC OS modules, but I still urge you to consider a compatible license. |
Jwoody (+0.1)
6/10/06 10:39AM |
mrchocky "What we lack is developers and motivation for the developers who are still here"
If true why not publish a guide to producing an executable
1) Where to get a RISC OS version of CVS client
2) Where to get and how to install GCCSDK and UPP
3) Where to get and how to install CHOX11 ( Or what ever its called )
4) How to get source tree from CVS for GIMP say
5) What to change in Makefile to setup Libraries and external variables etc
6) type make
7) What to look for in compiler errors
8) What to look for in linker errors
9) What needs including in !run file
I am sure that if people could at least get to produce an executable they could run, even if it crashes. It might start them on the road to porting. I fully agree there is lack of experienced developers around. But without some guide people face a very large learning curve just to get started and I think that puts off a lot of less experienced people |
DS1 (+1.0)
6/10/06 1:07PM |
In reply to Jwoody:
I think I would have to agree with this. I'm a 25 year professional, commercial applications developer, but not in C, so starting something in C would be incredibly difficult without a lot of starters. Certainly something like thismight help me get started.
Dave |
markee174
6/10/06 1:23PM |
If Castle setup their C/C++ library with scripts to build RISC OS, it would be another incentive to consider purchasing |
JGZimmerle
6/10/06 1:59PM |
IIRC the GPL would not "infect" RISC OS modules, as they are "separate works".
Here are the relevant paragraphs:
---------- snip ----------
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
---------- snap ----------
This basically means, that if an identifiable section of source code also works without the GPLed parts, then it is considered a "separate work" and the GPL does not automatically apply to it. Since RISC OS' modules are identifiable sections of code wich would work without other GPLed modules and without a GPLed kernel, for example when compiled for the RiscPC, they would not automatically fall under the GPL.
|
guestx
6/10/06 3:18PM |
Super digest follows...
In reply to DavidPilling:
"I agree, with RISC OS on top of a unix kernel it could be a serious contender. Or to put it more correctly without doing that it is not a serious contender."
Wise words indeed.
In reply to AMS:
"would Unix do RISC OS well ? I don't think so."
Mac OS X does classic Mac nicely enough, so there's a notable precedent that you're ignoring.
In reply to sa110:
"Why all this talk about porting RO to another platform. One of the main problem,in my opinion, is the lack of software development in general."
The two things aren't entirely independent. Having the machine lock solid because some kernel module (erm, relocatable module) dips into the OS workspace or some hardware register really undermines any attempt at a reasonable development environment.
In reply to simo:
"I'm not sure what made RISC OS great anymore, a few killer apps from ComputerConcepts (now surpassed by Scribus, Xara etc.)"
I'm not vouching for Scribus, and Draw still does some things more elegantly than Inkscape, although that's mainly due to the inability of developers to maintain usability whilst adding features, but there isn't any part of the RISC OS experience I can think of that isn't surpassed by something like KDE plus GNU/Linux. Back in 1994, RISC OS could have taught the UNIX desktop scene a few tricks; now the influence is definitively reversed.
In reply to JGZimmerle:
"This basically means, that if an identifiable section of source code also works without the GPLed parts, then it is considered a "separate work" and the GPL does not automatically apply to it."
This is why large parts of KDE, including derived works based on KDE code, can be distributed under the LGPL, although a complete, functional KDE distribution would most likely be licensed under the GPL due to the underlying library licences. |
Jwoody
6/10/06 3:24PM |
guestx
"and Draw still does some things more elegantly than Inkscape"
For an equivalent of Artworks or better see XaraExtreme but then they both eminate originally from Computer Concepts as was. Certainly more elegant than Draw and reads Draw files to boot. |
druck (+1.0)
6/10/06 3:40PM |
In reply to JGZimmerle:
My reading of the first paragraph contracts the meaning you are assigning to it. Separately distributed GPL softloading modules do not affect the status of other modules or the kernel, but a distributing a ROM image "a whole work" comprising of some GPL modules and/or a GPL kernel would come under the clause; "the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."
GPL is the wrong licence for RISC OS. Its aim is to foster collaborative development to compete against the established commercial interests of first Unix then Windows, and to prevent that work from being bought up and suppressed, or used without permission in commercial products. Its good for that purpose, but is not the "god license" and by no means suitable for every purpose, no matter how willing people are to evangelise it.
While we want the release of RISC OS source to encourage a open source developer community feeding back enhancements for the benefit of everyone, that is not the sole aim and will not ensure the future of RISC OS. To ensure that both hardware manufacturers and software developers stick with the platform, there still needs to be financial input from commercial ventures using RISC OS in vertical markets. For RISC OS to be considered 3rd parties must be able to make their own enhancements, adding value to the product without having to make that code available to their competitors, as the GPL would require.
Lets not get lost in the license issues - over in Linux most effort is now creating noise over GPL2 vs GPL3, and we can't afford to waste time like that. If you are interested in the future of RISC OS then what’s on the table is a reasonable compromise between commercial and open source interests, and will allow us to start working and taking the OS forward. |
mrchocky (+1.0)
6/10/06 3:54PM |
In reply to druck:
"over in Linux most effort is now creating noise over GPL2". I watch Linux development very closely, and I'm certain that's not the case. We're much better at wasting time in RISC OS land, and wheel reinvention.
"GPL is the wrong licence for RISC OS." Let's not be so quick to make such sweeping statements. GPL might well be an excellent choice for parts RISC OS. But note that I was very careful in my wording and said "GPL-compatible".
|
mrchocky
6/10/06 3:55PM |
In reply to jwoody:
[Link: www.riscos.info] |
guestx
6/10/06 4:16PM |
In reply to mrchocky:
"I watch Linux development very closely, and I'm certain that's not the case."
Indeed. Relicensing Linux might now be conceivable (thanks to the auditing which followed the SCO charade), but isn't a particularly likely event. Comments from prominent kernel developers have mostly been posturing and/or misrepresentation of the actual GPL 3 content, but I doubt that they're diverting anyone's time away from technical matters.
In reply to mrchocky:
"GPL might well be an excellent choice for parts RISC OS. But note that I was very careful in my wording and said "GPL-compatible"."
Moreover, a dual-licensing arrangement where the GPL is offered alongside the "proprietary licence for paranoid companies" would present a superior solution to that proposed. Nobody is really suggesting that the GPL would placate those paranoid companies, so stating the situation as the GPL alone vs. the RISC OS "Open" combo (as druck does above) really adds no insight to the discussion. All I stated in the comments to the original article was that for the stated aims of RISC OS "Open", the GPL would be superior to their "in due course" licence for the reasons given by mrchocky in that same comment thread (and alluded to above). |
nijinsky
6/10/06 4:18PM |
IN reply to anyone getting their heads round running RISC OS on a linux kernel.
Back in my PhD days I used to run an automated framegrab from a microscope running MacOS8. For a wee bit of stability for the weeklong experiment I uised Mac On Linux.
see http://www.maconlinux.org/
Now before anyone says emulation, back then it was more simple. I turned on the machien and it booted straight into MacOS8. So I assume RISC OS would be the same.
If ported in this way.
Cheers
Bob; back to Slackware/VectorLinux.
|
JGZimmerle
6/10/06 4:42PM |
In reply to druck:
"My reading of the first paragraph contracts the meaning you are assigning to it. Separately distributed GPL softloading modules do not affect the status of other modules or the kernel, but a distributing a ROM image 'a whole work' comprising of some GPL modules and/or a GPL kernel would come under the clause"
No, the distribution in binary form is not what is meant by that paragraph, as is clearified in the last pragraph I quoted from the GPL. So my point still stands, that we could use the Linux kernel as a new kernel for RISC OS, without the risk of having to put legacy RISC OS modules or applications under the GPL as well. To make that absolutely certain, we only have to ensure, that the modules and applications (in source form) will still work with the legacy kernels as well.
I am certainly not evangelising the GPL, it is just another licence. However it would be useful to bring Linux' hardware support to RISC OS. With the RISC OS sources becoming available, it will become a lot easier to make native builds of RISC OS for different hardware architectures, once a cross-assembler and an interface-layer between a Linux kernel and RISC OS modules has been created. An ARM emulator could be integrated into non-ARM RISC OS versions that provides compatibility for legacy applications wich are not developed anymore. |
| 1 comment(s) are below your moderation threshold. Login to view them. |
| Use the forum for more comments on this article |
Web monkeys and source code jockeys are being recruited by 
