5 ms·

The only criticism I could have of Linux filesystems is that user mounted devices show up in /run?/media/<user>/<device> rather than ~/media/<device>. Otherwise

by zanny 11y ago

The only criticism I could have of Linux filesystems is that user mounted devices show up in /run?/media/<user>/<device> rather than ~/media/<device>. Otherwise everything a user does or makes is showing up under ~ somewhere, and the superuser's stuff resides in a mix of /etc, /root, and /usr. Well, I'll take that back, the fact the config folder is hidden by default is also kind of sucky, and the habit of some software putting configuration data in ~/.local/share and some applications putting non-config data in ~/.config is extremely annoying but should be solved on a per-application basis. Just a few offenders on my desktop in config: * Chrome/ium stores extensions in .config rather than share. Those take up 600MB each in my config folder on my system. * Qupzilla has a profile network cache of 32MB in config. * Brackets has 14MB of cache data in config. * Clementine puts its indexing databases in config. * Spideroak puts everything in config - its index database and snapshots. I'm not as familiar with offenders putting configurations into share, but I know at least KDE's kscreen puts monitor layouts in share/kscreen when they belong in config/kscreen. I'd like to see Ubuntu, Arch, or Fedora (the big distros with the market share to push for best practices) enforce disk quotas on config directories - ie, a program cannot use more than 5MB of space there, akin to localstorage's limit and the intent to use it as a config store rather than persistent data store which is what indexdb / share are. Also, .config should just be config. No dot. Users need to configure their stuff, they should be able to see it.

vram22 11y ago
>I'd like to see Ubuntu, Arch, or Fedora (the big distros with the market share to push for best practices) enforce disk quotas on config directories - ie, a program cannot use more than 5MB of space there Potentially useful idea, in general. There used to be a quota feature on some Unix versions (SVR3 etc, IIRC), with commands to both set and get quotas, though I never really used it. Update: Just googled for "Linux disk quota", and some links show that there seems to be some support. But it is per file system, not per directory. though per-user limits seem to be supported too. But even if a per-directory limit could be enforced, how would you get around the fact that the program could create files in other dirs than the controlled ones, under your overall home dir (as long as they had write permission)? I supposed some kind of script-based monitoring could be improvised, but it might be a kludge ... and even if you could detect it in near real time, it wouldn't be a good idea to kill the process responsible. Interested to know if there are any other methods or approaches. Restricting write permissions could be the basis for one approach.
- zanny 11y ago
  MAC addresses your later concerns. The fact Arch does not support MAC at all then becomes somewhat of a problem, but it is already a huge problem to begin with. You can simply make SELinux / Apparmor profiles that default-restrict applications to ~/.config/<appname> and ~/.local/share/<appname> with quotas. Applications that need exceptions would be shipped with apparmor or selinux profile files to amend that. Its also how you can make desktop Linux a lot more sophisticated in permissions management for applications. I know Apparmor at least supports the idea of network, peripheral, and display access in the same way it controls directory access. It would be a huge usability and security boon to the Linux desktop to have notifications of requests to access resources when an application does so - I think Android 6 is absolutely going in the right direction on application control, and adopting those ideas would be valuable.
  - vram22 11y ago
    Interesting, thanks. Will check out those topics. Agree on the general point of the security benefits.
  - vram22 11y ago
    >MAC addresses your later concerns. What's MAC,, in the context I wrote about? Googled a bit, being a common acronym as well as abbreviation for Macintosh makes it difficult to find the right links.
    - vram22 11y ago
      Ok, never mind, found it under Wikipedia link for AppArmor: https://en.wikipedia.org/wiki/Mandatory_access_control https://en.wikipedia.org/wiki/Mandatory_access_control
astazangasta 11y ago
I have never had to edit anything in .config in decades of using Linux. Dotfiles are hidden for a reason, you shouldn't have to edit them by hand very often, and most heavy applications (e.g. Chrome) have their own configuration interface that will edit them for you. I think the . is a fine convention for easily separating configuration space from work/project data space.
- kevinmgranger 11y ago
  I think it's worth noting that the reason dotfiles are hidden was originally a bug: https://plus.google.com/u/0/+RobPikeTheHuman/posts/R58WgWwN9jp https://plus.google.com/u/0/+RobPikeTheHuman/posts/R58WgWwN9...
  - vram22 11y ago
    Yes, saw that a while ago, interesting. Getting to know the reason after years of using Unix, because the info only came out recently (AFAIK) ...
  - adrusi 11y ago
    That's not the reason why "dotfiles" are hidden, that's the reason that files whose names begin with dots are hidden. "Dotfile" refers specifically to user-local configuration files, which almost always have filenames that begin with a dot, or are located within a directory whose name begins with a dot. Dotfiles are hidden because some people decided that configuration files ought to be hidden from the user during normal activities and so they took advantage of the originally-a-bug-feature of hidden files. This became the standard practice because at the time there was no agreed-upon location for user-local configuration (as existed for system-level config in the form of /etc), so the most logical thing to do was to just put config files inside $HOME. This clutters up the home directory, and so hiding these configuration files made sense.
