[Gllug] Sluggishness and confusion

[Steve Nelson]

On Thu, 10 Feb 2005 12:45:52 +0000, Bruce Richardson
<itsbruce at uklinux.net> wrote:

> > Examples?  I don't know of many easy-to-use, supported, actively
> > developed, and fully integrated GUI tools on Debian.
> 
> The Debian project doesn't see that as their job.  

Which is no better than saying The RedHat Corp don't see it as their
job to pay developers to work on curses-based tools.

> Look to the various
> user-friendly offshoots of Debian (Xandros, Progeny, Libranet etc).  

I've seen them, and used them - not much to write home about, and not
what you'd run a production cluster on.  I'm not saying Redhat's
perfect - far from it, just that one has to decide where to invest
capital (financially, and intellectually) - more so as a business.

> > I agree.  However in the real world I think Redhat achieves close to
> > this - CLI is reliable, and easy.  GUI tools are reliable, and easy.
> > Curses tools are reliable, easy, but no longer actively supported.
> 
> Why?  It is quite explicitly a bad design decision.

Its not bad design, its good use of resource.  Be serious - do we
still provide for linuxconf in redhat? No - because it was goodish for
its time, and is no-longer used.  Correct me if I am wrong, but how
much active development is there for ipchains now?  Unless I
misremember, there was a time when debian's way of configuring host
address, netmask and default router was to edit /etc/init.d/network -
this no longer exists, and we have /etc/network/interfaces.  No-one
expects us to maintain both systems.

> Great.  So give them that tool.  Just don't make it the primary tool.
> There is no reason why it cannot either sit on top of good cli tools or
> share a common set of scripts with them.  

That's what it does.

> That would be good design, as
> opposed to bad design.

We agree.

> That's like saying "We all know this table only has three legs but Red
> Hat have never yet put anything heavy on the wobbly corner".  It is not
> a good argument for a square table only having legs at three corners.

Your argument holds for any open-source project.  They are equally
vulnerable to radical change.  The scenario you outlined would be as
likely as someone deciding to redesign debian's init process based
around slackware's instead.

> Some of them.  Others, which you do have to edit or extend if you want
> to get perfectly simple and reasonable functionality, are either not
> documented at all or are quite clearly labelled "do not touch".

Quite rightly.  You are advised not to touch the inside of your
computer, your car, your television, unless you  know what you're
doing.  Similarly in Debian - would you advise an inexperienced user
to mess around with /etc/apt/preferences and mix testing and unstable
unless the knew what they were doing?

 > No, quite important parts of them are not.  Find me the documentation
> for the ifup-local extension and prove me wrong.  It's a crap mechanism
> but it is there, so it bloody should be documented.

Interesting challenge.  How do you define documentation? 30 seconds
googling on the redhat page showed dozens of user-submitted articles
mentioning it.  Similarly, is every aspect of Debian administartion
contained in documentation with a debian logo on the front?  Redhat
began as, and still continues to be an open-source, community driven
system, and so its documentation resides in the community.

> My first objection to much of the Red Hat config stuff is simply that it
> is of mediocre quality, often achieving the trick of adding unnecessary
> complexity while actually restricting flexibility.

I think this is a fair criticism, compared to, say, Debian.  I would
say the same of Linux and FreeBSD.  Much of the linux stuff is of
mediocre quality, adding unneccessary complexity without improving
functionality or performance.  Doesn't mean Linux is bad.

> My second objection, which is the one that you've taken issue with, is
> to the design decision only to support the GUI tools.  

I don't like it either, but I understand the reasoning.  What I don't
accept is that that hampers sysadmins who don't want to use GUI tools.
 It never has, and it never will.

> It is fundamentally a bad design
> move.  

Its not a design move - its an idealogical move.  We may not like it,
but its engineered well enough to not interupt the internals. 
Compared with my most recent of experience with suse, which really
does.

> Not only are they moving ever further down that line, rather than
> bringing the end-user and low-level tools back into sync, but it has a
> detrimental effect on the quality of the whole system.  

I think you'll find millions of sysadmins think the quality of RHEL is
rather good.

> Good
> build/design quality requires good discipline, documented procedures and
> documented interfaces that are adhered to.  Not only do Red Hat not
> make such a set of procedures and interfaces externally available, so
> that third party developers can work to those standards and contribute
> their own improvements, but they don't work to them internally.  

I can't speak with authority on this, but I wouldn't mind betting
there are unpaid, open-source developers who are well aware of the
redhat procedures and interfaces.  How else can the fedora project
feed into RHEL?

> If they
> did, the quality of the system would improve across the board.

Which has been uniformly proved with fedora - fc1 was a rebadged RG9,
fc2 was funky but a big improvement, and fc3 is excellent - which is
where this discussion began.

> You do not need to have poorly designed internals to have thos
> advantages.  

This is where we have to agree to disagree.  Debian's network setup is
a better design than Redhat's.  Agreed.  Redhat's is also good. 
Debian's is just better.

> There are historical reasons why Red Hat's internals are as
> they are but carrying on that way only more so is not a good thing.

Should Redhat change the internals radically, like Solaris have with 9
--> 10?  Wouldn't that create even more outcry?  Wouldn't you then
argue that its bad design to evolve the system without continuing to
develop the older, deprecated system too? ;-)

> Bruce

S.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug