One thing I like it with the current way is that all config files the user need to edit are collected under /etc. Of course, if the symlinks works correctly, they would still be with GLFH, but it would probably be quite a mess to support this properly, and ensure that every config file actually gets linked in the right place. And I'm not looking forward to have to check both /etc, and having to sometimes search thtough the /Programs dir for the right progam. right version, and then find the config file there.
I haven't used GoboLinux for myself, but I have a hard time to see exactly how this would make things easier for users and admins. If a user wants to install a custom version of a program, he can easily do that in his home-directory, or if he has sufficient privileges, under /usr/local. I know that /etc , /usr and so on are not very intuitive names, but I don't see that as a drawback major to warrant this change. Or maybe that this is the wrong solution to that problem. Just my two cents. Cheers Pär 2008/1/9, Stephan Hermann <[EMAIL PROTECTED]>: > > Hi, > > Am Wed, 9 Jan 2008 13:42:43 -0600 > schrieb "Conrad Knauer" <[EMAIL PROTECTED]>: > > > On Jan 9, 2008 5:15 AM, Guilherme Augusto > > <[EMAIL PROTECTED]> wrote: > > > > >> http://www.gobolinux.org/?page=at_a_glance > > > > > > What would improve by using Gobolinux filesystem hierarchy? > > > > A little over a year ago SABDFL blogged on > > http://www.markshuttleworth.com/archives/66 > > > > --- > > A long, long time ago, packaging was an exciting idea. [...] Today, > > these differences are just a hindrance. The fact that there are so > > many divergent packaging systems in the free software world (and I > > include the various *bsd's) is a waste of time and energy. [...] I'd > > like to see us define distribution-neutral packaging that suits both > > the source-heads and the distro-heads. > > --- > > > > The GLFH sounds like a good way to create a standard package format > > that can be easily layered over any *nix OS... > > Well, I don't like to interfere here with Mark, but packaging has > absolutely nothing to do with a filesystem standard. > > Mark blogged this stuff not because we are in need of a new Filesystem > Standard, but because we invent many different packaging methods for > the same stuff. RPM, DEB Packages, SlackWare, this new python based > packaging systen, solaris pkg, etc. > > A Filesystem Standard should always be applied on all unix alike and > old unix operating systems. I wonder if you can apply GoboFHS to an > old fart AIX unix or onto an tru64? (well, tru64 + solaris > are the only real unixes on the market which a unix admin needs to > work with...linux is a unix alike system and most of the admins are > working on linux). > > Therefore introducing a complete new FSS doesn't bring any good to the > world...and right now, we are not talking about the desktop here, just > because until today there is not a real revenue stream to see from > linux for desktop (hopefully this will change). > > > Reading the docs of the GoboFHS this is just an add on to the normal > base file system structure, therefore I think when we use our > braincells in a good way, we find a better way, then symlinking stuff. > > A sysadmin has more clue about the system then the normal user has, > which is good, so the sysadmin needs to take care about the user needs. > > A user just wants to save a file in a special location, let's say: My > Files/Pr0n/Hot/Stuff/ > > This is already being the reality...so for what we need a change > in /var/www/mywebsite/htdocs/foo...where user bla can't save anyways? > > > > > On the other hand, if someone already uses Linux, he probably got > > > used with the "normal" filesystem hierarchy. If it is someone's > > > first time, wouldn't it be confused to have a filesystem in a way > > > and every Forum, HOWTO and other help docs over the net telling how > > > to do things with another filesystem hierarchy? > > > > "the Unix paths [...] are actually there, but they are concealed from > > view using the GoboHide kernel extension. This is for aesthetic > > purposes only and purely optional" IOW, the old way of doing things > > should still work. > > Yes, but we introduce new bugs when we use a kernel extension for this. > How long will GoBo support the stuff? > > > Also, just as an aside, I find that if I need Ubuntu help, searching > > for '[my problem] Linux' isn't nearly as helpful as '[my problem] > > Ubuntu'. People will adapt, just as someone moving from KDE to Gnome > > will adapt to the different apps and controls. > > Well that's one of the problems we have right now. Many people think: > linux == ubuntu and Ubuntu == linux...which is totally nonsense. > When I have a problem using my Ubuntu, hopefully the same problem will > occure on any other distro as well. So linux as searchterm would be the > right thing to do. > > > I don't think the GLFH should be rejected (just) because its > > different; there would never be any progress if we do that ;) > > The problem is not the idea, the problem is the implementation. as > always. The computer was a good idea, but the implementation was a real > bug ,-) (Happy Birthday Mr. Weizenbaum, Greetings to Berlin) > > Regards, > > \sh > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
