Hardy+1 Idea: GoboLinux Filesystem Hierarchy?

[Stephan Hermann]

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