First RISC OS Distro for Pi?

one of Zap and StrongEd

That’s not a clear-cut decision, even for a compiler of a distro. For example, I have a personal preference, but that’s probably more borne from initial first use than objective criteria.

I agree with Messrs Phillips and Flegg. The distribution seems to be getting larger and more complicated, and I’m not entirely sure why. Part of the beauty of RISC OS for me (despite not having used it properly since 1999) is its simplicity, its speed and its pared back nature. It’s a nice comparison to Windows, Linux and OS X, which are rather porcine by comparison.

How much input – if any – are ROOL having into what goes into it? It’s important that it provides the best possible experience for those new to RISC OS. If someone tries RISC OS and doesn’t like it, there isn’t anything binding them to the platform. It’s free to download, and the download itself is small. And it isn’t hugely difficult to install (or to erase, for that matter).

I’d personally like to see an additional, stripped down distribution that contains the basics that you need to get RISC OS up and running (i.e. the FAT partition, a decent-sized partition for RISC OS and a boot sequence). It wouldn’t be much use for beginners, I admit, but it may have some appeal to more technical users or people, who, like me, used RISC OS ages ago and are returning (after a manner of speaking) to the platform. I spent a lot of time back in the mid/late 1990s getting my RISC PC running just right – for me, and I think I’d actually enjoy doing that on a RPi.

[Zap or StrongEd] That’s not a clear-cut decision, even for a compiler of a distro. For example, I have a personal preference, but that’s probably more borne from initial first use than objective criteria.

I disagree: it is a clear-cut decision. The distributor can ship whichever they prefer. I’m a StrongEd man, but if it’s Zap – I don’t care, I can download StrongEd. That’s where package managers or up-to-date indices of modern software come in.

If it’s Zap and I really care, I can fork the distro. But the point is that a person getting started shouldn’t have the paradox of choice to contend with when getting started with an unfamiliar OS.

To my mind, the two criteria which should decide it are the one which is most stable (rather than most featureful) and the one which is most actively being developed; whether that’s Zap or StrongEd.

Chris’ work is supported by ROOL – this will become the official distro.

I think the reasoning against Programming v Apps is that $.Apps gets auto-booted and added to Resources:$.Apps. That makes StrongED the default text editor. If Zap is also at the same level, I’m not sure quite what the behaviour is (does it depend on the order the directory is scanned?). In any case, it might be unpredictable. Putting Zap elsewhere at least means it’s available to people who want to try it (editor wars being a fairly common phenomenon on many platforms).

Fred, the wiki page says “Contact: ongoing with Fred Graute”. What is the state of those discussions?

There will always be the option of reformatting your disc, putting !Boot on it, and starting from scratch. At the moment that’s slightly complicated due to the formatter having to run on RISC OS, and the special hack magic of the FAT partition embedded in the FileCore partition, but it’s not intended that the ‘distro’ is the only way to install RISC OS.

Package manager: I’m working on it, but currently Zap isn’t packaged (and is rather awkward to package). Zap is confusing because the ‘official’ site doesn’t have an ARMv7 working version on it. StrongED 4.60 is packaged so that’s available for download, but we’d rather have the latest version.

I agree, presenting too many choices is confusing. But there’s quite a hurdle to going off and installing stuff (packaged or manually), so there’s a balance to be struck between too many choices and making it easy for people to try new software without the trouble of finding out what something is called and going look for it.

Theo (not speaking directly for ROOL)

[…] the two criteria […] most stable […] most actively being developed […]

OK, that makes perfect sense. Sounds like StrongED, then IMHO (and I’ve always primarily used Zap, myself). AFAIK Tank’s Zap compatibility updates don’t mean the resumption of active development by him or the original developers. Is that a fair summary, or not?

I think the reasoning against Programming v Apps is that $.Apps gets auto-booted and added to Resources:$.Apps. That makes StrongED the default text editor. If Zap is also at the same level, I’m not sure quite what the behaviour is (does it depend on the order the directory is scanned?). In any case, it might be unpredictable. Putting Zap elsewhere at least means it’s available to people who want to try it (editor wars being a fairly common phenomenon on many platforms).

Fair point. However, is !Zap.!Boot well-behaved if StrongED’s been booted and is the default text editor? For example, when the user:

• shift-double clicks on a file
• selects Task Window from the switcher
• uses an editor using OLE

