I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky.
Some of the things it does which are IMHO better:
- starts disk formatting / copying / installing in parallel with asking user questions
- downloads updates in parallel too
- uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time)
- suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch)
This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area.
Thoughts? Can we switch to their installer?
Rich.
On Mon, Oct 11, 2010 at 6:41 AM, Richard W.M. Jones rjones@redhat.com wrote:
I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky.
Some of the things it does which are IMHO better:
- starts disk formatting / copying / installing in parallel with asking user questions
- downloads updates in parallel too
- uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time)
- suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch)
This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area.
Thoughts? Can we switch to their installer?
I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project.
josh
On Mon, Oct 11, 2010 at 09:51:41AM -0400, Josh Boyer wrote:
I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project.
Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter.
Rich.
On Mon, 11 Oct 2010, Richard W.M. Jones wrote:
On Mon, Oct 11, 2010 at 09:51:41AM -0400, Josh Boyer wrote:
I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project.
Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter.
I think our pride problem will pretty much ensure that won't happen. Afterall, we're the innovators, not them. So if they did it, it's not innovation. :(
-Mike
On 10/11/2010 10:21 AM, Richard W.M. Jones wrote:
On Mon, Oct 11, 2010 at 09:51:41AM -0400, Josh Boyer wrote:
I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project.
Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter.
Do you seriously believe that we don't look at other OS installers, including Ubuntu's, for ideas?
That's quite the naïvette you've cultivated there.
On Mon, Oct 11, 2010 at 10:37:15AM -0400, Peter Jones wrote:
On 10/11/2010 10:21 AM, Richard W.M. Jones wrote:
On Mon, Oct 11, 2010 at 09:51:41AM -0400, Josh Boyer wrote:
I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project.
Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter.
Do you seriously believe that we don't look at other OS installers, including Ubuntu's, for ideas?
That's not obvious to me, no.
Rich.
On Mon, 2010-10-11 at 15:21 +0100, Richard W.M. Jones wrote:
On Mon, Oct 11, 2010 at 09:51:41AM -0400, Josh Boyer wrote:
I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project.
Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter.
We do.
Porting Fedora to the Ubuntu installer would be rather more work than just adding those features to anaconda. You might get a more favorable reaction by phrasing your RFEs positively ("this is a neat thing that these guys are doing, we should look into it") rather than negatively ("we should throw away what we're currently using and switch").
- ajax
On Mon, Oct 11, 2010 at 03:21:40PM +0100, Richard W.M. Jones wrote:
Proving what? You can just imagine what a rebranded Ubuntu installer that installed Fedora would look like. My point anyway is that we could look at Ubuntu for ideas, because the first point of contact with users is now very smooth and (maybe) first impressions matter.
Maybe the virt-manager developers could spend some more time looking at vmware? This isn't a good way to have a worthwhile discussion. A description of the factors that you feel make Ubiquity better than Anaconda would be a much better way to handle this.
2010/10/11 Josh Boyer jwboyer@gmail.com:
I would like to see you create a Fedora Remix spin with this change to illustrate the benefits. That way we can evaluate feasibility and overall value add before we dive head first into it across the whole project.
Useless waste of time. Just grab Ubuntu iso and see a stunning gap in both technology and usability between anaconda and their own installed.
Useless waste of time. Just grab Ubuntu iso and see a stunning gap in both technology and usability between anaconda and their own installed.
Does the Ubuntu installer support installing to iscsi? Multipath? CCISS? Fully automated installation? Install over VNC? Installation from NFS, ISO on NFS, ISO on HD? Live images on USB keys? Driver disks?
Do you have any idea how much crap anaconda really does?
- Chris
On Mon, Oct 11, 2010 at 10:48:44AM -0400, Chris Lumens wrote:
Useless waste of time. Just grab Ubuntu iso and see a stunning gap in both technology and usability between anaconda and their own installed.
Does the Ubuntu installer support installing to iscsi? Multipath? CCISS? Fully automated installation? Install over VNC? Installation from NFS, ISO on NFS, ISO on HD? Live images on USB keys? Driver disks?
Do you have any idea how much crap anaconda really does?
<SNIP>
A big epic +1
-AdamM
On Mon, 2010-10-11 at 10:48 -0400, Chris Lumens wrote:
Useless waste of time. Just grab Ubuntu iso and see a stunning gap in both technology and usability between anaconda and their own installed.
Does the Ubuntu installer support installing to iscsi? Multipath? CCISS? Fully automated installation? Install over VNC? Installation from NFS, ISO on NFS, ISO on HD? Live images on USB keys? Driver disks?
Do you have any idea how much crap anaconda really does?
That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users.
Matthias Clasen (mclasen@redhat.com) said:
That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users.
Correct. And any time it's suggested that certain parts of that crap be removed to streamline things, people come screaming. (The discussion about pruning the install methods is the one that comes to mind... mm, nfsiso and hard drive installs.)
Bill
On Mon, 2010-10-11 at 13:16 -0400, Bill Nottingham wrote:
Matthias Clasen (mclasen@redhat.com) said:
That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users.
Correct. And any time it's suggested that certain parts of that crap be removed to streamline things, people come screaming. (The discussion about pruning the install methods is the one that comes to mind... mm, nfsiso and hard drive installs.)
The permutations are exhaustive.
https://www.redhat.com/archives/anaconda-devel-list/2010-May/msg00305.html
Thanks, James
On Mon, 2010-10-11 at 13:16 -0400, Bill Nottingham wrote:
Matthias Clasen (mclasen@redhat.com) said:
That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users.
Correct. And any time it's suggested that certain parts of that crap be removed to streamline things, people come screaming. (The discussion about pruning the install methods is the one that comes to mind... mm, nfsiso and hard drive installs.)
...and all the people who are complaining about how the text install has been streamlined...
On Mon, Oct 11, 2010 at 01:07:26PM -0400, Matthias Clasen wrote:
That is certainly a big part of the problem. Anaconda does a _ton_ of crap that only very few users care about. And keeping all these minority features from falling apart is leaving you no time to polish the user experience for the large majority of users.
I do not see why we should remove functionality (and almost everything is there for a good reason) to "polish the user experience". I do not even see that the latter is needed (the things mentioned in the initial mail we really minor things and/or probably quite easy to add), but that's maybe my fault as a hard-core UNIX guy...
I recently had to install a SLES system for some experimental reason and ended up with a screwed-up system (read: MBR), probably because the user experience was so polished that it didn't want to ask me the things it *should* have asked :(.
- downloads updates in parallel too
Package updates?
- uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time)
We can do this, it's just never really been brought up. I'd like to rework a lot of the l10n stuff anyway, there just never seems to be time.
- suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch)
If DNS knows a hostname, we will suggest that. Of course it's not foolproof.
mgracik is working on the username suggestion thing already.
Thoughts? Can we switch to their installer?
No.
- Chris
Chris Lumens (clumens@redhat.com) said:
- downloads updates in parallel too
Package updates?
1) Given that it's using yum, downloading multiple things in parallel would need to be fixed there. 2) If it means downloading packages in the background while it does other tasks, given that package selection is the final task in the current workflow, it would require reordering the workflow to be beneficial. (Which becomes a memory usage tradeoff.)
Bill
On Mon, 2010-10-11 at 13:18 -0400, Bill Nottingham wrote:
Chris Lumens (clumens@redhat.com) said:
- downloads updates in parallel too
Package updates?
- Given that it's using yum, downloading multiple things in parallel
would need to be fixed there.
We have an open rfe for related things - we're hoping to combine two rfe's into one:
1. have the pkg/metadata downloads run in a different process in a different context - for selinux 2. have each repo have its own downloader process which can handle however many pkgs/metadata at a time that downloader process can cope with.
If someone wants to work on that come by #yum
-sv
On Mon, 2010-10-11 at 13:18 -0400, Bill Nottingham wrote:
Chris Lumens (clumens@redhat.com) said:
- downloads updates in parallel too
Package updates?
- Given that it's using yum, downloading multiple things in parallel
would need to be fixed there. 2) If it means downloading packages in the background while it does other tasks, given that package selection is the final task in the current workflow, it would require reordering the workflow to be beneficial. (Which becomes a memory usage tradeoff.)
I believe the Ubuntu installer under discussion is the live installer. Like Fedora, there is no package selection involved there. Ubuntu gains considerable simplicity by having a separate installer app for live images and making that its default installer - I'm no expert, but I think the 'advanced' installer you can use for network installs and custom package selection and LVM and RAID and all that stuff is essentially Debian's installer, and is a completely different experience to the Ubuntu installer.
So, we could follow this same path and make an anaconda-live which would be a considerably simplified subset of anaconda and could gain in parallelization and simplification and stuff, but we'd be duplicating a lot of effort then and we'd have no handy 'upstream' installer to fall back on for more complex cases, as Ubuntu does.
On Mon, 2010-10-11 at 11:11 -0400, Chris Lumens wrote:
- downloads updates in parallel too
Package updates?
- uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time)
We can do this, it's just never really been brought up. I'd like to rework a lot of the l10n stuff anyway, there just never seems to be time.
Would like to see this as well.
- suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch)
If DNS knows a hostname, we will suggest that. Of course it's not foolproof.
That's not it. Your name is entered (Chris Lumens) and from it you should get a hostname (chris-lumens-fedora-desktop.local) as well as a presentation name ("Chris Lumens' Fedora Desktop") which could be used for things like services being advertised through avahi, or even the default name for the Bluetooth adapters.
See xdg-hostname on Freedesktop.org. I'd definitely like to see something like that move forward so people can have nice names for their Bluetooth adapters on the machines, and remove the need for me to show a text entry to change that name in gnome-bluetooth.
mgracik is working on the username suggestion thing already.
Thoughts? Can we switch to their installer?
No.
- Chris
On Tue, 2010-10-12 at 16:00 +0100, Bastien Nocera wrote:
On Mon, 2010-10-11 at 11:11 -0400, Chris Lumens wrote:
- suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch)
If DNS knows a hostname, we will suggest that. Of course it's not foolproof.
That's not it. Your name is entered (Chris Lumens) and from it you should get a hostname (chris-lumens-fedora-desktop.local) as well as a presentation name ("Chris Lumens' Fedora Desktop") which could be used for things like services being advertised through avahi, or even the default name for the Bluetooth adapters.
The Mac does this too, and I'm sure it's great for avahi stuff ... but it's really annoying for anyone using the hostname anywhere else (mainly due to the expected size). Is there nowhere else that we could store a "hostsummary" instead of hostname?
2010/10/12 James Antill james@fedoraproject.org
On Tue, 2010-10-12 at 16:00 +0100, Bastien Nocera wrote:
On Mon, 2010-10-11 at 11:11 -0400, Chris Lumens wrote:
- suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch)
If DNS knows a hostname, we will suggest that. Of course it's not foolproof.
That's not it. Your name is entered (Chris Lumens) and from it you should get a hostname (chris-lumens-fedora-desktop.local) as well as a presentation name ("Chris Lumens' Fedora Desktop") which could be used for things like services being advertised through avahi, or even the default name for the Bluetooth adapters.
The Mac does this too, and I'm sure it's great for avahi stuff ... but it's really annoying for anyone using the hostname anywhere else (mainly due to the expected size). Is there nowhere else that we could store a "hostsummary" instead of hostname?
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I believe anaconda is Ok, But many users complain about it, I honestly can't understand why. What I can undersand and even say is that anaconda needs a little "more polished" experience.
I mean, in the "look part" Fedora needs a re-birthday, we use same graphics combination in anaconda, the same Gnome theme, the same themes to pick for (gtk) and mostly the same that when Fedora started.
I believe we need to polish that look part, as far as I understand an O.S. Needs to be newer in each new version not only in features, but also in look. If we can give that to users, discussions like these ones will be present in a fewer number.
On 10/12/2010 10:35 PM, Manuel Escudero wrote:
2010/10/12 James Antill <james@fedoraproject.org mailto:james@fedoraproject.org>
On Tue, 2010-10-12 at 16:00 +0100, Bastien Nocera wrote: > On Mon, 2010-10-11 at 11:11 -0400, Chris Lumens wrote: > > > - suggests a username and hostname based on the user's real name > > > (Mac OS X's installer also does this -- it's a nice touch) > > > > If DNS knows a hostname, we will suggest that. Of course it's not > > foolproof. > > That's not it. Your name is entered (Chris Lumens) and from it you > should get a hostname (chris-lumens-fedora-desktop.local) as well as a > presentation name ("Chris Lumens' Fedora Desktop") which could be used > for things like services being advertised through avahi, or even the > default name for the Bluetooth adapters. The Mac does this too, and I'm sure it's great for avahi stuff ... but it's really annoying for anyone using the hostname anywhere else (mainly due to the expected size). Is there nowhere else that we could store a "hostsummary" instead of hostname? -- devel mailing list devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/develI believe anaconda is Ok, But many users complain about it, I honestly can't understand why.
because it's ugly. among ALL installers that I've used ( mint / debian / suse >=9 ) anaconda has the ugliest user interface. And I mean all versions that I ever used , in RH ( pre-RHEL era), Centos and Fedora.
What I can undersand and even say is that anaconda needs a little "more polished" experience.
exactly. there are tons of facilities but the aspect "could be improved"
On Mon, 2010-10-11 at 11:41 +0100, Richard W.M. Jones wrote:
I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky.
Some of the things it does which are IMHO better:
starts disk formatting / copying / installing in parallel with asking user questions
downloads updates in parallel too
uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time)
suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch)
This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area.
Thoughts? Can we switch to their installer?
Rich.
Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing 747. Sure, both can accomplish the same task. Read: transporting people from one airport to another, but lets see you try transporting 400 peoples from London to NY using a Cessna...
The same logic applies to the Ubuntu installer: As long as you require a fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no fancy setup source [nfs, dvd, http], -very- basic encryption, standard software set and repository selection, etc), the Ubuntu installer is a great tool, but once you need something complex, you're screwed.
- Gilboa
On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote:
Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing 747. Sure, both can accomplish the same task. Read: transporting people from one airport to another, but lets see you try transporting 400 peoples from London to NY using a Cessna...
The same logic applies to the Ubuntu installer: As long as you require a fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no fancy setup source [nfs, dvd, http], -very- basic encryption, standard software set and repository selection, etc), the Ubuntu installer is a great tool, but once you need something complex, you're screwed.
That's all true. I've found the Ubuntu installer looks /very/ polished and nice for very common install cases, but I always use LVM on every install that I do, and last time I did a VM install of Ubuntu, I had to switch to a VT and get LVM sorted on the command line. Not super user friendly as compared with Anaconda. Other installers were even more of a joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and VNC do really matter, and not just for "Enterprise" users. You don't need to use LVM w/wo RAID, you can just do bare partitions if you don't care about being able to do anything useful with your disks at all :)
Jon.
On Mon, 2010-10-11 at 12:09 -0400, Jon Masters wrote:
On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote:
Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing 747. Sure, both can accomplish the same task. Read: transporting people from one airport to another, but lets see you try transporting 400 peoples from London to NY using a Cessna...
The same logic applies to the Ubuntu installer: As long as you require a fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no fancy setup source [nfs, dvd, http], -very- basic encryption, standard software set and repository selection, etc), the Ubuntu installer is a great tool, but once you need something complex, you're screwed.
That's all true. I've found the Ubuntu installer looks /very/ polished and nice for very common install cases, but I always use LVM on every install that I do, and last time I did a VM install of Ubuntu, I had to switch to a VT and get LVM sorted on the command line. Not super user friendly as compared with Anaconda. Other installers were even more of a joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and VNC do really matter, and not just for "Enterprise" users. You don't need to use LVM w/wo RAID, you can just do bare partitions if you don't care about being able to do anything useful with your disks at all :)
Amen to that. Given the absurdly cheap price of HD these days, I usually opt for LVM over software RAID1 / RAID5 on each and every workstation machine I install. Achieving the same using the Ubuntu installer would have required a lot of manual mdadm and lvm pv/vg/lv** commands. (Let alone their basic disk partitioning tool)
... In their race for Joe-six-pack and Apple like polish, Ubuntu gave up on many Linux core capabilities. Hopefully Fedora will -not- follow suite.
- Gilboa
- Gilboa
2010/10/11 Gilboa Davara gilboad@gmail.com:
On Mon, 2010-10-11 at 12:09 -0400, Jon Masters wrote:
On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote:
Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing 747. Sure, both can accomplish the same task. Read: transporting people from one airport to another, but lets see you try transporting 400 peoples from London to NY using a Cessna...
The same logic applies to the Ubuntu installer: As long as you require a fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no fancy setup source [nfs, dvd, http], -very- basic encryption, standard software set and repository selection, etc), the Ubuntu installer is a great tool, but once you need something complex, you're screwed.
That's all true. I've found the Ubuntu installer looks /very/ polished and nice for very common install cases, but I always use LVM on every install that I do, and last time I did a VM install of Ubuntu, I had to switch to a VT and get LVM sorted on the command line. Not super user friendly as compared with Anaconda. Other installers were even more of a joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and VNC do really matter, and not just for "Enterprise" users. You don't need to use LVM w/wo RAID, you can just do bare partitions if you don't care about being able to do anything useful with your disks at all :)
Amen to that. Given the absurdly cheap price of HD these days, I usually opt for LVM over software RAID1 / RAID5 on each and every workstation machine I install. Achieving the same using the Ubuntu installer would have required a lot of manual mdadm and lvm pv/vg/lv** commands. (Let alone their basic disk partitioning tool)
... In their race for Joe-six-pack and Apple like polish, Ubuntu gave up on many Linux core capabilities. Hopefully Fedora will -not- follow suite.
Hello,
I am doing the same setup, nice to see someone else with those requirements. actually without kickstart setting up softraid in anaconda was broken (try it manually without precreated partitions... it will drive you insane). out of the box booting didnt work when /boot was on a mirror raid and the mbr wasnt cloned either. not that great of an out of the box experience. i had those issues in f11 f12 and f13. but hey... instead of redundancy having some colored automatically selected flags and languages is probably more important after all.
kind regards, Rudolf Kastl
Gilboa
Gilboa
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/12/10 7:20 AM, Rudolf Kastl wrote:
I am doing the same setup, nice to see someone else with those requirements. actually without kickstart setting up softraid in anaconda was broken (try it manually without precreated partitions... it will drive you insane). out of the box booting didnt work when /boot was on a mirror raid and the mbr wasnt cloned either. not that great of an out of the box experience. i had those issues in f11 f12 and f13. but hey... instead of redundancy having some colored automatically selected flags and languages is probably more important after all.
Have you been participating in the test days and filing bugs? We've done many raid setups, it's part of our release criteria, and we haven't ran into the issues you seem to be describing above.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
2010/10/12 Jesse Keating jkeating@redhat.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/12/10 7:20 AM, Rudolf Kastl wrote:
I am doing the same setup, nice to see someone else with those requirements. actually without kickstart setting up softraid in anaconda was broken (try it manually without precreated partitions... it will drive you insane). out of the box booting didnt work when /boot was on a mirror raid and the mbr wasnt cloned either. not that great of an out of the box experience. i had those issues in f11 f12 and f13. but hey... instead of redundancy having some colored automatically selected flags and languages is probably more important after all.
Have you been participating in the test days and filing bugs? We've done many raid setups, it's part of our release criteria, and we haven't ran into the issues you seem to be describing above.
Let me clarify. On the criteria page i read (have to dig out the link) it said that bugs regarding having /boot on softraid are ignored at this point, so no i didnt bother filing a report. sounded like a known issue. As for the test day. Really, i always try to help out on test days but i guess i was too busy/on the road when this one happened. Manually setting up softraids with mdadm works like a charm btw. What is problematic is setting up the correct partition layout manually with 2 drives because anaconda moves around and reenumberates the partitions when you add new ones. (that drove me to insanity.) also note that using kickstart works like a charm aswell.
in the notes i only found: http://fedoraproject.org/wiki/Common_F13_bugs#Booting_from_an_mdraid_mirror_...
Atleast on the f12 install this also failed with a seperate boot. I am going to keep my eyes open for f14 and doing an install with the current f14 state soon to see which of those issues is still left and file appropriate reports regarding the open issues. I am really curious also if it will automatically make both disks of the mirror setup bootable (writing grub to both mbrs).
kind regards, Rudolf Kastl
kind regards, Rudolf Kastl
Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAky0eG4ACgkQ4v2HLvE71NV3hACgq6Wuii5Vue4Kg7ZI4hkfFJ5J qGMAoJ3/hd/jzljK+OUlgE/SbR9l1iaz =lxeC
-----END PGP SIGNATURE-----
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/13/10 2:04 AM, Rudolf Kastl wrote:
Let me clarify. On the criteria page i read (have to dig out the link) it said that bugs regarding having /boot on softraid are ignored at this point, so no i didnt bother filing a report. sounded like a known issue. As for the test day. Really, i always try to help out on test days but i guess i was too busy/on the road when this one happened. Manually setting up softraids with mdadm works like a charm btw. What is problematic is setting up the correct partition layout manually with 2 drives because anaconda moves around and reenumberates the partitions when you add new ones. (that drove me to insanity.) also note that using kickstart works like a charm aswell.
in the notes i only found: http://fedoraproject.org/wiki/Common_F13_bugs#Booting_from_an_mdraid_mirror_...
Atleast on the f12 install this also failed with a seperate boot. I am going to keep my eyes open for f14 and doing an install with the current f14 state soon to see which of those issues is still left and file appropriate reports regarding the open issues. I am really curious also if it will automatically make both disks of the mirror setup bootable (writing grub to both mbrs).
Ok, so what you're saying is, that the specific case of having /boot on softraid didn't work for you. I may have missed that clarification in your first email. I do find it odd because I constantly test scenarios where /boot is a small mirror and / is a large stripe and it seems to work every time for me, often starting from blank disks. I'll test that scenario again soon, maybe there is something I'm doing that you're not, or vice versa?
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On Wed, Oct 13, 2010 at 02:28:05AM -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/13/10 2:04 AM, Rudolf Kastl wrote:
Let me clarify. On the criteria page i read (have to dig out the link) it said that bugs regarding having /boot on softraid are ignored at this point, so no i didnt bother filing a report. sounded like a known issue.
Ok, so what you're saying is, that the specific case of having /boot on softraid didn't work for you. I may have missed that clarification in your first email. I do find it odd because I constantly test scenarios where /boot is a small mirror and / is a large stripe and it seems to work every time for me, often starting from blank disks. I'll test that scenario again soon, maybe there is something I'm doing that you're not, or vice versa?
I encountered this problem when using preupgrade. This is already filled in bugzilla, ate least those two: - preupgrade doesn't work with software raided /boot https://bugzilla.redhat.com/show_bug.cgi?id=444497 - preupgrade/anaconda can't use install.img (stage2) on RAID https://bugzilla.redhat.com/show_bug.cgi?id=500004
2010/10/13 Jesse Keating jkeating@redhat.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/13/10 2:04 AM, Rudolf Kastl wrote:
Let me clarify. On the criteria page i read (have to dig out the link) it said that bugs regarding having /boot on softraid are ignored at this point, so no i didnt bother filing a report. sounded like a known issue. As for the test day. Really, i always try to help out on test days but i guess i was too busy/on the road when this one happened. Manually setting up softraids with mdadm works like a charm btw. What is problematic is setting up the correct partition layout manually with 2 drives because anaconda moves around and reenumberates the partitions when you add new ones. (that drove me to insanity.) also note that using kickstart works like a charm aswell.
in the notes i only found: http://fedoraproject.org/wiki/Common_F13_bugs#Booting_from_an_mdraid_mirror_...
Atleast on the f12 install this also failed with a seperate boot. I am going to keep my eyes open for f14 and doing an install with the current f14 state soon to see which of those issues is still left and file appropriate reports regarding the open issues. I am really curious also if it will automatically make both disks of the mirror setup bootable (writing grub to both mbrs).
Ok, so what you're saying is, that the specific case of having /boot on softraid didn't work for you. I may have missed that clarification in your first email. I do find it odd because I constantly test scenarios where /boot is a small mirror and / is a large stripe and it seems to work every time for me, often starting from blank disks. I'll test that scenario again soon, maybe there is something I'm doing that you're not, or vice versa?
hmm could be. actually what i do is i create 2 partitions on each disk ( for /boot and the rest) and then i softraid each pair and put lvm on top of the non /boot md of course due to the limitations of legacy grub (raid 10 would be faster but... i like the lvm functionality). All raid setups are simple mirrors with 2 disks. I already had the trouble that the partition enumberation would change numbers and order during creating the partitions (to workaround that i precreated the partitions before starting the installer). after completing an install like that the system refused to boot (as far as i remember when it was supposed to read and handle the initrd.) i was assuming that it maybe doesent have the raid modules loaded or not available in the initramfs, but this is just a guess, i cannot remember really.
what succeeded was... installing the os on one disk using lvm (/boot / /home swap). creating the mdraid with missing instead the first disk on the second physical hds partitions. then adding the md devices to the vg and pvmoving the first physical disk out... later adding the disk in the "missing" slot of the md and also mirror raiding the /boot partition followed by an update of the initramfs.
kind regards, Rudolf Kastl
Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAky1e6IACgkQ4v2HLvE71NWecQCfYDJpbd3O69EMAKUGJZ6nM2dh 56QAn1uSq+WNs9NzspcWU1zV/EGGwIXf =MPSn
-----END PGP SIGNATURE-----
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 2010-10-13 at 02:28 -0700, Jesse Keating wrote:
Ok, so what you're saying is, that the specific case of having /boot on softraid didn't work for you. I may have missed that clarification in your first email. I do find it odd because I constantly test scenarios where /boot is a small mirror and / is a large stripe and it seems to work every time for me, often starting from blank disks. I'll test that scenario again soon, maybe there is something I'm doing that you're not, or vice versa?
As I recall it, Jesse, Rudolf's right - there are known issues with having /boot on a soft RAID and that's why it's explicitly excluded from the release criteria. Unfortunately it's sufficiently long since FUDCon Toronto that I can't recall what the known issues were exactly, but anaconda team may.
On Wed, 13 Oct 2010 08:23:23 -0700 Adam Williamson awilliam@redhat.com wrote:
On Wed, 2010-10-13 at 02:28 -0700, Jesse Keating wrote:
Ok, so what you're saying is, that the specific case of having /boot on softraid didn't work for you. I may have missed that clarification in your first email. I do find it odd because I constantly test scenarios where /boot is a small mirror and / is a large stripe and it seems to work every time for me, often starting from blank disks. I'll test that scenario again soon, maybe there is something I'm doing that you're not, or vice versa?
As I recall it, Jesse, Rudolf's right - there are known issues with having /boot on a soft RAID and that's why it's explicitly excluded from the release criteria. Unfortunately it's sufficiently long since FUDCon Toronto that I can't recall what the known issues were exactly, but anaconda team may.
pre-upgrade doesn't work if boot is on raid. I don't remember other issues when you install from disk.
Simo.
Hello,
I am doing the same setup, nice to see someone else with those requirements. actually without kickstart setting up softraid in anaconda was broken (try it manually without precreated partitions... it will drive you insane). out of the box booting didnt work when /boot was on a mirror raid and the mbr wasnt cloned either. not that great of an out of the box experience. i had those issues in f11 f12 and f13. but hey... instead of redundancy having some colored automatically selected flags and languages is probably more important after all.
kind regards, Rudolf Kastl
When installing Fedora on machine with -large- amount of drives (8-16), I simply use a single sfdisk script to create the same partition table on all drives. When dealing with smaller configurations (3-4 drives), Anaconda is OK. (At least to me)
As for MBR: I assume that like me, you create a small RAID1 for /boot and RAIDX for the rest, hoping the first disk won't die on a DVD-less machine :) In-order to solve it (when I remember to do it :)), I simply dd 446 bytes from the first drive to every other drive.
- Gilboa
On 10/13/2010 10:53 AM, Gilboa Davara wrote:
When installing Fedora on machine with -large- amount of drives (8-16), I simply use a single sfdisk script to create the same partition table on all drives. When dealing with smaller configurations (3-4 drives), Anaconda is OK. (At least to me)
As for MBR: I assume that like me, you create a small RAID1 for /boot and RAIDX for the rest, hoping the first disk won't die on a DVD-less machine :) In-order to solve it (when I remember to do it :)), I simply dd 446 bytes from the first drive to every other drive.
Just curious: you script the creation of an identical partition table, and then you copy 446 bytes which specifically copies the MBR without the partition table which is in bytes 447-512. Why not just copy the entire 512 bytes to all the disks from the first one?
I guess one reason might be if the disks did not have identical CHS geometry, which can happen for the identically sized disks. I have heard rumors that even a single model drives had been seen with different geometries in different firmware revisions.
On Wed, 2010-10-13 at 11:50 -0400, Przemek Klosowski wrote:
Just curious: you script the creation of an identical partition table, and then you copy 446 bytes which specifically copies the MBR without the partition table which is in bytes 447-512. Why not just copy the entire 512 bytes to all the disks from the first one? I guess one reason might be if the disks did not have identical CHS geometry, which can happen for the identically sized disks. I have heard rumors that even a single model drives had been seen with different geometries in different firmware revisions.
I'm paranoid, that why :) While in most machines, I have identical drives from the same manufacturer, in others, I specifically buy drive of the same size, but from different manufacturers and even different dates to reduce the risk of simultaneous death of multiple drives. (Same drive, same manufacturer, same batch, same day, etc) As you pointed out, different drives, can have more-or-less identical partition size, with different CHS in the partition table.
As I don't trust myself to use the -right- size every time (446 vs 512), I simply assume the worse.
Hi.
On Wed, 13 Oct 2010 22:26:18 +0200, Gilboa Davara wrote
As you pointed out, different drives, can have more-or-less identical partition size, with different CHS in the partition table.
I my experience the hard disk vendors have been astonishingly coordinated in how much sectors a drive of a given size should have.
On Wed, 2010-10-13 at 23:51 +0200, Ralf Ertzinger wrote:
Hi.
On Wed, 13 Oct 2010 22:26:18 +0200, Gilboa Davara wrote
As you pointed out, different drives, can have more-or-less identical partition size, with different CHS in the partition table.
I my experience the hard disk vendors have been astonishingly coordinated in how much sectors a drive of a given size should have.
... My experience is somewhat different, but as I said, I'm paranoid :)
- Gilboa
On 10/13/2010 05:51 PM, Ralf Ertzinger wrote:
Hi.
On Wed, 13 Oct 2010 22:26:18 +0200, Gilboa Davara wrote
As you pointed out, different drives, can have more-or-less identical partition size, with different CHS in the partition table.
I my experience the hard disk vendors have been astonishingly coordinated in how much sectors a drive of a given size should have.
Total numbers of sectors may be the same---but the way the partitions are defined in the partition table requires the use of correct CHS disk geometry. Of course modern disks don't even have a well-defined physical geometry---the number of sectors per cylinder varies between the inner and outer tracks---but they still must declare one as a weird historical artifact required by the BIOS and traditional partition table layout. The manufacturers lie about it, e.g. declaring dozens of heads, but what's worse different manufacturers lie about it differently.
Warning: what follows is boring and geeky, and might be wrong because a) I haven't worked with this stuff for a while now and b) things change as the disks get biger and newer.
The reason the partition table has to represent the partition boundaries not as a Linear Block Address (LBA) sector count but as a Cylinder/Head/Sector coordinates, is because the BIOS booting code uses CHS access method. If those numbers assume wrong disk geometry then the partition ends up being non-contiguous because IIRC, the calculation from CHS to LBA goes somehow like this:
LBA = c * (H*S) + h * S + s
where c, h, s are the CHS coordinates of a partition in the partition table, and C, H and S are the total 'reported' number of cylinders, heads and sectors on the drive. If you copy the chs numbers without converting them for the different CHS geometry, you will get different and wrong LBA addresses, i.e. different partitioning.
On 10/11/2010 06:09 PM, Jon Masters wrote:
On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote:
Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing 747. Sure, both can accomplish the same task. Read: transporting people from one airport to another, but lets see you try transporting 400 peoples from London to NY using a Cessna...
The same logic applies to the Ubuntu installer: As long as you require a fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no fancy setup source [nfs, dvd, http], -very- basic encryption, standard software set and repository selection, etc), the Ubuntu installer is a great tool, but once you need something complex, you're screwed.
That's all true. I've found the Ubuntu installer looks /very/ polished and nice for very common install cases, but I always use LVM on every install that I do, and last time I did a VM install of Ubuntu, I had to switch to a VT and get LVM sorted on the command line. Not super user friendly as compared with Anaconda. Other installers were even more of a joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and VNC do really matter, and not just for "Enterprise" users. You don't need to use LVM w/wo RAID, you can just do bare partitions if you don't care about being able to do anything useful with your disks at all :)
imho, the never drop any feature since raid, lvm, iscsi are important (what's more i use them:-), BUT most user don't ie. 80% of the users never use them. it can be an "advanced" installer option for us, and a "basic" for average user. the other point of richards is what the whole fedora community and redhat should have to understand: "most users like ubuntu rather then fedora/redhat". why? because: - it's looks better. every component looks better, installer, default gnome themes etc. we can make a long discussion about which is better but our opinion simple do not count. better is what most user like. period. - it's easier to use. for average user it's the most important thing. we can always have an advance and basic settings.
wouldn't be useful to ask users which they like and try to make fedora/redhat's component better?
just my 2c.
On Monday 11 October 2010 23:44:01 Farkas Levente wrote:
but our opinion simple do not count. better is what most user like. period.
We all know that's not true. In an ideal world the best things would also be those with the most success. Sadly, in reality this doesn't apply. Just look what the most popular newspapers are. Do you really want to tell me these are the ones offering the highest quality journalism available? At least where I live, the most popular newspapers are also those most full of crap. In the best case they just write trivial nonsense, whereas most of the time they use their popularity to push their own agenda. Nevertheless they sell most of the copies, whereas many papers used to be known for their high quality are struggling for their existence. No, in reality there is not always a correlation between popularity and quality.
Obviously, this doesn't mean that popularity is bad. But when the price we have to pay for being popular is heavy (i.e. doing something that makes Fedora inferior from a technical point of view) this should be well considered.
Speaking frankly, I want to help making an operating system that is excellent in technical terms. Popularity is certainly nice to have, but when it requires actions that are contrary to technical excellence it clearly comes second. I don't want to do anything against better judgement. As long as Fedora doesn't depend on selling as much copies as possible I think that's an reasonable approach. But that's just my humble opinion. Everybody is free to have their own.
Lars.
the other point of richards is what the whole fedora community and redhat should have to understand: "most users like ubuntu rather then fedora/redhat". why? because: -... better is what most user like. period.
Following your simplistic logic, we should mimic the Windows Vista/7 UAC (Even if it's insecure by design) or even consider running as root by default, why? - Usage-wise, Windows XP is the leading OS in the world, and 99% of all Windows XP users are running as administrator. (Most don't even bother to use password protected administrator-capable user accounts) - Windows 7 will most likely overtake Windows XP in 2-3 years and it's using UAC by default.
I assume that I do really need point out -why- this logic is flawed... Different operating system target different user bases and usage cases. Different Linux distributions target different user bases and usage cases.
At least the last time I checked, Fedora -didn't- target Joe-six-pack as its primary target user base (Let alone RHEL, which shares the same Anaconda code).
- Gilboa
On 10/12/2010 09:53 AM, Gilboa Davara wrote:
the other point of richards is what the whole fedora community and redhat should have to understand: "most users like ubuntu rather then fedora/redhat". why? because: -... better is what most user like. period.
Following your simplistic logic, we should mimic the Windows Vista/7 UAC (Even if it's insecure by design) or even consider running as root by default, why?
with "better" i simple refer here to the style (ie. which one looks better) it's nothing to do functionality or security. of course if you wouldn't like to understand that's a different story.
ps. and yes most of the case windows and windows apps looks better the linux and we'd have to learn a lot from them.
Le Lun 11 octobre 2010 23:44, Farkas Levente a écrit :
imho, the never drop any feature since raid, lvm, iscsi are important (what's more i use them:-), BUT most user don't ie. 80% of the users never use them.
If you fail one way or another 20% of users you fail period. That's not an acceptable failure rate for something like the installer everyone has to use at a time.
2010/10/11 Richard W.M. Jones rjones@redhat.com:
I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky.
Some of the things it does which are IMHO better:
- starts disk formatting / copying / installing in parallel with asking user questions
- downloads updates in parallel too
- uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time)
- suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch)
This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area.
Thoughts?
Which of these functions can not be implemented in anaconda?
Can we switch to their installer?
Does it support text based minimal install?
Rich.
Regards, Michal
Shipping 2 different installers is a recipe for disaster from a user and QA perspective.Choose one between Ubiquity, Debian-installer and Anaconda.
We only ship one installer, and that is anaconda. I suppose you could argue over whether livecd is its own thing or not, but that's a nitpicky detail.
- Chris
On Tue, Oct 12, 2010 at 12:12:35AM +0200, Emmanuel Seyman wrote:
- Matthew Garrett [11/10/2010 19:57] :
debian-installer? Yes.
Shipping 2 different installers is a recipe for disaster from a user and QA perspective.Choose one between Ubiquity, Debian-installer and Anaconda.
Ubiquity is a graphical interface built on top of the debian-installer framework.
On 10/11/2010 03:41 AM, Richard W.M. Jones wrote:
Some of the things [Ubuntu 10.10 installer] does which are IMHO better:
starts disk formatting / copying / installing in parallel with asking user questions
downloads updates in parallel too
What was the wall-clock duration from "Go!" to done? Should be about 140 seconds for a 32X CD-ROM: (700MB / 5MB/s). {Fetch_from_media_or_download, and uncompress_package_to_pieces_in_RAMfs} parallelizes almost perfectly with package install, even with only one CPU.
--
I think anaconda is better than ubuntu installer.
Ubuntu installer does not support LVM and RAID. I need these features.
Anaconda does not easily support upgrading from internet. It is quite regretful.
On Tue, Oct 12, 2010 at 12:14 AM, John Reiser jreiser@bitwagon.com wrote:
On 10/11/2010 03:41 AM, Richard W.M. Jones wrote:
Some of the things [Ubuntu 10.10 installer] does which are IMHO better:
starts disk formatting / copying / installing in parallel with asking user questions
downloads updates in parallel too
What was the wall-clock duration from "Go!" to done? Should be about 140 seconds for a 32X CD-ROM: (700MB / 5MB/s). {Fetch_from_media_or_download, and uncompress_package_to_pieces_in_RAMfs} parallelizes almost perfectly with package install, even with only one CPU.
--
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2010-10-12 at 00:29 +0800, Liang Suilong wrote:
Anaconda does not easily support upgrading from internet. It is quite regretful.
Did you mean to say 'Ubuntu installer' here too? Anaconda certainly does support upgrading from the Internet. And it's *too* easy -- I often find it's using an Internet repository without even offering me the choice of using my local NFS mirror.
On Mon, Oct 11, 2010 at 11:41:13 +0100, "Richard W.M. Jones" rjones@redhat.com wrote:
Some of the things it does which are IMHO better:
- starts disk formatting / copying / installing in parallel with asking user questions
I think that is a misfeature. I don't want anything irreversible to be done until I say go.
Once upon a time, Bruno Wolff III bruno@wolff.to said:
On Mon, Oct 11, 2010 at 11:41:13 +0100, "Richard W.M. Jones" rjones@redhat.com wrote:
Some of the things it does which are IMHO better:
- starts disk formatting / copying / installing in parallel with asking user questions
I think that is a misfeature. I don't want anything irreversible to be done until I say go.
You know that Fedora has done partitioning/mkfs about halfway through the install for a while now, right? I don't see why there would be a problem with letting that run in the background while continuing through the questions.
On Mon, Oct 11, 2010 at 12:44:49 -0500, Chris Adams cmadams@hiwaay.net wrote:
I think that is a misfeature. I don't want anything irreversible to be done until I say go.
You know that Fedora has done partitioning/mkfs about halfway through the install for a while now, right? I don't see why there would be a problem with letting that run in the background while continuing through the questions.
I forget which stuff gets done afterwards, since I haven't done a fresh install for a while now. (I mostly do yum upgrades and play with live USB images.) But I do remember a clear no/no go point where disk drive file systems get formatted. Depending on the file systems being used that can take a little bit of time to complete, but is short compared to the rest of the install. I tend to do install all of the games, so my installs may take longer than average. I also always do custom disk layouts, so I might see things a bit different from people that don't do that.
On Mon, 2010-10-11 at 12:51 -0500, Bruno Wolff III wrote:
On Mon, Oct 11, 2010 at 12:44:49 -0500, Chris Adams cmadams@hiwaay.net wrote:
I think that is a misfeature. I don't want anything irreversible to be done until I say go.
You know that Fedora has done partitioning/mkfs about halfway through the install for a while now, right? I don't see why there would be a problem with letting that run in the background while continuing through the questions.
I forget which stuff gets done afterwards, since I haven't done a fresh install for a while now. (I mostly do yum upgrades and play with live USB images.) But I do remember a clear no/no go point where disk drive file systems get formatted. Depending on the file systems being used that can take a little bit of time to complete, but is short compared to the rest of the install. I tend to do install all of the games, so my installs may take longer than average. I also always do custom disk layouts, so I might see things a bit different from people that don't do that.
In fairness to Rich, I think it's easy to get carried away with how technicall better we are, but we shouldn't totally devalue the impact of the shiny gloss on some users, reviews, and on general perception.
I used to be technical editor for a Linux magazine and I've read more than my fair share of reviews of distributions over the years (and written some too, it has to be admitted). Here's how it seems to go all too often in general: 10% background, 30-40% installation, 20% what got installed, then everything else. It's because reviewers are busy, and don't have time to know a community - so first impressions count. And Ubuntu is "known to be cool", so they get extra points in any case.
Sadly enough, this means that a shiny Ubuntu installer is to the whole distribution what GNOME shell is to the GNOME project. It doesn't matter if you've got a lot of bells and whistles underneath, or what you can do, if you don't look pretty while you do it. It's just the reality. I would venture that one of the reasons Rich sent his mail originally is that he's aware of this mentality and pointing out its effects.
Jon.
On Mon, 2010-10-11 at 15:44 -0400, Jon Masters wrote:
Sadly enough, this means that a shiny Ubuntu installer is to the whole distribution what GNOME shell is to the GNOME project. It doesn't matter if you've got a lot of bells and whistles underneath, or what you can do, if you don't look pretty while you do it. It's just the reality. I would venture that one of the reasons Rich sent his mail originally is that he's aware of this mentality and pointing out its effects.
You forgot to qualify the above paragraph: it doesn't matter _to a distribution reviewer_. We aren't necessarily making Fedora for distribution reviewers.
On Mon, 2010-10-11 at 19:23 -0700, Adam Williamson wrote:
On Mon, 2010-10-11 at 15:44 -0400, Jon Masters wrote:
Sadly enough, this means that a shiny Ubuntu installer is to the whole distribution what GNOME shell is to the GNOME project. It doesn't matter if you've got a lot of bells and whistles underneath, or what you can do, if you don't look pretty while you do it. It's just the reality. I would venture that one of the reasons Rich sent his mail originally is that he's aware of this mentality and pointing out its effects.
You forgot to qualify the above paragraph: it doesn't matter _to a distribution reviewer_. We aren't necessarily making Fedora for distribution reviewers.
But impressions that get spread around do tend to haunt you.
The most technically-superior solution unfortunately doesn't always enjoy the popularity it could have. (e.g. Beta max :) )
~m
On 10/11/2010 08:51 PM, Bruno Wolff III wrote:
On Mon, Oct 11, 2010 at 12:44:49 -0500, Chris Adams cmadams@hiwaay.net wrote:
I think that is a misfeature. I don't want anything irreversible to be done until I say go.
You know that Fedora has done partitioning/mkfs about halfway through the install for a while now, right? I don't see why there would be a problem with letting that run in the background while continuing through the questions.
I forget which stuff gets done afterwards, since I haven't done a fresh install for a while now. (I mostly do yum upgrades and play with live USB images.) But I do remember a clear no/no go point where disk drive file systems get formatted. Depending on the file systems being used that can take a little bit of time to complete, but is short compared to the rest of the install.
Actually formatting a large partition ( and >=1 TB disks are becoming more and more frequent) DOES take enough time to go boil a coffee.
On 10/11/10 19:31, Bruno Wolff III wrote:
On Mon, Oct 11, 2010 at 11:41:13 +0100, "Richard W.M. Jones"rjones@redhat.com wrote:
Some of the things it does which are IMHO better:
- starts disk formatting / copying / installing in parallel with asking user questions
I think that is a misfeature. I don't want anything irreversible to be done until I say go.
I always liked the way suse does the install. It comes up with a *single* overview screen showing *everything* it suggests to do (partitioning, packages to install, some basic settings, ...). Then you can go and change stuff if you want, and after changing settings it goes back to the overview screen, showing what it would do now after applying your changes. This way you are not bothered with lots of interactive questions but still have the option to change everything as you like if you want. When you are happy with everything you say 'go!' and it goes. It doesn't touch your hard disk before.
Anaconda goes though everything step-by-step instead, asking one question after another, doing some work inbetween (partitining), asking more questions (packages to install) ...
Dunno how hard it would be to change anaconda to have such an overview screen. Maybe it isn't *that* hard after all as we have kickstart. So for a interactive install anaconda could collect all info from the user, compile a kickstart file from that, then feed the install machinery with the just-generated kickstart file.
Anaconda can try to figure reasonable defaults. Using geoip. By inspecting the hardware. Have 'klick here to change' buttons to change things, which can probably handled by the existing screens for timezone / keyboard / ... selection. Maybe even reading stuff from a kickstart file and present it in the overview, so you could stick your favorite non-default settings there.
cheers Gerd
Anaconda goes though everything step-by-step instead, asking one question after another, doing some work inbetween (partitining), asking more questions (packages to install) ...
We have worked a little to reduce this over time, too. If you remember we used to have a confirmation screen after picking your packages. The result of that was that many people would click Next, go away to do something thinking packages were being installed, then come back much later only to see that the confirmation screen is still there.
But yes, there is always more to do.
Dunno how hard it would be to change anaconda to have such an overview screen. Maybe it isn't *that* hard after all as we have kickstart. So for a interactive install anaconda could collect all info from the user, compile a kickstart file from that, then feed the install machinery with the just-generated kickstart file.
We have talked about doing just this. I don't imagine it's terribly difficuly, with the exception of storage.
- Chris
On Monday 11 October 2010 12:41:13 Richard W.M. Jones wrote:
This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area.
Thoughts? Can we switch to their installer?
Rich.
It may be nice usability-wise but it lacks support for LVM2, LUKS disk encryption and practically everything more advanced. It can't be automated using some equivalent to kickstart and it fails at all the stuff Anaconda subsumes unter "advanced storage devices". You can't even do the install from some remote place without setting anything up by hand. Ubuntu users requiring more than these very basic features have to go for the Debian text mode installer Ubuntu ships on their alternate media.
Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users.
So I don't think it's a good idea to switch to this, even if it was trivially possible to use with Fedora. But there's nothing preventing us to take the ubiquity features we enjoy most and enable Anaconda to do something similar.
Lars.
Hi,
Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users.
We don't have to make things inferior to improve usability. To stick with the "advanved storage" example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named "local storage" and "SAN storage". Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users.
cheers, Gerd
On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
Hi,Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users.
We don't have to make things inferior to improve usability. To stick with the "advanved storage" example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named "local storage" and "SAN storage". Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users.
If you want to appeal to the same audience Ubuntu is going for then you have to remove choice. The whole storage bit needs to be completely removed or at least stripped down. "advanced storage" certainly has to disappear completely. The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one.
You cannot make two distinct target audiences happy with one workflow especially if one of those groups requires a limitation of choice.
Regards, Dennis
On 10/12/2010 02:16 PM, Dennis Jacobfeuerborn wrote:
On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
Hi,Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users.
We don't have to make things inferior to improve usability. To stick with the "advanved storage" example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named "local storage" and "SAN storage". Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users.
If you want to appeal to the same audience Ubuntu is going for then you have to remove choice.
Why? All that would be required would be to move it out of this audience's way (the "defaults").
As Gerd mentioned in another mail, SUSE's installer seems interesting wrt. this. Its "defaults" cater the demands of "uneducated desktop installers", while still allows many kinds of complex setups outside of the "defaults" in "advanced menus".
Apart of what Gerd already said, SUSE's installer also comes with clever GUI-implementation details, which I think might be worth a look into for the anaconda folks ;)
Ralf
On 10/12/2010 02:52 PM, Ralf Corsepius wrote:
On 10/12/2010 02:16 PM, Dennis Jacobfeuerborn wrote:
On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
Hi,Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users.
We don't have to make things inferior to improve usability. To stick with the "advanved storage" example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named "local storage" and "SAN storage". Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users.
If you want to appeal to the same audience Ubuntu is going for then you have to remove choice.
Why? All that would be required would be to move it out of this audience's way (the "defaults").
Now we are really talking semantics. The point is that users should not be confronted with choices they don't really need to make or they don't understand.
As Gerd mentioned in another mail, SUSE's installer seems interesting wrt. this. Its "defaults" cater the demands of "uneducated desktop installers", while still allows many kinds of complex setups outside of the "defaults" in "advanced menus".
As long as most of these defaults and menus are not displayed initially that would probably be fine. The problem here is that every time you present the user with data dumps (e.g. lists of defaults) or menus you create a cognitive hurdle where the user wonders what he's supposed to do or gets worried that he breaks something. Minimizing that is really key to creating a streamlined installation interface.
The second aspect is that you want to talk to the user in terms of his "problem" and not in terms of the underlying technology. For example a user wants to either replace the current System completely or install the distribution into free space on his HD and but into either the old or the new installed system. The user doesn't care at all about "partitions", "LVM" or "mountpoints". This is different from the more apt user who wants to actually have control over these details (where exactly to put partition(s) on the disk for example).
The issue here is that keeping these advanced features available could have a negative impact on the "easy-mode" experience. If you manage to prevent that from happening than more power to you but if not then creating two distinct workflows is really the only option.
Regards, Dennis
On Tuesday 12 October 2010 15:56:02 Dennis Jacobfeuerborn wrote:
Now we are really talking semantics. The point is that users should not be confronted with choices they don't really need to make or they don't understand.
I disagree. How should a user know about some nice feature if its whole existence is hidden from his eyes? Yeah, he should read the documentation but aren't we talking about improving usability right now? Imagine some random user does his installs the hard way for years and now discovers (someone tells him oder he learns about it by chance by searching the documentation for an unrelated problem) that Anaconda has the capabilities to make his life easier.
He goes like: "Woow cool, this is the stuff I've been searching for years. I don't have to waste my precious time anymore by setting all of this up by hand. Anaconda now takes care of it. Didn't thought those Anaconda developers are that genious. But why on earth didn't they tell me before their software was capable of doing that? Do they actually like watching people suffer? Seriously, you guys suck!"
Hiding features doesn't have to be beneficial to usability. It can be harmful, too.
As long as most of these defaults and menus are not displayed initially that would probably be fine. The problem here is that every time you present the user with data dumps (e.g. lists of defaults) or menus you create a cognitive hurdle where the user wonders what he's supposed to do or gets worried that he breaks something. Minimizing that is really key to creating a streamlined installation interface.
There are other ways to prevent confusion and worries about potential brokenness. If there are sane defaults and it is clearly communicated to the user that using those is the recommended way and gives him the best results in most cases, I don't see a problem. If users can trust in those defaults being sane and that by not touching them they get a good default configuration, they aren't helpless as they know what to do. However, if they wish to change something in future attempts they already know where they have to look.
new installed system. The user doesn't care at all about "partitions", "LVM" or "mountpoints".
I think you are strongly limiting the definition of what an user can be. So who is an user of Anaconda? For me, that is all those people using Anaconda. There is some guy from your neighborhood installing Fedora to surf the internet. There is some developer installing Fedora to work on the latest and greatest software in the GNU/Linux/X/freedesktop.org stack. There are designers using Anaconda to install the free software they need to create your favorite layout. There are also sysadmins deploying Fedora/RHEL/CentOS to many computers in their company, a public school or at your ISP's datacenter. So when you restrict Anaconda's userbase to just one kind of user, the whole assumption on which you build your enhancements to usability is wrong and will lead to software which sucks in usability as soon as you want to do something that you didn't consider basic enough to show it to users.
Lars.
On 10/14/2010 06:32 PM, Lars Seipel wrote:
On Tuesday 12 October 2010 15:56:02 Dennis Jacobfeuerborn wrote:
Now we are really talking semantics. The point is that users should not be confronted with choices they don't really need to make or they don't understand.
I disagree. How should a user know about some nice feature if its whole existence is hidden from his eyes? Yeah, he should read the documentation but aren't we talking about improving usability right now? Imagine some random user does his installs the hard way for years and now discovers (someone tells him oder he learns about it by chance by searching the documentation for an unrelated problem) that Anaconda has the capabilities to make his life easier.
He goes like: "Woow cool, this is the stuff I've been searching for years. I don't have to waste my precious time anymore by setting all of this up by hand. Anaconda now takes care of it. Didn't thought those Anaconda developers are that genious. But why on earth didn't they tell me before their software was capable of doing that? Do they actually like watching people suffer? Seriously, you guys suck!"
Yet most of this can be done in a much better way *after* the installation. I'm not sure why you think cramming as many features as possible into anaconda is a good idea. Once you've got the desktop running you have way better means to advertise features to the user.
Hiding features doesn't have to be beneficial to usability. It can be harmful, too.
Clearly if we wanted to hide *everything* we would not require a user interface at all but some choices need to be made. The point is that a lot of the stuff you apparently have in mind don't actually need to happen during the installation but can happen for example as part of the first-boot configuration.
As long as most of these defaults and menus are not displayed initially that would probably be fine. The problem here is that every time you present the user with data dumps (e.g. lists of defaults) or menus you create a cognitive hurdle where the user wonders what he's supposed to do or gets worried that he breaks something. Minimizing that is really key to creating a streamlined installation interface.
There are other ways to prevent confusion and worries about potential brokenness. If there are sane defaults and it is clearly communicated to the user that using those is the recommended way and gives him the best results in most cases, I don't see a problem. If users can trust in those defaults being sane and that by not touching them they get a good default configuration, they aren't helpless as they know what to do. However, if they wish to change something in future attempts they already know where they have to look.
new installed system. The user doesn't care at all about "partitions", "LVM" or "mountpoints".
I think you are strongly limiting the definition of what an user can be. So who is an user of Anaconda? For me, that is all those people using Anaconda. There is some guy from your neighborhood installing Fedora to surf the internet. There is some developer installing Fedora to work on the latest and greatest software in the GNU/Linux/X/freedesktop.org stack. There are designers using Anaconda to install the free software they need to create your favorite layout. There are also sysadmins deploying Fedora/RHEL/CentOS to many computers in their company, a public school or at your ISP's datacenter. So when you restrict Anaconda's userbase to just one kind of user, the whole assumption on which you build your enhancements to usability is wrong and will lead to software which sucks in usability as soon as you want to do something that you didn't consider basic enough to show it to users.
The problem is that you insist on cramming all these people into one single group and create an installer that will make everyone happy. That's just not going to happen and it's one of the primary reason why efforts to improve things often fail. While abstraction is good there is such a thing as too much of it.
One perfect example is the idea that you can simply slap a traditional desktop on one of these new tablets or smartphones and you are done. The real genius behind what Apple accomplished wasn't some nifty technological feat or the fact that they control both hardware and software but that they recognized that these devices simply aren't traditional desktop PCs and as a result need a system that is tailored to this new world rather than simply rebranding StandardOS(tm) and putting that on there.
I think what is needed here is a similar approach were we don't try to take the current installation process and put some lipstick on it but instead recognize that the needs of Joe Sixpack who doesn't care about technology but simply want to share YouTube videos, manage his photos and browse Facebook are different from Mr. Admin who worries how he can separate his /home partition from the rest of the system to make fresh installs easier and wants to use a bridge setup so he can access his virtual machines from elsewhere.
I simply don't find the idea that we must bother Joe Sixpack with all these options simply because we *must* have a single installer that work for everyone very appealing because it makes innovation much harder.
Regards, Dennis
On 10/12/2010 03:56 PM, Dennis Jacobfeuerborn wrote:
On 10/12/2010 02:52 PM, Ralf Corsepius wrote:
On 10/12/2010 02:16 PM, Dennis Jacobfeuerborn wrote:
On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
Hi,Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users.
We don't have to make things inferior to improve usability. To stick with the "advanved storage" example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named "local storage" and "SAN storage". Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users.
If you want to appeal to the same audience Ubuntu is going for then you have to remove choice.
Why? All that would be required would be to move it out of this audience's way (the "defaults").
Now we are really talking semantics.
I don't think so.
The point is that users should not be confronted with choices they don't really need to make or they don't understand.
My point is to offer users who want choice the choices they want and not to force them into something they do not want.
As Gerd mentioned in another mail, SUSE's installer seems interesting wrt. this. Its "defaults" cater the demands of "uneducated desktop installers", while still allows many kinds of complex setups outside of the "defaults" in "advanced menus".
As long as most of these defaults and menus are not displayed initially that would probably be fine.
Please get yourself a SUSE DVD and try yourself - I was very positively surprized, esp. about SUSE's "disk partitioner's work-flow".
It is easy to use for beginners (Click-through), while it still allows complex setups.
The problem here is that every time you present the user with data dumps (e.g. lists of defaults) or menus you create a cognitive hurdle where the user wonders what he's supposed to do or gets worried that he breaks something. Minimizing that is really key to creating a streamlined installation interface.
The second aspect is that you want to talk to the user in terms of his "problem" and not in terms of the underlying technology.
Correct, ... my needs differ from that of others, ... therefore the tools being provided by a distro need to cater my needs, otherwise the distro doesn't fit my needs.
For example a user wants to either replace the current System completely or install the distribution into free space on his HD and but into either the old or the new installed system.
Correct, that some user's demand .. but definitely not all, and could not be further away from my demands.
The user doesn't care at all about "partitions", "LVM" or "mountpoints". This is different from the more apt user who wants to actually have control over these details (where exactly to put partition(s) on the disk for example).
Correct ... The latter for instance is what I had needed. I wanted to compare SUSE against Fedora. So I installed SUSE in parallel to other OSes (amongst them Fedora and Windows) on to the same machine.
If my only choice would have been erase Fedora and/or Windows, ... this distro would have disqualified itself.
The issue here is that keeping these advanced features available could have a negative impact on the "easy-mode" experience.If you manage to prevent that from happening than more power to you but if not then creating two distinct workflows is really the only option.
I can't avoid to disagree.
Spawning different installers means duplicating work and wasting resource.
Ralf
On 10/14/2010 07:05 PM, Ralf Corsepius wrote:
On 10/12/2010 03:56 PM, Dennis Jacobfeuerborn wrote:
On 10/12/2010 02:52 PM, Ralf Corsepius wrote:
On 10/12/2010 02:16 PM, Dennis Jacobfeuerborn wrote:
On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
Hi,Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users.
We don't have to make things inferior to improve usability. To stick with the "advanved storage" example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named "local storage" and "SAN storage". Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users.
If you want to appeal to the same audience Ubuntu is going for then you have to remove choice.
Why? All that would be required would be to move it out of this audience's way (the "defaults").
Now we are really talking semantics.
I don't think so.
The point is that users should not be confronted with choices they don't really need to make or they don't understand.
My point is to offer users who want choice the choices they want and not to force them into something they do not want.
As Gerd mentioned in another mail, SUSE's installer seems interesting wrt. this. Its "defaults" cater the demands of "uneducated desktop installers", while still allows many kinds of complex setups outside of the "defaults" in "advanced menus".
As long as most of these defaults and menus are not displayed initially that would probably be fine.
Please get yourself a SUSE DVD and try yourself - I was very positively surprized, esp. about SUSE's "disk partitioner's work-flow".
It is easy to use for beginners (Click-through), while it still allows complex setups.
The problem here is that every time you present the user with data dumps (e.g. lists of defaults) or menus you create a cognitive hurdle where the user wonders what he's supposed to do or gets worried that he breaks something. Minimizing that is really key to creating a streamlined installation interface.
The second aspect is that you want to talk to the user in terms of his "problem" and not in terms of the underlying technology.
Correct, ... my needs differ from that of others, ... therefore the tools being provided by a distro need to cater my needs, otherwise the distro doesn't fit my needs.
For example a user wants to either replace the current System completely or install the distribution into free space on his HD and but into either the old or the new installed system.
Correct, that some user's demand .. but definitely not all, and could not be further away from my demands.
The user doesn't care at all about "partitions", "LVM" or "mountpoints". This is different from the more apt user who wants to actually have control over these details (where exactly to put partition(s) on the disk for example).
Correct ... The latter for instance is what I had needed. I wanted to compare SUSE against Fedora. So I installed SUSE in parallel to other OSes (amongst them Fedora and Windows) on to the same machine.
If my only choice would have been erase Fedora and/or Windows, ... this distro would have disqualified itself.
For all of the above select the advanced installation. I'm not sure why you recognize that you have very special needs for you installation yet at the same time seem to insist to be able to use the same installation procedure tailored to users who don't even understand a lot of the words you were using above. Nobody is "forcing" you to do anything.
The issue here is that keeping these advanced features available could have a negative impact on the "easy-mode" experience.If you manage to prevent that from happening than more power to you but if not then creating two distinct workflows is really the only option.
I can't avoid to disagree.
Spawning different installers means duplicating work and wasting resource.
Nobody is talking about spawning different installers. You'd start the same installer but it would present you with a different workflow i.e. in the advanced workflow you'd create your partitions manually and in the easy workflow you select to wipe your disk or install next to you existing windows os and anaconda would determine the necessary partitioning itself without bothering the user.
Regards, Dennis
On Tue, Oct 12, 2010 at 8:16 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
Hi,
Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users.
We don't have to make things inferior to improve usability. To stick with the "advanved storage" example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named "local storage" and "SAN storage". Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users.
If you want to appeal to the same audience Ubuntu is going for then you have to remove choice. The whole storage bit needs to be completely removed or at least stripped down. "advanced storage" certainly has to disappear completely. The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one.
You cannot make two distinct target audiences happy with one workflow especially if one of those groups requires a limitation of choice.
Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Why this mode could not be selected by the user?
I would say that the default mode be more like the Ubuntu installer and give the choice of an advanced mode like the current one. When you boot the CD/DVD, you could easily add the new choice in the list (Install, Install (advanced features), Boot from hard drive, etc).
On 10/12/2010 02:57 PM, Jean-Francois Saucier wrote:
On Tue, Oct 12, 2010 at 8:16 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
Hi,Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users.
We don't have to make things inferior to improve usability. To stick with the "advanved storage" example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named "local storage" and "SAN storage". Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users.
If you want to appeal to the same audience Ubuntu is going for then you have to remove choice. The whole storage bit needs to be completely removed or at least stripped down. "advanced storage" certainly has to disappear completely. The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one.
You cannot make two distinct target audiences happy with one workflow especially if one of those groups requires a limitation of choice.
Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Why this mode could not be selected by the user?
I would say that the default mode be more like the Ubuntu installer and give the choice of an advanced mode like the current one. When you boot the CD/DVD, you could easily add the new choice in the list (Install, Install (advanced features), Boot from hard drive, etc).
That would certainly be an option. The key point here is that you need a way to provide a distinct experience for regular users that is not hampered by considerations for more advanced ones. That's one of the things that Ubuntu does differently than Fedora in my opinion although with the latest ideas for a simplified package manager Fedora is certainly heading in the right direction.
Let me clarify my position: I have no problem with with providing advanced features but in order to create a truly polished experience for regular users you need to be able to truly focus on them. If every time you think "If we did X, Y and Z we could make the lives of users a lot easier" you have to immediately go to "but because of the advanced audience we can't do X and Y and we can only do an awkward implementation of Z" than you will not be able to create a truly exceptional experience.
Regards, Dennis
On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one.
Anaconda actually has the ability to do this with "install classes".
On 10/12/2010 04:20 PM, Matthew Miller wrote:
On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one.
Anaconda actually has the ability to do this with "install classes".
I figured as much and my guess is that anaconda already has most of the required stuff implemented and it's really just a case of lining up the bits and pieces the right way.
Another question is where to split this off exactly:
1) Different spins 2) Boot menu option (default=easy and an "advanced" option) 3) Selection screen when anaconda starts 4) "advanced" buttons in the anaconda pages
From top to bottom I would say the implementation work probably decreases but the danger of one install path "contaminating" the other probably increases. What that means is that at 1) you end up with two completely distinct installation procedures which requires more work to implement but can really be customized for the different target audiences whereas at 4) you share a lot of stuff even in the interface but the different installation methods must have a similar workflow which doesn't allow for much individualization.
Regards, Dennis
On Tue, 2010-10-12 at 16:40 +0200, Dennis Jacobfeuerborn wrote:
On 10/12/2010 04:20 PM, Matthew Miller wrote:
On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one.
Anaconda actually has the ability to do this with "install classes".
I figured as much and my guess is that anaconda already has most of the required stuff implemented and it's really just a case of lining up the bits and pieces the right way.
Another question is where to split this off exactly:
Live vs. traditional seems like the obvious split to me.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/12/10 7:20 AM, Matthew Miller wrote:
On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one.
Anaconda actually has the ability to do this with "install classes".
Anaconda used to have an Advanced mode where things like the complex partitioning and package selection were hidden. Turns out, the vast majority of people who used anaconda and said something about it had picked advanced mode, because they felt their case was special. If everybody uses advanced mode, that becomes the norm...
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On Tue, Oct 12, 2010 at 08:06:59AM -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/12/10 7:20 AM, Matthew Miller wrote:
On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one.
Anaconda actually has the ability to do this with "install classes".
Anaconda used to have an Advanced mode where things like the complex partitioning and package selection were hidden. Turns out, the vast majority of people who used anaconda and said something about it had picked advanced mode, because they felt their case was special. If everybody uses advanced mode, that becomes the norm...
Making "advanced" only a choice at the beginning of a 10 step process is a non-starter and leads to the problem you describe above. If instead there were "Advanced Options..." in each step along the way that could be opened/closed at will, that would allow users to explore the advanced options without worrying that they made the "wrong choice" way back at the beginning of the 10 step process, whether or not they actually end up using the advanced options.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/12/10 8:13 AM, Chuck Anderson wrote:
Making "advanced" only a choice at the beginning of a 10 step process is a non-starter and leads to the problem you describe above. If instead there were "Advanced Options..." in each step along the way that could be opened/closed at will, that would allow users to explore the advanced options without worrying that they made the "wrong choice" way back at the beginning of the 10 step process, whether or not they actually end up using the advanced options.
So like how the storage screen now has an advanced option...
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On 10/12/2010 05:13 PM, Chuck Anderson wrote:
On Tue, Oct 12, 2010 at 08:06:59AM -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/12/10 7:20 AM, Matthew Miller wrote:
On Tue, Oct 12, 2010 at 02:16:49PM +0200, Dennis Jacobfeuerborn wrote:
The only way to accomplish this without actually removing the features is to have two anaconda modes one for easy desktop installation and one full featured mode. This mode should be chosen not by the user but by the spin e.g. the desktop spin would use the easy mode and the server or workstation spins would use the full featured one.
Anaconda actually has the ability to do this with "install classes".
Anaconda used to have an Advanced mode where things like the complex partitioning and package selection were hidden. Turns out, the vast majority of people who used anaconda and said something about it had picked advanced mode, because they felt their case was special. If everybody uses advanced mode, that becomes the norm...
Making "advanced" only a choice at the beginning of a 10 step process is a non-starter and leads to the problem you describe above. If instead there were "Advanced Options..." in each step along the way that could be opened/closed at will, that would allow users to explore the advanced options without worrying that they made the "wrong choice" way back at the beginning of the 10 step process, whether or not they actually end up using the advanced options.
This assumes that the workflow for both methods is always the same which is pretty limiting. Maybe for the simple installation you don't want a storage configuration screen at all and simply put up an option to overwrite the hd completely or install next to an already present os. Perhaps you can even put this on the screen where the user enters his name since this selection doesn't really warrant its own screen at all.
Regards, Dennis
Dennis Jacobfeuerborn wrote:
On 10/12/2010 10:28 AM, Gerd Hoffmann wrote:
Hi,Striving for usability and pleasantness for the untechnical users certainly is a good thing. It gets problematic when you choose to make things technically inferior just to please those kind of users.
We don't have to make things inferior to improve usability. To stick with the "advanved storage" example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named "local storage" and "SAN storage". Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users.
If you want to appeal to the same audience Ubuntu is going for then you have to remove choice. The whole storage bit needs to be completely removed or at least stripped down. "advanced storage" certainly has to disappear completely.
I don't agree. There's nothing unusual about a dumbed-down interface for novices, with an 'advanced' tab hiding more options.
On Tue, 2010-10-12 at 10:53 -0400, Neal Becker wrote:
I don't agree. There's nothing unusual about a dumbed-down interface for novices, with an 'advanced' tab hiding more options.
As someone else has pointed out, a lot of usability experts consider this a bad idea, for two reasons:
1) everyone thinks they're an expert, even if they're not, and hits 'advanced'
2) it creates a confusing decision point for *everyone*: how do you know if you need the 'advanced' options? You can't really know without looking at them, so you have to look at them to decide if you need them, so essentially we're presenting the advanced options to everyone...
On Tue, Oct 12, 2010 at 6:30 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2010-10-12 at 10:53 -0400, Neal Becker wrote:
I don't agree. There's nothing unusual about a dumbed-down interface for novices, with an 'advanced' tab hiding more options.
As someone else has pointed out, a lot of usability experts consider this a bad idea, for two reasons:
- everyone thinks they're an expert, even if they're not, and hits
'advanced'
- it creates a confusing decision point for *everyone*: how do you know
if you need the 'advanced' options? You can't really know without looking at them, so you have to look at them to decide if you need them, so essentially we're presenting the advanced options to everyone...
Well most people just press "Next", "Next", "Next" ....
On Tue, 2010-10-12 at 18:34 +0200, drago01 wrote:
On Tue, Oct 12, 2010 at 6:30 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2010-10-12 at 10:53 -0400, Neal Becker wrote:
I don't agree. There's nothing unusual about a dumbed-down interface for novices, with an 'advanced' tab hiding more options.
As someone else has pointed out, a lot of usability experts consider this a bad idea, for two reasons:
- everyone thinks they're an expert, even if they're not, and hits
'advanced'
- it creates a confusing decision point for *everyone*: how do you know
if you need the 'advanced' options? You can't really know without looking at them, so you have to look at them to decide if you need them, so essentially we're presenting the advanced options to everyone...
Well most people just press "Next", "Next", "Next" ....
As I recall, several distros have done usability studies and found that this isn't actually true. People have been *trained* to just press next, next, next under specific circumstances - like Windows software installation - but it's not everyone's default behaviour, especially the kinds of people who tend to install Linux distributions. (Have you ever observed people trying to use subway ticket machines in an unfamiliar city? They certainly don't just click next, next, next, in my experience. They read every screen carefully and worry which of the many options to choose. Frequently, when the process is too complex, they worry that they've somehow got something wrong, cancel, and start over.)
Even when people do it, it's more of an 'exasperation fallback': it's what people do when they hit their breaking point of potential decisions, they go 'oh what the hell, I'll just hit next on everything'. If we get to that point we've already 'lost', because we exasperated the user: even if they happen to get a fully functional install, they're not happy with the experience.
It'd be nice if anyone who's been involved in Fedora UX studies could contribute...
On Tue, Oct 12, 2010 at 7:03 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2010-10-12 at 18:34 +0200, drago01 wrote:
On Tue, Oct 12, 2010 at 6:30 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2010-10-12 at 10:53 -0400, Neal Becker wrote:
I don't agree. There's nothing unusual about a dumbed-down interface for novices, with an 'advanced' tab hiding more options.
As someone else has pointed out, a lot of usability experts consider this a bad idea, for two reasons:
- everyone thinks they're an expert, even if they're not, and hits
'advanced'
- it creates a confusing decision point for *everyone*: how do you know
if you need the 'advanced' options? You can't really know without looking at them, so you have to look at them to decide if you need them, so essentially we're presenting the advanced options to everyone...
Well most people just press "Next", "Next", "Next" ....
As I recall, several distros have done usability studies and found that this isn't actually true. People have been *trained* to just press next, next, next under specific circumstances - like Windows software installation - but it's not everyone's default behaviour, especially the kinds of people who tend to install Linux distributions.
Any pointers to those studies? Not saying that you are lying, but I am actually interested to see them.
(Have you ever observed people trying to use subway ticket machines in an unfamiliar city? They certainly don't just click next, next, next, in my experience. They read every screen carefully and worry which of the many options to choose. Frequently, when the process is too complex, they worry that they've somehow got something wrong, cancel, and start over.)
It involves money ;)
Even when people do it, it's more of an 'exasperation fallback': it's what people do when they hit their breaking point of potential decisions, they go 'oh what the hell, I'll just hit next on everything'. If we get to that point we've already 'lost', because we exasperated the user: even if they happen to get a fully functional install, they're not happy with the experience.
Or they think "don't care, just install the damn thing".
On Tue, 2010-10-12 at 19:15 +0200, drago01 wrote:
As I recall, several distros have done usability studies and found that this isn't actually true. People have been *trained* to just press next, next, next under specific circumstances - like Windows software installation - but it's not everyone's default behaviour, especially the kinds of people who tend to install Linux distributions.
Any pointers to those studies? Not saying that you are lying, but I am actually interested to see them.
No, unfortunately - I remember stuff from ages-old blog posts and mailing lists but I'm not a good note/bookmark taker so I have no references :(
On Tue, Oct 12, 2010 at 09:30:45AM -0700, Adam Williamson wrote:
- it creates a confusing decision point for *everyone*: how do you know
if you need the 'advanced' options? You can't really know without looking at them, so you have to look at them to decide if you need them, so essentially we're presenting the advanced options to everyone...
100% agreed. You do not know in advance what options will not be shown in non-advanced mode (e.g. custom filesystem layout, MBR at a different partition, etc.). As a CLI expert I'm considering myself all but a GUI expert, but I never understood how people can "guess" the corect answer to this kind of undefined questions (like "do you want basic or advanced install mode?").
On 10/12/10 18:39, Jos Vos wrote:
On Tue, Oct 12, 2010 at 09:30:45AM -0700, Adam Williamson wrote:
- it creates a confusing decision point for *everyone*: how do you know
if you need the 'advanced' options? You can't really know without looking at them, so you have to look at them to decide if you need them, so essentially we're presenting the advanced options to everyone...
100% agreed. You do not know in advance what options will not be shown in non-advanced mode (e.g. custom filesystem layout, MBR at a different partition, etc.). As a CLI expert I'm considering myself all but a GUI expert, but I never understood how people can "guess" the corect answer to this kind of undefined questions (like "do you want basic or advanced install mode?").
"advanced install mode" is a non-started as discussed elsewhere in this thread. It must be more fine-grained, i.e. each installation step (where it make sense) should offer some button to see the advanced options.
And it probably shouldn't be labeled "Advanced ..." but say what kind of advanced stuff is hidden there, i.e. the "advanced storage" button should be labeled "Add SAN storage ..." because this is what it actually is about. Now you can figure whenever you need that or not without klicking and looking, see?
cheers, Gerd
On Wed, Oct 13, 2010 at 10:16:00AM +0200, Gerd Hoffmann wrote:
"advanced install mode" is a non-started as discussed elsewhere in this thread. It must be more fine-grained, i.e. each installation step (where it make sense) should offer some button to see the advanced options.
The "Show a screenful of sane defaults for lots of stuff" with a "Change" button next to each sounds good to me, and probably could just be a front for the current dialogs (which might not be perfect, but they are quite good)
If the keyboard, timezone etc. are correct (based on autodetection/GeoIP when available) then why make the user even press Next?
If "Nuke everything and use LVM on my 1TB Seagate" is ok, same there. If "Standard desktop" is fine, then so be it. If not, press "Change", select "Server" and if that's not good either, fiddle with the packages while you're over there.
Personally I would probably like a cmd line option to anaconda for it to fetch some file through http (kickstart :) ), and that would have my favourite packages listed, and I could pretty much just press "Install" after anaconda starts up (after verifying that everything got detected correctly). Pretty much the current situation, except I wouldn't have to go through all of those dialogs.
I'm no UX person, though. Maybe people want to think about one thing at a time and then press Next :D
On Wed, 2010-10-13 at 10:16 +0200, Gerd Hoffmann wrote:
And it probably shouldn't be labeled "Advanced ..." but say what kind of advanced stuff is hidden there, i.e. the "advanced storage" button should be labeled "Add SAN storage ..." because this is what it actually is about. Now you can figure whenever you need that or not without klicking and looking, see?
Nope, because that's not all it does. You also need the 'advanced' storage mode if you want to explicitly exclude disks from being considered during installation at all, which was previously part of the normal installation flow; now you're only shown that screen if you pick the 'advanced' mode. A button saying 'SAN storage and explicit device selection...' is rapidly getting uglier, and I'm sure there's other stuff that's in that path which that description still doesn't cover.
On 10/13/2010 05:21 PM, Adam Williamson wrote:
On Wed, 2010-10-13 at 10:16 +0200, Gerd Hoffmann wrote:
And it probably shouldn't be labeled "Advanced ..." but say what kind of advanced stuff is hidden there, i.e. the "advanced storage" button should be labeled "Add SAN storage ..." because this is what it actually is about. Now you can figure whenever you need that or not without klicking and looking, see?
Nope, because that's not all it does. You also need the 'advanced' storage mode if you want to explicitly exclude disks from being considered during installation at all, which was previously part of the normal installation flow; now you're only shown that screen if you pick the 'advanced' mode. A button saying 'SAN storage and explicit device selection...' is rapidly getting uglier, and I'm sure there's other stuff that's in that path which that description still doesn't cover.
This discussion is what you get when you try to make both groups happy with a single solution and in the end this usually kills any progress because not only do they not come to an agreement initially but even if they do any future changes now have to be agreed upon by both sides.
This sort of tight coupling is exactly what should be avoided if you want to make both groups of users happy.
Regards, Dennis
On Mon, 2010-10-11 at 11:41 +0100, Richard W.M. Jones wrote:
I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky.
Some of the things it does which are IMHO better:
starts disk formatting / copying / installing in parallel with asking user questions
downloads updates in parallel too
uses IP geolocation to guess the user's timezone and keyboard settings (it's been 100% correct for me each time)
suggests a username and hostname based on the user's real name (Mac OS X's installer also does this -- it's a nice touch)
This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area.
Thoughts?
Could somebody send in bug numbers for the RFEs they filed already?
Can we switch to their installer?
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
On Mon, 2010-10-11 at 11:41 +0100, Richard W.M. Jones wrote:
I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. <snip>
As a full-time Ubuntu user, I just want to point out that I don't really like the Ubuntu installer and its whole process. Although I do prefer to use to distro itself.
When I do use Fedora, I really enjoy the whole live-image-copy process as its super fast and efficient and it does the job well. It's much faster than the installer of Ubuntu. So again, as a full-time Ubuntu user, the Fedora Development Team should be very proud of what they've achieved with the Fedora and Anaconda Installer.
Regards
Chris Jones
* Chris Jones [13/10/2010 11:35] :
As a full-time Ubuntu user, I just want to point out that I don't really like the Ubuntu installer and its whole process. Although I do prefer to use to distro itself.
Amen, I've lost count of the amount of times installing Ubuntu has involved installing Fedora to partition the drive correctly then installing Ubuntu telling it to use the existing partition.
Emmanuel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/10/10 03:41 AM, Richard W.M. Jones wrote:
I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky.
Some of the things it does which are IMHO better:
- starts disk formatting / copying / installing in parallel
with asking user questions
downloads updates in parallel too
uses IP geolocation to guess the user's timezone and keyboard
settings (it's been 100% correct for me each time)
- suggests a username and hostname based on the user's real name
(Mac OS X's installer also does this -- it's a nice touch)
This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area.
Thoughts? Can we switch to their installer?
Rich.
Looking at the installation and the documentation of Ubuntu 10.10, the outside looks nice but the functionality is very lacking as pointed out on many posts. AFAIK, Ubuntu installer does not have the ability to customize installation for use needs as highlighted and can be only done offline. I don't know if there are installer from live media that provide more control about package to install other than extracting the bundled applications.
What anaconda needs is more refinement and polishing as majority of function are already in place (has the team solved issue about multiple boot bug or recognition of other installed distributions>).
To answer the question: don't switch to that new installer.
- -- Luya Tshimbalanga Graphic & Web Designer E: luya@fedoraproject.org W: http://www.thefinalzone.net
Hi,
/*Luya Tshimbalanga luya@fedoraproject.org*/ wrote on 10/15/2010 6:06:10 AM +0350:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/10/10 03:41 AM, Richard W.M. Jones wrote:
I installed and played with Ubuntu 10.10 over the weekend (in a VM), and I have to say that their installer is very smooth indeed. It's starting to make anaconda look distinctly clunky.
Some of the things it does which are IMHO better:
- starts disk formatting / copying / installing in parallel
with asking user questions
downloads updates in parallel too
uses IP geolocation to guess the user's timezone and keyboard
settings (it's been 100% correct for me each time)
- suggests a username and hostname based on the user's real name
(Mac OS X's installer also does this -- it's a nice touch)
This is in contrast to anaconda (certainly from the live CD install) which seems to be a usability no-go area.
Thoughts? Can we switch to their installer?
Rich.
Looking at the installation and the documentation of Ubuntu 10.10, the outside looks nice but the functionality is very lacking as pointed out on many posts. AFAIK, Ubuntu installer does not have the ability to customize installation for use needs as highlighted and can be only done offline. I don't know if there are installer from live media that provide more control about package to install other than extracting the bundled applications.
What anaconda needs is more refinement and polishing as majority of function are already in place (has the team solved issue about multiple boot bug or recognition of other installed distributions>).
To answer the question: don't switch to that new installer.
I completely agree. I've never heard any of the users who prefer Ubuntu to complain about the mentioned problems with the Fedora's installer. While those features are nice to have, but it's not hard for users to live with them at all. The only thing that I've seen that some (specially novice) users prefer about the Ubuntu installer is the ability to install from the Windows environment and it's ability to install Ubuntu "inside" a Windows partition without requiring to change hard disks partitioning (IIRC the old RedHat had this feature for sometime). I was also proud of Anaconda's features, and hardly against reducing its feature set. Looking for new users should not make us forgetting current Fedora users. There is some reason that the current Fedora users has not switched to Ubuntu; but if you make things more and more like Ubuntu the current users will look somewhere else to find what they want.
For example, I do lots of Fedora installations, but I rarely do a normal install. On my own ThinkPad X61 I use hard disk installation (it doesn't have any DVD/CD drives), and for others I usually do an HTTP install from my laptop. (Installing from live medias or BFO installation methods are simply a No-Go for me because of the required during-install or after-install bandwidth). Also, from time to time I do organize some competitions in which I should install Linux on many systems, and so I do an HTTP install to install in parallel. In my case, being able to do a hard disk install from an NTFS partition (which worked fine in F13 but doesn't work in F14, and it was never officially supported) is much much more important (as I don't have any non-lvm ext partitions and FAT partitions have been long gone from hard disks!) than the mentioned features.
Another thing which hits me is being forced to customizing package list always: if you select "Software Development" as the software you need, you cannot select any other option in the new Anacondas; and in its default selection there is no Office suits, no media applications and even it doesn't select Eclipse (I wonder if most of software developers do not use office and sound/video applications!). So, I'm forced to customize the package selection.
IMHO, the features I mentioned provide more than a little faster installation or guessing user's timezone.
Good luck, Hedayat
Luya Tshimbalanga Graphic& Web Designer E: luya@fedoraproject.org W: http://www.thefinalzone.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJMt74WAAoJEGZ+gIukWeEez4UH+wcvdTZBl8TvStVILx2vHGF2 1L1mgvYlfyZqmvTA/B8oFaU5uId3tNCFhoeGAhWEXwhjX2R9mX8MFjI5Gf+aU5Me A9rI2PGePvcV9jJ7B+Fohc5/61KGAYtitNZhiDq8MlBH1TMEH+HfesX3nzMvn3iV wjDELf3dzistkprX7ERSBm+pV0auUkYIQuOlr8AapoZzhi9LaRaOW4rBORb92ATf EfKOxu/ukicaqebrMHaMB3PaDDSXhFb/99opE+pwDG5IcwCymuMfiBT+D1g5+1vr SYyThPcxmhd1BGmXpO8ChW/wwIYQJ32hTvixvBJCiIVSUp9AIkJSEZdRf1lllUc= =1O1D -----END PGP SIGNATURE-----
-
Adam Jackson -
Adam Miller -
Adam Williamson -
Bastien Nocera -
Bill Nottingham -
Bruno Wolff III -
Chris Adams -
Chris Jones -
Chris Lumens -
Chuck Anderson -
David Woodhouse -
Dennis Jacobfeuerborn -
drago01 -
Emmanuel Seyman -
Farkas Levente -
Farkas Levente -
Gerd Hoffmann -
Gilboa Davara -
Hedayat Vatankhah -
James Antill -
James Laska -
Jean-Francois Saucier -
Jesse Keating -
John Reiser -
Jon Masters -
Jos Vos -
Josh Boyer -
Lars Seipel -
Liang Suilong -
Luya Tshimbalanga -
Manuel Escudero -
Manuel Wolfshant -
Matthew Garrett -
Matthew Miller -
Matthias Clasen -
Michał Piotrowski -
Mike McGrath -
Máirín Duffy -
Neal Becker -
Nicolas Mailhot -
Pekka Pietikäinen -
Peter Jones -
Peter Lemenkov -
Przemek Klosowski -
Ralf Corsepius -
Ralf Ertzinger -
Richard W.M. Jones -
Rudolf Kastl -
Seth Vidal -
Simo Sorce -
Tomasz Torcz