Where do we discuss issues with Direct

Now why do think that was not intentional? The build was unecessary.

So say you! What is difficult for you to understand. Its not a different build of the OS, with extra software supplied as standard and a new Direct theme to help promote the OS to NEW users of the Os with a ready to run system.

I did not claim it was fork

Well I and others on that thread read your comment that you were claiming it was a folk. When its not.

We are trying to recruit new users to the OS, this is a way of promoting the OS and providing a wide range of software. Its been agreed the software provided needs tweaking. when the distribution is updated it will have no doubt an updated version of the RISC OS 5.27 as built by ROOL. You are not the primary intended user for this distribution.

You can update the OS as normal in Direct since its just 5.27 from January/Fabruary.

RISC OS is now truly open source and that allows anyone to use it how they wish – except sell it.

RISC OS Direct is a recent build of RISC OS 5 bundled with lots of useful applications that most new users of an modern Operating System may expect to come preinstalled.
It’s an initiative that will hopefully keep first-time users using RISC OS for more than 5 minutes before deciding that there is no Internet Browser, music player, document editors for RISC OS and installing another Distribution on their SD card for the Pi.

There are probably hundreds of Pi distributions that RISC OS needs to compete against. RISC OS Direct is a great first attempt at this. I’m looking forward to seeing how RISC OS Direct improves over the coming months.

b1. What is difficult for you to understand. Its not a different build of the OS,

Of course it is a different build. ALL versions of 5.27 are (and I quote) a Nightly beta development build. (Work in progress!)

Not the way to introduce a system to new users.

You are not the primary intended user for this distribution.

To be honest, I was quite happily plodding along with 5.24 until I was told on these forums (and I quote):

John S – not really sure why you don’t use the RISC OS Direct build as your main choice – it is intended for that purpose.

At the time, I had over 500 posts on these forums since September 2012.

Fortunately, only one server has been changed from 5.24. (apart from my use of a Pi 4)

Forum account deleted

except sell it.

Actually, you can.
There’s nothing in the Apache, bsd, or CDDL that prohibits selling. And the first two don’t carry an obligation to share/distribute modified sources.

Of course it is a different build.

I think we’re splitting hairs on what the word “build” implies. Yes, it is correct that every single day a new version of RISC OS is built. However, using that logic it’s also fair to say that there isn’t actually a single build of any of the stable releases either (the OMAP version is different from the Pi version is diff….).

What I believe was being intended by Chris’ post is to say that Direct isn’t taking “a version of RISC OS” and adding a bunch of tweaks and customisations that are not a part of the standard OS … and no, I don’t count a theme as being a fundamental customisation; I’m talking about stuff like, say, baking in LanMan98 or whatever and switching stuff around so it behaves differently.
They’re not doing this. It is essentially a version of RISC OS 5.27 at whatever date in time they picked, packaged up in what is supposed to be an easy to digest way.

Not the way to introduce a system to new users.

As I said before, 5.23 (dev) begat 5.24 (stable) which begat 5.25 (dev) which begat 5.26 (stable) which begat 5.27 (dev). It’s like the book of Genesis, isn’t it?

Anyway, the only real difference between a dev build and a stable build is that a dev build on a given date is not guaranteed to work. It can happen.

The benefit to using a dev build (one that works, of course!) is that it has twenty five months of development compared to the previous stable release. And it may be, even, that the last stable one won’t play so well with recent Pi firmware (it can happen).

I did not claim it was fork.

No, you were actually somewhat less polite: Did anybody test this lot? Have I made my point? None of us should waste any more time on this.

We’re supposed to be providing feedback to iron out the problems (such as the ones being uncovered here).

So either ditch Direct and stick with what you know, or provide constructive friendly feedback so the issues can be resolved. In either case, stop being so goddamn negative, as that is not the way to introduce a system to new users.

Anyway, the only real difference between a dev build and a stable build is that a dev build on a given date is not guaranteed to work. It can happen.

That’s not the impression one gets when one reads the information on stable releases, though.

There are a whole bunch of criteria, and for the past few rounds several platforms haven’t received a stable version because they didn’t meet the requirements.

Forum account deleted

Well done, Chris…

There are a whole bunch of criteria,

Well, sure. They don’t just bump the version number and call it stable. There are a number of things that need to be put in order when marking the release as a stable one. However, the stable, once released, is then version bumped and considered the next dev version. It’s not as if they’re different things, one progresses to the next which…. you get the idea. ;-)

several platforms haven’t received a stable version because they didn’t meet the requirements.

