Custom Filesystem Hierarchy

I am creating a new Desktop Environment & Software Development Framework based on Qt4, One
of the features that I would like to implement is called CFHS (Custom Filesystem Hierarchy Specification) The CFHS defines a set of agreed upon techniques used to construct a filesystem hierarchy that would allow programs and library's to function in an environment that has no set structure.

An Example Hierarchy might look like this:
http://code.google.com/p/zester/wiki/CFHS_Technical_Specification

My question is would this be possible in FreeBSD and Easily Implemented?
If so any ideas on how to begin would be much appreciated.

Here is what the Desktop Environment currently looks like.
6ftqbq.png


You can learn more here.
http://code.google.com/p/zester/

Thanks Zester :)
 
Probably not possible if you plan to be able to use ports/packages as most ports are written with an idea that current folder hierarchy is being honored and will try to setup files where they think that they should be.
 
Unless you also create Makefile patches to correct all paths. But that sounds really convoluted and is probably unrealizable.
 
I think it's an interesting idea. Making all the major package managers (apt, pacman, rpm, ports, portage, pkgsrc) support it might be kind of a pain, but on FreeBSD you could probably get it to work quite easily by running port scripts in a temporary jail of sorts with e.g. /usr/local/bin pointing to /System/bin, or something of that nature.

The other issue is that things like autotools and other build systems which look for libraries and headers in specific directories will get "confused", which can cause problems for users who wish to install things which are not included with the default package managers. This is actually the biggest problem I've seen with alternate filesystem layouts: it becomes almost impossible for the lay user to install something which is not aware of the new layout. Already it's possible to run into issues installing things that expect something in /usr to be in /usr/local, or vice versa.

I do however encourage you not to bite off more than you can reasonably chew! It's quite an undertaking to design a desktop environment alone, without trying to invent a new filesystem hierarchy and "applications framework" (???).

You're not the first person who has tried to rework the common POSIX filesystem layout, and I encourage you to look at the efforts of others and perhaps consider contributing to one of the current plans. It's better to have fewer, better-maintained projects than a lot of projects with only one developer.

http://en.wikipedia.org/wiki/GoboLinux
 
irkkaaja said:
I think it's an interesting idea. Making all the major package managers (apt, pacman, rpm, ports, portage, pkgsrc) support it might be kind of a pain, but on FreeBSD you could probably get it to work quite easily by running port scripts in a temporary jail of sorts with e.g. /usr/local/bin pointing to /System/bin, or something of that nature.

The other issue is that things like autotools and other build systems which look for libraries and headers in specific directories will get "confused", which can cause problems for users who wish to install things which are not included with the default package managers. This is actually the biggest problem I've seen with alternate filesystem layouts: it becomes almost impossible for the lay user to install something which is not aware of the new layout. Already it's possible to run into issues installing things that expect something in /usr to be in /usr/local, or vice versa.

I do however encourage you not to bite off more than you can reasonably chew! It's quite an undertaking to design a desktop environment alone, without trying to invent a new filesystem hierarchy and "applications framework" (???).

You're not the first person who has tried to rework the common POSIX filesystem layout, and I encourage you to look at the efforts of others and perhaps consider contributing to one of the current plans. It's better to have fewer, better-maintained projects than a lot of projects with only one developer.

http://en.wikipedia.org/wiki/GoboLinux

1. Distribution Package Managers wouldn't be a problem because the desktop it's self doesn't depend on the filesystem hierarchy.

2. I am going to write a new shell to solve the problems with linking. They default filesystem hierarchy layout that I came up with places dirs like /bin, /lib, /include, ...
under the System/ directory. /usr/bin well thats a different story, installed user applications like the desktop, file-manager, multimedia player have there own dir in Applications/ and they link to there libraries in System/. When you execute say the file-manager from the command-line the shell automatically knows that the binary and its containing folder have the same name so all I have to do is make the shell aware of the Applications/ path. Doing it that way solves the problem with having a bunch on entries in the $PATH environment variable.

3. The system core (base system) is going to be very small, only packages that are needed for a basic system and libraries need for the programs in Applications/ will be in the system core. With that said I was going to rewrite the all packages build scripts to use qconf and qmake. QConf builds configure scripts and make files. Being that I am not trying to support operating systems like Windows or Mac I have no need for any other build tools like cmake. The end user will have two choices aether a NanoBSD Core or a LFS Core.

4. I also have my own package manager that works on NanoBSD and LFS. It uses yaml for the package file spec. http://code.google.com/p/zester/wiki/Zester_Package_Manager and http://code.google.com/p/zester/wiki/PKFS_Technical_Specification, It's not only an installer but also a package creator.

5. Application framework or Application development framework consists of a software framework used by software developers to implement the standard structure of an application for a specific development environment (such as an operating system or a web application). As an example I have sub-classed every QWidget so that by default every widget you use reads the style.css file from your user settings and the style is then applied to your applications widgets. Qt4 doesn't read external .css files by default it makes you hardcore the css into your application. Another example is I have an iconview widget that makes it brain dead simple for you to create a new custom file-manager or desktop in 5 min.

6. I am aware of Gobo and there also aware of FreeBSD :) http://gobo.kundor.org/wiki/GoboBSD server was down last I checked just view http://webcache.googleusercontent.c...lnk&gl=us&client=ubuntu&source=www.google.com
 
Grand idea!

Your idea sounds very interesting!
I was thinking of making a package to create customized file system hierarchy in archlinux.
I'm gonna try with a different, simpler approach:
Code:
-keep the original fs hierarchy for compatability
-hide it using gobohide or something similar
-use bind mounts to mirror old fs to new customized one (using full, descriptive names, one big 'Executables' dir (for bin:sbin:usr/bin:usr/sbin)
-use package managers (pacman in archlinux) cache query to symlink all files owned by package to 'Applications' dir
-use find (minus known installed files query) to create 'Unowned files' dir
-maybe use customized file manager (one for classic linux/bsd fs, one for new customized fs)

Here's a quick, first example layout (ideas welcome) of how it could look:
(probably contains some mistakes)
Code:
User                       /usr/home
 >Desktop                  /usr/Desktop
 >Panel                    /usr/share/.Desktop
Applications               (pacman -Ql) /usr/local:/opt:/AppDirs
Removable Media            /media:/mnt?
Shared?                    (desktoplinks:fonts:icons:templates)

System
 >Executables              /bin:/sbin:/usr/bin:/usr/sbin
 >Settings                 /etc:/shared(/icons:/fonts)?
 >Logfiles                 /var/log
 >Documentation            /var/doc:/usr/share/man:usr/share/doc
 >Temporary                /tmp
    >>preserved            /var/tmp:/usr/tmp
 >Tasks                     
    >>running              /var/run
    >>queues               /var/spool:/usr/spool
    >>busy                 /var/lock:/usr/lock
    >>processes?           /proc
    >>services?            /srv
 >Linux/BSD
    >>/Libraries           /lib:/usr/lib:var/lib
    >>/Kernel
        >>>/boot           /boot
        >>>/hardware?      /dev
        >>>/status         /proc
        >>>/object         /sys
    >>/Sources             /usr/src
    >>/Headers?            /usr/include
Hope it can inspire others too, anyway, I really hope your project will find a place to stay. Quite sure a lot of people will like it!
Customized file system hierarchy w00t :e
 
This is something what apple's OS does. The gui managers hide bsd style file system's layout with a custom more user friendly one on top.
 
Back
Top