Trying to get a grasp on how all this works

[Renegade Apprentice]

Hey all

1) I stumbled across the EasyOS Website & in turn found the Puppy Linux Forum. I've read through the EasyOS site (some parts multiple times). I still need to re-read much of it. From the EasyOS site, I've followed the links here. I've played with EasyOS, EasyOS-Buster, & EasyPup, but mostly with EasyOS. Even did a frugal install. Gotten frustrated with it, put it down for a bit, but I'm too intrigued to give it up. I've started reading some of the different threads in the general Puppy Forum, even found some help there with appimages. I'm a little concerned about what translates over to EasyOS & what doesn't. On the EasyOS website, Barry says, "It is only natural that a lot of "puppyisms" can be found in Easy, though, it must be stated that Easy is also very different, and should not be thought of as a fork of Puppy."........... So I'm wondering what are the differences I should be aware of, so I'm not wasting time looking for answers in the wrong places?

2) I've read in the EasyOS portion of the Puppy Forum, concerning the Buster series dying a slow death, that it is suggested to rely more on portable apps & sym-links (did I spell that right?).
A) Elsewhere in the general Puppy Forum, EXE file apps were suggested. To my limited knowledge, they need either Wine, PlayonLinux, or one of the other alternative applications. I noticed in the EasyOS-Buster, that Wine & PlayonLinux were available for download, but didn't see either of these in EasyOS. Since in the discussion I read, that portable apps were implied to be used in EasyOS in place of using downloaded applications from the .deb packages, How does one get these to work in EasyOS?
B) I've tried to get appimages to work in EasyOS & EasyOS-Buster, with some trouble. I installed appimagelauncher (which I will refer to in question 3 later. Since that didn't seem to work, I found in my reading in the general Puppy Forums, some suggestions that did work. It seems that I need to open a terminal in the folder where my appimages are located & run the appimage plus the command "--no-sandbox". It seems this involves some extra steps from what I"m use to, & which I'm willing to do if there is no other way, but is there a simpler way?
C) Does the --no-sandbox command negate my being able to run the app in a container? If so, if I run the whole desktop in a container, then does that solve the problem?
D) Elsewhere in the forum I read that portable apps could be stored in a folder on another partition, or on another hard drive then use a sym-link (forgive me if this isn't the proper term) to run the app from the OS. My question about this practice, does running the system in Ram where I can't access drives other than USBs, does the sym-link overcome this? It maybe since that discussion was about other puppy distros, it doesn't apply concerning Easy.
E) Again, elsewhere in the forum, I've read that there are some old archives or older forum posts where someone made sfs from the portable apps? So far I haven't found any in my searches, does anyone have an idea where I can search?

3) I installed the .deb package appimagelauncher into EasyOS & EasyOS-Buster. It seemed to install alright & populated in my menu, but it didn't help any at all concerning running my appimages. I started wondering if it really installed, so I installed another .deb package (Brave) as a test. Again, it appeared to install alright & populated my menu. Yet when I clicked on the Brave icon, it didn't run. The same for EasyOS-Buster. My question is, is there another step in getting installed .deb packages to work, or are these distros not meant to have .deb packages installed locally? I have noticed that in another systemd-free system, that I would always get errors when updating, upgrading the system, or installing other packages, related to appimagelauncher. Yet it worked & all my appimages would populate in my menu, where I could click on them & run them.

4) Concerning sym-links, is this somehow different than the regular links that I'm used to in Debian & Ubuntu type distros? Can anyone link me to some reading material concerning this?

5) As mentioned, my experience has mostly been Debian & Ubuntu type distros. What frame of mind changes or ways of thinking & handling things do I need to be aware of concerning working with Easy?

[mikeslr]

Hi Renegade Apprentice and to the Kennels.

