A .hidden file should be included in / that hides the directories not required for typical desktop use. All modifications should as be easy to undo as possible.


New and inexperienced users are often very scared of the many confusing directories in /. Most of them make sense only with an explanation of how a Linux system works, and not all users are interested in that. Some of them even seem misleading - /usr is not for user files. And those users usually don't have to do anything there; they don't even have to know these folders are there. / is already obscured in the GUI, but users still have many ways to get there, either accidentally or while exploring. By hiding all folders not relevant to desktop use, users won't get confused by things they don't have to deal with anyway, similar to how user configuration files in ~/ are only visible to those who want to mess with them.

Of course, any such changes should be easy to undo - many power users want to be able to access everything in / easily, and they have every right to. And it is important that everything still works on the command line as usual.

Use cases

Gustav has just installed Ubuntu, his first Linux distribution. He goes to the top level of his file system, like he's used to, and finds a ton of cryptic things that confuse him. He tries to put stuff there, but it tells him he can't do that. After playing around some more and making everything worse with half-knowledge, he removes Ubuntu again and proceeds to write "Why no sane person would ever use Linux" articles.

Henrietta is a Linux power user and system administrator and wants to be able to see every folder that's there, because she knows what it's for and what she can do there and how.



This could be done in several ways. The easiest seems to be using .hidden files. Nautilus will hide everything in a directory that is listed in a text file called ".hidden" in that folder. This could be used to hide everything but the relevant things (probably /home and /media). It would also be possible to hide everything but newly created symlinks to these folders that have more accessible names ("User Data", "Drives", etc), but that might be problematic as symlinks start a different hierarchy. Another possibility would be to add a rename feature that works similar to the .hidden file, then more sensible names can be provided without creating a new hierarchy, but this would be a major feature change and probably has issues if it's own. If new names are introduced, they should be localized.

In all cases, undoing this would be very easy (just delete the .hidden file, and the renamed symlinks if created) and could be provided as a script. It's also possible view the files on demand by enabling "Show Hidden Files". It's also possible to hide only for normal users, so a sudo'd nautilus still shows everything by default.

Another way, that isn't tied to a specific file browser and doesn't require us to change applications it to use something like the GoboHide patch, which hides directories and files in the system call level. It was suggested that we even go as far as making the filesystem structure Gobo-like.

Gobolinux is a Linux distribution that breaks away from the historical UNIX directory hierarchy. Basically, this means that there are no directories such as /usr and /etc. The main idea of the alternative hierarchy is to store all files belonging to an application in its own separate subtree; therefore we have directories such as /Programs/GCC/2.95.3/lib. To allow the system to find these files, they are logically grouped in directories such as /System/Links/Executables, which, you guessed it, contains symbolic links to all executable files inside the Programs hierarchy. To maintain backwards compatibility with traditional Unix/Linux apps, there are symbolic links that mimic the Unix tree, such as "/usr/bin -> /System/Links/Executables", and "/sbin -> /System/Links/Executables" (this example shows that arbitrary differentiations between files of the same category were also removed) GoboLinux site

Hofy and his specification: "There are two problems if I open my harddisk I see /etc /var .... and so on. A normal user did not understand this and he is imprisoned in his home folder and can not use an own structure. The second thing is that if I install for example typo3 that I not know were the program is after the install. So I would suggest to make a new structure like this: On the root we have: /, /home (like before), /programs (contains all installed programs), /linux/etc...(includes all system specific thinks), /home/USERNAME/programs (contains all userspecific program things). Then we did not need the invisible folder in the user directory of installed software. Then I always know where the programs are and I can open the root path and I will find everything I need. Because I thing the current default filesystem structure is not good for home users"



Data preservation and migration

Outstanding issues

- needs to be fixed so the files hidden with .hidden are not visible in the file selector by default.

Note: Taken in part from the UsabilityWishlist. Many thanks to all contributors.

BoF agenda and discussion

See also discussion in part "Userfriendly filesystem - Home folder dot-files" in UsabilityWishlist: "A home directory can be cleaned up, but as soon as you show hidden files it becomes a big, big mess. Suggestion: Create an infrastructure separating data, configuration and temporary/cache files. This will also allow to delete the gnome configuration if it becomes corrupted without data loss (...)"

Darek27: Microsoft Windows have a "Windows" folder. For Linux I propose a "System" folder not a "Linux", because we create a standard for future operating systems also for BSD and others. Maybe a future version of our operating system will base on a BSD kernel not a Linux kernel (but still will run a old linux programs). "Linux" word is copyrighted by Linus Torvalds and probably can't be used in the BSD and the others. "System" is a neutral, universal word. I propose a userfriendly filesystem:

".Programs data" is a hidden folder. Don't create a separate folders Home/username/.Programs data/config Home/username/.Programs data/data because a lot of programs mix a config and data files (see Gimp folder tree (brushes, patterns, ...) and a other big programs). They always make a folder like Home/username/.Programs data/gimp (with it own mix a config and data subfolders). Userfriendly program will make a two folders itself:

We can't force ALL programs to split its config and data files to our .Programs data/config .Programs data/data folders like this:

They will only use our common temp folder .Programs data/temp. We won't convince all lazy programmers of close-source software. We will always see a thundreds of names of programs in the main data folder .Programs data like .Programs data/starwars_game .Programs data/dvdriper ... Therefore don't put a few programs in the separate folders .Programs data/config .Programs data/data and a rest in the main .Programs data folder (like .Programs data/starwars_game) because this is mislead for a new users. ALL must be in a one place. We need ONLY ONE method of store the config and data files.
We can eventually move "/Programs files" in "/System/Programs files" because people don't have reasons for see this files. They only need back up ".Programs data" in "Home/username/.Programs data" New folder tree will be simple, only: Home Media System

