It seems you're running into the basic problem of an hierarchical filesystem: information isn't relate-able as it is in a relational database Notice how the structure of each directory repeats itself. To a database guy, that screams "Normalize Me", maybe by having a table called TopLevelDirectory with app, etc, and home elements. To a coder, it suggests an Object File System where TopLevelDirectory is a class with members app, etc, and home. (OFS was tried and canned by microsoft in the early 90's.)
I completely agree with Liam. This is a well worn path with briar patches on both sides. On Sat, Apr 27, 2013 at 12:17 AM, Trans <transf...@gmail.com> wrote: > Thought you all might be interested in hearing about my progress in > creating a spiritual derivative of GoboLinux. In turn I use any feedback > you have to offer. > > Originally I had planed to use GoboLinux's file hierarchy with only some > minor modifications, but I have given it a great deal of contemplation and > I am thinking now of taking things an additional step forward in one > respect while taking a step back in another. > > Taking the later point first, I am thinking it might be better to use the > more traditional FHS directory names with some minor modifications, not > because I think that's better --Gobo's full names are a definite > improvement. But it occurs to me that it may be easier for others to accept > in transitioning away from FHS. In other words, by providing a "migration" > path away from FHS toward something more sane might be better received then > immediately jumping to a radical departure from current standards. > > On the former point, I've come up with a concept of division of the file > system into a set of user/groups. Each of these would have the exact same > file layout. Users can belong to groups which grants them access to all > that groups files. System, in Gobo terms, is just one of these user/groups > with some special files in its layout (e.g. the Kernel entries). Another > special group would be the "Common" group which is always shared by all > users. > > As for the exact layout I am torn between two overarching patterns. The > more traditional pattern would keep toplevel "categorical" directories, > e.g. app, etc, home (or Programs, Settings, User in Gobo terms), but under > each of these would be a subdivision of user/group. For example: > > app/ > system/ > common/ > joe/ > etc/ > system/ > common/ > joe/ > home/ > system/ > common/ > joe/ > > This has the downside of separating a users file across different toplevel > directories, but its not so bad given how distinct the types of files are. > This layout also syncs well with the current FHS. > > The alternative is put the user/groups on top. > > system/ > app/ > etc/ > home/ > common/ > app/ > etc/ > home/ > joe/ > app/ > etc/ > home/ > > While radical is a certain sense, this later design strikes me a very > compelling. It turns the whole layout on it's head. It's almost like having > Rootless in every subdirectory of the root file system. I am very curious > to learn what other think of this. > > Finally I want to mention that I came up with, what I think might be good > strategy for getting a distro up and running fairly quickly while also > creating a way around a number of painful boot issues, as well as a way to > have a solid rescue system. Basically the idea is to have two distros in > one. The first is a minimal install that goes in a small primary partition. > It acts as the boot system and takes care of the initial setup of the > system after which it does a chroot over the to the main distro and goes > from there. Generally once the boot distro is setup it rarely needs to be > changed so its a perfect fallback if the main system gets hosed for some > reason. It also doesn't even have to be the exact same distro --which > allows me to start out with a minimal install of an off-the-shelf distro to > get thinks rolling. I am using Debian right now and will probably set it up > something like Damn Small Linux. (Note, I've also been considering TinyCore > but I am not sure that is mature enough to make a very helpful jumping off > point although it has more similarities with Gobo's design. I am also > considering Gentoo.) Eventually this "kickstart" OS can be the same as the > main distro once its mature enough. Why not do that right away? Well, I > suspect that setting up the init system and implementing good hardware > detection is one of the harder aspects of creating a good distro. This > would allow me to worry about those things later, and focus on the package > system and improved file hierarchy first. Please correct me if I am wrong > about this though. Maybe booting and hardware detection is easier then I > think it will be? > > Okay, that's a good rundown thus far. I have few other notions, but those > can wait. Would love to hear what other think about all this. > > > > > _______________________________________________ > gobolinux-devel mailing list > gobolinux-devel@lists.gobolinux.org > http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel > >
_______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
