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-20-2008, 07:40 PM
Mario Vukelic
 
Default

I just wanted to add to my previous reply that you probably simply
haven't had the chance to read the analyses and examples I mentioned at
the end. Too much going on in the thread I didn't mean to have write
with an unfriendly voice.


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-20-2008, 07:47 PM
Bart Silverstrim
 
Default

Dotan Cohen wrote:
> 2008/5/20 Bart Silverstrim <bsilver@chrononomicon.com>:
>> Mike Bird wrote:
>>
>>> And where do I type my big explanatory comment in your GUI?
>> Documentation kept separate of the server for reference and
>> configuration issues where it won't get accidentally obliterated by an
>> upgrade?
>>
>> Just a guess ;-)
>>
>
> It won't get read. That's why Python has the excellent
> self-documentation features.


If you're not careful you're going to start sounding like the argument
response is, "If it's not the way I like, it's wrong and just won't work
for me, period..."

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

Mario Vukelic wrote:

>> Configuration isn't difficult. It's tedious, and repetitive and prone to
>> mechanical error. It's the sort of thing that _should_ be left to
>> monkeys.
>
> Here you stop making sense. Come on ...

I didn't think so, but I'll try a different approach :-)

I help maintain a machine hosting about 6 or 7 different web servers, all
proxied by one Apache virtual host. They're all identical from a
configuration viewpoint, except for the actual internal URL, but every time
the actual administrator wants to create a new instance, he has to call me
to write the changes to the Apache config - and all _I_ do is copy and
paste the last line of the rewrite rules and then change the URLs. A
monkey could do it... and would cost a lot less than me.
--
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-20-2008, 07:52 PM
Mario Vukelic
 
Default

On Tue, 2008-05-20 at 15:35 -0400, Bart Silverstrim wrote:
> Interesting point, but to answer your question, if the system is broken
> and they needed the help desk to begin with, something is already
> impeding them.

But taking over their screen can easily impede them more.

> The NMAP front end?

I just looked at screenshots, and while I haven't used it, I think I can
say two things:

One, it is not a configuration editor as such - it controls several
independent applications. To make it work as an analogy to Derek's
proposal (GUI editor that prevents admin from making mistakes), you
would now have to require that Zenmap allows only combinations of
options and settings that achieve what the admin intended and don't
break anything.

Two, it does not even seem that complex to me. I submit xine's
preferences dialog in "Master of the known universe" mode as a more
appropriate example.

<snip>
> Maybe. It depends on the nature of the edits. Otherwise you couldn't
> have commented CPP code that can be opened in your favorite IDE/editor.

Hmm, interesting point, but something is wrong with it, i just can't put
my finger on it right now. I'm sure someone else will


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-20-2008, 07:53 PM
Bart Silverstrim
 
Default

Dotan Cohen wrote:

> As Dilbert once said, that approach is more applicable to stone
> carving than programming. With VI at least I do a quick "U:w" (that's
> undo-save for for mousemaids) if I screw something up.

Mousmaids? How about just English readers?

>> Truth is, GUI vs CLI has no one answer. It's horses for courses. There
>> are times one is better/quicker/safer/whatever than the other. There
>> are times the opposite is true. It depends what you are trying to
>> achieve.
>
> That's why it is argued that the GUI approach should compliment the
> CLI approach, not replace it.

Sounds reasonable.

>> And trying to achieve 100% correctness, or 0% errors ? Need to replace
>> humans with robots. Then you get lumbered with hardware failure
>> And what if the robots go mad ?
>>
>> [If you wonderful GUI tool trashes your config file, what do you do ?]
>
> Can you easily backup config files from the GUI? Somehow I doubt that you can.

Um...*can* you? Yes, if you're building the GUI interface. You can do it
with a menu option or a button marked BACKUP or even an obscure menu
option. If you didn't make the interface and it doesn't have that option
then no.



--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-20-2008, 08:01 PM
Avi Greenbury
 
Default

On Tue, 20 May 2008 14:59:57 -0300
Derek Broughton <news@pointerstop.ca> wrote:

> Avi Greenbury wrote:
>
> Why? That smacks of really poor programming in the first place. Computer
> programming is deterministic - whenever "X" happens, then "Y" (OK, not
> entirely true, as you can add randomness, but the whole purpose of config
> files is usually to enforce determinism). Any deterministic system can be
> completely modeled, and so there should, in theory, be _nothing_ that a
> power user would want to configure that can't be done with a config tool
> that would prevent him doing it incorrectly.
>

