FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Build System

 
 
LinkBack Thread Tools
 
Old 01-24-2011, 12:53 AM
Máirín Duffy
 
Default Draft proposal for using full anaconda as the default Fedora download

Hi John,

On Mon, 2011-01-24 at 00:19 +0000, John Reiser wrote:
> > I composed the DVD myself using pungi. I excluded all the @Languages by
> > commenting them out in the fedora-rawhide.ks, so the result is 2.6GB
> > instead of 3.5GB. I Fresh Installed the default Graphical Desktop to an
> > existing 16GB partition, reformatted to ext2/3/4. There were 1207 packages
> > which "df" said occupied 3.4GB on the installed root filesystem.
>
> Today I built a DVD with no excluded languages: 3.8GB total DVD size,
> 3150 packages. Graphical Desktop installed the same 1207 packages
> as before: total 3.4GB on ext4, taking the same elapsed time of 22 minutes.

These are really fantastic data points, thanks for doing this. I was
wondering if you could try the live desktop cd too, just as a point of
comparison, on the same hardware? I really hope DVD is as fast...

~m


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-24-2011, 02:26 AM
John Reiser
 
Default Draft proposal for using full anaconda as the default Fedora download

Hi Máirín,

> I was
> wondering if you could try the live desktop cd too, just as a point of
> comparison, on the same hardware? I really hope DVD is as fast...

Today's rawhide nightly compose Live Image
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20110123.17.iso
boots into Gnome shell, but the icon Activities > Applications > Install to ...
says "Can't do live image installation unless running from a live image."
The same message appears when running /usr/bin/liveinst from a text shell
on VT2; and the shell also reports a Segmentation violation from zenity.
Is there another URL that I should try?

--

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-24-2011, 04:13 PM
Bill Nottingham
 
Default Draft proposal for using full anaconda as the default Fedora download

David Cantrell (dcantrell@redhat.com) said:
> >>Internally it just uses the os.read() and os.write() Python functions.
> >>8MB at a time.
> >
> >Do you know why today's install DVD ends up being slower (45 min vs
> >10-20 min) the Desktop Live Media for the meat of the install? Are they
> >both using the same read/write functions, and it's just the DVD has a
> >bigger payload today than the desktop spin?
>
> I really don't know. My guess is that it's just the size difference, like
> you said.

The non-live installer unpacks RPMs to the filesystem, introducing multiple
layers of indirection that isn't there on the live install which is just
blasting the filesystem image to the device as fast as possible. Enhancing
RPM to be as fast as writing a filesystem image I believe falls far beyond
the scope of this initiative.

> >>>5. Constrained / curated package set, no burden on the user to configure
> >>>too much up front
> >>>
> >>>It would be possible to make the full installer behave this way too via
> >>>comps groups juggling.
> >>
> >>This really becomes a matter of solidifying what we call the "Fedora" tree
> >>vs. the Everything tree.
> >
> >Is this an okay thing to do or is it going to be a pandora's box?
>
> Any time we start talking about what is the base or core system, it's
> pandora's box. I think this was part of the goal of the spins effort, so
> anyone could go and define what they think the install media should be.
>
> I don't think it's impossible and it really does come down to perception
> and expectations on the user's side. I think it's possible to have a base
> system defined and then a handful of install variants on top of that
> (e.g., GNOME, KDE).

It would require not insiginficant changes to comps. For example, we
offer 'Sound and Video' as a group checkbox. There's no good way to make
this checkbox do a reasonably sane thing depending on which of the other
checkboxes you checked (did you check GNOME? KDE? No desktop at all?)

This is a big advantage of the live media; it's not just curated for the
default offering, but gives a good method for any use case to design for
its offering.

Stepping back for a sec, a lot of this would go back to actually designating
what the non-Live media is for. We've *never* done that, leading to it
essentially just being 'a set reasonably comparable to what was on the old
Red Hat Linux CD/DVD.' I don't see how something with that mantra helps
with our usage cases/target audience, regardless of technical benefits.

> What I was thinking is the catch-22 case of users wanting install media
> but only having one computer. The live image requires one of three
> special tools to create it, which requires access to a computer that can
> run one of those tools.
>
> For the person with a single computer, say a modern laptop, they could
> download just the install disc or get it from somewhere else, boot it, and
> then install to a USB flashdrive rather than the hard disk in their
> system. This gives them a way to try it out before committing the entire
> system to it. It's also an environment we have more control over rather
> than telling them to download a live image writing tool and run it on
> _whatever they have on the system_.

One minor issue here is referring to the install disc; I have three
'modern' laptops in my household, and *none* of them came with optical
drives. Obviously, the plural of anecdote is not data, but I think it's
a case we need to have a good answer for, even if it's no better than the
current case for live images where you need some additional tool.

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-24-2011, 08:49 PM
Máirín Duffy
 
