Puppy Linux Discussion Forum

Once in a while ....mostly after System Updates/upgrades with Synaptic Packet Manager,or updating Web Browser or my favorite Media Players (VLC/ Smplayer/Smtube) ....i save my "updated" System ,which now is just "temporary" stored/saved into the "Save Folder".

After a while of testing.....when everything seems save/fine i do a "Quick Remaster" to merge "Save Folder" with the Main 01.filesystem.squashfs .........."Save Folder" is now empty at the next Reboot ( cause merged into the Main 01.filesystem.squashfs).

I keep a Backup of the older 01.filesystem.squashfs .......to be on the save Side.......just in Case.

That`s just the Way i do it.......Never encountered any "visible" Problem until now.

But i am anyway not to much "paranoid" regarding "Cybersecurity"........i gave up on it.
On my working System (mostly Web browsing) anyway is nothing much important .

Funny how it has been claimed a read/write filesystem is less secure than a read-only squashed filesystem. I've also thought that was a silly idea and all the more so since a hacker is generally pretty good at computing/Linux. Whether the filesystem is stored uncompressed, or compressed in read-only sfs, or in an initrd img file or whatever is totally irrelevant to any hacker. Actually weedogit used to download isos and extract from them any sfs files or img rootfilesystems they had and uncompress and change them and then recompress them again. Simple job, simple scripting. Unsquashing sfs and resquashing a one liner - same with anything like that. Different indeed if the partition is read only - then you must find a way of remounting it read/write, but if you break in as root user - well, forget security. Easy to modify sfs, initrd contents, whatever you like. Using sfs files is nothing to do with security so not an argument against the likes of Pupmode 13 with a savefile or savefolder. Partitions can get corrupted too, as can individual files; sometimes backup mechanisms break down during backup and cause corruption! Anything involving computers connected to the internet is a security risk. I don't want a driverless car that uses internet accessible AI to help drive it!!!

Funny thing is, people claim all sorts of advantages about certain ways of using distros - like adverts - but completely nonsense most of the time. A kind of false pride in a favourite product rather than a true selling point.

one wrote: ↑Sat Aug 19, 2023 1:27 pm

amethyst wrote: ↑Sat Aug 19, 2023 12:46 pm

dimkr wrote: ↑Sat Aug 19, 2023 12:08 pm

One reason for me to stay very far away from save files/folders, it's just prone to corruption. I don't care what anyone else says because I've experienced the corruption risks first-hand. Huge save files/folders are the worst scenario, just a terrible way of computing in my view. Some users have save files/folders GB's in size, playing with fire....

Hi @amethyst,

no problem if you backup your current savefile-/folder on a different medium.

peace

btw: I don't use savefile-/folder but I would surely backup if ...

Yes and then backup becomes fun when reaching the GB sizes. No, thank you.

Backup using rsync - only changes get sent back to backed up save folder.

So guys, why don't we just do full installs.

Another favourite 'advert' of nonsense is that copy2ram makes everything much faster. Well, maybe if using terribly slow external media, slow hard drive, or slow usb stick, but most machines that still use such old technology don't have much RAM anyway so hardly ever a good idea to waste that via copying all sfs files and so on into RAM before continuing boot... And on modern fast machines, you won't notice any speed difference whatsoever, so why so many still claiming big advert advantage of distro by default copying everything into RAM prior to continuing boot? It is fine as an option, but wrong as a default in most cases.

The main reason we don't do full installs, which are best for upgrading the likes of kernels and glibc and so on, is that you don't get the likes of wonderful Pupmode 13 save-on-demand-only. Otherwise full installs work fine unless you are messing around damaging the system as root user... In practice most mainstream full installed distros have near perfect package management so if you install something you don't want you can just remove it. Trouble comes when you get into config file edit madness and break things - not having Pupmode 13 gives you a problem then... Hence when I want to use my own full installed Linux Mint distro for 'experimental developments' I first turn it quickly into a frugal install and use save on demand overlays. Nothing to do with hacker attack type security though - full or frugal - both just as vulnerable in reality (outside of people's fantasy dreams).

Go read-only for me . Much more difficult to breach in my view although some have tried to explain otherwise. I don't share that view...

Well, of course there are a few more 'steps' involved to change something inside a squashed filesystem or a compressed initrd img or similar. But computers do millions of steps per second I think, so not an issue to them. Manually doing it, command by command as a human is a different matter, but what hacker would bother wasting such time when a simple script would just immediately (almost) make any change they wish? But each to their own - if a person doesn't like the idea of have a save folder/file with the likes of Pupmode 13 cos they think that is insecure, well fine - just use same system each time with sfs read-only layer files only, but don't let hacker in cos two seconds (milli-seconds?) later it is all compromised anyway...

At least if you run as non-root user, hacker does have the trouble of breaking out to become root user; at least that is problematic.

note: I would say that sfs do have a useful advantage characteristic anyway though. I believe a save folder/file is much more easily corrupted in the case of power failures and so on. I'm not sure what if any error-correction mechanisms are involved, but I have heard that squashed filesystems are relatively robust. Not being sure about the truth or falsehood of that statement, I think it would be worth experimenting - corrupting a bit or two to see if the files internal to the sfs remain intact or not??? The only major danger to any of my own computers has however only been myself - and I've suffered some horrendous data losses over time...

Let's see. Grandma Malicious (not very computer literate) decides to "attack" Johnny's Puppy. For save file (doesn't matter which pupmode) - Mount save file, make changes. save. Grandma says: "Wow, that was quick and easy". For sfs - mount/load, copy contents to another location to edit, make changes, make a new sfs, delete/overwrite the old sfs. Grandma says: "Now that was not so easy. I had to know how to copy correctly and I had to know how to make a new sfs, besides, the whole operation took some time, Johnny could have caught me in the act". With this I'm signing off from this specific topic.

Bump. So far there have only been 29 votes. Your vote matters.

Bump. So far there have only been 29 votes. Your vote matters.

Maybe there is someone who would like to participate in this poll but doesn't know what pupmode is or how to find it.

Each booted Puppy runs in a specific pupmode. No need to know the details.

You can simply go to Menu -> System -> Event manager, where you will see the necessary information for voting.

You can vote in this poll until September 16, 2023.
Thanks

Usually use pupmode 12 on an internal drive.

For anyone who may not know, here's my layman's understanding of the various PupModes:

PupMode 5 boots Puppy without mounting a SaveFile/Folder (or using the tar.gz you created) because: (a) you have not created any of the forgoing; (b) you've replaced any previously created SaveFile/Folder with either an adrv.sfs or ydrv.sfs using the Save2SFS module of the Utility-Suite*, viewtopic.php?p=12983#p12983; or (c) although you have a SaveFile/Folder, you've used the 'pfix=ram' boot argument so that it hasn't be mounted on boot-up.

PupMode 13 is the default written by boot-loaders for a Puppy deployed to a USB-Stick. Changes made --settings, configurations, user-installed applications-- are NOT immediately written to the USB-Stick; rather they are held in a folder in Ram. The effect of those changes on your system can be tested by executing Menu>Exit>Restart Graphical Server (AkA Restart-x) which causes a Puppy to re-catalog its current components.
A Save Icon is on the desktop which, when clicked, will execute a Save. And at shutdown/reboot that process is halted (for 60 seconds) providing you with the time to respond to a GUI asking whether you want to perform a Save. Although the 'Save' Button is highlighted for ease (just press return) the default is 'No Save', so you can just walk away.

PupMode 12 is the default written by boot-loaders for a Puppy deployed to a Hard-drive. Changes made --settings, configurations, user-installed applications, documents in /root/my-document, junk you didn't know you picked up while surfing, anything-- are immediately written to your SaveFile/Folder.

Currently, a User can configure a Puppy deployed to a Hard-drive to operate under PupMode 13 --as if it had been deployed to a USB-Stick-- by manually making the following changes:

a) Change the boot-argument: The line beginning with the 'linux' or 'kernel' may have the argument pmedia=atahd. If present, it has to be edited to read pmedia=ataflash. If absent, the argument pmedia=ataflash has to be added.
(b) After booting with the 'pmedia=ataflash' argument the User must configure Menu>System>Puppy Event Manager and click the Save Sessions Tab. The bottom of the GUI that opens looks like this:

The instructions provided by the GUI may not need any explanation. But it can't hurt to mention that if the interval isn't '0' or a check has not been placed in the "Ask" button, the Puppy still functions as if under PupMode 12 with the User's choice of Save Interval. [Hence, why the Poll has two choices relating to PupMode 13].

PupMode 66 is new. I have never used it and have no desire to. So I just mentioned using a tar.gz for Saving. Feel free to provide more information.

FWIW, the PupMode Numbers 5, 12, 13 etc. are not arbitrary. When Barry K modified Puppys to handle USB-Sticks differently from Hard-drives he posted an explanation of the change and why those specific numbers were used. But I've forgotten his explanation.

-=-=-=-
* There may be other ways to create an adrv or ydrv.

Thanks to everyone who voted in this poll.

I created it partly out of curiosity to see what percentage of users prefer pupmode 12 and how security (malware) compares to pupmode 13 and 5.

In the long run I prefer convenience, ie pupmode 13 without periodic saving.
But I will admit that I believed the posts here on the forum that pupmode 5 is "bulletproof" in terms of security. So thanks dimkr and wiak for the clarification.

Thirteen is a lucky number .

Pupmode 5!

Using PACKIT to remaster.
Extract with UEXTRACT.

I'm almost always in 5 but missing 13 for there are always changes after a remaster if you get that far.

It's tedious & time consuming to set up every boot for basic use, but that's what I do.

There are no browsers in my main remaster, FossaXenial (64 Xenialpup with Fossapup kernel) so they are loaded by script on demand. I'm also copying scripts to bin, the hosts file, etc., manually each boot.

If Puppy could be designed to work in 5 normally with automated saved changes that would be a boon, yet functionality no one owes to anyone.

The only thing that would still be tedious for me with a Redmond-like setup is I like to change my desktop theme a lot. A theme changer would also be a boon, have only seen ptheme in Slacko pups.

Once you figure out how the basics work, what I'm posting is really just about time, making the way you use a distro time-efficient.

Doing the same thing everyday is like Sisyphus.

I haven't figured out yet how to get my main device to hibernate, but if I do I won't shut it down.