Re: [cobalt-users] the GUI interface

[Kris Dahl <krislists@xxxxxxxxxxxxx>]

> 1) Cobalt doesn't view the GUI interface as a convenience tool, or as
> training wheels for those just getting started; they actually intend it
> to be *the* *only* interface for doing system-administration.  This is
> not only naive, but it's strategically impractical to attempt as such
> an early stage in development. Perhaps, over a time they can produce
> robust and flexible software that handles sys-admin tasks more fully,
> they can eventually hint at making a more preferable interface tool.

I would disagree with you on this.  I believe that Cobalt is intending the
interface to be the primary tool for administration.  But they have
intentionally used standard software on the backend, and let you (even
document how in some cases) make changes when neccessary.

Your warranty is voided when you make some changes (and they are *not* hard
core about this--if you install MySQL, they aren't going to give you a hard
time if BIND stops running 6 months later) because of the support nightmares
involved with Linux servers.  Anyone wonder why its hard to find good Linux
support companies?  Its due to the same reason Linux is so cool--there is
more than one way to configure a machine, more than one piece of software to
do each task, which adds up to really hard to support.  Flexibility can be a
hindrance sometimes, look at the lack of compatibility problems on the
Macintosh for example compared to the windows world.

If they didn't want you messing under the hood, they wouldn't let you be
able to do it.  Some 'appliance' manufactures don't--Team Internet for
example.

> 3) The GUI will *overwrite* anything that you do on the system using
> the non-gui interface.  this is really poor design and planning.
> When you startup the GUI, it should read the data that's in the files
> however they got that way, whether were written by a previous
> invocation of the GUI, or by some other human or process.

I do wish that Cobalt wrote a better parser for the datafiles so that it was
more flexible to custom modifications.  But its a pretty difficult task to
write a generic parser for each config file.  They didn't go down that path
for a reason--it would have required a very large amount of engineering.  So
I understand why the did it, but would still like to see it improved.

-k