Re: XDG Standard is not evil (was: Re: Why focus on systemd?)
Le 28.11.2014 15:32, Rusi Mody a écrit : However there are some issues: if the software-versions in these dont match up then its precisely these XDG files that tread on each others' toes across OSes. Well... if configuration files are not both upward and downward compatible between different versions, which could be both major, minor, Ubuntuesque or googlesque (yes, I do think that Ubuntu and chrome/firefox version schemes are stupid) I do not see where is the problem. After all, why, in the first time, do you need on the same computer different versions of the same software, if not for testing/development purposes? And in those purposes, you probably know how to change the default directory, right? On correct softwares, there is a command-line option for that, like -c, --config, or sometimes -C. No issue for me here but... One solution that Ive been toying with is as follows: 1. Have one real My-home partition 2. Keep /home as part of the OS-file system, so that each OS can mess around with its own 'XDG's' I wonder if people have tried this (or something similar) and any downsides Here, you know, you could be smarter. XDG directories are defined by environment variables. So, why not using, for example, in you .profile, something like this: $cat ~/.profile #!/bin/sh case $( grep PRETTY_NAME /etc/os-release |cut -f2 -d'' ) in Debian GNU/Linux jessie/sid) XDG_FOOBAR_STUFF=~/.config/jessie *) echo hey, I have no idea what distro this is? esac But, of course, it won't work with, for example, vim, bash, and plenty of softwares which... DO NOT respect XDG things. Oh, and I used /etc/os-release, which is not always present because... it's a part of XDG, AFAIK. But, you can do this by grepping/sedding in some mount on labels or whatever trick you want to identify the system on which you actually are. This is clean, and efficient. Far better that what you could achieve *without* XDG. Yes, I like xdg, between other reasons because it does not impose things: good softwares (for example, i3) allows the user to choose, if he want or not to use XDG. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/457101a6a693f20b243e931a9d3ed...@neutralite.org
Re: XDG Standard is not evil (was: Re: Why focus on systemd?)
Le 27.11.2014 03:04, Serge a écrit : Later some people started to abuse those directories and put there files, that never supposed to be there. Those people don't really think about standards or unification. Usually they just enable displaying hidden files in their file manager, see a lot of dotfiles in a home directory and think that this is wrong. They start searching how to fix this, find xdg basedir-spec, and use it as an excuse for moving ~/.appname files, to ~/.config/appname, or worse, split them among .config, .local, .cache... If only rogues can put their configuration files in a subdirectory of a common directory, then every application is a rogue, since all applications put their configuration files in the $HOME directory or any of it's subdirectories. The point is that, applications using $HOME instead of $XDG_CONFIG_HOME does not only put their configuration there, but all their files. So, thanks to those ones, you will have things like: .bashrc, .bash_history, .dmenu_cache, .prxAEIHar (try to guess what's this file? I myself have no idea... reading it, it seems it's related to xosview?) etc. Ok, now, you only want to save your configuration files. Which ones will you take? Or, for a reason you want to use an application which is not installed on your system, but in a remote file system that you can't access everytime. If this application puts everything in $HOME, then you'll have useless things on your local machine, but if it uses XDG directories, you can mount/bind/whatever the distant directory to a point in $XDG_CONFIG_HOME. Another nice thing: Imagine I use several softwares which are not pieces of an existing monolithic DE. Imagine I would like to write an application to manage configuration of those applications I am using. I will probably have to use the strategy design pattern[1] because configuration formats will differ (key=value in INI-style way, xml-erk-style format...) and have plug-ins to manage those formats, but there are quite common ways, easy to parse, like good ol' INI (like gftp, but you'll probably find many others lying around on your own computer), or ugly (my opinion) XML. Ok, so, we sometimes have common formats, which might be used by several applications I use. So, maybe we could find some which shares common features? Like, for example, binding a shorcut to open a file (pretty common, right?) or move your character in an FPS game? For this, I could ask my plug-ins to extract, in all configuration files of $XDG_CONFIG_HOME, everything which looks like being able to open a file (some regexes on the key's name should do the work in many cases), and refer the folder's name which contains the files to identify which software uses it. Then, I could ask the user if he want to define a new shortcut for some specified set of applications (or to all? Why not?). Ok, then, now, the user can have a way to configure everything on his computer, without those applications having been written to be integrate in any DE. Of course, DEs can use it too, but, I made the choice to not use such things, because I think that there is too much bloat. This would be harder, by far, if every application just puts things, sometimes in $HOME/.application, or $HOME/.application.conf, or $HOME/.application/config or $HOME/.application/application.config (not to speak about those nasty rc files!). Last but not least, it means that one could write a library to manage configuration files, which could be reused, because things goes in some predefined places, in a predefined order. No need to learn that .bash_profile is read before .profile... oh, sorry, bash does not uses XDG dirs. So, I can see advantages. Several ones. I'll try to find the problems now: the application have to be made correctly enough to not trust the content of an environment variable, because it may try to trick the software, for buffer overflows, code injections, or less dangerous things like behavior changing depending on the moment, if the application re-read the environment variable. That's all I can find. They don't think about /etc/xdg, they don't read FHS or other XDG standards, Well... honestly, I would not follow FHS blindlessly, obviously. Because, well... it does not works on Microsoft Windows, first, which is a widely used system, and I prefer to make things portable (so I would use a different mechanism on windows than on Debian to read default configuration files) plus, FHS is not followed in the same way everywhere: in *BSD, I think the softwares you will install through the package manager will not go into /usr/bin, but in /usr/local/bin. On some linux distro, it may go in /opt. How could I know? Even UNIX-style OSes disagree! About other XDG standards, well... I do not have to use dbus stuff to know what directory I should use to store my specific user's configuration, right? they don't care about people who have to do 2-4 times more
Re: XDG Standard is not evil (was: Re: Why focus on systemd?)
On Thursday, November 27, 2014 8:00:05 AM UTC+5:30, Serge wrote: 2014/11/16 Peter Nieman wrote: Has anyone ever wondered where all these funny directories like ~/.cache, ~/.config, ~/.local or even ~/Desktop (with a capital D) came from that appeared in Debian after upgrading to - was it Lenny? Here's an answer: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html People often misunderstand what XDG standards were created for. Imagine that you're writing some graphical application in those old days before XDG standards appeared. And you want to put a link to it to the main menu of your DE/WM. Where would you put it? ~/.gnome2/vfolders/applications? ~/.kde/share/applnk? Maybe .icewm/menu? Or all of them? What if you want to autostart it on login? ~/.kde/Autostart? ~/.kde/share/autostart? ~/.gnome2/autostart? The problem arises when MULTIPLE INDEPENDENT apps need SAME files. So they came together and created XDG standard. It looks like: [autostart-spec] system-wide autostart files are placed in $XDG_CONFIG_DIRS/autostart/ user-specific overrides go to $XDG_CONFIG_HOME/autostart/ based on the desktop base directory specification. [menu-spec] .menu files are placed in $XDG_CONFIG_DIRS/menus/ .desktop files are placed in $XDG_DATA_DIRS/applications/ user overrides go to $XDG_DATA_HOME/applications/ and $XDG_CONFIG_HOME/menus according to the desktop base directory specification. and so on. The Base Directory Specification itself is just html page to reference, a base for other XDG specifications, that's why it's called base. As its original author said [1]: XDG Base Directory spec is intended for use by other specification. For example the XDG Menu specification and Autostart specification refer to the XDG Base Directory specification instead of reinventing their own filesystem locations / hierarchy. It just gives the meaning to directories, used by *other XDG standards*, which brought peace and clarity to the mess of desktop environments. Those XDG standards were created by X Desktop Group only to define unified directories for COMMON files of multiple X desktop environments, not for some rogue applications to hide their own private files. Each of files placed in those directories is extensively documented by other XDG standards. Later some people started to abuse those directories and put there files, that never supposed to be there. Those people don't really think about standards or unification. Usually they just enable displaying hidden files in their file manager, see a lot of dotfiles in a home directory and think that this is wrong. They start searching how to fix this, find xdg basedir-spec, and use it as an excuse for moving ~/.appname files, to ~/.config/appname, or worse, split them among .config, .local, .cache... They don't think about /etc/xdg, they don't read FHS or other XDG standards, they don't care about people who have to do 2-4 times more work to find and migrate settings of selected application to another machine, they just don't want to see dotfiles. But don't blame XDG standard for that, blame people abusing it to reduce the number of dotfiles in their home directory. [1] https://lists.launchpad.net/unity-design/msg02114.html -- Serge I have a question along these lines: Years ago when we used computers, many people used one machine -- centrally administered. Nowadays one person uses many machines 1. Simply multiple hardware 2. Multiple OSes on the same h/w 3. Other more fancy (cloud) usage Just staying with 2. for now and that too only Linux, its a good idea to map the One-me -- Many OSes to One /home -- Many 'slashes' (eg Debian on sda5, Debian 32 on sda7 ubuntu on sda6 etc) However there are some issues: if the software-versions in these dont match up then its precisely these XDG files that tread on each others' toes across OSes. One solution that Ive been toying with is as follows: 1. Have one real My-home partition 2. Keep /home as part of the OS-file system, so that each OS can mess around with its own 'XDG's' I wonder if people have tried this (or something similar) and any downsides -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ba47c259-1d40-4203-aace-499d0218f...@googlegroups.com
Re: XDG Standard is not evil (was: Re: Why focus on systemd?)
I do this on my own machine. The visible stuff I used to keep in my home directory is now in a separate partition mounted on ~/Desktop. I've noticed just one downside: cd no longer takes me to a useful place. So I have an alias called cdd that takes me to Desktop and I'm trying to remember to use it, and I've changed .bash_aliases to cd there as well, so shells start in Desktop rather than the real home directory. Other than that, I like this arrangement just fine. My OSes can all share the Desktop and have their own /home and ~/ directories. On Fri, Nov 28, 2014 at 6:32 AM, Rusi Mody rustompm...@gmail.com wrote: On Thursday, November 27, 2014 8:00:05 AM UTC+5:30, Serge wrote: 2014/11/16 Peter Nieman wrote: Has anyone ever wondered where all these funny directories like ~/.cache, ~/.config, ~/.local or even ~/Desktop (with a capital D) came from that appeared in Debian after upgrading to - was it Lenny? Here's an answer: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html People often misunderstand what XDG standards were created for. Imagine that you're writing some graphical application in those old days before XDG standards appeared. And you want to put a link to it to the main menu of your DE/WM. Where would you put it? ~/.gnome2/vfolders/applications? ~/.kde/share/applnk? Maybe .icewm/menu? Or all of them? What if you want to autostart it on login? ~/.kde/Autostart? ~/.kde/share/autostart? ~/.gnome2/autostart? The problem arises when MULTIPLE INDEPENDENT apps need SAME files. So they came together and created XDG standard. It looks like: [autostart-spec] system-wide autostart files are placed in $XDG_CONFIG_DIRS/autostart/ user-specific overrides go to $XDG_CONFIG_HOME/autostart/ based on the desktop base directory specification. [menu-spec] .menu files are placed in $XDG_CONFIG_DIRS/menus/ .desktop files are placed in $XDG_DATA_DIRS/applications/ user overrides go to $XDG_DATA_HOME/applications/ and $XDG_CONFIG_HOME/menus according to the desktop base directory specification. and so on. The Base Directory Specification itself is just html page to reference, a base for other XDG specifications, that's why it's called base. As its original author said [1]: XDG Base Directory spec is intended for use by other specification. For example the XDG Menu specification and Autostart specification refer to the XDG Base Directory specification instead of reinventing their own filesystem locations / hierarchy. It just gives the meaning to directories, used by *other XDG standards*, which brought peace and clarity to the mess of desktop environments. Those XDG standards were created by X Desktop Group only to define unified directories for COMMON files of multiple X desktop environments, not for some rogue applications to hide their own private files. Each of files placed in those directories is extensively documented by other XDG standards. Later some people started to abuse those directories and put there files, that never supposed to be there. Those people don't really think about standards or unification. Usually they just enable displaying hidden files in their file manager, see a lot of dotfiles in a home directory and think that this is wrong. They start searching how to fix this, find xdg basedir-spec, and use it as an excuse for moving ~/.appname files, to ~/.config/appname, or worse, split them among .config, .local, .cache... They don't think about /etc/xdg, they don't read FHS or other XDG standards, they don't care about people who have to do 2-4 times more work to find and migrate settings of selected application to another machine, they just don't want to see dotfiles. But don't blame XDG standard for that, blame people abusing it to reduce the number of dotfiles in their home directory. [1] https://lists.launchpad.net/unity-design/msg02114.html -- Serge I have a question along these lines: Years ago when we used computers, many people used one machine -- centrally administered. Nowadays one person uses many machines 1. Simply multiple hardware 2. Multiple OSes on the same h/w 3. Other more fancy (cloud) usage Just staying with 2. for now and that too only Linux, its a good idea to map the One-me -- Many OSes to One /home -- Many 'slashes' (eg Debian on sda5, Debian 32 on sda7 ubuntu on sda6 etc) However there are some issues: if the software-versions in these dont match up then its precisely these XDG files that tread on each others' toes across OSes. One solution that Ive been toying with is as follows: 1. Have one real My-home partition 2. Keep /home as part of the OS-file system, so that each OS can mess around with its own 'XDG's' I wonder if people have tried this (or something similar) and any downsides -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a
Re: XDG Standard is not evil (was: Re: Why focus on systemd?)
On 11/28/2014 6:32 AM, Rusi Mody wrote: I have a question along these lines: Years ago when we used computers, many people used one machine -- centrally administered. Nowadays one person uses many machines 1. Simply multiple hardware 2. Multiple OSes on the same h/w 3. Other more fancy (cloud) usage Just staying with 2. for now and that too only Linux, its a good idea to map the One-me -- Many OSes to One /home -- Many 'slashes' (eg Debian on sda5, Debian 32 on sda7 ubuntu on sda6 etc) However there are some issues: if the software-versions in these dont match up then its precisely these XDG files that tread on each others' toes across OSes. XDG is not relevant to that. Database formats change. Software that use databases change formatting of information they store. Configuration options/formats change. Software developers usually only plan for the upgrading of these things. If they do plan for downgrades it would normally only be for rare special circumstances. The Debian packaging system lets you downgrade packages, but there is a disclaimer for the same reason. Allowing older versions of software access to newer databases, configuration files, etc... can get ugly. Allowing older and newer the same increases the risk. One solution that Ive been toying with is as follows: 1. Have one real My-home partition 2. Keep /home as part of the OS-file system, so that each OS can mess around with its own 'XDG's' I wonder if people have tried this (or something similar) and any downsides Depends on what you consider a down side. Chrome and Firefox have solutions for bookmarks... http://askubuntu.com/questions/41766/is-it-possible-to-enable-google-bookmarks-sync-in-chromium https://support.mozilla.org/en-US/kb/how-do-i-set-up-firefox-sync Assuming you don't just use webmail, and your email provider supports it, there is imap for email. http://www.pop2imap.com/ Pictures, music, etc... can all be kept on another partition, creating symlinks in your home directory within each installation in place of the real Documents, Pictures, etc... that would normally be there. As root you can do something like: |groupadd sharedusers -g 2000 :to create a group in each installation: |chown -R :sharedusers /location/of/shared/directory :in one of the installations to change the group ownership of the directory where you put your pictures, documents, etc... note the ':' before the group name. To change group permissions on the shared files/directories you can do something like: chmod -R g+rwX :note capital X, execute/search only if the file is a directory or already has execute permission for some user. Later, Seeker
XDG Standard is not evil (was: Re: Why focus on systemd?)
2014/11/16 Peter Nieman wrote: Has anyone ever wondered where all these funny directories like ~/.cache, ~/.config, ~/.local or even ~/Desktop (with a capital D) came from that appeared in Debian after upgrading to - was it Lenny? Here's an answer: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html People often misunderstand what XDG standards were created for. Imagine that you're writing some graphical application in those old days before XDG standards appeared. And you want to put a link to it to the main menu of your DE/WM. Where would you put it? ~/.gnome2/vfolders/applications? ~/.kde/share/applnk? Maybe .icewm/menu? Or all of them? What if you want to autostart it on login? ~/.kde/Autostart? ~/.kde/share/autostart? ~/.gnome2/autostart? The problem arises when MULTIPLE INDEPENDENT apps need SAME files. So they came together and created XDG standard. It looks like: [autostart-spec] system-wide autostart files are placed in $XDG_CONFIG_DIRS/autostart/ user-specific overrides go to $XDG_CONFIG_HOME/autostart/ based on the desktop base directory specification. [menu-spec] .menu files are placed in $XDG_CONFIG_DIRS/menus/ .desktop files are placed in $XDG_DATA_DIRS/applications/ user overrides go to $XDG_DATA_HOME/applications/ and $XDG_CONFIG_HOME/menus according to the desktop base directory specification. and so on. The Base Directory Specification itself is just html page to reference, a base for other XDG specifications, that's why it's called base. As its original author said [1]: XDG Base Directory spec is intended for use by other specification. For example the XDG Menu specification and Autostart specification refer to the XDG Base Directory specification instead of reinventing their own filesystem locations / hierarchy. It just gives the meaning to directories, used by *other XDG standards*, which brought peace and clarity to the mess of desktop environments. Those XDG standards were created by X Desktop Group only to define unified directories for COMMON files of multiple X desktop environments, not for some rogue applications to hide their own private files. Each of files placed in those directories is extensively documented by other XDG standards. Later some people started to abuse those directories and put there files, that never supposed to be there. Those people don't really think about standards or unification. Usually they just enable displaying hidden files in their file manager, see a lot of dotfiles in a home directory and think that this is wrong. They start searching how to fix this, find xdg basedir-spec, and use it as an excuse for moving ~/.appname files, to ~/.config/appname, or worse, split them among .config, .local, .cache... They don't think about /etc/xdg, they don't read FHS or other XDG standards, they don't care about people who have to do 2-4 times more work to find and migrate settings of selected application to another machine, they just don't want to see dotfiles. But don't blame XDG standard for that, blame people abusing it to reduce the number of dotfiles in their home directory. [1] https://lists.launchpad.net/unity-design/msg02114.html -- Serge -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caovener+ek2blbhhq7u5k0hhbwbtyj70c7xzbzrs8ouspfg...@mail.gmail.com
Re: XDG Standard is not evil (was: Re: Why focus on systemd?)
On 11/26/2014 6:04 PM, Serge wrote: Those XDG standards were created by X Desktop Group only to define unified directories for COMMON files of multiple X desktop environments, not for some rogue applications to hide their own private files. Each of files placed in those directories is extensively documented by other XDG standards. Later some people started to abuse those directories and put there files, that never supposed to be there. Those people don't really think about standards or unification. Usually they just enable displaying hidden files in their file manager, see a lot of dotfiles in a home directory and think that this is wrong. They start searching how to fix this, find xdg basedir-spec, and use it as an excuse for moving ~/.appname files, to ~/.config/appname, or worse, split them among .config, .local, .cache... They don't think about /etc/xdg, they don't read FHS or other XDG standards, they don't care about people who have to do 2-4 times more work to find and migrate settings of selected application to another machine, they just don't want to see dotfiles. But don't blame XDG standard for that, blame people abusing it to reduce the number of dotfiles in their home directory. [1] https://lists.launchpad.net/unity-design/msg02114.html Are you saying you think it's a bad thing that .config files got moved in to a .config directory instead of multiple other locations? The /etc/xdg location would be for the defaults, not the user specific stuff. Looking at /etc/xdg it does appear it could be used more. It's not 2010 anymore so specs are adhered to better than they were when https://lists.launchpad.net/unity-design/msg02114.html was posted, at least for the user specific stuff, .config, .local, etc Later, Seeker -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5476c8e8.9030...@comcast.net
