Does GNOME work?

[Christopher Masto <chris+gnome netmonger net>]

[I apologize for the saga-style introduction.  Skip it if you don't care
how I ended up on the path of GNOME.]

Ok, here's the deal.  I got some extra disk and RAM on my workstation
a while back, so I decided to do some experimentation with my desktop.
Although I am a fan of the GPL, from what I could tell on GNOME's web
site at the time, there was barely anything available.  Also, there
was a port (I use FreeBSD) for KDE.  So I installed KDE, and was
rather impressed by some aspects and dismayed by others (their window
manager, for example, is very nice, but it also seems to take over
keys like alt+tab and not let you have them back).

As time passed, and KDE 1.0 was released, I started installing more
applications.  Eventually I came across ksirc.  The released version
of ksirc did not work with the most recent version of the qt libraries
that I had installed.  I downloaded a more recent snapshot of ksirc.
The more recent snapshot required some kind of exception support that
was missing from the gcc 2.7.2.1 that comes with FreeBSD.  Ah, but
FreeBSD had a port of egcs.. so I installed egcs-2.91.53.  Ksirc
built.  Ksirc would not link.  Something about g++ libraries and eg++
libraries not mixing.  So I rebuilt qt.  Ksirc linked and ran nicely.
KDE no longer worked (whoops, forgot that KDE was linked against that
qt I just replaced).  So I rebuilt KDE.  (Taking several hours; I
think egcs, being a development version, was built with no
optimization.)  I had my KDE back, but now kpanel wouldn't start up.
So I installed gdb, ddd, and xxgdb.  I spent a day or so trying to
find the problem with kpanel, but being written in C++ made it
particularly difficult (I am not a C++ expert and apparently neither
is gdb).

While this all was going on, there was also the perpetual background
of the qt license "disagreement" on the KDE mailing lists, and when I
thought about my personal opinion on it, I realized I didn't really
like it.  Factor #3 was that I installed the GIMP, which I had
previously played with in an earlier version, but felt it was
incomplete.  The current version blew me away with its
more-than-completeness, and I quickly decided to take another look at
GNOME.  It seemed that a lot more work had been done, and since I was
spending my time debugging KDE, I felt that I'd be better off putting
my energy into something whose license I agree with.

--> Start reading again here if you skipped the intro <--

I've got GNOME running on my system.  Or, rather, I'm still using kwm,
but occasionally I can start GNOME's panel for a while, and I'm using
electric eyes to view images.  I don't really feel like I'm using
GNOME.