If the non-default text editor stays out of the way (even after being Filer_Booted) except whilst it’s running (and ideally reverts the system back to using the default text editor after it’s shut down), that’s ideal.

How much input – if any – are ROOL having into what goes into it?

Ultimately, we’re responsible for anything we distribute, so I suppose we have a veto on anything. But please realise that we’re not an organisation like Acorn was, or even Castle when they were producing Iyonix. We have no full-time staff (although the workload is at a point now where we really need some!) There is no testing department. There is no public relations department. There is no engineering department, no sales department, no technical publications department, no financial department, no logistics, no IT support, no management. We’re trying to do it all ourselves. We work entirely in our free time, whilst trying to hold down full time jobs and (in one case) a young family. There is absolutely no way we can micro-manage every part of RISC OS – the entire shared-source RISC OS project is reliant upon the community pulling together. We need lots of pairs of eyes to be checking this stuff, to ensure that the distro is the best it could be. If you care about the success of RISC OS, the community needs your help, now.

On Zap vs StrongEd – I’m a firm Zap user myself, and within ROOL, Zap users outnumber StrongEd users. Yet I have to say that the Zap developers have been less responsive in our previous attempts to put together disc images – anyone who has purchased one of our USB sticks may have noticed that StrongEd is present but Zap is not. Also, with its toolbar, StrongEd is probably less daunting to new users, so much as it pains me to say it, it makes sense to me for it to be the default editor.

(So, a plea to the Zap developers – please get an official release together for modern machines, or you’ll end up as an also-ran! With the Raspberry Pi being so cheap, not being able to afford new hardware to test it on is no longer an excuse!)

So !Edit is not going to be the default text editor? If this is the case, it could be worth bearing this in mind when writing the welcome/user guide…

But the point is that a person getting started shouldn’t have the paradox of choice to contend with when getting started with an unfamiliar OS.

Quote: “In the book, Schwartz argues that eliminating consumer choices can greatly reduce anxiety for shoppers.”

On the other hand, using a computer system is a highly personal thing. Why do we prefer RISC OS over, say, Windows? They both work in more or less the same way. But both exist in their own paths. Along with Ubuntu (and dozens of Linux distros), Mac’s OS, and so on. Mobile phones offer a variety of systems (Android, iOS, WinMobile, Blackberry, Symbian, Bada…) that do pretty much the same things. Why?
Simple. The theory is wrong. For a start, there is the price factor. This is clearest to see with mobile phones where Bada is low price, Android is low/middle, and iOS is high price. There is also the Apple status-symbol issue. And, that aside, people just work and think a little differently. Some are happy with a restricted system that lets them do only so much, some prefer to have more control. Some root their phones and exercise godlike powers over the device.

Zap and StrongEd are essentially the same. But how they get it done is different. To my mind, very different. Picking one could alienate those who prefer the other; and seeing as how $.Apps auto-boot, I would suggest both are moved to Programming so that Edit starts as the docs imply it would. It’s easy enough to move the application if you find you prefer it (as I myself have done). This can be mentioned in the user guide or the app help.

So, a plea to the Zap developers

The official website seems to have stopped around 2008; Tank’s (very much appreciated!) OMAP3 port is dated 16 Sep 2011. Is he the only current developer at this time?

AFAIK Tank’s Zap compatibility updates don’t mean the resumption of active development by him or the original developers. Is that a fair summary, or not?

The official website seems to have stopped around 2008; Tank’s (very much appreciated!) OMAP3 port is dated 16 Sep 2011. Is he the only current developer at this time?

Calling me a “developer” is really overstating it. I have just (hopefully) made it work with a belt and braces changes to the code. I only originally did this as I wanted to use Zap myself. Recently Chris Gransden has emailed me with some problems with zero page useage, so I have been helping him weed those out and so there may be another update when this is done.

Calling me a “developer” is really overstating it.

Thou hacketh, thus thou dost be called by the name “developer”.

[developers! developers! developers! dev…<cough>]

Ultimately, we’re responsible for anything we distribute, so I suppose we have a veto on anything.

You certainly do.

I have updated the distro to 24 July, adding a few things (see top of this thread for details). I have stuck with the 21 July ROM image as the latest image is being heavily developed and I’ll wait for that to stabilise.

Picking one could alienate those who prefer the other

My hypothesis is that the distribution will be used by more people than who’ve ever used either.

