Best of 2006 awards results | Drobe.co.uk archives

Best of 2006 awards results

Published: 31st Dec 2006, 12:23:30 | Permalink | Printable

Here's to 2007

As 2006 finally draws to a close, it's time to reveal who was hot and who was not in the RISC OS world this year. The Best of 2006 results are in, and here are the winners and runners-up chosen by drobe.co.uk readers.

Every developer, bug hunter, article writer, mailing list poster, and user who found a way to contribute to their favourite software and platform, is worth their weight in gold. The results shine a spotlight on people who communicate well with their fellow users, and blow a raspberry at those who think silence is golden. The voting also showed how important the Internet is to RISC OS users, and how open source software is vital for the progression of the platform. And without further ado:

The winners
The best commercial product of 2006, according to drobe readers, is the AdvantageSix A9home. Officially released in time for the Wakefield show in May, this diminutive RISC OS 4-powered computer uses a 400MHz system-on-a-chip Samsung ARM9 processor and a Silicon Motion SM501 graphics chip in an attempt to offer an affordable RISC OS desktop machine. In a close second place comes R-Comp's email and Usenet client Messenger Pro, which gained numerous features this year including HTML email support.

In the best non-commercial software category, in first place is the run away success story NetSurf. The open source application continues to be developed by an informal team of young programmers who are gradually working towards a version 1.0 milestone. In second place is Peter Naulls's RISC OS port of Firefox, which saw version 2 released later this year.

The best RISC OS event of 2006 goes to the Wakefield show, as organised by the WROCC. Close behind in second place was SASAUG's South East show in Guildford.

Although they've yet to release any source code or decide upon a licence, RISC OS Open impressed enough readers to win the best ingenious project category. The organisation, with the help of Castle, are hoping to reveal the blueprints of RISC OS 5 so everyone can get stuck into improving the operating system. ROS Open's Steve Revill and Castle's Jack Lillingston are set to present their efforts so far to punters in London in January. In second place, is Martin Wuerthner and John Tytgat's plans to develop a PostScript 3 printer driver.

The prize of top own goal of 2006 goes to Qercus editor John Cartmell and his AWOL magazine. The 'monthly' publication appears to be on the straight and narrow again, with three issues in the post since October, although the new 6-week publishing cycle isn't exactly what the 'thousands' of subscribers paid their 50 quid a year for. In second place is Peter "never explain, never apologise" Naulls, mainly for his initially Iyonix-only Firefox that used ARMv5 specific instructions to shave thousandths of a second off web page rendering.

And finally, in the category of best overall contribution to the platform in 2006, the winner has worked on several commercial and non-commercial software packages, from graphic design to printing to word processors. First place this year goes to Martin Wuerthner. Second place goes to the NetSurf development team for their work and spin-offs from the browser project.

Thanks to readers who voted, congratulations to the winners, and a pat on the back to everyone to contributed to the platform in 2006 - have a happy new year.

Links

Back to the front page

Previous: Acorn professor awarded CBE
Next: AmigaOS woes show ROS is not alone

Discussion

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

Woo! NetSurf wins! At least! Congratulations to the winners, and condolences to the not-quite-winners. It'd be interesting to see by what margins everyone one/lost - ie, how many votes are there between JC's and The Chox's home goal prize?

rjek on 31/12/06 2:38PM
[ Reply | Permalink | Report ]

A big thankyou to all RISC OS developers, 2006 has (all in all) been a good year for our favourite platform. Let's hope 2007's even better.... Iyonix 2 anyone?

leeshep on 31/12/06 3:53PM
[ Reply | Permalink | Report ]

Remind me again why an Iyonix-only port is an own-goal? Much as I'd like to see a (cut-down?) RPC version, if that's not possible then surely there are too few A9's to have made a port worthwhile for any initial releases of v2?

AW on 31/12/06 4:41PM
[ Reply | Permalink | Report ]

I would have to agree wrt Firefox it's unreasonable to expect modern (hungry) applications to work on 10 year old hardware. Be thankful for what Chox has done with Firefox and the underlying libraries.

tweety on 31/12/06 4:54PM
[ Reply | Permalink | Report ]

AW: The Chox's FF2 port was made Iyonix-only for non-technical reasons. Read into that what you will.

rjek on 31/12/06 4:58PM
[ Reply | Permalink | Report ]

I am thankful whether I can use it or not but I don't think it's unreasonable in theory in this case as it happens.

