Directory structure

[dixy]

Please take a look on how a linux distro (Gobo linux) managed to arrange every bit of software in directories like Programs and System. I think it will be nice to have the same features in Pcbsd. http://www.gobolinux.org


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).

[scottro]

One thing that many BSD users prefer over Linux is its directory structure. :)

[intensityx]

One thing that many BSD users prefer over Linux is its directory structure. :)

Gobolinux has a great dir structure that is similar to Mac OS in that it hides the more complicated linux directory structure with a more user friendly structure. AFAIK the original directory structure remains intact just like in Mac OS and can be revealed and used instead if desired.

This would be a great feature on PCBSD and would prevent new and casual users from getting confused with the BSD file structure.

[DrJ]

If the standard BSD file structure is diddled with in PC-BSD -- and I'd strongly prefer that it is not -- I would suggest the opposite approach of Gobolinux: keep the FreeBSD file structure, and use symbolic links from the "new" directories to their BSD homes.

DrJ

[kmoore134]

This is something that would be difficult to do. I understand trying to make the OS FS layout more easy for EU's, but on the other hand, I don't want to break any FreeBSD support either. I would love to see the OS reside almost completely in its own dir like /System. When I get a chance, i'll probably play with links and stuff to see if there is a way to "fake" this nice directory structure. Like /System and /Home.

[DrJ]

Yes, it would be a challenge to do really right.

OTOH, I don't really get the concern about EUs understanding the traditional Unix file structure. Would not most just be interested in their programs (which could point to /usr/local/whatever or /usr/local/bin/whatever) and their home directory? The rest of the system (such as /bin, /etc, /lib and so forth) need not be understood unless one is interested. Why would an EU even want to go here?

DrJ

[bhna]

the first step could be the renaming of /MyPrograms in /Programs and a new /Driver folder for the Nvidia (and ATI) driver.

[dixy]

I would love to see the OS reside almost completely in its own dir like /System. When I get a chance, i'll probably play with links and stuff to see if there is a way to "fake" this nice directory structure. Like /System and /Home.

That's just what the people behind Gobolinux had done. If you have the time maybe you can take a look to it and discuss with them - maybe they can help.

[1000k]

I'm thinking for a while about this issue.

The fact is that we can't change the BSD directory structure.
So -> symbolic links.

The cool thing with symbolic links is that, for example, you can adapt a script to make symbolic links in the choosen language of the installation (ex: /Programs will become /Programmes in French).
It will be a gain in noob-friendliness if only we can "hide" the real path, i.e. by default we can't see the /usr folder, only the /Programs folder (but an option would be able to unhide /usr and so on). In Kamel, maybe? :wink:

Let's discuss about the best way to do this.

[dean_fry]

I would love to see the OS reside almost completely in its own dir like /System. When I get a chance, i'll probably play with links and stuff to see if there is a way to "fake" this nice directory structure. Like /System and /Home.

That's just what the people behind Gobolinux had done. If you have the time maybe you can take a look to it and discuss with them - maybe they can help.

any update on this?? maybe after 1.0 is out you can get to this again??

cheerZ

[sblevin]

The FreeBSD union filesystem is what apple uses. I'd love to just install a package into a fake root, then zip it up and call it a .PBI that grafts over the top of the existing filesystem with a "read this stuff first before looking in the real structure" approach. Thats what apple did and the support is (probably somewhere) in PC-BSD already (I assume).

[dean_fry]

The FreeBSD union filesystem is what apple uses. I'd love to just install a package into a fake root, then zip it up and call it a .PBI that grafts over the top of the existing filesystem with a "read this stuff first before looking in the real structure" approach. Thats what apple did and the support is (probably somewhere) in PC-BSD already (I assume).

i'd love to see the osx approach on pcbsd...maybe someday...
.....

....

so is it ready??? :D

[gnutux]

I disagree, I think that it is a pointless and utterly useless and time wasting feature. The current UNIX file architecture has been used for 35 years and no one had really complained about it. Even Linux picked it up when Linus Torvalds was programming it. BSD is a UNIX, so I think that it should stay that way. Gobo can have its way since Linux isn't a "true" UNIX operating system. Also, I find the Mac handles things may confuse more people than it helps, so therefore, I vote against this idea.

