Linux installation

[Richard Gaskin]

Bob Warren wrote:

> 1. An "executable" (e.g. a file produced by VB in Windows) is not a 
> program, it's half a program. Nor is it executable. It finds its other 
> half in the operating system it is running under (in the form of 
> libraries), and when the 2 halves are put together, it can do something.

This is way OT, but folks here who enjoy what is usually a true 
standalone may get a kick out of what ToolBook makes as an executable: 
it adds only the tiniest stub of code to the stack file to help it find 
a collection of DLLs strewn all over three or more directories across 
the user's system.

Given this complex hodge podge, the boot sequence is so complicated that 
as of v6 it was not in the docs that came with the product.  I had to 
trace it out once for a project, and when I was done I submitted my 
summary to Asymetrix tech support who thanked me for what they described 
as the first time their complex boot sequence had been documented.

I'll take a self-contained executable file any day. :)

When I described my apps' structure to my VB developer friends, they 
almost fall out of their chair with disbelief at its simplicity and ease 
of installation (how many millions of hours are wasted each year 
resolving DLL conflicts among apps built with VB?).


> 2. A "standalone" is a whole program, not half. It does not refer to any 
> libraries at all in the runtime operating system**, and can be executed 
> directly.
> 
> [** except perhaps totally invariable ones - if such a thing exists??]
> 
> What Jacque seems to be trying to tell me is that in spite of the 
> denomination, Rev "standalones" for Linux are not pure. They mainly have 
> the characteristics of the 2nd category, but they have some of the 
> characteristics of the 1st.
> 
> Although this does not seem to fit in with an ideal situation, is it 
> certainly true in Linux?

This may be because the Linux GUI experience isn't an actual "thing", 
but really a collection of many different things, chiefly the kernel and 
the window manager.  KDE isn't Linux, Gnome isn't Linux, and KDE and 
Gnome use different APIs.

So while adding a GUI layer on top of Linux can provide a reasonably 
satisfying GUI, Linux itself is not a GUI per se, with the GUI being 
handled by these window managers delivered by different teams.

In contrast, while Apple's OS X is a window manager that rides on top of 
BSD, the vendor has assumed responsibility for integrating the two into 
a single cohesive experience.

If you take away the Finder and all the Aqua support from OS X, and 
allow anyone to make any number of alternative GUIs, OS X would provide 
the same level of confusion and fragmentation in the market, and 
developers would have as much difficulty delivering consistent 
appearances as they have with Linux.

I agree that it would be desirable for RunRev to come up with a scheme 
to have native appearances on all of the various incompatable Linux 
window managers, but it's not a simple task until those development 
teams start prioritizing Linux adoption higher than they value market 
fragmentation.

Admittedly this does raise a philosophical question of what constitutes 
"self contained" when it comes to Linux executables, but I'm not sure I 
would place any blame solely on RunRev, esp. given that RB has related 
issues.  It seems more fair to chalk it up to the inherently fragmented 
nature of GUI Linux.

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com