Hi, folks. So as a quick test of the DVD / live package set stuff, I just built an F21 live image from fedora-live-desktop.ks - rather than fedora-livecd-desktop.ks .
Even with absolutely no tweaks or optimization, it comes out at the huge size of...1.2GB.
So I think it's entirely feasible to bump the size target to 2GB, drop fedora-livecd-desktop.ks entirely, and just build from fedora-live-desktop.ks, giving the live image the same package set as DVD. We wouldn't wind up with a crazy huge image or anything, and we'd have lots of space inside the size target and not have to worry about that problem.
There are certainly optimizations possible; if we did this, we could focus more on optimizing things in comps. One obvious one is the dep chain that pulls in perl. fedora-livecd-desktop.ks drops 'linux-atm' from the live image to prevent perl getting pulled in and save space. In comps, linux-atm comes in via the 'dial-up' group. So an obvious tweak there is to move 'dial-up' from being a default group for GNOME to being an optional group - this makes sense anyway, I think. People who still use dial-up or plug directly into a PPPoATM modem or something can select the group easily enough, everyone else doesn't get useless stuff.
If any of the other package drops on the live image make sense to preserve for a larger live image and DVD install, we can look at how to implement them in comps (ideally).
If people are interested in this I can come up with a concrete proposal pretty fast, I think. Even with the whole three-product thing rolling along, I think it makes sense to do this, since it wouldn't be particularly difficult and would simplify things a lot; I think it's possible that the 3 product stuff gets pushed out to F22, and if that happens, it'd be nice not to have fuss about the size limit and differences between DVD and live installs for F21 testing.
On Sun, 2013-12-15 at 18:15 -0800, Adam Williamson wrote:
Hi, folks. So as a quick test of the DVD / live package set stuff, I just built an F21 live image from fedora-live-desktop.ks - rather than fedora-livecd-desktop.ks .
Even with absolutely no tweaks or optimization, it comes out at the huge size of...1.2GB.
So I think it's entirely feasible to bump the size target to 2GB, drop fedora-livecd-desktop.ks entirely, and just build from fedora-live-desktop.ks, giving the live image the same package set as DVD. We wouldn't wind up with a crazy huge image or anything, and we'd have lots of space inside the size target and not have to worry about that problem.
There are certainly optimizations possible; if we did this, we could focus more on optimizing things in comps. One obvious one is the dep chain that pulls in perl. fedora-livecd-desktop.ks drops 'linux-atm' from the live image to prevent perl getting pulled in and save space. In comps, linux-atm comes in via the 'dial-up' group. So an obvious tweak there is to move 'dial-up' from being a default group for GNOME to being an optional group - this makes sense anyway, I think. People who still use dial-up or plug directly into a PPPoATM modem or something can select the group easily enough, everyone else doesn't get useless stuff.
Keep in mind that a lot of what you see in those kickstart files is historic - I don't know if linux-atm still pulls in perl, or if something else does by now.
If any of the other package drops on the live image make sense to preserve for a larger live image and DVD install, we can look at how to implement them in comps (ideally).
If people are interested in this I can come up with a concrete proposal pretty fast, I think. Even with the whole three-product thing rolling along, I think it makes sense to do this, since it wouldn't be particularly difficult and would simplify things a lot; I think it's possible that the 3 product stuff gets pushed out to F22, and if that happens, it'd be nice not to have fuss about the size limit and differences between DVD and live installs for F21 testing.
This goes a bit against some of the long-term plans we have for the desktop spin, which is to make it smaller, not bigger. One of the reasons for working on gnome-software is that we need a user-friendly way to install applications to get out of having to pre-install them all.
Maybe the Fedora workstation product will change these plans, but even then I don't think 'just make it bigger' is the right answer.
On mán 16.des 2013 13:58, Matthias Clasen wrote:
This goes a bit against some of the long-term plans we have for the desktop spin, which is to make it smaller, not bigger.
I'm no desktop expert but to me this is being approached the wrong way.
Stop looking at the size and focus on the end user experience in the end of the day that's what matters not the size...
JBG
On Mon, 2013-12-16 at 14:03 +0000, "Jóhann B. Guðmundsson" wrote:
On mán 16.des 2013 13:58, Matthias Clasen wrote:
This goes a bit against some of the long-term plans we have for the desktop spin, which is to make it smaller, not bigger.
I'm no desktop expert but to me this is being approached the wrong way.
Stop looking at the size and focus on the end user experience in the end of the day that's what matters not the size...
Thanks, that is exactly what we are doing.
On mán 16.des 2013 14:10, Matthias Clasen wrote:
On Mon, 2013-12-16 at 14:03 +0000, "Jóhann B. Guðmundsson" wrote:
On mán 16.des 2013 13:58, Matthias Clasen wrote:
This goes a bit against some of the long-term plans we have for the desktop spin, which is to make it smaller, not bigger.
I'm no desktop expert but to me this is being approached the wrong way.
Stop looking at the size and focus on the end user experience in the end of the day that's what matters not the size...
Thanks, that is exactly what we are doing.
Upstream perhaps downstream historically and currently ( with Adam's proposal which simply increases the size to the $next_target_size which is wrong ) not so much.
We need to diminish that thought entirely, essentially say to ourselves it will be what it will be, It might be large it might be small we do not care since our focus is entirely on the end user experience ( which logically speaking cannot be determine by or be allowed to be dictated by size )...
JBG
On Mon 16 Dec 2013 09:43:59 AM EST, "Jóhann B. Guðmundsson" wrote:
On mán 16.des 2013 14:10, Matthias Clasen wrote:
On Mon, 2013-12-16 at 14:03 +0000, "Jóhann B. Guðmundsson" wrote:
On mán 16.des 2013 13:58, Matthias Clasen wrote:
This goes a bit against some of the long-term plans we have for the desktop spin, which is to make it smaller, not bigger.
I'm no desktop expert but to me this is being approached the wrong way.
Stop looking at the size and focus on the end user experience in the end of the day that's what matters not the size...
Thanks, that is exactly what we are doing.
Upstream perhaps downstream historically and currently ( with Adam's proposal which simply increases the size to the $next_target_size which is wrong ) not so much.
We need to diminish that thought entirely, essentially say to ourselves it will be what it will be, It might be large it might be small we do not care since our focus is entirely on the end user experience ( which logically speaking cannot be determine by or be allowed to be dictated by size )...
JBG
One could also argue that user experience also includes the time to download & install an operating system. If the live image is bloated, this will negatively impact the experience for users using slower internet connections. The size of the image should still be something that is _considered_, not just thrown out as a "we don't have to care about this anymore".
regards, ryanlerch
On mán 16.des 2013 14:54, Ryan Lerch wrote:
One could also argue that user experience also includes the time to download & install an operating system. If the live image is bloated, this will negatively impact the experience for users using slower internet connections. The size of the image should still be something that is _considered_, not just thrown out as a "we don't have to care about this anymore".
One could make the counter argument of the way being forward is always update/upgrade from the point of installment thus it ( the action of installment ) being one time action and or conducted on rare occasion ( when something fails ) which would distribute the cost of download over a longer period of time ( after the initial installment ) thus nullify that argument you make.
JBG
On Mon, 2013-12-16 at 08:58 -0500, Matthias Clasen wrote:
This goes a bit against some of the long-term plans we have for the desktop spin, which is to make it smaller, not bigger. One of the reasons for working on gnome-software is that we need a user-friendly way to install applications to get out of having to pre-install them all.
I don't think this is incompatible with your plans, it just requires doing the work of dropping stuff in comps instead of in the kickstart. Why not drop these unwanted packages from gnome-desktop in comps, and add them to a new group, say gnome-extra? Then the user installing via DVD can check that group if he knows to do so and wants the full set, but by default, he'll get the same (or near the same) result as he would have using the live CD.
What we're hoping to do is remove the arbitrary distinction between GNOME installed from the live CD and GNOME installed from the DVD. It'd be nice if the results were the same (or as close to the same as is politically possible -- hello rsyslog).
Maybe the Fedora workstation product will change these plans, but even then I don't think 'just make it bigger' is the right answer.
If you don't have enough space for evolution-help on the live CD, then I think that is sufficient justification to make it bigger.
On Mon, 2013-12-16 at 09:08 -0600, Michael Catanzaro wrote:
On Mon, 2013-12-16 at 08:58 -0500, Matthias Clasen wrote:
This goes a bit against some of the long-term plans we have for the desktop spin, which is to make it smaller, not bigger. One of the reasons for working on gnome-software is that we need a user-friendly way to install applications to get out of having to pre-install them all.
I don't think this is incompatible with your plans, it just requires doing the work of dropping stuff in comps instead of in the kickstart. Why not drop these unwanted packages from gnome-desktop in comps, and add them to a new group, say gnome-extra? Then the user installing via DVD can check that group if he knows to do so and wants the full set, but by default, he'll get the same (or near the same) result as he would have using the live CD.
What we're hoping to do is remove the arbitrary distinction between GNOME installed from the live CD and GNOME installed from the DVD. It'd be nice if the results were the same (or as close to the same as is politically possible -- hello rsyslog).
Maybe the Fedora workstation product will change these plans, but even then I don't think 'just make it bigger' is the right answer.
If you don't have enough space for evolution-help on the live CD, then I think that is sufficient justification to make it bigger.
We already gave up on CD size. For F20 we targeted 1GB (power-of-ten bytes), and it's pared _to the bone_ to make that.
Matthias, I was going to say something similar to Michael: I can take your point in theory, but in practice it's difficult to see how you can possibly achieve the goal of a full GNOME environment in 1GB. Even with all the potential change on the table with the fedora.next stuff, I don't see that there's enough fat to cut to be able to say confidently that we'll be able to deliver what we want as the coherent GNOME experience inside of 1GB for the foreseeable future.
Look at the significant stuff that's cut from the current live:
%packages # reduce the office suite in size -planner -libreoffice-xsltfilter -libreoffice-pyuno -libreoffice-emailmerge -libreoffice-math
# remove some other applications -gnome-boxes -gnome-dictionary
# Dictionaries are big # we're going to try keeping hunspell-* after notting, davidz, and ajax voiced # strong preference to giving it a go on #fedora-desktop. # also see http://bugzilla.gnome.org/681084 -aspell-* -man-pages* -words
# Help and art and fonts can be big, too -evolution-help -desktop-backgrounds-basic -*backgrounds-extras -stix-fonts
# These things are cut purely for space reasons -aisleriot -brasero -brasero-nautilus -bijiben -gnome-system-log -deja-dup -eog -gnu-free-mono-fonts -gnu-free-sans-fonts -gnu-free-serif-fonts -uboot-tools -dtc
especially that last section, those are things the desktop team clearly wants in the Proper Experience, as they're in the GNOME desktop comps group (most of them). They're being cut "purely for space reasons". At bare minimum, it seems like you'd somehow need to cut enough space from the 'deliverable' (whatever it winds up being, with fedora.next) both to get all those things back in, and to account for future bloat, or else we'll be stuck on the 'try and find some space to save in a raging hurry every milestone' train.
On Mon, 2013-12-16 at 09:23 -0800, Adam Williamson wrote:
We already gave up on CD size. For F20 we targeted 1GB (power-of-ten bytes), and it's pared _to the bone_ to make that.
Don't forget that RPM changelogs have been deleted from specs in order to save space. (I didn't even realize those were installed.)
especially that last section, those are things the desktop team clearly wants in the Proper Experience, as they're in the GNOME desktop comps group (most of them). They're being cut "purely for space reasons".
I think the comment is halfway outdated: those GNOME apps were indeed removed to save space, but I'm not sure that Matthias would put them back even if there was enough room. None of those apps are really necessary, and the plan is for some of them to be featured in GNOME Software. So I don't think they're necessarily part of the Proper Experience.
Anyway, I'm not fond of most of the other drops. LibreOffice Math, for example, is not just some silly add-on program, it provides formula support for LibreOffice Writer, which is disabled if you use the live CD, but not if you install with the DVD. That's an important feature. And dropping user help, especially for a complicated program like Evolution, seems really excessive.
On Mon, 2013-12-16 at 14:56 -0600, Michael Catanzaro wrote:
On Mon, 2013-12-16 at 09:23 -0800, Adam Williamson wrote:
We already gave up on CD size. For F20 we targeted 1GB (power-of-ten bytes), and it's pared _to the bone_ to make that.
Don't forget that RPM changelogs have been deleted from specs in order to save space. (I didn't even realize those were installed.)
especially that last section, those are things the desktop team clearly wants in the Proper Experience, as they're in the GNOME desktop comps group (most of them). They're being cut "purely for space reasons".
I think the comment is halfway outdated: those GNOME apps were indeed removed to save space, but I'm not sure that Matthias would put them back even if there was enough room. None of those apps are really necessary, and the plan is for some of them to be featured in GNOME Software. So I don't think they're necessarily part of the Proper Experience.
Cool, but that's not a problem for making the experience consistent: just do it in comps instead, put them in an option group.
Since the current framing of the proposal seems to be blocking on fedora-next, can I do some judo and make the proposal "Let's decide on a coherent GNOME package set and define that in comps instead of in the spin kickstart" instead? If there's something desktop really really wants that can't be done in comps - dropping stuff that's in @default , or something - then that will have to stay in the kickstart, but I think we could move stuff like the above into comps.
On Mon, 2013-12-16 at 09:23 -0800, Adam Williamson wrote:
Matthias, I was going to say something similar to Michael: I can take your point in theory, but in practice it's difficult to see how you can possibly achieve the goal of a full GNOME environment in 1GB. Even with all the potential change on the table with the fedora.next stuff, I don't see that there's enough fat to cut to be able to say confidently that we'll be able to deliver what we want as the coherent GNOME experience inside of 1GB for the foreseeable future.
Look at the significant stuff that's cut from the current live:
%packages # reduce the office suite in size -planner -libreoffice-xsltfilter -libreoffice-pyuno -libreoffice-emailmerge -libreoffice-math
# remove some other applications -gnome-boxes -gnome-dictionary
# Dictionaries are big # we're going to try keeping hunspell-* after notting, davidz, and ajax voiced # strong preference to giving it a go on #fedora-desktop. # also see http://bugzilla.gnome.org/681084 -aspell-* -man-pages* -words
# Help and art and fonts can be big, too -evolution-help -desktop-backgrounds-basic -*backgrounds-extras -stix-fonts
# These things are cut purely for space reasons -aisleriot -brasero -brasero-nautilus -bijiben -gnome-system-log -deja-dup -eog -gnu-free-mono-fonts -gnu-free-sans-fonts -gnu-free-serif-fonts -uboot-tools -dtc
especially that last section, those are things the desktop team clearly wants in the Proper Experience, as they're in the GNOME desktop comps group (most of them). They're being cut "purely for space reasons". At bare minimum, it seems like you'd somehow need to cut enough space from the 'deliverable' (whatever it winds up being, with fedora.next) both to get all those things back in, and to account for future bloat, or else we'll be stuck on the'try and find some space to save in a raging hurry every milestone' train.
Again, what I was trying (poorly) to describe is not so much about size or bloat, but about conceptual clarity - you install the OS as a unit, but applications are separate from it and can be installed, played with, removed, separately.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Jóhann B. Guðmundsson -
Matthias Clasen -
Michael Catanzaro -
Ryan Lerch