> >For the standard hard disk size we see now, 50GB is nothing. Netbooks > >present > >a different use case. Are those users interested in a separate /home by > >default? Should we care? > > > > Yes (for example to only crypt /home, which is a nice performance boost > given netbook's speed, also for all the some reasons not netbook users > are interested in a separate /home) The problem with this is that coming up with the split values when you only have 8 GB or 10 GB or 15 GB is way harder, and the consequences of getting it even a little wrong are much larger. If the user's got 200 GB to work with and we end up making / 5 GB too large, probably not a problem. If they've only got 10 GB to work with and we make / 2 GB too large, that's probably a much bigger problem. > So I would like to propose the following instead: > If the VG > 30 GB (32 GB - 2GB for /boot and overhead), do a split > /home and split things between home and /, 50/50 until / grows over > 50 GB at which point we start only growing /home Well, see my previous comments about how we don't recommend a separate /var, /usr/local, etc. by default and also needing enough space for preupgrade. If they only have 30 GB to work with, we're giving them a 15 GB home. Is that enough for an installed system, and another whole system's worth of packages, plus whatever other crud the user may have laying around? > >Given how hard the live install concept is sold, I think it would be > >worth our > >time to do something for this use case. > > > > Hmm, then again live installers may end up installing tons of stuff, > like openoffice, development tools, ... I don't really see the > space needs here being that much different after a couple of months of > use. True, the user could add a bunch of other stuff later. However, one good thing about the livecd case is that we know the size of the payload up front, so we can at least make slightly smarter suggestions. I'm not completely sold on this idea yet but it's worth thinking about. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
