RISC OS Distributions, Why, Good/Bad

the feedback is extremely confusing (at least to someone that is not British I guess).

Oh, the feedback would be equally confusing to the British. The only difference is that the British are very, very used to being confused. No, they don’t like it, but they don’t notice it because they don’t know anything else. They don’t know how horrible it is because it’s just life so far as they’re concerned.

They don’t know how horrible it is because it’s just life so far as they’re concerned.

Life’s not bad, could be worse…

8~)

Even if this involves setting up Direct, Fortress, 4té, etc. etc. repos where packages that may be found in those bundles live, just setting up PackMan on those systems to have that extra system-specific repo (for the cases where licensing might prohibit just stuffing it out on the web somewhere or in the standard RISC OS package sets).

I think there’s a good point here. The ‘distros’ are fine if you’re starting from scratch – they hit the new user market nicely (‘just download this SD card image’). But they don’t seem to do much for the existing user – if I already have a running system, how do I pick up the extra goodies that other distros are offering, or have the good bits from two distros? At present it looks like I download their SD image onto a new card, plug it into a USB reader, and copy stuff across. That’s not very friendly, and leaves me having to unpick what they did to port it to my existing setup. Unless that’s a thing I’m experienced with, the distro is no use to me. And that probably covers the majority of existing RISC OS users who already have a working system.

[There’s a group of what I might call ‘Linux distro dilettantes’ who just randomly try Linux distros until they find one that looks nice to them, without understanding that most of how they look and feel is superficial and trivial to change, while being ignorant of much deeper technical differences. The usual result is they end up on some obscure distro nobody has heard of, get stuck and find there’s nobody to help them out.]

Meanwhile if you make the component pieces available I can install the ones I want and it will dovetail with what I already have. If I want to try out the offerings from distro X, I just install the ‘X’ meta-package which pulls everything in, or I can download the pieces (and install manually if I prefer to do that).

The thing that does concern me is closed source platforms though. I understand that folks who port RISC OS to a new platform want to make a return on their investment, and that’s fine. But if I want to do development on the ROM for a platform that isn’t in the ROOL tree, I can’t if the source isn’t available. And that makes some of the newer platforms unusable for any development which might touch the OS.

if I already have a running system, how do I pick up the extra goodies that other distros are offering, or have the good bits from two distros?

Lots of the extra software in the so called ‘distros’ are available from !packman, !Store both of which are provided on the ‘distros’ to enable users to get other software or updates etc.. I think a few are from the riscosports website. By the way the ‘distros’ underneath are just the ROOL builds with a different theme to brand them.

The thing that does concern me is closed source platforms though. I understand that folks who port RISC OS to a new platform want to make a return on their investment, and that’s fine. But if I want to do development on the ROM for a platform that isn?t in the ROOL tree, I can’t if the source isn’t available. And that makes some of the newer platforms unusable for any development which might touch the OS.

What closed source platforms are you on about? I am not aware of any, if you mean say RISC OS Direct, its not closed source, its the standard Pi ROOL Build with extra software to help new users. Same for the Fourtress its the standard Pi ROOL build again with the RISCOSbits own theme, which you can change as you wish and optionally extra software.

Just to be clear again they are NOT distros as such they are simply the standard ROOL Pi builds with a specific theme for the pinboard etc. which you can change as you wish. Nothing underhand, its called marketing really using a different branded theme.

What closed source platforms are you on about?

The only thing I am aware of is the ARMX6 ROM which has some baked in changes to the USB stack that has not seen its way back to the actual sources as I understand there is a discussion about getting those changes baked in to the underlying sources it is built on and thats needs some up stream changes.

However there is a Wandaboard ROM available without those.

In addition I guess there is a grey area where say someone paid for access to RISC OS under the old shared licence scheme but paid extra not to say share their version updates back for a period, if at all.

In which case legally I guess the open source Apache licence does not superceed a prior commercial agreement on the old licence terms.

As usual, caveat is I might be talking cxxx :-)

What closed source platforms are you on about?

I’m thinking of things like the Pinebook or some of the Rockchip ports. Last time I looked for the source I couldn’t find it – it wasn’t in tree on Gitlab or in a public repo that I could find. I might just have overlooked it, however.

The only thing I am aware of is the ARMX6 ROM which has some baked in changes to the USB stack that has not seen its way back to the actual sources as I understand there is a discussion about getting those changes baked in to the underlying sources it is built on and thats needs some up stream changes.