In Linux, regardless of which Linux, borrowing a phrase from music theory, https://makingmusicmag.com/music-theory ... n-a-theme/ you are always dealing with some variation on a theme.
What you already know about Linux will carry over to a large extent into Puppy Linux; and despite however much Barry K --the creator of both Puppy Linux and EasyOS-- thinks they differ, the latter is a variation of the former.
The primary distinctions between Puppy Linux and "Major Distros" is that the latter are unitary systems which do not distinguish between RAM and Storage, constantly reading and writing between them. To achieve isolation of any thing from the whole system, Major Distros confine the activity of a User to his-or-her own folder unless and until the 'the Administrator's magic password' is given. 15+ years ago, Puppy Linux realized that the User was the Administrator and dropped that non-sense. But the environment in which Puppy Linux was to evolve was a PC running Windows; and Windows --then as now-- zealously guards the locations under its control. Unguarded at that time was what could be run from a CD --after all there had to be some way to get Windows onto storage in the first place. Windows also had no control of what happens in RAM, else you wouldn't be able to play 'Space Invaders'. Initially, therefore, Puppy Linux booted from a CD, and ran 'in RAM', disappearing from RAM when shut down and Windows was none-the-wiser.
The next variations were to (1) move Puppy's system files from the CD into only a folder on the hard-drive and boot it from there; and (2) extend Puppy's capabilities by making use of Linux's ability to merge file-systems in RAM: sort of like how graphic programs use Layers, one on top of another, only the top one showing, but not actually modifying the permanent base graphic until commanded to do so.
Those concepts 'merge in RAM', 'don't become permanent until commanded' form the basic techniques by which Puppy operating systems function today; how they differ from Major distros; and --with respect to your question-- to a large extent how EasyOS differs from Puppy Linux.
SFS is an acronym for 'squashed --i.e. compressed-- file-system'. To preserve customiztions, settings and the use of applications not included by the Dev in the base SFS Puppys evolved to make use of a Save.SFS: Information in RAM being written to such file on the Storage media, and on reboot such Save.SFS mounted with the files it contained having priority over any conflicting files in the base.sfs provided by the Puppy's Dev. [SaveFolders as an alternative to SaveFiles came later]. A remaster permanently combines the files-systems, again with those from the SaveFile/Folder having priority. Puppys can boot with instructions not to employ a SaveFile/Folder or to what extent their contents are to be copied into RAM. Alternative SaveFiles/Folders can be created. SaveFiles/Folders can be easily 'backed-up', deleted, and the use of alternative Saves offered as a choice on boot-up. [There's also available under Puppys an application which will package what otherwise would be in a SaveFile/Folder into a READ-ONLY SFS. I don't know about its utility under EasyOS].

Evolving at a time when computers seldom had more than 256 Mbs of RAM, conserving RAM to perform actual work was an objective Puppy tackled early on. One method was that rather than install an application into a SaveFile, it was packages as an SFS. As an SFS it could be mounted when needed, unmounted when not. Unmounted it required no RAM at all. Unmounted, its files can not conflict with any files currently in use. Major distros have only recently discovered the value of this idea, producing applications which don't have to be installed but are merely mounted. An AppImage is one such version. Flatpaks and Snapds are two others, both less useful under Puppys as both --unlike AppImages-- require applications within the OS to manage them.
Under Puppys, AppImages only have to be made executable, then file-browsed-to and Left-Clicked to run. Alternatively, a script can be written or a symbolic link created 'on the path' which will execute the AppImage from wherever it is located. If it will run at all.
As under other Linuxes, you can open a terminal and create a symbolic link. Or you can write a bash-script ‘on the path’ to an executable which, itself, isn't 'on the path' by using a text editor, then make the script executable. Or you can Right-click and empty space and select New>Script from the popup-window.
[Oddly, once the AppImage is, itself, executable the argument in the bash script does not take on the usual form, e.g.
exec /opt/master-pdf-editor-4/masterpdfeditor4 "$@"
Rather, only something like the following is needed:
/mnt/home/Pup-Apps/Leonflix.AppImage --no-sandbox
i.e. FULL-PATH-TO/x.AppImage
Note, however, the script itself must be executable.
But Puppys and EasyOS --which both employ Rox as file-manager-- provide an easy way to create symbolic links. Open two Rox windows, one to the file, the other to somewhere 'on the path' and drag the file from the former to the latter, selecting Link(relative) from the pop-up window. Both Puppys and EasyOS have a location 'on the path' which is a convenient location for such symlinks as it is unique to those OSes: /root/my-applications/bin.
You may run into a couple of problems trying to use AppImages. First, both Puppys and EasyOS 'run as root' and many AppImages -especially those based on Chromium or its cut down version known IIRC as Electron-- will refuse to run as Root. The workarounds published for Puppy with respect to those AppImages should work under EasyOS. Essentially, they take two forms. Start the AppImage via a bash-script which contains either of these arguments 'run-as-spot' or '--no-sandbox', such as in the Leonflix.AppImage example above. Sometimes you'll need both, e.g.
run-as-spot /mnt/home/Pup-Apps/eddie-VPN.AppImage --no-sandbox
Both AppImages and SFSes-created-for-Puppys are supposed to be 'self-contained': that is include within itself all the files upon which the application depends. Neither may prove true, especially with regard to AppImages. These are built and tested to function OOTB under 3 or 4 major Linux distros; the most relevant being some versions of Ubuntu or debian as many Puppys --and, for example, EasyOS-Buster-- are 'binary-compatible' with some version of Ubuntu or debian. Binary-compatible, however, does not mean 'identical'. Rather it means that Puppys and EasyOS have been built using the binaries of such distro-version, and their Package Manager will provide direct access to such distro-version's repositories repositories and the ability to install packages from them.
Between the core files of an operating system and the files of an application are an infra-structure which enables the former to make use of the latter. Puppys' infra-structure is unique to Puppy, except to the extent that it may also be employed in EasyOS. Consequently, Puppy and EasyOS may not already contain dependencies which creators of an AppImage assumed to be present and tested against.
Under EasyOS it is important to remember that there is a distinction between the MainOS and any Containerized-OS you can run under it. The Containerized-OS operates with a curtailed ability to mount file-systems. . As a result, it can not make use of either AppImages or SFSes. But you can install applications, or manually place an application's files into it. [I'm not sure how EasyOS accomplishes it, but IIRC --always a Big IF-- files and packages installed into the Containerized-OS were available on reboot].