Now, in this case, having the “other” editor elsewhere isn’t that bad; as long as the documentation isn’t trying to cater to experienced RISC OS users who may prefer one over the other, and so full of conditional statements (which would just confuse matters).

However, for things like screenshot tools, there should be one. For image viewers/converters, there should be as few as possible. For music/movie players, I’d argue for only a single one which was as polished & full featured as possible; rather than having a dozen half-working, single-format supporting players which the user has to try all of.

Finding that the one shipped doesn’t work with the video format a particular video format is in is going to be less frustrating than having to have a dozen video players, none of which play it back effectively.

If we used packman to deal with this, we could have one of everything. And, assuming that the image has programs pre-installed via packman, users could modify it as they wish, simply. (Also upgrades could be supplied via it).

We could also have the choice of an ultra slim image and a big one.

If we used packman to deal with this,

In principle, Yes. But it would require quite a bit of work to have a suitable external site set up with sensible choices dedicated to inexperienced users running it on a Pi. Advantage – the external site can be developed after fixing the disc image. Disadvantage – by having everything on disc support is easier.

This is going to be a long one, hopefully no-one minds, but I think it’s important to show where I’m coming from as well as providing some background on how I got involved with StrongED and ended up being its maintainer.

[Zap or StrongED] That’s not a clear-cut decision, even for a compiler of a distro.

I disagree: it is a clear-cut decision. The distributor can ship whichever they prefer.

Allow me to use this as a starting point. Yes, the distributor has, of course, the right to pick whatever they think is best. But by picking one over the other they also introduce bias, just think of the situation with Internet Explorer where users stuck with that simply because it came with the machine.

For those of us that have been in the RISC OS world for a long time it’s not a problem, we’re aware of both editors and can install the other one if desired. New users however may well stick with what’s already there, with the risk that they end up with an editor that doesn’t really suit them.

I’m sure Ben (hope you don’t mind me using you as an example :-) would still do a wonderful job when forced to StrongED but he’d probably be less productive than when using Zap which he’s more at ease with.

To me that’s what it comes down to in the end; productivity. Probably one of the dearest things in the RISC OS world are developers and as such it’s vitally important that they can be as productive as possible and that means that they need to be comfortable with the tools they’re using.

So, I feel that Zap/StrongED should be presented in a neutral way without any kind of bias (accidental or otherwise). It’s then up to the user to decide which editor they prefer.

With both included users have a choice other than Edit which isn’t really suited for programming beyond a simple Obey file. I certainly ditched it for something better asap, which was, believe it or not, Zap (1993-ish). StrongED didn’t show up on my radar until a couple of years later (not connected to the internet back then). When it did appear here I looked at it out of curiosity but continued to use Zap.

Some time later I started work a BASIC project and I had noticed that StrongED had better syntax colouring support for BASIC than Zap (1.35-ish) at that time. So I used them in tandem for several years, StrongED for BASIC and Zap for everything else.

(As aside; syntax colouring to me is THE raison d’être for code editors. It makes things so much more readable, the day I’m forced to code without it is the day I’ll drop programming. Shiver to think that I started coding on a 40×25 characters monochrome screen.)

This dual usage lasted till late 2000 when AcornUser released their Programmer’s CD which, although still without internet, didn’t offer much I didn’t already have save one thing; the sources to StrongED. As I had became aware of a couple of bugs in StrongED I set out to fix them, and I have continued working on StrongED right up to the present day.

Had the sources to Zap been on that CD chances are I’d be doing Zap now, but they weren’t and as I got more into StrongED my Zap usage diminished quickly.

As you can see I’ve been doing this for a while and within that time there have been some incidents regarding distribution of my software. Such as people creating a full version by combining the latest release version with an updated RunImage I’d made and sticking that on a website somewhere. Support issues however landed here even though I had no hand in producing that particular release nor had I given permission for it.

In one particular instance the user posing a question couldn’t remember where it came from so I had to google for it, download it, diff against my own copy to see if there were any code changes before I could set about answering the query raised. The extra work, as I’m sure you’ll understand, I can well do without.

Another issue is that when permission is given to include StrongED in some form of distribution then this is taken to be a licence for any and all version of StrongED, past, present and future. Even though it only applies to one version, usually the latest release at that time.

In response to the above I have, reluctantly, taken the decision to tighten up licensing of my software. Rather than just giving permission to include something I now supply the version of software that the licence applies to directly to the party asking for permission. Examples of these are:

Castle, FRU and a few others which I forget also had (old style) licences to distribute StrongED.

This gets us to late 2011 when Theo contacted me asking if it’d be okay to include StrongED in a RPi image. The licensing conditions would be largely set by the RPi foundation and they cast a very wide net; allow redistribution through third parties, being able to charge for it, allowed to make alterations.

This basically means giving free access to StrongED to everyone, all they’d have to do is say that they got it through the RPi. Given past experience this was an unsettling proposition, but at the same time a great opportunity to expand the StrongED userbase.

So I began to reconsider my earlier decision to tighten up the licence, perhaps another model might be better with open source being the most logical candidate.
No firm decision has been made on this but I did modify StrongED’s build process to make such a move easier – StrongED uses the BASIC assembler but BASIC files don’t sit well with RCS systems, now the source is held as text files with the build process converting them to BASIC prior to assembly.

Which is pretty much where things are at today.

In conclusion, as you can see I’m not adverse to allowing others to distribute my software. What I do oppose to is people including something without checking with me first. StrongED especially has a lot of time and effort invested in it, not just developing but also getting into it (Norwegian comments anyone? Okay, buying a Norwegian <→ Dutch dictionary largely sorted that. Of course these days you just chuck it at Google Translate. ;-)

Getting asked for permission is a bit of remuneration for all that work and it lets me know where support questions can come from, rather than me wondering what someone means when they refer to, say, the ‘ROOL’ version. Besides, it’s not like I’ve vanished from the RISC OS scene without a trace.

Hopefully I’ve clarified my position with this and haven’t bored everyone to death.

Recently Chris Gransden has emailed me with some problems with zero page useage, so I have been helping him weed those out and so there may be another update when this is done.

@Tank, you may also want to have a look at some of the flag preservation code. When I looked at the source some time ago I noticed that some of it is using MSR CPSR_c rather than MSR CPSR_f. HTH

Fred, the wiki page says “Contact: ongoing with Fred Graute”. What is the state of those discussions?

You tell me :-)
As you may remember that was between you and me. My last email to you (12 Dec) has gone without a reply so negotiations stopped. Did you receive it or has my ISP been overzealous again in its spam checking?

StrongED 4.60 is packaged so that’s available for download, but we’d rather have the latest version.

It is now, I only fixed the link recently – it was still pointing at Guttorm Vik’s, now gone, webspace.

It’s not much use though as it’s not ARMv7 safe nor is it 32/26 bit neutral.

This gets us to late 2011 when Theo contacted me asking if it’d be okay to include StrongED in a RPi image.

I proposed to include StrongEd in the form in which it is included on ROOL’s DDE (C/C++ compiler) [i.e. 4.69a5] subject either to these discussions being favourable and/or subject to ROOL being content that it is already within their permission. At present Zap is ‘hidden’ in a sub-directory. At present this is all alpha and I am doing my best to steer my way around the licensing issues and am only involved in the negotiations at third hand in most cases.

I am working on the basis that software that is free to download can be included in a free to download distro provided it is kept complete and intact along with all copyright info etc. (even sources if it is GPL) – it is simply being collected together for the convenience of the end user – effectively acting as his agent.

This is only likely to become an issue when someone wants to charge for providing a ‘ready made’ SD card but that is another issue.

What a doozy. Nice work. Runs straight out of the box.

Alex Macfarlane Smith has pointed out that Nettle also works perfectly well on RPI:
http://www.riscos.info/packages/NetworkDetails.html#Nettle

Maybe worth dropping in a future distro?

Fred,

You tell me :-)
As you may remember that was between you and me. My last email to you (12 Dec) has gone without a reply so negotiations stopped. Did you receive it or has my ISP been overzealous again in its spam checking?

