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

521–530 of 534 posts

Re: Dotfile madness

#521

Post by joshvm »

int_19h wrote: post #491
joshvm wrote: post #421

Earlier quoted context omitted.

> The problem is that so many apps just straight up ignore all those guidelines. The fact it happens so often suggests that the documentation isn't good enough. > Of course. At least Apple's pages is pretty clear and has some nice diagrams. I think this page is more appropriate: https://docs.microsoft.com/en-us/windows/desktop/shell/csidl It's reasonably well documented for UWP, though I can't find an equivalent for…

> The fact it happens so often suggests that the documentation isn't good enough. Any library or framework author knows that documentation is never enough. ~ On Windows, though, there's also historical reasons - back in Win9x days, there was no practical reason for apps to bother if they didn't anticipate running on NT, which is why it was so common to just dump configs next to the .exe (and even to this day, Windows…

> This page describes pre-Vista, deprecated APIs. Unless you need to target XP, a desktop app should use the known folder mechanism.

Actually the current documentation refers you to the CSIDL list if you want to know what any of the GUIDs actually mean. The new docs just provide a list of IDs with minimal information.

See https://docs.microsoft.com/en-us/windows/desktop/shell/known...

Re: Dotfile madness

#522

Post by WorldMaker »

wongarsu wrote: post #445
airstrike wrote: post #400

Earlier quoted context omitted.

C:\ isn't protected by UAC like C:\Program Files, though

Steam is doing just fine writing into C:\Program Files (x86)\Steam\steamapps from an unpriviledged process. It just gives all users full rights over that folder. (whether that's a great idea is a different question, but UAC isn't a problem if you just set your access rights correctly)

Steam has definitely been handling Program Files wrong for as long as Program Files has existed. It's a marvel that there isn't more historic Malware intentionally targeting Steam install paths, though it looks like that storm is brewing on the horizon as I've seen references to such malware in the process of becoming a problem.

Steam should have worked to figure out a better approach to UAC years ago. At this point it is one of several big tech debt issues with Steam that has my confidence in Valve at an all time low as a consumer.

Re: Dotfile madness

#523

Post by WorldMaker »

gesman wrote: post #386
teknopaul wrote: post #319

Earlier quoted context omitted.

Most people like to separatly store data and executables for good reasons.

\Programs\VendorX\ProgramY\data \Programs\VendorX\ProgramY\code

The problem there is "how lazy is VendorX"? With \Program Files\ Microsoft has a ton of top level ACLs to lock down access to the directories that everything just inherits by default. How much work does the OS need to do to allow something like "folders named `data` under \Programs\ have ACLs XData and `code` have ACLs YCode"? Does it need to watch for silly mistakes like Devs that localize `code` (`Código` for instance) or misspell it (`ocde` or `coode`)?

Re: Dotfile madness

#524

Post by Spivak »

krferriter wrote: post #404
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…

You can customize those 'well known' directories.

https://www.freedesktop.org/wiki/Software/xdg-user-dirs/

The Arch wiki has more instructional docs:

https://wiki.archlinux.org/index.php/XDG_user_directories

Re: Dotfile madness

#525

Post by Spivak »

pmontra wrote: post #253
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.

You can create another user and sudo / gksudo to it when working on sensitive data. It never occurred to me before reading your comment. I could start doing it myself.

You can do better than entirely separate accounts. You could use a user namespace (i.e. subuid/subgid) for sensitive data.

Re: Dotfile madness

#526

Post by eithed »

On Windows I've never put anything in C:/, yet I have a shitload of install.res.xxxx.dll files, shitload of eula.xxxx.txt files, globdata.ini, vcredist.bmp, install.ini, VC_RED.msi. In my home folder I've .QtWebEngineProcess folder (never installed qt), .mongorc.js (which is empty), .v8flags.xxxx.json, .dbshell, and so on and so on. I'm not delving into insanity which is /Program Data, Windows/Temp, or [user]/AppData

Re: Dotfile madness

#527

Post by JdeBP »

notyourday wrote: post #520
JdeBP wrote: post #519

Earlier quoted context omitted.

"you renamed a wrong file" shows that "there's no guarantee that you are renaming the file you just wrote to".

