Just to give a quick idea of the problem and one solution,
I've just downloaded Google Earth for Linux, and after I've
found out that the file GoogleEarthLinux.bin is a really a
script which needs to be started from terminal (guess
whether your mom / dad / gf / wife / sister could find this
out).
It's not necessary to start it in terminal. It's enough to set
executable attribute for GoogleEarthLinux.bin (right mouse click,
preferences, mark executable box, then left mouse click will execute
the file).
By default all files downloaded by browser does not have such
attribute
for rather clear security reasons.
Try to explain this for a novice user.
BTW, I'm still getting: 'Could no display "/home/...."'
I've finally started it from Terminal, so much about user
experience. (Ubuntu 8.10 BTW)
Anyhow, it turns out - miracle - that there is about
50MB worth of _static libs inside_, plus the executable.
There is no even single static library or binary in
GoogleEarthLinux.bin.
All libraries and executable files are linked dynamically.
So it's rather bad example ;-)
Okay, let's pick nits and let's try to avoid my point.
So sorry for saying the wrong word. They are _privately stored
dynamic libs_. Conceptually it's the exact same as if they were
linked right inside - staticly - to the executable. In any case
they are shipping the dynamic libs along with the executable and
storing them in the exact same directory. It's the same as if
hbrun would get shipped a harbour.dylib along with it in the same
dir, and if my app would ship with a local libssh2.so, instead
of using the OS one.
So physically they are separate but logically they belong together,
they are installed in one dir, and there is no additional/external
OS dependency.
Is Google wrong?
Wrong with what?
They created package which can be installed by any user in his
home directory and have a copy of all system shared libraries
used by this application directly or indirectly by libraries
compiled with some extended support. They did not even rebuilt
used libraries without support for unnecessary stuff.
Just simply they put together everything what ldd shows as
dependencies
and is not part of linux kernel in some directory then packed it using
tar/bzip2 and encapsulated in shell scripts (in similar way as it was
done by mpkg_tgz.sh before we disabled it due to problem with sed used
as extractor) using dedicated tool for packing and encapsulation
called Makeself.
It's just _almost_ similar to mpkg_tgz.sh, as Google Earth
will ask you wether to install in local dir (and where) or
to install in global dir requiring sudo rights.
This is BTW an almost perfect solution (apart from unstartable
download icon and the small hassle with 'install' phase) for
a desktop app, and I'd (as a simple user) expect most programs
work this way. [ Too bad this doesn't seem very typical to
Linux, I hope someone can prove me wrong though. ]
So Google did it right. If you look at OSX though, waste
majority of programs will not even require you to "install",
and "installation" is merely done by drag and dropping the app
icon from the downloaded disk image (.dmg) to your preferred
folder. A simple copy, that's it. Sometimes it's just a .tgz
automatically uncompressed and voila your app is right there,
you can move anywhere you want. "uninstall" is just moving your
app icon to the trash can.
Is it good? The question is for whom. Personally I do no like that
I will have copy of 40MB shared libraries in each user directory
and I'd prefer more system friendly installation which will use my
original libraries. The above looks for me like low cost fast
solution.
Przemek, sorry to inform you but you don't represent
the majority of human population when it comes to computing
skills, so while I understand you concern about disk space,
most ppl will just be willing to spend $60 on a 500GB HDD and
forget about the space issue. Probably I don't represent
an average user either, but I simply love the fact in OS X
that you can just "install"/"uninstall" like described above,
and besides being extremely straightforward it also doesn't
allow for any crap to just pile up under the hood, like
most ppl got used to it on Windows. Users can also have
several different versions of the same program installed
at the same time (like the next beta, previous working
version etc), all they need to do is rename one of the icons
to something different. "Switching" between these multiple
versions is also a no brainer. For app developers it gives
a much cleaner environment, with known and tested component
versions and so on.
That's what I'd like to have with Harbour too (on OSX).
I'd prefer this for Linux too, but there unfortunately,
and in contrary to OSX, the 'when in Rome' rule seems
pretty much against it, so I'll live with that.
[ I know Harbour is a compiler not a desktop app for end
users, but I see no reason to give up good OS X practices
and introduce unnecessary and obligatory complexities
just because. Most ppl, even developers have better things
to do than wrestling with tools. ]
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
