Raspberry Pi RC16

In case you haven’t noticed, RISC OS Pi RC16 is now available for download.

My initial impressions (on a Pi 3B) are that it’s very good.

Some notes:

• On running Packman, it showed 4 packages needing an upgrade. Of those, DPlngScan failed to upgrade (PackMan’s Conflict Manager complained about “exifinfo/html” and “draw/png”). “Backup and retry” worked. The other 3 applications (PipeDream-Manuals, ResetBoot and UserGuideFiles) updated without incident.
• Documents.Welcome.quick/13/html – The image (of Edit’s icon bar menu) is missing the “Save choices” option now present in Edit.
• Documents.Welcome.quick/14/html – ditto.
• Documents.Welcome.software/html – Two items:
  • The links for Messenger, DataPower and SafeStore (in the “ePic” section) mention an old (demon.co.uk) domain that is about to expire. They should instead refer to “www.rcomp.co.uk”.
  • “The RISC OS Blog” still exists, but updates ceased 12 months ago. Is it still appropriate to mention it here?

No doubt I’ve missed quite a lot…

DPlngScan failed to upgrade (PackMan’s Conflict Manager complained about “exifinfo/html” and “draw/png”)

I am baffled by that. As far as I can see both of these files are part of the html manual within the application. Why is Packman complaining about a conflict (with what?).

I am baffled by that. As far as I can see both of these files are part of the html manual within the application.

I don’t get it either. The files in the “Backup1” directories are identical to the replacement files – even the file permissions are the same.

Sunspot activity, perhaps?

What a pity that !Zap is not included. Still at least RISC OS 5.26 is now finally available under the new licence.

Should the startup screen still have a Castle logo on it?

For some time now, with the ‘latest’ riscos/img file, I have not seen the keyboard not present message.

Is it intentional that it is now visible again? I thought the boot was better without.

There is an icon on the desktop with the name !ePic.

If I double click it, I get an unhelpful error message – [unknown] application not seen by filer.

something assumes that a browser has been seen

Surely !NetSurf is in Apps and the first time RC16 is run, it opens a browser window with a help message.

If I double click it, I get an unhelpful error message – application not seen by filer.

!ePic runs a URI file, but that filetype is not set up by !NetSurf’s !Boot, so simply booting NetSurf is insufficient. The URI filetype does not become fully active until !NetSurf is run. To avoid that have !ePic run a URL file. Tested here. The URL file contains only the URL and is filetype b28. Alternatively, once NetSurf is connected to the ePic site, the URL file is created by Shift-dragging from NetSurf’s URL bar.

And the Obey Mode is missing from StrongED.

Surely !NetSurf is in Apps and the first time RC16 is run, it opens a browser window with a help message.

Yes, but if a user does not double click on !ePic until after a reboot then the the error will occur.

For some time now, with the ‘latest’ riscos/img file, I have not seen the keyboard not present message. Is it intentional that it is now visible again? I thought the boot was better without.

I had the same message last year as well as mouse issue (the mouse would not behave correctly till I had clicked once on each of the mouse buttons). Then I took everything with me while visiting a friend and then it started to behave. I suspect the order in which the USB devices are connected is important.

I suspect the order in which the USB devices are connected is important.

I agree. The USB order can matter in a number of scenarios.

But this one is quite simply that the recent riscos/img downloads do not show the message and this build does. (tested by swapping between image files in loader, with no other changes)

What a pity that !Zap is not included.

Has there been any movement on resolving the redistribution questions since 2016? The RISC OS Pi image ends up on NOOBS (for example) so requires a somewhat robust chain of evidence that it’s not just an SD card chock full of bootleg warez.

While we’re at it, do the manuals need to look like they’ve been copied from a DOS machine? For example, can the Style Guide be renamed to Style or StyleGuide, instead of STYLE/PDF?

Initial observations:

• for my monitor disable_overscan=1 had to be added to CONFIG/TXT. What springs to mind … How would someone new to RISC OS find out about this? Perhaps adding a small configuration utility might address this.
• Within the html “Welcome” guide a number of the software links are broken, because they’ve been given an adddress of https instead of http
• USB behaviour is occasionally a bit random. I’ve had to occasionally unplug and swap around keyboard and mouse to get them working (USB hub). It’s the first time I’ve encountered this.

Bootleg warez

