[DNG] Menus: Was: What not to back up
Olaf Meeuwissen said on Wed, 24 Nov 2021 20:39:18 +0900 >Hi, > >Steve Litt writes: >> * The UMENU2 menu structure. > >I have no such thing as far as I am aware of. >Don't even know what UMENU2 is :-? > >Ah, http://troubleshooters.com/projects/umenu2/ explains. Don't have >it, then. For my needs, dmenu and *sh-completion suffice. As far as I'm concerned, dmenu is an absolute must for all touch-typists. I use dmenu about 100 times a day to launch programs. I use dmenu in vertical mode, taking its input from the executable path, to choose what to run. With 3 to 5 keystrokes you can run any program you want, without ever reaching for the mouse. Unfortunately for me, dmenu is made with direct-to-X calls, no Gtk, no Qt, no xforms, no tk, just calls to X. What this means is that when I'm finally forced to move to Wayland, dmenu stops working. At that time I'll need to go into the dmenu source code, replace all X calls with calls to a layer of abstraction, and code that layer to work with Wayland. The dmenu source code is pretty ugly because it's a mish-mash of list handling plus X calls almost completely mixed together. I know this because I once tried to make a CLI (or maybe nCurses) version of dmenu and failed. I haven't used it too much this way, but dmenu is also an outstanding input facility for shellscripts. You can type in a value and capture its value, or pick a value out of a list, or a little of both. Dmenu is one of the best applications I've ever come across. It's a work of genius. What UMENU2 adds to the mix is the ability to run whole command lines, including arguments, even with the possibility of UMENU2 querying for those arguments. UMENU2 shines in the following situations: * Command lines you don't use enough to memorize * Command lines you use so often you want to reduce keystrokes * Front ending a lots-of-possible-arguments executable to make it user friendly. * Creating a simple, menu driven application from UMENU2 internal shellscripts, or from a shellscript DSL (Domain Specific Language). * Working remotely over a slow network line. Unfortunately, UMENU2 is, as systemd aficionados would say about other init systems, "not ready for prime time" because specifying menus and commands is not easy. Right now you have to do these specifications with a file manager or with a couple of programs I wrote, but none of this is all that simple. Some day, when I retire, I'm gonna add a "config mode" to UMENU2, so that you can do specifications within the UMENU2 work environment, so everything will be prompted and discoverable. But that's at least a week's work, and I have books to write in order to pay the rent. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What not to back up
Hi,
Steve Litt writes:
> Dr. Nikolaus Klepp via Dng said on Tue, 23 Nov 2021 20:43:28 +0100
>
>>Anno domini 2021 Tue, 23 Nov 14:27:56 -0500
>> Hendrik Boom scripsit:
>>> I'm setting up a new backup script that will do it all piecemeal so
>>> that if a part of it fails, it can be retried without having to
>>> start *everythng* over from scratch.
>>>
>>> Which top-level filesystems should *not* be backed up.
>>
>>
>>Question is: What do you want the backup for? Recover from a failed
>>disk in 5 minutes or "just" all your settings and user directories? I
>>for myself do not bother to save the OS, a list of all manually
>>installed packages is good enough for me.
>>
>>Nik
>
> I'm the same as Nik. If I can buy it again, or install it again, it's
> not a tragedy if I lose it. For this reason I don't back up /usr.
By the same reasoning, you can exclude /bin, /lib, /lib64 and /sbin.
However, I would back up /usr/local because that may be a real pain
to reconstruct.
>
> The majority of files in /home/yourname are useless. /home/yourname is
> a mishmash of stuff you created, settings you use, and useless crap
> like cache. It's huge and ugly. For that reason I create other top
> level directories to hold stuff I created myself.
I create dedicated directories below $HOME, version control them with
git and push to an external location. Gives me backups + versioning!
>
>
> Nevertheless, it really is necessary to back up /home, although
> everything should be done to make sure none of what you back up is
> cache:
>
> ==
> [slitt@mydesk ~]$ find .cache | wc -l
> 82571
> [slitt@mydesk ~]$ du -hs .cache
> 2.1G .cache
> [slitt@mydesk ~]$ find . | grep cache | wc -l
> find: ‘./mail/Maildir/lost+found’: Permission denied
> 173948
> [slitt@mydesk ~]$
> ==
>
> Really?
Depending on what software you use, you may have missed a swat of
cache. I'd look for
find $HOME/.[^.]* -iname '*cache' -type d
# The above assumes bash for the .[^.]* shell glob.
At the office I (have to) use M$ Teams and that caches boatloads of
stuff elsewhere. Firefox also creates per site caches.
> Then there's ~/Downloads. The way I see it, if you need things in the
> download directory enough to back them up, those files should have been
> moved somewhere else.
That'd be ${XDG_DOWNLOAD_DIR:-Downloads} for folks that customize.
# Settings in ${XDG_CONFIG_HOME:-$HOME/.config}/user-dirs.dirs.
> I back up /home minus .cache, but I segregate that backup, and when I
> reinstall, instead of restoring to /home, I restore it to
> /scatch/oldhome, and manually transfer things as necessary.
I also do something like that for my $HOME. Now I still have an
$HOME/__ATTIC__/__ATTIC__/__ATTIC__/__ATTIC__/
that needs cleaning out ;-O
> In my opinion, here are some things that are absolutely essential to
> back up:
>
> * The /etc tree
> * The output of the mount command (yeah, I know /etc/fstab, but still)
> * The output of the command telling all the packages that were
> installed manually.
As mentioned in another follow up, you may want a *full* list of
packages installed (with their versions) if only to help trouble
shooting issues after reinstalling the list of previously manually
installed packages.
Even if you installed all 50,000+ Devuan packages, that'd be peanuts
compared to the size of the rest of your backup.
> * The UMENU2 menu structure.
I have no such thing as far as I am aware of.
Don't even know what UMENU2 is :-?
Ah, http://troubleshooters.com/projects/umenu2/ explains. Don't have
it, then. For my needs, dmenu and *sh-completion suffice.
> * All data you created, and I hope it's *not* in /home.
>
> Like Nik says, if your goal is to get it back up in 5 minutes, your
> best bet is to back up the entire system, as well as the mbr or
> whatever you call the UEFI equivalent (both copies). But if your
> intent is just to stay in business after losing a disk, I think a
> data-only backup is superior.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What not to back up
Hi Hendrik,
Hendrik Boom writes:
> I'm setting up a new backup script that will do it all piecemeal so
> that if a part of it fails, it can be retried without having to start
> *everythng* over from scratch.
>
> Which top-level filesystems should *not* be backed up.
>
> To start with, I presumably shouldn't back up
>
> /proc
> /tmp
> /dev (cause I'm using some version of *udev)
> /mnt
ACK.
> and I certainly should back up /var, /usr. /root, /bin,
> /boot, /etc, /home, /lib, /lib64, /sbin
I wouldn't bother with /var/cache and /var/log but you're talking
top-level ;-)
/boot is managed by installing kernel images and grub (using settings in
/etc/grub) so isn't all that important to include. At least on amd64.
> But what about
>
> /run
> /srv
> /sys
> ?
Both /run and /sys are tmpfs file systems. Not worth backing up.
Basically, you should only care about a subset of what lives below the
mount points listed by
df | grep ^/ | awk '{print $6}'
and make sure your backup command doesn't cross file system boundaries.
That should automatically exclude things like /dev, /proc, /run, /sys
and may (or may not) exclude /tmp (depending on installation choices).
As /mnt is meant for temporary mounts, that should be excluded too.
> What are those even used for?
I would have pointed you to the FHS but as Lars pointed out already `man
7 hier` will tell.
Of course, if you don't use things like /srv and /opt, there's not much
of a cost to backing up the empty directories :-)
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What not to back up
Hi, Dr. Nikolaus Klepp via Dng writes: > Anno domini 2021 Tue, 23 Nov 21:39:07 +0200 > Lars Noodén via Dng scripsit: >> On 11/23/21 21:27, Hendrik Boom wrote: >> > I'm setting up a new backup script that will do it all piecemeal so >> > that if a part of it fails, it can be retried without having to start >> > *everythng* over from scratch. >> [snip] >> >> It depends on what you've set up. >> >> For the systems I have, I only back up the configuration files in /etc/ >> plus the output of >> dpkg --get-selections >> The restoration plan is to do a fresh installation and restore with >> dpkg --set-selections > > I prefer "apt-mark showmanual" :) That gets my vote as well but ... > $ dpkg --get-selections|wc -l > 3474 > $ apt-mark showmanual|wc -l > 904 ... changing dependencies being what they are, one might have a few dependencies lingering around that would not be covered by apt-mark's output. In case one unwittingly relied on those being installed, the output of `dpkg --get-selections` or `dpkg-query -W` might be a better option. Note that the latter even includes version info. I would include the output of all three in a backup. It's not a lot of info, just a couple of kb, but may save the day in case restoring does not quite get you where you want to be. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