The article implies that he made the port Iyonix only *for* technical reasons. I would agree that non-technical reasons namely more Iyonixes about (presumably) would make more sense but an own-goal? :S

AW on 31/12/06 5:21PM
[ Reply | Permalink | Report ]

Well done to all the winners and runner ups.

As to all the debate about FF2, then all I can say is well done to Peter for getting out the door in a very usable form and delivering on what he promised. The A9 issue is also now a non issue as it runs on that platform as well. I could see both sides of the arguement and as Peter had a Iyonix then perhaps that is why the initail release was aimed at an area he could check out bug reports on first.

As to RISCPC ports then isn't it time that we started to let the old machine go. Yes, they are still usable and RISCOS Adjust/6 is a good addition but modern hardware enables more things to be done and should be supported if the market is to survive.

Iyonix 2 would be great and i can't believe that my Iyonix will be 5 years old soon.

bluenose on 31/12/06 5:33PM
[ Reply | Permalink | Report ]

AW: There was zero reason for The Chox to make his initial FF2 port Iyonix-only from a technical point of view. Infact, it was *more* work for him (if only marginally) to make it Iyonix-only. He clearly wanted, for his own reasons, to stop Omega and A9Home users using his FF2 port. It has nothing to do with there being "more" Iyonixes. Given his absolute refusal to explain himself, we are left only able to assume he did this out of spite. Given that I then managed to get it running on the A9Home, easily as fast as it appeared to run on the Iyonix, without his assistance and emulating the Iyonix's CPU to an extent, it seems very much like an own-goal - we just don't know what he was trying to achieve - only that it was stopped.

rjek on 31/12/06 5:35PM
[ Reply | Permalink | Report ]

Has Peter given any official comment on the issue? Peter would be the person to ask but I would have thought that he wouldn't have manually added any A9Home unfriendly instructions by hand. I presume that he simply built it with the correct set of options and optimizations for his Iyonix.

Peter has done a lot for the platform this year and it's a shame that he has come top of one of the negative poll categories.

killermike on 31/12/06 6:09PM
[ Reply | Permalink | Report ]

In reply to rjek: As you say, we don't know Peter's reasons. However, I think spite is unlikely. Isn't it more likely that, since we know he was in pursuit of better performance, he just used all the optimisation switches? This would be a reasonable approach from someone intending to come back to fine tuning later (which is consistent with the latest release being A9 compatible, AIUI).

TonyStill on 31/12/06 7:11PM
[ Reply | Permalink | Report ]

TonyStill: The Chox highly advocates actually testing to see if things are faster or not - or at least he certainly does when somebody else tries to demonstrate something. As I had previously said, making GCC emit XScale-only instructions a) is more effort, and b) saves less than a thousandth of a second on the Iyonix. Premature optimisating is very very bad, and The Chox knows this. The more heavily you optimise, the more difficult it is to track down bugs.

rjek on 31/12/06 7:35PM
[ Reply | Permalink | Report ]

rjek>Not having the innate talent to read Peter Naulls' mind I am at somewhat a disadvatage in knowing why the initial release was XScale only. It isn't just the case of XScale only instruction optimisations being taken into account (remember GCC wasn't written specifically to compile FF2) therefore the exact effect of compiling for it might not have been known when Peter iniitially did it. Also instruction *scheduling* may have a part to play (having a longer pipeline it's important to cater for this on XScale, Peter may well have chosen to optimise for the best/fastest native ARM solution, not unreasonable I would have thought).

Now he's catered for A9 users too - so what's the problem - please give the guy *credit* he's done lots of useful work for RISC OS.

AMS on 31/12/06 8:37PM
[ Reply | Permalink | Report ]

AMS: You demonstrate your lack of talent in this respect with your suggestions. Simply reordering/tuning/scheduling instructions to optimise for XScale does not render the code unable to execute on other CPUs. The only thing that does (and is what The Chox did) is to specifically ask the compiler to use instructions that only the XScale has. Why go to extra effort to make it more likely that bugs will occur at the same time as making it more difficult to debug, and limiting the number of users who can test it? Peter knows better than this, and also knows that there was no good technical reason to do so. So we're still left guessing as to why he chose to do it.

rjek on 1/1/07 1:47AM
[ Reply | Permalink | Report ]

rjek wrote>"Simply reordering/tuning/scheduling instructions to optimise for XScale does not render the code unable to execute on other CPUs."

Never said that it did, but the reordering does improve performance more for XScale, I would assume that GCC would optimise by (1). Using XScale only instructions where possible *and* (2). Reorder instructions for best performance on XScale. Therefore there could be merit for initially compiling in this way (it would give *more* performance improvement than simply using XScale only instructions alone).

