2006 predictions | Drobe.co.uk archives

2006 predictions

By Chris Williams. Published: 2nd Jan 2006, 17:22:44 | Permalink | Printable

Belated summary of news expected some time this year

Looking pretty much like a blank canvas, 2006 is barely out of its box and plastic wrapping. With a whole year ahead of us, anticipation is mounting on what will appear over next 12 months. Sadly, we didn't get a time machine nor a lottery win for Christmas, so rather than confidently predicting what will emerge, we'll settle for making educated guesses instead.

NetSurf
The browser is hurtling towards its first stable, formal release and this is expected to be completed some time this year. Since its inception, the open source web browser has been like a roller coaster with each build generated automatically every night using source code hot off the developers' hard discs. Version 1.0 will hopefully be a snapshot of the application that users can rely on while the programmers work on the next set of features: it's understood that adding support for Javascript and related functionality is 'feasible', depending mostly on how much free time coders can commit to the task. A disc cache is also close to completion.

Oregano 3
Patience is a virtue, as the saying goes, but for Oregano users, it's a necessity. Last year, Oregano overseer Richard Brown gave Oregano 3 a shy green light after a number of users expressed (again) an interest in seeing the next RISC OS incarnation of Oregan's web browser. With big customers like Sony, it ultimately rests on how much attention and time can be spared by Oregan as to whether or not O3 appears this year.

Select 4
It was going well up until the pointless legal battle of 2004 drained everyone's resources. Now the project is understood to be on its feet again and RISCOS Ltd. are aiming for a second quarter release, which we think is a fair estimate given what's been shown in public so far. Predicted features include a mountain of bug fixes, increased stability, Filer keyboard shortcuts, Filer toolbar, enhanced 'Set type' sub-menu in the Filer, improved Toolbox modules, abstracted graphics support, improved image handler plugins, updates to meta-key handling to reflect Castle's changes, new networking modules to make network configuration even more painless, and so on.

Iyonix Select
After some gentle arm twisting, a port of Select for the Castle Iyonix is slowly coming together and it's predicted that this won't be out until after Select 4 is - the exact timescale hinging on how much more time must be spent on delivering promised work to Select subscribers and finishing off their 32bit work. How ROL will softload their RISC OS 4 kernel and keep the RISC OS 5 device drivers is still on the drawing board.

A9home
If this doesn't appear in 2006 then, dare us say it, this wee ARM9 computer may be too little too late. The system is mostly complete and stable, with work needed on some final sub-systems, such as the audio output and harnessing the DMA functionality in the chipset. We suspect AdvantageSix will also be keeping an eye on the eBay market of 2nd hand StrongARM RISC OS systems, crossing their fingers to make sure prices increase as fewer items are listed.

RISC OS 5.10
It's been a long time coming, especially after Castle updated their Nvidia driver module to make it more compatible with recent GeForce video cards, and a formal release via the Iyonix Update Watcher should arrive before long. Hopefully, they'll sequeeze in the time to fix all the long standing bugs that have been reported by users over the years, and possibly take a look at moving ShareFS over to using TCP instead of UDP to improve the reliability of the file sharing system.

VirtualRiscPC on Mac OS X
Will it appear this year? The Linux version has been relegated to the vaults after VirtualAcorn decided it wasn't worth the end user support hassle and dealers have been reluctant to add such a port to their line up of PCs 'running' RISC OS for pretty much the same reason. Predicting whether or not the hardware emulator will appear on Apple's platform is tricky because it depends on how large a market VA sees Mac OS X. Apple are expected to introduce the start of their Intel x86 based computers this year which could open up an increased market share for them.

Multimedia
The success of Adrian Lees' DVD player software now depends upon whether or not ADFS can be improved and enhanced to make it efficient enough to achieve the data transfer rates demanded by DVD playback without hogging the processor. Programmers who have casually looked into producing a RISC OS port of the open source Real player have said such a project is practicable provided there is someone available who can put in the time and patience to see it through. 2006 could well be the breakthrough year for multimedia, albeit only if a developer or three are not only willing to commit themselves but if the actual hardware and operating system are capable of supporting modern multimedia playback.

ArtWorks
Adding multi-page handling to ArtWorks has been described as difficult by developer Martin Wuerthner, although there are other items potentially on the 2006 to do list: alpha channel image export and import and a panel to quickly apply styles to paths.

TechWriter
The previously reported macro programming language unveiled for the TechWriter family is on the back burner for now, but one feature that could be developed this year is so called 'pdfmark' support. This would allow EasiWriter and TechWriter to include the document structure view and any hyperlinks when a document is printed as a postscript file, which would then subsequently be included in a PDF file distilled from this postscript.

Open sourcing of projects
Or rather, the lack of. Castle aren't big fans of opening up parts of RISC OS, although they like using bits and pieces of NetBSD and FreeBSD. They were also against the open sourcing of the Printers+ user interface. RISCOS Ltd. similarly aren't keen to open source their core intellectual property, and neither is Viewfinder developer John Kortink. In such a tiny market, no one feels they can afford to publish the source code of commercially available assets, and as such it's presumed the OS will remain a closed and proprietary technology through 2006.

