Exactly! Welcome to the Linux/Unix world.
Customizability of various distros
- Thread starter heyjudek
- Start date
Are you refering to "/root/my-applications" ?Technically speaking, yes; AppImages DO "run from anywhere". You can locate them anywhere in the system, click on them to launch and they will - generally speaking - just work. But even here, there's a "file-spec".....because without exception, they unpack themselves into, and run from /tmp for the duration. And /tmp is still a fixed, immutable location....
And they still create their .config files in fixed, 'expected' locations. You move an AppImage from one distro to another, and it will create a fresh set of .config files.....and even if you never use that AppImage in that distro ever again, those .config files remain behind.....just in case.
So you end up duplicating the same files, over & over again, ad nauseam. And THIS was the rationale behind my creation of Puppy's 'portable' apps; the app - AND its .config files - remain within a single, self-contained directory. You can move the portable app from one Puppy to another.......and the .config files move with it, since the launch script is written to set the self-contained directory AS the user's $HOME directory.
No more duplication.....and no need to have to set everything up again.
Mike.
I read that this is a standard system subdir with Puppy . I have installed and run tests on 22 different Puppy OS, and all have this subdir.
I now see your post "....because without exception, they unpack themselves into, and run from /tmp for the duration." So, two places recognized by Puppy OS. Your "AppImage" is an interesting concept.
Last edited:
@GlenE77is :-
Hallo, Glen.....and welcome to the best general Linux forum on the 'net..!
en.wikipedia.org
The official website is here:-
As James ( @Fanboi ) pointed out earlier on, although the idea is that they contain absolutely everything needed for them to run, they still have to work with the host system's kernel & glibc.....and none of them contain all the Xorg stuff required for a working desktop, since this is 'standard' to any distro.
In the early days, they weren't that easy to work with, either; lots of specialised binary utilities were required to create them/open up and edit them, etc. In more recent years, many of these utilities have been transferred direct to the command-line, so that they can be more easily extracted, worked on and re-built.
BUT; unless instructed otherwise, they still create their config files in the normal way, i.e., scattered throughout the system in the "standard" locations. The whole idea behind the Puppy-portables is to keep those config files together with the AppImage itself, in such a way that the self-contained portable directory can be moved anywhere and still work as soon as you fire it up.....without needing to set everything up again from scratch. In this way, a single 'portable' can often be shared between multiple Puppies, if run from a location external to those Pups.
(As an example, I 'share' a portable 64-bit build of the DeaDBeeF music player between half-a-dozen 64-bit Puppies.....and a 32-bit build between 3 or 4 older 32-bit Pups. And both builds share a common config file between them.)
Fredx181 - the current maintainer for the DebianDogs - did some research a few years ago, and discovered that the way they're packaged is essentially the same as the SFS files we're all familiar with in Puppy.....so he developed some scripts that would permit Puppians to build their own AppImages. One app I've done this with is OpenOffice. It comes as a whole collection of tiny little .debs - which all install to a single directory - but it makes creating a "shareable" package a bloody nightmare.
So I created the thing in a 'vanilla' live Puppy, then built the directory into an AppImage. Result? You just click on the AppImage, and OpenOffice launches, with all its config files just as you left them. In fact, I turned this one into a ROX-app, so a single click on the directory launches it; you don't even need to go into the directory to start it!
I used the XDG protocol as mentioned by @f33dm3bits a few posts back.....also mentioned on the Puppy forum by MochiMoppel during discussions about this stuff. Together with a 'read-link' clause in the launcher, this causes the app to 'see' its own directory AS the user's $HOME directory.....and it automatically creates all the config stuff within. Works a treat.
(As you must be aware by now, /root/my-applications/bin is a location totally unique to Puppy.....it's written into Puppy's /etc/profile file as standard. You won't find this anywhere else).
@heyjudek :-
Now I think about it, there is actually a protocol - provided within the AppImage build-specs - that will cause it to create its config files alongside it in whatever directory it resides in. I've only just remembered this; I'll have to do some digging in the Puppy forum archives, and see if I can't unearth the info for you. It may take me a while to find it!
Be patient. If I can find it, I'll post back in this thread.
Mike.
Hallo, Glen.....and welcome to the best general Linux forum on the 'net..!
Heh. Oh, I wish I could claim credit for this one.....but the concept dates back decades, almost to the very year Puppy itself was born:-
AppImage - Wikipedia
The official website is here:-
As James ( @Fanboi ) pointed out earlier on, although the idea is that they contain absolutely everything needed for them to run, they still have to work with the host system's kernel & glibc.....and none of them contain all the Xorg stuff required for a working desktop, since this is 'standard' to any distro.
In the early days, they weren't that easy to work with, either; lots of specialised binary utilities were required to create them/open up and edit them, etc. In more recent years, many of these utilities have been transferred direct to the command-line, so that they can be more easily extracted, worked on and re-built.
BUT; unless instructed otherwise, they still create their config files in the normal way, i.e., scattered throughout the system in the "standard" locations. The whole idea behind the Puppy-portables is to keep those config files together with the AppImage itself, in such a way that the self-contained portable directory can be moved anywhere and still work as soon as you fire it up.....without needing to set everything up again from scratch. In this way, a single 'portable' can often be shared between multiple Puppies, if run from a location external to those Pups.
(As an example, I 'share' a portable 64-bit build of the DeaDBeeF music player between half-a-dozen 64-bit Puppies.....and a 32-bit build between 3 or 4 older 32-bit Pups. And both builds share a common config file between them.)
~~~~~~~~~~~~~~~~~~~~~
Fredx181 - the current maintainer for the DebianDogs - did some research a few years ago, and discovered that the way they're packaged is essentially the same as the SFS files we're all familiar with in Puppy.....so he developed some scripts that would permit Puppians to build their own AppImages. One app I've done this with is OpenOffice. It comes as a whole collection of tiny little .debs - which all install to a single directory - but it makes creating a "shareable" package a bloody nightmare.
So I created the thing in a 'vanilla' live Puppy, then built the directory into an AppImage. Result? You just click on the AppImage, and OpenOffice launches, with all its config files just as you left them. In fact, I turned this one into a ROX-app, so a single click on the directory launches it; you don't even need to go into the directory to start it!
I used the XDG protocol as mentioned by @f33dm3bits a few posts back.....also mentioned on the Puppy forum by MochiMoppel during discussions about this stuff. Together with a 'read-link' clause in the launcher, this causes the app to 'see' its own directory AS the user's $HOME directory.....and it automatically creates all the config stuff within. Works a treat.
(As you must be aware by now, /root/my-applications/bin is a location totally unique to Puppy.....it's written into Puppy's /etc/profile file as standard. You won't find this anywhere else).
~~~~~~~~~~~~~~~~~~
@heyjudek :-
Now I think about it, there is actually a protocol - provided within the AppImage build-specs - that will cause it to create its config files alongside it in whatever directory it resides in. I've only just remembered this; I'll have to do some digging in the Puppy forum archives, and see if I can't unearth the info for you. It may take me a while to find it!
Be patient. If I can find it, I'll post back in this thread.
Mike.
Last edited:
It doesn't depend on distribution. Its a part of the concept of distribution itself. Dont think of it as of a platform for applications, think of it as of a single piece of software, that can update itself and install additional modules. Its just a black box.
If it doesn't fit you, just install you software not as a part of distro - Nix, AppImage, Wine ... Basically, you can use any distro and install the Nix package manager on it. And don't use Ubuntu-based distros, they are buggy and unfriendly.
When it comes to settings, home directory can be created anywhere. Just store your own files in other place and home dir will be used for distro settings only. It seems to be XY problem. The real problem is to separate data and settings and its not solved in linux.
If it doesn't fit you, just install you software not as a part of distro - Nix, AppImage, Wine ... Basically, you can use any distro and install the Nix package manager on it. And don't use Ubuntu-based distros, they are buggy and unfriendly.
When it comes to settings, home directory can be created anywhere. Just store your own files in other place and home dir will be used for distro settings only. It seems to be XY problem. The real problem is to separate data and settings and its not solved in linux.
Condobloke
Well-Known Member
Off topic....but......the best music player i have ever used. Simple and clean. No clutter
Looking forward to it.
Also, just curious, what I took from this is that a user can modify the configuration and installation directory of specific software, right? However, is it also possible to make software store its settings in a relative path? For example, wherever the appimage file (or any other type of software package) is launched from, it should take the config files from there. This way, one could have a truly portable program that can even work on a usb. I know most people probably don't care about this, but theoretically, could this be done?
@heyjudek :-
By using the XDG Base Directory specifications - combined with the use of a 'readlink' clause in a launcher script - you can trick any application into thinking that the directory it's in is in fact the user's $HOME directory.....and at first run, it will create all its config files inside that same directory.
Let me give you an example. Here's the 'LAUNCH' script tht I use for a Puppy-portable which uses the LibreOffice AppImage:-
The line starting with 'HERE' is the 'readlink' clause; this is what makes the application think that it's running from the normal /home/username directory, and writes the config stuff accordingly.
The clause as written above is a wee bit more complex than the standard read-link commands in the above-linked tutorial, though it's all very straight-forward Bash scripting stuff when it boils down to it. That command, as written, WILL establish ANY directory as the one relative to all the stuff going on inside it.
The next few lines tell the application which specific config directories to create:-
"XDG_CONFIG_HOME" will cause the app to create a primary config directory (this would usually be directly within the $HOME/.config directory)
"XDG_CACHE_HOME" will cause the app to create a directory within $HOME/.cache (if the application uses .cache; not all do)
"XDG_DATA_HOME" equates to stuff that would normally go into $HOME/.local/share
The last line there tells it that the $HOME directory is the one delineated by the readlink variable, i.e., 'HERE'.
In the above example, only the first and last lines are 'active', since LibreOffice AppImages typically create a single directory within $HOME/.config. For this reason, the other two lines are commented out, since LibreOffice doesn't write anything to either of these locations.
Following the specs here at the Arch Linux Wiki (an invaluable source for any Linux information):-
wiki.archlinux.org
.....you can add whatever further directories you know (or think) will be necessary. To be on the 'safe side', you CAN leave them all uncommented, if you wish.
A little-known fact with AppImages is that you can re-name them to anything you want.....make them much shorter, and easier to remember, and they will STILL fire up. The reason WHY this is possible with AppImages is simple; because the act of clicking on them transfers the executable action to a file inside named 'AppRun'; this is what actually launches the main executable binary within. The AppImage, as you 'see it' when you obtain it is nothing more than a container for the app contents inside it.
When you click on the 'container', this causes the 'AppRun' file to evaluate the contents, unpack everything to a one-time directory created FOR the session within /tmp, assess the specified locations for the expected config files (and create them if they don't already exist), followed by finally launching the app itself once it's satisfied everything is in place. This is why there is frequently a slight - but noticeable - pause with AppImages before you see anything happen; even with the speed at which modern processors function, all the afore-mentioned activity will take at least a couple of seconds to run through.
Hope that clarifies some of what we've been talking about. I haven't forgotten that spec stuff for the AppImage config creation; as & when I find it, I'll post back back here with the information. Just remember; real life often has to take priority over our favourite subject matter on this forum - in my own case, as a full-time carer for an elderly relative, it's highly unpredictable at the best of times! - so just be patient. I WILL find it, time permitting.
Mike.
This is what I was saying above.
By using the XDG Base Directory specifications - combined with the use of a 'readlink' clause in a launcher script - you can trick any application into thinking that the directory it's in is in fact the user's $HOME directory.....and at first run, it will create all its config files inside that same directory.
Let me give you an example. Here's the 'LAUNCH' script tht I use for a Puppy-portable which uses the LibreOffice AppImage:-
Code:
#!/bin/sh
#
# Launcher for 'portable' LibreOffice...
#
HERE="$(dirname "$(readlink -f "$0")")"
#
XDG_CONFIG_HOME=
#XDG_CACHE_HOME=
#XDG_DATA_HOME=
HOME="$HERE"
#
LD_LIBRARY_PATH=$HERE/:$HERE/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
"$HERE/LibreOffice64" "$@"The line starting with 'HERE' is the 'readlink' clause; this is what makes the application think that it's running from the normal /home/username directory, and writes the config stuff accordingly.
Loading…
www.baeldung.com
The clause as written above is a wee bit more complex than the standard read-link commands in the above-linked tutorial, though it's all very straight-forward Bash scripting stuff when it boils down to it. That command, as written, WILL establish ANY directory as the one relative to all the stuff going on inside it.
The next few lines tell the application which specific config directories to create:-
"XDG_CONFIG_HOME" will cause the app to create a primary config directory (this would usually be directly within the $HOME/.config directory)
"XDG_CACHE_HOME" will cause the app to create a directory within $HOME/.cache (if the application uses .cache; not all do)
"XDG_DATA_HOME" equates to stuff that would normally go into $HOME/.local/share
The last line there tells it that the $HOME directory is the one delineated by the readlink variable, i.e., 'HERE'.
In the above example, only the first and last lines are 'active', since LibreOffice AppImages typically create a single directory within $HOME/.config. For this reason, the other two lines are commented out, since LibreOffice doesn't write anything to either of these locations.
Following the specs here at the Arch Linux Wiki (an invaluable source for any Linux information):-
XDG Base Directory - ArchWiki
.....you can add whatever further directories you know (or think) will be necessary. To be on the 'safe side', you CAN leave them all uncommented, if you wish.
~~~~~~~~~~~~~~~~~~~
You may have noticed the name of the AppImage in the final 'exec' line. Normally, when you obtain AppImages they usually have a much longer and more complicated name, often including a version number and the 'arch' for which they're built.
A little-known fact with AppImages is that you can re-name them to anything you want.....make them much shorter, and easier to remember, and they will STILL fire up. The reason WHY this is possible with AppImages is simple; because the act of clicking on them transfers the executable action to a file inside named 'AppRun'; this is what actually launches the main executable binary within. The AppImage, as you 'see it' when you obtain it is nothing more than a container for the app contents inside it.
When you click on the 'container', this causes the 'AppRun' file to evaluate the contents, unpack everything to a one-time directory created FOR the session within /tmp, assess the specified locations for the expected config files (and create them if they don't already exist), followed by finally launching the app itself once it's satisfied everything is in place. This is why there is frequently a slight - but noticeable - pause with AppImages before you see anything happen; even with the speed at which modern processors function, all the afore-mentioned activity will take at least a couple of seconds to run through.
Hope that clarifies some of what we've been talking about. I haven't forgotten that spec stuff for the AppImage config creation; as & when I find it, I'll post back back here with the information. Just remember; real life often has to take priority over our favourite subject matter on this forum - in my own case, as a full-time carer for an elderly relative, it's highly unpredictable at the best of times! - so just be patient. I WILL find it, time permitting.
Mike.
Last edited:
Thank you. In the meantime, I guess that you probably wouldn't recommend doing this for a not-so-experienced user, I guess?@heyjudek :-
This is what I was saying above.
By using the XDG Base Directory specifications - combined with the use of a 'readlink' clause in a launcher script - you can trick any application into thinking that the directory it's in is in fact the user's $HOME directory.....and at first run, it will create all its config files inside that same directory.
Let me give you an example. Here's the 'LAUNCH' script tht I use for a Puppy-portable which uses the LibreOffice AppImage:-
Code:#!/bin/sh # # Launcher for 'portable' LibreOffice... # HERE="$(dirname "$(readlink -f "$0")")" # XDG_CONFIG_HOME= #XDG_CACHE_HOME= #XDG_DATA_HOME= HOME="$HERE" # LD_LIBRARY_PATH=$HERE/:$HERE/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} "$HERE/LibreOffice64" "$@"
The line starting with 'HERE' is the 'readlink' clause; this is what makes the application think that it's running from the normal /home/username directory, and writes the config stuff accordingly.
Loading…
www.baeldung.com
The clause as written above is a wee bit more complex than the standard read-link commands in the above-linked tutorial, though it's all very straight-forward Bash scripting stuff when it boils down to it. That command, as written, WILL establish ANY directory as the one relative to all the stuff going on inside it.
The next few lines tell the application which specific config directories to create:-
"XDG_CONFIG_HOME" will cause the app to create a primary config directory (this would usually be directly within the $HOME/.config directory)
"XDG_CACHE_HOME" will cause the app to create a directory within $HOME/.cache (if the application uses .cache; not all do)
"XDG_DATA_HOME" equates to stuff that would normally go into $HOME/.local/share
The last line there tells it that the $HOME directory is the one delineated by the readlink variable, i.e., 'HERE'.
In the above example, only the first and last lines are 'active', since LibreOffice AppImages typically create a single directory within $HOME/.config. For this reason, the other two lines are commented out, since LibreOffice doesn't write anything to either of these locations.
Following the specs here at the Arch Linux Wiki (an invaluable source for any Linux information):-
XDG Base Directory - ArchWiki
.....you can add whatever further directories you know (or think) will be necessary. To be on the 'safe side', you CAN leave them all uncommented, if you wish.
~~~~~~~~~~~~~~~~~~~You may have noticed the name of the AppImage in the final 'exec' line. Normally, when you obtain AppImages they usually have a much longer and more complicated name, often including a version number and the 'arch' for which they're built.
A little-known fact with AppImages is that you can re-name them to anything you want.....make them much shorter, and easier to remember, and they will STILL fire up. The reason WHY this is possible with AppImages is simple; because the act of clicking on them transfers the executable action to a file inside named 'AppRun'; this is what actually launches the main executable binary within. The AppImage, as you 'see it' when you obtain it is nothing more than a container for the app contents inside it.
When you click on the 'container', this causes the 'AppRun' file to evaluate the contents, unpack everything to a one-time directory created FOR the session within /tmp, assess the specified locations for the expected config files (and create them if they don't already exist), followed by finally launching the app itself once it's satisfied everything is in place. This is why there is frequently a slight - but noticeable - pause with AppImages before you see anything happen; even with the speed at which modern processors function, all the afore-mentioned activity will take at least a couple of seconds to run through.
Hope that clarifies some of what we've been talking about. I haven't forgotten that spec stuff for the AppImage config creation; as & when I find it, I'll post back back here with the information. Just remember; real life often has to take priority over our favourite subject matter on this forum - in my own case, as a full-time carer for an elderly relative, it's highly unpredictable at the best of times! - so just be patient. I WILL find it, time permitting.
Mike.
I am guessing that as I learn more about Linux, this feeling of uncertainty would go away. However, how do experienced users deal with this? Is there something like whereis command for any app packaging that would tell you where everything is located? To be honest, I would still prefer the freedom to choose those locations myself, but I can make do until I reach a point where I can customize these locations on my own without difficulty.
Mm. Heh. Puppy IS kind of a unique case.....even in the Linux world.
Y'see, we run-as-root all the time. A Puppy user is admin of his/her system at all times.....but you have to understand that Puppy is - first & foremost - a single-user system. She was never intended to be a multi-user system, like the mainstream distros, AND - in addition to this, is best described as a "hobbyist distro".......meaning that she was always intended to be the type of system where you can literally pull it to pieces, and re-build it to suit yourself if you're so inclined.
Most Linux users learn to do stuff in the file system via the terminal, and need to use the "sudo" mechanism in order to do so. Many never even look at their file-system, and build up a picture of how things work entirely through terminal commands.
We're a bit more Neanderthal than that! If we want to make any changes in the system itself, we simply open up the file manager, dive-in, and change/alter/move/symlink/delete things directly to suit ourselves (tasks which ROX-filer makes very simple, due to its drag'n'drop nature). I couldn't give anybody detailed instructions on how to do stuff via the terminal, because I've never been used to doing so.
To many, this all sounds incredibly dangerous.....but Puppy's modular nature, loading into RAM from read-only files plus the ability to back-up literally via copy/paste, makes her all but bulletproof.....and positively encourages experimentation. But don't think this makes us blasé, because it doesn't; it's as easy to "bork" a Puppy system as it is any other. You do learn caution, as administrator (like XP), and probably build up a far better understanding of just how everything works together than most. The difference is that Puppy is incredibly quick - and easy - to recover.....typically, perhaps 3-5 minutes.
No; I wouldn't encourage new users to try some of the above-mentioned stuff straight away. Not until they've had time to acclimatise to, and gain at least SOME understanding of how their new system works. The acquisition of new skills and knowledge doesn't happen overnight. There IS a "learning curve", although it's entirely down to the individual as to how steep they make it. Being naturally inquisitive & open-minded, as well as technically-inclined, probably helped to make my own transition a lot easier than for many others.
I was as green as grass when I first made the switch to Linux. I had to learn a lot of stuff all over again, and could never have imagined that 10 years down the line I would be doing any of what I now take for granted. Scripting, for me, was all about making my system more responsive and easier to work with; automating as much as I could, because in the long run it leaves me so much more time to do what I WANT to do.
I'll leave you with this advice; whatever else you do, don't EVER be afraid to experiment, and try things out. It's YOUR system after all; learn to make it do what YOU want it to do, in whatever way takes your fancy. Linux is endlessly versatile, as witnessed by the fact that it essentially runs the 'net, the IoT and most of the world's supercomputers.
And never, EVER be "afraid" of your system. You're in full control of it, after all. Breaking and re-installing is all part of the Linux experience; we've all been there. Learn from your mistakes; next time around, you'll know what NOT to do for a change. Before long, you'll be able to make your system sit-up, beg, get up and dance, even make you a cup of coffee AND bring it to you! (Well, maybe not that last one, but.....you get my drift).
Knowledge is incredibly empowering.....more so, in this increasingly technical world we live in. Mastery of that knowledge makes life so much more bearable.
Mike.
Y'see, we run-as-root all the time. A Puppy user is admin of his/her system at all times.....but you have to understand that Puppy is - first & foremost - a single-user system. She was never intended to be a multi-user system, like the mainstream distros, AND - in addition to this, is best described as a "hobbyist distro".......meaning that she was always intended to be the type of system where you can literally pull it to pieces, and re-build it to suit yourself if you're so inclined.
Most Linux users learn to do stuff in the file system via the terminal, and need to use the "sudo" mechanism in order to do so. Many never even look at their file-system, and build up a picture of how things work entirely through terminal commands.
We're a bit more Neanderthal than that! If we want to make any changes in the system itself, we simply open up the file manager, dive-in, and change/alter/move/symlink/delete things directly to suit ourselves (tasks which ROX-filer makes very simple, due to its drag'n'drop nature). I couldn't give anybody detailed instructions on how to do stuff via the terminal, because I've never been used to doing so.
To many, this all sounds incredibly dangerous.....but Puppy's modular nature, loading into RAM from read-only files plus the ability to back-up literally via copy/paste, makes her all but bulletproof.....and positively encourages experimentation. But don't think this makes us blasé, because it doesn't; it's as easy to "bork" a Puppy system as it is any other. You do learn caution, as administrator (like XP), and probably build up a far better understanding of just how everything works together than most. The difference is that Puppy is incredibly quick - and easy - to recover.....typically, perhaps 3-5 minutes.
~~~~~~~~~~~~~~~~~~~~~
No; I wouldn't encourage new users to try some of the above-mentioned stuff straight away. Not until they've had time to acclimatise to, and gain at least SOME understanding of how their new system works. The acquisition of new skills and knowledge doesn't happen overnight. There IS a "learning curve", although it's entirely down to the individual as to how steep they make it. Being naturally inquisitive & open-minded, as well as technically-inclined, probably helped to make my own transition a lot easier than for many others.
I was as green as grass when I first made the switch to Linux. I had to learn a lot of stuff all over again, and could never have imagined that 10 years down the line I would be doing any of what I now take for granted. Scripting, for me, was all about making my system more responsive and easier to work with; automating as much as I could, because in the long run it leaves me so much more time to do what I WANT to do.
I'll leave you with this advice; whatever else you do, don't EVER be afraid to experiment, and try things out. It's YOUR system after all; learn to make it do what YOU want it to do, in whatever way takes your fancy. Linux is endlessly versatile, as witnessed by the fact that it essentially runs the 'net, the IoT and most of the world's supercomputers.
And never, EVER be "afraid" of your system. You're in full control of it, after all. Breaking and re-installing is all part of the Linux experience; we've all been there. Learn from your mistakes; next time around, you'll know what NOT to do for a change. Before long, you'll be able to make your system sit-up, beg, get up and dance, even make you a cup of coffee AND bring it to you! (Well, maybe not that last one, but.....you get my drift).
Knowledge is incredibly empowering.....more so, in this increasingly technical world we live in. Mastery of that knowledge makes life so much more bearable.
Mike.
Last edited:
@heyjudek :-
Right. I can't find the thread about the config stuff on the Puppy Forum - why am I not surprised? - but this page will help. It's about running AppImages in 'portable' mode.....and is from the official AppImage user documentation:-
docs.appimage.org
See if that explains what needs doing.....'kay?
Do be aware of one thing. This is a spec that was added in 2017.....but not ALL AppImages are built to make use of it; much depends on the individual packager AND the application itself. In that respect, it's still rather "pot luck" as to whether this'll do what you want it to. If the particular AppImage isn't written to make use of this, these directories will remain empty.....and the config stuff will once again be written to the standard filesystem locations.
This was another reason I developed the 'Puppy-portable' method for working around this. I remember trying it out now.....AND discovering that, more often than not, it wasn't working. You couldn't rely on it.
This thread over at AskUbuntu may also clarify matters.
Mike.
Right. I can't find the thread about the config stuff on the Puppy Forum - why am I not surprised?
- but this page will help. It's about running AppImages in 'portable' mode.....and is from the official AppImage user documentation:-Using portable mode — AppImage documentation
See if that explains what needs doing.....'kay?
Do be aware of one thing. This is a spec that was added in 2017.....but not ALL AppImages are built to make use of it; much depends on the individual packager AND the application itself. In that respect, it's still rather "pot luck" as to whether this'll do what you want it to. If the particular AppImage isn't written to make use of this, these directories will remain empty.....and the config stuff will once again be written to the standard filesystem locations.
This was another reason I developed the 'Puppy-portable' method for working around this. I remember trying it out now.....AND discovering that, more often than not, it wasn't working. You couldn't rely on it.
This thread over at AskUbuntu may also clarify matters.
Mike.
Last edited:
I would suggest you get familiar with the whole linux ecosystem to some level before playing around too much with this kind of thing. Then you'll have some ideas of what you'd like to accomplish with your configurations and why you'd like to do it in a certain way. I've found that trying to keep things as simple as you can is the key to not shooting yourself in the foot too much. And then you can ask targeted questions to find out the best way for you to approach an issue. If a structured approach suits you, one useful book might be Shotts' The Linux Command Line, available for free online.
As some people have mentioned, often it's easier to use a GUI interface to modify configurations. But sometimes you really need to automate something and that's where the command line can really shine.
As another example, if you're only using linux on a single machine, then it's not so important to organize config files too much. On the other hand, if you have to keep copying config files from one machine to another, that will get old fast, and you'll look for a solution to that issue that suits your usage.
I myself use a lot of symlinks to keep disparate things in one place physically (easy to backup and transfer) but scatter them around logically to match the apps' expectations. Sometimes I use command line options to change where a config file is kept. In one case, I'm using an appimage (keepass on linux) to get a more up-to-date version than my Mint distro provides, to match the version of keepass I'm using on a macbook. You'll figure these things out as you go along.
As some people have mentioned, often it's easier to use a GUI interface to modify configurations. But sometimes you really need to automate something and that's where the command line can really shine.
As another example, if you're only using linux on a single machine, then it's not so important to organize config files too much. On the other hand, if you have to keep copying config files from one machine to another, that will get old fast, and you'll look for a solution to that issue that suits your usage.
I myself use a lot of symlinks to keep disparate things in one place physically (easy to backup and transfer) but scatter them around logically to match the apps' expectations. Sometimes I use command line options to change where a config file is kept. In one case, I'm using an appimage (keepass on linux) to get a more up-to-date version than my Mint distro provides, to match the version of keepass I'm using on a macbook. You'll figure these things out as you go along.
That is exactly what I am going to do. I don't think I would enforce these right now. This was more of a theoretical issue for me. I have many OCD-like tendencies when working with computers, or in general. So, in my head, it "feels" much better if I know that I can manipulate where a program is installed and where it keeps the configuration files, even though I may never actually change it. When I was in windows, it always felt icky for me when a program had to store files in some hidden directory in "Appdata" folder. I still have this aversion now. The ideal software for me is the one that needs no installation, can be run from anywhere and keeps the configuration files where it is run from. This way, I don't get into murky territory of where it is going to store what, without even asking me. This is why once eventually I get to "power user" level, I will probably switch to a distro with this philosophy. Is there a distro, where it is easier to customize these things? From my low-level research, I have heard that ArchLinux, NixOS and Gentoo seem to offer these things in some way, is this true?
I know what you mean about icky and Windows.
Since linux is a multi-user system, one thing you'll learn is that there is more than one level of configuration. There's at least the global (system-wide, for all users) configuration and there's the local (for yourself only) level of configuration. Certain commands (e.g. git) have other levels, too. So, it's not really possible to have all your configuration files in one place next to your command if you're going to use it as a multi-user system.
You can, of course, decide that that's the way you want it to work, for you. If so, you can go a long way to making that work with appimage files. I don't know of distros that make this the default. Maybe Puppy Linux, mentioned earlier?
Another consideration to think of is: what if you want to backup your personal configurations. Now they're scattered all over the place, next to your binaries, so it's a bit of a pain.
These are some of the trade-offs you'll encounter. You'll have to make decisions about what's right for you. My suggestion is to learn the "standard" system and by then it will be easier to pick which distro is right for you. In my case, because I have to use different servers of different flavors, I want a plain vanilla, everything-the-same system so I don't have to keep thinking about which environment I'm using right now when I do something. But your priorities may be completely different.
Since linux is a multi-user system, one thing you'll learn is that there is more than one level of configuration. There's at least the global (system-wide, for all users) configuration and there's the local (for yourself only) level of configuration. Certain commands (e.g. git) have other levels, too. So, it's not really possible to have all your configuration files in one place next to your command if you're going to use it as a multi-user system.
You can, of course, decide that that's the way you want it to work, for you. If so, you can go a long way to making that work with appimage files. I don't know of distros that make this the default. Maybe Puppy Linux, mentioned earlier?
Another consideration to think of is: what if you want to backup your personal configurations. Now they're scattered all over the place, next to your binaries, so it's a bit of a pain.
These are some of the trade-offs you'll encounter. You'll have to make decisions about what's right for you. My suggestion is to learn the "standard" system and by then it will be easier to pick which distro is right for you. In my case, because I have to use different servers of different flavors, I want a plain vanilla, everything-the-same system so I don't have to keep thinking about which environment I'm using right now when I do something. But your priorities may be completely different.
Yeah, I realize that Linux always assumes that it is a multi-user system, even though there is just one person using it. So, theoretically, it could be possible to have an app that have a single configuration directory regardless of which user is using it, but no one bothered to actually make it?
As you said, I am going to learn the standard system. For now, I am going through this book - https://www.amazon.com/Learn-Linux-Quickly-Friendly-Operating/dp/1712192795
It explains terminal from absolute zero. Is the fact that it is from 2020, be an issue. I reckon there shouldn't be any fundamental changes that would make this obsolete.
For me, the only upside of File System automatically managing this is that, in case there are two users, they will have their separate configurations, which is fine. Personally, I would rather personally manage my configuration files myself, because I would all put them into the same directory and separate the apps by different folders.
As you said, I am going to learn the standard system. For now, I am going through this book - https://www.amazon.com/Learn-Linux-Quickly-Friendly-Operating/dp/1712192795
It explains terminal from absolute zero. Is the fact that it is from 2020, be an issue. I reckon there shouldn't be any fundamental changes that would make this obsolete.
Certainly, because it likely wouldn't be very useful. Just don't read any configuration file except from some global configuration location. Then everyone gets the same thing. You'd actually have to work hard at this, though, because there are many sources of configuration, such as the command line options and environment variables, in addition to configurations stored in files.
Correct. The basics of linux are very stable and you won't see any changes there, except for perhaps some backward-compatible extra options being added. You could get far even reading a book on unix from 20 or 30 years ago. Linux is not a product being sold that requires constantly changing things in order to continue to pull in revenue. In fact, many, many people/businesses would get very upset if basic things were churning all the time. That said, there are constantly new things being added, but there's a lot to learn before you need to worry about that.
@jrw :-
Puppy doesn't make this the default, per se. But, unlike the majority of Linux distros, she was ALWAYS intended as - and designed to be - a single-user , "hobbyist" system. She was always designed, from the start (over 21 years ago), to be run from a flash drive.....NOT an internal HDD, though you can of course install her to your internal drive if you wish. It makes no difference to speed of operation.
I discovered AppImages several years ago. I always liked their 'portability', though I hated that they left config files & stuff hanging around, even if you only ever ran a given AppImage once (and never again). Since I'd grown used to using Windows PortableApps under Win XP, together with a few other Puppians we developed a way of combining the two in order to create a Puppy version of the Windows PortableApp.
I have no problems with keeping track of my 'portable configs'n'stuff. Like the PortableApp, the Puppy version keeps app files AND config files all the same directory. My extensive collection of Puppy 'portables' - over 150 of them at last count - all live together in the same large directory on a secondary data drive......and every single one has scripts for quickly linking/unlinking a Menu entry if one is wanted. Either that, or they can just be started from the built-in 'LAUNCH' script; in some cases, the Puppy-native ROX-filer FM has been used to make the entire portable directory executable.....so you simply click on the directory, and it launches.
I accept that such a set-up won't be to everyone's liking, but.......it all works very well for us.
Mike.
Puppy doesn't make this the default, per se. But, unlike the majority of Linux distros, she was ALWAYS intended as - and designed to be - a single-user , "hobbyist" system. She was always designed, from the start (over 21 years ago), to be run from a flash drive.....NOT an internal HDD, though you can of course install her to your internal drive if you wish. It makes no difference to speed of operation.
I discovered AppImages several years ago. I always liked their 'portability', though I hated that they left config files & stuff hanging around, even if you only ever ran a given AppImage once (and never again). Since I'd grown used to using Windows PortableApps under Win XP, together with a few other Puppians we developed a way of combining the two in order to create a Puppy version of the Windows PortableApp.
I have no problems with keeping track of my 'portable configs'n'stuff. Like the PortableApp, the Puppy version keeps app files AND config files all the same directory. My extensive collection of Puppy 'portables' - over 150 of them at last count - all live together in the same large directory on a secondary data drive......and every single one has scripts for quickly linking/unlinking a Menu entry if one is wanted. Either that, or they can just be started from the built-in 'LAUNCH' script; in some cases, the Puppy-native ROX-filer FM has been used to make the entire portable directory executable.....so you simply click on the directory, and it launches.
I accept that such a set-up won't be to everyone's liking, but.......it all works very well for us.
Mike.