Besides he's now addressed the issue so why continue complaining about it?

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

I whisper advice in the ear of Chris, who must be as distressed as I am at some of the comments made: Confucius he say "stir the tea with your finger and scum rises to the surface". Your motto for 2007 should be "honi soit qui mal y pense".

GavinWraith on 1/1/07 12:13PM
[ Reply | Permalink | Report ]

In reply to rjek: I believe we are talking here of an optimisation achieved by giving the compiler licence to use a wider set of instructions (ie including those found only on the XScale). Such an optimisation is quite different to one achieved by changes to the program logic.

Optimisation through logic or algorithm changes can indeed be unwise if done early in the development cycle. I can see no reason why using the compiler's optimisations is a problem for any release though and I think that's what Peter did. I stand by my statement that using all the speed related optimisations is a reasonable approach; indeed, the A9 incompatibility did bring a performance improvement, albeit a tiny one.

My speculation (and I'm no better informed than anyone else here) is that the gain from that particular optimisation was disappointing; the trade-off between improved performance and improved compatibility then became obvious, leading to the A9 compatible release that quickly followed. I could be completely wrong, of course, but I still think rational reasons are more likely than spite from Peter.

TonyStill on 1/1/07 12:23PM
[ Reply | Permalink | Report ]

Sad that we don't have anything more important to talk about than Peter's motivation in porting Firefox 2 :-(

NeilWB on 1/1/07 1:26PM
[ Reply | Permalink | Report ]

Firefox 2 - Great! Very, very stable and faster than 1.5. Brilliant stuff. I think that's important!

DaveW on 1/1/07 2:13PM
[ Reply | Permalink | Report ]

AMS: Yes, tuning for XScale may have given a tiny advantage, possibly more than using XScale-specific instructions. The reason he was nominated for own goal is that he will have known full well that a) using XScale instructions would have made a trivial and unnoticable difference, b) that this would stop it working on other machines, c) somebody got it to work anyway, without his help. Seems completely reasonable to me.

TonyStill: The more features of the compiler you use, the more difficult it is to discover if the bug is in your code, or in the compiler's. Which is why most software is developed with -O0 and only built with more optimisations later. Using certain optimisations and compiler features can also make it impossible to debug the software.

rjek on 1/1/07 2:32PM
[ Reply | Permalink | Report ]

Of course it is. I simply can't believe that spite was the reason that the first release only worked on the Iyonix. In any event, the second release (released on time I should add) works on the A9home as well and future versions (if there are any) will probably do so as well. I really can't see what the fuss is about. Can't people look to the future? Cheers!

fwibbler on 1/1/07 2:36PM
[ Reply | Permalink | Report ]

I don't think producing an Iyonix only version was an own goal, but initially not saying why, which lead to speculation, could qualify.

Am I right in thinking that if the latest version were compiled to support Risc PCs, there would be a speed penalty on the currently supported machines?

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

jess: A marginal, but possibly noticable one, yes - half-word (16 bit) loads and stores from memory are frequently of use in things like image decoders and such, and these are the instructions that do not work on RiscPC-class machines. (Less to do with the CPU, and more to do with the IOMD chipset on the motherboard.) StrongARMs can do them if the data is already in the cache, and Kinetics can do them if the data's on the on-board fast RAM.

In any case, Peter's refusal to say why he had decided to make it Iyonix-only in the first instance, when there is demonstratably no technical reason is the own-goal - and the nominations and the vast majority of the voting occured before he did release an A9 Home version. And we don't yet know if the only reason he made his second reason A9 Home-friendly is because we'd got his old one working anyway. He's been completely silent on the matter.

rjek on 1/1/07 3:49PM
[ Reply | Permalink | Report ]

rjek: So with suitable memory management, the existing firefox 2, might be able to be made to work on a Kinetic? (Perhaps if you get bored one evening

)

It would have been best if the reasons were stated with the release. However, once you proved there was trivial advantage, there would have been little point making an update just for A9 compatibility, since you provided a path to use that version, and it appears the next version is a significant step.

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

I don't know what all the fuss is about. Peter is at liberty to release the program how he wants. He has no obligation to justify any of his decisions to anyone. If other people don't like what he's done all they have to do is compile it themselves - simple really

coling on 1/1/07 6:54PM
[ Reply | Permalink | Report ]