In this case you know that you renamed a wrong file. In the close before rename you do not know that you have renamed a wrong file.

Knowing that something bad happened after the fact is not the same as your idea that there's a guarantee that something bad will not happen.

Re: Dotfile madness

#528

Post by darkmighty »

pmontra wrote: post #330
darkmighty wrote: post #312

Earlier quoted context omitted.

su - also works. Indeed the capability exists (unix/linux pioneered it?), but it relies on manual containment by the user. It should be automated, with prompts at install or execution time, like on mobile OSs. An idea is each file should have its own user, basically, with both relative and absolute file creation/modification permissions. If you run an arbitrary executable as a user there's great security risk since i…

There are differences between the apps I use on my phone and the programs I use on my PC. I don't trust many of the apps on my phone (all of Google, FB, messaging, etc). I trust the open source apps (example K9 email) and I'm replacing proprietary apps with open source ones. I trust almost all programs I use on my PC, which I install with apt-get from Ubuntu or other open source PPAs (no snap, no flatpack). There are…

Valid point. I thought about this, for system apps you would be able to assign lasting permission requests to read/write/modify anything., by default -- so it would work as right now. Just like in browsers, permissions (permission type prompt) could be remembered in a cache. If you're not comfortable with giving any command full reign on your system, you could simply give granular, temporary permissions as required.

A concept I find useful is that there are two kinds of security:

-- Accidental security

-- Malicious security

Permissions help with both. Not only you don't want 3rd parties to invade or disrupt your system, you don't want users to invade or disrupt your system (or their own systems) accidentally.

A classic example I believe is an user wanting to delete all files in current directory, typing

  $ sudo rm ./*
and missing the dot, getting

  $ sudo rm /* #(delete *all files*)
Ideally in this case you would see two different requests:

  > The command rf requests root access for file deletion at /
  > Accept? (y/N)
  > User's administrative password:
or

  > The command rf requests access for file deletion at /home/user/cache/
  > Accept? (Y/n)
Note you're not prompted for password in the second case because you already have permissions for this operations (only the process 'rf' doesn't).

You may not be particularly worried about malicious security for system programs, but even professional administrators could be worried about accidental security and best practices (if they're not they could easily select persistent full permissions). I get the impression the last thing e.g. sysadmins want is mess up production systems, and wouldn't mind a few more prompts when doing things manually (which should be rare?), or assgining scripts the exact permissions needed for their job.

Re: Dotfile madness

#529

Post by gerdesj »

dbrgn wrote: post #506
gerdesj wrote: post #219

Earlier quoted context omitted.

I've only been using Linux for around 10 years as my only desk and laptop OS and this is the first I heard of XDG user dirs! This laptop runs Arch. Thanks for the heads up. I'll drop "/etc/papersize" in return. If you are not familiar with this and do not print to letter paper then you will find it very, very useful.

Oh wow. If this does what I think it does, I'll be forever grateful for that comment.

It really does make CUPS, Libre Office and all the rest believe you when you say "I want to print on A4, yes A4, no not fucking Letter, A4, end of!" Obviously, substitute your paper size of choice. It probably even lends itself to some form of scripting and perhaps could be changed in reaction to events from say NetworkManager. Whatever.

My life at home is now worth living every time the wife hits print. Such a simple idea - brilliant.

Re: Dotfile madness

#530

Post by zapzupnz »

zackmorris wrote: post #487
asveikau wrote: post #367

Earlier quoted context omitted.

Leaving it next to the files means if directories are moved, copied, or renamed, the metadata is still there. So you or I might prefer it to live in a separate file under ~/ but I cannot say littering the whole tree with the metadata buys nothing or can't serve a purpose.

macOS knows when files and directories are moved via inodes: https://eclecticlight.co/2018/03/03/how-macos-tracks-your-fi... so I can't see any conceptual reason to keep .DS_Store.

Because macOS doesn't know when files and directories are moved on other devices, network drives, etc.

Nor can it preserve that metadata across other devices, network drives, etc. without copying it across somehow; the easiest solution was to store that data in hidden files and let Finder handle their automatic transfer.

Failure of your imagination isn't failure on someone else's part.

Post reply on HN