Bleachbit looks way cool, and I'll probably add it. (Haven't tried localpurge yet.)
localepurge provides "forward looking" attention to cleanup.
Its post-install trigger handles many (not all!) lang files placed by newly-installed packages.
-
bleachbit's cleanup of localization files is just one tiny prong of its functionality.
It auto-recognizes many installed apps + gives user granular options to clean (or not) junkfiles for each app
AND, perhaps more importantly, provides a GUI where user can enumerate custom cleanup paths/files
(Hold that thought...)
gnome-icon-theme - every time I run graphical disk map, I see that huge block,
and I want to get rid of it, but brasero, gdebi and evince depend on it.
Nixing icons PER APPLICATION, for any/all which aren't present in the distro should not cause a dependency problem.
Usage problem? Upon later installation, if user winds up with "broken" icon... can re-install the "gnome" iconset package, eh.
-
Additionally, consider: will you (or a user of your distro) _EVER_ need to see a 128x128px version of "icon for appXYZ"?
Personally, I nix ALL "sized" app icons larger than 32x32
(at the same time as weeding out icons for myriad gnomy apps I know I'll NEVER install)
Even if you retain the sized versions up to 48x48px, removing the imagefiles for the stoopidly-large versions of the icons eliminates MOST of the overhead.
^--- The chore of weeding out the icons isn't necessarily on your shoulders.
Mentioning it (the prospect of weeding out iconfiles) within a "optimization tips" document should suffice.
redundant menu items - I'm aware of a few, but not in the setting menu.
I see synaptic, gparted, time and date, and midnight commander in Accessories and System.
I don't notice it, because every linux I've used since 2000 has had redundant listings in the menu. Is it really a problem?
Problem?
Well, it's "par for the course" in terms of the loving care (or lack thereof) invested in creating a "distro".
We "see it for synaptic, gparted" because upstream numbnutz declare multiple categories in the Categories= line within the app's .desktop file
(okay, not numbnutz, more accurately "one-shoe-fits-all" nuts)
Fix this for the apps distributed within your "distro"... or don't, it's your call.
More thoughts about purging personal data before making a snapshot -
Right now, the excludes file eliminates a lot of sensitive or potentially sensitive data.
The user needs to manually edit that file if they want to include or exclude anything different.
Should there be a graphical excludes editor in the snapshot tool? Separate excludes files for different purposes?
(snapshot_exlcude.list.I_want_to_put_all_my_sensitive_data_on_the_live_system vs. snapshot_exclude.list.I_want_to_give_this_one_away)
I think I prefer empowering the user to make their own choices about what to exclude.
Maybe I just need to put more comments in the existing excludes file.
Adding some instructions for using bleachbit is a good idea, too, but I don't see it as a replacement for the extensive excludes file.
(Example: I don't want to share my ~/.ssh folder, but I also don't want it bleached from my hard drive.) Will have to play with bleachbit and see what it does.
I'm grateful for your effort in creating/maintaining refractasnapshot, but I'm not likely to install and use your "distro". Compared to SalineOS for instance, frankly I can't see much, if any, "added value" in the separate refracta distro, nor can I understand the motivation(s) involved in pursuing separate, redundant, projects. If refracta and salineOS and antix were all on the same page (under the same "brand") including a central, shared, user forum... I believe we all (devs + users) would benefit.
The "hold that thought" above == custom paths.
"make their own choices about what to exclude" (and / or include)
GUI or not, are you really eager for refractasnapshot to accommodate various use cases?
When user executes refractasnapshot, is his goal:
A) create a "distro" ( "redistributable" ~= exclusive of any personal info, inclusive of .configs ) ?
B) create a snapshot-in-time, for backup or migration purposes
C) something else
Compared to debian net-install, the value added by a given niche distro (to be used as a base) entails:
-- bundled /skel and /opt "enhancements"
-- "best practices" attention to pre-populating config details with SANE defaults
-- ease of preserving, and later migrating, "all my stuff(s), tweaked just da way i likes"
If a "distro" is gonna embrace xfce, the distro dev should EMBRACE xfce, to the extent of collecting, and including, various creative "custom thunar actions"... and documenting their inclusion. (kudos to salineOS for doing so.) The dev of an xfce "distro" should understand (and include) the usefulness of the "xfapplets" panel plug-in...
my point here is this:
Among the current crop of debian-derived and ubuntu-derived "distros" featuring xfce, MOST of 'em represent "somebody's ego trip" rather than serving as a meritworthy showcase for an xfce-powered environment. By focusing on which custom paths refractasnapshot might EXCLUDE, I worry that you are accommodating the least-desirable (IMO) use case, fostering a "whee, lookit me, i made a new distro" mindset.