SharedCLibrary headache
A9home users will be snookered if this issue isn't resolved by the time the AdvantageSix machine is ready to be launched. Due to version numbering and functionality inconsistencies in the two SharedCLibrary modules developed independently by old pals Castle and RISCOS Ltd., users of 32bit RISC OS 4 will be left out in the cold when they find that some 32bit applications refuse to run on their new machine. There are a number of solutions, for example, Castle offering a 32bit version of their SCL module from their website, or RISCOS Ltd. bringing their SCL in line with Castle's in terms of functionality. Until this is addressed, we can only predict outcry. If there was ever a prime reason why the OS should be merged, getting this fundamental component of the OS synchronised would be it.

Links

Back to the front page Become a writer

Previous: Best of 2005 awards results
Next: News in brief

Discussion

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

Um, yeah. Plagarism? Never. If you're going to rip off what I wrote, then at least bother to credit me. Too much of the above sounds like what I wrote just a few days ago:

[link]

Note mention of JS in NetSurf, open sourcing RISC OS, bug fixes in RISC OS 5 and other items.

At least when I wrote about comedy moments of 2005, I tried to avoid anything previously mentioned on drobe's "own goal" category.

[link]

And people wonder why I made such a noise over the omission from the awards.

mrchocky on 2/1/06 5:45PM
[ Reply | Permalink | Report ]

Peter: I was thinking exactly the same. Large elements of this article are taken from your blog. Christopher really needs to sort it out.

Shadow on 2/1/06 5:53PM
[ Reply | Permalink | Report ]

Just so people know. There is further "off topic" discussion of this article here:

[link]

Shadow on 2/1/06 6:03PM
[ Reply | Permalink | Report ]

No VA for Linux - terrible start to 2006 for me that. Which widget set are they now using? If it's wxWidgets, why not ask some enterprising Linux bod to port it over? I would guess the support required for Linux would be *masses* less than is required for Windows or Mac.

Oh well. Pity my emails to VA asking for help on getting VA5K running on a Linux box went unanswered (looks like a DirectX issue) nor can I get my copy of VA-RPC to run on a Linux box which I know one PC distributor (at least) was interested in [both under WINE of course!]. Well, that's one way not to make some money. Looks like VA is taking a leaf from ROS Ltd's books ;-p

(Yes, I was up until 4 this morning with my daughter and her tummy bug)

Nodoid on 3/1/06 8:09AM
[ Reply | Permalink | Report ]

I suspect its not the porting of it to linux thats the issue, its supporting it. Linux is a moving target, and one that's moving fast.

Which version of the libraries do you link against? will they still be there in the next release? are they the same on debian/fedora/suse? Getting things to work on Linux can be a real headache. If anything needs to be a kernel "module" they you have a real nightmare. The nVidia drivers are a good example of this - upgrade your kernel, reinstall your X drivers.

Unless you want to supply a "sealed box" solution (ie. boot up into RISC OS, if it all goes wrong put this CD in and reinstall) I wouldn't want to support it. Sure, a linux expert could keep it running, but someone who's just downloaded Fedora and installed it - they'd expect support when FC5 came out, as would a debian user, a SUSE user.

cmj on 3/1/06 10:41AM
[ Reply | Permalink | Report ]

Re ROL & Castle not being keen on Open sourcing this is an irrelavence that I have pointed out on more than one occasion! Both ROL and Castle have contracts that forbid them from releasing the sources. I doubt Pace would be agreeable to change the contract without a very large sum being paid, and I think other companies including (E14 inc, MSDW holdings etc) may also need to be 'bought off' In fact given the complicated nature of RISC OS IPR and licensing I'm not sure anyone knows what other companies have rights to what.

Why do people keep bring this up and wasting theirs and others time on it?

chrisevans on 3/1/06 12:06PM
[ Reply | Permalink | Report ]

cmj : "Which version of the libraries do you link against? will they still be there in the next release? are they the same on debian/fedora/suse?"

This is a good point (and I won't even go into Debian being so far behind sometimes it makes Win98 look like a modern OS at times). I would imagine that linking against wx2.6.2 (the current version) and supplying a custom build (which won't break when 2.6.2 changes) is probably the best way to go.

You're right about the moving target. However, now that Mac OS X is BSD with a fluffy front end, you can probably include them in that statement (albeit not moving quite as fast).

FC5? I'm still testing FC5test1, the full release isn't due out for a couple of months yet!

Nodoid on 3/1/06 3:42PM
[ Reply | Permalink | Report ]

chrisevans: "Both ROL and Castle have contracts that forbid them from releasing the sources. I doubt Pace would be agreeable to change the contract without a very large sum being paid, and I think other companies including (E14 inc, MSDW holdings etc) may also need to be 'bought off' In fact given the complicated nature of RISC OS IPR and licensing I'm not sure anyone knows what other companies have rights to what."

"Why do people keep bring this up and wasting theirs and others time on it?"

Well, since you ask...