I have, intentionally, made incredibly insecure and inadvisable
configuration changes to various systems in the past, because the use
to which they were being put demanded this. Or, at very least,
requested it.
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.

I've left the disputing of the possibility of your GUI to others.

> > That's one way people stop being idiots - they break and they learn.
>
> 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.

The way people learn is they make mistakes, and learn from them. I only
know what I do because I've broken lots of things in the past. Without
that access to the core of how the system works (with options named as
what they do, not dressed up in novice-user-speak), I wouldn't have
learnt anything except 'don't click there'.

--
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-20-2008, 08:04 PM
Mario Vukelic
 
Default

On Tue, 2008-05-20 at 15:53 -0400, Bart Silverstrim wrote:
> If you didn't make the interface and it doesn't have that option
> then no.

I guess that exactly the problem here, being limited to whatever the GUI
designer thought you'd want to do.


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

Mario Vukelic wrote:

> On Tue, 2008-05-20 at 15:32 -0300, Derek Broughton wrote:

> Or maybe
> you make it look much simpler than it is by conflating nearly everything
> into "text".

Agreed. The point being that those other options _are_ simplistic.

> May I offer procmailrc as an example for something that
> would probably be impossible to implement with a GUI configurator that
> should also check that the file really does what the user intended:
> http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=procmailrc

Well, I'm not going to write the config tool right now (or probably ever - I
never liked procmail - though I was working on one for maildrop), but start
at the beginning - sooner or later every recipe has to deliver mail to a
file, pipe or program, or to another user. It's simple to check that the
file/pipe/program exists. Validating an email address is harder - do you
simply check that the format is good, or actually test SMTP? Neither one
is impossible, though. Now, I can conceive of a situation where I might
actually forward to an invalid SMTP address intentionally (expecting the
address to be created shortly) but then it's a matter of what procmail
would do with such an address when actually running - if procmail will
retry, it's just a warning, if procmail would drop it, it's an error.

> It's not so much about valid key=value pairs, it is about legitimate
> combinations of values.

The "If A then B" conditions. In your example, procmail already checks
those, so why can't a config tool for procmailrc do the same?
--
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-20-2008, 08:15 PM
Mario Vukelic
 
Default

On Tue, 2008-05-20 at 16:47 -0300, Derek Broughton wrote:
> I didn't think so, but I'll try a different approach :-)
>
> I help maintain a machine hosting about 6 or 7 different web servers, all
> proxied by one Apache virtual host. They're all identical from a
> configuration viewpoint, except for the actual internal URL, but every time
> the actual administrator wants to create a new instance, he has to call me
> to write the changes to the Apache config - and all _I_ do is copy and
> paste the last line of the rewrite rules and then change the URLs. A
> monkey could do it... and would cost a lot less than me.

We have been using a different definition of "configuration". To me,
configuration means the inital setup of the conf file, with its possibly
many, many options.

What you described here, I would have called "deployment" or maybe
"instantiation". And I agree, there is probably a high number of far
better methods to do this than the procedure you seem to use.

The funny thing is, however, that these methods are _only possible
because apache lets you hand-edit the config files (or rather, allows
you to machine-generate them). If your proposal were in place, you would
be out of luck if the designer of the GUI configurator had for some
reason not thought of your specific situation.


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

On Tue, 2008-05-20 at 17:08 -0300, Derek Broughton wrote:
> Well, I'm not going to write the config tool right now (or probably ever - I
> never liked procmail - though I was working on one for maildrop), but start
> at the beginning - sooner or later every recipe has to deliver mail to a
> file, pipe or program, or to another user. It's simple to check that the
> file/pipe/program exists. Validating an email address is harder - do you
> simply check that the format is good, or actually test SMTP? Neither one
> is impossible, though. Now, I can conceive of a situation where I might
> actually forward to an invalid SMTP address intentionally (expecting the
> address to be created shortly) but then it's a matter of what procmail
> would do with such an address when actually running - if procmail will
> retry, it's just a warning, if procmail would drop it, it's an error.


> The "If A then B" conditions. In your example, procmail already checks
> those, so why can't a config tool for procmailrc do the same?

Your analysis misses the most important point of procmail: correctness
of the filters.


--
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 09:27 AM.

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