gnutux

[pcbsdusr]

"The current UNIX file architecture has been used for 35 years and no one had really complained about it."

I disagree with this last post. If everybody was like this os's would never have evolved...

[dean_fry]

hmm...i disagree with gnutux too...just my 2 cents...

[1000k]

I have recollections of when I was using UNIX for the first time (it was a Knoppix Live-CD). I thought "what is this silly directory structure ? Why are they using abbreviations of three of four letters, they think it's understandable? What /var means? Who knows that a /bin(ary) is a program? What fit in /etc? /sbin??? One more time it was designed as if only English-speaking geeks would use it."

So i'm all for a new(bie) approach of the architecture, which would be immediatly understandable in the native language of the user. It would be great to have a meaningful directory structure in Greek or simplified Chinese :)
Of course, the best thing would be a true metadatas-based filesystem to get rid of all kinds of directory structures, which are too strict.

I'd like to know what can be done with UnionFS, it seems promising for the PBIs. sblevin talked several times about it, but there haven't been any debate on this issue yet.

[BSDseeder]

"The current UNIX file architecture has been used for 35 years and no one had really complained about it."


yeah *lol* because they used it on some gigantic servers, not on desktop systems, what if you buy a new HD and want to install the apps on /myNewHd/ ?

i think SUSE came up with an idea to do something about it (i really don't know the details)

[gnutux]

I can still be considered to be a UNIX newb since I don't know everything about UNIX. Yet, the file structures aren't hard to guess. These are my guesses (and have doubled check them as is correct):
/home = home folder
/var = variable folder, files that change too regularly
/etc = etcetera, this is where all your other system configuration are stored.
/bin = system binary
/dev = devices
/sbin = Secured bin, for root user
/usr = USER-SHARED folder, programs which users can use
/usr/bin, /usr/lib, /usr/share, /usr/local are user-shared folders that users need
/lib = system libraries
/boot = where the kernel and bootloader files are
/opt = optional software that can be shared.
/sys = the system folder where the kernel configuration and system vital configurations are stored
/mnt = mounted drives folder
/media = DVD/CD/Floppy/USB DISC folder (Removables)

It's very simple and logical. Just because UNIX was used as a server doesn't mean that it has to be hard on the user. If UNIX was hard to use then no one used it, even the system admins.

That's my opinion on this lil' idea.

xboxrulz

[password]

Problem is that we can't change it if we want to be 100% compatible with FreeBSD. Best just to learn it.

[KiSS]

Search for the Unix File Standard on Google -

To Me its is too horizontal - too many peer dirs. IMHO a vertical one would be better.

One thing I dont get is all these "/bin"s in /usr: there is /usr/bin, /usr/local/bin, /usr/sbin, /usr/local/sbin ??????

A simpler hierachy would go to great lengths for users

/System
/bin
/rootbin
/boot
/dev
/config [etc doesn't make sense]
/mnt
/Media
/Home
/Group[name of group]
/All_Users
/user1
:
:
/Libraries
/Temp

[DrJ]

One thing I dont get is all these "/bin"s in /usr: there is /usr/bin, /usr/local/bin, /usr/sbin, /usr/local/sbin ??????


All of these binary directories help to keep things organized once you get used to them. /usr/bin contains "regular", OS-related binaries (including userland). /usr/sbin contains OS-related binaries for systems administration. The binaries for local programs (namely, user applications) are stored in /usr/local/bin. Binaries for systems administration for locally-installed binaries are in /usr/local/sbin.

The division between /usr and /usr/local is actually wonderful; there is a similar division for /etc and /usr/local/etc. It all makes sense once you get the hang of it.

I diagree that it should be more vertical. There are only a half-dozen or so directories for most of the systems-related areas. I'd hate to have to traverse down a half-dozen directories to reach the one in which I'm interested, when I can only go down a level or two as it is set up now.

DrJ

[gnutux]

didn't I explained that when I typed out all the directories?

xboxrulz

[KiSS]

I meant to say

/System
/bin
->/admin_bin
->/com_bin
/boot
/dev
/config [etc doesn't make sense]
/mnt
/media[initial bootup on peripherals then pass control to userland
control, to userland Media drivers - Usermode drivers -
Vista]

/Media
/Home
/All_Groups
/Group[name of group]
->/All_Users
->/user1
:
:

/Libraries
/Temp
/Shares

Maybe good if you don't want to traverse a hiearchy and quickly get to where you want to go.

But just pondering the use of ACLs in a vertical hiearchy -

Deep Vertical OO hiearchies are fundamental of OO programming and Soft Eng. May not apply here - but there are good reasons that OO has them - In comb with ACLs could provide isolation and encapsulation between kernal and userland, between various apps, between drivers and apps

just a though

KiSS

[gnutux]

How about giving 2 choices to the user:
Beginner
Intermediate/Expert

Beginner gets the directory listing of what others requested
Intermediate/Expert users can get the original UNIX directory listing.

xboxrulz

[pcbsdusr]

what about hiding things by default and have a swich on the system pcbsd manager that unhides it for ppl who preffer it that way?

I would also advise unhidden mode when one uses root previleges.

[lazyilmaz]

I think it doesn't matter how the directory structure looks like, the most important are /Home
/Programs
And they both are present in PCBSD, now all you have to do is hide the rest for the regular users, only the root user can see the rest.

[pcbsdusr]

I agree but a swich would be a good idea for advanced users.

some people just like to have it that way and it's not something regular users would complain from :)

[pcbsdusr]

I have been at Gobo's site and read all the documentation they have available there.

If i understood it right, what Gobo has is indeed a whole new structure which was very well thought and tuned.

The "legacy directory structure" they have is a fake directory in which files were replaced with symlinks to their locations at the new directory.

They only have it because there are still lots of programs which are part of the system and use "hard coded paths" in their code. while patching those programs to work on the new directory was possible, it would require extra work just to maintain the system each time one of those comnponents were updated. This is why a "legacy tree" will still be needed for years.

If you go here:

http://www.gobolinux.org/?page=documentation

you can read the same i did and get a better picture of the "new directory structure" issue and the reasons behind the whys, hows of that system.

Having read ad tried gobo, i must say i like the way they made things in a general way but i must also say i would not like some of those ideas implemented the same way on a desktop OS. Gobo wasn't made with the esktop user in mind, it was made regarding advanced users and for a system like PCBSD, the approach would have to be slightly modified in my opinion.


Some day we will have to take a decision:

- Live on top of 100% intact freebsd OS and all the issues with compatibility between PBI and FreeBSD
(PBI would have to evolve to be compatible with FreeBSD's tools among other things)

- Create a Gobo like system with a "legacy tree" and still maintain FreeBSD (modified) commands and packages
(freebsd users would not feel at home despite the commands and tools)

- Keep the old structure and adapt it as well as it's tools to our reality while maintaining commands and packages installed the "old way" without breaking the system
(easier to freebsd users to adapt but we'd lose the new structure positive points)

All of those take hard work to accomplish. I like the second. I belive we could create a system with a new structure with a legacy fake directory and keep freebsd's commands and packages.

Read those docs and post afterwords please.

Cheers!

Renato Flórido

[dean_fry]

hey good post!!
i've read some docs and will gobo a go...

i would LOVE to see that in pcbsd!!! come on pleaaaase!!

[pcbsdusr]

Well, the problem with the last two optins is that we most probabily dont have the resources to make something like this hapen easily while keeping up with FreeBSD development.

We need to think what are the positive and negative results in any move. Practical reasons to do something like this.

But one thing is certain, whatever we do with the system, it will have to maintain full compatibility with Freebsd components and packages.
If we can have this while being able to modify the tools to adapt to a new structure and keep all of freebsd commands working (albeit being modified in pcbsd) we can make a change.

But in the end, This system was thought up to be a friendly desktop with a powerful base system underneath (FreeBSD). We simply dont have the resources. The focus here is in user Friendlyness, not huge system changes so what you guys are thinking of could be maybe a different project.

Think of it as the future base of pcbsd.


Here is what you have to do to be sucessful:

-New directory structure - I'd folow gobo's book as much as i could as those guys have thought a lot before creating the new tree.
-Ability to run several versions of any program or dependency taking the principle of placing important files in their own folders - important for pbi usage in the future
- Keep freebsd commands but adapted to the new system
- Maintain ability to use all Freebsd system components, packages and drivers
- Hidden fake Legacy tree for stubborn programs which use hard coded paths and other onsanities

I can't think of anything else right now but i am sure some people here will help finishing this list.

Not easy... Anyone want to start looking for volunteers?

[cb22]

Hmm, there was a program called AdoreBSD, basically a trojan, but it allowed hiding of directories, which could be quite useful, however it doesnt compile on 6, so if a c dev wants to check it out...

[DrJ]

I've largely stayed out of the recent discussion, but I should point out that symbolic links can be more subtle than people generally recognize. Things have to be coded properly in the originating program or one can find one's self in a foreign location.

Here's an example: I have /usr/ports/distfiles linked symbolically to another drive that has more capacity and is slower. So if you cd to /usr/ports/distfiles (to see if you have the right one, for example) you go to the right directory. Now if you type "cd .." to go up one directory level, you are not back in /usr/ports, but (in my case) in /data. That's probably not what was expected.

You can also run into problems when you do simple-minded backups. You can run into recursive copying as you follow symbolic links, giving a size of copied files that far exceeds what you started with. You can even run into cases where doing a recursive copy never completes.

That's not to say that symbolic links are not useful -- they certainly are. But they have to be thought through really carefully so that something else does not bite you in the a**. Compatibility with ports or other parts of FreeBSD might be one of those.

DrJ

[pcbsdusr]

You are correct about symlinking. It might be a tool for some tasks and fail miserably in other tasks. I must also point out Gobo seems to have done it right and i have never heared about any problems there. I am not saying one should folow their strategy 100% but they have actually proved it can be done.

One other way to make things work could be using unionfs, creating pbi's with a fake filesystem and fool the system into beliving the apps were using the real thing. This could be a very nice approach if correctly applied. No major changes to the system would be required and we would have a very elegant pbi system. I am talking about what i read here and there though, i haven't really looked onto this yet.
This option would however leave the filesystem structure issue unresolved but as we could hide most of the system ala OSX it could be very nice.

I disagree with having simplified filesystem directory names as it is really of no use to EU's. To really simplify it for those people one would have to rename the whole system. When someone has enough knowlege to mess with the stuff inside system folders i assume they have the knowlege to do it or the new "easy" names wont help at all. I do agree we should hide most of the system for regular users and leaving it for root.

UPDATE

I forgot to mention... I haven't really thought how could we take care of the dependency duplication issue with these fake filesystem pbis...

Any ideas on this ppl?

[B3CK]

From a BSD and *NIX beginner, I would say to allow the FBSD bring this idea into their segment. Isn't the idea to be built on FBSD? Not, built from FBSD. Besides, as a home desktop or a large corporate network, tracking down files that someone else installed/buggered up, could be a bit of a task when users/guests start touching keys at the desk. I have been using Windows for so long, that the directory system in place is second nature. Even through the upgrades, It didn't even take 10 minutes to re-familerize myself with the directory changes for any upgrade 3.1 - xp ..

I would say to leave the directory the way it is. I don't really need to go through the system of pcbsd to change anything, unless I am following directions I am reading from somewhere. So far every program I have installed doesn't even ask me where I want to install it at, so why should I bother with moving it?

Right now if I understand right, almost any change that might be considered advanced, I can lookup and find in the BSD manual, if things get changed around, I am going to have to read the BSD manual, then translate the directions through the PCBSD manual after that. Sounds kinda hard un-necessary to me.

But then again, as I stated before, I am a complete beginner when it comes to any bsd or *nix.