E14 and MSDW no longer have an interest in RISC OS. Pace's agreements with ROL and Castle cover code licensed (in the case of ROL) or bought (in the case of Castle) from Pace, but not any code written by ROL or Castle themselves. Hope this helps.

Will! on 3/1/06 4:17PM
[ Reply | Permalink | Report ]

Chris>"How ROL will softload their RISC OS 4 kernel and keep the RISC OS 5 device drivers is still on the drawing board."

I suspect they won't implement it in the way the above sentence suggests. The only workable way would probably be to leave RO5 largely in place (kernel, drivers etc.,) and have new Select modules softloaded that provide the "extended" functionality - but still using RO5 for all the other stuff. Some of the Select extensions may be amenable to that - others might need a bit of "work".

That all having been said - has ROL confirmed that they are satisfied that the required "100" commitments have been made? If your suggestion that ROL are still at the "drawing board" stage for something as fundemental as softloading on RO5 then I wouldn't be optimistic about seeing RO5 Select anytime soon.

The other relevant point is I don't think *any* RO5 users would want to lose any of the advantages it provides just in order to softload Select - I certainly know I wouldn't

AMS on 3/1/06 8:16PM
[ Reply | Permalink | Report ]

In reply to Will E14 & MSDW may not currently have an 'interest' in RISC OS but they have rights which they retain until they transfer them to someone else. They might be able to make a public formal declaration that they were renouncing those rights, but I can't see that happening!

chrisevans on 4/1/06 12:07PM
[ Reply | Permalink | Report ]

chrisevans: Sorry, I should have made that clearer. MSDW and Element 14 sold all rights to RISC OS to Pace in 1999. Hence they no longer have an interest in RISC OS.

Will! on 4/1/06 2:47PM
[ Reply | Permalink | Report ]

In reply to Will!

I think it's worth clarifying that MSDW/E14 sold all rights, that they owned, to Pace. Neither of them could transfer rights that they did not own. In addition the transfer of rights also includes the transfer of obligations. If there was an obligation not to allow RISC OS to be open sourced then this would still apply.

VirtualAcorn on 4/1/06 3:47PM
[ Reply | Permalink | Report ]

In reply to AMS: One thing more often than not suggested was to softload the Select features as modules on top of RISC OS 5 but ROL kept busy claiming that that was not possible since they need kernel changes for that. Thus it is no surprise to think that they plan to load their full OS and use just the odd hardware driver module from the RISC OS 5 ROM. I'd even dare assume that their graphics driver change with abstraction layer is one step towards this goal. The problem perhaps arising is if things like Aemulor, Geminus etc. will run with Select on RISC OS 5..

hzn on 4/1/06 4:29PM
[ Reply | Permalink | Report ]

VirtualAcorn: Indeed. To date, no-one has asked Pace if they would agree to the opening of the components of RISC OS that they have no commercial interest in developing and which have no commercial value on their own (e.g. CDFS, BASIC, Edit, Draw, Paint etc).

Will! on 4/1/06 4:32PM
[ Reply | Permalink | Report ]

Will - but equally I suspect no one has asked Castle/ROL if they want/are prepared to open source any parts of RISCOS either.

On a related thought, parts of the printers system was made open source, did anything ever come of it?

DS1 on 4/1/06 4:54PM
[ Reply | Permalink | Report ]

hzn>It's taken ROL perhaps 2+ years to get their 32bit OS to work to the extent it does on the A9.

If you're right in thinking that it is (to quote you) "no surprise to think that they [ROL] plan to load their full OS and use just the odd hardware driver module from the RISC OS 5 ROM" I for one would be horrified. ROL's OS knows *nothing* of Iyonix! The Iyonix is *so* different from the RPC or A9Home that to do what you appear to suggest would take ROL a year or two.... Also Castle's drivers and modules are written to work on the Iyonix with its HAL and kernel - how do you think they'd react to an RO4 derived 32bit kernel then (just look at the "fun" regarding the 32bit SCL issues on the A9 to see how a relatively small change can cause *real* problems for the principals and users respectively).

You correctly point out that "The problem perhaps arising is if things like Aemulor, Geminus etc. will run with Select on RISC OS 5.". I'd agree - but if there were such issues one would have to seriously question the value of using Select on the Iyonix in the first place.

The *logical* approach is for ROL to modify their Select modules (after all they have the sources to these) and get them to work with the underlying OS (RO5) whose API is well documented. The other issue (which no one has really tackled) is that if ROL don't do hardware - and therefore are unlikely to *add value* to any existing or new hardware features on Iyonix - and if Castle have to try to get complex low level code to work with any new hardware but working also with an OS they don't control I would think we'd wind up seeing real problems (e.g., delays and bugs with one side blaming the other - can't wait for that (not....)).

For all those reasons I seriously hope that ROL will consider *softloading* their Select modules on top of a *full* RO5 OS - as IMHO I believe it to be the least likely to cause end users (or even ROL themselves) problems.

AMS on 4/1/06 7:24PM
[ Reply | Permalink | Report ]

In reply to AMS: I agree with your comment above.