Warbo: Creating such folders as "/linux" or "/system" is ridiculus. The comparisons made to Windows here really disturb me, as Windows is the most badly layed out system I have ever come across (Just press "Up" in Explorer and see what happens. C: is in My Computer, which is in Desktop, which is in C:\Documents and Setting\User, which is in C:, which is in My Computer......). Users have a right to know what is on there system, so hiding these files is proposterous (besides which, it would surely cause more outcry from Windows users such as "OMG, don't use Linux, they don't even let you see what it's installed!"). This idea proposal is surely thought up by a Windows user who is in unfamiliar territory. You are right to feel insecure about the filesystem structure, because you are using a different operating system! The idea of a "programs" directory seems like you want Linux to end up with something as confusing and broken as that Windows farce commonly know as "Program Files" (everything is just bundled into huge mess, programs, libraries, images, music and more, and then divided up on the basis of who crippled you with their license). Users should be free to use the system as they wish, and since Ubuntu is multi user I don't think one user should have the right to tamper with another user's setup. That is why $HOME was created. Regular users should not venture out of their $HOME, and even if they do go "up" to /, they have already been in $HOME to get there, so there is no confusion over where files should be stored. Either that or they have been in "Computer", and from there on to "Filesystem". In this second scenario I see no way for a user to think of treating "Filesystem" as they would do "C:", because there is no indication made that this is, in fact, a hard drive partition. The main reason is because it is NOT a harddrive partition and could never be used as such anyway (are you seriously proposing that users should be encouraged to think of "/" as being more "friendly"? I would never want people becoming complacent about a directory which contains networked filesystems, temporary filesystems which get wiped at reboot, RAM-based filesystems which can clog the machine's memory with personal files, only to find them all gone after a reboot, and that's not even taking into account all of the system configurations, binaries, libraries, images and music, source, etc. [which, you may notice, are kept sensibly seperate]) This confusion may come from Windows users who are used to making arbitrary directories throughout the entire system (including directly in C:) because "My Documents" is too restrictive. I would say that this is a Windows problem, due to "My Documents" containing unchangable content, thus forcing users to save elsewhere to maintain some level of control (During my [very] brief use of Windows I kept a seperate partition for my files [like I do on any OS I have ever used] and never touched "My Documents". I was also angered by "easy to use" installers which ask for an installation path, only to find that anything other than the default "Program Files" one breaks the program) and it is certainly not a problem with Linux. What, may I ask, is wrong with $HOME? Users are free to do what they want inside their home, and ANY filesystem structure can be used. Personally I keep all of my files on a seperate partition to my $HOME (and all of it's configurations and preference files), resulting in such poetic pieces of hierarchy as "/home/chris/Files/System/Storage/Packages/Debs/swftools_0.7.0-2_i386.deb"

kmon: This spec shouldn't be done, there are many good reason behind the way the filesystem herarchy is done. New users to linux shouldn't fidle with it if they don't understand it. Windows FS is pretty much broken and users have gotten used to have to manualy fix it, or hack on it in ways which aren't safe. Ubuntu shouldn't differ much from the Filesystem Hierarchy Standard.

JackWasey: A real revolution which would enable this would be clever desktop search with plenty of meta-data to back it up. Then the file system structure becomes irrelevant, and so it can stay the same for backwards compatibility. If you want to see files in a package, say, there are already (non-GUI) tools to do this. If nautilus captured a few extra use cases, people wouldn't need to work in the normal file system at all, just their home dir. Use cases might be:

My point is that any file system is complicated for a new user, so if you can distill what they actually need, this is a better option all round. Some weaving of beagle and nautilus could do this.

Wolki: OK, I'm a bit surprised to see so much activity now in a declined spec... Anyway, some comments.

Warbo: Thanks for the response, I have a few observations and ideas. Firstly, I never suggested that users cannnot go out of their home, In fact one of my arguments was that the filesystem should not be hidden as the user has a right to know what is on their machine, but they should not be encouraged to change it. My main argument was that once a user is in / they would not be confused because they either a) have already been in their home, in which case there is no confusion of "Look at all of these directories, where the hell do I put my stuff?" because they know where $HOME is (I mean in the "Places" menu or on the desktop, not that in the filesystem sense), or else they have been in "Computer" and gone in "Filesystem". To me this is a very "techie" type word, and for new users it would actually seem more logical that "Filesystem" is in "Home" rather than the other way around, because "Home" sounds like a top-level directory in which the rest of the system is put. This would get rid of any "I can't be bothered to make new folders, I'll just save it in C:" attitude because Home would be interpreted as the equivalent of C:. By the time the user realises that $HOME is in /home they would have seen the sense in it, and would carry on using $HOME. This is basically in the same type of mindset as "root user? I am the only person on the computer" which crops up in chat rooms and forums all of the time and the more dangerous "It is my computer, so I will be root all of the time" (which Ubuntu prevents quite well. In order to learn how to enable root and log in to it graphically the user would have been subjected to loads of reasons against it.) I think that the best way to tackle the problem of $HOME organisation in general is a) Beagle integration, so files can be found through content rather than some badly organised folders (I mean that the users have created in $HOME, not the excellent folders in /) and also some kind of FUSE based relational database filesystem, which would store files on the regular (ext3, reiserfs, etc.) partition (as these filesystems are mature and stable) but would also make them accessible via metadata "tags", so files would be stored in, say "/home/user/Files" in any structure (like the $HOME has today) but they can also be accessed via "/home/user/Browse Documents" (for example) which would make pseudo-folders such as "Music", "Videos", etc, meaning that files can be accesed in multiple places based on content. For example "Bill Gates Pied.mp4" could be found in "Videos/Shorts", "Videos/Funny", "Subject/Computing/Videos", "File Type/MPEG4", etc. The "tags" can be added and removed easily by copying and deleting files in "Browse Files", eg. copying "Bill Gates Pied.mp4" to a new folder "Subject/History/Historical Buildings" will add that tag to the regular file in "Files", and deleting the file in "Videos/Shorts" will remove that tag. Files can still be copied and deleted by accessing them through "$HOME/Files". This is the way to "disguise" /, by making it's hierarchal nature alien to general users who will become more accustomed to finding content through searches and catagories. Anyway, that is my opinion on the matter. Maybe someone will take up this FUSE idea?

alex-weej: You mention FUSE... is that really necessary? Can we not just extend Nautilus?


i think this should just be done using nautilus modes. easy/normal. It is no that unfriendly.


HideFilesystemStructure (last edited 2008-10-06 16:59:41 by iamnotwhatiam)