RISC OS Distributions, Why, Good/Bad

That’d be a breaking change, and many packages aren’t actively maintained. Just look at the number of red triangles.

in most cases actually no, I have tested quite a bunch of them and they work fine in different directories. The issue seems to be the the packaging was a bit sloppy and the packaged did not configured the required field correctly, I’ll post more details in the dev-team forum on the ROC.

I changed over to using https:// for the ROOL repos quite happily.

Please check the state of security of that “https” that you’ve just used :(

https://observatory.mozilla.org/analyze/packages.riscosopen.org

For the non-security folks: > THIS SITE USES AN UNTRUSTED OR INVALID CERTIFICATE <

Am I making more sense now?

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.

Thanks for your suggestion, we can add this very comment to it :)

See? it’s easy to improve.

[Edit: Stuart added the change you have requested and submitted a PR, you are tagged as the reviewer, so you can help me to check if that is exactly what you had in mind, please review, thx ]

Please check the state of security of that “https” that you’ve just used :(

I’m not sure how relevant that is, given ROOL is trying to support RISC OS users who may be running older RISC OS browsers. It gets a B from Qualys and that’s because it’s marked down for supporting TLS 1.0 and 1.1. I’m not au fait on what RISC OS browser supports what, but I’d be unsurprised if some older ones don’t work with newer TLS. packages.riscosopen.org is a different server from the main site, but there’s a good argument that a weaker cipher and some less strict settings are a lower risk than shutting out some RISC OS users completely.

Edit:

For the non-security folks: > THIS SITE USES AN UNTRUSTED OR INVALID CERTIFICATE <

Not really. It’s a Let’s Encrypt certificate. It looks in date. What’s wrong about it? Mozilla don’t appear to have the root CA certificate, which is odd. I am viewing the site in Firefox and that says ‘Connection secure’. What’s the problem?

Not really. It’s a Let’s Encrypt certificate. It looks in date. What’s wrong about it? Mozilla don’t appear to have the root CA certificate, which is odd. I am viewing the site in Firefox and that says ‘Connection secure’

Humm weird, it seems to have issues on certain pages and no issues on others… Do they have some weird redirect to “riscosopen.com”????

packages.riscosopen.org is a different server from the main site, but there’s a good argument that a weaker cipher and some less strict settings are a lower risk than shutting out some RISC OS users completely.

Not really. !PackMan works fine with TLS 1.2 and secure configurations. packages is a separate site and doesn’t need to redirect to www, so There is no need to be retro’.

Please check the state of security of that “https” that you’ve just used :(
https://observatory.mozilla.org/analyze/packages.riscosopen.org
For the non-security folks: > THIS SITE USES AN UNTRUSTED OR INVALID CERTIFICATE <
Am I making more sense now?

It doesn’t say that for me, and when I check the certificate in Firefox it tells me the site has a valid LetsEncrypt certficate.

I’ll grant you that the rating of F on on the Observatory isn’t great and some of those issues could easily be improved, but if you discover issues like this, you would be much better advised to e-mail the relevant system administrators, i.e. packages@riscosopen.org in this case, rather than posting a message here and hoping that someone who can do something about it happens to notice.

@ James,

I’ll grant you that the rating of F on on the Observatory isn’t great and some of those issues could easily be improved, but if you discover issues like this, you would be much better advised to e-mail the relevant system administrators, i.e. packages@riscosopen.org in this case, rather than posting a message here and hoping that someone who can do something about it happens to notice.

Thanks, maybe it’s worth saying that this email address should be added to the “Contact Us” list for who finds issues with the packages/package website.

But thanks for sharing the email.

I’ll email you with the list of issues I have found. In more general terms, my post were in answer to others posts, not necessarily am official report of issues found to ROOL ;)

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

Would that be this Steve?

http://www.kappa.me.uk/Miscellaneous/swAppUtils023.zip

It’s registered, and everything. ;-)

my App Filler provides a utility that can be enabled via configuration, to scan ALL Apps in $.Apps and automatically add them to ResourceFS.

I am slightly confused – RO has done this ‘forever’. Or do you mean sub-directories as well?

Or do you mean sub-directories as well?

Yes I mean sub-directories as well and recursive search. 20 lines of code at the most? XD

The usefulness is that it’s optional, so people who do not want it, do not enable it and people like me who wants it just enable it.

Next I am working to have a way to either allow category names to come from the sub-directories OR (optionally) have them configured manually by the user. So, users with “I want my own categorisation” will be able to do that and The developers who uses PackMan categorisation can still use it.

As soon as it’s stable enough I’ll publish it on GitHub, so whoever wants to help can help making it even better :)

