I think it's time we took this discussion to install-discuss. Please remove opensolaris-discuss from replies.
Instead of requiring that we unpack to a RAM based miniroot, have we explored the option of mounting compressed filesystems on the CDROM, and using symlinks in the miniroot, when the system is under a certain amount of RAM. (Generally, compressed filesystems increase IO throughput, in exchange for CPU cycles. This is particularly true on "slow" storage media). I think it is possible that this option has not been explored, because there may not have been a supported compressed filesystem before the recent changes to ZFS. Thanks, Brian On 8/28/07, Sarah Jelinek <[EMAIL PROTECTED]> wrote: > Hi Richard and All, > > Just a few comments inline... specific to the steps we took in the > Caiman installer related to this discussion. > > >>> Oh C'mon. 512Mb is not enough to run Windoze XP > >>> reasonably - even if > >>> you can actually install it. With 1Gb memory > >>> > >> DIMMs > >> > >>> around $50 (or > >>> less), expecting to run a state-of-the-art OS in > >>> 512Mb is "absolutely > >>> unacceptable". If you're serious about > >>> (Open)Solaris, then you're > >>> serious about your hardware. > >>> > >> We should never, under any circumstances, defend > >> regression. > >> > >> Regression is an error. A severe and serious error. > >> Dealing with regression has been one of the main > >> selling points of Solaris. If Solaris starts > >> regressing now, it will have lost one of the most > >> crucial competetive edges. > >> > >> > We didn't regress with Dwarf Caiman. We are within the existing memory > checks that the Solaris installer has had in them for some time. This is > our current requirements: > > 1. SXDE3 (Dwarf)- 786MB - we do exit out if the user doesn't have > enough memory. We tell them to go to the text based installer. Now, 768 > is a high limit for Dwarf. We know we can run under less memory, but not > on any reasonable boundary where we can lower this requirement at this > time. But, we are working on this. > > 2. SXCE - Interactive GUI - 768MB(same as it has been for a long time) > > 3. Text installer - windows based - 512MB > > 4. Console based text installer - > 256MB - its not quite 256MB any > longer. Not sure exactly the numbers though. > > >> We should also stop defending every bad decision and > >> hiding behind "engineering" for everything that just > >> plain isn't right: > >> > >> making that installer Java-based and Java-dependent > >> was just plain bad decision and it caused regression. > >> Rather than hiding behind claims that Java is great > >> and that it's "engineering", the responsible > >> person(s) should admit the error and fix it. > >> > > > > > With Dwarf and subsequent Caiman projects we have moved from the Java > based GUI to Gnome and C. This should help some, but it doesn't mitigate > all the size issues in the miniroot. > > No disagreement with most of that, except that I'm not sure I see > > increases in memory requirements (even for the duration of installation) > > as regression as such, even if they may a real obstacle. Unless of course > > working on a specified minimum configuration is a distro objective that was > > violated. > > > > I see a lot of tradeoffs here (ease of use, flexibility, speed, minimum > > hardware requirements, development resources needed to optimize the > > balance of the previous, etc). The present situation may suck, but a > > balance that would satisfy all interests may not be feasible. > > > > Or to put it another way, for whatever you want, what would you be > > willing to give up? :-) > > > > Part of the problem may be RAM-resident miniroot bloat. Seems to me > > that only volatile data _needs_ to live there; everything else could be > > on the installation media. However, optical media is slow in the face > > of a lot of seeks. Dividing miniroot space requirements into volatile > > data vs cache for performance might help; the latter could be built in > > increments based on available resources, so that a system with ample RAM > > could install very quickly, but a slimmer system would still install, if > > slowly. That is, divide the possible miniroot contents into multiple > > cpio (or tar, as you prefer) archives on the installation medium, grouped > > so the most benefit comes with the initial increments. Depending on > > how much RAM is available, load zero or more of those into the miniroot > > (over and above the skeleton needed to hold e.g. device files, symlinks, > > directories, config files needed during installation, etc); set $PATH so > > that those tools would be found first on the miniroot, and if not there, > > on fully-populated versions of the miniroot directories stored on the > > installation media. RPATH would be set in the executables to look for > > libraries similarly. > > > > > Actually, what you describe is what we do, partially. As part of the > work on Dwarf I separated out what needed to be in the part we call the > 'miniroot', x86.miniroot archive, and created several new archives that > hold the data that may or may not be used depending on the path the user > chooses for installation. We unpack only the archives necessary. This > helps with the RAM situation. We no longer load Java when it isn't > needed. We don't load Gnome when the user has chosen the Java GUI. > > But, we don't, at this time, run anything from the media until much > later for the Tools install. This is something we are looking in to > doing. As you note, there may be performance issues with this approach. > > A modular installer could also lend itself to both flexibility (character vs > > GUI vs answering as much as possible from site config/policy store) and to > > having no more of itself resident at any given time than reasonably > > necessary. > > > > > Regards, > sarah > *** > > > > This message posted from opensolaris.org > > _______________________________________________ > > opensolaris-discuss mailing list > > [email protected] > > > > > _______________________________________________ > opensolaris-discuss mailing list > [email protected] > -- - Brian Gupta http://opensolaris.org/os/project/nycosug/ _______________________________________________ opensolaris-discuss mailing list [email protected]
