I’ve been using Silverblue since January 2020 enjoying the benefits of inmutable system and the like. In a sense, similar to Haiku.
So I was thinking on how to manage all those saved states that appear when booting Haiku on BM (bare metal), therefore I came out with haistate.
While it’s not complete by all means, it’s a WIP as of today, it is only a simple approach at managing system states from the Terminal. Yep, it can be done with a GUI too, but for that I first need to fully understand the API.
Here is the first screenshot:
Any comments welcome. This is, for those guessing, just a simple bash script.
If I understood well how it works, you can’t know if pinned states will work.
Unlike a snapshot that will restore an image of the whole system, states are restoring what have been modified at a moment. To go back in time to state 1, you process through all states backward starting from actual state.
I may be wrong but if it is the case, successfully restoring a pinned state will depend of what have been modified in states deleted.
If it was somehow redundant, it may work. If was not, you can’t tell.
Actually I didn’t think about it until you pointed it out. I just did some check right now. States are just plain text files listing the installed packages. Removing unused just cleans space on disk and removes clutter from the boot process so there wouldn’t be a big list of states available.
I did a diff on two files from 2 different dates and there were big changes. So as you said,
I was expecting different hrevs saved, though not. Meaning my approach is absolutely wrong. It wouldn’t improve anything for the end user, and it might even cause bigger trouble than what I intended to address. That is why I wanted comments. I’m learning with each step.
Nonetheless, time wasn’t wasted on this as got a clearer picture of Haiku’s attributes and the state of ‘states’.
Doesn’t mean that the whole idea was wrong and there’s certainly something to do in this domain.
Perhaps have the last five on haiku partition and have another partion to store older states. When it reaches 90% used, you are deleting the oldest until you’re back at 60%. Or you archive them on an external drive CD/DVD, USB key, memory chip… But wherever you put them you will want the system to be able to access them there.
Check on the forum, I think humdinger made a script moving older states to another folder.
In state folder, there is only the text file activated packages when you install some new package without doing something else.
If you update your system, packages that have been replaced are also ending there along with the activated packages file.
I guess that it is the case for every package removed from the activated packages list.
If it was only the text file it wouldn’t grow so fast. Actualy, it does if you are using nightlies. I think that for a “normal” user who’s using the stable branch, it doesn’t.
This looks like it would just make things more complicated and still use just as much storage space, I think? If you want the system to access them, just have them in the system folder, that’s what it’s designed for
There is certainly something to do in this domain, and I think it’s as simple as deleting the old states after they are unused for a while. No need to get super fancy here, if some state is older than a month or so it’s probably not that useful.
As an end user, I totally agree. Though, I would be cautious with time based deletion because a casual user may not boot haiku for few months. In that case, I guess keeping at least the last five would make the user feel more secure even if it is an illusion.
I thought about external drive to store older states because I remembered you saying in another thread that you were keeping a lot of them…
No need to do that for stable branch but if they are useful for devs to test regressions or things alike, maybe an option in boot menu of nightlies could allow to load one from an external source.
I have no skills in coding at all and won’t start to learn now. So don’t be surprised if sometimes my ideas are dated, strange, not realistic, etc.
I thought the same at first but then I realised that things can go wrong only when you change something. And when you change something, a fresh state is always created before making any change. So you would have at least this one to recover from.
The case where you:
Update Haiku
Immediately shutdown your computer for several months
Run it again a few months later and find it broken and want to rollback
seems a bit unlikely. Would you remembre which state was “good” then?
I in fact don’t find myself using states all that much. But my case is different: when I have a bug, I try to fix it, not run an old version of Haiku where it doesn’t exist yet. And this I don’t consider the main use case
The idea I had was to let the script use attributes, that is,
when Haiku boots without issues, the script would add the attribute Boot/OK, and Default/OK
when user pins a state would add attribute Pinned/YES
when user unpins a state would remove attribute Pinned
when user removes a state, first checks if it’s pinned or the last with Boot/OK in which case, you know… warn the user
when user clears the states, removes states without Pinned/YES and the last ones with Boot/OK
when user lists states, these attributes would appear there too
and when user sets default boot, would set Default/OK to the new one, move it to the right place and remove attribute Default/OK from the “old one” and move this to a storage folder.
Well, that was the idea until I found out that states are just text files with a list of active packages. In my case, on nightlies, and testing software, installing, uninstalling… lists are quite large and vary a lot from state to state, even same day. So I presume that this approach does not make much sense as I could just delete old states from the hard drive and done, no need to worry about managing anything.
Then, if it were actually snapshots or “system deployments”, I am quite sure devs would have already implemented the tool to manage snapshots with their rollbacks.
Nonetheless, digging into the attributes thing was very interesting and hope I’ll be using that sooner than later.
The state is a directory with a text file indicating what is activated, and all packages that are needed to get back from the “next” state to this one (in other words, everything that was uninstalled or replaced right after saving this state).
So, they are not exactly snapshots, but they contain all the information to rollback to said state. That is what the bootloader does: when you pick a state, it just uses the textfile with the list of packages and knows that said packages will be found in one of three places:
/boot/system/packages if the package is still active
in the state backup directory
in another state backup directory
We don’t have implemented anything because we didn’t have time