[Skip a bit if you're not into technical details]

I admit I'm somewhat new to this, and I'm aware that it's all
considered "alpha" code, but I find myself wondering whether it's
"supposed" to be this unstable, or whether most of my problems are
because I'm using a different operating system or a different compiler
or whatever.  This is not intended to be a slam on GNOME or its
developers; you've contributed a ton of code to the free software
community and I'm very glad to be able to see and work with it.  It's
just that so far, I've had to make a lot of changes just to get things
to compile, and when they do compile, to get them to run.  Code like
this scares me (ORBit/src/IIOP/connection.c):

  newfd = accept(GIOP_CONNECTION_GET_FD(connection), &sock, &n);
  newcnx = GIOP_CONNECTION(iiop_connection_from_fd(newfd, IIOP_CONNECTION(connection)));
  GIOP_CONNECTION(newcnx)->orb_data = connection->orb_data;

There are two major opportunities there for failure leading to a null
pointer dereference, and neither of them check for it.  In fact,
iiop_connection_from_fd specifically returns NULL if it's been given
an invalid fd (such as the -1 accept() returns on error).

Or how about this one from gnome-core/panel/panel-util.c:

  if (fwhich == NULL)
    return NULL;
  if (fgets(buf, PATH_MAX+1, fwhich) == NULL) {
          pclose(fwhich);
          return NULL;
  }

Innocuous enough, except that it's used in extern.c like this:

  fullpath = get_full_path(path);
[...]
  ext->path = fullpath;
[...]
  exec_prog(applet_count-1,fullpath,param);

exec-queue.c:

  exec_prog(int applet_id, char *path, char *param)
which calls:
  really_exec_prog(int applet_id, char *path, char *param)
which does a fork, and in the child:
  execl(path,path,NULL);
  g_error("Can't execl!");
and in the parent:
  printf("started applet, pid: %d\n",child->pid);
  child->applet_id = applet_id;
  children = g_list_prepend(children,child);

And eventually blows up somewhere, all because the applet it wanted to
start wasn't found in the path.

Again, I'm not posting this to denigrate anyone's code.  It's alpha
stuff, and these things happen.  But it's a lot harder to go back
through and find them all than it is to meticulously check return
values when writing it.  It may not be easy to recover, but at least
the error can occur locally, so it's easier to debug.  I personally am
very lazy when it comes to continuing work on a project past the "it
starts and it works for me" stage, but I will try to continue to
contribute patches rather that just whining about things.

--> Start reading again if you skipped the technical bit <--

My main intention for writing this message (line 115 is a great place
to start to get to the point) is that I have been jotting down notes
on what seems to be the state of the various GNOME bits and pieces, so
that I remember what to go back and try to fix.  I thought I would
post it here to see if my experience is anywhere close to what it
should be (i.e. are these things working for everybody else?).  Please
keep in mind that this is just what it looks like on my machine; I'm
not trying to make authoritative statements about these programs.
Things that are not mentioned here I probably haven't installed yet.
I intend to investigate them all and supply proper bug reports, if not
patches, but in case there's anyone out there looking for something to
do..:-) The numbers in brackets are how often a crash occurs, on a
scale of 1-5.  (1 = happened once, can't reproduce.  5 = happens
always)

panel
  segfaults randomly [3]
  locks up sometimes (when saving?) [2]
  menus open in panel's window the first time
  user menu disappears
  most applets don't work
  most applets are linux specific
  applets crashing failing often take panel with them [4]
  crashes on or before first mouse click when started from gnome-session [5]
  occasionally locks and eats 100% CPU [2]

gnome control center
  does not start
    - ** ERROR **: file tree.c: line 68 (merge_nodes):
    + assertion failed: (node1 != NULL)

session manager
  crashes constantly [4]
  save-session can never connect to session manager

gnome-objc
  all of the test programs bus error on startup

gulp
  does not start (bus error)
    - probably because gnome-objc doesn't work

gxsnmp
  crashes easily [4]
  - edit->configuration causes immediate segfault
  doesn't actually work (cannot seem to do SNMP gets)
  lib/test program crashes (bus error)
  canvas and MIB browser seem stable

logview
  does start, main log display seems stable
  crashes occasionally when trying to open a logfile [3]
  focusing calendar eats 100% CPU (but calendar does work)
  zoom messages refer to linux despite running on FreeBSD

other
  file dialog won't show dotfiles
  file dialog won't go to a typed-in directory

WORKING AT OR CLOSE TO 100% STABILITY:
  electric eyes
  gimp
  menu editor
  most properties panels
  terminal
  help browser

- - -

Also, I would hope that GNOME is targeted at the platform known as
Unix, and not at the system known as Linux.  I'm glad to see autoconf
and such being used.  I have nothing against Linux, but for reasons
best left to another discussion, I think it is unfortunate that so
much "Linux software" is being produced.  I will be building GNOME
stuff on my FreeBSD workstation, but I would be glad to offer access
to GNOME developers who otherwise wouldn't be able to test their
programs outside of Linux.  I would hope that there are people out
there with other Unix systems who can also offer test builds,
particularly approaching release time.

Thank you for reading.
-- 
Christopher Masto        Director of Operations      NetMonger Communications
chris@netmonger.net        info@netmonger.net        http://www.netmonger.net

   You'll read that Bill Gates envisioned it all, which is a crock. he
   didn't invision any of it. Nobody did.
   - ED ROBERTS, Gates' First Boss