OK I see where you are coming from, these are just some ‘alternative modules’ to allow better sound IIRC, they have not been added to the main sources, because ROOL IIRC wanted the changes feeding back to BSD people since it from that the USB stuff was sourced. The extra modules are available I believe from those who developed them.

I’m thinking of things like the Pinebook or some of the Rockchip ports. Last time I looked for the source I couldn’t find it – it wasn’t in tree on Gitlab or in a public repo that I could find. I might just have overlooked it, however.

Not sure about the Pinebook one (do you mean the ARMBook one), the Rockchip ones were I think being done by Cloverleaf, so that may not be accessible yet – up to Cloverleaf to let us in to their ‘secret’ work.

Not sure about the Pinebook one (do you mean the ARMBook one)

The hardware base of the ARMBook is the Pinebook, so they are – hardware-wise – the same thing. And based on an Allwinner SoC. To my knowledge, there is no source available. Despite the fact that you cannot even buy the Pinebook/ARMBook anymore, because R-Comp is sold out and production stopped in favour of the Pinebook Pro a long time ago.

Same for the mini.m, which is – again IIRC – not 100% compatible to the Wandboard (aka ARMX6). No source available.

And again IIRC, the S-ATA support on the IGEPv5 is also not available as source.

the Rockchip ones were I think being done by Cloverleaf

It is/was – again IIRC – a cooperation between Cloverleaf and R-Comp to get RISC OS running on Rockchip SoCs (at least the RK3399) mostly to get the Pinebook Pro working, and also for a Cloverleaf SBC system based on the Radxa RockPi 4.

You see a lot of IIRC above? That’s the result of absolutely lousy communication and intransparency in RISC OS world, powered by outdated and non-detailed websites. The most we seem to get is some hints in show presentations. Cloverleaf is the exception, because their stuff is easily researchable e.g. on Kickstarter.

I’m thinking of things like the Pinebook

When did the Pinebook come out, and also Mini.m, as I said if the licence was under the old shared source one then I believe that depending what you paid allowed you to not feedback etc.

Also the Apache licence covers off this potential, in part, as well as I understand it according to Wikipdeia..yes I know..and usual caveat. cxxx talking me rearrange as required :-)

“The Apache License is permissive; unlike copyleft licenses, it does not require a derivative work of the software, or modifications to the original, to be distributed using the same license. It still requires application of the same license to all unmodified parts.”

“Unless explicitly stated otherwise, any contributions submitted by a licensee to a licensor will be under the terms of the license without any terms and conditions, but this does not preclude any separate agreements with the licensor regarding these contributions.”

However it would be nice to have everything available and back in the source tree.

Just so people know the score, the Allwinner A64/Pinebook stuff is due to be fed back any time – it was agreed earlier this year, once John has the source ready.

mini.m is (AFAIK) just a compile-time flag on the i.MX6 build, all of which has been fed back.

I do try to ensure everything is fed back, and is kept open. Indeed, I think other ports have more closed elements than ours, at least once Pinebook is fed back. I’ll mention it to John again next time I speak to him – we haven’t discussed A64/pinebook for a month or two.

Hi Andrew,

Thanks for taking the time to explain the situation, it is really appreciated, given the varying elements that pull and occupy your available time.

And again IIRC, the S-ATA support on the IGEPv5 is also not available as source.

You’ve not RC’d, or forgotten since May 2018 at least.
The SATADriver and ADFS are the vanilla pair of modules.

It’s a shame Git doesn’t offer the clarity that the former textual products files did, they were a nice quick way to see what’s in a given download and could refresh Steffen’s memory at a glance.

You’ve not RC’d, or forgotten since May 2018 at least.

Never been more happy to be wrong. Thanks for the correction.

Playing the ball back, how about properly announcing such major improvements? Looking at Git commit history to find out those things seems a bit…crazy.

Because that’s publicity, and it’s like an unwritten rule – the RISC OS community, as a whole, must suck at publicity.

Well, look at various websites (as noted by the awards).

@ Andrew and Sprow

Thanks for letting the community know, if you guys are too busy and need someone to post this news for you, please let me know in an email with the exact phrase you want and I share on all the places for you. I am sure others can do that too if they know how to use the various socials.

