FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-21-2008, 02:38 PM
Avi Greenbury
 
Default

On Wed, 21 May 2008 11:04:05 -0300
Derek Broughton <news@pointerstop.ca> wrote:

> Avi Greenbury wrote:
>
> > On Tue, 20 May 2008 14:59:57 -0300
> > Derek Broughton <news@pointerstop.ca> wrote:
> >
> > If you GUI tool exists to stop the user making stupid mistakes, and
> > actually managed it, I would have been unable to do that.
> > Had it not stopped me making what, in general, are stupid mistakes, it
> > hardly seems better than a text file.
>
> Do you actually intentionally make "stupid" mistakes that can never possibly
> work? That's what a config tool should prevent. When a config value needs
> to be a domain name, it may be desirable to permit domains that can't
> currently be resolved, but it's never going to desirable to allow you to
> enter a domain that could never be registered.

It depends on your interpretation of 'stupid' and 'never', I suppose.
What kind of domain that could never be registered, and that no-one
will ever want in their configuration, do you have in mind?

>
> >> Idiots _never_ stop being idiots. You surely know the saying: "The
> >> difference between ignorance and stupidity is that the former is curable"
> >> (Twain, I think).
> >
> > The exact wording (and opinion on the meaning of 'idiot') is immaterial.
>
> It's material, because there are many idiots that get put in the position of
> having to maintain servers, and many of them will _not_ learn. If they
> can't learn, they should at least be prevented from screwing up the
> servers.

As I meant to infer in the above, replace where I said 'idiot' with
'ignorant person'.
If you have, as you say, an idiot who can not and will not learn, and
they should be prevented from screwing up the servers, the easiest way
to accomplish that is to not let them anywhere near them, and let
someone who has learnt do the configuration.
If they cannot and will not learn, surely they're as likely to make
perfectly legal configuration errors as they are syntactical ones?

--
Avi Greenbury

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-21-2008, 02:48 PM
Derek Broughton
 
Default

Chris G wrote:

> On Wed, May 21, 2008 at 11:12:38AM -0300, Derek Broughton wrote:
>> Les Mikesell wrote:
>>
>> > And the best user interface is always no user interface whenever
>> > it is possible for the machine to do it correctly by itself.
>>
>> I can't argue with that :-)
>
> I can! The problem with the machine doing it correctly by itself is
> that it almost inevitably has to make some default assumptions.

The key though is "almost". Some developers will take the trade-off and
make assumptions that they think will almost always work. That's fine as
long as there's a simple way to override the assumptions when they _don't_,
but is not what Les & I had agreed to. There are cases where such
assumptions can be correct. For instance, it's inherent in the design of
Ubuntu that the first user set up on the system has sudo access. Isn't it
much nicer that Ubuntu configures /etc/sudoers for us, than then asking us
to set it up ourselves (as if we even could...)?
--
derek


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-21-2008, 03:07 PM
Les Mikesell
 
Default

Chris G wrote:
> On Wed, May 21, 2008 at 11:12:38AM -0300, Derek Broughton wrote:
>> Les Mikesell wrote:
>>
>>> And the best user interface is always no user interface whenever
>>> it is possible for the machine to do it correctly by itself.
>> I can't argue with that :-)
>
> I can! The problem with the machine doing it correctly by itself is
> that it almost inevitably has to make some default assumptions.
> That's all very well if they're correct and it's all very lovely and
> nice but the odd case when they're wrong can be infinitely frustrating.

Yes, but this is the precise circumstance where you don't want a GUI
with the same wrong assumptions trying to force them on you.

--
Les Mikesell
lesmikesell@gmail.com

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-21-2008, 03:26 PM
Chris G
 
Default

On Wed, May 21, 2008 at 10:07:48AM -0500, Les Mikesell wrote:
> Chris G wrote:
> > On Wed, May 21, 2008 at 11:12:38AM -0300, Derek Broughton wrote:
> >> Les Mikesell wrote:
> >>
> >>> And the best user interface is always no user interface whenever
> >>> it is possible for the machine to do it correctly by itself.
> >> I can't argue with that :-)
> >
> > I can! The problem with the machine doing it correctly by itself is
> > that it almost inevitably has to make some default assumptions.
> > That's all very well if they're correct and it's all very lovely and
> > nice but the odd case when they're wrong can be infinitely frustrating.
>
> Yes, but this is the precise circumstance where you don't want a GUI
> with the same wrong assumptions trying to force them on you.
>
I see no basic difference between a GUI assuming something and a
CLI/editor configuration assuming something. Either can make a
(wrong) assumption, assume nothing at all and leave you to make the
setting yourself, or show you what it has assumed and allow you to
change it (this last is my preference).

--
Chris Green

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-21-2008, 03:29 PM
charlie derr
 
Default

Derek Broughton wrote:
> Florian Diesch wrote:
>
>> I just don't know *any* GUI config tools that supports this things.
>> And that's just the basics, with text file based configs you easily
>> get versioning, template or rule based generation, automatic
>> distribution, ...
>
> Nobody, at any point in this thread, has argued against "text file based
> configs". I've argued against editing them with a text editor

