Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Webspace | Tech docs | Downloads | BBC Micro

Profile for gdshaw

ContactAbout me
Email:
Private
ICQ:
AOL:
Yahoo:
Username: gdshaw
Realname: Graham Shaw
About me:Author of: The RISC OS Toolkit (a C++ application framework); RiscPkg (a package manager for RISC OS).
Homepage: http://www.sagitta.demon.co.uk/riscos/
Face/Logo:
Comments posted:73 (show all)
Articles written:1 (show all)

All comments

On Wakefield 2008 show photos:

In reply to Druck: Perhaps it's just as well he didn't spot the 'Buffy the Vampire Slayer' mousemat :-)

 is a RISC OS Usergdshaw on 30/4/08 10:37AM
[ Reply | Permalink | Report ]

On RISC OS development charity taking shape:

In reply to rpc4ever:

And yet you are (presumably) willing to give money to private corporations - and through them, their shareholders. How odd.

 is a RISC OS Usergdshaw on 26/6/07 8:25PM
[ Reply | Permalink | Report ]

On Castle reveal shared source licence:

One further point that occurs to me: I am very pleased to see that the term 'Shared Source' is being used now rather than 'Open Source'. Whether previous comments in this forum have had any influence here I do not know, but if they have, thank you for listening.

 is a RISC OS Usergdshaw on 19/5/07 6:08AM
[ Reply | Permalink | Report ]

On Castle reveal shared source licence:

I have mixed feelings about this.

On the one hand, installing a complete disc image using a package manager has just become a realistic proposition. This had always been one of my objectives - you can just about boot a system using my half-finished !Boot and !System applications - and whatever you think about the licence, it is something we can live with in this context.

There will also be benefits to developments such as my threading module - it is much easier to fix bugs if you can see what you are trying to interact with.

OTOH, this makes it rather less likely that we will ever have a usable version of RISC OS under a real Open Source licence, or which targets other processors.

(I've been preparing another small contribution to the above - it's a free implementation of the filer module and is in the RiscPkg source repository.)

On balance though, a welcome development and one that will benefit my work significantly.

 is a RISC OS Usergdshaw on 19/5/07 5:53AM
[ Reply | Permalink | Report ]

On App development plans to be hatched at Wakefield:

In reply to Stoppers:

Being a customer in a small market is inevitibly a very different experience from what you would normally come to expect as a consumer. In particular, there is a much greater degree of inter-dependence. If suppliers want to sell then they need to respect and care about the customer - but if customers want to retain the ability to buy then they must care about the supplier.

If we try to avoid this reality then I think the market will simply disappear. On the other hand, it is clear that some users - rightly or wrongly (and probably a bit of both) - feel exploited by the current situation.

Where I think we can and should change is to improve transparency and accountability, because it is the lack of these which causes much of the current frustration that we see. This is one of the key points that my proposal is intended to address.

 is a RISC OS Usergdshaw on 29/04/07 2:41PM
[ Reply | Permalink | Report ]

On App development plans to be hatched at Wakefield:

In reply to arawnsley:

I would not want my proposal to be seen to be anti-commercial in any way.  On the contrary, I hope I've made it very clear that I'm in favour of cooperation between commercial and non-commercial developers.

Where I make no apology is for focussing on one particular part of the equation in a way that hasn't been tried before (within the RISC OS community).

If some form of complementary initiative could be taken in on the commercial side then I think that would be fantastic. What I don't have is any particular vision as to how this could be brought about, whereas for Open Source I do.

 is a RISC OS Usergdshaw on 29/4/07 2:00PM
[ Reply | Permalink | Report ]

On App development plans to be hatched at Wakefield:

