Derek Broughton wrote:
Tom Allison wrote:
I guess this is really just a vent/rant but...
I am a current user of Debian.
I picked it from Slackware because I was in favor of a faster install
process than slackwares. Of course I had fewer questions in Slackware
because I was always RTMing. Debian makes it easier to not do that.
Hmmm. I can't see that. Do you mean just because we're all so nice and
helpful? Because it's hard to use Debian without _some_ source of
documentation.
Actually it's the reverse!
I can install so much more and so much faster than I can possibly read!
Bloat? I'm stunned.
OK, the term "Bloat" was incorrect. I would like to retract that
statement if it's at all possible. It isn't a matter of physical
bloat in MB consumption. On the other had, it can be made quite small
and is possible to do most things without any X.
This niche specialization may have won
arguements with Debian, but it's at a high price with respect to
interchangeable configurations. I may be able to fix something on
Debian, but not on any other distro.
Is this a common digression between the distros?
I'm not sure I understand you but I think you're disappointed that
Debian isn't Redhat, or SuSE, or Slackware. Which one do you think we
should slavishly imitate? :-)
It's not that simple. Debian has some really good stuff. But finding
out where things go can be really difficult. This difficulty, in my
experience, comes from a deviation from the very direct approach of
something like Slackware or even Sun Unix. All distros are making
these deviations in order to keep the configuration capability
manageable. We ask a lot of Linux these days.
But the deviation in Debian is hard to identify and track down. I'm
not always sure which is the best way to do or where to look. I used
to always look in /etc/*.conf for the settings, but they've moved into
/etc/defaults/*.conf.
This is news to me.
I think it's about Documentation and getting a clear message of
architecture (or philosophical) changes to the Debian set-up.
Documention of a more Systems Administration approach. Things like:
Where do I put my pcmcia ethernet card setting?
/etc/network/interfaces, or /etc/pcmcia/network.opts.
AND
"We are changing to a new abstraction layer of /etc/defaults so that
we can better ..."
Philosophy --
example: Slackware has all it's documentation right in the file you
need to edit. And if it isn't in there, they probably tell you were
to go. But it does all assume some functional knowledge of a basic
BSD style rc. format. Similarly, everything is in /etc/ with tons of
text in the files themselves.
example: Suse keeps everything, including the kitchen sink in one
really big file. Now you know where to start from.
example: Debian -- I'm still not entirely certain. But I am still
trying.
In all of these, and with Debian in general, I have found that the
documentation is really the key. Who cares if it isn't "The RedHat
Way". If that is so important then I suppose I should go with RedHat
and shut up.
But I really like Debian. It's a cool ideal.
But the documentation, if available, will accomodate so many
potentially uncomfortable problems.
example: I had one PC that would swear the only editor it has was
something called 'ae' and not 'vi'. Make 'crontab -e' a little
foreign to me. Someone, somewhere, mentioned that there is some
defaults controlling application for setting things like the default
editor and that fixed me up.
Until I got the message by word of mouth I had no clue as to what to
do. Changing EDITOR did nothing for me. I expected it to. It's a
common functionality between everything I've ever seen in Linux/Unix
(maybe my experience is still too limited?).
But today I have forgotten the name of this application and have
absolutely no clue how I would ever find it again. I am lost.
To treat this specific case, maybe just a list, in <dl> form of the
Administration Tool/Function, and a description of what it does would
help. Even 'whatis' would help. But I don't know what to type in
after that as the name of a configuration/administraction management
tool in Debian.
I can only say that imo it _must_ be a
common digression between distros. We all try to do things consistently
where possible, but surely it's more important to do things _right_ than
to be consistent with Redhat if Redhat does it wrong (which happens :-))
otoh, maybe I just don't understand what you mean by abstraction...
--
derek
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