I have full automation to spread a message, between twitter, facebook, mailing lists at zero human effort, and can also add a manual announcement here.

It is important to communicate, please keep doing it. Thanks.

Basically, Linux distributions are just a set of applications + a package manager. Vanilla kernel, vanilla code. Some variations, but – most of the time – no real fork. Android is different. It forked the Linux kernel.

Almost all RISC OS distributions provide a complete support of 32bit RISC OS applications, and every specific 32bit application could work on another RISC OS distribution.

Basically, we have:

• Closed source versions of RISC OS. Good point to pay for some porting effort (we can’t rely only on community, as we’re not enough), if and only if the source code is given back to community at a later point. I suspect all existing companies would like to do this, but simply lack of time and resources. That’s a challenge.
• Vanilla versions of RISC OS, quite standard, with (ePic…) or without integrated commercial software. IMHO, the more we’ll have these kind of distributions, the best it will be. They can all attract some specific people. For example, a specific distro for RPC users or some bundle with RPCEmu or other optimized for games, etc.
• Vanilla versions of RISC OS, with some experimental stuff. As the one from Paolo. Not a fork, but with some choices that could be complex to adapt to other distributions. IMHO, this is not for daily use, but that’s very interesting.
• OS based on non vanilla kernel. RISC OS Pico was in this category (boots to FAT partition, no WIMP, etc.). An it proved to be very popular. IMHO, that can be very interesting. If one day I make a game, I’ll probably sell it as a RISC OS application AND a ready to run disc image for Pi.

which should I pick?

For most people, ROOL one is the most visible. So no problem for me. In fact, I even regret ROOL do not promote the other distributions.

I think that system builders and integrators should endeavour to add software on top of the basic ROOL disc image by using PackMan wherever possible and not just pulling stuff in with scripts.

I don’t really like the multiple directories + fixed destination for apps. But it can be configured. The next RISCOS.fr distro could adopt it, but with some specific configuration. My problem is to choose between giving “Apps” the ability to show subdirectories, or to use partitions to separate code from data.

very old stuff, abandoned by the authors, so it’s unlikely to ever make it onto PackMan.

IMHO, some things lack in Packman – Subject moved to another thread.

Just to avoid confusion, as Chris says, the “distro” supplied with our machines is not a “distro”. It is the basic HD4, with a lot of curated software added for extra value (and some links to software that can’t be distributed, to save users wading through the internet for them!), plus a Theme and a Pinboard background

For me, what you describe is a distribution, in opposition to a fork.
And that’s good.

RISC OS Pico was in this category

But is this anything that normal RISC OS cannot do when configured appropriately?

Note, for my games, Pico is useless. IIRC, it doesn’t have FontManager.

I even regret ROOL do not promote the other distributions.

To be fair, Direct doesn’t mention the normal ROOL versions. ;)

It’s worth noting, by the way, that only the ROOL releases are system agnostic. Direct targets the Pi, and others for certain machines will target those machines.

In fact, Direct is a good example of why it would be good to have access to the underlying stuff that is used to create the distribution. What if you’d like to use Direct, but have a a Beagle or Pine-thingy?

My problem is to choose between giving “Apps” the ability to show subdirectories

Steve has a patch to make that happen. It’s very useful for organising Apps.

@ David

Basically, Linux distributions are just a set of applications + a package manager. Vanilla kernel, vanilla code. Some variations, but – most of the time – no real fork. Android is different. It forked the Linux kernel.

I am sorry, but I have to disagree with this definition of a Linux Distro. Few examples:

• Alpine Linux adds extra patches for security that are NOT part of the Vanilla Kernel
• RED HAT Linux adds what Red Hat calls “back ports” which are features back-ported from newer kernels to the kernel release they support.

There are more examples. Now when you port a Driver for a device to a Red Hat based distro (RHEL, CentOS etc…) you MUST consider the back porting process because, let’s say, Red Hat Kernel 4.14 will react differently than Vanilla Kernel 4.14.

Also certain distros comes with their own File Browsers and tools (Open Suse uses RPMs by the tool used to control them is Zypper, not Yum as on RedHat. newer redhat have migrated to a newer tool as well)

Also Distribution do tend to patch also the apps they package, the re-submission of the fixes depends mostly on the license, this is another reason why GPL is so much spread on the Linux land. GPL forces to share the changes done and present them to the original maintainers. Apache 2.0 doesn’t warrantee this.