To be a bit more pedantic, I'd say that I have the impression you're arguing for (someday) not allowing others to be able to edit
config files with a text editor. Until there are truly bulletproof well-tested solutions in existence (and not just vaporware in
our dreams), I think most of us would disagree with that goal. Even after certain applications do have truly bulletproof
well-tested (I'm going to grant that this might be possible for some applications, though I'd think there vary well may be
applications/services that this would be extremely tough to do this for (and maybe not worth the effort)) solutions that exist, I
think many of us might still wish to be able to use a text editor to make our modifications (instead of using the GUI tool you're
proposing).


I also think that in some respects, calling this a "GUI" issue is somewhat misleading. As others have pointed out, having a way
to "test" or "verify" a specific config is really the holy grail here. Having this checking built into the interface (so that
it's impossible to even craft a config file with an invalid entry) doesn't really seem more valuable to me than a utility which
could be run against a config file and alert on invalid entries, syntax errors, etc... I actually think that looking at it this
wasy (as completely separate from the "GUI" part of your solution) would be a better way to proceed because then those of us who
truly abhor GUIs could still benefit from the work. But I'm not going to start coding anything like this, for at least 2 reasons:

1) I don't think that there's that much of a benefit. There's value in being able to edit text files and reading the
documentation describing the options for whatever software one is configuring. When it comes down to it, we're better off if the
folks who are administering important services have a greater breadth of knowledge (and understand the level of attention to
detail that is so important to being a good sysadmin).


2) It's really really hard for all but the simplest services/applications. Others have talked about the halting problem, and
while I'm not yet completely convinced that it would be impossible to create a solution such as you describe for some specific
software packages, I think that many of the specific services that have been mentioned (ssh, apache, ...) have such incredible
variation in how they're used in practice as to make this a very tough task.


But please don't let me talk anyone out of writing code that proves me wrong on either one (or both) of those points. I think
ubuntu would do very well to implement any of this functionality being discussed (even if it upsets some to talk about removing
the ability to configure services/applications using a text editor).


> - and you
> don't get _any_ of those benefits using vi.

Well maybe that's true, but with emacs, I get all kinds of benefits :-] (and I really really want to continue to be able to use it
to edit text files if I choose).

be well,
~c

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-21-2008, 03:37 PM
"James B. Byrne"
 
Default

On Tue, May 20, 2008 11:15, James B. Byrne wrote:
> This is the relevant part of the command:
>
> rsync -avz --rsh=ssh --delete-after /var/data/pas-redmine
> root@inet01.mississauga.harte-lyne.ca:/var/data
>
> The connection is made and a good deal of material is successfully
> transferred. I am however getting a number of permission errors:
>
> rsync: readlink "/var/data/pas-redmine/lib/tabular_form_builder.rb" failed:
> Permission denied (13)
> rsync: readlink "/var/data/pas-redmine/lib/redmine.rb" failed: Permission
> denied (13)
> rsync: readlink "/var/data/pas-redmine/lib/diff.rb" failed: Permission denied
> (13)
>
> and many more:


This indeed turned out to be an SELinux policy problem which I have since
resolved.

Thanks for the suggestions.

Sincerely,

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-21-2008, 04:17 PM
Les Mikesell
 
Default

Bart Silverstrim wrote:
>
>>>> But if you have that path in a text file, it becomes a cut/paste
>>> Are you talking about this operation being done in X? Because that would
>>> also technically be utilizing a GUI to assist in the administration :-)
>> Or screen, which is CLI. Or variables, which are programming.
>
> Somehow I knew those would come up. I do think that these access methods
> are used less today by newer administrators, though. X is maturing and
> hardware is advancing to the point where it's not such a novelty on the
> average home computer.

If X works and you have a mouse it is always nicer to use than console
mode - and you don't need to be on the same machine. I usually work
under the NX client with an X display from a different machine so I can
suspend it and grab it from another location with all programs still
running. And those programs generally include xterms ssh'd to a dozen
or more other machines.

>>> Or I put two windows side by side comparing items visually.
>> vimdiff, absolute godsend. I recently had an upgrade where the patch
>> files overwrote custom modifications by an admin long since gone. I was
>> facing digging through about 30-40Mb of JSP source, hundreds of files... and
>> did I mention I didn't know the language?
>
> Very handy. I'm not saying that the CLI should be eliminated or
> something can't be done with the CLI, I'm just saying that there are
> tasks that I find simpler in the GUI. Dealing with permissions under NT
> from the command line I find more difficult than using a graphical tool.

But it will probably do it wrong if you need exceptions to straight
recursions and it doesn't give you a handy way to remember a big list of
exceptions to apply again if you accidentally let a command recurse.

> Performing mass copies of directories while excluding particular names I
> find easier.

Rsync is great at this - and doesn't care if the copy is local or remote.

> Remembering obscure options I often find easier when the
> application can be very simple or very complex (like NMap).

Paste things into an editor and save them if you expect to need them again.

> <snip>Hogwash. It's
>> an easily learned UI. A good UI lets people do more as they /learn more/.
>> The CLI is not an easily learned UI but I could not trade the absolute raw
>> power it affords me.
>
> Intuitiveness is a part of a decent interface :-)

