On Fri, Sep 14, 2018 at 04:31:19PM -0500, Daniel Allcock wrote: > Dear all, > > I am wondering how you all deal with (for example) having an elaborate vim > or emacs environment built up over several decades, and being able > to use it in all of your regular everyday qubes (personal, work, untrusted, > etc, > probably leave vault out). Of course, you expect it to keep evolving as you > figure out how some package solves a problem for you, or you write some > vimscript or elisp to stop an annoyance. > > What is the qubes way to do this? I've considered several solutions from > the simple to the baroque: > > (simple) do the common config in the template vm (but not in /home > or /rw or /usr/local) and replace the relevant config files/dirs in the > actual-work > vm's with symlinks to them.
Most tools that allow a customized local config in /home also have an area for global configuration (for instance /etc/vim/vimrc). So since Qubes acts more like a single-user system you could just store your settings, plugins, etc. in their global location in the appropriate template. This has the added advantage that you could still override your global preferences in a particular qube if you needed to by setting things in /home. I follow the pattern where you clone the "default" provided templates to create ones that you customize with custom packages anyway. The default Qubes-provided templates just get package updates. That way backup/restore is a bit cleaner as you don't have a conflict when the fresh install has a brand new debian-9 template, for instance. So following this pattern you'd change that customized template and leave the default Qubes-provided ones for system qubes and vault, etc. -Kyle > > (also simple) have a "config" qube where you keep the configs you want to > sync, > but do no actual work there and have no net access. Set up a script to copy > the relevant files/dirs to your working qubes. When you find an annoyance, > fix it there, and then run the script. > > (rather complicated) set up a git server (say in its own dvm) > and have your qubes push commits to it when > you make changes to one of the files-to-sync. That way you can make your > tweaks wherever you happen to be working at the time, and later accept > those changes on the server. Then you can download the updated version > on your working qubes (perhaps by a script). > > All of these have different convenience levels and data-flow implications. > But I feel like maybe they are all wrong and I am overlooking something > obvious. Any thoughts appreciated! > Daniel > > -- > You received this message because you are subscribed to the Google Groups > "qubes-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-users+unsubscr...@googlegroups.com. > To post to this group, send email to qubes-users@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/DF890AFA-A2CC-4033-9532-56F905DF8714%40allcock.org. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180914220109.GO20469%40greenfly.net. For more options, visit https://groups.google.com/d/optout.