Peter has said why he did it to a number of people. Its so he can get on with the port without the constant whining of users of 13 year old machines complaining that code aimed primarily at muli-GHz x86 PCs doesn,t work fast enough on thier 200MHz StrongARMs. Frankly given the perpetual moaning on csa, I fully endorse this position.

Both GCC and Norcroft can produce code optimised for XScale scheduling but not using XScale specific instructions, or 16bit load and stores if required. When Peter has finished the port all the source will be made available under the GPL and people will be able to compile it for whatever they want, and then the pointless bleating can start all over again.

druck on 1/1/07 7:27PM
[ Reply | Permalink | Report ]

That would explain the current situation and is quite fair.

However, the previous version did not support the A9 which is new *and* produced by sponsors of the project.

At the time, not supporting it without explaination seemed odd and must have caused concern to any purchaser of an A9.

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

I'm not whining - just a suggestion to involve more users.

Talking in terms of "13 years old" and "time to move on" is disingenuous and inappropriate, frankly.

For a start the SA is about 10 years old, RISC OS 4+ less, and more importantly authors /know/ that in terms of compatibility they have to go the extra distance and then some more with RISC OS. Even with special offers of £500 for an Iyonix (not including monitor) it's too expensive to justify for many people. Most people would just get a laptop I imagine.

Furthermore, Castle started manufacturing RiscPC's as the last Acorn computers in 1999, just over 7 years ago and selling them in the region (inc. monitor) for £1000 so please give it a rest with "13 years" at least for the moment.

And as for RComp selling RISCBooks for aroud £900 or more, >70% of the British population must think they're living in cloud cuckoo land!

AW on 1/1/07 8:37PM
[ Reply | Permalink | Report ]

None of that changes that fact that the machine is a 13 year old design, with a I/O and memory speeds which stuck at the speed they were 13 years ago. The StrongARM gave a massive speed boost for the typical small RISC OS C or BASIC program, but is massively compromised by the slow memory and I/O when running applications like Firefox.

Both the Iyonix and A9 have massively faster memory and I/O, and significantly more processor power and only just run such a large and complex application at a reasonable speed, so older machines don't stand a chance, and no amount of wishing or whining is going to change that.

druck on 1/1/07 9:10PM
[ Reply | Permalink | Report ]

Well in the best spirit of Acorn/ RISC OS I say never say never to anything. I/O was "changed" by Kinetic. Firefox in theory can be changed (e.g. cut down in some respect or elements utilised elsewhere) as well.

AW on 1/1/07 10:45PM
[ Reply | Permalink | Report ]

Strictly speaking, Peter has to already provide his patched sources to other people. coling: Nobody's suggesting otherwise.

Firefox is a slow piece of software. Even on fast PC's, it's a little unresponsive. Frankly, I'm surprised anybody thinks it's usable on an Iyonix, but it'd be simply too much pain to run it on a RiscPC.

AW: No, only one small problem with the RiscPC architecture was solved by the Kinetic - all the others remained.

rjek on 2/1/07 12:40AM
[ Reply | Permalink | Report ]

jerk -

I mean the memory speed.

AW on 02/01/07 01:00AM
[ Reply | Permalink | Report ]

AW: I'm sure you do. But the RiscPC is still a hopelessly bad architecture in terms of speed of access to hardware etc, even if the Kinetic does provide marginally faster memory. It also has small caches. I don't understand how people can cope running Firefox on an Iyonix - it's unusably slow. Running it on a RiscPC would just be insane. It's not as if replacements for the RiscPC with a far superior architecture havn't been available for a while, now.

rjek on 02/01/07 12:57AM
[ Reply | Permalink | Report ]

Firefox is quite usable on an iyonix. On a risc pc it is too slow for general use, but having it available as an option would be useful for those odd occasions.

I can quite see that not having it available on slow machines while it is being developed is very desirable.

druck: My Risc PC is only twice as old as my Iyonix and not much older than the oldest Iyonixes, if I had bought it new, I doubt I would have purchased an Iyonix. I suspect there are quite a few people with RPCs that are relatively new who can't justify an Iyonix.

(And I do know that some of the I/O is on a par with a 286 PC)

jess on 02/01/07 1:50PM
[ Reply | Permalink | Report ]

I have not used Firefox much on my IYONIX, but at first glance, its perceived "slowness" does not come from the processing requirements of modern HTML/CSS/JavaScript parsing/layouting/executing stuff. In fact, I think that this part would be fast enough on a StrongARM Risc PC.

