361–370 of 534 posts
Earlier quoted context omitted.
Same for the default gopath. That was horrifying the first time. At least you can override it.
Default gopath was just a way to let newbies get up and running quickly; it originally required you to specify where to put it. I imagine they put it at ~/go so it would be glaringly obvious. Hopefully modules will render it all moot anyway.
Earlier quoted context omitted.
It avoids the realization that you have been paying AWS to back up ~/.cache and ~/.local for the last 6 months.
The article says the standard is to put data in ~/.local/share/ So I guess if any of your applications have important data, you better back it up! (I learned today)
* My definition of "garbage" in this context is stuff I don't miss if I wipe the machine, reinstall the OS and the app, and sign in again.
Earlier quoted context omitted.
There's a very simple solution to this: Don't run apps that you don't trust. If you simply must , use a VM or AppArmor or SELinux. Don't inconvenience everybody because you're too lazy to be responsible for your own data. Besides, untrustworthy apps will bypass the protections anyway. Judging by the popularity of "curl | sudo bash" lately, they'll probably just ask for root directly.
>a few users are too lazy Running untrusted programs is the default way we do computing. No one has time to audit every single program they run. The current desktop security model comes from when people mostly ran the programs that came with the OS and programs they wrote themself. Its vastly inappropriate for modern computer usage.
Even that isn't particularly safe.
The lack of useful names on the files is IMHO the most egregious issue. (OK using names that don’t start with ‘.’ is worse). I don’t ls -A my homedir as much, but what the hell are .517827.padl? Who created .android (I don’t use android and don’t develop for it) etc. These people are arrogant shitheads and I’d like to know who they are so I can avoid their software. I assume if they do crap like this their software d…
> These people are arrogant shitheads and I’d like to know who they are so I can avoid their software. Wow, this is really assuming the worst in people. It’s much more likely to be ignorance because the other developer doesn’t know where the file came from either (some compiler flag on a library accidentally enabled), or also doesn’t ls -a in their home.
Perhaps having all parts of this chain called "shithead" is extreme but they would all have responsibility and disrespect for the user.
Oddly I feel completely the opposite about this topic. I think dot files in your home directory are exactly the way to go. Using the XDG standard leaves you with whatever the distro decides is the correct location for these files. While their recommendation is all in the home directory, I wouldn't put it past some of these distro developers to make some crazy /var/users/{uid}/config directory. This is important when…
At my university I only have write permissions in my home folder so I prefer this too and I only need to backup my home directory as well.
Earlier quoted context omitted.
It avoids the realization that you have been paying AWS to back up ~/.cache and ~/.local for the last 6 months.
The whole point of .cache is that it's supposed to be that one folder that you know you shouldn't back up. As opposed to a dozen different app-specific ones that we have today.
My comment wasn't meant as a criticism of the basic idea of a standard directory scheme; it was a reply to someone asking why anyone would ever care about files you can't see.
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…
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…
> And of course, all this is on top of the new fashion for the OS to "helpfully" create Documents, Music, Video, etc folders in my home folder, and set the XDG environment variables to point to them. Noooooope. Yuuuup. It baffles me how Linux users can simultaneously complain that 'its never the year of the Linux desktop' and then at the same time rile against basic usability tenets. The average users wants/needs Doc…
Earlier quoted context omitted.
Associating tags with files is straight forward. What's not quite so straight forward is how you query the system. The worst implementations of file tagging only implement retrieving a list of all files that have a given tag. Slightly better than this are tagging systems that will return the intersection between two or more tags. Most tag systems never go beyond this. Going slightly further, tag exclusions are powerf…
Wasn’t this the whole idea and purpose of the successor to NTFS which was supposed to ship with Longhorn/Vista? What happened there?