David Cantrell (dcantrell@xxxxxxxxxx) 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