- loudmax 11y ago
  Hidden from whom? Regular users? Very few regular people are using Linux or any variant of Unix other than OS X on a desktop. Those of us who install Linux are the kinds of people who are most likely to mess with deep system settings anyway. Even my kids go into their .minecraft directory to install mods.

by zanny 11y ago

vram22 11y ago

>I'd like to see Ubuntu, Arch, or Fedora (the big distros with the market share to push for best practices) enforce disk quotas on config directories - ie, a program cannot use more than 5MB of space there Potentially useful idea, in general. There used to be a quota feature on some Unix versions (SVR3 etc, IIRC), with commands to both set and get quotas, though I never really used it. Update: Just googled for "Linux disk quota", and some links show that there seems to be some support. But it is per file system, not per directory. though per-user limits seem to be supported too. But even if a per-directory limit could be enforced, how would you get around the fact that the program could create files in other dirs than the controlled ones, under your overall home dir (as long as they had write permission)? I supposed some kind of script-based monitoring could be improvised, but it might be a kludge ... and even if you could detect it in near real time, it wouldn't be a good idea to kill the process responsible. Interested to know if there are any other methods or approaches. Restricting write permissions could be the basis for one approach.

zanny 11y ago
MAC addresses your later concerns. The fact Arch does not support MAC at all then becomes somewhat of a problem, but it is already a huge problem to begin with. You can simply make SELinux / Apparmor profiles that default-restrict applications to ~/.config/<appname> and ~/.local/share/<appname> with quotas. Applications that need exceptions would be shipped with apparmor or selinux profile files to amend that. Its also how you can make desktop Linux a lot more sophisticated in permissions management for applications. I know Apparmor at least supports the idea of network, peripheral, and display access in the same way it controls directory access. It would be a huge usability and security boon to the Linux desktop to have notifications of requests to access resources when an application does so - I think Android 6 is absolutely going in the right direction on application control, and adopting those ideas would be valuable.
- vram22 11y ago
  Interesting, thanks. Will check out those topics. Agree on the general point of the security benefits.
- vram22 11y ago
  >MAC addresses your later concerns. What's MAC,, in the context I wrote about? Googled a bit, being a common acronym as well as abbreviation for Macintosh makes it difficult to find the right links.
  - vram22 11y ago
    Ok, never mind, found it under Wikipedia link for AppArmor: https://en.wikipedia.org/wiki/Mandatory_access_control https://en.wikipedia.org/wiki/Mandatory_access_control

astazangasta 11y ago

I have never had to edit anything in .config in decades of using Linux. Dotfiles are hidden for a reason, you shouldn't have to edit them by hand very often, and most heavy applications (e.g. Chrome) have their own configuration interface that will edit them for you. I think the . is a fine convention for easily separating configuration space from work/project data space.

kevinmgranger 11y ago
I think it's worth noting that the reason dotfiles are hidden was originally a bug: https://plus.google.com/u/0/+RobPikeTheHuman/posts/R58WgWwN9jp https://plus.google.com/u/0/+RobPikeTheHuman/posts/R58WgWwN9...
- vram22 11y ago
  Yes, saw that a while ago, interesting. Getting to know the reason after years of using Unix, because the info only came out recently (AFAIK) ...
- adrusi 11y ago
  That's not the reason why "dotfiles" are hidden, that's the reason that files whose names begin with dots are hidden. "Dotfile" refers specifically to user-local configuration files, which almost always have filenames that begin with a dot, or are located within a directory whose name begins with a dot. Dotfiles are hidden because some people decided that configuration files ought to be hidden from the user during normal activities and so they took advantage of the originally-a-bug-feature of hidden files. This became the standard practice because at the time there was no agreed-upon location for user-local configuration (as existed for system-level config in the form of /etc), so the most logical thing to do was to just put config files inside $HOME. This clutters up the home directory, and so hiding these configuration files made sense.
loudmax 11y ago
Hidden from whom? Regular users? Very few regular people are using Linux or any variant of Unix other than OS X on a desktop. Those of us who install Linux are the kinds of people who are most likely to mess with deep system settings anyway. Even my kids go into their .minecraft directory to install mods.