How to uninstall built-in programs?

[je55eah]

[Mod Edit: Thread moved from "Software" to main "Fatdog64" section.]

I am thinking about creating a virtualbox install as a rox app or something else. Do I need to start over from scratch if I want to avoid a conflict with the virtualbox put in place by the third party installer? Is there a way to uninstall third party apps?

My current understanding is that rox apps can be deleted by deleting the application folder and the rox app folder.
Appimages can be uninstalled by deleting the appimage.
sfs and pets can be uninstalled by unloading and deleting the sfs or the pet. Are these the same?
Software installed with gslapt can be uninstalled with gslapt.

Although software may be uninstalled, the old files remain present (but masked) in the base save file or in some middle layer until the system is somehow remastered.

I want to remove Seamonkey, LibreOffice, GIMP, VLC, dds9, ripperX, Armagetron, Pipe Panic, Xinvaders, & GtkTetris and install a working Virtualbox.

[step]

I am thinking about creating a virtualbox install as a rox app or something else. Do I need to start over from scratch if I want to avoid a conflict with the virtualbox put in place by the third party installer?

You can create your rox app while the other app is installed because a rox app is encapsulated in its own folder. However, when you run your rox app then the other app may conflict because they both share the same file system.

Is there a way to uninstall third party apps?

No. Often third party apps provide their own uninstaller. VB does (see my answer in your other thread).

My current understanding is that rox apps can be deleted by deleting the application folder and the rox app folder.

Correct. However, if the rox app modified the system outside its own folder then you'll need to also undo those system changes to call the uninstall "complete and clean".

Appimages can be uninstalled by deleting the appimage.

Correct. However, again, recognize that system changes are always possible if you run the appimage as root!
Moreover, many rox apps and appimages will save the user's preferences under ~/.config or thereabout.

sfs and pets can be uninstalled by unloading and deleting the sfs or the pet. Are these the same?

No, they aren't. pets are old fashined packages similar to gslapt's packages. Pets are touched upon in Fatdog's FAQ/Help. Yes, sfs's can be unloaded to uninstall them.

Software installed with gslapt can be uninstalled with gslapt.

Yes. But again, recognize that software can make changes to the system, and that many uninstallers don't undo those changes.

Although software may be uninstalled, the old files remain present (but masked) in the base save file or in some middle layer until the system is somehow remastered.

Hmm, "masked" isn't clear. There is no "base" save file. There's only "the" save file, on top of any other kind of layer except the transient ram layer (which is merged into the save file when the save interval expires or you press "Save RAM layer"). I can agree that in multisession layers the file in the most-recently saved layer wins over older files by the same pathname.

[je55eah]

It's all a mess. Systems like this shouldn't be expected to do more than one thing reliably. It looks like I need to learn the ins and outs of the sandbox feature next.

VB does (see my answer in your other thread).

Thanks!

There is no "base" save file. There's only "the" save file, on top of any other kind of layer except the transient ram layer (which is merged into the save file when the save interval expires or you press "Save RAM layer").

I thought most of the files are locked in initrd permanently. My impression was that if I delete them, the save file simply hides them. Some people extract the base filesystem and load it as an sfs or as a base save in a multisession setup. In FirstRib the whole filesystem can also be moved to the layer right below the ram layer which would make it writeable/deletable like a traditional install or a frugal directory install. I'm happy to be corrected if I am mistaken.

[step]

It's all a mess.

What is all a mess?

Systems like this shouldn't be expected to do more than one thing reliably.

Systems like what shouldn't be expected?

I thought most of the files are locked in initrd permanently.

Indeed initrd and all sfs files are read-only archives (initrd is more than just an archive). In that sense the files are "locked in" permanently. Then there's the layered file system. I gave a FAQ link for that in an early thread of yours. The same pathname can appear in multiple layers. The pathname at the highest level wins over the others ("masks" the others to use a term you used before). The contents at the winning pathname are the file that you see when you open it in rox and applications. When you save a file its contents can't go back to a read-only layer, so they go back to the RAM layer, if it exists, and eventually to the savefile. Once saved contents are in the savefile, so if you re-read that file, you read it from the savefile.

My impression was that if I delete them, the save file simply hides them.

Correct. Aufs - the technology Fatdog64 uses for the layers - creates a placeholder in the savefile to remember that the pathname was deleted. This placeholder hides that pathname in all the layers.

Some people extract the base filesystem

It's called base sfs. It's an sfs and not a filesytem.

and load it as an sfs

Correct, it's an sfs so they need to load it in order to use it. Base sfs _is_ Fatdog64. Initrd includes base.sfs and, after booting the system, it loads base sfs. This last bit is explained in the FAQ (humongous initrd, which I know you've already read).

or [load the base sfs]as a base save in a multisession setup.

Hmm, they load the base sfs as the bottom layer. We all do regardless of how we will save our changes (savefile, savedir, multisession)