The possible work-around is to extract the SFS or AppImage manually place its files in their proper locations; or perhaps repackage its contents as a pet.

AFAIK, all Linux OS's contain a folder: /opt. You can put anything into it. But remember, /opt is not on the path. LibreOffice provides a good example of how it can be used. I think EasyOS has UExtract builtin. If not, you can download it from here, viewtopic.php?f=106&t=594, then Left-Click the pet to install it. You can mount an SFS by merely Left-Clicking it and selecting "view". From the window which opens you can copy any/all files into another folder. [After Left-Clicking an SFS you'll also be offered the option of installing. This can be dangerous because (a) doing so may over-write files other applications depend on; and (b) AFAIK, there's no way to 'uninstall']. To extract an AppImage, open a terminal to its PARENT folder and type a version of this command:
./appImage-name --appimage-extract
At any rate, decompress LibreOffice and examine how an application whose files are located in /opt is 'tied' into the operating system.
Also examine how MikeWalsh and fredx181 build portable-webbrowsers with scripts to run them from anywhere, viewforum.php?f=90.
Once a AppImage or SFS has been decompressed, copied to a folder and any necessary dependencies and restrictions [such as 'look only here for libraries' or no-sandbox or 'run-as-spot'] supplied that folder can be manually located in /opt. Alternatively, you can create a named folder, e.g. my-new-thing, create an /opt folder within it, copy your application's folder into that /opt, with other folders such as LibreOffice or a portable-web-browser uses to tie it into your OS, then (1) if available via Right-Click menu, right-click the my-new-thing folder and select "Create a pet package". (2) If not, open a terminal in my-new-thing's parent folder and enter the command dir2pet.

Three other things worth knowing about:
https://rockedge.org/psearch/ is a dedicated Search Engine for 'all things Puppy'.
ListDD, http://www.smokey01.com/radky/ is a great tool for determining what dependencies an application requires which your version of Puppy hasn't provided. [Unfortunately, it is of no use if what's lacking or conflicting is a python module].
and https://pkgs.org/ is a great source of links for obtaining such dependencies if Puppy's Package Manager can't.

