Re: [Hampshire] What do you think?

Top Page
Author: Andy Smith
Date:  
To: hampshire
Subject: Re: [Hampshire] What do you think?

Reply to this message
gpg: failed to create temporary file '/var/lib/lurker/.#lk0x58011100.hantslug.org.uk.2070': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Sun Jul 19 15:04:43 2009 BST
gpg: using DSA key 2099B64CBF15490B
gpg: Can't check signature: No public key
Hi Stephen,

On Sun, Jul 19, 2009 at 02:06:13PM +0100, Stephen Davies wrote:
> As everything in Linux/Unix is a file and the majority of these files
> are plain text there is a great temptation to edit them manually
> especially if you are remotely logged into the system over a slow
> connection and using the GUI is not practicable.


If use of the GUI is not practical then I don't see the point of
configuring it remotely, use a different tool altogether.

I also don't agree that configuring a GUI application must be done
with text files. If the application is a GUI then I think it should
be configured with a GUI, preferably part of the same application
itself.

It might be fine to read a config file to change some of the more
esoteric options, but I don't see why the majority of configuration
can't be done in the GUI. It seems to work for Firefox, which is
the largest GUI application I run.

By the way, I tend to prefer non-GUI applications for most things.

> Once you have done that there is a danger that the changes you make will
> not be picked up by the GUI application. This particularly applies to
> comments. Nice and helpful as they are, how many GUI’s distributed in a
> standard Linux Distro today can handle comments.


I don't know but it seems a trivial problem for the author of the
GUI software to overcome.

> It is good practice to comment any changes so that the next person who
> comes along to fix the problem you edit has just caused can know who did
> what, when & why to the file. Yep, the version history strikes back. How
> many GUI’s give you the opportunity to add a new bit oh version history
> to the file? Not many I’d be willing to guess.


The configuration of client software is typically not versioned. Do
you need it to be?

It's a good question about how to maintain central configuration
control for GUI desktop software.

> Then comes CVS (or something similar). We all know that it is good
> practice to use CVS/SVN/git or some commercial package to store those
> ultra critical files in so that when your system goes down in a heap of
> flames (it does happen) you can pull everything out of your Source
> Control System and deploy it on the new system knowing that it is the
> latest version.
> Some of these systems add comments into the file showing the checkin
> date/time & user. This is great for auditing purposes but we are back to
> the problem, how does the GUI handle comments. Again, the answer is not
> very well.


I'm not aware of any SCCS which adds stuff into the files under
control, unless you tell it to. And if your file format supports
comments then this again seems trivial.

>
> Command line option applicability
>
> With some applications that have a plethora of command line options the
> is often some which will not work together or worse still, are ignored
> completely if they are placed after another option of the command line.
>
> How is the GUI Developer going to easily, reliably code up the rules for
> the GUI so that the application has a better then 50/50 chance of doing
> what the user wants when if gets kicked off?


Config files are typically used when command-line configuration
becomes too complex.

> Estimating the number of test cases to ensure that the test coverage
> could be a daunting operation and without a decent tool to actually do
> the manual application of GUI operation it could be almost impossible.


Testing definitely seems the hardest thing to me. As always.

> One company I work with has done this for one of their applications
> already so it is not just some crystal ball gazing. The costs of
> maintaining the GUP have since dropped by more than 50% and from that
> experience, they are considering doing it for more applications. Note,
> this is not anything you will find buried in dome Debian repository
> somewhere and will cost you more money than most LUG users will earn in
> a year.


Nice implicit suggestion that expensive closed source software is
inherently better than FLOSS! Solaris used to cost a lot of money
and Windows still does, but I think Linux is better than both of
them. There countless examples of FLOSS that is the best in its
class. I don't see the point of your "you won't find this in
Debian" comment.

> Clearly this is not ideal practice and it is going to take a sea change
> in attitude by developers to achieve this even on a small percentage of
> key application in Linux but if the goal of doing away with the command
> line is to be achieved then I think that this change is essential and
> long overdue.


I don't really see that the standards of configurability for popular
Linux GUI apps is any better or worse than those for Windows.

I think this could be improved, but "doing away with the
command-line" is not a goal I support and I think is orthogonal to
making better GUI apps.

GUI apps could be better. On Linux and Windows.

> The ideal state would be that the GUI did the following:-
> 1) I can do EVERYTHING via the GUI that I can with vi or emacs
> 2) I can be sure that the options I select using the GUI will work and
> not be rejected due to some illegal syntax or combination of options.
>
> The $64,000 question is: Can this ever be achieved?


1) No; there are always going to be things you can do on the
command-line that can't easily be replicated in the GUI.

2) Yes. The answer to (1) doesn't mean that a GUI app can't be
completely configured to the satisfaction of 99% of the user
base, in the GUI. I don't expect Firefox to crash or behave
wrongly just because I set something in one of its GUI config
sections. While it might do that and certainly has done before,
that is a bug which can be fixed.

> Conclusions.
>
> While the ambitions of those who want to relegate the command line to
> history are very laudable,


Are they? I wouldn't use a computer with no access to the command
line, although plenty of people would. That doesn't make me wrong
and it doesn't make them wrong, so maybe it would be better to say
that the ambitions of those who write GUI apps that don't require
the command line are laudable?

> In addition to that, until Linux does not use any shell scripts on
> startup/shutdown the command line will be an essential for
> developers, sysadmins and even users (at times). I don’t think
> that reliance upon scripts will be removed anytime soon after all,
> we don’t want the mess that is the Windows Registry re-invented do
> we?


It already has been, in both Gnome and KDE. It's not a terrible
idea.

I don't really see where your article is going. It spends a lot of
time talking about the configuration of GUI apps and then concludes by
saying that the command line will always be there and Windows
Registry is bad.

Also you seem to not be able to decide if you're talking about the
computer itself or applications that run on it.

Cheers,
Andy

--
http://bitfolk.com/ -- No-nonsense VPS hosting

"It is I, Simon Quinlank. The chief conductor on the bus that is called
hobby." -- Simon Quinlank