From: Stewart Honsberger <blkdeath@gentoo.org>
To: Luke-Jr <luke-jr@gentoo.org>
Cc: foser <foser@foser.dyn.warande.net>, gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Replacing fdisk with cfdisk in
Date: Thu, 21 Aug 2003 15:34:25 -0400 [thread overview]
Message-ID: <3F451EC1.80108@gentoo.org> (raw)
In-Reply-To: <200308211333.29393.luke-jr@gentoo.org>
Luke-Jr wrote:
> No, but tools should be obvious to the user when they can be without losing
> any functionality. Nano, for example, makes itself quite obvious how to use
> and is not, AFAIK, explained anywhere in the manual. cfdisk is obvious in the
> same way. As far as the manual goes, neither nano nor cfdisk lack any needed
> functionality.
I'm not saying Nano shouldn't be included by any means. As for cfdisk,
it's less standard (read: common) than fdisk, and questions have been
raised about its functionality.
I've repaird literally thousands of partition tables with fdisk (the
same one, if only prior versions going back several years that ships on
the Gentoo install CD) and never encountered a problem. Why not stick
with something that takes minutes to learn, is standard, and proven
reliable?
>>fdisk is a simple, standard, powerful partition table editor. I've used
>>Linux's fdisk to repair botched tables more times than I can count.
>>Instructions for use can be very simple.
>
> Instructions for fdisk can be simple, as opposed to not really needing
> instructions for cfdisk at all... I'm not saying exclude fdisk (it can't be
> that big), but there's no reason to use it by default (eg in the manual).
Including alternate tools for every part of the installation, especially
when including tools that are not industry / POSIX standard tools, is
contributing to bloat.
Here's an idea; what about having a standard set of tools on the minimal
install CD, and only including duplicate functionality / "user friendly"
tools, scripts, menus, and installation GUIs on the larger CD that comes
with Stage3? Why are newbie users installing from Stage1 if they can't
even use vi or fdisk anyways?
Perhaps one of those lines could include the notion of "Advanced
installation from the ground up" or "hand-holding from Stage3 with the
option of using Stage1 if you're so inclined".
>>The last patch of the slope is the Vi(M) discussion. "Vi is hard" seems
>>like a bit of a cop-out to me. Vi can be summed-up in half a dozen lines;
>>
1 - >>vi <filename> - Load file for editing
2 - >>/<keyword> - search
>>
3 - >>:w - Write file to disk
4 - >>:q - Quit
>>
5 - >>Commands can be combined, eg; :wq - Write file to disk and Quit
>>
>>Five lines and users have all the knowledge they need to create / edit
>>their base system files. A few more short lines and you can explain
>>(global) search/replace to give them more advanced functionality.
>
> I don't see anything in those *4* lines explaining how to enter data (eg 'i'
Five lines. A sixth could be added that reads along the lines of;
Press 'i' to enter insert / edit mode, press Esc to return to command mode.
(Word wrap notwithstanding)
> or 'a'), but like fdisk, vi would require explaining how to use it whereas
> nano is obvious, so it should be includes, but not in the manual.
That's my point - how much "obvious" stuff are we going to include in
the installation procedure of a self-proclaimed "advanced user"
distribution?
As for the installation manual, it should perhaps contian pointers to
instruct people how to reference the help / manual pages for these
respective applications. In fdisk, for example, the default prompt urges
you to press '?' for help. How much more obvious can it get?
>>I'm of the opinion that we have to set barriers; lines in the sand, if
>>you will. "This is how friendly we will become" and stick to those
>>boundaries. This would, of course, also help with the consistency issues
>>that are raised weekly on this list. ;>
>
> I agree we may need to keep the "idiot" and "real user" communities seperate,
> but there's no reason both cannot exist.
If we keep the entry bar high, we'll produce a more educated Linux user
community, and the forums, IRC channels and Bugzilla will be less
clogged with FAQs and inanities. (Read: Developer time better spent).
Gentoo is in a great position to teach users to work with standard
tools, rather than looking for the easy-out two-click brainless method
emplored by 'other' OSs and distributions. We can teach users to look
through documentation and search engines and try to answer their own
questions before they come looking for hand holding.
As I said before, this is a slippery slope. The more user-friendly you
make a tool, the more dumbed down people will want it. We're way behind
the likes of RedHat, Mandrake and SuSE in that regard and trying to
catch up would only put is in the league of so many other mediochre
distributions who've tried and failed.
If people want an idiot-proof install, I tell them to investigate
RedHat. I won't reccomend Gentoo to a person who can barely fudge their
way through a Windows installation because it's unfair to them and the
user community. People offering support in #Gentoo shouldn't have to
answer 50 daily "Where is my C: drive?" questions.
Beisdes that; if our installation procedure forces people to learn (and
more importantly; learn how to learn), we'll find ourselves with a swath
of qualified individuals from whom to select as new developers.
Right now the install.txt can be practically followed to the letter to
get a person up and running with a Gentoo system. I know; I've done it
myself; executed each command in sequence until eventually I was booted
to a login prompt and rearing to go. Consider how many people can't
understand this procedure and tell us on a daily basis how difficult
Gentoo is to install!
--
Stewart Honsberger
Gentoo Developer
http://www.snerk.org/
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2003-08-21 19:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-19 8:27 [gentoo-dev] Replacing fdisk with cfdisk in Svyatogor
2003-08-19 8:19 ` Jon Portnoy
2003-08-19 10:44 ` Camille Huot
2003-08-19 15:29 ` matt c
2003-08-19 16:11 ` Svyatogor
2003-08-19 16:18 ` foser
2003-08-20 1:16 ` Luke-Jr
2003-08-20 4:52 ` donnie berkholz
2003-08-20 8:02 ` Sven Vermeulen
2003-08-21 5:36 ` Stewart Honsberger
2003-08-21 5:54 ` Patrick Kursawe
2003-08-21 9:06 ` Sven Vermeulen
2003-08-21 13:33 ` Luke-Jr
2003-08-21 19:34 ` Stewart Honsberger [this message]
2003-08-22 14:12 ` foser
2003-08-19 18:34 ` Salze
2003-08-19 10:59 ` Lloyd D Budd
2003-08-22 19:57 ` Jason Wever
2003-08-22 22:20 ` Martin, Stephen
2003-08-22 22:25 ` Martin, Stephen
2003-08-23 3:46 ` Georgi Georgiev
2003-08-23 9:33 ` Sven Vermeulen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F451EC1.80108@gentoo.org \
--to=blkdeath@gentoo.org \
--cc=foser@foser.dyn.warande.net \
--cc=gentoo-dev@gentoo.org \
--cc=luke-jr@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox