101–110 of 156 posts
Earlier quoted context omitted.
I'd like it if I didn't need a Google account to read anything on it.
Well be happy then, you don't need a Google account, as can be seen by entering the url in an Incognito window.
Earlier quoted context omitted.
> I see no benefit. The first benefit is that it removes clutters from your $HOME. The second benefit is that you can now manage and backup your settings in a sane way. * ~/.config contains config files (should not be lost, but if lost you can recreate them); * ~/.local contains user data files (save them often, never lose them for they are not replaceable); * ~/.cache contains cached information (can be tmpfs mounte…
> The first benefit is that it removes clutters from your $HOME. Invisible clutter? That's a strange concept. But the rest of your point indeed makes sense. It still is easier and probably comment to backup the whole $HOME. But those points you can see as a benefit, though not obvious.
Earlier quoted context omitted.
> I see no benefit. The first benefit is that it removes clutters from your $HOME. The second benefit is that you can now manage and backup your settings in a sane way. * ~/.config contains config files (should not be lost, but if lost you can recreate them); * ~/.local contains user data files (save them often, never lose them for they are not replaceable); * ~/.cache contains cached information (can be tmpfs mounte…
> The first benefit is that it removes clutters from your $HOME. Invisible clutter? That's a strange concept. But the rest of your point indeed makes sense. It still is easier and probably comment to backup the whole $HOME. But those points you can see as a benefit, though not obvious.
Earlier quoted context omitted.
OSX, because of its big corporate watchdog, and the separation of the 'GUI' layer and the unix layer, has the cleanest directory structure by far IMO. Most of the times you don't even need a manpage or google to find out how to repair a misbehaving application - just delete its plist in ~/Library/Preferences, possibly also its ../ApplicationSupport directory. The OSX defaults system is so well designed, every time I…
Why can't I reply to some comments? That comment about the new sandboxed folder structure made me realize he's right. What's going on with all those symlinks inside the container directory? This just shows to me what a bad idea sandboxing is for those kind of apps that are supposed to interoperate with the whole system. Is there even a security benefit vs. pure unix permissions if you sandbox the filesystem but then…
Dotfiles provided a poor, but at least simple way to store program-specific-user-specific configuration, since another standard was missing. After all it's a simple and decentralized system that worked very well with the concept of unix user and ACL: you write something inside your home directory, and this changes the behavior of your program.
Consider that this was invented many decades ago. Now it seems a lot better to have directories with sub directories. Maybe back then it was considered to be a waste of resources, inodes, and so forth.
We can improve it, create a new standard, and have something better than dot files, but dot files are better than many other over-engineered solutions that I can imagine coming out of some kind of design commission to substitute them.
Every time to passed your vim configuration to a friend you just copied a text file, sending it via email: you enjoyed one of the good points about dot files. Every time you did something like cat dotfile | grep option you enjoyed the positive effects of single-file plaintext configuration.
Also it's worth saying that dot files are not just the concept of an hidden file with config inside. A lot of dot files also have a common simple format of multiple lines " ", that's better than some XML or other hard to type format (IMHO JSON itself is not good for humans).
dotfiles are not perfect, but to have this very negative vision on a feature that also helped is a bit a revisionist attempt IMHO. Dotfiles provided a poor, but at least simple way to store program-specific-user-specific configuration, since another standard was missing. After all it's a simple and decentralized system that worked very well with the concept of unix user and ACL: you write something inside your home d…
Earlier quoted context omitted.
> The first benefit is that it removes clutters from your $HOME. Invisible clutter? That's a strange concept. But the rest of your point indeed makes sense. It still is easier and probably comment to backup the whole $HOME. But those points you can see as a benefit, though not obvious.
As Rob mentions in his post, the more dotfiles there are in $HOME the slower path resolution for any subfiles becomes. How do we navigate to ./src? We open the directory and read all the entries until we find the one called "src". What happens if we encounter a morass of dotfiles beforehand? src takes a while to find. The clutter may be invisible to you , but it does gum up the works.
Earlier quoted context omitted.
I see no benefit. It's not at all easy to understand, nor easy to implement, nor does it have any tangible advantages. It's one of these superfluous pseudo-standards that do nothing but add needless clutter. But gladly nobody seems to be using it anyway, I see only one directory in my ~/.local: vlc.
> I see no benefit. The first benefit is that it removes clutters from your $HOME. The second benefit is that you can now manage and backup your settings in a sane way. * ~/.config contains config files (should not be lost, but if lost you can recreate them); * ~/.local contains user data files (save them often, never lose them for they are not replaceable); * ~/.cache contains cached information (can be tmpfs mounte…
And for the backup-case: Whitelisting is usually a futile idea to begin with. Normally you'd prefer to backup the odd superfluous file rather than miss an important one.
Luckily most of the apps used on Linux systems now use it
Excuse me?
$ find ~ -maxdepth 1 -name ".*" | wc -l
228
$ find ~/.local | wc -l
4
$ uname
LinuxEarlier quoted context omitted.
Where would you choose to put application config instead?
Literally anywhere but my personal space. Why not have /etc/ /? I could even live with a single ~/.config/ but very few apps use that.
The canonical example is the backup. There's a strong case to be made for "tar czf /tmp/backup.tgz ~". Do you really want your backups to become as complicated as they are on OSX and Windows?
Likewise, being able to mount home-directories from remote servers, and being able to easily delete/move/quota users are highly desirable features in multi-user systems.
Earlier quoted context omitted.
As Rob mentions in his post, the more dotfiles there are in $HOME the slower path resolution for any subfiles becomes. How do we navigate to ./src? We open the directory and read all the entries until we find the one called "src". What happens if we encounter a morass of dotfiles beforehand? src takes a while to find. The clutter may be invisible to you , but it does gum up the works.
For what it's worth, most modern file systems (JFS, XFS, ext4, reiserfs, btrfs, ...) have logarithmic (or better) directory lookup times. This is achieved using hashes and b-trees (or even hash tables).