Re: gEDA-user: which linux?

["Samuel A. Falvo II" <sam.falvo@xxxxxxxxx>]

On 11/7/05, Xtian Xultz <xultz@xxxxxxxxxxxx> wrote:
> Whats the dependency hell? If you use Yast on Suse to install a package (Yast
> have a very large repository, not so big than Debian, but is big enough) he
> calculates all the dependencys, download them and install them. Like Debian,

Assuming the package you're looking for is listed in Yast.  If not,
you have to install the RPMs yourself, whereby you need to satisfy the
dependencies.  But, as with all Linux packages, you won't know these
dependencies until you actually try to install them.  What's really
missing from all package managers (including Debian's) is the ability
to query the package for dependencies, WITHOUT trying to install it in
the process.

The only thing that Debian truely does over RPM is it tries to
auto-grab the dependencies and is smart enough to install them before
installing the main package.  RPM simply isn't this smart.  Then
again, I'm not sure that it is supposed to be, frankly -- dpkg isn't
that smart to my knowledge either.  The user typically relies on a
higher-level wrapper (e.g., yast, apt-get, etc) to accomplish
dependency auto-satisfaction.

> And I didnt understood what you said about "hidden parts", both distros are
> completely open source.

SuSE 9 and earlier were not open source (at least, not fully).  SuSE
10 and later is.

That being said, trying to decipher how each system's init scripts
work is damn near impossible for anyone who has to work for a living,
especially maintaining multiple (thousands) of servers with SuSE or
Fedora Core installed.  So when something goes wrong, by the time
you've researched the /etc/rc.d(/init.d)/ script, there is another
phone call, or another case on the board, or another customer standing
in line behind your desk.  At work, we had exactly this problem happen
with a customer, whose network interface mysteriously wouldn't start
up on boot (but would post-boot; and yes, modules were being loaded
prior to establishing network connectivity).  The most cost-effective
solution was to just do a ground-up OS re-install, which fixed the
problem.  It literally took less time to do.  So in this case, the
so-called "open source" distro-specific init script system was
*effectively* as opaque as a closed-source product.  Obviously, this
applies to other parts of software as well, and is not restricted to
open source.  The complexity of dealing with device drivers in WIndows
is why you had to reboot the dang thing after moving the mouse for
changes to take effect, after all.

> > Anyways.... Don't install KDE or GNOME. They are realy eating up all
> > your resurces (like M$ windoze). I prefer XFCE, or even no environment
> > at all, just a window managger.

What a nebulous statement, which is simultaneously true and false. 
It's true that you need certain technology which HAS to appear outside
of X11 to work, but the reality is, CORBA and related technologies are
not resource hogs.  (I singled out CORBA and DCOP because they're the
#1 things people point to for being resource hogs.)  As far as the
fancy graphics and all that jazz goes, you can strip those out and
replace them with as austere a theme as you want, thus greatly
improving memory consumption and even rendering speed in some cases. 
Then some talk about the sheer size of the libraries.  Well, yeah, C++
sucks and so does fake GTK 2.0.  C++ sucks because templates are
relatively poorly implemented (and you just know that they're used all
over the place in KDE's core libraries), causing MASSIVE replication
of otherwise identical code, and GTK's implementation of its object
oriented runtime is now so complicated that it makes CORBA look
trivial in comparison.  In fact, GTK tries to do, in-house, what GNOME
typically relied on CORBA to do, without actually eliminating the need
for CORBA -- that is, to make multiple language bindings "simple"
without sacrificing the ease of use for any one language.  The
requirements for implementing new GTK classes is **rediculous** now,
and has an incredible amount of overhead.

So, only one of the three factors listed above contribute to the
bloatiness of the KDE/Gnome systems.  That being said . . .

> Tha XFCE 4.2 is not a good example. XKCE 4.0 was really nice, but 4,2 is as
> heavy as KDE...

. . . I'd like to know how this is true.  XFCE is strictly a window
manager, and because it can be configured to look as arbitrarily
eye-candy or austere as you like, doesn't necessarily make it bloated.
 I don't know what language it's written in, but I'm willing to bet
you, XFCE's codebase is probably a whole lot leaner than other window
managers out there.  Enlightenment E17, for example, includes a
rendering API that (while technologically superior to X11 or GTK)
will, I think, either go mostly unused or will cause some degree of
application fragmentation in the X11 community.  So, as a result, you
may end up with *three* sets of libraries on your box that all do the
same basic tasks of rendering stuff to windows: GTK, KDE, and now,
E17's core drawing libs.  Wonderful.

All this, because X11 is a slipshod graphics API.  True, it "works." 
But it doesn't solve problems -- it creates them.  As such, it needs
to be retired from service, and replaced with a *pure* CORBA-dependent
API, like Fresco/Berlin.  ("But Fresco is slow as molasses!"  Yeah,
until you use a high-performance ORB like ORBit.  MICO has
characteristically and categorically been the slowest ORB ever tested.
 OmniORB is significantly faster for C++ users.)  Let CORBA handle the
network transparency.  Let CORBA handle the language indepenedence. 
That's what CORBA was expressly *invented* for.  Then, we can
concentrate solely on offering a consistent GUI API that is
significantly leaner than the E/KDE/Gnome triad.  Then we can move on
in life, and end this thread.

We now return to our regularly scheduled gEDA discussions.

--
Samuel A. Falvo II