Consistency is more important in the long run. Intuitiveness only
matters on your first attempt.

>> After watching him for 3 minutes I was getting frustrated and said, "mind
>> if help you with that?" Got a copy on my machine, loaded it into vim:
>> :%s/.*(Ad+).*/copy image.jpg \1/g
>>
>> Is that easy UI? Hell no. Did it take me a while to learn a third
>> dialect of regex (Perl, Python, vim, in that order). Oh you bet it did. But
>> with 20 /seconds/ of work I saved him over an hour of "easy" UI grunt work.
>
> I knew you were going to cite this kind of example :-)
>
> I agree. You had an excellent fix to it. But it also still meant that
> investment you already conceded, the time to learn the other regex
> language.

Which, if you learned it 20 years ago, would probably have found a use
every day since that you used a computer.

> I would say that while you did have a great fix, the other
> (search and replace after a spreadsheet) was more convoluted but very
> understandable and simple in concept and less error prone from
> whoopsy-fingers on the keyboard.

The fun thing about regexp changes in vi is that if you get them wrong
you can hit 'u' and undo them.

>> But here's the real catch. Imagine if he had spent 1 hour learning the
>> "hard" and therefore "bad" UI. How much work would he have saved in him the
>> months prior and the months since?
>
> It would be handy. As long as he kept it polished in his memory. I have
> trouble remembering things like Cisco commands since I rarely use the
> routers. Make a mistake and it can have repercussions.

Cisco is about as helpful as it gets with command line/text configs.
Hit a ? and it gives a list of possible choices at that point,
abbreviations are accepted if they are enough to uniquely identify the
next word, and tab will do the completion for you. But the thing they
do that no one else gets right is that if you show a config it is listed
_exactly_ as you would type it back in, so you can cut/paste from a
working instances to the one you want to be similar. Or you can tftp
the whole configuration out to a text file, edit it, and tftp it back to
the same or a different router. Contrast that to what computers display
with 'ifconfig', route, etc. commands vs. what you have to input to
create that setup. So the issue isn't just cli vs. gui, it is good
design vs something that just happens to work. It's usually somewhat
easier to work around the bad designs in text mode, though.

> Sometimes I think that text gurus...not pointing fingers, I'm making a
> generalization from observations...have spent a lot of time and
> investment in learning their way around bash/cshsh/etc. and now they
> hold a more sophisticated version of 133tness, a badge of honor or a
> certification of a form of fraternal hazing that they feel allows them
> to look down on others who aren't whipping out Vi to solve every problem
> in system administration.

On the contrary. People that have found a skill to be useful over a
long term and in many situations are just likely to point out that
others could easily have the same benefits, especially when the tools
are free. Text isn't exactly exotic. We'd have a little trouble with
this conversation if you didn't know something about it.

> Because of this they will argue vehemently
> that anyone wanting to use an occasional GUI wizard is a mental
> defective not worthy of an entry in the sodoers file.

Learning to manipulate text is a generally useful skill, where learning
which tab to click to un-hide the option that some version of some
program needs to have changed this week isn't, unless that program turns
out to have an unusually long life.

--
Les Mikesell
lesmikesell@gmail.com

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-21-2008, 04:23 PM
"Steve Lamb"
 
Default

On Wed, May 21, 2008 7:48 am, Derek Broughton wrote:
> For instance, it's inherent in the design of
> Ubuntu that the first user set up on the system has sudo access. Isn't it
> much nicer that Ubuntu configures /etc/sudoers for us, than then asking us
> to set it up ourselves (as if we even could...)?

Nope. Because sudo certainly isn't needed on a single-user system. The
imposition of sudo on a single-user system is what requires the default
of the first user being injected into the sudoers file with ALL ALL
access.

Even worse on a multi-user system where one would want sudo chances are
the person who's installing the OS isn't going to be the only one you
want to give sudo access to. Therefore it'll have to be edited by
someone competent anyway.

So we have a default which is, on the one case, only needed because of a
bad choice and in the other case gets the default wrong. This is your
example?

--
Steve Lamb


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-21-2008, 04:39 PM
Mike Bird
 
Default

On Wed May 21 2008 07:26:02 Derek Broughton wrote:
> If I was cherry picking, I'd have picked something I knew better. Postfix
> was somebody else's suggestion.

Derek,

Please choose a commonly used application of similar
complexity to Apache or Postfix that you know well so
we can consider how your ideas fare in the real world.

--Mike Bird

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-21-2008, 04:39 PM
Mario Vukelic
 
Default

On Wed, 2008-05-21 at 11:11 -0300, Derek Broughton wrote:
> Then you remember distinctly wrong. I said that in an ideal world, editing
> config files would be impossible.

Ok. That was actually had in mind, I just wrote the wrong thing

So editing config files would be impossible. This still would suck

> I can't imagine a CLI implementation that
> would please users,

It's called text editor.

> but its the user of an editor I object to.

Well ... we already know that we disagree on this


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 

Thread Tools




All times are GMT. The time now is 11:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org