Written by Auzy the 29 Feb 08 at 10:05.
Category: Others.
Related project:
Nothing/Others.
Status: New
Rationale
User directories on ubuntu are a mess at the moment. They need more standardisation and more sense to remain clean. If you go to terminal/bash you may discover that your directory looks something like:
While you may note that anything with . is hidden normally, what if someone wants to delete the settings for a program? They need to manually unhide it, and sort through the dozens of directories in the home directory to find it. The problems with this is that:
a) Its messy, and certainly not a clean solution
b) Users cannot easily access their settings.
c) Everyones home directory is normally trashed with hundreds of other files, making it difficult to navigate.
d) Its not standardised.
A better way of organising the home directories would be something like:
/home/auzy/Documents
/home/auzy/Desktop
/home/auzy/readme.rtf
/home/auzy/iffy.rtf
/home/auzy/delete me.rtf
/home/auzy/argggggg.c
/home/auzy/fgdhgfdhd.txt
/home/auzy/Music
/home/auzy/friendsassignment.c
/home/auzy/friendsassignmentCopy.c
/home/auzy/Settings/
/home/auzy/Settings/org.Azureus.Azureus/*
/home/auzy/Settings/org.gnome.gnome2/*
/home/auzy/Settings/com.sun.ooffice/*
/home/auzy/Settings/org.bash.bash2/bashrc2
/home/auzy/Trash/*
The advantages? Simple
a) All user settings are now centralised in a single directory
b) Your user directory can be as messy as you want, and you will still be able to find your settings easily
c) Because settings are stored in reverse notation, you can easily find settings which all relate to the same company. Whilst at first this appears to make things harder, its not. Because it means that if you wish to change from KDE to gnome, you can now easily delete all com.kde.* settings, and they are gone.
d) No more searching for program preferences. You know exactly where your personal settings for a program are
e) No longer any need to hide them, because they are already cleaned up, and wont make the users directory appear messy.
f) Makes it easier to wipe the settings for specific programs, no need to unhide, and search everywhere, or go to faqs. You can easily guess now.
g) Finding something in your home directory is less painful with ls.
h) You can now use file hiding in your directory for useful purposes. Cant think of any though.
Unfortunately, it may require a few modifications to programs to support fully, so it would kind of be program, by program, trying to get the patches merged upstream, but if serious effort was put into it, it would benefit everyone.
Untested programs will still work, but put settings in the wrong spot. You can still create a symlink to those directories though in /settings easily with 1 line of code, so users can still access the programs configurations.
GNOME annoys me the most.. most of my hidden folders are from GNOME apps..
There is a standard in freedesktop, like Brot said that puts every configuration file in ~/.config/ ...some programs already do this (like the last version of Totem.. or XFCE apps)
I think following this standards should be encouraged.
"$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used."
As Kenden said, there is a standard available already though, we should get people to follow that. Whilst a showing hidden files may be handy, its better to fix it fully
It's not broken don't fix it. There is already a settings directory, ~. Not only is there already a settings directory, with the exception of junk that's in .config, everything should be stored by program name. If it just had a more sensible name like .gnome-config we'd all be fine. The system works, all configuration files are in one place, hidden in the root of the users home directory. Moving and unhiding them won't improve anything, if anything it will lead to more clutter, and increase new user's likely hood of deleting things they shouldn't.
This "feature" is great.. but will change slowly because it is app-related. Thus it is irrelevant here, even if encouraging such behaviour is a good thing to me.
peterjs: Not sure why you think the stuff i ~/.config is automatically junk? As mentioned above storing config files in ~/.config (using the $XDG_CONFIG_HOME env variable) is the correct way to program configuration files: the problem is the apps that dont do this, not the ones that do.
There is no logical reason for storing individual configuration files hidden in the home directory when you could roll them up under a single .config location. As individual files it is impossible to know what they are, similar files should be grouped.
Naming them all .-config is a cludge: if you need to add something to a bunch of files to identify them, they belong in a directory.
I suspect the problem with implementing this will be moving already existing config files.
I did not realize there was a standard for ~/.config
The only thing I ever find in there is gconf and other stuff that is tightly related to gnome and assumed that it was supposed to be a gnome-config directory that was poorly labeled. Having everything under ~/.config/app name would be workable, just don't make if visible by default or users will delete it. Also how do thinks like .themes and .icons that aren't configuration but data figured in to this scheme?
I think it is a very good idea, but it must be pushed a little bit more
I know the .config thing, but it should be
.config-hostname-distrib-version-number
something like that. With the lsb compliance, it should be easy to get those data.
And at boot, Ubuntu creates some .config links to the directory created before.
So that this home CAN BE shared between machines (hostnames), differents version of distrib (version), or differents install of same version of distrib (number), and between distribution (distrib)...
What do you think ?
Of course, every distrib with you share this home should use the same system (.config links created at boot time) and should have the LSB data to get those informations
Auzy, as much as I've appreciated your comments and ideas elsewhere, I think this is rather misguided. This has been a UNIX standard for 30 years, yes, and I don't see why it should change. The dotfile directories are rather clearly marked, and it's easy to unhide the folders if you want to view them in Nautilus.
I think your proposition would cause a lot of unnecessary clutter in the directory names. Part of the reason why I like *nix naming schemes is that they are short and succinct... true, things are not always immediately intuitive, but on the whole I've found things to be rather well-organised.
I'm sorry, but I'm going to have to give this a no.
with all due respect, 30 years ago we didn't have a thousand desktop applications installed by default each installing their own . file into the home root.
There is a standard in place and it states to put application configuration files into the ~.config directory. If you want legacy apps to stay in the user home that is fine. But desktop applicaitons? Give me a break. There is no "UNIX Standard" for desktop applications that has existed for 30 years. You are the one that is misguided.
Try it.. "ls" without quotes in your home directory. I get no .program config files or folders.
It's only when you type "ls -a" (-a Do not ignore entries starting with ".") that you get these folders.
Why not go ahead and call it "Documents and Settings" already. Linux is NOT Windows.
The fact that everyone voted this idea up just shows how crap Brainstorm is. Someone can LIE about how a feature works, suggest a solution where there is no problem and people vote it up!
Actually, I never once said the output was caused by ls. When I mentioned ls, I actually meant in reference to rearranging the names of setting directories so they were standardised (ie, com.X.X, not .gnome there, com.java.azureus there, etc, just a clean means of organisation), and I meant also just to seperate them out fully. You are right though, I maybe should have reclarified that.
All I want is all my settings in a seperate directory away from media files, with a more standardised way of naming them. you are right, ls -a and ls may from some peoples sense fix the problem, however, I'd like it so that its clean enough to unhide actually (so if a user has an issue with dodgy settings, its easier for them to find where they can delete them because they are all in one location, and cleanly named..
One issue we suffer is that config files can be stored in either the company name, or the product name. I just want a standard good enough, that when ubuntu is mainstream, its not just because its free, but because everything is as clean as it should be, and logical. Home directory should only be for user files. Settings should be in its own directory in the user directory. Because better organisation makes things better
if its not broken dont fix it.
kde uses .kde
xfce uses .config
gnome probably uses something
3rd party apps use .3rd party
if youve every backed up programs you'll appreciate that unrelated programs can easily be backed up seperatly, but if programs are linked (as is the case with kde or gnome programs) then you have to understand the links to back it up.
if your in terminal finding stuff is so easy it doesnt matter anyway, if your in natilus then cant you sort alphabetically, or start typing the name of the file your looking for?
ls -A | grep serves me fine
or if its hidden in some dir
ls -AR | grep
will find it instantly.
if your browsing through natilus well you shouldnt be changing .files without help anyway.
On the topic of standardized naming for config files, there is something I have been pondering:
It could be very benficial to use the .desktop entry standard for defining applications (in /usr/share/applications, if I recall correctly?) to also describe configuration systems. For example, a program could describe where its configuration files are located - or how to find them - via a simple Config key in that file.
It could be an interesting way to keep the miriad of config files well organized based on the applications they belong to, as well as keeping the standards we have nice and cohesive.
No andrewfenn, I didn't say. I said if you go to terminal.. Would it have made any difference if I said use midnight commander or enable hidden files too?
Just a few thoughts:
1. "not broken then don't fix". This kind of mentality only has one consequence: it prevents innovation. Do you think the Linux kernel is being worked on because it is broken and needs to be fixed? ;)
2. Those arguing that it has been a standard for more than 30 years (Windows has been a standard on the desktop for a long time too ;) clearly didn't read carefully the specification at FreeDesktop.org. Let me sum it up: it is about programs all using the same environment variable for configuration files. You don't like it being in ~/.config? Then simply go to /etc/skel and add the following line to the .bashrc (or .whatevershellyoureusingrc) file:
export XDG_CONFIG_HOME=$HOME
Kind of complicated isn't it? Oh sorry, you'll also have to do it for the root account (which might be the only one after a fresh install if you're so much into standards)
Anyway. This is a great idea, as standardization always is. Looking forward to have all my apps using $XDG_CONFIG_HOME...
@denys:
No, it's not yours only. The standard says you must use XDG_CONFIG_HOME defaulting to ~/.config.
This means that XDG_CONFIG_HOME should be used to override the default but it might not be set so the files will be stored in the ~/.config dir
everybody here talking about what is standard, so i give you mine :
i wants all config to be fu*ked and move to my brain. This is the only clean way. I don't want them to be in my Home cause they are not mine (??)
I want to set XDG_HOME_CONFIG to /dev/null cause i found it better and other HAVE TO DO the same way as me cause I AM THE LAW and I decide FOR EVERYBODY what is the RIGHT WAY. And I don't care about the 30 years old roots geeks that were peaceful before the windows-users-i-want-linux-to-be-like-I-want invasion.
Those who don't want programs that puts .files in their directories should not use them and that's all. Or patch it themself to change the config dir and stop boring us with gnagnagna i don't like it ! That's the only linux standard : PATCH ME.
Ahh ca fait du bien..
PS : stop deciding what is a standard and what is not, bl**dy m*r*ns
When i start using Linux 10 years ago i had this idea as well - in one hand, maybe you're taking as mistake considering your Home ('~/') directory as your documents folder, what can be considered a bit shocky from some bad habits when migrating.
Well, personally i used to have documents on another partition, which helps a lot on being better organized (at least it were for me), as i think and believe it's nothing recommended on having documents folder into your 'home' directory.
Overally, i used to see the the 'home' directory only for our Linux account preferences about operative system and applications, as well temporary files and desktop items, and stuff like installed typefaces ('~/.fonts' - fonts there can be considered installed, some people may not know...), wallpapers, file templates, nautilus scripts, .gnomecc colour schemes, etc.
Of course, some developers used to use '~/.config/' as the default folder for settings (like audacious and totem), and of course, would be interesting if more developers concerns on making '~' directory more organized, since people (like me) used to have thousands of applications installed, which may mean thousands of folders into '~' ...
Auzy is in the right here. If we really want to be clean and standardized, we should do it how OS X does it.
(There are hidden files in HardDrive/ but those are system required files and the user would never-ever have to touch them, see them, or interact with them in any way. It's also forbidden too.)
HardDrive/Applications/
- Applications which are accessible to all users. Restrictions on these global applications can be placed in the Accounts Preference Pane.
HardDrive/Users//Applications
- These are applications that only the particular user can access and see. Applications can be installed either here or in the HardDrive/Applications/ folder. In fact, a user can simple drag and drop applications between these to folders depending on whether or not they decide to change that. Power. Control. Flexibility.
HardDrive/Users//Desktop/
HardDrive/Users//Documents/
HardDrive/Users//Music/
HardDrive/Users//Pictures/
HardDrive/Users//Movies/
HardDrive/Users//Downloads/
HardDrive/Users//Library/
- This "Library" folder is user specific, unlike the HardDrive/Library folder.
• If we followed the above structure, there would be a logical storage place for ***everything*** that could be quickly and easily found. No more hiding anything. Its clean and very well organized. By doing things in this way, it makes it easier to have applications more easily interoperate with each other along with sharing data.
• Proper permission settings can also be used to prevent users from accidentally deleting whole "Library" or "System" folders and makes navigation, especially in recovery operations, much more approachable. Yet another benefit to this structure.
• Manual de-installation of programs is fast and painless.
• There are easily dozens of reasons why it should be structured in this fashion ranging from developer to end-user benefits.
For some reason on the above, it took out "accounts" with < and > (probable due to formatting). Where you see " // " there should be the word user accounts between that.
• There is another point Auzy was trying to make in the way preference files are named by applications. Agree +2.
"Actually, I never once said the output was caused by ls. When I mentioned ls, I actually meant in reference to rearranging the names of setting directories so they were standardised (ie, com.X.X, not .gnome there, com.java.azureus there, etc, just a clean means of organisation), and I meant also just to seperate them out fully."
• Auzy was proposing a method similar to how OS X wants (but not requires) applications to name their preference files. For instance, "com.apple.applescript.plist" or "uk.co.introversion.defcon.prefs". Applications should name it like this, and that is for 2 reasons.
1.) An application that just so happened to share the same name as another avoids this problem as the company and address tag are probable not the same. "org.argo.Uplink.plist" and "com.apple.Uplink.plist" Uplink in one context refers to a game, and in another, refers to some other networking application. Makes it plain and simple, and avoids file creation confusion.
2.) Allows the user to quickly shift through and find specific preference files they wish to delete so that the application and generate another upon launch (clean start). A GUI application later on can come and provide an even more simple and direct way of managing the preference folder. Which can provide even more advantages for the user/developer.
The results I'd like to see from a dir entry
concorde@BenjaminsLappy:/etc$ dir
/acpi /gre.d passwd
adduser.conf /groff passwd-
adjtime group /pcmcia
aliases group- /perl
/alternatives /grub.d /pm
.hiddenfile ./hiddenfolder
Just a snippet of my etc folder modified with my idea.
I think files should be the names on their own eg text1.txt
Hidden folders should have the dot before them eg .text2.txt
Folders should have a forward slash before them eg /folder1
And hidden folders would have a dot and a slash eg ./folder2
freedesktop it isn't a de facto standard on every application, you're right. the result it is necessary integrate this standard in all the ubuntu programs, just to start.
but if we have to discuss on this idea it remains my question:
"so, what's the idea? a standard directory(the one we already have) or a forced "Library" or "Settings" visible and non-hidden directory?"
I strongly disagree with using a non-hidden folder (which is capitalized! That makes it sooo much harder to work with from the shell) for this, however, using .config is a good idea (hidden, lowercase, centralized). Users who don't know how to view hidden files most likely do not need to modify those files.