On Fri, 21 Jan 2011, M?ir?n Duffy wrote:
Hi David,
Thanks for all the feedback so quickly! I added a lot of your points and
corrections to the wiki version of the proposals.
No problem. Hope responding via email isn't too annoying. I would edit
things there, but today seems to be a day where I'm living in email.
I have some more questions for you below:
On Fri, 2011-01-21 at 21:43 +0000, David Cantrell wrote:
2. Very fast install time (due to use of dd?)
Internally it just uses the os.read() and os.write() Python functions.
8MB at a time.
Do you know why today's install DVD ends up being slower (45 min vs
10-20 min) the Desktop Live Media for the meat of the install? Are they
both using the same read/write functions, and it's just the DVD has a
bigger payload today than the desktop spin?
I really don't know. My guess is that it's just the size difference, like
you said.
6. Dangerous option for long-term use because persistence is still not
reliable and depending on the brand of USB key it may just die
unpredictably.
The other big limitation people point out is the forced filesystem
selection. Or is that still a problem?
I don't see it being an issue for novice users, who we try to optimize
for in the default install selection.
That's true. Novice users won't care. But there are more seasoned users
who pick up live install media somewhere (say a FUDCon) and try to do an
install to another fs type only to hit that limitation. That's something
we could fix up in anaconda, but have so far avoided because the long term
goal has been to make the live installation more flexible with regards to
fs choices than to put a bunch of special case handling code in anaconda
to eliminate fs selection when doing a live install.
5. Constrained / curated package set, no burden on the user to configure
too much up front
It would be possible to make the full installer behave this way too via
comps groups juggling.
This really becomes a matter of solidifying what we call the "Fedora" tree
vs. the Everything tree.
Is this an okay thing to do or is it going to be a pandora's box?
Any time we start talking about what is the base or core system, it's
pandora's box. I think this was part of the goal of the spins effort, so
anyone could go and define what they think the install media should be.
I don't think it's impossible and it really does come down to perception
and expectations on the user's side. I think it's possible to have a base
system defined and then a handful of install variants on top of that
(e.g., GNOME, KDE).
One thing we wanted to do in anaconda is eliminate the fine-grained
package selection in favor of a spin selector. The package selection is
mostly pointless because users go to great lengths to click and unclick
specific things and then we run yum across that set and it craps all over
the transaction set after resolving dependencies. People say "I unchecked
thing and it got installed anyway! Bad: Installer crashed!"
I think we should steer people away from thinking about things in terms of
packages because why should we care? Spins are far more appropriate and
really what most people want to think about. "I just want a system to
play music" or "I just want something that lets me hack on Haskell code".
No one really cares whether or not cadaver is an optional package or
required by something else. Well, people do now, but we should change
that perception.
If the spins effort is at risk of falling apart, we should work to prop
that up. "We" being FESCo or any of our other committees with power to do
so.
1. Live environment is confusing to novice users who don't understand
what's going on.
The full install environment is clearly its own world and there is no
confusion regarding the state of the system when it is fully running,
nor is there any temptation to start working on documents that you would
then lose if you weren't sure what was really going on.
IMHO, I think it's easier to provide instructions to a complete novice for
a limited environment (regular installer) vs. a live system. There are
far to many things a user can click on under the live image.
I absolutely agree 100%
4. Having to download both the ISO and a client to put the image on a
USB stick afterwards is a lot to download and hard to figure out for
novice users.
This would still be an issue, but there are other solutions to this
(e.g., offer the liveusb-creator as the default download.
LiveUSB-creator can download ISOs for you!)
anaconda could also be used for this functionality, though it would
require some better instructions and messaging for users. But as you
state above, you can use the regular installer to install to a USB
flashdrive. We provide a bootable self-contained system on a CD/DVD image
and it does the rest. The LiveUSB-creator requires another system already
installed and up and running, which some people may not have.
What do you mean here? Anaconda could be used to install to a USB stick,
but how are you running anaconda right? What are you running it off of?
Is it correct to assume you need two usb sticks, one with bootable
anaconda and one with the installed Fedora?
What I was thinking is the catch-22 case of users wanting install media
but only having one computer. The live image requires one of three
special tools to create it, which requires access to a computer that can
run one of those tools.
For the person with a single computer, say a modern laptop, they could
download just the install disc or get it from somewhere else, boot it, and
then install to a USB flashdrive rather than the hard disk in their
system. This gives them a way to try it out before committing the entire
system to it. It's also an environment we have more control over rather
than telling them to download a live image writing tool and run it on
_whatever they have on the system_.
If the user likes Fedora and wants to commit the whole system to it, they
can use the same installation media and perform a regular installation.
Or, if we do some work in anaconda, they could install directly from the
USB media they created.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Supervisor, Installer Engineering Team
Red Hat, Inc. | Honolulu, HI | UTC-10
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
