Re: [DNG] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Hi spiralofhope, spiralofhope writes: > [...] > It got horrifying when I kept installing, trying, and uninstalling > software.. most of which left behind dotfiles and dotdirs that may or > may not remind me of the name of some program. (I hated wondering if > some object was necessary or just clutter) > > After several dozen dotfiles appeared, I learned to identify and > migrate items I cared about and reference each with a symlink. > > Then after blowing away a distribution and installing something new, I > would rebuild the symlinks pointing to that other partition/drive. The > programs would have a version similar enough to cope with re-using the > dotfiles. This was essential in my experiments with many, many programs > and distributions. You may be interested in `vcsh` which tries to avoid the need for a farm of symlinks and add git-based version control to the configuration files you really care about. 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] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Hi Didier, Didier Kryn writes: > Le 24/10/2021 à 01:22, Steve Litt a écrit: >> At this point I can't be sure because I run a rolling release, but I >> think ~/Music, Documents and ~/Videos were put there by the distro --- > > These are freedesktop crap. You can remove them by editing > $HOME/.config/user-dirs.dirs . > > Some applications refer to these definitions as a default place to store > files. > > Just define those you don't want as the same as an already existing one, > such as $HOME. > > I don't know what the purpose of user-dirs.locale is. That's for specifying the language you want the "default" locations to be shown in. This may be useful if your display manager lets you pick a language before you log in and occasionally switch languages. I do (on very rare occasions), between Japanese and British English, so it makes sense to set something unless you've customized all the locations. BTW, there's also a user-dirs.conf that can be used to prevent that translation from happening in the first place. Translation actually results directories being mv'd. > It's unfortunate one needs to surf the web to discover this and there is > no tool in the application menu to configure it. ACK and the manual pages are also not all that useful. IIRC, there's even a bug in there somewhere about translating the locations. 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] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Hi Steve, Steve Litt writes: > Simon said on Sat, 23 Oct 2021 15:00:26 +0100 > >>Olaf Meeuwissen via Dng wrote: >> > Might I suggest $HOME/bin :-) ~/bin isn't ideal for two reasons: 1) It's integrated with all sorts of config, cache, and who knows what, and can easily be lost or wiped out in a re-installation. >>> >>> In the case of $HOME/bin getting lost or wiped out in a >>> re-installation I'd argue you have bigger problems than just losing >>> $HOME/bin. You have most likely lost all of your $HOME, and maybe >>> even other users' $HOME as well. >> >>Agreed. >>The most logical place for personal stuff is in your $HOME. > > Well, yes, it would have been logical. But everybody, and I mean > everybody --- The distros, the standards makers, the dweebs at > Freedesktop.org, everybody made a flinking mess of $HOME. Is the config > for program myapp in ~/.myapp.rc, ~/.config/myapp/*, ~/.myapp/*? The FHS says[1] to use $HOME/.myapp.rc if one file suffices and use files below $HOME/.myapp/ if an application needs more. These have been pretty standard for a long time. The FHS also acknowledges a number of later standardization efforts that, for better of for worse, complicated the situation by adding $HOME/.config. Actually, that is controlled by the XDG_CONFIG_HOME environment variable, per XDG Base Directory Specification[2]. [1]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#homeUserHomeDirectories [2]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#basics So, your apps just put their config files where the "standard(s)" they follow tells them to :-/ Some, like git for example, now use both, having started with .gitconfig and .gitignore and now also honoring $XDG_CONFIG_HOME/git/config and $XDG_CONFIG_HOME/git/ignore. It may eventually deprecate the former and even remove them sometime. > Gotta love the way Python puts its cache in ~/__pycache__ instead of > ~/.cache/__pycache__, where it can be discarded along with all other > unnecessary cache. I have a ~/node_modules tree with over 300 files, > and I'm pretty sure node.js installation put them there. I don't really know about Python but for Node.js, that node_modules is created by running `npm install` or `yarn install` as a user. Looks like you ran that with a package.json in your $HOME. Back to Python, I guess __pycache__ was created when you ran a Python script you put in your $HOME, or maybe a `pip install` for some little Python utility you wanted to try out. Not saying $HOME/__pycache__ is a bright idea but, like the Node.js case, I think it's something you inflicted upon yourself. If simply installing packages from your distribution, or you using software provided by those packages, was responsible for this, I'd consider it a bug and would file a bug report. FWIW, I typically create a dedicated directory, under $HOME/tmp/ or $HOME/src, when I try out other people's code or extract an archive. This makes it a lot easier to keep things out of each others and your own way. It also makes cleaning up afterwards easier and if I put it below $HOME/tmp a cronjob will do that for me, eventually, if I don't do it myself. > Directories "~/Schember, John" and "~/Litt, Steve" were kindly > contributed by Calibre. Gotta love those spaces and commas. Good reason not to use Calibre ;-) Why would you create a directory named after the user in that user's $HOME directory? And with spaces and commas for crying out loud! Here's wondering how well they cope with full names using non-Latin scripts. I've got a few of those at home ;-) > At this point I can't be sure because I run a rolling release, but I > think ~/Music, Documents and ~/Videos were put there by the distro --- > I'd have no reason to do that. They were very likely created by your desktop manager or application in an attempt to adhere to the XDG user directories (which themselves seem to hark back to the Glib user directory[3] conventions). [3]: https://docs.gtk.org/glib/enum.UserDirectory.html FWIW, you can customize these names to taste and prevent them from being updated (or translated if using a different locale when logging in). Check user-dir.dirs(5) and user-dir.conf(5) for details. > They could have put all three within something called ~/Media, and > called the current ~/Media ~/Automounts. But even moving them like > that doesn't change the fact that some of your documents were produced > by you and can never be replaced, and others were things that could be > re-bought if lost. This has a huge impact on backup. For a *Personal > Computer*, $HOME is a zoo, and I either have to live with it, > reorganize it only to get broken again with the next major upgrade, or > violate FHS. First of, you're not violating the FHS in the least bit. You're just organizing your stuff in a somewhat unusual way. As long as you have given "extremely careful consideration of the consequences" to creating additio
Re: [DNG] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Le 24/10/2021 à 01:22, Steve Litt a écrit : > At this point I can't be sure because I run a rolling release, but I > think ~/Music, Documents and ~/Videos were put there by the distro --- These are freedesktop crap. You can remove them by editing $HOME/.config/user-dirs.dirs . Some applications refer to these definitions as a default place to store files. Just define those you don't want as the same as an already existing one, such as $HOME. I don't know what the purpose of user-dirs.locale is. It's unfortunate one needs to surf the web to discover this and there is no tool in the application menu to configure it. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
On Sat, 23 Oct 2021 19:22:57 -0400 Steve Litt wrote: > For a *Personal Computer*, $HOME is a zoo, and I either have to live > with it, reorganize it only to get broken again with the next major > upgrade, or violate FHS. Right from the beginning, I've always thought of $HOME as the place where my software keeps its stuff. My software, not me. It got horrifying when I kept installing, trying, and uninstalling software.. most of which left behind dotfiles and dotdirs that may or may not remind me of the name of some program. (I hated wondering if some object was necessary or just clutter) After several dozen dotfiles appeared, I learned to identify and migrate items I cared about and reference each with a symlink. Then after blowing away a distribution and installing something new, I would rebuild the symlinks pointing to that other partition/drive. The programs would have a version similar enough to cope with re-using the dotfiles. This was essential in my experiments with many, many programs and distributions. I do recognize that the leading dot can distinguish things from my own stuff, but it feels like software can stomp around in that tree and I don't trust it with my data. Of course since then there are intrusion detection systems and the like, but that's complexity creeping in. etckeeper would have been spectacular had it been around back when I was in my youthful experimentation phase. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Simon said on Sat, 23 Oct 2021 15:00:26 +0100 >Olaf Meeuwissen via Dng wrote: > Might I suggest $HOME/bin :-) >>> >>> ~/bin isn't ideal for two reasons: >>> >>> 1) It's integrated with all sorts of config, cache, and who knows >>> what, and can easily be lost or wiped out in a re-installation. >> >> In the case of $HOME/bin getting lost or wiped out in a >> re-installation I'd argue you have bigger problems than just losing >> $HOME/bin. You have most likely lost all of your $HOME, and maybe >> even other users' $HOME as well. > >Agreed. >The most logical place for personal stuff is in your $HOME. Well, yes, it would have been logical. But everybody, and I mean everybody --- The distros, the standards makers, the dweebs at Freedesktop.org, everybody made a flinking mess of $HOME. Is the config for program myapp in ~/.myapp.rc, ~/.config/myapp/*, ~/.myapp/*? Gotta love the way Python puts its cache in ~/__pycache__ instead of ~/.cache/__pycache__, where it can be discarded along with all other unnecessary cache. I have a ~/node_modules tree with over 300 files, and I'm pretty sure node.js installation put them there. Directories "~/Schember, John" and "~/Litt, Steve" were kindly contributed by Calibre. Gotta love those spaces and commas. At this point I can't be sure because I run a rolling release, but I think ~/Music, Documents and ~/Videos were put there by the distro --- I'd have no reason to do that. They could have put all three within something called ~/Media, and called the current ~/Media ~/Automounts. But even moving them like that doesn't change the fact that some of your documents were produced by you and can never be replaced, and others were things that could be re-bought if lost. This has a huge impact on backup. For a *Personal Computer*, $HOME is a zoo, and I either have to live with it, reorganize it only to get broken again with the next major upgrade, or violate FHS. Parodying Billy Joel, I didn't start the fire. > tongue in cheek> If it’s a mess at home, then tidy up a bit This would be much more true if not for the fact that a bunch of invaders called upgrades would again mess up my home. > - better >than deciding home is too much of a mess and effectively just moving >house to start again at another home. Let's examine the preceding sentence fragment. Is it really better to try to manage the mess if the new home would be free and the invader upgrades couldn't touch my new house? I'm not saying everybody should do it my way, but what I don't understand is the resistance to a method with no cost, at least as long as I'm in charge of the computer, which will be til the day I die. 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] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Olaf Meeuwissen via Dng wrote: >>> Might I suggest $HOME/bin :-) >> >> ~/bin isn't ideal for two reasons: >> >> 1) It's integrated with all sorts of config, cache, and who knows what, >> and can easily be lost or wiped out in a re-installation. > > In the case of $HOME/bin getting lost or wiped out in a re-installation > I'd argue you have bigger problems than just losing $HOME/bin. You have > most likely lost all of your $HOME, and maybe even other users' $HOME as > well. Agreed. The most logical place for personal stuff is in your $HOME. If it’s a mess at home, then tidy up a bit - better than deciding home is too much of a mess and effectively just moving house to start again at another home. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Steve Litt writes: > Olaf Meeuwissen said on Mon, 18 Oct 2021 18:52:05 +0900 > >>Hi Steve, >> >>Steve Litt writes: > >>> On more thing. When *I* write a program, I never put it in /usr/bin >>> or /usr/local/bin or /opt. I have my own directory, called /d/bats >>> (last century it was called D:\BATS when I used Windows), to contain >>> all executables > > [snip] > >>Might I suggest $HOME/bin :-) > > ~/bin isn't ideal for two reasons: > > 1) It's integrated with all sorts of config, cache, and who knows what, >and can easily be lost or wiped out in a re-installation. In the case of $HOME/bin getting lost or wiped out in a re-installation I'd argue you have bigger problems than just losing $HOME/bin. You have most likely lost all of your $HOME, and maybe even other users' $HOME as well. Personally, I haven found it being "integrated with all sorts of config, cache and who knows what". Yes, if $HOME/bin is in my $PATH, that may affect some programs. In that case, it's a bug of my own making and I can fix it by removing $HOME/bin from my $PATH or renaming whatever program in $HOME/bin causes the trouble. FTR, most of my $HOME/bin consists of scripts or stuff that you might want to install in /usr/local/bin or /usr/local/sbin. In addition, I tend to choose script names carefully so as to not collide with things that are in the default $PATH. My $HOME/bin/emacs is an exception ;-) > 2) On a *personal* computer, a place to store all self developed data >is needed. On a *personal* computer, my *personal* directory is $HOME. $HOME/bin is therefore my *personal* collection of (self developed) programs. > I have nothing against the standard File Hierarchy System (FHS) for > servers. It works, it's stood the test of time for 40 years, and it's > standard. ACK. > How different things are on a *personal* computer. On a server, it's > all about the computer (virtual or metal), and the user is incidental. > On the personal computer, it's all about the user, and the computer is > incidental. > > On a server, it's just fine (sort of) to store all locally developed > and/or used data, config and executables under /usr/local. But on a > personal computer I sure wouldn't want to store my stuff in a directory > owned by root, or under a directory owned by root. I want it in a > directory fully navagable by slitt all the way down. Eh, isn't that what $HOME is all about? Giving you a place of your own, fully navigable and controllable by $USER (or $LOGNAME in case you're running from `cron` ;-). From what you write it sounds as if `root` owns your $HOME. That'd be really unusual because user accounts, by default, get a dedicated $HOME directory, owned by that user. You'd have to bend over backward to get the Devuan installer or `adduser` to do something else. olaf@quark:~$ echo $USER olaf olaf@quark:~$ ls -ld $HOME drwxr-xr-x 1 olaf olaf 1686 Oct 21 18:37 /home/olaf > So isn't that what /home/slitt is for? Not really. /home/slitt is a > huge, disorganized mess with data, config, cache, and all sorts of > other stuff. Ah! So the problem is really one of *personal* hygiene ;-P # Not saying I'm squeaky clean myself, mind you! > /home/slitt gets destroyed in every clean install, If "clean install" means wiping the partition table, then yes, same here (`sed 's/slitt/olaf/') but there are occasions where I don't do that and preserve the partition that holds `dirname $HOME` and remount it there. Especially when the machine caters to other users as well. > so I have a choice: > > 1) Do a mass copy of the old /home/slitt tree to the new one, and >probably mess up programs whose config system has changed. What's wrong with fixing issues as they are discovered? I haven't really run into many issues myself in the course of close to two decades. Some programs update their configuration files for you when they discover a version change, others only need a minor tweak. > 2) One by one search the tree for non-config files that are made by >Steve Litt. That this is time consuming is an annoyance. That it's >error prone is very, very bad. You could track your hand-crafted files elsewhere and copy from there (or symlink to it). Personally, I use vcsh in combination with myrepos to version control sets of configuration files. This lets me share my configuration tweak across machines and activate only those sets I need on a particular machine. > There's also the matter of backup. Do I really want to back up 40,000 > files worth of cache to back up my home grown data? Not this iteration > of Steve Litt. olaf@quark:~$ find -type f | wc -l 239613 olaf@quark:~$ find .cache/ -type f | wc -l 28202 # if I look harder I can bump this to ~32,000 I don't know what you use as your backup solution but I have found rsync in combination with .rsync-filter files to exclude stuff a quite decent solution for my $HOME. That is, after you get your .rsync-filter files in shape but th
[DNG] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Olaf Meeuwissen said on Mon, 18 Oct 2021 18:52:05 +0900 >Hi Steve, > >Steve Litt writes: >> On more thing. When *I* write a program, I never put it in /usr/bin >> or /usr/local/bin or /opt. I have my own directory, called /d/bats >> (last century it was called D:\BATS when I used Windows), to contain >> all executables [snip] >Might I suggest $HOME/bin :-) ~/bin isn't ideal for two reasons: 1) It's integrated with all sorts of config, cache, and who knows what, and can easily be lost or wiped out in a re-installation. 2) On a *personal* computer, a place to store all self developed data is needed. I have nothing against the standard File Hierarchy System (FHS) for servers. It works, it's stood the test of time for 40 years, and it's standard. How different things are on a *personal* computer. On a server, it's all about the computer (virtual or metal), and the user is incidental. On the personal computer, it's all about the user, and the computer is incidental. On a server, it's just fine (sort of) to store all locally developed and/or used data, config and executables under /usr/local. But on a personal computer I sure wouldn't want to store my stuff in a directory owned by root, or under a directory owned by root. I want it in a directory fully navagable by slitt all the way down. So isn't that what /home/slitt is for? Not really. /home/slitt is a huge, disorganized mess with data, config, cache, and all sorts of other stuff. /home/slitt gets destroyed in every clean install, so I have a choice: 1) Do a mass copy of the old /home/slitt tree to the new one, and probably mess up programs whose config system has changed. 2) One by one search the tree for non-config files that are made by Steve Litt. That this is time consuming is an annoyance. That it's error prone is very, very bad. There's also the matter of backup. Do I really want to back up 40,000 files worth of cache to back up my home grown data? Not this iteration of Steve Litt. About /home/slitt/bin: Wel, maybe, but if I need a place to put all homegrown anyway, why not put my executables there too, and just put it on my executable path? So I personally defy FHS by creating /d, owned by Steve Litt, to contain all my home grown data, programs, config for those programs, etc. It's really a minor violation of FHS, but it does me immense good. 90% of what I use a computer for is backed up from one tree and laid back down in that tree. My programs. My books. My copy of the Troubleshooters.Com website, and my various other websites. All in one tree, ready to back up or restore at a moment's notice, and small enough to put on some fairly small media, without cache files and downloaded files to bloat me up to Blu-Ray size. My stuff under /d is the important stuff, the stuff whose loss would put me out of business. Losing the other stuff would be in inconvenience. I actually violate FHS in a lot of other ways, which I won't elaborate, to granularize my backup and restore. This works because I'm the one and only user. Some Personal Computer owners shouldn't do this because they're not cognizant of different kinds of data. They should probably do it the FHS way and figure out some backup system, probably brute force back up all drives, to accommodate their backup needs. But for the "power user", FHS violations can be helpful and don't do any harm. 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