P.S. Re-read your post. About Wine. Creating Wine packages which function, I've only found three methods; two of which won't function under a Containerized-OS, and I'm not sure about one under EasyOS, itself. One of the Wine.AppImages from this thread, viewtopic.php?p=13634#p13634 should work under a Ubuntu/Debian Main EasyOS if you follow the instructions on that thread. But not under the Containerized-OS since you can't mount it. And EasyOS-dunfel and similar may lack required dependencies. Portable-Wine from here, https://oldforum.puppylinux.com/viewtop ... 8&start=45 should run under Ubuntu/Debian based EasyOS provided that if they are 64-bit you also SFS-load the appropriate 32-bit compatibility SFS. But as it makes use of an SFS, it can't be used in containerized OSes. In passing, note that to build that portable I used one of Version2013's pets.
Building functional Wine is an art which Version2013 has mastered. I don't know any other Puppy Dev whose builds I trust, whose builds haven't generated posts about problems. I don't know whether EasyOS's package manager offers a Wine version. But my instinct is, if possible, use one of Version2013's builds.
Most of what I wrote here, viewtopic.php?p=31258#p31258 about getting a Windows program to run under EasyPup will apply to EasyOS. In particular, read the last paragraph. My recollection is that at some point I did have one of Version2013's Wine.pets running under Containerized racy. Racy is a 32-bit system OS, so doesn't need a compatibility layer. It is one of the operating systems BarryK has provided as an SFS-download. But TBH, it's been a while since I worked with EasyOS and I don't really trust my 'mid-term' memory.
A possible alternative --untested-- is that EasyOS --itself, & not a containerized OS-- could run the SFS of a Chrooted 32-bit operating system into which Wine had been installed. See the discussion here, viewtopic.php?p=33971#p33971. Note, it will not be as 'locked down' as a containerized-OS but exposure from its web-facing applications can be limited by using a VPN. FWIW, I've built such chroots using either dpup-stretch or xenialpup. Chrooted, Xenialpup's uget ran much better.