1. What I tried to state is that due to ROL more often than not stating that sofloading their Select features as modules on top of RO5 is *not* possible because of kernel changes needed I kind of have the impression that they're into offering a full RO as IYONIX Select but using the hardware drivers of RO 5. That was not meant to mean that I consider that a viable or likeable approach.

The claimed need of kernel changes is something which is hard to believe (me not being the only one thinking it hard to believe) and should not affect but very few things (if any functionality at all) - just think of add-ons like ImageFS, CDROMFS and LayerFS etc which show what can be done on top of an existing RISC OS. Furthermore looking at the IYONIX demos ROL does where they do softload the odd module to show Select functionality on RISC OS 5 does let this "kernel changes needed" claim look a bit strange :-)

2. What I personally would prefer and ever since told anybody happy to listen or read and explicitely to PM@ROL is a set of modules and applications being supplied as IYONIX Select which add the Select features to RO 5 which are missing there (some are already present in RO 5).

For ROL that softload module/applications approach should offer the odd advantage: Less work (the IYONIX demos showing that parts are already done) and thus less invenstments needed and thus less financial risk. Furthermore no need for a RO license saving even more. The result should reduce the risk of incompatibilities with things like Aemulor and Geminus (and thus the need for the author to update both) and due to being much cheaper to produce it should be *cheaper* for the end user. This would result in more sales and thus probably more income for ROL which is what they need it to be commercial viable.

