On Mon, 2006-06-12 at 18:05 -0700, Matt Ingenthron wrote: > Erast Benson wrote: > > > > I think Google folks did a nice job on Google Earth for GNU/Linux. Their > > applications does not depends on any sort of distribution's permutations > > and installs all needed libraries in a single user home directory called > > "google-earth". They do not use any system package and install it as a > > pure add-on application, self-contained and self-sufficient. That means > > it doesn't really matter whether QT is pre-installed or not. Their > > installer looks really simple, slick, fast starting and without any > > internal system packaging dependencies. > > > > I think we are seeing real example on how closed-sourced add-on GUI > > application for UNIX/Linux should look like to be successful. IMHO > > > Sounds a bit like the approach of current mozilla code or even legacy > Netscape code (that statically linked with motif to avoid platform > differences). > > I understand where you're coming from, but from a philosophical point of > view, that's throwing out all of the advantages we have with dynamic > linking to avoid the problems we have as an industry with agreeing on > stable, forward compatible interfaces, right? > > Take for instance a major security hole in libfoo. Your distribution/OS > issues a patch for libfoo. You apply the patch, and everything that > uses libfoo is now safe. However, BigApp X, to avoid having to do lots > of testing, make life easier on its users and avoid the problems that > incompatible implementations of various pseudo-specifications across > patches/packages/distros/kernels/builds/projects, bundled it's own > private implementation of libfoo. Well, now it's out of date, and needs > its own patch... > > There are other things you lose. Like efficiency (in memory once > regardless of the number of apps/users) and the ability for a > patch/upgrade to introduce new functionality or platform level > integration that doesn't break compatibility. > > In my humble opinion, the fact that Google Earth works well is probably > more a testament to the fact you can write good (or bad) code with any > compiler/language/toolkit. Some make it easier than others, but we > can't say it became a good app because it bundled it's own > implementation of common components. :) > > Personally, I'd be more impressed if it made use of whatever was around > on the OS (and libs, windowing toolkits, etc.), ran on many of them AND > was a very well done application. > > That's much more work for someone though-- either Google if they figured > out the least common denominator, or the various OS/toolkits if they > suddenly got religion and put much more effort into compatibility.
While I surely agree with your idealistic view, it doesn't work from any practical sense for UNIX/Linux. Remember, we are talking about GUI *desktop* application. People who are using desktop on their daily basis expect everything to just work without reading manuals and resolving packaging dependencies issues, i.e. just follow Installation GUI, click, click, click.. start.. done. And if some distribution do not ship this particular QT library(and they have a full rights to do so), it should not be a show stopper for the add-on GUI application to run. Sure it is not a most efficient use of *some* dynamic libraries, everybody understands it I guess, but this is not that high price for a GUI application to be easy to install, easy to use, easy to remove. This is the price for *nix flexibility. Besides, do you really care about of 5-6MB extra memory these days? And big chunk of unused code segments could be paged out anyways, which is especially the case for GUI type of applications. Erast _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