I am slightly confused – RO has done this ‘forever’. Or do you mean sub-directories as well?

I don’t really see the point of the Apps icon opening Resources:$.Apps, now that most apps aren’t ROM apps. Why doesn’t it open Boot:^.Apps instead? And then make some shortcuts in there for the remaining ROM apps (mostly !Edit), rather than making shortcuts for dozens of apps in ResourceFS?

We do have some odd categories in PackMan; PipeDream and Fireworkz Manuals seem quite lonely. I have had people complain that they couldn’t find the installed documentation as they had never looked in the Manuals dir.

Why doesn’t it open Boot:^.Apps instead? And then make some shortcuts in there for the remaining ROM apps (mostly !Edit), rather than making shortcuts for dozens of apps in ResourceFS?

This. + + + +

I don’t really see the point of the Apps icon opening Resources:$.Apps, now that most apps aren’t ROM apps. Why doesn’t it open Boot:^.Apps instead? And then make some shortcuts in there for the remaining ROM apps (mostly !Edit), rather than making shortcuts for dozens of apps in ResourceFS?

Theo, my code can obviously open Boot:^.Apps and read it. However, if a user add an app to “Apps” using !Configure, the actual command used to do that seems to add it to ResourceFS:$.Apps

So, if I go my own way, people who wants to manually configure “Add to Apps” via Configure will not have a way. While right now it works in perfect harmony with what a user has done via !Configure.

If you have the request to also add a direct load from Boot:^.Apps, I’ll add it to my TO DO list and as an option.

Totally happy to do that, if people wants to have this feature :)

This. + + + +

ok I guess I have multiple votes already for this lol :)

Guys,
can I make one request pleaseeeeeeeeee? Can we move the discussion about my App Filer replacement to the appropriate topic? Ideally I would ask people to open issues on the ROC on GitHub, so I could trace things easily (yeah as every software developer I am a lazy axx), but I do understand people may not be familiar or have a github account. So, at least on here is it possible to use dedicated topics? Even new ones in wish list if you prefer, as long as it’s easy for me to track the requests, please :)

Why doesn’t it open Boot:^.Apps instead?

Andrew Booker’s AppsClock has been available to do this for a couple of decades.

http://www.ajb121.net/riscos/apsclk.zip

It will even produce pseudo-apps.

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

I said “basically”. I know there are branches for the kernel and other funny things. But we are far away from a complete fork a la Android, since almost anything done can be replicated on another distro. Now, we all know there are different levels in what a distro change.

Because, let’s say, Red Hat Kernel 4.14 will react differently than Vanilla Kernel 4.14.

It shouldn’t. If it’s the case, you can raise a bug ticket.

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)

But once again, nothing you could not install on other systems.
There are not incompatible, and when the same applications and versions are used, there are mostly (exclude security patch back porting) based on the same source code.

Apache 2.0 doesn’t warrantee this.

All the BSD systems proved that while it’s a challenge, it’s not a dead end.

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 was the CTO of a company that did edit a Linux distro. So my view on this is a bit personal :)

Would that be this Steve?
It’s registered, and everything. ;-)

Thanks Steve.

Next I am working to have a way to either allow category names to come from the sub-directories OR (optionally) have them configured manually by the user.

Hint: packages installed with PackMan define a section value. It could be used to sort applications… A simpler way would be to integrate a launcher in PackMan!

Hint: packages installed with PackMan define a section value. It could be used to sort applications… A simpler way would be to integrate a launcher in PackMan!

That would be a bit the other way of the RISC OS way. But if you like to run PackMan for everything included running a simple utility.

However, I have never seen people running apps with YUM, Zypper, APT … just a thought…

Direct targets the Pi, and others for certain machines will target those machines.

And a modified version of Direct is what sits as a prepackaged item on the RPCEmu site and runs happily with an IOMD ROM as part of the setup.
Some included software requires features not present in the IOMD ROM / virtual hardware

Not really. It’s a Let’s Encrypt certificate. It looks in date. What’s wrong about it? Mozilla don’t appear to have the root CA certificate, which is odd. I am viewing the site in Firefox and that says ‘Connection secure’. What’s the problem?

The problem is certain locations have a reference to the old cross signed intermediate certificate that expired on September 30th
A quick search for “Let’s Encrypt September 30th” will get you list of links but this one is the horses mouth so to speak.

PS. Checking with the observatory link actually uses SSL Labs for the main scan, SSL Labs don’t hold their own certificate repository but use the Mozilla site cache
SSL Labs says this at the bottom of a scan result with trust problems:
For a time I think SSL labs was putting up fails for Let’s Encrypt certs with this cross-signing because the Mozilla cache was using the old cross sign.

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.