So, while I am happy with people sharing their opinions and believes, and I encourage everyone to do so, please, please, please check the details before posting things using a language that makes it sounds like it’s a fact and not just your personal opinion.

I think that system builders and integrators should endeavour to add software on top of the basic ROOL disc image by using PackMan wherever possible and not just pulling stuff in with scripts.

I don’t really like the multiple directories + fixed destination for apps. But it can be configured. The next RISCOS.fr distro could adopt it, but with some specific configuration. My problem is to choose between giving “Apps” the ability to show subdirectories, or to use partitions to separate code from data.

For this, my App Filler provides a utility that can be enabled via configuration, to scan ALL Apps in $.Apps and automatically add them to ResourceFS. It works and will be demoed on next progress updates video.

For whoever is interested, there will be subdirectories and categories supported in my new App Filer:

• Directories can be drag and dropped on the filer main window. When clicked, will simply cause a filer open dir.
• Each single App can be added to one or more categories. Full categories support will come with release 2 (as agreed with the RISC OS Twitter community which has requested categories support). Discord community has requested other features too. Have ROOL forum community requested any features? Let me check in the appropriate topic…. Humm no, not even a comment except from Andrew, so why do you frustrated? You can simply ask ;)

I agree that !PackMan behaviour should be to allow the user to decide where to install an App unless the developer has strictly forbidden that. But has anyone contacted Alan for this? I am pretty sure he’ll be happy to add such behavioural change.
Alan has reported multiple times that he no longer checks this forum, so just by posting it here may not reach Alan’s ears ;)

For what concern what a distro should use: I strongly agree that distros should use !PackMan based installation and also provide well secured repositories on-line. One reason I do not submit my pre-built packages to ROOL is because ROOL is being sloppy at this and still uses HTTP protocol, so until they will change this policy and offer a proper service I will not submit my packages to their repository.

If someone will respond to my comment with: “but ROOL has no time, they need to bring food at their table”, please spare the nonsense, the process to secure nginx/apache takes like 1 hour at the most. If they have no clue how to do it, I am happy to help them to achieve that level of security.

But is this anything that normal RISC OS cannot do when configured appropriately?

Note, for my games, Pico is useless. IIRC, it doesn’t have FontManager.

Very good point Rick!

Why Pico is Pico only if people physically remove kernel modules???? I have quite a few Pico running, they are simply repackaged Vanilla RISC OS with certain modules unplugged and a typical BBC Micro CMOS Configuration.

RISC OS ROM image is so tiny that still beats any other Tiny Linux distro.

very old stuff, abandoned by the authors, so it’s unlikely to ever make it onto PackMan.

Again, with the RISC OS Community on GitHub we are also trying to contact old authors to get their sources to patch them for RO 5 and repackage them for RiscPkg. I also purchased a domain specifically for the RISC OS Community, which will become operative as soon as I have time to configure it.

Things are happening, people are using the RISC OS Community on GitHub and the community itself is growing. Things ARE changing.

Whoever wants to help is welcome, I am also trying to create tasks there for everyone and there are more people claiming them and pushing their changes.

Please, give it a go, have a look: https://github.com/RISC-OS-Community

If you want me to share the access and clones from each repo please let me know, I know a lot of you are using the community, github shows us the access and the cloning, so no need to be shy ;)

I agree that !PackMan behaviour should be to allow the user to decide where to install an App unless the developer has strictly forbidden that. But has anyone contacted Alan for this? I am pretty sure he’ll be happy to add such behavioural change.

That’d be a breaking change, and many packages aren’t actively maintained. Just look at the number of red triangles. Apps can already state that they are happy to be re-located at install time, but it’s a dangerous assumption that ones without that flag are happy to be dragged elsewhere.

ROOL is being sloppy at this and still uses HTTP protocol, so until they will change this policy and offer a proper service I will not submit my packages to their repository

I changed over to using https:// for the ROOL repos quite happily. When a rebuilt PackMan hits the ROOL repos, you won’t even have to have downloaded the CaCertificates package first.

Again, with the RISC OS Community on GitHub we are also trying to contact old authors to get their sources to patch them for RO 5 and repackage them for RiscPkg

It’d help to say things like the coding guidelines apply only to new code there, though. Nobody is going to prettyprint their source for submission.