Firefox 2 on Dapper

Donn donn.ingle at gmail.com
Wed Jan 17 15:20:51 UTC 2007


Okay - I get it on the whole, just a few more things, keep your cool now.
:)

> First, because you distributed the ocx controls and didn't rely on the
> users to have or install them.  
I meant that they are no different to me distributing custom-made class files 
in a wxPython app on Linux - i.e. they are integral to the app, but not to 
the O/S.

> Second, the way Windows apps search for 
> libraries benefits in this instance only in that they (these days) search
> in \Program Files\Common Files\<app or company name> then in the system
> folder.  If you look at \Program Files\Common Files\ you are likely to find
> lots of copies of the same libraries, sometimes different versions.  Before
> w2k  and this hierarchy, conflicting versions of libraries caused frequent
> windows crashes.
So, Windows has a clever way to allow apps to search for the libs they need 
while Linux has only one copy of the libs and no way for apps to look for 
others. Yeah?
<wishful thinking>
If so then I would hope that some way is found to imitate the search-for-libs 
thing Windows does, as this would mean distros can have lives > 6 to 12 
months!
</wishful thinking>

> Use /opt for totally self-contained apps like Firefox, OpenOffice, Oracle,
> etc.
Right - got ya. Thanks. I'm going to assume it's no diff to using a dir in my 
home folder. Totally enclosed either way.

> Use /usr/local for apps that want to use the standard locations for 
> libraries but are not native to your distro.  They should the /usr/local
> tree should resemble your /usr tree with lib, share, bin and other
> subdirectories. This keeps them from interfering with your distro.
This one has me a little confused. I confess I have never been really been 'at 
home' with /usr/local. What would the diff be between an app in /usr/local 
and one in /opt ? I mean that app can still think of /opt as it's root and 
find /opt/bin and /opt/share etc. No?

/d




More information about the kubuntu-users mailing list