Any drawbacks to running directly from the extracted tar? Topic is solved

[Lew Rockwell Fan]

Are there any disadvantages to running directly from the executable file after extracting the tar and storing in a filesystem mounted with exec permission?

I did that for a while on my last round of tinker-until-it-breaks and it SEEMED to work fine until, well . . . until it didn't. Then I opened it and half my ui customization was gone. Extensions were still there, but buttons I'd placed on tool bars had disappeared. Some of them I could add back, but others were not to be found. For that matter, I lost a whole tool bar & the add-custom-toolbar function ceased to to work.

But I don't know that it happened because of how I was running it. I tinker a lot. I break stuff a lot. I back up stuff a lot too, but sometimes not fast enough to keep up with the breaking. Mea culpa. Them's the breaks. (The nice thing about the internet is people who don't like puns can't throw stuff at you.)

Please correct me if I'm wrong: I percieve these advantages in running from the extracted tar:

1-I can put it in a file system that is accessible from all my 64 bit 'nixes (I n-boot, and n is large & variable) & not have to worry about synching bookmarks, cookies, passwords, and so on. Because they all run the same code from the same place and, AND HERE IS WHERE I MIGHT BE WRONG, store all the changes made, like extensions, prefs, & bookmarks, in the same place. Like "portable", but not "live" with a virtual fs overlay, nor semi-live with a persistence file, but instead - ordinary persistent changes made the same way they would be on an ordinary installed system - just kept in a different part of the file system.

2- It's really, really easy to back it up. Just gotta get sumbody to kick me so I remember. Consequently when I break it, it's easy to fix. Just rm -r that tree & cp --preserve=all the last backup to the directory name the link in my menu points at.

Am I missing something? Is there more likely to be a problem with stability or updating for instance? Or some other reason to prefer a conventional installation?

Thanks for your thoughts.

[Walter Dnes]

Running the same extracted tarball is not a problem.

AND HERE IS WHERE I MIGHT BE WRONG, store all the changes made, like extensions, prefs, & bookmarks, in the same place.

That's the problem. Profiles are stored in $HOME/.moonchild productions/pale moon/ and of course the definition of the $HOME directory changes with each linux instance.

And here's a preemptive answer to the obvious hack... what if you set up the same $HOME for all instances of linux? Don't... just don't. It gets really ugly really quickly.

• Different distros have different settings in user init files (~/.bashrc ~/.bash_profile etc etc). The "right settings" for one distro may be wrong for another one.
• Can you be certain that your user is assigned the same UID in all instances? If not, a regular user from one instance won't be able to change settings/files that a regular user from another instance wrote. And running regular applications as root is not recommended.
• screwing up a profile in one instance screws up that profile in all instances
• Plugins are stored in /usr/lib/mozilla/plugins which will be different for each instance

Your best bet is to regularly synchronize the $HOME/.moonchild productions directory. e.g.

• have a "central_location" that is mounted by each linux instance.
• at startup
  rm -rf $HOME/.moonchild\ productions
  cp -a <central_location>/.moonchild\ productions $HOME
• before logging off
  rm -rf <central_location>/.moonchild\ productions
  cp -a $HOME/.moonchild\ productions <central_location>/.moonchild\ productions
  (root/sudo privileges may be required here)

There is also https://www.palemoon.org/sync/ which can sync

• Bookmarks
• Open tabs
• Browsing history
• Form history
• Passwords
• Preferences (limited subset)

...subject to disclaimers, internet uptime, etc. The "limited subset" of preferences may or many not be a problem for you.

[Lew Rockwell Fan]

Thank you. That seems pretty definitive. OK, won't do that.

Running the same extracted tarball is not a problem.

AND HERE IS WHERE I MIGHT BE WRONG, store all the changes made, like extensions, prefs, & bookmarks, in the same place.

That's the problem. Profiles are stored in $HOME/.moonchild productions/pale moon/ and of course the definition of the $HOME directory changes with each linux instance.

And here's a preemptive answer to the obvious hack... what if you set up the same $HOME for all instances of linux? Don't... just don't. It gets really ugly really quickly.

Been there, done that. You are so right. UID & GID, etc. is easy enough to deal with, but it is still a bad idea. To my thinking, ~ is for config files. Doesn't need to be large, doesn't need to be shared. Data is another matter.

Although a shared ~ wouldn't have been considered, now that you mention it, you've got me thinking - any reason I shouln't make ~/.moonchild productions/ a mountpoint? Owner/mode issues aren't a problem. All my corrsponding users have the same uid/gid - I make sure of it. And even for someone who didn't, ~ is simple anyway - you can chown --recursive user:group the whole thing if you need to. I may try that if nobody says it's a bad idea.

[Walter Dnes]

Mount or bindmount or symlinked directory would work. You would have only one copy of the profile and directory to worry about. The only problem is that screwing up that copy screws up your only copy. It can happen. See the recent thread https://forum.palemoon.org/viewtopic.php?f=37&t=18484 As long as you keep backups, you should be covered.