8:15 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:58 a.m.
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.
8:03 a.m.
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
8:10 a.m.
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.
8:43 a.m.
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
8:54 a.m.
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
9:03 a.m.
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
9:08 a.m.
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.
11:23 a.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:56 p.m.
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.
3:08 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10:25 a.m.
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.
3780
days inactive
3781
days old
desktop@lists.fedoraproject.org
11 comments
5 participants
participants (5)
-
Adam Williamson -
Jóhann B. Guðmundsson -
Matthias Clasen -
Michael Catanzaro -
Ryan Lerch