P.S. after the 3rd read of your OP.
Wine: If you employ the Wine.AppImage from the above linked thread, you'll also find instructions on that thread for linking it to your OP. An advantage of the AppImage per those instructions is that it enables you to run both 32-and-64 bit Windows programs.
Most of the Windows programs you may want to run are 32-bit. To run them under a 64-bit Puppy --other than by using the referred to AppImages-- requires that you first establish and configure a 32-bit Compatibility layer. You do this by downloading the appropriate SFS, SFS-loading it, then entering a terminal and typing, without the quotes, 'ldconfig'. The first letter of that word is a 'small' l (phonetic 'el') not a capital I (phonetic 'eye') or the letter 1. It should take some time before your terminal again becomes available. The ldconfig command sets up many links. I recommend that you have some simple 32-bit application other than Wine to test whether the command was successful.
[You can download opera-12.16-1860.i386.linux.tar.xz from here, https://get.opera.com/pub/opera/linux/1216/ and UEXtract it. Left-Clicking the opera script in the extraction folder should start it. You don't really care if it is fully functional or a web-browser Websites will grant access to].
If that application doesn't run, try re-entering the command.
Only after you've succeeded with configuring the 32-bit compatibility module will you have any hope of creating a wine emulation layer. Once you've installed a 32-bit Wine pet, or registered the 32-bit portable wine, you again have to open a terminal. Type the command 'wine winecfg'. But have a connection to the internet already established. The first thing configuring Wine tries to do is to install mono and gecko from WineHQ's repos.
It may help if you understand Linux packaging. A Package is an assemblage of files organized in such a way that the package manager of operating system for which the Package was created can unpack it and copy its files into designated folders within the structure used by that operating system. The structure of most Linux OSes are similar-to-identical, including those of Puppy and EasyOS. Puppys --while they do not employ Synaptic or Apt, or Slackware's package manager-- contain modules which can properly unpack debs and txz packages, create folders corresponding to those provided by the package creator in the package and copy the package's files and folder into your OS .
Those files were compiled against the system in which they were expected to be used. Usually, the files compiled for one OS will be identical to those for another. But not always, not even if they bear identical names. Typing a package name in pkg.org's search box will usually generate dozens of links, one for each operating system for which a package was compiled. Packages for a Ubuntu version are likely to be identical to those for a debian version of the same vintage. But the further you go from your binary-compatible distro, the more likely there will exist that some difference which will prevent a packages use OOTB, without creating symlinks, or ever.
And, of course, there's the 32-bit-64-bit dichotomy. Slackware chose to handle it one way, debian/Ubuntu another. And Puppy Linux has struggled to develop a means to work with both. But that's a story for a different day.

[Renegade Apprentice]

@Mikeslr,

Prior to seeing your reply come in last night. I had started reading your thread "The Illusion of Privacy/Security using ANY Web-browser", which was linked under/in your thread "Run an Almost Invulnerable Puppy". I hope to get to that one as well after finishing the first. I read your reply last night, then again this morning, a few portions, one or two times more. It was a great overview, with some paragraphs more pointed. Thank you for the time & consideration in putting all that together for me, it is very helpful.

[williwaw]

welcome renegade apprentice

as Mike mentioned above, electron based apps do not like to run as root, hence the ---no sandbox workaround.
from https://www.electronjs.org/

Electron uses Chromium and Node.js so you can build your app with HTML, CSS, and JavaScript.

whether an app is packaged as an appimage is a different issue I suppose.

So I'm wondering what are the differences I should be aware of, so I'm not wasting time looking for answers in the wrong places?

https://easyos.org/about/how-and-why-ea ... erent.html might help. Recently. the previous Easy forum was moved here, but there is a lot of development info here also https://oldforum.puppylinux.com/viewtop ... 5&t=109958

Barry recently posted some of his thought about the direction Easy is taking at the bottom of this post.
https://bkhome.org/news/202108/807-pack ... asyos.html

Barrys thoughts about not wanting to maintain a large repo seem ok to me, especially given how easy it is to have a puppy or dog capable of using the debian or slackware repos, available as a frugal, only a reboot away, or especially given the usefulness of being able to run a different flavor from a container within Easy.

Elsewhere in the forum I read that portable apps could be stored in a folder on another partition, or on another hard drive then use a sym-link (forgive me if this isn't the proper term) to run the app from the OS. My question about this practice, does running the system in Ram where I can't access drives other than USBs, does the sym-link overcome this?

symlinks across unmountable partitions is not possible, but....there are more ram options available in Easy. one that does allow mounting partitions, and one that allows replugging the USB.
https://bkhome.org/news/201908/easyos-b ... n-ram.html
https://bkhome.org/news/202008/shutdown ... items.html

[mikewalsh]

, @Renegade Apprentice ..!

Well. I thought it was time I took a look at this OS......and it's proving quite interesting.

I haven't bothered with all the "containerization" stuff.....yet. Most of my major apps are all running as 'portables' from sdc2, and this is where all my relentless work with portable-apps is really starting to pay dividends. It's a doddle to set-up another Puppy/Puppy-derivative, 'cos all I have to do is add the menu Entries in, and I'm up-and-running..!

Also - and Mikeslr might be interested in this! - since MooiTech's wonderful PhotoScape is pretty much the only Windows app that's really a must-have for me these days, I've built a self-contained PhotoScape-portable with its own built-in WINE, using the WINE AppImages trister found over at Github a while ago. At launch, it links the WINE AppImage and Wine 'profile' into the OS, followed by firing-up PhotoScape. When I'm finished with it, at shutdown WINE is "disconnected" from the system again. It runs very sweetly under Easy.

Using this, alongside AppImages of G.I.M.P & Krita, my graphics needs are covered.

-------------------------------------------------------------

Downloaded the img.gz file, unzipped it, and used Rosa Image Writer to write EasyOS Buster 64 2.6.2 to a 32 GB USB 3.1/3.2 SanDisk Ultra 'Fit' flash drive, and booted it through the Grub4DOS 'Advanced options', which lets me select the individual drive. Everything seems to run very nicely; the single fly in the ointment so far is that Easy doesn't appear to be recognising any of my sound cards; all I seem to get, regardless of the app, is "default ALSA sink".... Despite the Multiple Sound Card Wizard listing every one of my cards, not one single app actually "sees" any of them.

??!?

Still; it's early days yet. Plenty of time.....!!

Posting from Slimjet-portable under EasyOS Buster right now.

Mike.

[mikeslr]

...
Also - and Mikeslr might be interested in this! - since MooiTech's wonderful PhotoScape is pretty much the only Windows app that's really a must-have for me these days, I've built a self-contained PhotoScape-portable with its own built-in WINE, using the WINE AppImages trister found over at Github a while ago. At launch, it links the WINE AppImage and Wine 'profile' into the OS, followed by firing-up PhotoScape. When I'm finished with it, at shutdown WINE is "disconnected" from the system again. It runs very sweetly under Easy.

Using this, alongside AppImages of G.I.M.P & Krita, my graphics needs are covered.
...Mike.

Are you sure you weren't a detective in your prior life? You're really good at reading people.
I've made a note in Osmo to review this.