It’s certainly a good thing, but the primary reason for GPL in Linux land is because GPL only plays with GPL.
Without jumping through a lot of weird hoops (and even that’s not guaranteed), you literally have no other choice.

that makes it sounds like it’s a fact and not just your personal opinion.

That’s not how the internet works these days. You’re supposed to tell the world, in complete seriousness, that your Jamaican cousin’s best friend’s uncle had the Covid vaccination and his testicles exploded, therefore vaccinations are Not Good.

but it’s a dangerous assumption that ones without that flag are happy to be dragged elsewhere.

Except for system resources that might need to go in a specific place, doesn’t the idea of an app breaking because the user put it “somewhere else” rather wreck something that’s good about RISC OS?
The app should use relative paths set up from Obey$Dir and it really shouldn’t give a flying flamingo where it is actually installed.
[except maybe PipeFS, I’ll allow that ;) ]

Would that be this Steve?

I dunno, there’s so many it gets confusing.

http://www.kappa.me.uk/Miscellaneous/swAppUtils023.zip

Yup, that’s the one! 😀

rather than making shortcuts for dozens of apps in ResourceFS?

I don’t know about you, but I have a lot of crap in $.Apps as that’s, well, where the apps go.

The Apps thing is useful because I can present a sanitised version of the apps I use daily, as well as pulling in things in other places (Printers, ChangeFSI, etc) that I want easy access to.

as a prepackaged item on the RPCEmu site

Ah, well, it’s been forever since I’ve looked at the RPCEmu site, since the current builds no longer work on XP.

But…

Some included software requires features not present in the IOMD ROM / virtual hardware

Oh, whoops!

You’re supposed to tell the world, in complete seriousness, that your Jamaican cousin’s best friend’s uncle had the Covid vaccination and his testicles exploded, therefore vaccinations are Not Good.

Anti-masker: Masks cause disease – my husband went on a weekend conference where he had to wear a mask, and now he has Chlamydia…

Oh, whoops!

There’s a fair shovelful of software overall, fully testing everything for backward compatibility would be a major pain.

That would be a bit the other way of the RISC OS way. But if you like to run PackMan for everything included running a simple utility.

However, I have never seen people running apps with YUM, Zypper, APT …
just a thought…

That’s not the idea. The idea is to merge the launcher and the package manager. We should not have to launch an utility, search and install software, each time we need to make something new.

IMHO, we should be able to search new software from our software list (as on Windows 10), then to launch it directly (in a temp VM for example, for security, as with Zero Install Injector), or to install it (AKA, keep in cache) with a simple click on a star, to put it in our favorite list.

It could fit well with your launcher, and your VM ideas. Of course it would need an hypervisor, software (based on ADFFS?) or hardware. And a Unity feature for the Wimp (based on DeskWatcher?).

The idea is to merge the launcher and the package manager.

Ok so, I am not sure I understand what you mean by merging the launcher with the package manager.

The way it works now is that you can search for an app using the search engine in the launcher (this can also be done by drag and drop a string in the writable icon BTW, for example from a web page). If the app is not already installed, then you can click on the PackMan icon and that will start PackMan and also open its main window.

In the future, I hope I can also send a message to PackMan to automatically trigger the app search, so, in the end, for a user it will be just a single click on the PackMan icon on the Launcher. Which also identify a clear intent to find and install such an app or, at least, dig more into it.

That is already more than macOS can do and wants to do. Windows offer a bit more, but that has a price (privacy). For instance on RISC OS this whole process will NOT spy on the user habits as it happens on Windows when using cortana search and it’s already more features offered than macOS/Linux Desktop.

So, I think, it’s plenty of improvements over the existing “desktop use experience”. On Windows the initial search may already include searching the web (as MS calls it), but merging physically the Launcher and the Package Manager will result in an even more heavy app which also defeat the purpose of RISC OS Architecture (smaller separated components working together as one with the OS blending in as part of the application).

It could fit well with your launcher, and your VM ideas.

To lunch an app in a container will take a while, for now I am focusing on getting RISC OS working in a stable enough way on an hypervisor (which means implementing full virtualisation), but yes the future will have (if feasible with WIMP integration) the user able to decide if to run an application in an UNTRUSTED or if in a TRUSTED way.

- UNTRUSTED means the app will be executed in a completely isolated form, within a new VM, with (hopefully) a stub RISC OS ROM image that allows the main VM to redirect mouse, keys, WIMP events to the isolated VM (everything else is left untouched in RISC OS).
- TRUSTED means traditional way, so within the main RISC OS VM.

However, it will take me a long time before being able to deliver the untrusted form, hopefully things will get easier as I progress.