Porteus

Dear Porteus developer teams, I use porteus since to 3.0 version, now I using the new 5.rc3 version, ever in the mate desktop (for me mate is the linux standard desktop).

I've not words for describe my gratitude for this beautiful mode to use Linux; I love Porteus !!

Maybe Slackware isn't been the best choose as a base (I always watch Nemesis but isn't seems still mature as the Porteus standard), clearly I'm refer to packages installer.

It would be nice if someday it was available an converter from Flathub to Porteus module (package.xzm).

Meantime I use Appimage were is available ;-)

Thanks again
With love for Portus and Linux
Enzo

thanks for the praise.

Enzo wrote: ↑

19 Oct 2021, 10:39

Maybe Slackware isn't been the best choose as a base (I always watch Nemesis but isn't seems still mature as the Porteus standard), clearly I'm refer to packages installer.

the issue with package manager is a complex one.
I started my Linux path via Suse. Back then - Suse 5.2 & 5.3 - it took me days to finally configure email into it working, and a very short while later the Suse package manager deleted all my settings and setup files… prior me having made a backup. that frustrated me to no end - leading me to search for more stable even when harder to configure Linux → first Slackware → then Slax → finally going home with Porteus.

What is a seemingly more easy handling of dependencies worth when a Linux acts like Windoze by destroying user's personal data and/or settings?

Such destruction never even once happened with Porteus or Slax that I recall.

Hi everyone, the last week I have read anything interesting..very interesting; some time ago in this same forum, I had wrote: "It would be nice if someday it was available an converter from Flathub to Porteus module (package.xzm); Meantime I use Appimage were is available ;-)" ..
Good, now seems that an converter from Arch/AUR to Appimage are possible ... and then we can convert this Appimage (if want) in an Porteus module (package.xzm).
At the moment I've just changed my work, Iìve very poor freetime to play but maybe someone could make some test; I put the link (good read):

https://github.com/hanzala123/arch2appimage


Love Porteus, thanks again ..
Enzo

enzo73 wrote: ↑

19 Sep 2022, 08:04

Good, now seems that an converter from Arch/AUR to Appimage are possible ...

That is quite interesting indeed.

enzo73 wrote: ↑

19 Sep 2022, 08:04

... and then we can convert this Appimage (if want) in an Porteus module (package.xzm).

I presume doing so efficiently is more time-consuming.
You would want to leave out all already existing dependencies and only include the ones not in your system.
But that could result in a module that works in XFCE but not in Mate, or works in KDE only and not in any other DE…

I think such AppImage2xzm could even be automated, stripping all dependencies that are already in the system (usually a newer installed library should satisfy a program that needs an older version of the same library) - but even if someone would code such script, the resulting xzm would only work for sure for the very flavour of the DE the AppImage2xzm was initially executed under.

The plus side of AppImages is they run on almost all Linux variants. The downside of course is they often include many dependencies they need - that the Linux system you currently run already provides by itself.

If one loads a module that includes dependencies already installed doesn't the module's duplicate dependency simply overlay the one installed? Or does the new dependency get rejected because it is a dupe?

Ed_P wrote: ↑

19 Sep 2022, 15:23

If one loads a module that includes dependencies already installed doesn't the module's duplicate dependency simply overlay the one installed? Or does the new dependency get rejected because it is a dupe?

As I understand it, the module that got activated last overwrites files that previous activated modules provided.
Usually that is no issue…

Same when you mount another device onto the same mount path.
Just try that yourself. Say, you have /mnt/sda5 - and that is any kind of partition from your internal harddrive.
Now you could manually mount a USB thumbdrive there using - now when going to /mnt/sda5 you would only see the files and folders of your thumbdrive, and the ones from /dev/sda5 would be invisible and not accessible (as /mnt/sda5/*) as long as the thumbrive is also mounted there.
Of course the files and folders from /dev/sda5 are still there and are just fine, just not accessible as /mnt/sda5/*
And when you umount the thumbdrive, there would still be a device mounted as /mnt/sda5 - the original mounted /dev/sda5 - and now the original files and folders are accessible as /mnt/sda5/* once more.