[lsb-discuss] tux assistant idea

rahul at reno.cis.upenn.edu rahul at reno.cis.upenn.edu
Tue Feb 4 09:07:30 PST 2003


On Tue, Feb 04, 2003 at 10:26:47AM -0600, George Kraft wrote:
> Currently, we have over a dozen LSB certified systems following the
> FHS.  As we move forward trying to get the ISVs to certify, then they
> will be following the FHS and registering themselves with LANANA.  I
> believe we have adopted a good definition, and we have a good process
> and plan for adoption.
> 
> 
> Max OS X has the potential to become LSB certified  :-)
> http://www.apple.com/macosx/jaguar/unix.html
> 

George, I very much doubt it..the Mac file system is organized in a radically
different way. See:
http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/FileSystem/index.html
But FHS is sufficiently flexible that this should be possible.

My own personal opinion is that the organization is more intuitive than that in the FHS. But my point is entirely different..

Its not a criticism of the FHS, but of practises that have developed. For example the FHS explicitly states that only the loader and C library need be found in
/lib. Fair enough as a system has to bootstrap. 

On any standard linux system there is a mess in /lib and /usr/lib. Versioning and
multiple dll's are hard (dll hell). On the Mac, a framework has a structure like so:
framework/[v0.1/v0.2] with a current symbolic link to the current version.
Apps can define their own libraries in Appname/lib or similar. Now I believe none of this is incompatible with the FHS. 

But the FHS goes onto define /usr/lib and /usr/bin, etc, which I believe has encouraged from the time of FSSNTD the proliferation of apps in /usr/bin and libs in /usr/lib. LSB (IMHO) should have stuck with /lib, etc and whatever was needed
for the kernel and left the other parts aside. I believe it does a great job of defining the dynamic loader. But thats all thats needed: an interface, a way to get to libs once a bootstrap is in place. That itself is enough for any
competing set of library policies to co-exist.

By defining /usr/lib, etc there appears to be a notion of preference. Ditto for RPM's..(see innovations in micro-package-manager for exxample, or Appdirs in Mac..). Ditto for runlevels, where gentoo, serel, et have been doing interesting things.

so thats my point really, that the definition ought to be even more minimal,
with things such as /usr/lib defined, if at all, in a separate layer..

Anyway, in the end the market will decide, the only problem we might have is
that the market seems to be choosing the mac. At which point we say that we
fill the server niche, not desktop anyway and our policies are appropriate to that. And at which point the market says..that was an identical situation with windows and unix. But then came winnt and 2k..

Oh well...
Rahul

> > 
> > Rahul
> > On Tue, Feb 04, 2003 at 08:09:26AM -0600, George Kraft wrote:
> > > On Fri, 2003-01-31 at 19:31, rahul at reno.cis.upenn.edu wrote:
> > > > To play the devil, and go completely on the other side, the argument could
> > > > be made that for a desktop, the LSB, more precisely the filesystem spec 
> > > > might even be the wrong solution.
> > > > 
> > > > Take the Mac for example. Its filesystem structure derives from the old NeXT,
> > > > and for users, is way more intuitive. The appliocation structure has more
> > > > in common with old unix (/pkg/appname/[bin/lib, etc]) than with present day
> > > > linux systems and their preponderant usage of /usr, which is a consequence of rpm and deb, which in turn is a consequence of the mid 90's where disks were not
> > > > too large, and repeated libraries were a no-no.
> > > 
> > > I'm confused by your statement, because the FHS promotes /opt/ and not
> > > /usr/, which is similar to your /pkg/ example.  :-)
> > > 
> > > http://www.pathname.com/fhs/2.2/fhs-3.12.html
> > > 
> > > http://www.linuxjournal.com/article.php?sid=4121
> > > 
> > > George (gk4)
> > > 
> > > 
> > > _______________________________________________
> > > lsb-discuss mailing list
> > > lsb-discuss at freestandards.org
> > > http://freestandards.org/mailman/listinfo/lsb-discuss
> > 
> 
> 
> 
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at freestandards.org
> http://freestandards.org/mailman/listinfo/lsb-discuss




More information about the lsb-discuss mailing list