Hi,
After some discussion in #anaconda earlier this week I put together a proposal for using a full anaconda environment as the default installation method for Fedora rather than the current live installation environment. Before I sent this to fedora-devel (which I'm admittedly terrified of) I was hoping you folks might be willing to look over it below and sanity-check it for me?
The next step I think is maybe to have some discussion on fedora-devel and propose it to FESCo.
I really appreciate any feedback!
Thanks, ~m
---
PROPOSAL: Use full installer environment as default Fedora install method
Currently (and since ~Fedora 12) the default media promoted for installation of Fedora both via our website at fedoraproject.org and at conferences and other events is the Desktop Live Media ISO, delivered via pressed optical media at events, and typically delivered via home-burned optical media or live usb media created via dd, livecd-creator on the command line, or the Live USB Creator GUI (the latter the most popular for non-Linux systems.)
Live Media affords some clear advantages over traditional installers, primarily in its ability to be used via USB sticks as optical drives are less ubiquitous in laptops and its singularity as one image you can try-before-you-buy to test out drivers, rescue machines, and use as a full installer. It also affords a gee-whiz factor.
However, there are some serious concerns about the stability and overall user experience in promoting live media as the primary installation method of Fedora. There is also a larger concern about the future direction and maintenance of the spins project. Creating and maintaining usable live media is not a trivial task and many of our spins maintainers have understandably burnt out. Reconsidering how we deliver installation of Fedora to our end users may offer an opportunity to help this situation.
First we'll walk through the advantages and disadvantages of live media, then we'll specifically address how switching to a full install environment affects each point and try to assess via discussion whether or not this is a proposal worth considering.
= Advantages of Live Media: = =============================
1. Try-before-you buy - not sure if Fedora will work with your video card or other hardware? You can easily pop it in and test it out without the trouble of a full install.
2. Very fast install time (due to use of dd?)
3. Convenient transition from trying to buying
4. Only one image to download for try, install, and rescue
5. Constrained / curated package set, no burden on the user to configure too much up front
6. Live environment means it's easier to take screenshots of crashes and look up helpful information on line to assist with installation
7. Viable long-term solution for those with computer access but no administrative control (e.g., children with access to school & library computer labs) to provide access to free software (if persistence worked well)
8. It works off of USB, which is good for the many laptops and slim towers today that come without optical drives.
= Disadvantages of Live Media: = ================================
1. Live environment is confusing to novice users who don't understand what's going on. They may not realize the environment is on the USB stick, and pull it out while it's running losing data (I have witnessed this multiple times.) They also may think their system is 'installed' when it's not, go about their work, and then lose it on reboot.)
2. Live environment means it's possible to put the system into a state that anaconda won't know how to deal with it and install-to-disk will fail ("a system that actively encourages you to go screw around with things until anaconda can no longer trust how things are set up")
3. Getting it onto the USB stick is non-trivial. There are three ways to do it (dd, liveusb-creator command line, liveusb-creator UI) and no single clear path is promoted.
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.
5. Requires use of isohybrid which means media can't boot on Macs without bootcamp
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.
= Can the full installer provide the advantages of Live Media? = =================================================================
Let's walk through the advantages of live media and see if the full installer can also provide them:
1. Try-before-you-buy
While it's not advertised or often talked about, you can use the anaconda UI to install Fedora to a USB key or external hard drive to try before you buy.
2. Very fast install time
When I installed Fedora 14 via DVD, it took: ‣ 1.5 hours (mostly idle) to download the ISO ‣ 10 minutes to burn the ISO to a DVD and set the computer to burn to DVD ‣ 45 minutes from starting the install to booting into a running desktop
When I installed Fedora 14 via LiveMedia, it took: ‣ > 2 active hours and pain to get it downloaded and onto a USB stick ‣ 10-15 minutes for the meat of the install process, but varies based on drive type (that was an SSD) ‣ Total elapsed install time after that, including media check, was 45 minutes.
3. Convenient transition from trying to buying
It would be a little less convenient. You would need two USB keys - one for your 'trial' installation of Fedora, the other for the full installer - which you'd use both to create your 'trial' install and your real install-to-hard-disk install. You couldn't click a button from the running 'trial' USB install to install to disk - you'd have to reboot using the installer USB key.
4. Only one image to download for try, install, and rescue
You only need to download one ISO with the DVD as well for try & install. I'm not sure about rescue. Can the full installer media be used as a rescue disk or would we need an additional image for this?
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.
6. Live environment means it's easier to take screenshots of crashes and look up helpful information on line to assist with installation
This is definitely harder to do in the full installer, but you could always use a camera to take screenshots. There isn't a lot of evidence to indicate that users actually take advantage of the live install environment to look up documentation. Anaconda used to have a documentation pane and it was removed because it simply wasn't being used. Note that some developers told me they like the live environment because they can debug anaconda while it's running and get it working again without a reboot. Definitely a narrow edge-case, though.
7. Viable long-term solution for those with computer access but no administrative control...
You can use anaconda to install directly to a USB key. How easy this is to produce live USB keys en masse, I'm not sure.
8. It works off of USB, which is good for the many laptops and slim towers today that come without optical drives.
With some modifications LiveUSB-creator could make a bootable full install environment on a USB key.
= Can the full installer improve the disadvantages of Live Media? = ===================================================================
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.
2.Live environment means it's possible to put the system into a state that anaconda won't know how to deal with it.
The full install environment is far more stable and reliable and would likely result in a better overall success rate for users.
3. Getting it onto the USB stick is non-trivial. There are three ways to do it (dd, liveusb-creator command line, liveusb-creator UI) and no single clear path is promoted.
Since this would be a new delivery method for Fedora, we have the opportunity to develop clear & consistent messaging for it.
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!)
5. Requires use of isohybrid which means media can't boot on Macs without bootcamp
We would still need isohybrid to run anaconda off of a USB stick unfortunately.
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.
Data persistence would NOT be an issue with an anaconda-installed USB stick since it's not a live environment.
= Summary = ===========
In summary, we could say that moving to the full installer would have the potential disadvantages:
• Require a modification of liveusb-creator to support the creation of bootable usb media for the full installer
• Might possibly require a separate rescue image
• Not require much more time for installation if you start out media-less (the website use-case), but would require more time if you are handed a disc or USB key (the conference / LUG / office case).
• Require a minor inconvenience - users will need to reboot to install fully while trying out Fedora off of the bootable Fedora USB stick.
• Make it a little bit harder to take screenshots and debug the installation process when it fails.
It would bring several compelling advantages:
• Anaconda-installed Bootable USB media are going to be more reliable and pose less risk to user data and thus less risk to the impact of outreach efforts such as the Girl Scouts program we recently engaged in.
• Bootable USB media for Fedora may be easier to create as well as the installer is a single robust method and the same method used for real computer installations.
• There will be less confusion about the state of the computer when full anaconda is running.
• Less temptation for users to create documents / bookmarks / conversations / other media that will be lost post-install.
• The opportunity to present a single, clear and consistent path to getting the bootable installer onto a USB stick.
• No live environment means no opportunity for changing the state of the system in unpredictable ways, causing difficult-to-impossible-to-debug crashes in installations.
Suggested Path to Getting There
• Modify comps-groups / anaconda appropriately to provide a sane, curated default package set via the full installer. ∘ Consult with desktop SIG on this
• Modify the website: ∘ to provide links to the full installer by default ∘ Or (even better) modify the website to provide links to liveUSB creator (link may change based on sniffed OS, offer Win / OS X links to the creator as well) ∘ (if needed) Add links to rescue media
• Modify liveusb-creator: ∘ streamline live USB creator to make it clear how to download the appropriate ISO ∘ Usability review & redesign for Live USB creator to optimize for new use cases: ‣ create bootable anaconda ‣ create bootable Fedora or install Fedora to disk ∘ Modify liveusb-creator to support the creation of bootable usb media for the installer ∘ Modify liveusb-creator to support OS X
• If additional rescue media images are needed, the creation of these added to the release engineering processes
• Modify docs to clearly outline new installation steps
• Development of docs / website tutorials to outline the new try-before-you-buy USB creation process
• Spins.fedoraproject.org and spins in general.... :( I don't know. Replaced with comps groups?
Open Questions
• Is separate rescue media necessary if we opt for full installer? • What happens to spins.fedoraproject.org? • What happens to spins in general • Is the LiveUSB-creator work required to make this happen feasible? Is it something we can put more effort behind?
On Fri, 2011-01-21 at 19:25 +0000, MáirÃn Duffy wrote:
After some discussion in #anaconda earlier this week I put together a proposal for using a full anaconda environment as the default installation method for Fedora rather than the current live installation environment. Before I sent this to fedora-devel (which I'm admittedly terrified of) I was hoping you folks might be willing to look over it below and sanity-check it for me?
The next step I think is maybe to have some discussion on fedora-devel and propose it to FESCo.
I really appreciate any feedback!
In case it's easier to read:
https://fedoraproject.org/wiki/User:Duffy/Default_Install_Proposal
~m
On 01/21/2011 11:51 AM, Máirín Duffy wrote:
On Fri, 2011-01-21 at 19:25 +0000, MáirÃn Duffy wrote:
After some discussion in #anaconda earlier this week I put together a proposal for using a full anaconda environment as the default installation method for Fedora rather than the current live installation environment. Before I sent this to fedora-devel (which I'm admittedly terrified of) I was hoping you folks might be willing to look over it below and sanity-check it for me?
The next step I think is maybe to have some discussion on fedora-devel and propose it to FESCo.
I really appreciate any feedback!
In case it's easier to read:
https://fedoraproject.org/wiki/User:Duffy/Default_Install_Proposal
One additional point that should be made in favor of shifting back to a more "normal" install process (using the full anaconda environment) is that doing a network install form a Live CD is basically impossible, mostly due to the lack of ability to boot a Live CD over the internet.
Just my $0.02 however.
- John 'Warthog9' Hawley
On Fri, 2011-01-21 at 21:04 +0000, J.H. wrote:
On 01/21/2011 11:51 AM, Máirín Duffy wrote:
https://fedoraproject.org/wiki/User:Duffy/Default_Install_Proposal
One additional point that should be made in favor of shifting back to a more "normal" install process (using the full anaconda environment) is that doing a network install form a Live CD is basically impossible, mostly due to the lack of ability to boot a Live CD over the internet.
Just my $0.02 however.
That's a really great point! It also reminded me that you can add additional repos, which isn't possible in live media. I added these two points under advantages here:
https://fedoraproject.org/wiki/User:Duffy/Default_Install_Proposal#Advantage...
Thanks!!
~m
On 01/21/2011 01:28 PM, Máirín Duffy wrote:
On Fri, 2011-01-21 at 21:04 +0000, J.H. wrote:
On 01/21/2011 11:51 AM, Máirín Duffy wrote:
https://fedoraproject.org/wiki/User:Duffy/Default_Install_Proposal
One additional point that should be made in favor of shifting back to a more "normal" install process (using the full anaconda environment) is that doing a network install form a Live CD is basically impossible, mostly due to the lack of ability to boot a Live CD over the internet.
Just my $0.02 however.
That's a really great point! It also reminded me that you can add additional repos, which isn't possible in live media. I added these two points under advantages here:
https://fedoraproject.org/wiki/User:Duffy/Default_Install_Proposal#Advantage...
Well let me rephrase my previous "basically impossible" it's possible, and I've been trying to figure out who's in charge of the live cd's so it can be enabled by default, but it's currently not there and thus impossible.
Just saying, I manually set it up, mostly, for boot.kernel.org.
But yes, both are very good points regardless.
- John 'Warthog9' Hawley
On Fri, 21 Jan 2011, M?ir?n Duffy wrote:
Hi,
After some discussion in #anaconda earlier this week I put together a proposal for using a full anaconda environment as the default installation method for Fedora rather than the current live installation environment. Before I sent this to fedora-devel (which I'm admittedly terrified of) I was hoping you folks might be willing to look over it below and sanity-check it for me?
The next step I think is maybe to have some discussion on fedora-devel and propose it to FESCo.
I really appreciate any feedback!
Thanks, ~m
PROPOSAL: Use full installer environment as default Fedora install method
Currently (and since ~Fedora 12) the default media promoted for installation of Fedora both via our website at fedoraproject.org and at conferences and other events is the Desktop Live Media ISO, delivered via pressed optical media at events, and typically delivered via home-burned optical media or live usb media created via dd, livecd-creator on the command line, or the Live USB Creator GUI (the latter the most popular for non-Linux systems.)
Live Media affords some clear advantages over traditional installers, primarily in its ability to be used via USB sticks as optical drives are less ubiquitous in laptops and its singularity as one image you can try-before-you-buy to test out drivers, rescue machines, and use as a full installer. It also affords a gee-whiz factor.
However, there are some serious concerns about the stability and overall user experience in promoting live media as the primary installation method of Fedora. There is also a larger concern about the future direction and maintenance of the spins project. Creating and maintaining usable live media is not a trivial task and many of our spins maintainers have understandably burnt out. Reconsidering how we deliver installation of Fedora to our end users may offer an opportunity to help this situation.
First we'll walk through the advantages and disadvantages of live media, then we'll specifically address how switching to a full install environment affects each point and try to assess via discussion whether or not this is a proposal worth considering.
= Advantages of Live Media: =
- Try-before-you buy - not sure if Fedora will work with your video
card or other hardware? You can easily pop it in and test it out without the trouble of a full install.
To me, this is the best advantage of the live media.
- 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.
Convenient transition from trying to buying
Only one image to download for try, install, and rescue
Constrained / curated package set, no burden on the user to configure
too much up front
- Live environment means it's easier to take screenshots of crashes and
look up helpful information on line to assist with installation
- Viable long-term solution for those with computer access but no
administrative control (e.g., children with access to school & library computer labs) to provide access to free software (if persistence worked well)
- It works off of USB, which is good for the many laptops and slim
towers today that come without optical drives.
= Disadvantages of Live Media: =
- Live environment is confusing to novice users who don't understand
what's going on. They may not realize the environment is on the USB stick, and pull it out while it's running losing data (I have witnessed this multiple times.) They also may think their system is 'installed' when it's not, go about their work, and then lose it on reboot.)
- Live environment means it's possible to put the system into a state
that anaconda won't know how to deal with it and install-to-disk will fail ("a system that actively encourages you to go screw around with things until anaconda can no longer trust how things are set up")
- Getting it onto the USB stick is non-trivial. There are three ways to
do it (dd, liveusb-creator command line, liveusb-creator UI) and no single clear path is promoted.
- 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.
- Requires use of isohybrid which means media can't boot on Macs
without bootcamp
- 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?
= Can the full installer provide the advantages of Live Media? =
Let's walk through the advantages of live media and see if the full installer can also provide them:
- Try-before-you-buy
While it's not advertised or often talked about, you can use the anaconda UI to install Fedora to a USB key or external hard drive to try before you buy.
- Very fast install time
When I installed Fedora 14 via DVD, it took: ? 1.5 hours (mostly idle) to download the ISO ? 10 minutes to burn the ISO to a DVD and set the computer to burn to DVD ? 45 minutes from starting the install to booting into a running desktop
When I installed Fedora 14 via LiveMedia, it took: ? > 2 active hours and pain to get it downloaded and onto a USB stick ? 10-15 minutes for the meat of the install process, but varies based on drive type (that was an SSD) ? Total elapsed install time after that, including media check, was 45 minutes.
- Convenient transition from trying to buying
It would be a little less convenient. You would need two USB keys - one for your 'trial' installation of Fedora, the other for the full installer - which you'd use both to create your 'trial' install and your real install-to-hard-disk install. You couldn't click a button from the running 'trial' USB install to install to disk - you'd have to reboot using the installer USB key.
- Only one image to download for try, install, and rescue
You only need to download one ISO with the DVD as well for try & install. I'm not sure about rescue. Can the full installer media be used as a rescue disk or would we need an additional image for this?
Yes, rescue is the same. Just pass "rescue" as a boot option.
- 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.
- Live environment means it's easier to take screenshots of crashes and
look up helpful information on line to assist with installation
This is definitely harder to do in the full installer, but you could always use a camera to take screenshots. There isn't a lot of evidence to indicate that users actually take advantage of the live install environment to look up documentation. Anaconda used to have a documentation pane and it was removed because it simply wasn't being used. Note that some developers told me they like the live environment because they can debug anaconda while it's running and get it working again without a reboot. Definitely a narrow edge-case, though.
You can do this in the regular installer. Hit PrintScreen and you'll get a PNG of the current screen in root's home directory on the target system, /root/anaconda-screenshots. If you don't complete installation, you can still get to the screenshots via tty2 in /tmp/anaconda-screenshots.
If you are doing a kickstart install, you can add "autoscreenshot" to the ks file and anaconda will take a screenshot of each screen it comes to and place them in the above directories.
- Viable long-term solution for those with computer access but no
administrative control...
You can use anaconda to install directly to a USB key. How easy this is to produce live USB keys en masse, I'm not sure.
- It works off of USB, which is good for the many laptops and slim
towers today that come without optical drives.
With some modifications LiveUSB-creator could make a bootable full install environment on a USB key.
= Can the full installer improve the disadvantages of Live Media? =
- 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.
2.Live environment means it's possible to put the system into a state that anaconda won't know how to deal with it.
The full install environment is far more stable and reliable and would likely result in a better overall success rate for users.
- Getting it onto the USB stick is non-trivial. There are three ways to
do it (dd, liveusb-creator command line, liveusb-creator UI) and no single clear path is promoted.
Since this would be a new delivery method for Fedora, we have the opportunity to develop clear & consistent messaging for it.
- 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.
- Requires use of isohybrid which means media can't boot on Macs
without bootcamp
We would still need isohybrid to run anaconda off of a USB stick unfortunately.
- 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.
Data persistence would NOT be an issue with an anaconda-installed USB stick since it's not a live environment.
= Summary =
In summary, we could say that moving to the full installer would have the potential disadvantages:
? Require a modification of liveusb-creator to support the creation of bootable usb media for the full installer
? Might possibly require a separate rescue image
? Not require much more time for installation if you start out media-less (the website use-case), but would require more time if you are handed a disc or USB key (the conference / LUG / office case).
? Require a minor inconvenience - users will need to reboot to install fully while trying out Fedora off of the bootable Fedora USB stick.
? Make it a little bit harder to take screenshots and debug the installation process when it fails.
It would bring several compelling advantages:
? Anaconda-installed Bootable USB media are going to be more reliable and pose less risk to user data and thus less risk to the impact of outreach efforts such as the Girl Scouts program we recently engaged in.
? Bootable USB media for Fedora may be easier to create as well as the installer is a single robust method and the same method used for real computer installations.
? There will be less confusion about the state of the computer when full anaconda is running.
? Less temptation for users to create documents / bookmarks / conversations / other media that will be lost post-install.
? The opportunity to present a single, clear and consistent path to getting the bootable installer onto a USB stick.
? No live environment means no opportunity for changing the state of the system in unpredictable ways, causing difficult-to-impossible-to-debug crashes in installations.
Suggested Path to Getting There
? Modify comps-groups / anaconda appropriately to provide a sane, curated default package set via the full installer. ? Consult with desktop SIG on this
? Modify the website: ? to provide links to the full installer by default ? Or (even better) modify the website to provide links to liveUSB creator (link may change based on sniffed OS, offer Win / OS X links to the creator as well) ? (if needed) Add links to rescue media
? Modify liveusb-creator: ? streamline live USB creator to make it clear how to download the appropriate ISO ? Usability review & redesign for Live USB creator to optimize for new use cases: ? create bootable anaconda ? create bootable Fedora or install Fedora to disk ? Modify liveusb-creator to support the creation of bootable usb media for the installer ? Modify liveusb-creator to support OS X
? If additional rescue media images are needed, the creation of these added to the release engineering processes
? Modify docs to clearly outline new installation steps
? Development of docs / website tutorials to outline the new try-before-you-buy USB creation process
? Spins.fedoraproject.org and spins in general.... :( I don't know. Replaced with comps groups?
Open Questions
? Is separate rescue media necessary if we opt for full installer?
No.
? What happens to spins.fedoraproject.org? ? What happens to spins in general ? Is the LiveUSB-creator work required to make this happen feasible? Is it something we can put more effort behind?
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.
I have some more questions for you below:
On Fri, 2011-01-21 at 21:43 +0000, David Cantrell wrote:
- 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?
- 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.
- 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?
- 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%
- 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?
~m
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:
- 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.
- 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.
- 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.
- 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%
- 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@redhat.com) said:
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.
The non-live installer unpacks RPMs to the filesystem, introducing multiple layers of indirection that isn't there on the live install which is just blasting the filesystem image to the device as fast as possible. Enhancing RPM to be as fast as writing a filesystem image I believe falls far beyond the scope of this initiative.
- 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).
It would require not insiginficant changes to comps. For example, we offer 'Sound and Video' as a group checkbox. There's no good way to make this checkbox do a reasonably sane thing depending on which of the other checkboxes you checked (did you check GNOME? KDE? No desktop at all?)
This is a big advantage of the live media; it's not just curated for the default offering, but gives a good method for any use case to design for its offering.
Stepping back for a sec, a lot of this would go back to actually designating what the non-Live media is for. We've *never* done that, leading to it essentially just being 'a set reasonably comparable to what was on the old Red Hat Linux CD/DVD.' I don't see how something with that mantra helps with our usage cases/target audience, regardless of technical benefits.
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_.
One minor issue here is referring to the install disc; I have three 'modern' laptops in my household, and *none* of them came with optical drives. Obviously, the plural of anecdote is not data, but I think it's a case we need to have a good answer for, even if it's no better than the current case for live images where you need some additional tool.
Bill
On Mon, 2011-01-24 at 17:13 +0000, Bill Nottingham wrote:
It would require not insiginficant changes to comps. For example, we offer 'Sound and Video' as a group checkbox. There's no good way to make this checkbox do a reasonably sane thing depending on which of the other checkboxes you checked (did you check GNOME? KDE? No desktop at all?)
I'm kind of thinking, drop those checkboxes. You get the equivalent of the desktop live cd (the default offering) if you just click next next next. Instead of having the package group selection screen (http://docs.fedoraproject.org/en-US/Fedora/13/html-single/Installation_Quick... ) you can select different 'add-on packs'. They would all assume a GNOME installation. Other desktops could be installed, but as 'add ons.'
(please direct death threats to spamtrap@linuxgrrl.com)
This is a big advantage of the live media; it's not just curated for the default offering, but gives a good method for any use case to design for its offering.
This is also a huge problem with the live media.... it proliferates the limiting notion that Fedora is a bucket o' packages rather than a platform to build upon.
Stepping back for a sec, a lot of this would go back to actually designating what the non-Live media is for. We've *never* done that, leading to it essentially just being 'a set reasonably comparable to what was on the old Red Hat Linux CD/DVD.' I don't see how something with that mantra helps with our usage cases/target audience, regardless of technical benefits.
Which do you mean? The mantra that designating what non-live media is for doesn't help, or the mantra that the DVD is comparable to ye olde RHL doesn't help?
One minor issue here is referring to the install disc; I have three 'modern' laptops in my household, and *none* of them came with optical drives. Obviously, the plural of anecdote is not data, but I think it's a case we need to have a good answer for, even if it's no better than the current case for live images where you need some additional tool.
Absolutely. I'm in the same boat - my laptop has no optical drive.
~m
On Mon, 2011-01-24 at 21:49 +0000, MáirÃn Duffy wrote:
On Mon, 2011-01-24 at 17:13 +0000, Bill Nottingham wrote:
It would require not insiginficant changes to comps. For example, we offer 'Sound and Video' as a group checkbox. There's no good way to make this checkbox do a reasonably sane thing depending on which of the other checkboxes you checked (did you check GNOME? KDE? No desktop at all?)
I'm kind of thinking, drop those checkboxes. You get the equivalent of the desktop live cd (the default offering) if you just click next next next. Instead of having the package group selection screen (http://docs.fedoraproject.org/en-US/Fedora/13/html-single/Installation_Quick... ) you can select different 'add-on packs'. They would all assume a GNOME installation. Other desktops could be installed, but as 'add ons.'
Like this
http://farm6.static.flickr.com/5218/5385215221_73496245a9_b.jpg
~m
Máirín Duffy (duffy@fedoraproject.org) said:
It would require not insiginficant changes to comps. For example, we offer 'Sound and Video' as a group checkbox. There's no good way to make this checkbox do a reasonably sane thing depending on which of the other checkboxes you checked (did you check GNOME? KDE? No desktop at all?)
I'm kind of thinking, drop those checkboxes. You get the equivalent of the desktop live cd (the default offering) if you just click next next next. Instead of having the package group selection screen (http://docs.fedoraproject.org/en-US/Fedora/13/html-single/Installation_Quick... ) you can select different 'add-on packs'. They would all assume a GNOME installation. Other desktops could be installed, but as 'add ons.'
My engineering mind immediately goes to 'how would we implement this in terms of the existing infrastructure of the comps file, kickstart files, etc.', and is somewhat confused. We could have a lot of new groups, I guess, that are structured in this way, but it means a lot of random packages would no longer be selectable via tha UI. This could be both good and bad.
Another idea would be to make all the groups we have either much more general (the desktop group would include its sound apps, the KDE group would include its sound apps, and we could drop the general group), or much more focused (specific task groups, like 'office-suite', or 'imap server', or similar). We could then build up logical installation classes or installation profiles that consist of combinations of these. (This is what another product does, of course.)
This is a big advantage of the live media; it's not just curated for the default offering, but gives a good method for any use case to design for its offering.
This is also a huge problem with the live media.... it proliferates the limiting notion that Fedora is a bucket o' packages rather than a platform to build upon.
Hm. Maybe it's me, but I think the current incarnation of the non-live media (need a better nomenclature) reinforces this even worse, actually giving the user a pile of options to select & deselect and break themselves with. At least with the various live media, we get something that theoretically has been curated and tested as a unit.
Stepping back for a sec, a lot of this would go back to actually designating what the non-Live media is for. We've *never* done that, leading to it essentially just being 'a set reasonably comparable to what was on the old Red Hat Linux CD/DVD.' I don't see how something with that mantra helps with our usage cases/target audience, regardless of technical benefits.
Which do you mean? The mantra that designating what non-live media is for doesn't help, or the mantra that the DVD is comparable to ye olde RHL doesn't help?
The latter. The non-live media has never had a real target other than the bucket'o'packages idea, and therefore isn't really designed for anything specific.
Bill
Hi Bill,
On Mon, 2011-01-24 at 22:29 +0000, Bill Nottingham wrote:
My engineering mind immediately goes to 'how would we implement this in terms of the existing infrastructure of the comps file, kickstart files, etc.', and is somewhat confused. We could have a lot of new groups, I guess, that are structured in this way, but it means a lot of random packages would no longer be selectable via the UI. This could be both good and bad.
Well... regarding random packages not being selectable in the anaconda UI - is that really a problem? Isn't it better (and I know it's not there yet :) ) to have one place that's really optimized for package picking - packagekit - and if users really want a particular set of packages they can do post-install?
If the use case is, I'm upgrading from F13 to F14 with a fresh install but I don't want to have to sit around for 2-3 hours trying to cherry-pick the add-on packages I installed last time... there's probably a better way to solve it than checkboxes in anaconda's GUI right? Is there a different use case those package-by-package checkboxes solve? (Noting that if you really need to spit out a bunch of systems with a particular manifest of packages you're better off using kickstart and skipping the GUI?)
Another idea would be to make all the groups we have either much more general (the desktop group would include its sound apps, the KDE group would include its sound apps, and we could drop the general group), or much more focused (specific task groups, like 'office-suite', or 'imap server', or similar). We could then build up logical installation classes or installation profiles that consist of combinations of these. (This is what another product does, of course.)
This is a big advantage of the live media; it's not just curated for the default offering, but gives a good method for any use case to design for its offering.
This is also a huge problem with the live media.... it proliferates the limiting notion that Fedora is a bucket o' packages rather than a platform to build upon.
Hm. Maybe it's me, but I think the current incarnation of the non-live media (need a better nomenclature) reinforces this even worse, actually giving the user a pile of options to select & deselect and break themselves with. At least with the various live media, we get something that theoretically has been curated and tested as a unit.
Ah totally agreed. I wasn't really clear what I meant, sorry; what I mean is that the spins work off of the everything bucket-o-packages and kind of start with a clean slate every time, rather than Fedora having a defined, familiar platform for end-users that you build the spins on top of. (Does that make sense?) I guess you could say it is a platform wrt how spins work today, but it's a very low-level platform that doesn't include a desktop and some of the bits under the desktop.
Also thank you for the 'theoretically' (she says after the experience of discovering the design suite spin had no networking stack for some weeks)
Stepping back for a sec, a lot of this would go back to actually designating what the non-Live media is for. We've *never* done that, leading to it essentially just being 'a set reasonably comparable to what was on the old Red Hat Linux CD/DVD.' I don't see how something with that mantra helps with our usage cases/target audience, regardless of technical benefits.
Which do you mean? The mantra that designating what non-live media is for doesn't help, or the mantra that the DVD is comparable to ye olde RHL doesn't help?
The latter. The non-live media has never had a real target other than the bucket'o'packages idea, and therefore isn't really designed for anything specific.
It'd be nice to fix that wouldn't it?
~m
Máirín Duffy (duffy@fedoraproject.org) said:
On Mon, 2011-01-24 at 22:29 +0000, Bill Nottingham wrote:
My engineering mind immediately goes to 'how would we implement this in terms of the existing infrastructure of the comps file, kickstart files, etc.', and is somewhat confused. We could have a lot of new groups, I guess, that are structured in this way, but it means a lot of random packages would no longer be selectable via the UI. This could be both good and bad.
Well... regarding random packages not being selectable in the anaconda UI - is that really a problem? Isn't it better (and I know it's not there yet :) ) to have one place that's really optimized for package picking - packagekit - and if users really want a particular set of packages they can do post-install?
It makes sense, yes. I'm just trying to organize what we currently have, where the package groups (and the attributes around the packages - mandatory, optional, etc.) are exposed as installable entities:
- in anaconda, in this group selection screen - in anaconda/kickstart, in %packages - in yum, post-install - in PackageKit, post-install
So, changing what anaconda does in group selection to do something else (or removing group selection entirely), without changing where it's exposed elsewhere doesn't help us as much.
Now, if it just means we expose the groups solely as groups (i.e., no individual package selection in them), then we don't need as much drastic surgery. Although, I do wonder if the same interface makes sense for all the logical groups we have - for example, a desktop environment should likely be a single group that is installed and removed as a unit, but I could see the Games group as something that's better served by a browsing interface.
Hm. Maybe it's me, but I think the current incarnation of the non-live media (need a better nomenclature) reinforces this even worse, actually giving the user a pile of options to select & deselect and break themselves with. At least with the various live media, we get something that theoretically has been curated and tested as a unit.
Ah totally agreed. I wasn't really clear what I meant, sorry; what I mean is that the spins work off of the everything bucket-o-packages and kind of start with a clean slate every time, rather than Fedora having a defined, familiar platform for end-users that you build the spins on top of. (Does that make sense?) I guess you could say it is a platform wrt how spins work today, but it's a very low-level platform that doesn't include a desktop and some of the bits under the desktop.
Tossing out ideas - if we really want a defined platform, then why not build at compose time an image of that platform, embed it on the media, install it via the live method, and then reboot into that platform to install packages/groups on top of it to customize?
Obviously this complicates the installer, and if the RPM installation is as repeatable as it should be, it may not be worth the effort to optimize it in this way.
Bill
On 1/21/11 1:25 PM, Máirín Duffy wrote:
= Disadvantages of Live Media: =
I have another one that I'd need to quantify. When preparing the image for the live media, the fs gets shrunk, as I understand it. During installation, it gets grown again to the size of the host. This will almost certainly result in a less-than-optimal layout of the OS files in the filesystem, but I'd need to poke at it a bit to see just how it changes things.
-Eric
On Fri, 2011-01-21 at 22:00 +0000, Eric Sandeen wrote:
On 1/21/11 1:25 PM, Máirín Duffy wrote:
= Disadvantages of Live Media: =
I have another one that I'd need to quantify. When preparing the image for the live media, the fs gets shrunk, as I understand it. During installation, it gets grown again to the size of the host. This will almost certainly result in a less-than-optimal layout of the OS files in the filesystem, but I'd need to poke at it a bit to see just how it changes things.
Interesting! I added this point to the draft, it's a good thing to note!
~m
2011/1/21 Máirín Duffy duffy@fedoraproject.org:
Hi,
After some discussion in #anaconda earlier this week I put together a proposal for using a full anaconda environment as the default installation method for Fedora rather than the current live installation environment. Before I sent this to fedora-devel (which I'm admittedly terrified of) I was hoping you folks might be willing to look over it below and sanity-check it for me?
The next step I think is maybe to have some discussion on fedora-devel and propose it to FESCo.
I really appreciate any feedback!
Thanks, ~m
PROPOSAL: Use full installer environment as default Fedora install method
Currently (and since ~Fedora 12) the default media promoted for installation of Fedora both via our website at fedoraproject.org and at conferences and other events is the Desktop Live Media ISO, delivered via pressed optical media at events, and typically delivered via home-burned optical media or live usb media created via dd, livecd-creator on the command line, or the Live USB Creator GUI (the latter the most popular for non-Linux systems.)
I don't think this is quite a fair representation of the situation when it comes to pressed media distributed at events. We don't promote either as a "default" method. We have always produced far more non-live media for events, usually it outnumbers all the live media by 2 to 1 in North America. While some people do install from the live media we really promote it as an easy way to try Fedora out, not as a preferred way to install it.
Live Media affords some clear advantages over traditional installers, primarily in its ability to be used via USB sticks as optical drives are less ubiquitous in laptops and its singularity as one image you can try-before-you-buy to test out drivers, rescue machines, and use as a full installer. It also affords a gee-whiz factor.
However, there are some serious concerns about the stability and overall user experience in promoting live media as the primary installation method of Fedora. There is also a larger concern about the future direction and maintenance of the spins project. Creating and maintaining usable live media is not a trivial task and many of our spins maintainers have understandably burnt out. Reconsidering how we deliver installation of Fedora to our end users may offer an opportunity to help this situation.
Again, we do not promote it now as the primary installation method.
From the perspective of someone who has handed out such media at
events, if the install to hard drive option on the live media is causing issues my suggestion is to remove it. The live media has great value without it - it seems to be almost an afterthought anyway.
John
Currently (and since ~Fedora 12) the default media promoted for installation of Fedora both via our website at fedoraproject.org and at conferences and other events is the Desktop Live Media ISO, delivered via pressed optical media at events, and typically delivered via home-burned optical media or live usb media created via dd, livecd-creator on the command line, or the Live USB Creator GUI (the latter the most popular for non-Linux systems.)
I don't think this is quite a fair representation of the situation when it comes to pressed media distributed at events. We don't promote either as a "default" method. We have always produced far more non-live media for events, usually it outnumbers all the live media by 2 to 1 in North America. While some people do install from the live media we really promote it as an easy way to try Fedora out, not as a preferred way to install it.
While that may all be quite true, for live events, the fact remains when I go to:
http://fedoraproject.org/en/get-fedora
The big obvious Download button here is for the live media, not for the installer. I would wager that since Fedora 12 the number of installs / upgrades done via the live image has gone up significantly because of this.
Now I am a *HUGE* supporter of the Single button serves most uses approach (heck I'm probably the reason there's a big blue button on the get-fedora page), but to find the normal install media on the site I specifically have to jump through two additional clicks:
More download options... -> Formats
The formats section of the page is hidden via javascript, which I'll add is annoying.
This tells me that the Fedora Project is pushing for people to do more via the live cd than via the traditional install media, particularly since it's as buried as it is and the only way to find it is to dig and know it's there.
Live Media affords some clear advantages over traditional installers, primarily in its ability to be used via USB sticks as optical drives are less ubiquitous in laptops and its singularity as one image you can try-before-you-buy to test out drivers, rescue machines, and use as a full installer. It also affords a gee-whiz factor.
However, there are some serious concerns about the stability and overall user experience in promoting live media as the primary installation method of Fedora. There is also a larger concern about the future direction and maintenance of the spins project. Creating and maintaining usable live media is not a trivial task and many of our spins maintainers have understandably burnt out. Reconsidering how we deliver installation of Fedora to our end users may offer an opportunity to help this situation.
Again, we do not promote it now as the primary installation method.
From the perspective of someone who has handed out such media at
events, if the install to hard drive option on the live media is causing issues my suggestion is to remove it. The live media has great value without it - it seems to be almost an afterthought anyway.
If the project is not intending to push the download of the live image over the traditional install media, than I must ask the obvious question: why does the website seem to promote otherwise?
I don't entirely agree with removing the installation option from the live media, I think it actually would be a bad idea.
The issue at hand seems to be one where there are, effectively, two different installers being supported (one from the live image, and the more normal anaconda route). Why not simplify this some?
On the live image have the "install" option do nothing more than execute a kexec (with an appropriate we will be leaving the live realm and entering the installer, you can't switch back and forth, etc preamble) to a safe install medium, likely the anaconda network installer to save space.
This would, I think, keep both sides of this situation happy. It still uses the proper anaconda installer, while preserving the ability to opportunistically let people install from the live image should they want.
And if the live images had boot from iscsi support you could run the whole thing, end to end, from the internet - but I'll admit I can't figure out who's in charge of the live images to get that support added in (which I'd happily do the patches for).
- John 'Warthog9' Hawley
On Fri, Jan 21, 2011 at 8:33 PM, J.H. warthog19@eaglescrag.net wrote:
Currently (and since ~Fedora 12) the default media promoted for installation of Fedora both via our website at fedoraproject.org and at conferences and other events is the Desktop Live Media ISO, delivered via pressed optical media at events, and typically delivered via home-burned optical media or live usb media created via dd, livecd-creator on the command line, or the Live USB Creator GUI (the latter the most popular for non-Linux systems.)
I don't think this is quite a fair representation of the situation when it comes to pressed media distributed at events. We don't promote either as a "default" method. We have always produced far more non-live media for events, usually it outnumbers all the live media by 2 to 1 in North America. While some people do install from the live media we really promote it as an easy way to try Fedora out, not as a preferred way to install it.
While that may all be quite true, for live events, the fact remains when I go to:
http://fedoraproject.org/en/get-fedora
The big obvious Download button here is for the live media, not for the installer. I would wager that since Fedora 12 the number of installs / upgrades done via the live image has gone up significantly because of this.
Now I am a *HUGE* supporter of the Single button serves most uses approach (heck I'm probably the reason there's a big blue button on the get-fedora page), but to find the normal install media on the site I specifically have to jump through two additional clicks:
More download options... -> Formats
The formats section of the page is hidden via javascript, which I'll add is annoying.
This tells me that the Fedora Project is pushing for people to do more via the live cd than via the traditional install media, particularly since it's as buried as it is and the only way to find it is to dig and know it's there.
I don't disagree with that, I just didn't want both distribution channels lumped together because at live events I think the impression we give is live media is for trying stuff out non-destructively and installation media is for installing Fedora with both available to visitors.
Live Media affords some clear advantages over traditional installers, primarily in its ability to be used via USB sticks as optical drives are less ubiquitous in laptops and its singularity as one image you can try-before-you-buy to test out drivers, rescue machines, and use as a full installer. It also affords a gee-whiz factor.
However, there are some serious concerns about the stability and overall user experience in promoting live media as the primary installation method of Fedora. There is also a larger concern about the future direction and maintenance of the spins project. Creating and maintaining usable live media is not a trivial task and many of our spins maintainers have understandably burnt out. Reconsidering how we deliver installation of Fedora to our end users may offer an opportunity to help this situation.
Again, we do not promote it now as the primary installation method.
From the perspective of someone who has handed out such media at
events, if the install to hard drive option on the live media is causing issues my suggestion is to remove it. The live media has great value without it - it seems to be almost an afterthought anyway.
If the project is not intending to push the download of the live image over the traditional install media, than I must ask the obvious question: why does the website seem to promote otherwise?
I can't speak to the reasons the website is how it is. Probably just a case of the best intentions not leading to the best results. There is no reason to not revisit those decisions now and make appropriate changes. I'm all for that.
I don't entirely agree with removing the installation option from the live media, I think it actually would be a bad idea.
Yeah, I am ambivalent about the install option on live media personally. I never use, I know others who always use it. It just isn't really the selling point of the live media to me.
The issue at hand seems to be one where there are, effectively, two different installers being supported (one from the live image, and the more normal anaconda route). Why not simplify this some?
No objection from me.
On the live image have the "install" option do nothing more than execute a kexec (with an appropriate we will be leaving the live realm and entering the installer, you can't switch back and forth, etc preamble) to a safe install medium, likely the anaconda network installer to save space.
This would, I think, keep both sides of this situation happy. It still uses the proper anaconda installer, while preserving the ability to opportunistically let people install from the live image should they want.
And if the live images had boot from iscsi support you could run the whole thing, end to end, from the internet - but I'll admit I can't figure out who's in charge of the live images to get that support added in (which I'd happily do the patches for).
No objection to any of those suggestions either.
John
On Sat, 2011-01-22 at 02:33 +0000, J.H. wrote:
I don't entirely agree with removing the installation option from the live media, I think it actually would be a bad idea.
The issue at hand seems to be one where there are, effectively, two different installers being supported (one from the live image, and the more normal anaconda route). Why not simplify this some?
On the live image have the "install" option do nothing more than execute a kexec (with an appropriate we will be leaving the live realm and entering the installer, you can't switch back and forth, etc preamble) to a safe install medium, likely the anaconda network installer to save space.
This is a really interesting idea. Is there a way to enable an install without internet connection though? Is it a problem if not? I'm not sure - you need an internet connection to download the ISO in the first place so maybe not. (It might be a problem to hand something like this out at shows or thru the free media project though? Maybe?)
This would, I think, keep both sides of this situation happy. It still uses the proper anaconda installer, while preserving the ability to opportunistically let people install from the live image should they want.
I like it, what do the installer team folks think?
And if the live images had boot from iscsi support you could run the whole thing, end to end, from the internet - but I'll admit I can't figure out who's in charge of the live images to get that support added in (which I'd happily do the patches for).
I'm not sure either, sadly :(
~m
On Sat, 2011-01-22 at 02:02 +0000, inode0 wrote:
Currently (and since ~Fedora 12) the default media promoted for installation of Fedora both via our website at fedoraproject.org and at conferences and other events is the Desktop Live Media ISO, delivered via pressed optical media at events, and typically delivered via home-burned optical media or live usb media created via dd, livecd-creator on the command line, or the Live USB Creator GUI (the latter the most popular for non-Linux systems.)
I don't think this is quite a fair representation of the situation when it comes to pressed media distributed at events. We don't promote either as a "default" method. We have always produced far more non-live media for events, usually it outnumbers all the live media by 2 to 1 in North America. While some people do install from the live media we really promote it as an easy way to try Fedora out, not as a preferred way to install it.
Fair enough. It is pressed for and distributed at events, though, which I think is still worth considering since it's still in the mix (and that may or may not be completely valid to continue doing depending on how we think this through...)
The website, though, absolutely promotes it as the primary method, intentionally so.
I'll rewrite this paragraph on the proposal wiki page to not make it seem as if its the primary thing promoted at events.
Live Media affords some clear advantages over traditional installers, primarily in its ability to be used via USB sticks as optical drives are less ubiquitous in laptops and its singularity as one image you can try-before-you-buy to test out drivers, rescue machines, and use as a full installer. It also affords a gee-whiz factor.
However, there are some serious concerns about the stability and overall user experience in promoting live media as the primary installation method of Fedora. There is also a larger concern about the future direction and maintenance of the spins project. Creating and maintaining usable live media is not a trivial task and many of our spins maintainers have understandably burnt out. Reconsidering how we deliver installation of Fedora to our end users may offer an opportunity to help this situation.
Again, we do not promote it now as the primary installation method.
Maybe at events, but it is promoted as such on the website. I'm not sure what % of installs originate from event-distributed media but would it be the majority? I think online is probably the primary distribution channel? (Does that seem sensical?)
From the perspective of someone who has handed out such media at
events, if the install to hard drive option on the live media is causing issues my suggestion is to remove it. The live media has great value without it - it seems to be almost an afterthought anyway.
I'm glad to hear this. I don't know how widely this opinion is shared but I hope it is.
~m
2011/1/21 Máirín Duffy duffy@fedoraproject.org:
On Sat, 2011-01-22 at 02:02 +0000, inode0 wrote:
Currently (and since ~Fedora 12) the default media promoted for installation of Fedora both via our website at fedoraproject.org and at conferences and other events is the Desktop Live Media ISO, delivered via pressed optical media at events, and typically delivered via home-burned optical media or live usb media created via dd, livecd-creator on the command line, or the Live USB Creator GUI (the latter the most popular for non-Linux systems.)
I don't think this is quite a fair representation of the situation when it comes to pressed media distributed at events. We don't promote either as a "default" method. We have always produced far more non-live media for events, usually it outnumbers all the live media by 2 to 1 in North America. While some people do install from the live media we really promote it as an easy way to try Fedora out, not as a preferred way to install it.
Fair enough. It is pressed for and distributed at events, though, which I think is still worth considering since it's still in the mix (and that may or may not be completely valid to continue doing depending on how we think this through...)
Well, this is what was worrying me about this discussion. I think the live media (or some sort of live media) really has tremendous value at events big and small. If this leads to an effort to make better live media I'm all for it. Getting rid of live media is going to be a tough sell to those of us who see its value.
The website, though, absolutely promotes it as the primary method, intentionally so.
Yup, I see that.
I'll rewrite this paragraph on the proposal wiki page to not make it seem as if its the primary thing promoted at events.
Thanks.
Live Media affords some clear advantages over traditional installers, primarily in its ability to be used via USB sticks as optical drives are less ubiquitous in laptops and its singularity as one image you can try-before-you-buy to test out drivers, rescue machines, and use as a full installer. It also affords a gee-whiz factor.
However, there are some serious concerns about the stability and overall user experience in promoting live media as the primary installation method of Fedora. There is also a larger concern about the future direction and maintenance of the spins project. Creating and maintaining usable live media is not a trivial task and many of our spins maintainers have understandably burnt out. Reconsidering how we deliver installation of Fedora to our end users may offer an opportunity to help this situation.
Again, we do not promote it now as the primary installation method.
Maybe at events, but it is promoted as such on the website. I'm not sure what % of installs originate from event-distributed media but would it be the majority? I think online is probably the primary distribution channel? (Does that seem sensical?)
I'm sure the number of installs generated by the website dwarfs the number from media distributed at events. We probably only give out around 6k pieces of media per release in North America so I hope other installation sources contribute more to our user base.
From the perspective of someone who has handed out such media at
events, if the install to hard drive option on the live media is causing issues my suggestion is to remove it. The live media has great value without it - it seems to be almost an afterthought anyway.
I'm glad to hear this. I don't know how widely this opinion is shared but I hope it is.
I know other people who love installing from live media. But as I look at the sources of value that live media brings to the table that is at the bottom of the list.
I'll add that the biggest shortcoming of the current live media in my opinion is that it doesn't include enough software to really showcase Fedora in as powerful a way as it could. I would like to see us move to live media that includes much more, perhaps as big as 2GB which could easily accommodate a full installer being incorporated into it.
John
On Sat, 2011-01-22 at 03:09 +0000, inode0 wrote:
Well, this is what was worrying me about this discussion. I think the live media (or some sort of live media) really has tremendous value at events big and small. If this leads to an effort to make better live media I'm all for it. Getting rid of live media is going to be a tough sell to those of us who see its value.
Is the value in demoing *in the booth* or giving to people to take home?
Maybe at events, but it is promoted as such on the website. I'm not sure what % of installs originate from event-distributed media but would it be the majority? I think online is probably the primary distribution channel? (Does that seem sensical?)
I'm sure the number of installs generated by the website dwarfs the number from media distributed at events. We probably only give out around 6k pieces of media per release in North America so I hope other installation sources contribute more to our user base.
Ah. So it may not be worth mentioning events much at all in the proposal. Sorry for stringing it in, especially in such a misinformed light, I'm very sorry - I don't know much about which media is produced in what numbers, but thought we had handed out a lot more live media than DVD at shows I've been boothing at in recent memory.
From the perspective of someone who has handed out such media at
events, if the install to hard drive option on the live media is causing issues my suggestion is to remove it. The live media has great value without it - it seems to be almost an afterthought anyway.
I'm glad to hear this. I don't know how widely this opinion is shared but I hope it is.
I know other people who love installing from live media. But as I look at the sources of value that live media brings to the table that is at the bottom of the list.
I'll add that the biggest shortcoming of the current live media in my opinion is that it doesn't include enough software to really showcase Fedora in as powerful a way as it could. I would like to see us move to live media that includes much more, perhaps as big as 2GB which could easily accommodate a full installer being incorporated into it.
Yeh, I think a word processor would help. And gimp. And inkscape. But I am biased :)
~m
2011/1/21 Máirín Duffy duffy@fedoraproject.org:
On Sat, 2011-01-22 at 03:09 +0000, inode0 wrote:
Well, this is what was worrying me about this discussion. I think the live media (or some sort of live media) really has tremendous value at events big and small. If this leads to an effort to make better live media I'm all for it. Getting rid of live media is going to be a tough sell to those of us who see its value.
Is the value in demoing *in the booth* or giving to people to take home?
Personally I would prefer a mix of both. You have a live media which can be demoed and if you want a particular blend of Fedora there are desktop icons which a person clicks and then runs the anaconda installer to get to the hardware. However wishes are fishes.
I normally use "live" media for enhanced rescue environments. While probably not the "best" use, I have seen colocation techs use it to boot up a system and check out what is running compared to how hardware was running before. Other places I have seen it used are in throw away mode places. I have untrusted hardware, network, etc. I just want to run from a cdrom and save to a flash/usb drive (or some combo of all that). tada. In those cases, I am not wanting to install (heck I really really DON'T want to install in some cases.)
2011/1/21 Máirín Duffy duffy@fedoraproject.org:
On Sat, 2011-01-22 at 03:09 +0000, inode0 wrote:
Well, this is what was worrying me about this discussion. I think the live media (or some sort of live media) really has tremendous value at events big and small. If this leads to an effort to make better live media I'm all for it. Getting rid of live media is going to be a tough sell to those of us who see its value.
Is the value in demoing *in the booth* or giving to people to take home?
There is high value for demo use but not just at booths. The convenience of having them available on your laptop to boot in a VM at will or on a USB stick make it possible to quickly show off Fedora to an interested person pretty much any time the occasion arises.
At events I think there is more value in getting people to test Fedora while they are at the event than sending a DVD home with them. Since live media can be experimented with non-destructively I often see someone come back to the booth the next day with questions after playing around with Fedora in their room overnight. That really doesn't happen with the full DVD during events. I have no way of knowing how many people who take DVDs home actually install Fedora from them but I'm pretty pessimistic about the number, I suspect it is pretty low and most event goers at least in NA and EMEA are probably quite capable of downloading it anyway.
So as far as event use goes I am a big fan of live media and think it is in general a better thing for us to use to hook folks in that environment.
Live media is also valuable to some people to test whether a particular piece of hardware will be happy with Fedora. That use case is small, but it can sure put your mind at ease booting it up and seeing that the wireless works before you buy it.
Live media is valuable in various situations where you don't want to install but you want to boot into a safe environment. I use Fedora live media in several ways that fall into this category, but there are alternatives and using Fedora doesn't bring anything specific to these cases.
Maybe at events, but it is promoted as such on the website. I'm not sure what % of installs originate from event-distributed media but would it be the majority? I think online is probably the primary distribution channel? (Does that seem sensical?)
I'm sure the number of installs generated by the website dwarfs the number from media distributed at events. We probably only give out around 6k pieces of media per release in North America so I hope other installation sources contribute more to our user base.
Ah. So it may not be worth mentioning events much at all in the proposal. Sorry for stringing it in, especially in such a misinformed light, I'm very sorry - I don't know much about which media is produced in what numbers, but thought we had handed out a lot more live media than DVD at shows I've been boothing at in recent memory.
I think it is fair to estimate that in the area of 25k to 30k pieces of pressed media annually are distributed by representatives of the project. Event owners request the media they want for their events, some will choose live media based on availability or their view of how well it matches those who they expect to attend. So what you see at any particular show is not consistent across shows.
Freemedia is another data point but I think one you should probably disregard too. Requests for freemedia are overwhelmingly lopsided in favor of full installation DVDs but the folks requesting media that way typically do not have adequate bandwidth to download it so they want as much software on the media as possible. The volume in the freemedia program is also low, maybe around 300-500 pieces of media a month.
From the perspective of someone who has handed out such media at
events, if the install to hard drive option on the live media is causing issues my suggestion is to remove it. The live media has great value without it - it seems to be almost an afterthought anyway.
I'm glad to hear this. I don't know how widely this opinion is shared but I hope it is.
I know other people who love installing from live media. But as I look at the sources of value that live media brings to the table that is at the bottom of the list.
I'll add that the biggest shortcoming of the current live media in my opinion is that it doesn't include enough software to really showcase Fedora in as powerful a way as it could. I would like to see us move to live media that includes much more, perhaps as big as 2GB which could easily accommodate a full installer being incorporated into it.
Yeh, I think a word processor would help. And gimp. And inkscape. But I am biased :)
I agree. I'm not biased for either word processors or inkscape as I really don't use either but I do think they should be on the live media. What we want is to have on the media what will impress the person booting it up and looking around and we don't know in advance what their interests will be (but we know they will cover just about everything if we sum them up).
John
On 01/21/2011 11:25 AM, Máirín Duffy wrote:
When I installed Fedora 14 via DVD, it took:
‣ 45 minutes from starting the install to booting into a running desktop
That install time is 2X slower than I usually see on my boxes.
Today I performed three installs of a DVD of Fedora 15 rawhide in (mm:ss) to these root filesystems: total type Packages only 21:31 ext2 15:45 22:14 ext3 16:28 21:54 ext4 16:12 The box is a 2.0GHz uniprocessor x86_64, 3.3GB DDR RAM (not DDR2 or DDR3), 4X DVD+RW media in desktop DVD drive ("22X" but only 4X because of media), 7200RPM SATA 3.0 Gbit/s harddrive (138MB/s observed max transfer rate.)
I composed the DVD myself using pungi. I excluded all the @Languages by commenting them out in the fedora-rawhide.ks, so the result is 2.6GB instead of 3.5GB. I Fresh Installed the default Graphical Desktop to an existing 16GB partition, reformatted to ext2/3/4. There were 1207 packages which "df" said occupied 3.4GB on the installed root filesystem.
Switching to VT2 just before reboot, "ps ax | grep anaconda" showed just over 9 minutes CPU time, for an average 41% CPU utilization. By creating a three-stage pipeline (fetch .rpm and uncompress, %install, %post) and running two pipes in parallel, then the time for package install can be reduced by a factor of 2X or more. Note that there were at least 2*1207 DVD seeks which accounted for about 300 seconds of dead time. One pipeline would recover that 5 minutes easily. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=71184 (8 years old.)
I composed the DVD myself using pungi. I excluded all the @Languages by commenting them out in the fedora-rawhide.ks, so the result is 2.6GB instead of 3.5GB. I Fresh Installed the default Graphical Desktop to an existing 16GB partition, reformatted to ext2/3/4. There were 1207 packages which "df" said occupied 3.4GB on the installed root filesystem.
Today I built a DVD with no excluded languages: 3.8GB total DVD size, 3150 packages. Graphical Desktop installed the same 1207 packages as before: total 3.4GB on ext4, taking the same elapsed time of 22 minutes.
Hi John,
On Mon, 2011-01-24 at 00:19 +0000, John Reiser wrote:
I composed the DVD myself using pungi. I excluded all the @Languages by commenting them out in the fedora-rawhide.ks, so the result is 2.6GB instead of 3.5GB. I Fresh Installed the default Graphical Desktop to an existing 16GB partition, reformatted to ext2/3/4. There were 1207 packages which "df" said occupied 3.4GB on the installed root filesystem.
Today I built a DVD with no excluded languages: 3.8GB total DVD size, 3150 packages. Graphical Desktop installed the same 1207 packages as before: total 3.4GB on ext4, taking the same elapsed time of 22 minutes.
These are really fantastic data points, thanks for doing this. I was wondering if you could try the live desktop cd too, just as a point of comparison, on the same hardware? I really hope DVD is as fast...
~m
Hi Máirín,
I was wondering if you could try the live desktop cd too, just as a point of comparison, on the same hardware? I really hope DVD is as fast...
Today's rawhide nightly compose Live Image http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64... boots into Gnome shell, but the icon Activities > Applications > Install to ... says "Can't do live image installation unless running from a live image." The same message appears when running /usr/bin/liveinst from a text shell on VT2; and the shell also reports a Segmentation violation from zenity. Is there another URL that I should try?
On 01/23/2011 05:53 PM, Máirín Duffy wrote:
On Mon, 2011-01-24 at 00:19 +0000, John Reiser wrote:
Today I built a DVD with no excluded languages: 3.8GB total DVD size, 3150 packages. Graphical Desktop installed the same 1207 packages as before: total 3.4GB on ext4, taking the same elapsed time of 22 minutes.
These are really fantastic data points, thanks for doing this. I was wondering if you could try the live desktop cd too, just as a point of comparison, on the same hardware? I really hope DVD is as fast...
Finally, a Fedora 15 Live spin that installs: the 22-Feb-2011 edition of http://serverbeach1.fedoraproject.org/pub/alt/stage/15-Alpha.RC1/Live/x86_64... I burned the 570MB to DVD+RW.
clock stage ----- ------ 00:00 Install to harddrive... 02:15 Copying from 4X DVD+RW to harddrive 05:02 Checking copied [installed] filesystem 06:55 Congratulations! [done] 1097 packages occupying 2.56GB of ext4; 9.14MB/s average over 280 seconds
That's on 2.0GHz Athlon64 to ext4 on SATA 3.0Gbit/s. memtest86+-4.10 reports L1 64K 15705 MB/s L2 512K 3888 MB/s mem 3328M 1819 MB/s DDR1 128-bit
On newer hardware the General Desktop install from DVD is 09:08 (mm:ss). That's on 3.0GHz Core2 Duo E8400 memtest86+-4.10 reports L1 32K 42249 MB/s L2 6144K 19606 MB/s mem 8191M 4444 MB/s DDR2 128-bit
On a newer AMD box, General Desktop install from DVD is 09:32 (mm:ss). That's on 3.2GHz PhenomII x2 memtest86+-4.10 reports L1 64K 52695 MB/s L2 512K 17007 MB/s L3 6144K 9236 MB/s mem 4095M 3652 MB/s DDR2 128-bit
anaconda-devel@lists.fedoraproject.org
-
Bill Nottingham -
David Cantrell -
Eric Sandeen -
inode0 -
J.H. -
John Reiser -
Máirín Duffy -
Stephen John Smoogen