[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

Re: [XaraXtreme-dev] Doesn't start on Suse

On Fri, 14 Apr 2006 12:59:42 +0100, Alex Bligh wrote:
> > As such Linux is incredibly user hostile and Windows is a lot more user
> > friendly (and I'm talking normal users here who just double click a file
> > and expect to see something, if only an error, happen.)
> Sure, but that, it seems to me, is largely the desktop's problem. If
> you click on a pogram that says "I can't run" and reports the
> error as best it can, you get nothing back.

Yes, the answer to the question "Why didn't the errors on stderr
appear in a dialog box" is more a matter of what the desktop software
is doing at the time of double-click, rather than what the application
itself is doing.

However, there are some things that an application can do at this
point to work better with the desktop. For example, there's a startup
notification (draft) specification which applications can use to make
the desktop be aware that an application is trying to start. This is
what allows the desktop software use busy cursors and otherwise
indicate that something is happening. It seems like that might be the
place to solve the failed to start problem, (I'm really not familiar
enough with the spec. to know if it handles this at all yet). The
specification text can be read at:


and its status is noted as one of several "draft specification that
are new and not yet widely used, though they may be used by one or
more desktops or desktop applications: " here:


Meanwhile, there is a more fundamental question as to how did the
user's computer ever get into this state where a critical shared
library is missing? You introduced a "normal user" who is just
double-clicking. Fortunately, such users will generally not be able to
easily delete shared libraries, (thanks to some user permission
separation that Linux provides).

So then it's just a matter of getting the application installed
properly in the first place.

The software that is most successful at this is the software that is
well-integrated with the entire distribution. Then it can take
advantage of the distribution's package management with dependency
management etc. My experience with using released versions of Debian
or Fedora, say, is that it is exceedingly rare to find a critical
library missing after installing something with the distributions
packaging tools.

Of course, taking advantage of good integration with the distribution
requires compatible licensing. Xara is definitely on the right track
here, and will get there when it ships with an entirely GPL source

Meanwhile, there are application vendors that choose licensing schemes
that are incompatible with the distributions. These vendors do face
problem with getting libraries properly installed, (and face problems
as system libraries get updated/removed by a packaging system that is
unaware of the application). Some vendors respond by shipping static
builds instead to avoid the problem altogether. But this introduces a
raft of other problems as now the application has frozen all the
security-related bugs of its dependent libraries into its own
application. When the user next updates zlib (or whatever) to fix a
security bug, the application might still be running with the old
buggy version.

So, basically, by choosing this route, the vendor has decided to
accept all the problems that the distribution's packaging system is
already solving, (library dependencies, software updating,
etc.). There are things (you mentioned klik for example) that try to
make this easier, but it's still quite a bit of pain to choose. But,
this is part of the tradeoff that comes when choosing licensing that
means the software cannot be an integrated part of the system.

Fortunately, Xara does not appear to be choosing that route at all.

So my suggestion is: Get to pure GPL as soon as possible, and get
integrated into the main part of as many distributions as
possible. Many problems will "disappear" this way---either directly
solved by the packaging systems or else solved by the actual package
maintainers---either way it means less work for Xara engineers.


Attachment: pgpSbaOEjk5Yj.pgp
Description: PGP signature