Ah, err, oops. Think that fell between mine and Trevor’s stools when we were sending out lots of emails about software. I see I even read it too :(

Stepping back a moment, am I right in assuming your primary concern is people modifying things but the support burden passing on to you? The following is not aimed at you particularly, but hopefully touches on my philosophy a bit (my philosophy != the philosophy of a RPi distro, of course). I’m happy to take things to back to email if you prefer.

I think the way the open source community handles the ‘version confusion’ is to minimise the reason for releasing modified things in the first place. For example, have a publically-visible revision control system (sourceforge, github, riscos.info, etc). Encourage people to submit patches. Provide timely integration of patches that are submitted, and the fresh release of new (alpha/beta) versions. Encourage open discussion of problems (eg a support mailing list whose archives Google picks up) rather than personal email. github and sourceforge have all this integrated (though, of course, git doesn’t currently run on RISC OS).

That way people are less likely to email you about problems which are already known, because Google may find the answer (and if not, other users may help). If people fix a bug, it’s less hassle to submit a patch (‘svn diff’) and you to turn the handle and release a new version (integrate patch [version control helps here], bump version number, type ‘make release’ or whatever) than it is for them to release a hacked-up version on their own website.

Under an open-source licence, forking is easy. But generally people don’t do it, unless the maintainers have abandoned it, or (rarely) if they’re intransigent (eg OpenOffice stagnation after being bought by Oracle). Arguably services like github make forking easy, but generally mainline projects thrive.

On the point of selling things, again the open source community has an answer to that too… it’ll always be available cheaper somewhere else. For example, a vendor can take GPL software and sell it for a million pounds. But since it’s GPL we can ask for the source. Once we have the source, we can compile it and give it away (with source, of course). So the vendor won’t be able to ask a million pounds for long, and generally they don’t try. They can offer some value-added service, like coming round your house and installing it personally, and that’s fine, but you can get the source for free if you don’t want that. BSD doesn’t have such protection – someone can modify it and sell it without publishing changes. Generally, though, the changes have to be significant to make people pay much more than ‘free’.

Looking at it from another perspective, suppose some evil person wilfully ignores all your ‘no commercial use’ clauses. What are you going to do? Sue?

While this was very different in the days of PD libraries, cover discs and limited distribution channels, the internet has changed the landscape hugely. I’m hoping that RISC OS developers will embrace the new mindset :)

EDIT: On the ‘confusion’ point, one method that exists is preserving your ‘brand’ while still permitting open source freedom. For example, Mozilla only allows binaries built from approved sources to be called ‘Firefox’. Debian’s sources aren’t (because they do their own security patching), so theirs is called ‘Iceweasel’. It’s arguable whether this is a good thing for Firefox or not, but it does draw a clear distinction (in terms of perception, support, user experience, not relying on third parties).

^{^}
What he said.

Seriously, look at Tank’s modifications to Zap. The Zap site points to it, but the most logical thing would be for an updated Zap. Why isn’t there one?

The reason? Lack of integration. I’m sure if Zap was hooked to a RISC OS like autobuilder with source access, things could be quite different. For a start, different people could tackle their pet bug, knowing that the changes will immediately benefit everybody. Which is surely better than one person effectively forking Zap into a “works on newer ARM” version to sit alongside the older version.

As a developer, in this day and age you have a choice:

• Sole control. Your project, your say, your workload.
• Shared control. Makes you a ringleader, with others helping. The open nature means others could walk off and make a derivative version, but then the security of being able to can help convince people to take part. [sounds a paradox, what I mean is the source and project will still be around if the dev gets in a strop, dies, decides to take up llama farming on a remote mountainside… in essence, the contributors can get out more than they put in so if it is a worthy project, it’s a win win for everybody – look at RISC OS itself]

While this was very different in the days of PD libraries, cover discs and limited distribution channels, the internet has changed the landscape hugely. I’m hoping that RISC OS developers will embrace the new mindset :)

As Rick says, +1.

If we do get an influx of new users from the Raspberry Pi, they’ll either be non-techy or geeks looking for a new toy OS to play with. The confusion around RISC OS “freeware” licencing will be a shock to people used to well-defined open source projects under the (L)GPL, BSD and Artistic licences.

Although Fred makes his points very well, they almost come across as parochial compared with more established open source communities.

Which reminds me, I need to raise a bug/suggestion for StrongEd: the ability to define the font in the base configuration, since on a fast machine using outline fonts like Consolas is prettier than the system font.

If this was possible, I’d suggest a free font – like Open Sans Mono – being configured as the default in StrongEd in the distro. Similarly, bundling other free fonts, like the Droid & Ubuntu families might provide some nice options. My desktop, with Ubuntu Sans, looks very nice IMHO:

There is no testing department. There is no public relations department. There is no engineering department, no sales department, no technical publications department, no financial department, no logistics, no IT support, no management. We’re trying to do it all ourselves.

What are the chances off Messrs Moyler and Nicoll arranging (limited) company resources to assist in some of these areas?