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, 06:20 AM
"Cybe R. Wizard"
 
Default

Mario Vukelic <mario.vukelic@dantian.org> said:
> Yeah well, there are many other threads that are not exactly "Ubuntu
> user technical support". Come one, the guys who are discussing in this
> thread (e.g., Derek, Bart, Avi, Steve, Dotan, myself (sorry if I
> forgot anyone)) are among the most frequent contributors to the list,
> and may I say also among those who give the soundest advice.

Beware, this is /exactly/ what killed off the Libranet linux mailing
list. Next the frequent contributors will start thinking they should
have the ability to have political leanings in their .sigs!
Heavens, what next?

Cybe R. Wizard
--
Nice computers don't go down.
Larry Niven, Steven Barnes
"The Barsoom Project"

--
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, 01:34 PM
Bart Silverstrim
 
Default

Steve Lamb wrote:
> Bart Silverstrim wrote:
>> Les Mikesell 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.

>> 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.
Performing mass copies of directories while excluding particular names I
find easier. Remembering obscure options I often find easier when the
application can be very simple or very complex (like NMap).

>> Okay GUIs aren't easily scriptable. That doesn't mean they're
>> fundamentally flawed for other tasks any more than saying that the
>> command line doesn't easily let me browse hi-res photos.
>
> Agreed. But would you say that CLI's the _only_ way one should browse
> hi-res photos or would you concede that maybe a remotely displayed display
> (program name, not a double word there, honest) which is CLI might be useful?

Of course. I right now have three SSH sessions running to do a couple
file transfers and tars over multiple servers, along with this message
being sent by a remote X session of Thunderbird.

>> Preferences are. But there are other benchmarks that can be applied.
>> Usability studies and interface research aren't based on magic.
>
> They should be. KDE4 is absolutely abysmal when it comes to usability.

I've heard. I think programmers tend to worry more about scratching
their personal itches than making a product for general use across a
wider range of expertise. Everyone's building their own bikeshed.

<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 :-)

> A simple anecdote on the difference between easy and good. Notepad is
> easy, I don't think anyone would refute that. Good? Not a chance.

Good for what? I don't mind it for simple simple things. Just scratching
a note. Converting some text to simple plain text. Typing onto someone's
display when remotely operating someone's desktop. Not for novel
writing, though.

Depends on the task/goal.

>The prime
> example is the day when a coworker of mine was scripting something in batch
> (that's another story) to update the background image on 300+ machines. He
> had a list of machines, one per line, and was culling the cruft and prepending
> the copy command one at a time.

True, not fun when it gets to be a big list. I have seen a workaround
involving Excel and a save as then using a search and replace.

> 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. 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.

> 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.

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. 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.

--
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, 01:57 PM
Derek Broughton
 
Default

Les Mikesell wrote:

> Derek Broughton wrote:
>>
>>> What are the possible choices for RewriteRules or ProxyPass directives
>>> in an apache config? You can verify that server won't crash with some
>>> contents you choose but not that it will actually function correctly or
>>> at all. There are any number of configuration options where the entries
>>> are completely arbitrary.
>>
>> You can't verify it any more if you hand-edit the file either. So
>> there's
>> no advantage there using a text editor. However, if you really want to
>> to semantic validation too, this is a fine example - since I actually
>> have had to do this recently :-)
>>
>> I have an apache server that proxies a bunch of Plone servers. The
>> rewrite rules look like:
>>
>> RewriteRule ^/cmb(.*)
>> http://localhost:9080/VirtualHostBase/http/www.DOMAIN:80/cmb$1 [L,P]
>>
>> So the first thing I do after adding one of these is:
>> # wget http://localhost:9080/VirtualHostBase/http/www.DOMAIN:80/cmb/
>> # wget http://www.DOMAIN:80/cmb/
>>
>> The first verifies that the rewrite target is valid, and the second
>> verifies
>> that the source is valid. That would be easier to do in the config
>> tool...
>
> Except that (A) you'd have to write this mythical config tool first, (B)
> you'll find it impossible to describe in general how to construct the
> URL that tests your rule, and (C) the test target may not be ready or
> working at the time you want to add the rule.

True - but that's _exactly_ the situation if you're hand editing. You're
telling me that GUI tools don't work, but then providing examples where
they work _at least_ as well as hand editing.
--
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, 02:04 PM
Derek Broughton
 
Default

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.

>> 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.
--
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, 02:11 PM
Derek Broughton
 
Default

Mario Vukelic wrote:

> I remember distinctly that you wrote that in an ideal world, cli changes
> would be impossible and everything would have to be validated through a
> gui. (To which I replied that I want you to leave me out of your ideal
> world)

Then you remember distinctly wrong. I said that in an ideal world, editing
config files would be impossible. I've never objected outright to a CLI -
and now regret using the term GUI in the first place, as I really want
appropriate configuration tools. I can't imagine a CLI implementation that
would please users, but its the user of an editor I object to.
--
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, 02:12 PM
Derek Broughton
 
Default

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 :-)
--
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, 02:18 PM
Derek Broughton
 
Default

Mario Vukelic wrote:

>
> 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.

Why? There's a straightforward syntax that says that any virtual host can
have any number of rewrite rules, so the rewrite rule configuration would
simply allow for any number of iterations. If the designer didn't add
a "duplicate this" button, you could always just use the underlying
copy/paste of the GUI environment.
--
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, 02:24 PM
Chris G
 
Default

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.

--
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, 02:26 PM
Derek Broughton
 
Default

Les Mikesell wrote:

> Derek Broughton wrote:
>>
>> For instance, to configure postfix as
>> a smarthost, it needs to know your ISP's SMTP server name, port, and
>> authorization information. When you enter those into a config tool, it
>> can open a connection to the server and test it.
>
> First, remember that postscript

postfix - I know even less about postscript...

> was written specifically to be easy to
> configure so you are cherry-picking an example.

If I was cherry picking, I'd have picked something I knew better. Postfix
was somebody else's suggestion.

>> Why would I assume _it's_ wrong any
>> more than I would assume somebody screwed up the config in an editor?
>
> You haven't been doing this very long, have you? Wade through the bug
> history on a few large programs to catch up. It's a pretty safe
> assumption that every program has bugs and it's just as easy to make a
> mistake in program source as a config file.

Of course there are bugs (and yes, I've been doing this for 30 years). But
there's still a vastly smaller chance that there'd be a bug in a config
tool than that there'd be a mistake in a hand-edited file.

>> Sorry, that's an insane statement. If I am editing a config file with an
>> editor, it's up to me to make sure changes are checked into version
>> control.
>
> And that's a problem? Why?

It's not - but you said it couldn't be done in a config tool.
>
> Great, let me know when it's done. And when it will match my version
> control system.

Why would it have to? This is OSS - it would depend on the tools necessary
to do version control. If I wrote it, I'd probably use svn. If you liked
the tool, but not the version control, you'd modify it to handle your
preferred form of version control.

--
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, 02:30 PM
Derek Broughton
 
Default

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 - and you
don't get _any_ of those benefits using vi.
--
derek


--
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 04:36 AM.

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