Hi,
I put together a desired installation experience wishlist. Let's discuss and consider forwarding this to the Anaconda developers as a request.
* Remove the timezone selection spoke. This spoke is redundant with gnome-initial-setup. * Remove or simplify the network configuration spoke. In the live installer, this spoke allows setting only the system hostname, but it follows different rules for setting the hostname than GNOME/systemd. The spoke should either follow hostnamed's rules for pretty hostnames (i.e. allows capital letters, spaces, etc. without any complaint), or the spoke should be removed. If we keep it, it should allow the user to set a "computer name" (avoiding technical terminology like "hostname") and should not include the phrase "network configuration." * Remove root password configuration. It's confusing how this is different from the user's admin account password. Advanced users can set a root password after installation if desired. * Remove user account creation. This is redundant with gnome-initial -setup. * Remove hub and spokes: simply go straight to keyboard layout selection after language selection, then from there to disk layout, optionally from there to the hostname panel, and then to the installation progress panel. This last panel will need a bit of a redesign, since it will be pretty empty otherwise.
Clearly this is mostly a list of things to remove, rather than things to add. The goal is to make installation as simple and easy as possible.
Changes to gnome-initial-setup: Skip language and keyboard layout selection in user creation mode. These panels cannot reasonably be removed from Anaconda, so we should use them only in existing user mode (when a new user account is created after installation). They're redundant in user creation mode.
This proposal leaves the disk layout spoke untouched, which is the most confusing portion of the installation experience, but it's more than enough changes for one release already.
Thoughts?
+1 ACK
*Timezone always seemed very odd to me because it's always gotten it right and NTP defaults to 'on' anyway... Also yes, it's redundant with gnome-initial-setup.
*We have "Pretty Names" thanks to systemd, we might as well use them. Also, yes, the entire 'network configuration' page needs to either be removed or modified because right now its a giant waste of white space (more on that later...)
*Root password + User got brought up in a different thread, one of the Workstation guys said that long run they wanted to make it more obvious that it was an Either/Or (You can either set root, OR make a user), you didn't have to do both. If we're going to be removing the root prompt then I think a few 'bugs' need to be ironed out.
The one that comes to mind is... if you're an "Administrator" then you have the ability to use grub2-mkconfig but... you have to blindly specify an output file on an EFI system. On my system only root can look inside /boot/EFI/ (not modify mind you, just LOOK) which means if i'm under my user account and decide to change a grub parameter I have to either blindly remember what the path is, or take the time to swap to root and then swap back just for the sake of updating the boot config.
I get that the boot config isn't something that you want just any user with sudo messing around with, but at the same time... if they got sudo they can already just rm -rf /etc and /usr anyway, plus some consistency would be nice.
*If user account creation gets removed then gnome-initial-setup needs to trigger under KDE, XFCE, and LXDE spins as well, or they need to get appropriate first-time-setup utilities as well.
*I already said I thought hub-and-spoke was a bad idea. Installer starts --> Keyboard and Language selection ---> Disk partitioning --> User Creation ---> Done. Keep an expert button for software selection and non-default network config if we really want to keep those in. The installer is the one point of contact that EVERYONE experiences and everyone should experience it for the LEAST amount of time possible, and that means it needs to get out of your way and have the bare minimum necessary to get a system running.
*Additionally, does the installer really need to be fullscreen / maximized? There's tons of wasted whitespace all around and if hub and spoke gets removed then there will be even more waste because we won't have the spoke page filled up with topics. Just make it a 'normal' application.
Disk layout needs some work, seriously. It might have been a bug but when I installed it on my laptop i couldn't get it to automatically create btrfs partitions + encrypted volumes. I spent an easy 30minutes+ fighting with Anaconda and at the end of it I threw in the towel and just opted for ext4 + encryption because thats what I could get it to show me... in the end what I was told I was gonna get (ext4 + encrypted, possibly LVM in there too) and what I GOT (btrfs + encrypted... which is what I wanted anyway, but the installer told me I wasn't gonna get it) were very different.
On Sat, May 9, 2015 at 12:19 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
Hi,
I put together a desired installation experience wishlist. Let's discuss and consider forwarding this to the Anaconda developers as a request.
- Remove the timezone selection spoke. This spoke is redundant with
gnome-initial-setup.
- Remove or simplify the network configuration spoke. In the live
installer, this spoke allows setting only the system hostname, but it follows different rules for setting the hostname than GNOME/systemd. The spoke should either follow hostnamed's rules for pretty hostnames (i.e. allows capital letters, spaces, etc. without any complaint), or the spoke should be removed. If we keep it, it should allow the user to set a "computer name" (avoiding technical terminology like "hostname") and should not include the phrase "network configuration."
- Remove root password configuration. It's confusing how this is
different from the user's admin account password. Advanced users can set a root password after installation if desired.
- Remove user account creation. This is redundant with gnome-initial
-setup.
- Remove hub and spokes: simply go straight to keyboard layout
selection after language selection, then from there to disk layout, optionally from there to the hostname panel, and then to the installation progress panel. This last panel will need a bit of a redesign, since it will be pretty empty otherwise.
Clearly this is mostly a list of things to remove, rather than things to add. The goal is to make installation as simple and easy as possible.
Changes to gnome-initial-setup: Skip language and keyboard layout selection in user creation mode. These panels cannot reasonably be removed from Anaconda, so we should use them only in existing user mode (when a new user account is created after installation). They're redundant in user creation mode.
This proposal leaves the disk layout spoke untouched, which is the most confusing portion of the installation experience, but it's more than enough changes for one release already.
Thoughts?
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Sat, 2015-05-09 at 13:05 -0400, Eric Griffith wrote:
The one that comes to mind is... if you're an "Administrator" then you have the ability to use grub2-mkconfig but... you have to blindly specify an output file on an EFI system. On my system only root can look inside /boot/EFI/ (not modify mind you, just LOOK) which means if i'm under my user account and decide to change a grub parameter I have to either blindly remember what the path is, or take the time to swap to root and then swap back just for the sake of updating the boot config.
I think 'sudo -i' does what you want.
*If user account creation gets removed then gnome-initial-setup needs to trigger under KDE, XFCE, and LXDE spins as well, or they need to get appropriate first-time-setup utilities as well.
I don't suggest any of these changes for other products or spins: that would probably be a nonstarter. Just for Workstation.
*I already said I thought hub-and-spoke was a bad idea. Installer starts --> Keyboard and Language selection ---> Disk partitioning --> User Creation ---> Done. Keep an expert button for software selection and non-default network config if we really want to keep those in.
Note that we don't have software selection on the live image and never have.
Disk layout needs some work, seriously. It might have been a bug but when I installed it on my laptop i couldn't get it to automatically create btrfs partitions + encrypted volumes. I spent an easy 30minutes+ fighting with Anaconda and at the end of it I threw in the towel and just opted for ext4 + encryption because thats what I could get it to show me... in the end what I was told I was gonna get (ext4
- encrypted, possibly LVM in there too) and what I GOT (btrfs +
encrypted... which is what I wanted anyway, but the installer told me I wasn't gonna get it) were very different.
Ouch, that really needs to never happen. :(
On Sat, May 09, 2015 at 01:36:59PM -0500, Michael Catanzaro wrote:
I don't suggest any of these changes for other products or spins: that would probably be a nonstarter. Just for Workstation.
Some of these (particularly, the "remove a step" options) might fit into the per-product anaconda config we're already doing in order to change the default filesystem (and provide different graphics).
If you had a gnome-initial-setup (minus some steps, just language and keyboard) in the Live environment, the only thing you'd need to setup would be where to install the OS.
Which is about all I think an installer should do.
----- Original Message -----
Hi,
I put together a desired installation experience wishlist. Let's discuss and consider forwarding this to the Anaconda developers as a request.
- Remove the timezone selection spoke. This spoke is redundant with
gnome-initial-setup.
- Remove or simplify the network configuration spoke. In the live
installer, this spoke allows setting only the system hostname, but it follows different rules for setting the hostname than GNOME/systemd. The spoke should either follow hostnamed's rules for pretty hostnames (i.e. allows capital letters, spaces, etc. without any complaint), or the spoke should be removed. If we keep it, it should allow the user to set a "computer name" (avoiding technical terminology like "hostname") and should not include the phrase "network configuration."
- Remove root password configuration. It's confusing how this is
different from the user's admin account password. Advanced users can set a root password after installation if desired.
- Remove user account creation. This is redundant with gnome-initial
-setup.
- Remove hub and spokes: simply go straight to keyboard layout
selection after language selection, then from there to disk layout, optionally from there to the hostname panel, and then to the installation progress panel. This last panel will need a bit of a redesign, since it will be pretty empty otherwise.
Clearly this is mostly a list of things to remove, rather than things to add. The goal is to make installation as simple and easy as possible.
Changes to gnome-initial-setup: Skip language and keyboard layout selection in user creation mode. These panels cannot reasonably be removed from Anaconda, so we should use them only in existing user mode (when a new user account is created after installation). They're redundant in user creation mode.
This proposal leaves the disk layout spoke untouched, which is the most confusing portion of the installation experience, but it's more than enough changes for one release already.
Thoughts?
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Michael Catanzaro píše v So 09. 05. 2015 v 11:19 -0500:
Hi,
I put together a desired installation experience wishlist. Let's discuss and consider forwarding this to the Anaconda developers as a request.
- Remove the timezone selection spoke. This spoke is redundant with
gnome-initial-setup.
- Remove or simplify the network configuration spoke. In the live
installer, this spoke allows setting only the system hostname, but it follows different rules for setting the hostname than GNOME/systemd. The spoke should either follow hostnamed's rules for pretty hostnames (i.e. allows capital letters, spaces, etc. without any complaint), or the spoke should be removed. If we keep it, it should allow the user to set a "computer name" (avoiding technical terminology like "hostname") and should not include the phrase "network configuration."
- Remove root password configuration. It's confusing how this is
different from the user's admin account password. Advanced users can set a root password after installation if desired.
- Remove user account creation. This is redundant with gnome-initial
-setup.
- Remove hub and spokes: simply go straight to keyboard layout
selection after language selection, then from there to disk layout, optionally from there to the hostname panel, and then to the installation progress panel. This last panel will need a bit of a redesign, since it will be pretty empty otherwise.
Clearly this is mostly a list of things to remove, rather than things to add. The goal is to make installation as simple and easy as possible.
Changes to gnome-initial-setup: Skip language and keyboard layout selection in user creation mode. These panels cannot reasonably be removed from Anaconda, so we should use them only in existing user mode (when a new user account is created after installation). They're redundant in user creation mode.
This proposal leaves the disk layout spoke untouched, which is the most confusing portion of the installation experience, but it's more than enough changes for one release already.
Thoughts?
I suppose this expects that Anaconda is flexible enough to provide different versions for different products/spins of Fedora because only Workstation uses gnome-initial-setup. I know that this possibility has been discussed, but I'm not sure how far it is.
My two wishes for the installer:
* new layout for the "Installation in Progress" screen. There is a huge empty place in the middle which is there to add extra spokes, but it's been three years since the new Anaconda was introduced and we don't have any extra spokes. But the layout of this screen has been terrible for the whole time. Maybe it's time to admit that people just don't want to create new spokes and add them to Anaconda and change the screen. The empty space may be used for some better banners showing the users what Fedora has to offer. Ubuntu is doing much better at this.
* the installer or some post-installation process should download and install missing packages for full localization because right now users don't get fully localized Fedora and there is no obvious way to achieve it.
OT: it'd be great to be able to choose your language even before booting as Ubuntu has it. It leaves much better impression if the live system is already translated. It has happened to me several times that people turned down Fedora in favor of Ubuntu because the audience they wanted to give USB sticks/DVDs required translated system and Fedora is not translated running from live media (unless you undergo quite cumbersome process of setting it manually).
Jiri
[...] because only Workstation uses gnome-initial-setup.
Just two random (and stupid?) ideas:
1- Replace Anaconda in Fedora Workstation with a screen that asks your language and another that asks if you want to "Erase everything and install Fedora" or "Install Fedora alongside existing OS". All the rest handled by GNOME Initial Setup.
or
2- Split anaconda into "Anaconda Installer" (language + partitioning) and "Anaconda Initial Setup" (everything else) and apply this to all variations/spins (except "Anaconda Initial Setup" to Fedora Workstation).
:)
On Mon, May 11, 2015 at 02:13:40PM +0200, Jiri Eischmann wrote:
I suppose this expects that Anaconda is flexible enough to provide different versions for different products/spins of Fedora because only Workstation uses gnome-initial-setup. I know that this possibility has been discussed, but I'm not sure how far it is.
It's close enough that we could easily do something drastic for F23 if we start planning now.
Here is an updated list of proposed changes, based on our discussion in the WG meeting today. These changes are proposed for the Workstation installer only and not other products' installers, so we assume that Anaconda will allow this level of per-product configurability. Changes are targeted for F24, not F23, and subject to further discussion with Anaconda developers.
* Remove the timezone selection spoke from either anaconda or gnome -initial-setup. These spokes are redundant and one or the other needs to go. The reason to potentially retain it in Anaconda would be to get the timestamps of installed files correct, if we care about that. * Remove root password configuration. It's confusing how this is different from the user's admin account password. Advanced users can set a root password after installation if desired. * Remove user account creation. This is redundant with gnome-initial -setup. * Remove or simplify the network configuration spoke. In the live installer, this spoke allows setting only the system hostname, but it follows different rules for setting the hostname than GNOME/systemd. The spoke should either follow hostnamed's rules for pretty hostnames (i.e. allows capital letters, spaces, etc. without any complaint), or the spoke should be removed. If we keep it, it should allow the user to set a "computer name" (avoiding technical terminology like "hostname") and should not include the phrase "network configuration."
Changes to gnome-initial-setup: Skip language and keyboard layout selection in user creation mode. These panels cannot reasonably be removed from Anaconda, so we should use them only in existing user mode (when a new user account is created after installation). They're redundant in user creation mode. Also, completely remove timezone selection if it remains in anaconda.
Optional: Remove hub and spokes: simply go straight to keyboard layout selection after language selection, then from there to disk layout, optionally from there to the hostname panel, and then to the installation progress panel. This last panel will need a bit of a redesign, since it will be pretty empty otherwise. Many WG members feel this would make the installer easier to use, but we do not have consensus on this. It is unrelated to the goal of reducing redundancy between anaconda and g-i-s.
We also note that there have been many requests to simplify the installation destination spoke, but we do not have any design for this.
On Wed, May 27, 2015 at 6:19 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
- Remove the timezone selection spoke from either anaconda or gnome
-initial-setup. These spokes are redundant and one or the other needs to go. The reason to potentially retain it in Anaconda would be to get the timestamps of installed files correct, if we care about that.
Nit: file timestamps are not dependent on the timezone and packaged files timestamps are set to when the package was built.
Rui
On Wed, May 27, 2015 at 06:53:51PM +0200, Rui Tiago Cação Matos wrote:
- Remove the timezone selection spoke from either anaconda or gnome
-initial-setup. These spokes are redundant and one or the other needs to go. The reason to potentially retain it in Anaconda would be to get the timestamps of installed files correct, if we care about that.
Nit: file timestamps are not dependent on the timezone and packaged files timestamps are set to when the package was built.
This is only partly true — some files are created at package install time, or by the installer itself.
This is generally only a problem when these turn out to have timestamps in the future. That could be solved by automatically back-dating them (several mechanisms possible) to at least the previous day (maybe a time fixed per anaconda build?) but that would be confusing too.
On Fri, May 29, 2015 at 12:27:39PM -0400, Matthew Miller wrote:
On Wed, May 27, 2015 at 06:53:51PM +0200, Rui Tiago Cação Matos wrote:
- Remove the timezone selection spoke from either anaconda or gnome
-initial-setup. These spokes are redundant and one or the other needs to go. The reason to potentially retain it in Anaconda would be to get the timestamps of installed files correct, if we care about that.
Nit: file timestamps are not dependent on the timezone and packaged files timestamps are set to when the package was built.
This is only partly true — some files are created at package install time, or by the installer itself.
This is generally only a problem when these turn out to have timestamps in the future. That could be solved by automatically back-dating them (several mechanisms possible) to at least the previous day (maybe a time fixed per anaconda build?) but that would be confusing too.
Timestamps are stored in absolute time (UTC), so as long as that time does not jump backwards (because of ntp or the user updating the clock) timestamps are never in the future. When you change the timezones only the way that timestamps are displayed is changed (*).
So whether timestamps are consistent is a question of (UTC) time being correct or at least monotonic, and not the timezone.
Zbyszek
(*) Different users can use different timezones simulataneously. E.g. when logging over ssh. The "system" timezone is just the default, so the concept of "the" timezone with which timestamps are written is not well defined.
On Sat, May 30, 2015 at 01:47:34AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
This is generally only a problem when these turn out to have timestamps in the future. That could be solved by automatically back-dating them (several mechanisms possible) to at least the previous day (maybe a time fixed per anaconda build?) but that would be confusing too.
Timestamps are stored in absolute time (UTC), so as long as that time does not jump backwards (because of ntp or the user updating the clock) timestamps are never in the future. When you change the timezones only the way that timestamps are displayed is changed (*).
The problem is that the installer has no idea if the system time is in UTC or in the local timezone (let alone just wrong).
On Fri, May 29, 2015 at 11:43:34PM -0400, Matthew Miller wrote:
On Sat, May 30, 2015 at 01:47:34AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
This is generally only a problem when these turn out to have timestamps in the future. That could be solved by automatically back-dating them (several mechanisms possible) to at least the previous day (maybe a time fixed per anaconda build?) but that would be confusing too.
Timestamps are stored in absolute time (UTC), so as long as that time does not jump backwards (because of ntp or the user updating the clock) timestamps are never in the future. When you change the timezones only the way that timestamps are displayed is changed (*).
The problem is that the installer has no idea if the system time is in UTC or in the local timezone (let alone just wrong).
Right, but we were talking about the timezone selection spoke in the installer. Getting the time wrong is an orthogonal issue.
Zbyszek
On Sun, May 31, 2015 at 01:56:41AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
The problem is that the installer has no idea if the system time is in UTC or in the local timezone (let alone just wrong).
Right, but we were talking about the timezone selection spoke in the installer. Getting the time wrong is an orthogonal issue.
Practically speaking, one of the common ways where the time ends up wrong is when the system hwclock is set to the wrong timezone (or the assumption about whether it is local time or utc is wrong).
On 06/01/2015 09:25 AM, Matthew Miller wrote:
On Sun, May 31, 2015 at 01:56:41AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
The problem is that the installer has no idea if the system time is in UTC or in the local timezone (let alone just wrong).
Right, but we were talking about the timezone selection spoke in the installer. Getting the time wrong is an orthogonal issue.
Practically speaking, one of the common ways where the time ends up wrong is when the system hwclock is set to the wrong timezone (or the assumption about whether it is local time or utc is wrong).
some of the ways tz can be wrong at install time and cause later problems:
- filesystem creation timestamp - timestamps relative to network resources (contact a repo on the network mid or post install and the packages you suck down could have timestamps in the future depending on which way you're off) - config files that get written at install time - various caches that get created at install time
we -really- wanted to pull tz selection out of anaconda when doing the redesign (we couldn't pull it out of first boot because of the OEM/third-party install case) but there were too many cases where it would blow things up, sometimes rather catastrophically, and it is extremely difficult to debug because the symptoms can be so bizarre and unpredictable. in one case, a symptom was that the icons on the system slowly started disappearing - that was because the timestamp on the icon cache was in the future IIRC and whatever reads in the icons freaked out when checking the age of the cache and getting a negative number. sometimes it results in an unbootable system post-install. sometimes random services fail bc of the timestamps on the config files (exacerbated i think by subsequent updates that move new configs to .rpmnew)
i am really not an expert in all the technical details here, as i recall jesse keating was the main person i consulted with when we were trying to determine the feasibility of pulling tz selection from anaconda. i think if the tz ends up being in UTC (and anaconda correctly detects this which it does try to do, and the system isn't booted into another OS that twiddles this back to non-UTC before the next boot) it still doesn't help because the user would be changing the tz post-install in g-i-s which is what would enable timestamps from the future.
it might be a good idea to bring this discussion to the actual installer team (anaconda-devel-list@redhat.com, not cc'ed as i see here) who are the technical experts here and could give you a much more informed take on pretty much all of the points brought up in the thread. a lot of thought and planning went into the anaconda rewrite as i am sure all appreciate here.
~m
On Tue, 2015-06-02 at 08:51 -0400, Máirín Duffy wrote:
it might be a good idea to bring this discussion to the actual installer team (anaconda-devel-list@redhat.com, not cc'ed as i see here) who are the technical experts here and could give you a much more informed take on pretty much all of the points brought up in the thread. a lot of thought and planning went into the anaconda rewrite as i am sure all appreciate here.
TBH, I think I will bring everything *except* this to the installer team. Reading the above, it doesn't sound like something worth fighting with. I see no significant advantage to having timezone selection in gnome-initial-setup, and many disadvantages, so let's drop it and focus on the other points instead.
Thanks Máirín,
Michael
----- Original Message -----
On 06/01/2015 09:25 AM, Matthew Miller wrote:
On Sun, May 31, 2015 at 01:56:41AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
The problem is that the installer has no idea if the system time is in UTC or in the local timezone (let alone just wrong).
Right, but we were talking about the timezone selection spoke in the installer. Getting the time wrong is an orthogonal issue.
Practically speaking, one of the common ways where the time ends up wrong is when the system hwclock is set to the wrong timezone (or the assumption about whether it is local time or utc is wrong).
some of the ways tz can be wrong at install time and cause later problems:
- filesystem creation timestamp
- timestamps relative to network resources (contact a repo on the
network mid or post install and the packages you suck down could have timestamps in the future depending on which way you're off)
- config files that get written at install time
- various caches that get created at install time
we -really- wanted to pull tz selection out of anaconda when doing the redesign (we couldn't pull it out of first boot because of the OEM/third-party install case) but there were too many cases where it would blow things up, sometimes rather catastrophically, and it is extremely difficult to debug because the symptoms can be so bizarre and unpredictable. in one case, a symptom was that the icons on the system slowly started disappearing - that was because the timestamp on the icon cache was in the future IIRC and whatever reads in the icons freaked out when checking the age of the cache and getting a negative number. sometimes it results in an unbootable system post-install. sometimes random services fail bc of the timestamps on the config files (exacerbated i think by subsequent updates that move new configs to .rpmnew)
i am really not an expert in all the technical details here, as i recall jesse keating was the main person i consulted with when we were trying to determine the feasibility of pulling tz selection from anaconda. i think if the tz ends up being in UTC (and anaconda correctly detects this which it does try to do, and the system isn't booted into another OS that twiddles this back to non-UTC before the next boot) it still doesn't help because the user would be changing the tz post-install in g-i-s which is what would enable timestamps from the future.
From what I can understand from this, the problem isn't actually the timezone
(because if whether I'm in New York or Timbuktu, the UTC time written to disk will still be the same). What you need is the right time. Which we could make sure to pull from the network if it's available.
And if we're not connected to the network, there's nothing extra to install and modify on the disk, we're just copying whatever's on the read-only image we're trying to install.
So, in effect, the timezone (and UTC mode switch) would only need to be available when installing data from the network, but network time isn't available.
it might be a good idea to bring this discussion to the actual installer team (anaconda-devel-list@redhat.com, not cc'ed as i see here) who are the technical experts here and could give you a much more informed take on pretty much all of the points brought up in the thread. a lot of thought and planning went into the anaconda rewrite as i am sure all appreciate here.
~m
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
----- Original Message -----
Here is an updated list of proposed changes, based on our discussion in the WG meeting today. These changes are proposed for the Workstation installer only and not other products' installers, so we assume that Anaconda will allow this level of per-product configurability. Changes are targeted for F24, not F23, and subject to further discussion with Anaconda developers.
- Remove the timezone selection spoke from either anaconda or gnome
-initial-setup. These spokes are redundant and one or the other needs to go. The reason to potentially retain it in Anaconda would be to get the timestamps of installed files correct, if we care about that.
As mentioned by Rui, this wouldn't be necessary. This could also be used to remove the uninvited GeoIP check in anaconda itself. Setting the timezone would be done after asking the user whether the system can use geolocation.
- Remove root password configuration. It's confusing how this is
different from the user's admin account password. Advanced users can set a root password after installation if desired.
Agreed.
- Remove user account creation. This is redundant with gnome-initial
-setup.
Ditto.
- Remove or simplify the network configuration spoke. In the live
installer, this spoke allows setting only the system hostname, but it follows different rules for setting the hostname than GNOME/systemd. The spoke should either follow hostnamed's rules for pretty hostnames (i.e. allows capital letters, spaces, etc. without any complaint), or the spoke should be removed. If we keep it, it should allow the user to set a "computer name" (avoiding technical terminology like "hostname") and should not include the phrase "network configuration."
It would be better for this to be done after the creation of the first user in gnome-initial-setup, so that we can have a useful default name for the computer: "Rupert Monkey's laptop" or "Bastien's desktop"
(and the rough i18n that goes with it)
Changes to gnome-initial-setup: Skip language and keyboard layout selection in user creation mode. These panels cannot reasonably be removed from Anaconda, so we should use them only in existing user mode (when a new user account is created after installation). They're redundant in user creation mode. Also, completely remove timezone selection if it remains in anaconda.
There are 3 things to note here: - the anaconda setting changes the system configuration, thus the default layouts used in gdm. - we are in a live environment, where the user can change the current configuration through the Settings panel already. This should be exported to the installed system's configuration - anaconda's layout selection doesn't support IBus, which means it's inadequate as a user layout selection tool.
I would: - make anaconda migrate the current settings to the installed system - make it possible to set IBus engines in the installed gdm's configuration
Optional: Remove hub and spokes: simply go straight to keyboard layout selection after language selection,
Only language selection should really be necessary in Anaconda, the keyboard layout can be inherited from the live environment. We could make sure to always show the language selector even if there's only one default language in the live environment (that's probably a one-liner in gnome-shell).
then from there to disk layout, optionally from there to the hostname panel, and then to the installation progress panel. This last panel will need a bit of a redesign, since it will be pretty empty otherwise. Many WG members feel this would make the installer easier to use, but we do not have consensus on this. It is unrelated to the goal of reducing redundancy between anaconda and g-i-s.
We also note that there have been many requests to simplify the installation destination spoke, but we do not have any design for this.
I'd even go a bit further, in that we should have less moving parts in the disk selection. I personally find it easier to make room on the disk using Disks (available in the Live environment) and passing that to Anaconda, or having Anaconda use the old Linux installation, or having it use the whole disk.
Cheers
On Fri, 2015-05-29 at 08:24 -0400, Bastien Nocera wrote:
As mentioned by Rui, this wouldn't be necessary. This could also be used to remove the uninvited GeoIP check in anaconda itself. Setting the timezone would be done after asking the user whether the system can use geolocation.
OK, timezone belongs in g-i-s, agreed.
It would be better for this to be done after the creation of the first user in gnome-initial-setup, so that we can have a useful default name for the computer: "Rupert Monkey's laptop" or "Bastien's desktop"
(and the rough i18n that goes with it)
Agreed, we should just get rid of the network configuration spoke.
There are 3 things to note here:
- the anaconda setting changes the system configuration, thus the
default layouts used in gdm.
- we are in a live environment, where the user can change the current
configuration through the Settings panel already. This should be exported to the installed system's configuration
- anaconda's layout selection doesn't support IBus, which means it's
inadequate as a user layout selection tool.
I would:
- make anaconda migrate the current settings to the installed system
- make it possible to set IBus engines in the installed gdm's
configuration
OK, OK... although I think it already picks up on keyboard layout if set in System Settings.
Only language selection should really be necessary in Anaconda, the keyboard layout can be inherited from the live environment. We could make sure to always show the language selector even if there's only one default language in the live environment (that's probably a one-liner in gnome-shell).
I don't think keyboard layout is any different from language selection. You *can* set both in the live environment, but they're buried under System Settings, not easy to find at all. And you can't install unless you have these set properly. So either Anaconda needs to display them both, or the live environment needs to display them both (in which case they could be removed from Anaconda).
But I agree that there is just no point to keeping hub and spokes now that we're going to request almost every spoke to be removed.
I will leave a few days to see if anyone objects, then post an updated summary on the anaconda mailing list.
I'd even go a bit further, in that we should have less moving parts in the disk selection. I personally find it easier to make room on the disk using Disks (available in the Live environment) and passing that to Anaconda, or having Anaconda use the old Linux installation, or having it use the whole disk.
I think "less moving parts" is a good goal, but it's too hazy a requirement. Further discussion is needed here. I also see value in separating out the disk selection changes from the changes to reduce redundancy with g-i-s, since we can do one without the other.
Michael
----- Original Message -----
On Fri, 2015-05-29 at 08:24 -0400, Bastien Nocera wrote:
As mentioned by Rui, this wouldn't be necessary. This could also be used to remove the uninvited GeoIP check in anaconda itself. Setting the timezone would be done after asking the user whether the system can use geolocation.
OK, timezone belongs in g-i-s, agreed.
It would be better for this to be done after the creation of the first user in gnome-initial-setup, so that we can have a useful default name for the computer: "Rupert Monkey's laptop" or "Bastien's desktop"
(and the rough i18n that goes with it)
Agreed, we should just get rid of the network configuration spoke.
There are 3 things to note here:
- the anaconda setting changes the system configuration, thus the
default layouts used in gdm.
- we are in a live environment, where the user can change the current
configuration through the Settings panel already. This should be exported to the installed system's configuration
- anaconda's layout selection doesn't support IBus, which means it's
inadequate as a user layout selection tool.
I would:
- make anaconda migrate the current settings to the installed system
- make it possible to set IBus engines in the installed gdm's
configuration
OK, OK... although I think it already picks up on keyboard layout if set in System Settings.
Only language selection should really be necessary in Anaconda, the keyboard layout can be inherited from the live environment. We could make sure to always show the language selector even if there's only one default language in the live environment (that's probably a one-liner in gnome-shell).
I don't think keyboard layout is any different from language selection.
They are, very much so.
Keyboard layout changes don't require logging in and out.
You *can* set both in the live environment, but they're buried under System Settings, not easy to find at all.
They wouldn't be buried if we always show the keyboard layout switcher in the live environment.
And you can't install unless you have these set properly. So either Anaconda needs to display them both, or the live environment needs to display them both (in which case they could be removed from Anaconda).
The idea is that if the user is comfortable using the default keyboard layout to do the installation, then, presumably, they would also be using that as the system default layout, which can be changed after installation anyway.
But I agree that there is just no point to keeping hub and spokes now that we're going to request almost every spoke to be removed.
I will leave a few days to see if anyone objects, then post an updated summary on the anaconda mailing list.
I'd even go a bit further, in that we should have less moving parts in the disk selection. I personally find it easier to make room on the disk using Disks (available in the Live environment) and passing that to Anaconda, or having Anaconda use the old Linux installation, or having it use the whole disk.
I think "less moving parts" is a good goal, but it's too hazy a requirement. Further discussion is needed here. I also see value in separating out the disk selection changes from the changes to reduce redundancy with g-i-s, since we can do one without the other.
Sure.
On Fri, 2015-05-29 at 09:35 -0400, Bastien Nocera wrote:
They wouldn't be buried if we always show the keyboard layout switcher in the live environment.
Even the keyboard layout switcher in the top bar is not really obvious enough for me.
The idea is that if the user is comfortable using the default keyboard layout to do the installation, then, presumably, they would also be using that as the system default layout, which can be changed after installation anyway.
I think we need a real keyboard layout selection screen that the user has to pass through, either before starting the installer or as one of the first steps in the installer. Same for language selection.
Crazy idea: we could reuse gnome-initial-setup for this. It could run the language and keyboard layout selection, then present the "try OS live / install OS now" options.
On 27/05/15 09:19 AM, Michael Catanzaro wrote:
Changes to gnome-initial-setup: Skip language and keyboard layout selection in user creation mode. These panels cannot reasonably be removed from Anaconda, so we should use them only in existing user mode (when a new user account is created after installation). They're redundant in user creation mode. Also, completely remove timezone selection if it remains in anaconda.
Optional: Remove hub and spokes: simply go straight to keyboard layout selection after language selection, then from there to disk layout, optionally from there to the hostname panel, and then to the installation progress panel. This last panel will need a bit of a redesign, since it will be pretty empty otherwise. Many WG members feel this would make the installer easier to use, but we do not have consensus on this. It is unrelated to the goal of reducing redundancy between anaconda and g-i-s.
We also note that there have been many requests to simplify the installation destination spoke, but we do not have any design for this.
Have you seen the second round of visual redesign of Anaconda? - Choose language - If not enough storage space, offer option to either resize the partition from existing OS or delete it - Modified Hub and Spokes that includes network, keyboard, software (for listing what are provided), source to destination -Install Maybe using "disable" word would be better than "removing" considering its flexibility.
desktop@lists.stg.fedoraproject.org
-
Bastien Nocera -
Diogo Campos -
Eric Griffith -
Jiri Eischmann -
Luya Tshimbalanga -
Matthew Miller -
Michael Catanzaro -
Máirín Duffy -
Rui Tiago Cação Matos -
Zbigniew Jędrzejewski-Szmek