On reading http://zap.tartarus.org/copyright I don’t see how that applies to !Zap … If you included !Sibelius then I’d agree with you… IMHO better to provide pointers to software and let the user decide, after all ;-) !Edit is included.

Overall I like the build and it’s simplicity, including the changelog. I think the ReadMe could be worded differently all refs to Linux, Unix, Windows removed. Perhaps talk about RISC OS being part of the first ARM ecosystem, having a community or it being tailored to ARM processor – it’s history and innvoation…(WYSIWYG).

Bootleg warez

On reading http://zap.tartarus.org/copyright I don’t see how that applies to !Zap

I’m sure the official version of Zap from zap.tartarus.org could be included without problem. But that version is useless on modern machines – you need to use a copy which has been patched by the community. The problem is that that text you’ve linked to denies the permission to distribute modified versions of the app.

Looking at the “It’s been over 12 years…” message from the github repo/mailing list, I believe the way we’re expected to resolve this situation is:

1. Someone needs to contact James and ask to take over as a/the maintainer
2. He’ll transfer his git repo to a “Zap developers” github org (and hand over the website credentials?)
3. Potentially reword the copyright/licensing to make things more permissive? (not sure how much can be “legally” done without seeking permission from the historic contributors)
4. Incorporate the community patches & release a new official version

But judging by the thread Sprow linked to, nobody seems willing to take on the responsibility of being an official maintainer.

Ta. C’est la vie… ;-) Slaps forehead in dismay…

More observations…

• RC16 start-up: the start-up screen I see is slightly pixelated. Whereas on my usual set-up (same system (Pi3B), different cards) its much clearer. I see the ROOL graphic at the top of the screen and white text on a black background at the bottom.
• The view of the desktop between my usual set-up and RC16 looks different. RC16 looks brighter when looking at a configuration window, for example Display settings. Whereas my usual set-up running the 14-Jun ROM looks more natural.

Or simply ask James to reword the licence to remove that specific restriction.

It made sense when there were maintainers to have an official copy and block broken clones and hacks.

However, many years down the line, it’s a restriction that is hurting Zap.

I’m purposefully ignoring that part of the licence, because it’s either ignore it or Zap dies with the RiscPC era.

There’s no point in keeping the “no mods” term, it’s not as if everybody is going to go fork Zap the moment that clause gets removed!

nobody seems willing to take on the responsibility of being an official maintainer.

I’ll do my best to fix bugs, but to be honest I don’t actually understand how a lot of it works.

Rick – at this point, I think it is more a case of someone taking a responsibility for it, rather than understanding it intimately. Other people can get intimate with it if they wish, so long as someone active is willing to accept the project as a whole. It looks like that “somebody” needs to be someone with an understanding/experience of git though (narrows it down somewhat). They can then push through a re-licensing and others can take the code on from there.

with an understanding/experience of git though

Why?
I ask because I have no clue about Git, I didn’t get most of my code from Git (didn’t even know it was there until somebody pointed me to it for something else) and the patches I’ve applied came from random zip files and forum posts. And the Rick “ultimate edition” ¹? It’s a zip file. So can the sources be if anybody is interested.

Okay, I’ll grant you, source control makes sense when there are multiple maintainers, but…. that’s a bridge to cross when the need arises.

Besides, given it’s a much simpler project than an OS, wouldn’t CVS suffice? We already have a suitably competent client, it’s nowhere near as overcomplicated as Git, and something that I would absolutely demand (if being involved with it myself) is that it be fully visible/useable on NetSurf. GitLab fails badly in this respect (while the older CVS was fine).

They can then push through a re-licensing

Just a tweak to remove the “no mods” wording. It would be nice to have the project come under a recognised, open, non encumbered ² licence but making changes like that will require the agreement of all the copyright holders, reciprocally through all of the extensions and add-ons. Best not to poke that with a stick…

¹ Yes, urine is being extracted.

² These two words added to discount GPL.

Why?

Probably because the suggestion was that the lucky new owner would get given the keys to the Git repository…

Okay, I’ll grant you, source control makes sense when there are multiple maintainers, but…. that’s a bridge to cross when the need arises.

No, it’s a bridge to cross now, otherwise we return again and again to the current situation, where we have Zap-tnk, Zap-tim, Zap-Ultimate, Zap-whatever…

Besides, given it’s a much simpler project than an OS, wouldn’t CVS suffice?

