requesting to input a text note during persist-save operation

[stewie]

the ...bin/persist-save script already writes to $LIVE_DIR/config/last-persist-save but it only logs the date. Please consider amending the script so that it will accept text input and log the captured text also. The desired flow I am envisioning is this:

If the save mode is semiautomatic, after clicking YES at "Shall we begin" prompt the following dialog would display a text entry field, along with a label stating "(optional) enter a note associated with this save".

On subsequent runs, the script would read in notetext from tail of last-persist-save and display that note+date in the currently blank dialog titled "Shall we begin". If note was blank, at least display the datetime of last save operation.

With this feature in place, I could experiment to create a pygtk app similar to what MS Windows had, called "SystemRestore".

[BitJam]

Stewie, I don't think what you are asking for would do what you want because that directory is not preserved across reboots. I don't understand what your end goal is because I am not a Windows user, nor do I understand how the feature you requested would help your experiments. I don't want to give all users an extra hurdle and get translations done and so forth when the benefit of the changes has not been made clear to me.

I suggest you make a modified version of persist-save for your experiments. Also, I suggest that you approach this problem "the Unix way" and instead of intermingling different functionalities, either make a wrapper to go around persist-save or add a hook inside of persist-save that calls a program that does whatever you want. For example, the following code will only call $prog if it exists so you are not inflicting this feature on everyone and it also allows $prog to control whether persist-save continues or exits via the exit status of $prog.

if test -x $prog; then $prog || exit; fi

Also note that there are times where persist-save runs as a CLI application without access to X-windows. The entire suite of persist-* programs are like this. That way we don't lose this functionality in our "core" flavour which does not come with X-windows. But even on systems with X-windows I rely on being able to run persist-save via the command line.

[BitJam]

Stewie! Have you used the live-remaster program yet? I believe it has the hooks you requested already built in. This is really the way to save major changes anyway. The file that saves the version information is /etc/live/version/linuxfs.ver. I didn't add any user comments but if I had then they would go into the title: field. Here is a sample entry:

==== 406ad6e2335ab324ef611c571b25739e

title: 
creation date: 22 April 2016 16:40:49 EDT
kernel: Linux 4.4.2-antix.2-amd64-smp
machine: x86_64
inxi version: antiX-16-b1_x64-full Berta Cáceres 11 April 2016

We only append to this file so it keeps a history of what changes have been made. We also offer to stash older versions of the linuxfs files neatly in a way that makes it easy to find out which is which. We never built a retrieval mechanism because there has been absolutely no demand for it.

Even without retrieving older linuxfs files, there is already a lot of easy flexibility when the combination of live-remaster and root persistence is used. You can always disable root persistence to get back to the last remaster. You can get to the previous remaster with the "rollback" cheat. There is no automatic way to "roll forward" but it is easy to do manually because we try hard to make sure no information is lost when you do the rollback.

All of this functionality exists now (and has existed for years). In addition, if you choose to "save" the previous old remaster when you make a new one then it gets saved in a way that makes it easy for a program to automatically select and retrieve it (although this program has never been written).

Also, once there is a remaster feature, the rootfs file is not a good way to archive changes because each rootfs file is tied to a specific linuxfs file. Once the linuxfs file changes during a remaster, the previous set of archived rootfs files are no longer valid.

Like with any complex design, there were many compromises and trade offs that we had to make. For example, Puppy Linux made a different set of choices so some things are easier in Puppy Linux and some things are easier in our system. For us, the remaster feature is key because it makes it easy for people to make their own version of the distro they can distribute to others. This feature has been enhanced with our snapshot programs that go one step further and make an iso file as well. One of my dreams is to have a (free) marketplace of these remasters with enough information about each so people can borrow and learn from each other and go beyond what the original distributions do.

We also make available the build-iso program which is for people who seriously want to make their own distribution with 32-bit and 64-bit versions and other possible variations and maintain it over the course of years. The remasters and snapshots are great for personal use or for sharing something at one point in time but they are not good for maintaining your own distribution over time. For that you should use build-iso.

HTH

[stewie]

Thanks for the detailed explanation. Wow i really misunderstood the mechanism. OK, i saw 'overlay' and read about overlayfs, and came away with the impresson that saving a persist created a new layer, a layer to be added to the stack. Because the mechanism is just merging changes during each save, merging them directly to the squashfs, there's no layer dataset to timestamp and label and saveAs.

Closest to my envisioned idea is the rootfs.new vs rootfs.old storage used in the live remaster mechanism. My vision would have been to grab a labeled copy of rootfs.old each time one was generated and hold em potential rollback restore points. No that wouldn't be efficient. I need to manage versioning for a fileset of 14K php project files and have comre around to realizing that SVN localhost server is probably the best already invented wheel for the task.

[BitJam]

What about using btrfs on an installed system? Snapshots at the filesystem level are about as efficient as you can get.