Default Draft proposal for using full anaconda as the default Fedora download

On Mon, 2011-01-24 at 17:13 +0000, Bill Nottingham wrote:
> It would require not insiginficant changes to comps. For example, we
> offer 'Sound and Video' as a group checkbox. There's no good way to make
> this checkbox do a reasonably sane thing depending on which of the other
> checkboxes you checked (did you check GNOME? KDE? No desktop at all?)

I'm kind of thinking, drop those checkboxes. You get the equivalent of
the desktop live cd (the default offering) if you just click next next
next. Instead of having the package group selection screen
(http://docs.fedoraproject.org/en-US/Fedora/13/html-single/Installation_Quick_Start_Guide/images/pkgselection/pkg-group-details.png )
you can select different 'add-on packs'. They would all assume a GNOME
installation. Other desktops could be installed, but as 'add ons.'

(please direct death threats to spamtrap@linuxgrrl.com)

> This is a big advantage of the live media; it's not just curated for the
> default offering, but gives a good method for any use case to design for
> its offering.

This is also a huge problem with the live media.... it proliferates the
limiting notion that Fedora is a bucket o' packages rather than a
platform to build upon.

> Stepping back for a sec, a lot of this would go back to actually designating
> what the non-Live media is for. We've *never* done that, leading to it
> essentially just being 'a set reasonably comparable to what was on the old
> Red Hat Linux CD/DVD.' I don't see how something with that mantra helps
> with our usage cases/target audience, regardless of technical benefits.

Which do you mean? The mantra that designating what non-live media is
for doesn't help, or the mantra that the DVD is comparable to ye olde
RHL doesn't help?

> One minor issue here is referring to the install disc; I have three
> 'modern' laptops in my household, and *none* of them came with optical
> drives. Obviously, the plural of anecdote is not data, but I think it's
> a case we need to have a good answer for, even if it's no better than the
> current case for live images where you need some additional tool.

Absolutely. I'm in the same boat - my laptop has no optical drive.

~m

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-24-2011, 09:04 PM
Máirín Duffy
 
Default Draft proposal for using full anaconda as the default Fedora download

On Mon, 2011-01-24 at 21:49 +0000, MáirĂ*n Duffy wrote:
> On Mon, 2011-01-24 at 17:13 +0000, Bill Nottingham wrote:
> > It would require not insiginficant changes to comps. For example, we
> > offer 'Sound and Video' as a group checkbox. There's no good way to make
> > this checkbox do a reasonably sane thing depending on which of the other
> > checkboxes you checked (did you check GNOME? KDE? No desktop at all?)
>
> I'm kind of thinking, drop those checkboxes. You get the equivalent of
> the desktop live cd (the default offering) if you just click next next
> next. Instead of having the package group selection screen
> (http://docs.fedoraproject.org/en-US/Fedora/13/html-single/Installation_Quick_Start_Guide/images/pkgselection/pkg-group-details.png )
> you can select different 'add-on packs'. They would all assume a GNOME
> installation. Other desktops could be installed, but as 'add ons.'

Like this

http://farm6.static.flickr.com/5218/5385215221_73496245a9_b.jpg

~m

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-24-2011, 09:29 PM
Bill Nottingham
 
Default Draft proposal for using full anaconda as the default Fedora download

Máirín Duffy (duffy@fedoraproject.org) said:
> > It would require not insiginficant changes to comps. For example, we
> > offer 'Sound and Video' as a group checkbox. There's no good way to make
> > this checkbox do a reasonably sane thing depending on which of the other
> > checkboxes you checked (did you check GNOME? KDE? No desktop at all?)
>
> I'm kind of thinking, drop those checkboxes. You get the equivalent of
> the desktop live cd (the default offering) if you just click next next
> next. Instead of having the package group selection screen
> (http://docs.fedoraproject.org/en-US/Fedora/13/html-single/Installation_Quick_Start_Guide/images/pkgselection/pkg-group-details.png )
> you can select different 'add-on packs'. They would all assume a GNOME
> installation. Other desktops could be installed, but as 'add ons.'

My engineering mind immediately goes to 'how would we implement this in
terms of the existing infrastructure of the comps file, kickstart files,
etc.', and is somewhat confused. We could have a lot of new groups, I
guess, that are structured in this way, but it means a lot of random
packages would no longer be selectable via tha UI. This could be both
good and bad.

Another idea would be to make all the groups we have either much more
general (the desktop group would include its sound apps, the KDE group
would include its sound apps, and we could drop the general group), or
much more focused (specific task groups, like 'office-suite', or
'imap server', or similar). We could then build up logical installation
classes or installation profiles that consist of combinations of these.
(This is what another product does, of course.)

> > This is a big advantage of the live media; it's not just curated for the
> > default offering, but gives a good method for any use case to design for
> > its offering.
>
> This is also a huge problem with the live media.... it proliferates the
> limiting notion that Fedora is a bucket o' packages rather than a
> platform to build upon.

Hm. Maybe it's me, but I think the current incarnation of the non-live
media (need a better nomenclature) reinforces this even worse, actually
giving the user a pile of options to select & deselect and break themselves
with. At least with the various live media, we get something that
theoretically has been curated and tested as a unit.

> > Stepping back for a sec, a lot of this would go back to actually designating
> > what the non-Live media is for. We've *never* done that, leading to it
> > essentially just being 'a set reasonably comparable to what was on the old
> > Red Hat Linux CD/DVD.' I don't see how something with that mantra helps
> > with our usage cases/target audience, regardless of technical benefits.
>
> Which do you mean? The mantra that designating what non-live media is
> for doesn't help, or the mantra that the DVD is comparable to ye olde
> RHL doesn't help?

The latter. The non-live media has never had a real target other than the
bucket'o'packages idea, and therefore isn't really designed for anything
specific.

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-25-2011, 02:58 PM
Máirín Duffy
 
Default Draft proposal for using full anaconda as the default Fedora download

Hi Bill,

On Mon, 2011-01-24 at 22:29 +0000, Bill Nottingham wrote:
> My engineering mind immediately goes to 'how would we implement this in
> terms of the existing infrastructure of the comps file, kickstart files,
> etc.', and is somewhat confused. We could have a lot of new groups, I
> guess, that are structured in this way, but it means a lot of random
> packages would no longer be selectable via the UI. This could be both
> good and bad.

Well... regarding random packages not being selectable in the anaconda
UI - is that really a problem? Isn't it better (and I know it's not
there yet ) to have one place that's really optimized for package
picking - packagekit - and if users really want a particular set of
packages they can do post-install?

If the use case is, I'm upgrading from F13 to F14 with a fresh install
but I don't want to have to sit around for 2-3 hours trying to
cherry-pick the add-on packages I installed last time... there's
probably a better way to solve it than checkboxes in anaconda's GUI
right? Is there a different use case those package-by-package checkboxes
solve? (Noting that if you really need to spit out a bunch of systems
with a particular manifest of packages you're better off using kickstart
and skipping the GUI?)

> Another idea would be to make all the groups we have either much more
> general (the desktop group would include its sound apps, the KDE group
> would include its sound apps, and we could drop the general group), or
> much more focused (specific task groups, like 'office-suite', or
> 'imap server', or similar). We could then build up logical installation
> classes or installation profiles that consist of combinations of these.
> (This is what another product does, of course.)
>
> > > This is a big advantage of the live media; it's not just curated for the
> > > default offering, but gives a good method for any use case to design for
> > > its offering.
> >
> > This is also a huge problem with the live media.... it proliferates the
> > limiting notion that Fedora is a bucket o' packages rather than a
> > platform to build upon.
>
> Hm. Maybe it's me, but I think the current incarnation of the non-live
> media (need a better nomenclature) reinforces this even worse, actually
> giving the user a pile of options to select & deselect and break themselves
> with. At least with the various live media, we get something that
> theoretically has been curated and tested as a unit.

Ah totally agreed. I wasn't really clear what I meant, sorry; what I
mean is that the spins work off of the everything bucket-o-packages and
kind of start with a clean slate every time, rather than Fedora having a
defined, familiar platform for end-users that you build the spins on top
of. (Does that make sense?) I guess you could say it is a platform wrt
how spins work today, but it's a very low-level platform that doesn't
include a desktop and some of the bits under the desktop.

Also thank you for the 'theoretically' (she says after the experience of
discovering the design suite spin had no networking stack for some
weeks)

> > > Stepping back for a sec, a lot of this would go back to actually designating
> > > what the non-Live media is for. We've *never* done that, leading to it
> > > essentially just being 'a set reasonably comparable to what was on the old
> > > Red Hat Linux CD/DVD.' I don't see how something with that mantra helps
> > > with our usage cases/target audience, regardless of technical benefits.
> >
> > Which do you mean? The mantra that designating what non-live media is
> > for doesn't help, or the mantra that the DVD is comparable to ye olde
> > RHL doesn't help?
>
> The latter. The non-live media has never had a real target other than the
> bucket'o'packages idea, and therefore isn't really designed for anything
> specific.

It'd be nice to fix that wouldn't it?

~m

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 01-25-2011, 03:14 PM
Bill Nottingham
 
Default Draft proposal for using full anaconda as the default Fedora download

Máirín Duffy (duffy@fedoraproject.org) said:
> On Mon, 2011-01-24 at 22:29 +0000, Bill Nottingham wrote:
> > My engineering mind immediately goes to 'how would we implement this in
> > terms of the existing infrastructure of the comps file, kickstart files,
> > etc.', and is somewhat confused. We could have a lot of new groups, I
> > guess, that are structured in this way, but it means a lot of random
> > packages would no longer be selectable via the UI. This could be both
> > good and bad.
>
> Well... regarding random packages not being selectable in the anaconda
> UI - is that really a problem? Isn't it better (and I know it's not
> there yet ) to have one place that's really optimized for package
> picking - packagekit - and if users really want a particular set of
> packages they can do post-install?

It makes sense, yes. I'm just trying to organize what we currently have,
where the package groups (and the attributes around the packages -
mandatory, optional, etc.) are exposed as installable entities:

- in anaconda, in this group selection screen
- in anaconda/kickstart, in %packages
- in yum, post-install
- in PackageKit, post-install

So, changing what anaconda does in group selection to do something else
(or removing group selection entirely), without changing where it's exposed
elsewhere doesn't help us as much.

Now, if it just means we expose the groups solely as groups (i.e., no
individual package selection in them), then we don't need as much drastic
surgery. Although, I do wonder if the same interface makes sense for all
the logical groups we have - for example, a desktop environment should
likely be a single group that is installed and removed as a unit, but I
could see the Games group as something that's better served by a browsing
interface.

> > Hm. Maybe it's me, but I think the current incarnation of the non-live
> > media (need a better nomenclature) reinforces this even worse, actually
> > giving the user a pile of options to select & deselect and break themselves
> > with. At least with the various live media, we get something that
> > theoretically has been curated and tested as a unit.
>
> Ah totally agreed. I wasn't really clear what I meant, sorry; what I
> mean is that the spins work off of the everything bucket-o-packages and
> kind of start with a clean slate every time, rather than Fedora having a
> defined, familiar platform for end-users that you build the spins on top
> of. (Does that make sense?) I guess you could say it is a platform wrt
> how spins work today, but it's a very low-level platform that doesn't
> include a desktop and some of the bits under the desktop.

Tossing out ideas - if we really want a defined platform, then why not
build at compose time an image of that platform, embed it on the media,
install it via the live method, and then reboot into that platform to
install packages/groups on top of it to customize?

Obviously this complicates the installer, and if the RPM installation is
as repeatable as it should be, it may not be worth the effort to optimize it
in this way.

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 02-24-2011, 06:28 PM
John Reiser
 
Default Draft proposal for using full anaconda as the default Fedora download

On 01/23/2011 05:53 PM, Máirín Duffy wrote:
> On Mon, 2011-01-24 at 00:19 +0000, John Reiser wrote:

>> Today I built a DVD with no excluded languages: 3.8GB total DVD size,
>> 3150 packages. Graphical Desktop installed the same 1207 packages
>> as before: total 3.4GB on ext4, taking the same elapsed time of 22 minutes.
>
> These are really fantastic data points, thanks for doing this. I was
> wondering if you could try the live desktop cd too, just as a point of
> comparison, on the same hardware? I really hope DVD is as fast...

Finally, a Fedora 15 Live spin that installs: the 22-Feb-2011 edition of
http://serverbeach1.fedoraproject.org/pub/alt/stage/15-Alpha.RC1/Live/x86_64/Fedora-15-Alpha-x86_64-Live-Desktop.iso
I burned the 570MB to DVD+RW.

clock stage
----- ------
00:00 Install to harddrive...
02:15 Copying from 4X DVD+RW to harddrive
05:02 Checking copied [installed] filesystem
06:55 Congratulations! [done] 1097 packages occupying 2.56GB of ext4;
9.14MB/s average over 280 seconds

That's on 2.0GHz Athlon64 to ext4 on SATA 3.0Gbit/s.
memtest86+-4.10 reports
L1 64K 15705 MB/s
L2 512K 3888 MB/s
mem 3328M 1819 MB/s DDR1 128-bit

On newer hardware the General Desktop install from DVD is 09:08 (mm:ss).
That's on 3.0GHz Core2 Duo E8400
memtest86+-4.10 reports
L1 32K 42249 MB/s
L2 6144K 19606 MB/s
mem 8191M 4444 MB/s DDR2 128-bit

On a newer AMD box, General Desktop install from DVD is 09:32 (mm:ss).
That's on 3.2GHz PhenomII x2
memtest86+-4.10 reports
L1 64K 52695 MB/s
L2 512K 17007 MB/s
L3 6144K 9236 MB/s
mem 4095M 3652 MB/s DDR2 128-bit

--

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 04:52 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org