Re: How to install X-Chat in five hours (or more)
On Tue, 5 Aug 2003, Colin Watson wrote:
>>
>> The term "dselect" means nothing to me. It isn't a usable name. That's
>> another example of the problem I mentioned.
>
> Tools have names, and they don't really have to be generic. I think it's
> quite acceptable for the installation manual to tell you the names you
> need to know to get started, and it does: see sections 8.11 to 8.15 of
> <http://www.debian.org/releases/stable/installmanual>.
Ok, that's fair enough.
>> Note that, if for some reason the user knew about the command
>> "apropos", even that wouldn't help him -- none of dselect, aptitude,
>> and apt-get come up for "apropos install" or "apropos setup".
>
> They all show up for 'apropos package', along with a bunch of other
> stuff, but yes, that would probably be a useful enhancement to at least
> one of those man pages.
I'm glad you agree. :-)
> However, it's better for a command-line tool to be verbose up-front,
> because if it crashes or blows up or just goes slightly wrong, at least
> the last of which is frequent with buggy packages, we need the
> information for bug reports [...].
That's probably true. It would still be nice if the verbose messages were
more consistent, though. For example, 'apt-get' error messages start with
'E:' instead of the more standard 'apt-get:'. Similarly, when you do an
apt-get update, you get some messages of the form:
Hit ftp://apt sid/mail Packages
...some of the form:
Get:1 ftp://apt ./ Packages
...and some of the form:
Reading Package Lists... Done
...which is odd: why three different kinds of messages? What does "Hit"
mean, as opposed to "Ign" or "Get:1"? And so on.
This isn't only a problem with apt-get, of course. Error and status
messages throughout the industry and in particular throught the free
software world are often obscure, obtuse, and unclear. Indeed, Mozilla has
its share of such problems! :-)
> With a graphical front-end it's much easier to hide the verbosity and
> have a "show me the installation log" option in case of error. I've seen
> graphical front-ends for the Debian package management system that do
> exactly this.
That's cool. (aptitude doesn't, as far as I can tell.)
> :-) Fundamentally, we're trying to produce the best, most stable, most
> reliable, etc. system we can, not get as many users as we can.
That's fair enough! :-)
> That's not to say that the goal is user-hostility, just that
> user-friendliness isn't always the all-defeating trump card when
> discussing relatively low-level tools like dpkg and apt-get.
I think that user-friendliness, even at such a low level, should still be
important -- just because the user is an expert doesn't mean he wants to
have to decode messages.
>> although "var" is a historical name that really should be replaced by
>> something more user friendly, but that's another story.
>
> You can't get there from here, I think. Unix admins coming to Debian
> will scream blue murder if it starts being "/My Variable Data/Logs", and
> that group is important to us.
Note that there is at least one project which is looking at doing exactly
that while retaining backwards compatability (GoboLinux). It may be worth,
on the long term, looking at how it may be possible to migrate from
obscure paths like "/opt", "/bin", "/sbin", "/usr/bin", etc, to more
sensible names, in that way.
And I would scream if you called it "/_My_ Variable Data/" too... :-P
--
Ian Hickson )\._.,--....,'``. fL
"meow" /, _.. \ _\ ;`._ ,.
http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Reply to: