Include a very tiny savefile?

[nanZor]

Hmm.. my .02c time. How about including a very teeny savefile, say 100mb or so in the distribution iso?

Even though a new user is warned up front about not having a savefile the very first time they fire up in Graphics, it might be convenient to have a tiny persistence built in, since some are not even familiar with what a savefile is coming from the usual scatter-disk installation of other systems.

This way, since Porteus finds a savefile automatically if not instructed to do so otherwise, those who don't take the time to use the Porteus SaveFile Manager, won't lose their desktop session setting tweaks, and possibly the addition of a browser download upon first reboot.

Sure enough, this would be kicking the can down the road if the user overflows the miniscule distributed savefile. BUT, that may tend to lead to using the Savefile Manager and either expanding the existing one, or creating a new one. Aha, the light-bulb goes off!

Experienced users will do their own thing of course, like deleting the teeny one, or running frugal with some other filesystem etc etc.

Just a thought tossing it out there. It isn't a problem for me.

[M. Eerie]

How about including a very teeny savefile

A little script could do it at boot time, maybe...

[Vic]

I remember having issues with persistence when first using Porteus. Took a while before it clicked in my brain.

I like the "changes=" idea but I am mostly sure it only works for posix file systems. The Savefile Manager is very easy too.
One needs to be aware of their existence to use them though.

Maybe have the install script create a savefile and modify the porteus(x).cfg file. I will have to think about how it could have been easier for me.

I really like how Porteus(x) is so small, especially KDE. Nobody beats that from what I have seen.

Adding a save file to the ISO might be an option for downloading, but would add more storage load on the servers.

I did like how a person used to be able to build an ISO from the website. Thought that was cool.
Maybe offer options to download different porteus(x).cfg files with instructions along with a save file of various sizes.

Vic

[Ed_P]

I like the "changes=" idea but I am mostly sure it only works for posix file systems.

A save.dat file can be anywhere, mine are on FAT32 & NTFS systems. A concern with a small file is when changes exceed it's size it gets corrupted and you loose everything, and it's very annoying. I've used various sizes over the yrs and currently use with 512MB ones which I try to save as half full.

I did like how a person used to be able to build an ISO from the website. Thought that was cool.

Yes, that was very cool. It's too bad we don't have all the website developers we used to have. A lot of the stuff is outdated.

[M. Eerie]

Since pendrives are now cheaper, maybe it's time to rethink the strategy...

Once an initial (small) VFAT partition is created for booting and another (POSIX) EXT4 partition with the rest of the disk space, saving the changes becomes an understatement, since we are dealing with a real installation. That is, there is no need for the CHANGES cheatcode anymore...

[Ed_P]

A major advantage of CHANGES, especially CHANGES=EXIT, the ability to make them and not save them. You boot, you do things, you change things, you visit websites, etc and at the end you realize that wasn't the best day, and EXIT and exclude saving the day's changes.

[Otto]

This way, since Porteus finds a savefile automatically if not instructed to do so otherwise, those who don't take the time to use the Porteus SaveFile Manager, won't lose their desktop session setting tweaks, and possibly the addition of a browser download upon first reboot.

You can stop the save-session to readonly mode by adding Boot stanza "changes-ro".

[nanZor]

Personally, if a tiny 128mb empty savefile was included, I'd name it something like "tinypersist.dat".

That would be the clue when the new user hopefully just mounts the iso (rather than burn) and sees the files, that when he overflows it later, they'll remember why, and either expand it, or create a new one. But at least it would be enough oobe automation to save the DE settings, and maybe a single browser. Experienced users will simply not use or copy the tinypersist.dat file anyway and do their own thing.

I think the total modularity and flexibility can throw one off coming from a scatter-disk installation. Depending on mood, I'll use savefiles, or full blown posix extX filesystems, but that knowledge came later in my Porteus discovery.

Re the web options to make an iso on request ... I think Slitaz had a "cooker", but an issue developed where the users were constantly hammering the cook servers making full-blown large iso's with miniscule option changes, rather than simply downloading a different DE module and applying it to the existing one they had already cooked....

Large fat32 thumbdrives? Use multiple savefiles not exceeding 4gb. (If I want a max savefile on one of those, I usually choose nothing larger than 3800mb in the gui savefile manager). I make plenty with different names, like porteussave.dat, backup1.dat, encrypted.dat etc, and then at the splash screen, hit TAB and change the name temporarily etc...

Full blown ext filesystems? The Raspberry Pi install usually has a teeny FS included, which the user is obligated to manually expand after install. I think they automate it to the rest of the stick now...

Anyway, see how this goes? There is no "one true way" with Porteus. I just think for the quick first-time tire-kickers, a teeny savefile might be easy enough to implement in the distribution iso without having any sort of paradigm change... Just thoughts, not a big deal.

[vinnie]

Perhaps my approach is a bit unpopular, but I prefer to always select what needs to be saved because I like the startup state of the system to be determined.
So I don't like all changes to be saved automatically.
Currently what I am doing is not using either the changes dir or the file.dat (although I can't quite remember why I am not using this), but I am using saves in xzm modules

[AcnapyxoB]

My solution for saves:
to save or not to save: machine-id (Post by AcnapyxoB #100705)

[Ed_P]

I am using saves in xzm modules

Certainly a good approach, especially if you determine what needs to be saved verses everything that has changed.

[nanZor]

See, this is kind of the problem - even Jesse at distrowatch complained about being confused installing PorteuX. The first thing we do is get all guru about it and seek simplified instructions just to see if they can make a usb stick work in the first place - all the guru stuff can come later!

These would be my instructions for Porteus today to my next-door neighbor for either a modern uefi machine or an older one:

1) Porteus is different. Although distributed as an iso, we do not "burn it". We MOUNT the iso, and then COPY all the files to the target drive. Your existing file manager should have that option to mount the iso. (mind blown!)

2) Eject the drive nicely, or reboot. Use your bios settings or boot override to boot the new stick first.

3) Upon a successful boot, to save your settings, go into the Savefile Manager. Accept the defaults, and direct it to put the persistence savefile on the same stick you booted from.

4) If you are confused about editing the porteus.cfg file, don't worry - Porteus will find it automatically again, so you may opt out of editing this file if you aren't sure.

5) Reboot, make some changes, and reboot once again to prove your persistence works.

6) IF YOUR SYSTEM DOESN'T BOOT: It might be that the machine needs a special bootloader to handle the non-uefi or older bios setup.
In that case, reboot your machine to the original system. Find the installer exe (for windows) or linux installer (ON YOUR NEW TARGET DRIVE, not from elsewhere). Run that, and when prompted, just be sure it is directed to your new target usb stick. Reboot again this time and the system should recognize it as bootable.

This is the problem I see with most reviews - most go immediately guru about it. That can come later, but up front, it is way too confusing for many. Not burning the iso, but mounting and copying is like a total mindblower. If I ran the world (grin!), I'd distribute in zip format to force a dearchive to a stick, but that's me.

[Vic]

"distribute in zip format"

Easier than trying to wrap my knewbee brain around ISO mounting way back in the good ol' days. Any of the usual compression schemes would work: zip, tar.gz, 7zip, etc. Way back when I used M$ Windows the zip was a no-brainer and easy. I only found out about ISO stuff through programs like CloneDVD and such.

Maybe there could be offerings in a community remix format such as "Totally Black Theme" or similar.

Vic

[vinnie]

I am using saves in xzm modules

Certainly a good approach, especially if you determine what needs to be saved verses everything that has changed.

Actually this “approach” stems from my fear of having to identify problems that I do not know I have caused.
The downside is that you have to waste more time on it; the upside is that generally nothing inadvertent happens.
In the end it all boils down to:
1) making changes until you get what you want
2) reboot, make the same changes “cleanly”
3) create the save file with the “portes session saver” tool.

Problems:
1) You have to be careful because it only saves changes (it is incremental) so you should NOT delete old xzm of saves.
2) Another thing you have to be careful about (I'm going from memory) is that if you make saves sequentially maybe the system will overwrite the last save and thus may lose the previous one. If I remember correctly it is because of the automatic name used.
3) I had noticed that it was not possible to unzip and merge xzm save files, however, I think I had already been explained why and maybe solved

Currently I don't remember why I don't use the savefile.dat, maybe because I didn't know how to edit it manually or because that was also being updated automatically or because I had had some problems managing it with changes= or the changes..cfg

[ncmprhnsbl]

We MOUNT the iso,

just to point out that afaia *most* archive managers quite happily extract isos just like any other archive.
due to the recent activity around a network install script, we've added a "install-skeleton.tar.xz" .. which is simply an archive of the iso contents, without any modules or kernel
so, a manual install would be: format and partition you drive(if necessary) download and extract the skeleton to it (distributing boot EFI and porteus folders depending on your partition layout), download a kernel(vmlinuz to /boot/syslinux and 000-kernel.xzm to /porteus/base)
..download the base modules(001-core,002-xorg,002-xtra,003-your_choice) to /porteus/base and then whatever other modules eg. a browser, printing etc.. to /porteus/modules or optional..
then if requiring legacy bios booting, run one of the *installer.com/exe s ..