Hardy+1 Idea: GoboLinux Filesystem Hierarchy?

Pär Lidén par.liden at gmail.com
Thu Jan 10 09:07:19 UTC 2008

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.


2008/1/9, Stephan Hermann <sh at sourcecode.de>:
> Hi,
> Am Wed, 9 Jan 2008 13:42:43 -0600
> schrieb "Conrad Knauer" <atheoi at gmail.com>:
> > On Jan 9, 2008 5:15 AM, Guilherme Augusto
> > <guilherme.augustus at gmail.com> 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 at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20080110/d6f3f0e3/attachment.html>

More information about the Ubuntu-devel-discuss mailing list