And with a delicious serving of irony, the Pi status is a big red dot. Though, understandably, that’s probably because of the Pi4….. ;-)

Well done, Chris…

Steve no one asked John to delete his account, I was just one of several people who pointed out he was being unnecessily negative about Direct, if he did not like it he could have just gone back to the default 5.27 or even back to 5.24 if he wanted – it was his choice. I was most certainly not hounding him as you claim.

He had a particular issue and a suggestion was made how he could fix it. I appreciate it should not be there in a ready to go distribution. I would expect it to fixed in the next planned distribution of Direct.

As one of the issues picked up from people using it.

With respect to the EDID issue reported, if ROOL had/have fixed something, it would have been extremely helpful to explain when/where, so that we can figure out whether it is the same bug or not. Unless it was fixed since Feb, I suspect quite strongly that it is something else, as yet undiagnosed/resolved, but in truth I’ve never (personally) tried EDID headlessly on any RISC OS system.

(To me) it would make a lot more sense to use the supplied RISC OS Direct MDF with headless, to ensure you are in a suitablely sized screen mode. I know that’s what all the “headless folk” I know do on their servers, let’s put it that way. It’s also (one reason) why I submitted a suitable MDF based on my iMX6 work for RISC OS Direct.

As Chris H pointed out, this is what I was referring to with regards to the request for helpfulness and politeness. It’s the difference between “It’s Crap!” and “It’s crap because of x, y, and z, but here’s how these can be resolved easily, or if they can’t be resolved, could you fix them please?”.

As to the issue of transparency, my comment would be that I (personally) feel unable to significantly contribute to ROOLs builds, either due to technical barriers, lack of understanding, or perceived roadblocks. In other words, I don’t think Direct is any more or less transparent than RISCOSpi etc. However, that doesn’t mean it can’t be better (and can strive to be), and I think the wiki/bugtracker approach could be very helpful. I can’t promise that every suggestion will be implemented, but we’d certainly welcome the input – I’ve said this all along.

However, it is (ultimately) a distribution from the guys who own the OS, for better or worse. We’ll do our best to include as many suggestions as possible, and utilise as much feedback as possible, but in the end the buck stops with RISC OS Developments and the guys putting together the project. We have to make judgement calls as best we can – no, we’re not going to include your 5-line “hello world” program, just because you upload it to the wiki. But, if you contribute a “how to create your own program” to accompany it, then that suddenly sounds (fractionally) more interesting.

Final point – the choice of OS build. There’s no right/wrong answer to this. It has to be 5.26 or later because of licensing. 5.27 has seen some show-stopper bugs fixed for Pi (notably the keyboard bug), which IMHO make it essential to use something newer than 5.26. That means we have to use some form of beta. It’s just a case of picking a point that seems as good as we can make it. The Feb build seemed/seems to meet those criteria from the relatively limited number of issues reported.

Edit – also, thanks Alan Robertson for your kind words – will pass them on to the guys here.

I recently decided to download RISC OS direct and RPCEMU (Pi4).

Whilst organising the folders I discovered that you cannot move the Graphics folder into the Apps folder, as when you do and reboot, it causes errors: “File ‘BootError’ not found”. It’s not the only folder that causes the issue. Has something been accidentally hardwired?

Whilst organising the folders I discovered that you cannot move the Graphics folder into the Apps folder, as when you do and reboot, it causes errors: “File ‘BootError’ not found”

It looks like there are two problems there – the one you are specifically asking about, and one it’s also bringing to light.

The folders that are causing you problems (or certain apps within them) are probably pointed at in the Configure → Boot → Add to / Look at sections.

The other problem is BootError. It sounds like that’s being issued as a command somewhere in the boot sequence (presumably, if my guess is right above, where the Add to/Look at things are handled). So either there’s something missing that defines that command, or it’s a mistake and the command being used should have been Error.

I think you will find that the backdrop is referred to in the boot process, either in relative or absolute terms (no other method exists). The backdrop image resides in the ‘Graphics’ directory. So that an error during boot is inevitable unless you update the location of the backdrop image.

The whole purpose of a hosted distribution is that it works ‘out of the box’. If you tinker with it and do not understand what you are doing, it is not surprising that you encounter errors. Any update will probably assume that things remain where they were put.

Adding sub-directories to Apps is not a good place to put data that you want to see. By design such subdirectories stay hidden from Resources.Apps and are not looked at during booting.

At the risk of stirring a hornets nest, I’m doing a little work to update Direct (hopefully in time for virtual London show). It won’t be the big update that I’d like, as there aren’t enough hours to prepare and test that. However, I’m trying to fix bugs where I can.