However, the user interface part is - probably because of the way ChoX11 works (or better: has to work) - non-responsive. As we all know, non-responsiveness of the user interface is perceived as "slowness". Plain drawing speed on the screen is not too bad and certainly not the problem.

So overall I would suspect that the parsing/layouting/drawing part would run OK-ish on a StrongARM Risc PC - after all, there are people who used Webster XL on an ARM610. But without optimizations in the user interface part (e.g. keyboard entry, scrollbar handling, dialogue operation, font rendering), there is really no point in providing a Risc PC port.

I guess Peter's first priority is ensuring correct operation above fast operation of ChoX11, and I agree with this priority. It remains to be seen how much optimization can be done on the ChoX11 layer - I am not really qualified to comment on this.

hubersn on 02/01/07 3:26PM
[ Reply | Permalink | Report ]

As Seffen says most of the perceived slowness of Firefox is down to the lack of responsiveness of the UI layers rather than the speed of the parsing and rendering engine. I've been using FF on a UMPC which runs 300MHz on batteries (1GHz on mains), and the browser itself perfectly usable on that. What is dog slow are operations such as opening new windows, which is down to the bloated an inefficient OS on the device (XP). We've got a lean and fast OS but unfortunately Firefox makes very little use of it, having draw and handle all of its own controls via the necessarily complex ChoX compatibility libraries. Peter has said there is scope for improvement in this area, both in terms of RISC OS look and feel, and performance, which is hopefully will hopefully come from his ongoing work.

druck on 02/01/07 7:04PM
[ Reply | Permalink | Report ]

rjek -

Why do you have to be so negative about things? It would seem you are a capable talented programmer. That means you have the creative capacity to really make things happen with RISC OS. Great asset. Something to be positive about.

AW on 02/01/07 7:43PM
[ Reply | Permalink | Report ]

In my experience FF on the Iyonix compensates for its apparent lack of responsiveness by efficiency in other areas - cached pages are retrieved very quickly, for example, and the comprehensive history enables previously accessed pages to be easily retrieved. In these respects FF is much /more/ responsive than nominally faster browser like the Oreganos. Besides, the latest RO version is significantly more responsive than the earlier ones. Finally, knowing that your browser isn't going to throw a terminal wobbly after minutes of painstaking data entry into successive https screens is a comfort!

bucksboy on 02/01/07 9:06PM
[ Reply | Permalink | Report ]

FF 1.5 was responsive enough as far as web page rendering, but the UI was far too slow, the answer still is the same as for all software....get a new machine :@)#

congrats to all those whom won!

em2ac on 03/01/07 12:59AM
[ Reply | Permalink | Report ]

The first version was odd - it was treacle-like in UI responsiveness on the RiscPC, but 'm sure the display seemed quicker than the Iyonix (e.g. when scrolling a page). Still, it's coming on and still improving. So is Netsurf; Oregano doesn't get much use from me now, although I do most of my browsing on non-RISC OS machines.

SimonC on 03/01/07 3:56PM
[ Reply | Permalink | Report ]

I think Peter should be congratulated on his work - having a well known application such as Firefox on the platform is a major plus and demonstrates, IMHO, that Risc OS isnt some old, dead and buried OS from school years ago - if people get to know that Firefox works on Risc OS then hopefully it should make them realise that its alive and kicking

polas on 03/01/07 4:03PM
[ Reply | Permalink | Report ]

In reply to Nick Brown:

Alive yes, but hardling kicking. I'd say treading water is all it's doing at the moment.

sa110 on 03/01/07 5:02PM
[ Reply | Permalink | Report ]

Well, if the enthusiasts aren't possitive then who will be?

polas on 03/01/07 5:11PM
[ Reply | Permalink | Report ]

polas:

[link]!

& spot how many of them have Firefox - including us :-D

OK I'm the only RISC OS user to have posted but I agree - those of other OSs realise that we have firefox their ears & eyes perk up ;-)

ROHC on 03/01/07 7:04PM
[ 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

The new apple of my eye
Would you swap your dusty Acorn for a polished Apple computer? Martin Hansen has been checking out the world of Steve Jobs and his range of shiny kit.

15 comments, latest by adh1003 on 6/1/09 1:06PM. Published: 17 Nov 2008

Random article

RiscCAD returns to author
Welcome back

6 comments, latest by john on 4/11/04 12:36PM. Published: 3 Nov 2004

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
"Contrary to some RISC OS news sites who don't bother to check the facts before they run a story..."
Page generated in 0.0873 seconds.