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 m
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
On 2 December 2014 at 15:24, Miles Fidelman wrote: > Scott Ferguson wrote: >> >> On 2 December 2014 at 11:49, Miles Fidelman >> wrote: >>> >>> Having just waded through this thread, >> >> My sincere sympathies. >> >>> and then reading the standard itself, >> >> Based on what you are quoting - that's the Base Directory >> Specification, which is part of the XDG Standards >> >>> I can only conclude that it may not be "evil" but it is a horribly >>> written >>> standard. >> >> Lacking in comprehensive detail specifications? >> >>> To start with, there's absolutely no context: >> >> "Base Directory Specification" >> >>> The introduction reads, simply "Various specifications specify files and >>> file formats. This specification defines where these files should be >>> looked >>> for by defining one or more base directories relative to which files >>> should >>> be located." >>> >>> Nothing about where the standard applies, "Base Directory Specification", logically, precedes the Introduction. By doing so it frames the documents i.e. provides context. >>> what kinds of files are being >>> talked about, >> >> I believe the very next section entitled "Basics" provides an overview >> that covers those items. >> http://standards.freedesktop.org/basedir-spec/latest/ar01s02.html > > > No... it lists a collection of concepts, again, with no context. Does it not mention files? Please try and interleave your responses below the point you are replying to - this is not the Gish Gallop mailing list. > > Somehow (from XDG) > "The XDG Base Directory Specification is based on the following concepts: > > * > >There is a single base directory relative to which user-specific >data files should be written. This directory is defined by the >environment variable |$XDG_DATA_HOME|. > > * etc." > > Is NOT context. Nor did I say it was. I said, and the post remains unchanged - that "Base Directory" is the context. > > In contrast to, to pick a non-random example, the Linux Standard Base Which demonstrates only that you ignored, or are unable to understand the following:- >> >> >>> on what kinds of systems. >> >> Any system/application that chooses to adopt it. In terms of OS, it's >> used on Linux, Mac (Apple?), and Windows. >> >>> Nothing about what the standard is to be used for. >> >> "a set of common interfaces for desktop environments" >> >> >> https://wiki.gnome.org/action/show/Initiatives/GnomeGoals/XDGConfigFolders?action=show&redirect=GnomeGoals%2FXDGConfigFolders > > > Wow a web page, buried way deep inside a specific project's web site, > not referenced in the standard itself - does not a standard make. Maybe, > just maybe a design document. Is that a novel way of saying "Thanks Scott for doing my homework for me?" > >> >>> Nothing about who maintains the standard, >> >> Waldo Bastian, Ryan Lortie, and Lennart Poettering are credited on the >> page you referenced, anyone can contribute - simply join the mailing >> lists, which is all development is done:- >> http://lists.freedesktop.org/mailman/listinfo/xdg > > > Again, not a standard. Do you not understand your own comment that I was replying to "Nothing about who maintains the standard," - or are you being deliberately obtuse, or perhaps, and I hope not - trolling? > >> >>> the process by which it is >>> maintained and updated, >> >> See above. >> >>> where to find the latest version. >> >> I found them here:- >> http://standards.freedesktop.org/basedir-spec/latest/ >> >> I don't know where you read your version. > > > Again, not stated anywhere in the standard. I neither said nor implied that it was - nor that it *should* be. I was simply responding to your comment with a relevance. It's the basis of effective communication. Do try it. >> >> >>> No references. >>> >>> >>> The lack of any of this, makes the rest of it essentially useless. >> >> If you expect a simple guide to the standard to include all of those >> points - then you are correct. >> Definitely agreed that what you've referenced is lacking in >> comprehensive detail, especially the sort I'd expect to see in an ISO >> standard. But then Freedesktop.org standards are not formal standards. >> And unless you follow the mailing lists, and have followed the history >> of X Desktop Group, it's very hard to understand. > > > Hence, my point. It's somewhat pretentious to call it a standard, I fear, for lack of a better metaphor - you are trying to make a fish out of a hat. I took the time to read and consider what I was replying to - it would be polite if you could reciprocate. The XDG Base Directory standard is a "defacto", "informal" standard. > and by > any measure of a well written, well coordinated standards document - it > simply is horrendous. > >> > > > And their documents can legitimately be considered both standards, and well > written. *Formal standards* As is their purpose - something you seem prepared to put an inordinate amount of effort into *not* recogni
Re: XDG Standard is not evil
Scott Ferguson wrote: On 2 December 2014 at 11:49, Miles Fidelman wrote: Having just waded through this thread, My sincere sympathies. and then reading the standard itself, Based on what you are quoting - that's the Base Directory Specification, which is part of the XDG Standards I can only conclude that it may not be "evil" but it is a horribly written standard. Lacking in comprehensive detail specifications? To start with, there's absolutely no context: "Base Directory Specification" The introduction reads, simply "Various specifications specify files and file formats. This specification defines where these files should be looked for by defining one or more base directories relative to which files should be located." Nothing about where the standard applies, what kinds of files are being talked about, I believe the very next section entitled "Basics" provides an overview that covers those items. http://standards.freedesktop.org/basedir-spec/latest/ar01s02.html No... it lists a collection of concepts, again, with no context. Somehow (from XDG) "The XDG Base Directory Specification is based on the following concepts: * There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable |$XDG_DATA_HOME|. * etc." Is NOT context. In contrast to, to pick a non-random example, the Linux Standard Base (http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/book1.html) Which starts with, "This is version 4.1 of the Linux Standard Base Core Specification. This specification is one of a series of volumes under the collective title /Linux Standard Base/: * Core * Note that the Core, C++ and Desktop volumes consist of a generic volume augmented by an architecture-specific volume." And continues with: "The LSB defines a binary interface for application programs that are compiled and packaged for LSB-conforming implementations on many different hardware architectures. A binary specification must include information specific to the computer processor architecture for which it is intended. To avoid the complexity of conditional descriptions, the specification has instead been divided into generic parts which are augmented by one of several architecture-specific parts, depending on the target processor architecture; the generic part will indicate when reference must be made to the architecture part, and vice versa." on what kinds of systems. Any system/application that chooses to adopt it. In terms of OS, it's used on Linux, Mac (Apple?), and Windows. Nothing about what the standard is to be used for. "a set of common interfaces for desktop environments" https://wiki.gnome.org/action/show/Initiatives/GnomeGoals/XDGConfigFolders?action=show&redirect=GnomeGoals%2FXDGConfigFolders Wow a web page, buried way deep inside a specific project's web site, not referenced in the standard itself - does not a standard make. Maybe, just maybe a design document. Nothing about who maintains the standard, Waldo Bastian, Ryan Lortie, and Lennart Poettering are credited on the page you referenced, anyone can contribute - simply join the mailing lists, which is all development is done:- http://lists.freedesktop.org/mailman/listinfo/xdg Again, not a standard. the process by which it is maintained and updated, See above. where to find the latest version. I found them here:- http://standards.freedesktop.org/basedir-spec/latest/ I don't know where you read your version. Again, not stated anywhere in the standard. No references. The lack of any of this, makes the rest of it essentially useless. If you expect a simple guide to the standard to include all of those points - then you are correct. Definitely agreed that what you've referenced is lacking in comprehensive detail, especially the sort I'd expect to see in an ISO standard. But then Freedesktop.org standards are not formal standards. And unless you follow the mailing lists, and have followed the history of X Desktop Group, it's very hard to understand. Hence, my point. It's somewhat pretentious to call it a standard, and by any measure of a well written, well coordinated standards document - it simply is horrendous. "For Linux operating system standards, please see the Linux Standard Base project. freedesktop.org is loosely affiliated with the Free Standards Group; the FSG is one group that does "de jure" standards for free software. The X.Org Foundation and the IETF are other groups that do *formal* standards." And their documents can legitimately be considered both standards, and well written. Unlike these groups, freedesktop.org is just a "collaboration zone" where ideas and code can be tossed around, and de facto specifications encouraged. Which should not be referred to, or considered anything like a standard. Miles Fidelman -- In theory, there is no di
Re: XDG Standard is not evil
On 2 December 2014 at 11:49, Miles Fidelman wrote: > Having just waded through this thread, My sincere sympathies. > and then reading the standard itself, Based on what you are quoting - that's the Base Directory Specification, which is part of the XDG Standards > I can only conclude that it may not be "evil" but it is a horribly written > standard. Lacking in comprehensive detail specifications? > > To start with, there's absolutely no context: "Base Directory Specification" > > The introduction reads, simply "Various specifications specify files and > file formats. This specification defines where these files should be looked > for by defining one or more base directories relative to which files should > be located." > > Nothing about where the standard applies, > what kinds of files are being > talked about, I believe the very next section entitled "Basics" provides an overview that covers those items. http://standards.freedesktop.org/basedir-spec/latest/ar01s02.html > on what kinds of systems. Any system/application that chooses to adopt it. In terms of OS, it's used on Linux, Mac (Apple?), and Windows. > > Nothing about what the standard is to be used for. "a set of common interfaces for desktop environments" https://wiki.gnome.org/action/show/Initiatives/GnomeGoals/XDGConfigFolders?action=show&redirect=GnomeGoals%2FXDGConfigFolders > > Nothing about who maintains the standard, Waldo Bastian, Ryan Lortie, and Lennart Poettering are credited on the page you referenced, anyone can contribute - simply join the mailing lists, which is all development is done:- http://lists.freedesktop.org/mailman/listinfo/xdg > the process by which it is > maintained and updated, See above. > where to find the latest version. I found them here:- http://standards.freedesktop.org/basedir-spec/latest/ I don't know where you read your version. > > No references. > > > The lack of any of this, makes the rest of it essentially useless. If you expect a simple guide to the standard to include all of those points - then you are correct. Definitely agreed that what you've referenced is lacking in comprehensive detail, especially the sort I'd expect to see in an ISO standard. But then Freedesktop.org standards are not formal standards. And unless you follow the mailing lists, and have followed the history of X Desktop Group, it's very hard to understand. "For Linux operating system standards, please see the Linux Standard Base project. freedesktop.org is loosely affiliated with the Free Standards Group; the FSG is one group that does "de jure" standards for free software. The X.Org Foundation and the IETF are other groups that do *formal* standards." Unlike these groups, freedesktop.org is just a "collaboration zone" where ideas and code can be tossed around, and de facto specifications encouraged. Perhaps that's a difficulty inherent with a "informal standard" (informal standards[*1]) built on "concepts"? Some confusion lies in people confusing xdg-utils[*1] compliance and the concepts they (the tools) are based (whacky, and unlikely, but it is possible that some is the result of reaction to anything with Lennart's name in it). [*1] see /usr/share/doc/xdg-utils/README > > Miles Fidelman > > Kind regards -- 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/CAMt2cQOowPHS_QkJta-bn8dg897Tr4wspw=arzmr_wy1tyq...@mail.gmail.com
Re: XDG Standard is not evil
Having just waded through this thread, and then reading the standard itself, I can only conclude that it may not be "evil" but it is a horribly written standard. To start with, there's absolutely no context: The introduction reads, simply "Various specifications specify files and file formats. This specification defines where these files should be looked for by defining one or more base directories relative to which files should be located." Nothing about where the standard applies, what kinds of files are being talked about, on what kinds of systems. Nothing about what the standard is to be used for. Nothing about who maintains the standard, the process by which it is maintained and updated, where to find the latest version. No references. The lack of any of this, makes the rest of it essentially useless. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- 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/547d0ca8.3010...@meetinghouse.net
Re: XDG Standard is not evil
* seeker5528 [29-11-2014 08:52 EET]: > Oh yeah, if you've done all that you might actually want your user account > to belong to the shared group. ;) > as root: > > |usermod -a -G sharedusers yourusername| > > :note the capital G. In Debian you can also adduser yourusername sharedusers -- 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/20141201224005.GA11880@darkside.homesite
Re: XDG Standard is not evil
On 11/28/2014 10:27 PM, seeker5528 wrote: 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. Oh yeah, if you've done all that you might actually want your user account to belong to the shared group. ;) as root: |usermod -a -G sharedusers yourusername| :note the capital G. Later, Seeker
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
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 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
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?)
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
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