In FirstRib the whole filesystem can also be moved to the layer right below the ram layer which would make it writeable/deletable like a traditional install or a frugal directory install. I'm happy to be corrected if I am mistaken.

I don't know how FirstRib does things. Fatdog64 is unrelated to FirstRib.

[je55eah]

It sounds like we are on the same page.

What is all a mess?

These applications are like children that leave their toys scattered all over the place. I think unix was not designed for apps to be added and removed. It seems like they are best suited to providing a well defined set of services so that the OS and the software all work together as a singular product.

Projects such as Gobo, Nix, Fedora Silverblue, and EasyOS are each attempting to create more modular systems in similar but different ways but few operating systems address portability as well as Fatdog and Puppy.

That's why I want a well tuned hypervisor that will live boot on anything. KVM would be nice, but it is inconvenient to use on systems such as Antix, Puppy, and FatDog which eschew Systemd. I did get it working on Antix with hand coded scripts. Fred has built someDebianDogs with systemd recently so I will hopefully get KVM working on a live boot MX or on DebianDog, or SparkyBonsai, or maybe something like a MxDog.

Since your report about Qemu was positive, perhaps I should try using Fatdog as an ARM emulator to host Android guests. Prime and Bliss were barely functioning on virtualbox. I see that Qemu also offers KVM virtualization now.

Virtualbox is less performant than KVM, but an argument can be made that it is well suited to hosting desktops. I will try the sfs you sent me and a few more things, but if Qemu gets the job done and Virtualbox continues to be troublesome there's a point when I will stop swimming against the current.

[rockedge]

In FirstRib the whole filesystem can also be moved to the layer right below the ram layer which would make it writeable/deletable like a traditional install or a frugal directory install. I'm happy to be corrected if I am mistaken.

Yes this is correct. The entire root (base) filesystem can be decompressed then renamed to upper_changes. This will then behave similar to a full install though is actually a frugal installation. A delete is a real deletion since the rootfs is now combined with the read/write layer

[jamesbond]

In FirstRib the whole filesystem can also be moved to the layer right below the ram layer which would make it writeable/deletable like a traditional install or a frugal directory install. I'm happy to be corrected if I am mistaken.

Yes this is correct. The entire root (base) filesystem can be decompressed then renamed to upper_changes. This will then behave similar to a full install though is actually a frugal installation. A delete is a real deletion since the rootfs is now combined with the read/write layer

Been there, done that, long before FirstRib was even a twinkle in wiak's eyes
In the above guide, step (6) is the "decompression" part. An updated guide for more recent Fatdogs is here.

The interesting thing with Fatdog's version of "Layered Full Install" mode (as we call it) is that you can still use the RAM-layer and choose whether or not changes made during a session is saved into this "full-install" layer, as a pre-caution / privacy measure. You can choose when or whether you want to make your changes persistent into your beautifully curated "full-install" setup. Of course, __can__ doesn't mean you have to; you can also configure it to have all changes directly persisted into the "full-install" layer too.

[rockedge]

Been there, done that, long before FirstRib was even a twinkle in wiak's eyes

And that means what to me? I already know that.

I literally had to scan every single entry in the old forum fixing the murga forum stuff.

So I know some Puppy History. But that led to why was the decompressed file system abandoned? Did you build distro's with a recipe file via script? I booted FatDog once and only once so I do not know what the status is with a full install in a frugal install with that thing.

By the way I was answering a question and I am removing from here ->______________________________ what I think of your remark.

Reviewing the links the process looks interesting and I'll give it a try out. Still doing it with FirstRib seems much easier, But I'll try it and see how it works. I do not know enough about FatDog to even say what it's built on and what the package manager is.

[rockedge]

@jamesbond I don't go around saying anything negative about anyone's work. You feel like your toes are getting stepped on or what?

I am at a loss for the words and surprised at your remarks. I will ponder my response.

[jamesbond]

@jamesbond I don't go around saying anything negative about anyone's work.

Please enlighten me where exactly did I say anything negative about anyone's work.

You were explaining about a certain FirstRib feature. I appreciated that.

To add to that information, I said that Fatdog also has similar feature, a feature that I implemented more than ten years ago, with links to prove it (the documentation about such feature was written ten years ago, but the feature actually pre-dated the documentation). Now, ten years ago wiak had not written FirstRib, and I didn't remember he said anything anywhere about writing his own distro (Weedog and the associated FirstRib) either back then, so it is fair to say that he didn't have an inkling about writing FirstRib at that time.

These are facts.

Which part of those facts says negative things about FirstRib or wiak or perhaps yourself?
Or are you simply saying that I am not allowed to state those facts?

In addition, the links I posted contains the details of how exactly this can be done in - for people who may be interested but can't find the relevant instructions. I did this in my own thread, in my own section which specifically talks about Fatdog.