3. Unfortunately to the best of my knowlegde (which in this case is derived from the odd internet source like drobe as well as infos directly from PM@ROL) the softlaoding of Select feature modules and/or applications on top of a full RO5 is something ROL is not looking at... The meaning of that as for time scheduled, pricing etc is left to the reader to figure out (I can't anyhow) :-(

*But* *I* *am* *be* *very* *happy* *to* *stand* *corrected* *on* *all* *this* *by* *ROL*.

hzn on 5/1/06 1:42PM
[ Reply | Permalink | Report ]

cmj: "Linux is a moving target, and one that's moving fast."

I don't doubt that there are library versioning issues, but large numbers of people don't seem to have problems releasing software for GNU/Linux even in binary form, although I'd accept that many probably make packages for the distributions they actually use rather than a generic package that is intended to work on anything.

However, things like the LSB should give some kind of isolation from lower-level library evolution.

guestx on 5/1/06 2:49PM
[ Reply | Permalink | Report ]

hzn: I believe what PM was demonstrating at the roadshow was closer to your 2nd statement that your first: PM demonstrated that entire modules were replaced from the original RISC OS 5 ones, making the resulting system an amalgamation of RISC OS 5 and Select. Of course, I may have misinterpreted what he was saying, but this was what appeared to be the case.

jymbob on 5/1/06 3:32PM
[ Reply | Permalink | Report ]

hzn: Well, my hunch is that ROL intends to provide a universal RO, i.e. for all existing machines. If they need to 'isolate' certain RO4/Select functions into stand-alone modules to load on top of RO5 (which should be feasible), they would lose precious development time for their main work - RISC OS 4 development. Furthermore, if ROL need to provide abstracted versions of their (evolving) Select features for RO5, the gap between both lines of RO will continue and likely expand. My opinion is one version of RISC OS for all machines. Castle does hardware + drivers, ROL does the OS. That almost seems to be the case anyway. RISC OS 5 currently is almost at version 5.10 - it took Castle 3 years.

Also, last I heard, the 2004 deal between ROL and Castle still stands. Both parties are to provide code/time/programmer to develop a unified version of RISC OS.

One more thing. I believe we (including me) need to stop referring to Select as if it is something seperate. I now tend to believe Select refers merely to the subscription scheme of ROL. The fact is we are talking about RISC OS 4 when we refer to Select. So, essentially, we are talking about taking something out of RO4 and 'bolting' it onto RO5! Still, to make these things formal, I believe ROL must make things clearer by explaining their work on their website. ROL for dummies style.

hEgelia on 5/1/06 3:32PM
[ Reply | Permalink | Report ]

Its pretty obvious to anyone who has looked in to the RO5 HAL model that it is the way forward and superior to the mish mash of procressor and device specific code in the Select, RO4 and earlier kernels. The mention by ROL that certain Select features can't just be softloaded on top of RO5 because they are dependant on things in the Select kernel, reinforces this point, as those things should not be in the kernel to start with, but suitably abstracted.

If we are to prevent any further wasting of time and effort on duplicated OS development, and gain a true single source, one size fits all OS, ROL must licence the underlying RO5 kernel and HAL from Castle and add their value on top of this with Select features. There is then a clear well defined boundary between device specific and general OS code, both technically and commercially. The resultant OS can then be deployed on the Iyonix, A9, Risc PC and other legacy machines, bringing its advantages of hardware indepenence and enhanced APIs to all RISC OS users.

Will it happen? - No.

Paul Middleton is on record as describing all the other players in the market and Castle in particular as "Bastards Bastards Bastards", and their cheif programmer (if he's still working for them) views the minor internal divergence of Select and RO5 as schism of religous beleifs, and about as likely cooperate on integration in to a single source as as sunni and shia muslims are to get back together in Iraq.

Castle also view working with erratic management style and financially untransparent ROL with horror. They've never really seen the Select features as something which sells new machines, and while they might welcome the ultimate goal of a single source and letting ROL play with the UI bells and whistles while they concentrate on hardware and embedded projects, getting there is going to be nothing but pain. They could be faced with the intermediate step of a Select over RO5 bodge generating a nightmare of support issues, which users wont be able to distinquish between problems with hardware for Castle to deal with and OS bugs for ROL to fix. A two tier local governement style buck passing ring is bound to deveolop damaging the reputations of all concerned.

My personal view, which I'd very dearly like to be proved wrong on, is that there will only be one source again when there only one company, i.e. a merger or more likely one or the other going to the wall. My bet would be the one that has taken its customers money for 19 months and failed to deliver any kind of product.

druck on 5/1/06 4:53PM
[ Reply | Permalink | Report ]

Castle owns a share in ROL,right? Why don't they simply convince other shareholders to disband ROL and trade their ROL share for Castle + still keep the select program going. And don't forget that an agreement was signed forcing ROL's OS to merge with Castle 's OS sadly this seems to take an awfull time.It's seems like such a wast 32 bittifying the OS for the A9 why didn't they simply use Castle 32bit OS

highlandcattle on 5/1/06 5:21PM
[ Reply | Permalink | Report ]

Since its initial release at least 400000 pounds have been invested in the development of RISC OS 4 prior to its 32-bitting. Why should that be thrown away for a 32-bitted OS (RISC OS 5), that is otherwise mostly at the development stage of the initial release of RISC OS 4? Today it is a lot easier to convert software to be 32-bit-clean than it was when RO5 was 32-bitted, because all the tools necessary are there now, where as for RO5 they had to be developed first and a lot was probably done by hand. So it is probably less work to 32-bit RISC OS 4 and make it Iyonix compatible, than it is to develop RO5 to the stage wich RO4 has evolved to. Hopefully this will happen in cooperation with Castle, to utilise the many man-years of work they put into driver development.

JGZimmerle on 5/1/06 11:11PM
[ Reply | Permalink | Report ]

In reply to JGZimmerle: RUBBISH!

Vasty more money and resources were invested Pace in converting and restructuring RISC OS 5 than Select. It has a modern HAL structure which is essential for future support of modern processors and chipsets. RO4 still has the adhoc non abstracted kernel jumble and the only thing Select did down there was move some of the stuff round and create lots of dynamic areas which are fundementally unsuitable for the 32bit memory map.

Yes Adjust32 was probably converted to 32bit quicker than RO5, because its fundementally the same code as Adjust26 and the oppotunity wasn't taken to make the major architectural improvements. That makes it far more difficult to port to the Iyonix and any other machine, not easier.

All of the high level bells and whistles of the UI and the new APIs from Select can be utilised in any future OS, but the low level structure of RISC OS 4 needs to be consinged to history where it belongs.

druck on 6/1/06 9:55AM
[ Reply | Permalink | Report ]

druck: I don't feel your comments are entirely fair. I don't think anyone except for a very few people inside RISCOS Ltd know what the internal structure of the RISC OS 4 kernel is at the present time; e.g. how the source code has been adapted to support different hardware platforms.

The RISC OS 4 kernel has been divested of much baggage that arguably doesn't belong in a kernel; e.g. the OS_Convert SWIs. This is something that I applaud. Does it not count as restructuring?

Dynamic areas are only unsuitable for the 32 bit memory map when there are no sensible limits set on the amount of address space claimed. As far as I can tell, this is not the case for RISC OS 4 (most of the new dynamic areas appear to be limited to 16Mb or less, and there aren't an excessive number of them).

It would be fallacious to suggest that the HAL in RISC OS 5 removes the need for device drivers to be written for new hardware, as some people appear to believe. However the limited abstraction it provides is valuable so I hope eventually the OS 4 kernel will present a similar interface for the benefit of those writing driver modules.

Frankly I don't see how RISC OS 4 for Iyonix could work without providing some kind of implementation of the OS_Hardware SWI.

thesnark on 6/1/06 7:55PM
[ Reply | Permalink | Report ]

If RISC OS 5 is 'the better OS', as druck suggests, they why did STD pay RISC OS Ltd to convert Select to the A9, rather than taking the already 32bit RISC OS 5. If the HAL is any good, that should have been a much simpler (and cheaper) task?

I know nothing about the Castle HAL, but i will point out that RISC OS 5 currently only runs on one platform. The Castle Iyonix.

cmj on 8/1/06 12:41PM
[ Reply | Permalink | Report ]

druck: Do you mean the HAL that was developed by breaching the GPL, and failing to acknowledge its original authors? [link]

md0u80c9 on 8/1/06 1:57PM
[ Reply | Permalink | Report ]

I'd probably conject that STD chose Select rather RO5 because it's the more desirable OS from a desktop user's point of view, I know that the features in Select have me more interested in an A9 than an Iyonix, despite the very numerous hardware benefits the Iyonix has. And to be fair on Castle, they have demoed RO5 on MiMagic boards and the like for embedded customers. RO5 might be the 'better' OS from a technical point of view, to be honest, I really wouldn't know, but Select is a great deal more appealing from a 'give me the nicest version of RISC OS' point of view.

thegman on 8/1/06 2:02PM
[ Reply | Permalink | Report ]

@thegman:

I don't believe that Ad6 would choose RO4.4x over RO5 for the features that are nice for desktop users. Their main business comes from customers in the embedded market. If RO5 would have such enormous technical advantages over RO4.4x as some people claim, that would have taken priority over the desktop features.

JGZimmerle on 8/1/06 2:18PM
[ Reply | Permalink | Report ]

thegman:

Out of interest what specifically is your "nicest version of RISC OS" point of view?

It might be an idea for some select advocate users to explain what they like about select.

We have never had select and therefore would need to understand why we would want it on our Iyonixes

ROHC on 8/1/06 2:20PM
[ Reply | Permalink | Report ]

In reply to ROHC: A quick google or search on drobe returns the following and more about RISC OS Select: -

[link] [link] [link] htt p://www.drobe.co.uk/search/?launched=yes&type=drobenews&terms=select

sa110 on 08/01/06 3:14PM
[ Reply | Permalink | Report ]

ROHC:

I don't know about thegman, but there are certainly a number of Select features that I'd like to see on the Iyonix, from an end user point of view.

Just a few that spring to mind are the following:

Writable icon cut and paste - allows text in icons to be selected for cut and paste. This is such a simple thing, but makes such a big difference and must be part of every other WIMP system under the sun!

Sprites with alpha channels - allows you to create and use icons with variable transparencies, providing proper transparent drags, and proper anti aliased icons independent of the background, for example.

Better network sharing - you can share individual folders rather than whole drives.

Better configuration - for example, network configuration changes occurs immediately, instead of needing a restart.

Better apps - Paint, Draw etc. are improved.

That's just a few things off the top of my head and there are many more. Most of these are UI changes, so it really ought to be possible for them to be layered on top of RO 5.

Having said all that, I do personally really enjoy RO 5 as well, and it also has benefits over Select: things like pop up printers, nice USB funcionality (USB drives just appear on the icon bar), large application task memory, Internet updates, very fast boot time. These are also important from a user perspective and I'm not sure I'd be willing to lose them to gain the Select benefits.

Sorry for the long post. It's just that in my opinion RO 4 and 5 each have some great unique features and I don't know of any proper comparison that highlights the stengths of both.

flypig on 08/01/06 3:27PM
[ Reply | Permalink | Report ]

thesnark>"The RISC OS 4 kernel has been divested of much baggage that arguably doesn't belong in a kernel; e.g. the OS_Convert SWIs. This is something that I applaud. Does it not count as restructuring?"

Yes it is a form of restructuring and no it is not really that significant. OS_Convert SWI's may not logically have a place in the Kernel - but moving them elsewhere *does not* make the OS more portable. Having a hardware abstraction layer and the quite considerable changes made in RO5 *does* IMHO.

thesnark>"Dynamic areas are only unsuitable for the 32 bit memory map when there are no sensible limits set on the amount of address space claimed. "

My understanding was that if you use *any* DA's then you limited the available memory for all applications - if you *don't* use DA's then the available memory (for a 32bit app) is almost all the available free memory (which on an Iyonix is quite a bit more than 16MB)

thesnark>"It would be fallacious to suggest that the HAL in RISC OS 5 removes the need for device drivers to be written for new hardware"

No one said that! The point is having a Hardware Abstraction Layer is that it presents a coherent/consistent interface for driver and OS code. It doesn't mean *no drivers* it means easier to implement drivers with no required changes to the kernel - a thing Select lacks.

cmj said >"If RISC OS 5 is 'the better OS', as druck suggests, they why did STD pay RISCOS Ltd to convert Select to the A9"

Would it have to do with Castle being in competition with STD - but RISC OS Ltd., not being? Or is that a bit obvious

cmj said>"I know nothing about the Castle HAL, but I will point out that RISC OS 5 currently only runs on one platform. The Castle Iyonix."

And how many platforms does the 32bit version of Select run (sort of) on? Answer one - the A9.

Castle *do* have versions of RO5 running on embedded products (which another contributor has pointed out).

Md0u80c9 said>"Do you mean the HAL that was developed by breaching the GPL, and failing to acknowledge its original authors?"

The HAL is *not* part of the OS. But that having been said Castle *did* subsequently comply with the GPL by making the source code for the HAL available.

thegman said>"RO5 might be the 'better' OS from a technical point of view, to be honest, I really wouldn't know, but Select is a great deal more appealing from a 'give me the nicest version of RISC OS' point of view."

The only thing that matters *is* the technical point of view IMHO. After all having "round buttons" and alpha blends while *nice* is all a little pointless if you want to add a third HDD drive (and can't) or want to use more than 128MB of RAM or use USB 2. But hey it's your money and you have to make the choices that suit you.

Painting a mini RED like a Ferrari doesn't make it a Ferrari does it

JGZimmerle>"I don't believe that Ad6 would choose RO4.4x over RO5 for the features that are nice for desktop users. Their main business comes from customers in the embedded market. If RO5 would have such enormous technical advantages over RO4.4x as some people claim, that would have taken priority over the desktop features."

We can only surmise why Ad6 chose RO4 over 5. I would imagine that the decission was probably taken on practical and financial rather than technical considerations; I might suggest a few reasons (this is *just* speculation - but are considerably more likely reasons that the ones you cite):

1. ROL asked for less money? 2. Castle wouldn't sell the RO5 to Ad6 as they are direct compeditors in the embedded market (why give a compeditor your only advantage eh?) 3. Castle may have wanted to honour the original agreement made by Pace with ROL to allow ROL to develope RO4 for desktop use and may not have wanted to raise something that might raise "legal" issues. If Castle *had* sold RO5 *direct* to Ad6 that would have put them in direct competition with ROL in a desktop product that ROL might reasonably have expected to provide an OS for. 4. After the last legal problems perhaps Ad6 didn't want/couldn't to deal with Castle (or visa versa)

As to your other point - no. RO4 other than round buttons and alpha-blend sprites has not real technical advantages over RO5 (RO4's advantages are at the "Appearence" and "User Interface" level - not in any of the underlying areas that count IMHO). RO5 runs on more expandible, faster and more advanced hardware than anything RO4 runs on.

Yes I do like UI bells and whistles too - but it needs to be built on a sound modern OS too - doesn't it?

AMS on 08/01/06 3:39PM
[ Reply | Permalink | Report ]

Acknowledging but skipping over md0u80c9's valid point about the dubious processes which went on in the development of the RISC OS 5 HAL (I don't buy the excuse that the hardware abstraction layer just inits some stuff before the kernel takes over, since that sounds a lot more like a BIOS than an HAL, and one wonders what kind of "bare metal" the kernel works against if that's the case), it should be clear by now that the future of RISC OS as any modern desktop environment lies in virtualisation, emulation, or just plain substitution of the popular applications with functional equivalents on other platforms. One can buy decent enough hardware that runs Linux for less than all of the touted RISC OS machines, and if RISC OS and its applications weren't so lacking in developer interest, we'd be running the best bits on Linux by now anyway. Anyway, let the denial continue - it makes for some kind of entertainment, I suppose.

guestx on 08/01/06 4:05PM
[ Reply | Permalink | Report ]

In reply to ROHC, for me, the big feature is alpha-blending, my brother used to own an Iyonix, and we were both quite bemused by the lack of alpha-channel support in any vector package, except (I think) in Vantage, which is now of course, dead and gone. The other features mentioned above are nice too, and as I'm using a digital camera more often now, thumbnails in the filer would be cool too. Also, despite the lack of Select development at the moment, from a desktop user's point of view there is still more going on than on RISC OS 5, which to the best of my knowledge, has not had any updates of any note to UI/desktop stuff since it's release. The exception maybe the better USB mass storage support, which is very important.

In reply to GuestX, I think it's true to say you can get functional equivalents (or superiors) on many different platforms to RISC OS, but you still wouldn't get the desktop UI of RISC OS, which as far as I am concerned is pretty much the only reason to use RISC OS. Not that it's not a good reason of course. Let's face it, those of who use RISC OS rarely do it for hard headed business reasons.

thegman on 08/01/06 4:59PM
[ Reply | Permalink | Report ]

GuestX>To my knowledge Castle have complied with the GPL by releasing the source to the HAL, I certainly have not seen any further complaints on that front. To be sure it would have been better,IMHO, if they had either *not* used that code at all or failing that if they had published the HAL source at the outset. Mistakes like this sadly do happen.

Regarding using RISC OS apps on Linux (or Windows - seen that the most effective RISC OS emulator runs on Windows) surely the point is that RISC OS would simply become a "layer" fully dependant on another OS. How happy would you be running Linux under emulation on top of Windows Vista?

While I have nothing against Linux (I even have an old Red Hat setup on an old PC at home) my purpose is *not* to promote Linux but RISC OS (I figure Linux doesn't need the help - it has enough already

). I still consider the optimal option for RISC OS to be running on native hardware - anything else puts it at risk as it puts its future in the hands of others whose primary interests don't necessarily coincide with those of RISC OS users.

AMS on 08/01/06 5:05PM
[ Reply | Permalink | Report ]

A new thought... virtualisation is quite good nowadays: you can run one OS inside another with relatively little hassle or performance hit. I've thinking of things like VMware, QEmu, Xen etc. How about if VirtualAcorn came up with a basic Linux distribution that ran VRPCforLinux? They would ship a CD with a disc image of this on. Also shipped would be emulators/virtualisers for a number of target platforms (Linux/x86, Windows, Mac OS X/x86). So you could either install the basic Linux distribution resulting in a standalone VRPC machine, or install the virtualiser and emulate Linux emulating RISC OS. That sounds slow, but modern virtualisers have little speed impact if they're on the same CPU architecture, and forthcoming processors will have specific support for virtualisation. Any changes to the underlying OS/libraries/etc just require an updated virtualiser which might even be part of the OS distribution (eg QEmu comes as a Debian package).

The problems I can forsee are graphics card and host access, but those aren't insurmountable.

caliston2 on 08/01/06 5:44PM
[ Reply | Permalink | Report ]

"Virualisation....relatively little...performance hit": not according to the tests run by T.O.M.S. in the latest Archive, where the performance of various David Pilling ports of RO apps to Windows (Trace, DPScan, OvationPro) was compared to the RO apps running under emulation. The ported apps running natively under Windows were 5-7x faster than under RO emulation! Now it may well be that further development of VRPC will improve this ratio, but clearly ATM there is a considerable overhead when running on top of Windows. To put it another way, a RO app will run under emulation on a 3Ghz+ x86 processor at roughly the same speed as on an Iyonix with its 0.6Ghz ARM processor.

As to where we go from here, I suspect that emulation and x86 improvements (including dual-core and 64-bit chips) will outstrip the speed improvements in suitable ARM chips. I'd love to be proved wrong, and I'd love to see Iyonix 2 with a 1Ghz+ ARM chip, full graphics card acceleration and modernised filing system to replace the Iyo on which I'm typing this.

bucksboy on 09/01/06 10:03AM
[ Reply | Permalink | Report ]

That's emulation, not virtualisation. The difference is that virtualisation runs code on the processor it was designed for, so for example you might have an x86 PC running Linux, on which there was an x86 virtual machine running Windows inside. If you're just running straight user-land code (Firefox, say) it runs directly on the x86 processor as if the code were part of Linux. The only performance hit is that when the code tries to hit make operating system calls the calls get diverted to the virtualised Windows machine rather than the underlying Linux machine.

[link](virtual_machine_monitor) has a better (technical) outline of how one system works.

Another idea for VRPC on Linux... make the Windows version WINE friendly. (WINE is a program for Linux that runs Windows programs by emulating the full Windows API). If it only used Windows calls that were supported by WINE then it should run on Linux under WINE without any problems. And the same code would run quite happily on Windows by definition.

caliston2 on 09/01/06 10:53AM
[ Reply | Permalink | Report ]

Theo, thanks for the correction (memo to self: always read the question!).

bucksboy on 09/01/06 11:15AM
[ Reply | Permalink | Report ]

Theo>But surely it's x86 processors doing the virtualisation, therefore all you'd be doing is *still* running a RISC OS emulation - on a virtual x86 processor dedicated to running Windows while a different x86 runs Linux?

AMS on 09/01/06 6:14PM
[ Reply | Permalink | Report ]

further to that> Time for me to take my foot out of my mouth. The article on [link] gives details of a device that sports an Intel xScale processor and a VIA (x86 compatible) processor - it can run WinCE (as in PDA's) and XP. The xScale is a lowly 400MHz model (but hey no worse than what the A9Home's). Now if the xScale side could be persuaded to run RISC OS eh ?

AMS on 09/01/06 6:19PM
[ Reply | Permalink | Report ]

Should have read that more carefully it runs two separate processors ;(

AMS on 09/01/06 6:21PM
[ Reply | Permalink | Report ]

Indeed, VRPC will always be an ARM emulator. But the point I'm getting at is that VA don't want to release a Linux version of VRPC because of the support headaches. So I was thinking of ways VRPC could run on Linux by putting in another layer between it and the host OS. This means either tricking VRPC into thinking it's running on Windows (the WINE route), or coming up with a Linux version of VRPC which runs on one fixed OS installation on one fixed hardware platform (that 'emulated' by the virtualiser). Any support headaches are therefore transferred to the virtualiser, which has a much larger user base. And if the virtualiser is multi-platform, it'll run on other OSs (eg Mac OS X/x86) so VA only need release one version of VRPC.

(I suspect the WINE route is probably much less work)

caliston2 on 10/01/06 12:43AM
[ Reply | Permalink | Report ]

With respect to the amount of work required, I'd argue that a bit of effort on the Linux build system is a lot less effort than developing some virtualisation technology or hacking up some WINE-based solution. If VA really didn't want to dirty their hands, I'm sure there's someone out there with the experience who'd do the job for a reasonable rate.

guestx on 11/01/06 01:11AM
[ Reply | Permalink | Report ]

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

Search the archives

Today's featured article

Cross platform development
Building RISC OS Programs on Windows

47 comments, latest by EasyKees on 07/10/04 8:05PM. Published: 24 Sep 2004

Random article

Wakefield 2001: drobe.co.uk talks to sponsor R-Comp Interactive

Discuss this. Published: 4 Apr 2001

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign

© 1999-2009 The Drobe Team. Some rights reserved, click here for more information
Powered by MiniDrobeCMS, based on J4U | Statistics
"Unless and until you are willing to produce the evidence to back up your assertions, please cease and desist making these allegations"
Page generated in 0.5438 seconds.