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 > opensolaris-discuss@opensolaris.org > > _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
