Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dotfile madness

0x46.net

Post reply on HN
Print view View original

401–410 of 534 posts

Re: Dotfile madness

#401

Post by airstrike »

pvg wrote: post #324
nycticorax wrote: post #119

To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't b…

But nowadays, lots of applications seem to think it's OK to put normal files in my home folder without asking first. This is just outright barbarism. If every desktop application that needed to store cross-invocation state asked for permission we'd probably say it was an invasion of bad-design huns.

%APPDATA% doesn't require permission

Re: Dotfile madness

#402

Post by eeeeeeeeeeeee »

I definitely have looked at my home directory in awe at the number of dot files, but I think the article is a bit hyperbolic. I get that it's "clutter" but I think the simplicity of storing configuration in $HOME might be worth that trade-off.

Even the $XDG_ env variables still require the user to set that up, or the OS maintainer needs to set it up. If the OS maintainer sets it up, the user probably won't know where to find configuration.

The reason $HOME is so commonly used is because the developer knows with almost 100% certainty that the unprivileged user will 1) be able to read/write to it without superuser privileges and 2) it keeps all configuration data contained in the user's home directory for portability, instead of throwing it all over the file system in locations nobody will know.

That portability will come in handy when you're backing up or restoring from backups, which I just did yesterday. It means restoring is as simple as copying your entire home directory back. I don't need to tell each app where my configuration is, it just knows it will be in $HOME.

And that assumption will be correct for almost any *NIX-based operating system.

I do agree that non-dotfiles should not be created in $HOME, that is a nuisance.

Re: Dotfile madness

#403

Post by eeeeeeeeeeeee »

ljm wrote: post #232
nycticorax wrote: post #119

To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't b…

This strongly reminds me of installing software on Windows, where most games and programs would use My Documents as a dumping ground.

Which is sort of an improvement from the past, where user-level config data was thrown into the actual app directory in "program files." So if you ever wanted to back-up those settings, you needed to track down every single unique location for each app.

Re: Dotfile madness

#404

Post by krferriter »

nycticorax wrote: post #119

To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't b…

Yeah it is crazy when I noticed Ubuntu created a ~/snap folder that is required when anything is installed via snap. People defend placing application data/config folders in ~/ because they're old and it's always been like that, but Snap is brand new and they still neglected to follow the modern standard.

Other "new" softwares that fail to follow best-practices by putting top level files into ~/ just on my laptop are: npm, Ansible, pylint, docker, steam, rustup+cargo, vscode, IDEA IDE, Zoom, AWS CLI. These applications have no excuse.

Also I agree on the Documents, Music, Video, etc. I hate upper case letters in my folders, so when I do a reinstall I delete those and restore my backups from the lower-case versions.

Re: Dotfile madness

#405

Post by eeeeeeeeeeeee »

sakoht wrote: post #252

The real problem is that any app I run accesss all files I own with equal permissions. App1 and App2 shouldn’t write their data to my home, or read each other’s data, or, please, be able to write each other’s data. A video game can read my tax forms. WTF. Mobile & tablet OSs solve this. Everything has to follow. Until then, basically every app should run in a docker container. Then it can do what it wants.

It seems like MacOS has been headed in this direction, at least with the App Store apps. But it's a hard problem to elegantly implement without breaking everything.

I still see a lot of Mac apps that basically say "disable system protection first."

Re: Dotfile madness

#406

Post by saagarjha »

h1d wrote: post #399

Homebrew just started offering Linux support but they would put stuff under /home/linuxbrew/ but wtf is this about? Won't be using until this is fixed. https://docs.brew.sh/Linuxbrew

I haven't used Linuxbrew, but Homebrew is kind of finicky if you try to install anything to a non-standard folder. I remember a while back they used to say "you can change the default folder" but then later said that this was not recommended.

Re: Dotfile madness

#407

Post by eletious »

eeeeeeeeeeeee wrote: post #402

I definitely have looked at my home directory in awe at the number of dot files, but I think the article is a bit hyperbolic. I get that it's "clutter" but I think the simplicity of storing configuration in $HOME might be worth that trade-off. Even the $XDG_ env variables still require the user to set that up, or the OS maintainer needs to set it up. If the OS maintainer sets it up, the user probably won't know where…

You missed the point - they default to a dotfolder where all of those dotfiles go. You likely already have one!

The default is there to allow users and OS maintainers to not worry about it. It still goes in your home directory, but at least it's organised.

Re: Dotfile madness

#408

Post by krferriter »

Aeolun wrote: post #354
nycticorax wrote: post #119

To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't b…

I have great difficulty understanding why the snap developers think the excuse “it’s hard to change!” flies. If it’s hard to change, you should’ve either fixed your architecture from the start, or thought a bit harder about the implications of magically creating a new directory in $HOME.

It shouldn't be hard to change unless the string "/snap" is hardcoded all over the codebase. There should be a function like "get_app_dir" or "get_install_dir" or some other config string lookup that doesn't use a static string.

Re: Dotfile madness

#409

Post by eeeeeeeeeeeee »

saagarjha wrote: post #406
h1d wrote: post #399

Homebrew just started offering Linux support but they would put stuff under /home/linuxbrew/ but wtf is this about? Won't be using until this is fixed. https://docs.brew.sh/Linuxbrew

I haven't used Linuxbrew, but Homebrew is kind of finicky if you try to install anything to a non-standard folder. I remember a while back they used to say "you can change the default folder" but then later said that this was not recommended.

Yep, I tried to run mine in ~/.homebrew but gave up. I can't remember why, but stuff was breaking and it was clear Homebrew didn't want you to do it.

I've spent some of my career building packages from source and I know the assumptions you get stuck with because the app developer hard-codes certain things. So it makes sense they just go for what is most standard and expected.

Re: Dotfile madness

#410

Post by zapzupnz »

zackmorris wrote: post #241
chrisweekly wrote: post #195

Related pet peeve: macOs '.DS_Store' files. Can someone better-informed than me please explain how to prevent heir creation? Barring that, I'd settle for a justification.

They're a bug/feature from the early days of OS X. Apple should have done the work of storing directory metadata in something like ~/Library/Preferences/com.apple.finder.plist but they were too busy getting anything at all to work. This is the type of low hanging fruit that Apple evidently doesn't care about anymore, but would go really far towards improving user sanity. It's like when you go to a restaurant and orde…

> This is the type of low hanging fruit that Apple evidently doesn't care about anymore

This is an unfair comment, showing you don't know _why_ those files exist. They're an ugly tradeoff, but they serve a purpose.

Dot files and .DS_Store files are meant to replicate the movement of metadata that Classic Mac OS achieved with creator codes and whatnot, as well as the layout settings for the folder. Those files need to be in the same directory as the files/folder because Finder knows to copy those files as well.

Finder saves the layout options and settings for each individual folder, harkening back to the spatial Finder of Classic Mac OS. It's an integral feature of the system enabled by default. It would be an absolutely terrible idea for Apple to put the preferences for every single folder to which the user has navigated in one preference file, especially given that it would need to be updated whenever files/folders undergo any CRUD operation.

> but would go really far towards improving user sanity

99.9% of the time, users don't notice this at all. Those files are currently everywhere on a macOS system, but nobody sees them. The only time they really come up is when you're using ``ls -A`` or copying files to Windows; apart from then, they're truly invisible.

What Apple should do is provide an option to not copy the dotfiles and .DS_Store files to USB sticks, especially if they're FAT32 or ExFAT format. That's a better solution than one huge preference file of shame.

Post reply on HN