Am I not allowed to talk about Fatdog features, to Fatdog users, in Fatdog's own section, when it references other people's work?

You feel like your toes are getting stepped on or what?

Stating that Fatdog had the same feature and had it earlier than FirstRib, means that my toes are getting stepped on?

I am at a loss for the words and surprised at your remarks.

The feelings are mutual.

I will ponder my response.

This is your forum. You are the king here. I'm just but a passer-by.
So, please do as you wish. I yield to your authority.

[jamesbond]

Been there, done that, long before FirstRib was even a twinkle in wiak's eyes

And that means what to me? I already know that.

The comment wasn't never meant for you personally. There are new people coming in here every day, we can't expect them to know every single bit of history of every Puppy variants, derivatives, and offshots.

I literally had to scan every single entry in the old forum fixing the murga forum stuff.

So I know some Puppy History. But that led to why was the decompressed file system abandoned?

I'm not sure I understand you. Nothing I said spoke about anything being abandoned. I'm not sure where you get the idea.

Did you build distro's with a recipe file via script?

How is this relevant to the subject at hand?

But to answer your question: yes, we build Fatdog using scripts.
These scripts are available for everyone to use.
This collection of scripts is called "Fatdog ISO Builder", which is announced and updated every time we released Fatdog.
This is the equivalent of FirstRib, although, of course, it will only build Fatdog out of Fatdog own packages, not from any other distros.

I booted FatDog once and only once so I do not know what the status is with a full install in a frugal install with that thing.

Indeed, and you're not the only one. That's why I feel the need to explain that we too support such feature. People may be interested in that.

Reviewing the links the process looks interesting and I'll give it a try out. Still doing it with FirstRib seems much easier, But I'll try it and see how it works.

The link I is about using an already-made Fatdog, and run it in either "layered full install" or "true full install". It is not instructions on how to build a Fatdog. It's an instruction on how to install / use Fatdog. We are talking about two different things here.

I do not know enough about FatDog to even say what it's built on and what the package manager is.

Here we go:

Fatdog is an independent distro that builds its own packages from source.

There are three package managers in Fatdog, built upon layers:
a) The foundation package manager is "pkgtools" which we adopt from Slackware.
b) The convenience package manager is "slapt-get" which is CLI only, and uses "pkgtools" to do its job.
c) The GUI package manager is called "gslapt" which uses "slapt-get" to do its job.
(a) and (b) can be scripted. Any package-related activities (install/uninstall/upgrade) from one layer is immediately visible in the other layers too.

I hope that explains.

[rockedge]

The link I is about using an already-made Fatdog, and run it in either "layered full install" or "true full install". It is not instructions on how to build a Fatdog. It's an instruction on how to install / use Fatdog. We are talking about two different things here.

That's exactly what I am talking about. That is using a an already made KLV and using compressed or decompressed SFS components at any time. Just as FatDog can a decade earlier I suppose.

My goal was to find or make a distro that is totally customized or made to do one thing. That is run ZoneMinder fully in the smallest possible space and with top efficiency. That is how I got into all of this to begin with. KLV and all those WeeDog-Void's I made in both 32 and 64 bit versions all really began as platforms for Zoneminder and it's web server.

I have not attempted to build ZM for FatDog but I am pretty sure that I could successfully. Probably will now to be able to say I did plus a really good way to really get to know a distro.

[Clarity]

Could anyone in FDland direct me to the "current wisdom" documentation for getting and keeping current QEMU?

I have an old 'operational' document from Google, but, is there a current one for FD specific to FD that one can refer?

Thanks in advance for "guiding to a current FD & current QEMU document" if one exists.

[je55eah]

If you download the devx sfs and load it then qemu will appear in your menu. I haven't tested it yet, but it is in there. The sfs could also be loaded at boot by adding it as an extra in your boot options.

[Feek]

Could anyone in FDland direct me to the "current wisdom" documentation for getting and keeping current QEMU?

Hi,
a few times I installed QEMU using gslapt for one session only to test some .iso's. Also, there is a simple GUI package for QEMU available in gslapt (made by Fatdog team, I think).
In this GUI, the help button can be clicked for basic instructions on how to proceed.

[Clarity]

Hello @Feek

I ask:

• What GUI are you referencing when you did your testing in the past?

• Are you referring to something installed with QEMU via the Package Manager or a secondary package added along with your QEMU addition?

Thanks, in advance

[Feek]

@Clarity ,
I meant a secondary package added along with QEMU addition.
I'm not currently in Fatdog.
However, I'm now looking at the FD packages at https://distro.ibiblio.org/fatdog/packages/810/
It should be this: "qemu-vm-manager-1.4-noarch-1.txz"

[rockedge]

This is your forum. You are the king here. I'm just but a passer-by.
So, please do as you wish. I yield to your authority.

There is no King. Merely a Captain and Chief Engineer momentarily in command.