So far we have:

Latest Pi firmware

Fixed keymapper issue so that only Menu is remapped

Added text message during PreDesk to alert people to press Escape if startup stalls at DHCP phase (Pi Zero)

Fixed hard-coded disc name in PinSetup

Updated CAcertificates to recent version for ported SSL apps

Updated ReDHCP for modern platforms

Included RISC OS 5 user guide released since first RISC OS Direct

I am still hunting the BootError issue that Andrew McCarthy mentions – any detectives out there with an hour or two to spare would be appreciated. In the meantime I’ll focus on making sure !Boot is suitably up-to-date.

If there’s anything else that people would like fixing, now’s the time to say. Polite requests please, though – I’m trying to fit this in around a very full schedule.

Also, I’m trying to keep the download size down, as I know some people will want to update via PC/Mac, which means the RISC OS disc updates will need to fit in a zip on the FAT32 partition, which is only (I think) 64 MB.

Is it possible to get the very early stage of initialisation, i.e. before RISC OS even initialises, to put a simple splash screen on the monitor?

I think if one re-compiles the OS, it is possible to change the green RISC OS loading image. Don’t think before that. I’m not quite sure how the boot image system works (BootFX module) but I agree it’d be nice. Not sure if there’s time to investigate that rabbit hole (for me at least) but yet, I’d be curious.

Added text message during PreDesk to alert people to press Escape if startup stalls at DHCP phase (Pi Zero)

As long as the information doesn’t prompt them to press anything in less time than the standards default timeout of 62 seconds.

I am still hunting the BootError issue that Andrew McCarthy mentions – any detectives out there with an hour or two to spare would be appreciated. In the meantime I’ll focus on making sure !Boot is suitably up-to-date.

Background: Whilst re-organising applications, moving them into the Apps folder and restarting the Pi, I discovered the BootError.

On my Pi3 I can reproduce a version of the error by moving !DPIngScan to the Apps folder.

Whilst re-organising applications, moving them into the Apps folder and restarting the Pi, I discovered the BootError.

Choices.Boot.Desktop contains this :-

IfThere Boot:^.Graphics.!DPlngScan Then Else BootError Add to Apps: Could not locate 'Boot:^.Graphics.!DPlngScan'

This line is obviously invoked if !DPlngScan is moved. There is no BootError command or file, I think it is a ROL-ism. Substituting Error for BootError does give the intended error message. But why do this at all. Having moved the app this error will occur on every start up. A number of other apps are also locked in place by this mechanism.

Why is Choices.Boot.PreDesktop of type Desktop, should it not be Obey.

Lastly StrongED needs to be 4.70a14 to accommodate a 4GB or larger RPi4.

HTH.

It’s nice to see that there’s an update for the RISC OS Direct distribution on the way. Especially the software compilation of RISC OS Direct and the easy installation helped a lot of people recently to get involved in Risc OS again.

But what I think is clearly missing is just a note somewhere on the web page (https://riscosdev.com/direct/ and https://www.riscosdev.com/projects/) on the status from what date the ROM or RISC OS (including what version) is included and some general date on updates in that respect.

Whilst re-organising applications, moving them into the Apps folder and restarting the Pi, I discovered the BootError.

On my Pi3 I can reproduce a version of the error by moving !DPIngScan to the Apps folder.

Short answer – don’t move them to the Apps folder.
There’s a nice item in Configure to do that for you. (Virtually)

Click on !Boot then click on Boot in there.
Then, click on “Add to Apps” and drag your Application icon from the folder it normally sits in (which you may call “MyOtherApps” or whatever) and drop the icon in the left panel of “Add to Apps”.
Click the “Set” button and close all the windows you just opened.
Reboot.

The Apps folder is the correct place for them.

Short answer – don’t move them to the Apps folder.

One of the things I like most about RISC OS is the fact that you can (usually) put an app wherever you like, and organise things in whatever way suits you. It seems like a backward step to be forcing users to keep apps in a particular place, and pop up errors when they try to move them, unless there’s a very good reason.

The Apps folder is the correct place for them.

It’s a place for them. :-)

It seems like a backward step to be forcing users to keep apps in a particular place, and pop up errors when they try to move them, unless there’s a very good reason.

The “locked in place” apps such as DPlngScan appear greyed out in the Configuration tool, the entries are hardwired in the Desktop file. If an ‘Add to Apps’ is set using the Configuration tool then that setting is written to the PreDesktop file.