In response to some of the feedback I've received I've added some information to the proposal about how a charitable organisation could become involved in non-charitable activities if necessary. (I don't think this is would in any case be a major limitation in practice - for example, both of the browsers currently under active development are already Open Source, and if Java isn't already then it will be soon. There would be plenty for the organisation to do without stepping outside these bounds, but it may be of some reassurance to know that it could do so if needed.

 is a RISC OS Usergdshaw on 29/4/07 9:23AM
[ Reply | Permalink | Report ]

On App development plans to be hatched at Wakefield:

In reply to druck:

I'd agree with this wholeheartedly. In particular, we (meaning all of us) need to learn how to have technical arguments without it becoming personal.

Would this be a good opportunity to draw a line under old differences? I don't expect us to magically agree on the right way forward, nor would that necessarily be healthy, but we can at least start to be nice about it.

(Taking this a step further, I'd be interested to hear what others think about the codes of conduct which are used in communities like Groklaw and Ubuntu. Not something you can enforce in the newsgroups, obviously, but may be of some benefit elsewhere.)

 is a RISC OS Usergdshaw on 28/4/07 8:47PM
[ Reply | Permalink | Report ]

On App development plans to be hatched at Wakefield:

In reply to Druck:

There are no doubt many RISC OS programmers with similar views to your own - I never imagined otherwise. The questions I am looking to answer are: - whether there are programmers for whom either a nominal or a substanial reward would make a difference, and - whether there are tasks which need doing which would not otherwise be done because they are not sufficiently interesting to those who program purely for intellectual enjoyment.

(I'm obviously hoping that the answer to these questions is 'yes', but I can't prove it yet and it is very useful to hear what people think. I also take Druck's point that we need to be careful not to demotivate existing programmers. That's one reason why it would be essential for the organisation to be democratic and transparent.)

 is a RISC OS Usergdshaw on 28/4/07 8:27PM
[ Reply | Permalink | Report ]

On App development plans to be hatched at Wakefield:

In reply to markee174:

I've used the word 'bounty' rather than 'prize', but the concept is very similar in principle to what you've described.

Where there might be a difference is size. I don't think offering a single, large bounty to (for example) add full Javascript support to Netsurf would work very well because it would take too long. The tasks need to be small and manageable, and achieving that is probably the single greatest challenge.

 is a RISC OS Usergdshaw on 28/4/07 5:38PM
[ Reply | Permalink | Report ]

On App development plans to be hatched at Wakefield:

In reply to markee174:

That's already covered (buying out closed-source software) - see the last paragraph of the 'incentives' section.

You're right that the focus here should be on software which is no longer being sold - partly because it will be more affordable in that state, and partly to reduce the risk of displacing commercial development.

 is a RISC OS Usergdshaw on 28/4/07 2:32PM
[ Reply | Permalink | Report ]

On App development plans to be hatched at Wakefield:

In reply to killermike:

The proposed organisation doesn't have a name as yet, although there are a number of ideas on the table from those who have helped me to develop the idea.

('Foundation' is already taken, although I'm not convinced that it should have been - my understanding is that it is normally reserved for use by charities and similar bodies, which ROL isn't.)

Anyhow, for now I'm using the word 'charity' because it has a specific legal meaning, and because it conveys better than any other word how the concept differs from any other RISC OS-oriented organisation that has existed before.

 is a RISC OS Usergdshaw on 28/4/07 8:03AM
[ Reply | Permalink | Report ]

On Oregano 3 scrapped:

As promised, I've uploaded an outline of my ideas to:

[link]

I don't know how well this matches up to what others have in mind, but I do think that having specific proposals on the table will help to focus any future discussion.

Comments?

 is a RISC OS Usergdshaw on 27/04/07 8:00PM
[ Reply | Permalink | Report ]

On Oregano 3 scrapped:

One more point, for clarity: I'm not looking to make any money out of this idea personally (and those responsible for running it would almost certainly not be allowed to).

 is a RISC OS Usergdshaw on 25/04/07 8:10PM
[ Reply | Permalink | Report ]

On Oregano 3 scrapped:

I'm here. Thanks to those who e-mailed.

Yes, this is an idea I've been gradually developing for some time. The basic concepts are that: - tax relief is a very good incentive for people to donate money, and - money is at least a moderately good incentive for fixing the things that nobody wants to do (and generally 'oiling the wheels'). The obvious example of where bounties have met with some success is Ubuntu. Unfortunately I'm not in a position to personally bankroll the venture, but I suspect there are enough who would be willing to contribute if the organisation was sufficiently democratic, transparent and accountable. No it won't solve everything, but it might achieve something. I have written some more specific proposals. They're not quite fit for publication yet, but now that the topic has been brought to the fore I will ensure that they are very soon.

 is a RISC OS Usergdshaw on 25/04/07 7:50PM
[ Reply | Permalink | Report ]

On RiscPkg author publishes new coding book:

In reply to GavinWraith:

The best way to buy a copy would be to go to the RISC OS South West show yesterday. (I didn't want to announce anything until I was sure I could deliver, and unfortunately that point was not reached until rather close to the show.)

Failing that I hope to be at Wakefield, or can offer it mail order. I've just put up a web page with more details ([link])

 is a RISC OS Usergdshaw on 25/2/07 10:56PM
[ Reply | Permalink | Report ]

On First release of unofficial open source SharedCLibrary:

In reply to druck:

I agree completely, but I hope you'll understand that I want to focus on correctness rather than performance in the first instance.

(As I mentioned in csa.apps some of the current functions are naive in the extreme, but they have the virtue of being much less likely to go wrong than highly optimised versions.)

 is a RISC OS Usergdshaw on 22/12/06 9:55AM
[ Reply | Permalink | Report ]

On First release of unofficial open source SharedCLibrary:

In reply to TonyStill:

I don't see why having separate implementations is such a problem provided that they work to the same API. If you find a difference of behaviour then it is either a bug in your program or a bug in the library, and in either case the sooner it is eliminated the better.

I aim to match any implementation-defined behaviour of the existing SCL implementation, and programs should not rely on unspecified or undefined behaviour in the first place. I've also made it very clear that in its experimental phase, the SCL should be considered the prime suspect for any problems that occur and they should not be reported to other developers.

 is a RISC OS Usergdshaw on 22/12/06 8:46AM
[ Reply | Permalink | Report ]

On A9home first impressions review:

In reply to Pete and RickCB:

Sorry, but how exactly can one have "too many computers"? :-)

 is a RISC OS Usergdshaw on 7/11/06 12:03AM
[ Reply | Permalink | Report ]

On NetSurf users hit by HSBC account freeze:

In reply to hzn:

Privoxy can be used to change the user agent string. AFAIK it hasn't been ported to RISC OS yet, but it definitely works with Netsurf if you run it on another machine. I would expect that porting would be fairly straightforward.

 is a RISC OS Usergdshaw on 23/10/06 8:38AM
[ Reply | Permalink | Report ]

On South East 2006 show report:

A clarification before anyone becomes over-exited: I have written, and will shortly be releasing for public review, a proposal for some extensions to the Simtec threads module. I've also done enough proof-of-concept work to be convinced that I can implement them without too much difficulty, but they (along with the Free Shared C Library - which is almost ready for a preliminary release) are just two parts of a larger plan that will take quite some time to implement.

 is a RISC OS Usergdshaw on 21/10/06 11:08PM
[ Reply | Permalink | Report ]

On RISC OS Open needs your help:

In reply to JWoody:

Would it help at all if a machine were available on the net that you could log into and use GCCSDK?

(It would have to be command line only, but all of the tools could be pre-installed and ready to use.)

 is a RISC OS Usergdshaw on 08/10/06 08:52AM
[ Reply | Permalink | Report ]

On Intel wheels out 1.2GHz XScale family:

In reply to JGZimmerle:

Having 8 lanes available does not exclude all PCIe graphics cards. Some require 16 lanes, but others are available which use only 1. Not ideal, I'm sure, but not a showstopper either.

 is a RISC OS Usergdshaw on 28/9/06 6:24AM
[ Reply | Permalink | Report ]

On Castle considering open sourcing RISC OS:

In reply to Jess Hampshire:

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

 is a RISC OS Usergdshaw on 03/09/06 08:53AM
[ Reply | Permalink | Report ]

On Dual core 1.2GHz Xscale touted by Intel:

In reply to James Woodland:

Apologies if I over-condensed the summary there, but my point doesn't really depend on exactly how you slice and dice the wording.

You don't need to be Castle, or to be a 'select company with RISC OS knowledge' (whatever that means), to produce potentially usable hardware - even if you allow ARM-based hardware only.

Any sufficiently skilled programmer can enhance the operating system. Yes, access to the existing codebase would help, but it isn't necessary.

Any sufficiently skilled programmer can help to plug some of the software gaps. Maybe not all of them, but some would be a good start.

To port the existing codebase to new hardware you would (quite possibly) need Castle's consent, but that is very different from requiring that they or an existing player take the initiative. (You do not, of course, have to use any or all of the existing codebase.)

In short, whatever you mean by "advancing RISC OS as a platform" there are options open to us. Some of them might even happen if we spent more time doing rather than complaining.

 is a RISC OS Usergdshaw on 31/08/06 11:34PM
[ Reply | Permalink | Report ]

On Dual core 1.2GHz Xscale touted by Intel:

In reply to James Woodland:

So on the one hand only Castle can advance RISC OS because only they can make new hardware, but on the other hand new hardware would not advance the platform because of all the software gaps? Sorry, but I don't see how that makes any sense at all (even if you accept the premise).

Be careful not to confuse the hardware platform (of which we have several - including x86 via emulation), the software platform (essentially the ABI and API) and the existing codebase.

Castle control one (current) hardware platform and a substantial part of the existing codebase. Significant, yes, but a long way from the total control implied above.

 is a RISC OS Usergdshaw on 31/08/06 10:17PM
[ Reply | Permalink | Report ]

On Dual core 1.2GHz Xscale touted by Intel:

In reply to Michael Stubbs:

"We have no control over and no means to achieve any advance of RISC OS as a platform"

On the contrary, due to its modular nature it is perfectly possible for third parties to advance RISC OS (with or without access to the source code for the remainder).

(That doesn't mean it will happen, of course, but it is inaccurate to say that we have no control.)

 is a RISC OS Usergdshaw on 31/08/06 7:31PM
[ Reply | Permalink | Report ]

On Castle considering open sourcing RISC OS:

In reply to druck:

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

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

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

 is a RISC OS Usergdshaw on 25/08/06 1:06PM
[ Reply | Permalink | Report ]

On Dual core 1.2GHz Xscale touted by Intel:

Particularly attractive is the fact that this would be a worthwhile upgrade even if one of the cores were left idle (as it probably would be at first). That gives it a chance to achieve a large enough installed base to make the necessary software enhancements viable.

 is a RISC OS Usergdshaw on 23/8/06 5:30AM
[ Reply | Permalink | Report ]

On Castle considering open sourcing RISC OS:

In reply to Dan Maloney:

"I could see that being beneficial to RISC OS"

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

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

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

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

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

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

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

 is a RISC OS Usergdshaw on 23/08/06 04:01AM
[ Reply | Permalink | Report ]

On Castle considering open sourcing RISC OS:

In reply to Dan Maloney:

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

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

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

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

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

 is a RISC OS Usergdshaw on 22/08/06 08:01AM
[ Reply | Permalink | Report ]

On Castle considering open sourcing RISC OS:

In reply to Jess Hampshire:

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

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

 is a RISC OS Usergdshaw on 19/08/06 9:38PM
[ Reply | Permalink | Report ]

On Castle considering open sourcing RISC OS:

In reply to Jess Hampshire:

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

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

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

 is a RISC OS Usergdshaw on 19/08/06 8:41PM
[ Reply | Permalink | Report ]

On ROS must open up to survive says Wild:

In reply to Stewart Brodie:

"The problem is the infectious nature of the licence"

If you think the GPL is infectious, consider what would happen if you reused code taken from Microsoft Windows, RISC OS, or just about any other piece of proprietary software.

 is a RISC OS Usergdshaw on 02/08/06 9:47PM
[ Reply | Permalink | Report ]

On ROS must open up to survive says Wild:

In reply to Julian Zimmerle:

"So what is your suggestion?"

Personally I would go for a Debian-like model, perhaps using a package manager like RiscPkg. But then, perhaps I'm a little biased on that count :-)

As I said above, this does not mean that everyone has to distribute source code: commercial companies could distribute binary-only packages if they so wished, either on disc or from a password-protected website.

(BTW this isn't an entirely academic discussion: I am seriously interested in methods that could be used to efficiently distribute software optimised for different sub-architectures such as ARM6, XScale and so on. If anyone has any other ideas then I'm listening.)

 is a RISC OS Usergdshaw on 25/07/06 9:47PM
[ Reply | Permalink | Report ]

On ROS must open up to survive says Wild:

In reply to Julian Zimmerle:

"The debian model of having big distributions for different platforms is unsuitable, because it would require all software vendors to agree on a single distribution method."

Not true. Debian systems do not require that all software be installed using a single method.

"And it adds even more overhead, because then all the data files ... would all be duplicated"

Only if you package them naively, and even then only on the server (and any distribution media etc.)

I'm not saying that there isn't a point to be made here, but at the moment you are arguing it from a number of false premises.

 is a RISC OS Usergdshaw on 24/07/06 02:53AM
[ Reply | Permalink | Report ]

On ROS must open up to survive says Wild:

In reply to Julian Zimmerle:

"It's not like the size of application executables is in any way a relevant factor"

That is a value judgement with which I for one disagree. What concerns me most are the multiplicative and open-ended nature of the overhead, especially having seen some of the difficulties Debian have experienced as their number of architectures has increased (when their model only impacts on the server side).

We are already afflicated with a number of design decisions which were, shall we say, unfortunate in the long term. Leaving aside the issue of whether we have a long term future, do we really want to be adding new ones?

"The approaches of debian and gentoo are not open to us, unless we want to loose all commercial applications"

So far as the basic Gentoo model is concerned (by which I mean compiling locally), I agree. Debian is rather different, as it does not require the release of source code, and I see no technical reason why it is necessarily unsuitable for proprietary software.

 is a RISC OS Usergdshaw on 24/07/06 01:03AM
[ Reply | Permalink | Report ]

On ROS must open up to survive says Wild:

In reply to Garry Taylor:

I thought someone might mention that, which is why I said 'a significant number of architectures'.

Yes, if you only intend to support two or three then you can get away with a naive implementation, and if (as in the case of the Mac) you are only using it to migrate from one platform to another then you will never have more than two or three.

The considerations that apply if you intend to support a significant number of platforms on a long term basis are completely different, and simply putting a binary for every platform in every application would be an awful precedent to set for an operating system which prides itself on being efficient.

 is a RISC OS Usergdshaw on 23/07/06 8:00PM
[ Reply | Permalink | Report ]

On ROS must open up to survive says Wild:

In reply to Julian Zimmerle:

The method you propose for supporting multiple architectures is not scalable: everyone takes a hit (in terms of disc space, download times and so on) whenever you add a new one.

The only successful models I have seen that manage a significant number of architectures concurrently are Debian (multiple binary distributions generated centrally, user downloads one) and Gentoo (single source distribution, user downloads and compiles).

A further benefit is that you would be able to support sub-architectures (ie. optimised for ARM 6, StrongARM, XScale etc.)

(Apologies for empty message above due to finger trouble.)

 is a RISC OS Usergdshaw on 23/07/06 6:32PM
[ Reply | Permalink | Report ]

On ROS must open up to survive says Wild:

(nt)

 is a RISC OS Usergdshaw on 23/07/06 6:23PM
[ Reply | Permalink | Report ]

On Ex-Pace staff back RISC OS Open Ltd:

In reply to Stewart Brookes:

"Let's make it happen."

Agreed. Anyone who is willing to help organise this, or who has ideas about exactly how it should work, contact me and I will set up a mailing list. (My e-mail address can be found at [link])

The first stage will presumably be to set up a web-based directory of some description. It would be really useful to have someone who is good at web page design for this. I can do the back end database without diverting too much time from other projects. Once that is up and running we can start looking at other ways to direct effort towards the main problems we face.

 is a RISC OS Usergdshaw on 17/07/06 5:49PM
[ Reply | Permalink | Report ]

On Ex-Pace staff back RISC OS Open Ltd:

In reply to David Buck:

One more thing such an organisation could do: raise money and use it to fund prizes for some of the more difficult (or easy but long-standing) problems.

(I'm willing and able to give my time for free, and I can't see that changing, but others may be in less fortunate circumstances. I could see this making a big difference (a) in encouraging those who have written for RISC OS in the past, but are now starting to drift away, and (b) concentrating effort on the problems that need fixing. Deciding what needs fixing most is likely to be contentious, so any venture along these lines would need to be both inclusive and democratic or it would merely become another forum for infighting.)

 is a RISC OS Usergdshaw on 15/07/06 08:09AM
[ Reply | Permalink | Report ]

On Ex-Pace staff back RISC OS Open Ltd:

In reply to Stewy:

You asked what non-programmers can do. Here's a suggestion. We have a limited number of programmers, but there is much more to software development than just writing code: there is testing, documentation, graphic design, website design, first-line support, publicity and so on. Most of our non-commercial projects are run by a single individual, and time spent doing these things is time not spent programming.

(It is also the case that programmers are often not very good at the other things that go into software.)

What if there were some sort of clearing house dedicated to identifying the key problems we face, and those willing to help, and bringing the two together?

I don't imagine for a moment that we can solve all of our problems overnight this way, but it might help to deploy the resources we have more effectively. Perhaps more importantly it would help give a sense of progress, and an assurance that problems (even if not immediately solvable) had not simply been forgotten.

 is a RISC OS Usergdshaw on 14/07/06 7:30PM
[ Reply | Permalink | Report ]

On Ex-Pace staff back RISC OS Open Ltd:

In reply to Gulli:

I think your assessment is too pessimistic. Using RISC OS as ones primary (or only) operating system is a much more realistic prospect now than it was five, or even two years ago. I would also venture that RISC OS has quite a healthy number of developers in relation to the size of its userbase.

Now it is true that RISC OS also faces some serious challenges and it is important to be realistic about them, but there is a difference between being realistic and fatalistic. If we simply accept that RISC OS will die then it probably will, but then that is a self-fulfilling prophesy. Wouldn't it be better to try to take control of events rather than be controlled by them?

 is a RISC OS Usergdshaw on 13/07/06 00:06AM
[ Reply | Permalink | Report ]

On NetSurf conquers Wikipedia:

In reply to wuerthne:

Ironic that you should say that, because the W3C went to great lengths to define the DOM in terms of pure interfaces so that (in theory) it avoids placing constraints on the underlying data model.

(In practice I'm inclined to agree with you: in any sane implementation the data structures need to be at least vaguely congruent to the DOM interfaces. Whether or not that is true of Netsurf at present I have no knowledge.)

 is a RISC OS Usergdshaw on 12/7/06 9:09PM
[ Reply | Permalink | Report ]

On Could public cash save our software?:

In reply to epdm3be:

Microsoft's file formats do not enjoy universal compatibility, even between different versions of Office let alone other platforms.

As for adopting a standard RISC OS document format there is one very obvious candidate: OpenDocument ([link]).

 is a RISC OS Usergdshaw on 9/7/06 12:51PM
[ Reply | Permalink | Report ]

On Could public cash save our software?:

In reply to mripley:

To clarify, I'm not really defending the current situation: it is, as I said, unfortunate. I do, however, contend that eliminating the fragmentation you referred to (presumably by concentrating effort on one browser) would in this case have made matters worse not better.

 is a RISC OS Usergdshaw on 9/7/06 12:01PM
[ Reply | Permalink | Report ]

On Could public cash save our software?:

In reply to timephoenix:

The problem with concentrating work on a single browser is that FireFox (on RISC OS) will never be as fast as NetSurf, and NetSurf (realistically) will never be as compatible as FireFox. Unfortunately I think we need them both, and I am very grateful to those involved for bringing us to the point where it is no longer necessary to switch to another operating system for most web browsing needs.

 is a RISC OS Usergdshaw on 9/7/06 7:33AM
[ Reply | Permalink | Report ]

On NetSurf conquers Wikipedia:

Excellent news indeed.

NetSurf has been my main browser for some time now, and while it cannot completely replace FireFox without Javascript, it is good to have the speed and aethetics of a native RISC OS application for the very large number of sites which do not have (or are usable without) active content.

 is a RISC OS Usergdshaw on 3/7/06 7:00AM
[ Reply | Permalink | Report ]

On RiScript in delivery delay shame:

In reply to knutson:

RISC OS does not, however, exist in a vacuum. Add too much heavy-handed copy protection and you (a) remove one reason for avoiding MS Windows and (b) create a very powerful reason for switching to GNU/Linux.

To compete with free you need to have a superior product, and if copy protection gets in the way of that then you loose.

 is a RISC OS Usergdshaw on 30/4/06 8:14AM
[ Reply | Permalink | Report ]

On MW Software reveals PDF work:

In reply to nico:

I'll second that. Thank you, Martin. Techwriter really has moved forward over the last year or so, and this will be a most useful upgrade. Long may it continue.

 is a RISC OS Usergdshaw on 26/4/06 8:24PM
[ Reply | Permalink | Report ]

On ROL release C99 SCL to A9home users:

In reply to jools:

If the two branches simply went off in their own direction then we would already have a complete disaster, because it is rather important that each function within a given library chunk have a unique and well-defined interface. Fortunately, that hasn't happened.

Given that this basic level of cooperation is essential, it would not be difficult to arrange for the version number to increment each time the interface is changed.

What would be needed for this to happen is agreement that the version number identifies the interface to which a module conforms rather than a specific implementation.

 is a RISC OS Usergdshaw on 18/4/06 7:32PM
[ Reply | Permalink | Report ]

On New ArtWorks, AWRender planned for Wakefield:

In reply to wuerthne:

I still can't help feeling that this is a step in the wrong direction when compared with the push for more open data formats that is gaining momentum elsewhere - but you are right that this is more of a theoretical than a practical issue, and I am very encouraged by your comments about what may happen to it in the future. (Certainly you can count me in for the upgrade.)

 is a RISC OS Usergdshaw on 18/4/06 7:09PM
[ Reply | Permalink | Report ]

On New ArtWorks, AWRender planned for Wakefield:

In reply to wuerthne:

The trouble is that embedding into other documents will be a less attractive proposition if you cannot be confident that others will be able to view the result correctly.

I can see why you have chosen to distribute it this way, but a model that placed the costs solely on the originator would be preferable - even (IMO) to the originator.

(You would have to change the file format slightly to make this work - or rather, to ensure that documents produced using the existing method did not work - but it could be done.)

 is a RISC OS Usergdshaw on 18/4/06 5:06AM
[ Reply | Permalink | Report ]

On Inside an unofficial Shared C Library:

In reply to chrisrayson:

I can avoid making the problem any worse. My intention is to match the version number of the most recent ROL or CTL module which which I believe mine to be fully compatible, and then provide further details of exactly what is loaded in the comment field.

I'm not so sure what to do in response to the function _clib_version. Does anyone use this, and if so do they interpret it programmatically?

 is a RISC OS Usergdshaw on 21/3/06 5:41PM
[ Reply | Permalink | Report ]

On Alternative Shared C Library in development:

In reply to nodoubt73:

I have full confidence that ROL and/or CTL will resolve the Shared C Library issue by the time the A9 becomes a fully released product. At most this project it a bit of friendly competition.

What I presume they won't be doing is releasing the source code to their versions, and that's where I can make a difference.

 is a RISC OS Usergdshaw on 21/3/06 11:30AM
[ Reply | Permalink | Report ]

On Inside an unofficial Shared C Library:

In reply to cmj:

The licence only specifies what you can do without asking the author beforehand.

Having said that I doubt my module would integrate very well with the way RISC OS is built, not to mention any political or support issues.

 is a RISC OS Usergdshaw on 21/3/06 10:06AM
[ Reply | Permalink | Report ]

On Inside an unofficial Shared C Library:

In reply to GavinWraith:

Sounds feasible, but it might cause compatibility problems with existing software so I would want to tread cautiously.

(There is the possibility of making this sort of behaviour optional - either controlled globally or on a per-program basic - in much the same way as some of the features provided by UnixLib.)

A related question is whether to use the FPE or soft floating point. (Initially I'm going for the FPE, but a floating point library could be incorporated later.)

 is a RISC OS Usergdshaw on 21/3/06 9:50AM
[ Reply | Permalink | Report ]

On Alternative Shared C Library in development:

In reply to nodoubt73:

I may not be a real company, but I am a real person.

In any case, anyone can support a program once it has been released as open source. Surely that is better than being dependent on a single company?

 is a RISC OS Usergdshaw on 20/3/06 5:30PM
[ Reply | Permalink | Report ]

On Alternative Shared C Library in development:

In reply to nodoubt73:

By your reasoning the UNIX-compatible market should be in a far worse state than RISC OS. Not only have most of their users deserted the official C library for glibc, they went and replaced the rest of the OS too.

In reply to bluenose:

Fragmentation is an issue which I am very much aware of, which is why any changes to the interface have to be very carefully thought through.

A good example of what I have in mind is better cooperation between the SCL and UnixLib when a program using one calls a program using the other. This doesn't break the documented interface, and is much more likely to fix undesirable behaviour than to cause it.

The having several implemtations of the SCL is not a problem. Having different interfaces is.

 is a RISC OS Usergdshaw on 18/3/06 11:26AM
[ Reply | Permalink | Report ]

On Distributing software with RiscPkg:

In reply to JGZimmerle:

Actually, I've been making a point of keeping files together in application directories, avoiding use of the !System, Library and Resources directories.

Being self-contained is an entirely different matter, and my goal is to normalise as much as possible. (By 'normalise' I mean avoid redundancy, as in a relational database.) Once dependencies are managed there is little benefit in having self-contained packages and quite a few disadvantages (not just disc space, but also the risk of clashes at run-time when different applications contain different versions of a module or other resource).

 is a RISC OS Usergdshaw on 25/02/05 6:59PM
[ Reply | Permalink | Report ]

On The Case for a RISC OS Package Manager:

In reply to Loris:

Actually, RiscPkg has already reached a state where it could install from a CDROM set. (There are a couple of issues which make this a bit more complicated than it needs to be, but these will disappear once RiscPkg is able to resolve relative as well as absolute URLs.) The main reason no CDROM set has been produced is the small number of packages available to put on it.

Other package transport schemes could be implemented as necessary, but if this left you having to manually download packages one at a time then you could reasonably question whether it was all worth the effort.

 is a RISC OS Usergdshaw on 23/01/04 5:47PM
[ Reply | Permalink | Report ]

On The Case for a RISC OS Package Manager:

In reply to Loris:

The normal mode of operation is for RiscPkg to install the package(s) requested along with any other packages needed to make them work, all in one operation.

I dare say there will be an option to turn off dependency resolution. It is also possible for a package to 'recommend' or 'suggest' other packages, and I hope to include support for these relationships at some point in the future.

There will be a status bar to tell you how many packages and how many megabytes you have selected before you commit to downloading them.

 is a RISC OS Usergdshaw on 22/01/04 6:48PM
[ Reply | Permalink | Report ]

On The Case for a RISC OS Package Manager:

In reply to Chris:

There are already plans for an 'alternatives' mechanism which will have the necessary information to do this for already installed packages.

To do the same for uninstalled packages it would be necessary to add the information to the package control record. My only question is how useful the facility would be in practice (bearing in mind that the files which cause most difficulty tend to be those produced by (a) discontinued commercial software or (b) other operating systems.

I'll open up the question on the mailing list as to what if any metadata should be provided for searching (beyond the section, priority and free-text description). There are already quite a few fields to complete, and I don't want to make packaging more difficult or time-consuming than it needs to be.

 is a RISC OS Usergdshaw on 22/01/04 06:12AM
[ Reply | Permalink | Report ]

Recent articles and quickies

  • The Case for a RISC OS Package Manager
    Graham Shaw talks about RiscPkg
     44 comments, latest by gdshaw on 23/01/04 5:47PM. Published: 18 Jan 2004

  • Search the archives

    Today's featured article

  • DialUp, R-Comp's net connectivity package, is put to the test as Michael Stubbs reviews

     2 comments, latest by gary_hughes_fp on 7/8/01 3:50AM. Published: 12 Feb 2001

  • Random article

  • AcornArcade to re-release Cooper classics
    Berty games are back on the block
     7 comments, latest by aardvark on 27/2/04 10:34PM. Published: 26 Feb 2004

  • Useful links

    News and media:
    IconbarMyRISCOSArcSiteRISCOScodeANSC.S.A.AnnounceArchiveQercusRiscWorldDrag'n'DropGAG-News

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    Dealers:
    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster

    Usergroups:
    WROCCRONENKACCIRUGSASAUGROUGOLRONWUGMUGWAUGGAGRISCOS.be

    Useful:
    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign


    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "You know you use the comments system too much when you get email telling you that someone replied to your comment, and that someone is you"
    Page generated in 0.5494 seconds.