Re: [Fsfe-uk] Re: An ignorant question?

[Chris Croughton]

On Tue, Jun 10, 2003 at 04:42:53PM +0100, Robin Green wrote:

> The one key difference:
> Windows installers would (and still do, I'm afraid)
> render other programs unusable by overwriting DLLs without warning.
> A decent Linux package manager shouldn't do that, because of dependency
> checks.

True, the package just doesn't work.  Or if you try to force it you end
up with a system which is unusable (been there, done that, tried to
upgrade certain things to the Woody versions from Potato (Debian) and
ended up having to do a complete re-install because it wouldn't even
boot).

> I've already tried to make a case that semi-automated installing of
> necessary packages to resolve dependencies is better than static linking.

Which apt-get does (in Debian).

> Another issue is security. If everyone dynamically links to zlib, and
> a security hole is found in zlib, you only need to upgrade one package.
> If everyone statically links to it, you need to upgrade EVERYTHING that 
> uses it - and how do you know which ones those are? Are all the programs
> you use even MAINTAINED any more?

Nope.  And yes, that is a valid point, and the Debian maintainers are
careful to keep doing security maintenance upgrades for older releases
as well as the 'current' and coming ones (apt-get update, apt-get
upgrade).

> > For instance, I pulled down the binaries for Squeak/Smalltalk, only to
> > find that it wanted a different version of glibc.
> 
> The rough equivalent to that in the Windows world would be downloading
> a program only to find out that it only runs on Windows XP and you still
> have Windows 98. On Windows what do you do... shell out for an OS upgrade?

Well, no, it's more like Visual Studio had installed one version of the
DLLs and an app wanted a later one.

> On Linux you can sometimes get away with just upgrading glibc. I have
> done in the past; only once had a problem, which was due to trying out
> a bleeding-edge version, not due to any actual need to upgrade glibc.

I've managed to completely screw the system.  Because the Debian glibc
package which was the later edition wasn't compatible with some of the
older packages, so it wanted to upgrade them as well, and it ended up
with something totally weird.

> >  If it hadn't been
> > that it would likely have objected to my version of Gtk or whatever it
> > uses for the GUI.  At which point I think of compiling from source,
> 
> Uhh, how is compiling from source going to solve the problem that it
> probably requires features or bugfixes (or even, God forbid, bugs!) which
> aren't in your version of Gtk?

I doubt it does need those, it only needs to know the appropriate entry
points to the shared library (in fact they probably haven't even
changed, but the version number has, or it was compiled wit ha different
compiler, or whatever).  As witness that having compiled it from source
it does indeed work fine, as do almost all of the sources I compile.

Going by the dates of the files, I suspect that it was just compiled on
a system with a later compiler version.

> Compiling from source is sometimes useful for performance and (pre
> GCC3.2) to resolve libstdc++ dependencies (or more accurately, C++ ABI
> dependencies). It does not, and cannot, magically make all version
> dependency problems go away.

No, but any major ones (like missing library functions) will be detected
at configure, compile or link time.  It is very rare, in my experience,
that an executable wanting to link to a specific shared library is
actually wanting to use that version because of bugs in previous
versions, it is much more likely that it's what the person who compiled
it happened to have installed.

> >  So what I want
> > is a single GUI which lets me choose which widget set I want to use
> > (defaulting to whatever) and after that lets me pick from whichever one
> > I have selected, without having to load up yet another development kit
> > with yet another user interface -- and to say "take my application and
> > generate it using Motif (or whatever) so I can see the different style".
> 
> So, let me get this straight. You want a single development environment
> that can automatically convert your application from Motif to Athena
> or Athena to GTK?

It would be nice.  But failing that I'd be happy with any of them, as
long as whatever it is has sufficient functionality.

> I think a more realistic approach would be to pick two (or possibly three)
> toolkits, one for low resource machines and one for high resource
> machines. Then if you're coding to low spec machines for a project, your
> decision is already made. If not, you can pick one of the two.

Yup, that would suit me.

> Note that Qt/KDE have a number of different "look and feels", so they
> can be made to look like other widget sets. However, the default is 
> to use the L&F selected in the Control Center, which means all KDE
> apps have whichever L&F the user or distro maker has chosen.

Let me guess, you have to be running KDE to do that?  What happens if
the app is run under Gnome, fvwm or something even simpler?

> > Because the casual user who just wants to knock up a simple GUI doesn't
> > want to have to use XYZ for Athena, QWERTY for Motif/Lesstif, VBNM for
> > Tk etc., zie just wants to get the job done.
> 
> This casual user can look at, off the top of my head:
> 
> * xgammon for an example of what Athena looks like
> * Muffin for an example of what Motif looks like (it uses Java AWT which
> currently uses Motif)
> * Bitkeeper for an example of what Tcl/Tk looks like
> * GNOME for an example of what Gtk can look like
> * Konqueror for an example of what Qt can look like
> 
> They don't need a development environment supporting 10 different toolkits
> just to see what those toolkits look like.

But they don't show how my app will look with the different toolkits,
neiter will they show the differences between what they provide.

> If they are then programming using 10 different toolkits they are NOT
> a casual user by any stretch of the imagination!

No, true -- but if they only have one toolkit installed and that isn't
the one the development environment supports, that's not going to help
either.  I appear to have Lesstif, Tk and gtk installed (probably Athena
as well but it doesn't seem to be a separate Debian package).

> Choice is a good thing. But asking for a development environment which
> supports all the main toolkits is a bit like asking Microsoft to support
> all Borland's stuff in Visual Studio. It Ain't Going To Happen, I'm
> afraid.

Probably not.  Of course, it could provide its own dedicated toolkit,
that would do...

> > The same goes for other applications.  One thing MS have got right is
> > that they use VB for scripting in every application which needs
> > scripting -- Word, Excel, PowerPoint, etc. as well as "standalone" VB --
> > so you only have to learn one language.  This theoretically could be
> > done with (for instance) Java, but it isn't, they all do their own.
> 
> Well, I certainly agree with that. More apps should support BeanShell
> scripting! (A 100% interpreted language very similar to Java, which
> is nowadays 90% compiled.)

Hmm.  Trouble is that other people want their own favourite (Python,
Vim's own scripting language, S-Lang etc.).  If there were a common
'plug-in' scripting interface...

> KDE does allow language-neutral scripting with DCOP, but it's not usually
> very useful, or even working. I tried scripting Kate and it worked - 
> so long as you only had one file open.

Er, right.  That's the sort of thing which will put users right off.

Chris C