If you were going for “not Git”, you would probably use Subversion these days. CVS has too many restrictions and issues to be a sensible choice for a new project.

Besides, IT’S IN GIT NOW. Use Git.

Just a tweak to remove the “no mods” wording.

What if that option isn’t on the table?

but making changes like that will require the agreement of all the copyright holders

That may well apply to removing the “no mods” wording, too.

It looks like that “somebody” needs to be someone with an understanding/experience of git though (narrows it down somewhat). They can then push through a re-licensing and others can take the code on from there.

OK, serious question: if someone were to approach James and attempt to coordinate this, is anyone actually genuinely serious about updating Zap at all?

Besides, IT’S IN GIT NOW. Use Git.

Why? The next guy who will maintain Zap will probably be alone
So she/he will choose.

OK, serious question: if someone were to approach James and attempt to coordinate this, is anyone actually genuinely serious about updating Zap at all?

Good question :)

Why?

Let’s break that into two questions.

“Why use version control?”. Because the reality now is that Zap is more likely to become a project patched by its users rather than developed by any one person. In four years, no-one has come forward in response to James’ post, and that itself was many years after the last serious update. If there was someone out there, they would have stepped forward by now.

In the meantime, we’ve had numerous guerilla updates, which have become a mess to keep track of.

And if, in the future, the new maintainer’s interest dies out again, having the code in a public repository means that others can still pick it up at some point¹ even if the maintainer can no longer be contacted.

“Why use Git?”. Because it’s the best option for new projects, as it’s far better than even SVN at handling collaborative work. It looks scary, but if you take a short while to find out how it works (perhaps with a good graphical GUI), you’ll kick yourself for not learning it sooner.

The next guy who will maintain Zap will probably be alone

Why do you think that? Evidence so far is that no-one is maintaining it, but numerous people are patching it.

¹ To pick a topical example, if previous WinEd developers had taken the approach being espoused by Rick and yourself, we wouldn’t have had a “High Vector Happy” version this week. The reason we do is because the source was in a public version control system, from which I could download it, change it, and then commit the changes back. In fact, the last developer’s copy of the source is lost, which is why we can’t find out what WinEd 3.22a looked like.

“Why use version control?”. Because the reality now is that Zap is more likely to become a project patched by its users rather than developed by any one person.

Which means either:

• Somebody curates the modifications/patches into a master version and does some testing to ensure it doesn’t break things.

Or:

• Give a number of people access to patch the master version directly and hope for the best…

we’ve had numerous guerilla updates, which have become a mess to keep track of.

Generally… the most recent is the definitive. It’s also why I put together “Zap Ultimate”. You no longer need to get this from here, that from there, etc. It’s a full release that can be installed without the hassles of the guerilla updates.

“Why use Git?”. Because it’s the best option for new projects,

Until the Next Best Thing comes along.
Trust me, it will.
Programming languages are evolving constantly. Source control is the same, only more slowly.

if previous WinEd developers had taken the approach being espoused by Rick and yourself, we wouldn’t have had a “High Vector Happy” version this week

To neatly refute your nice example – Zap Ultimate is on !Store exactly because of the method of random zip files. It’s far from perfect and it sucks as revision control, but the code within was more up to date than the Git ones.
When I have time, I’ll look at the suggestion made by Julie… and anybody else if there’s a favourite pet quirk they’d like to patch… and then there’ll be another version on !Store.

Oh, and I eventually downloaded the code from Git because of something I didn’t appear to have. You know what I ended up with? A bloody great pile of files in an archive and not a single one filetyped.

The reason we do is because the source was in a public version control system available

There, fixed that for you.

I didn’t get Zap from any version control. But it exists because the source exists.
I didn’t get Ovation from any version control. But it exists because the source exists.
Repeat until bored.

The reason we do is because the source was in a public version control system,

Which, I suppose, was easy for you because you took something and fixed it.

What about when something has been taken, fixed multiple times, and the changes not fed back?

I’m not arguing against version control. Don’t get me wrong, it’s a good idea and it is certainly useful to be able to do things like “oh crap, this breaks stuff, let’s revert” as well as keeping an itemised list of what changed when, and if desired, showing actual differences between versions.

What I’m mostly arguing against is tools that do not play nicely with RISC OS.

To pick a topical example, your earlier message implies that you built WinEd on Linux…