Porteus

Could there be a designated place for portable installations, please? They don't have to be modules and a part of aufs union, especially if they are self-updating. I suggest to designate a "/portable" folder next to the /porteus on the ext4 partition. Of course it won't be permanent: /mnt/sda2/portable, mnt/sdb3/portable and so on. So, inside rc.local we need to mount -bind it to a permanent path, e.g., /home/user/P. After that, the user will place all portable, permanent stuff into that folder: outside an aufs union, no xzm to mount, no changes to overlay. I've been using such a setup successfully for many years, I wonder whether Porteus/X could officially designate a storage and a fixed path for out-of-tree stuff.

The user data and config can often be made portable too, further easing the pressure on the changes folder. For example, all AppImages can have adjacent AppImage.home and AppImage.config see https://docs.appimage.org/user-guide/portable-mode.html. Another example are web browsers that can specify the Profile folder location, e.g., where P is defined in rc.local as: and is a constant path for the portable apps. Whereas Interestingly, many apps (for example, Firefox) resolve their true path through a symbolic links and discover they are run from a different location. That's why it has to be a mount --bind type "hard" link.

As you can see I've chosen the portable folder to be next to the porteus folder on my USB/HDD. But it's also next to the porteux that I sometimes boot into! Thus, my portable installations, not only are taken out of xzm modules and out of the changes folders, but are also easily accessible from both porteus and porteux -- truly portable! The example of a web-browser (Firefox, Zen, etc.) illustrates the advantages of portable installations. They are constantly updating the user Profile folders, and quite often they self-update in-place! The alternative up to now has been (for a human!) to constantly produce newly updated .xzm modules for Firefox itself and keep constantly changing the rather heavy Profile folder inside /changes.

In the next post I'll talk about the system and desktop integration of portable apps.

I use my Porteus Optional folder for portableapps and create bash scripts in my /home/guest folder to activate them like this one. I do the same for modules I use occasionally like 05_devel.xzm.

Portable Apps still need to integrate into user/system CLI and GUI to be usable. We're going to have to find the .desktop, icons, and make a symbolic link in /usr/bin or /usr/local/bin. AppImages seem to include the .desktop and icons: Portable-Linux-Apps project extracts it like this: For other portable binary apps the .desktop and icons can be found from the corresponding .deb packages and so on. For the portable zen.linux-specific.tar.bz2 I took the integration from

ncmprhnsbl wrote: ↑

26 Aug 2024, 06:57

zen-browser-1.0.0-a.39-1-x86_64.xzm

-- thank you, ncmprhnsbl -- making a tiny zen-browser-integration.xzm that inserts those files into the correct places in the system. Of course, properly adjusted, e.g. I gather these little integration xzms into /P/portable-integration/ and merge them with porteux's (it's a bit buggy but works).

That folder /P/Modules is for the "portable" xzm modules common to both Porteus and Porteux. PorteuX will pick them up through a symbolic folder link in the /modules folder, Whereas, Porteus's BusyBox doesn't seem to support symbolic links (?) so we use the cheetcode instead: In the next post I'll talk about updating portable apps.

Examples of updating portable Apps (living outside the xzm+changes paradigm)

1. Self-updating: web-browsers, Telegram
User doesn't need to bother or even know the version number, it's always (modulo application restart) most recent. The App has to live in a fully uncompressed form.

2. Large multi-GB installations with their own component update managers: TeX, Conda. Fully uncompressed on a portable persistent file system path.

4. AppImages:
a) Self-updating (exotic, never seen)
b) Updateable with AppImageUpdate (rare, haven't found one that works)
c) Using the scripts from the https://portable-linux-apps.github.io/ framework. The manager itself is unfortunately hardcoded to install all AppImages under /opt, which in Porteus lives in an aufs union thus installed in the /changes folder essentially. But their huge database of update scripts, which isn't limited to AppImages, can be borrowed from.
d) Manually comparing the version numbers and downloading the newer AppImages.

5. Large multi-GB Software packages with annual updates: Matlab, Mathematica. They can be in the compressed form as SquashFS and mounted read-only on demand. They sometimes download extra stuff into the User's Profile folder which often can be portable as well.

So, in addition to the 2 locations where Porteus/X is conceptually stored on the disk: xzm modules and porteus/changes folder, I'm asking for an official extra storage path for portable "stuff", for example, the portable folder next to the porteus folder: which is always mounted to /P -- outside of any aufs union.

Is this a good idea? How/Where do users install (self-updating) portable apps otherwise? Having it as manually updatable xzm with possible /changes overlayed on top would be so cumbersome, no?

this seems to me like some things that magic-folders would handle fairly well:
http://www.porteus.org/component/conten ... lders.html
you set a target and a destination (and have as many as you want wherever you want) that are bind mounted (or loop in the case of a container(.dat) i think)