Peter Tribble wrote: > On 3/1/07, Dave Miner <Dave.Miner at sun.com> wrote: >> >> On what basis do you believe that we will end up requiring more memory? >> Do you have data you can point to? And what do you think is a >> reasonable memory requirement for a graphical installation? >> >> We believe that, when all's said and done, the Caiman GUI will require >> no more memory than the current graphical installer. We don't have data >> yet, either, but that's because we're only just starting to work out the >> design issues for the changes needed in supporting the new >> implementation. I'm expecting we'll be able to keep the required memory >> around 512 MB for the graphical case. > > I have serious concerns here as well, which is why I asked about caiman > pulling in bits of gnome. We understand these concerns. We are using Gnome for the Dwarf Caiman GUI and the Caiman GUI's in general, but we won't just pull in Gnome bits on top of the already large amount of stuff in the miniroot. It is our plan to separate the gnome bits from the general X/dtwm bits so that we load only what we need, specifically in the solaris developer express path. Certainly, we are not trying to make the memory situation any worse.
We are looking at ways to help minimize the memory footprint in the graphical installer. Part of our reason to use C as the implementation language was in an effort to reduce the dependency on Java. It wasn't the only reason, but memory requirements were a consideration in this decision. The Dwarf Caiman team has placed the memory requirements at a high priority for our project. As Dave notes, we don't have all the details because we are still working through the design issues to make the changes. We will post more data as we have it. thanks, sarah *** > > I don't know about anybody else, but I regard the current memory minimum > as excessive. The 768M minimum for the developer edition ought to be > considered unacceptable. > > The install has to run and complete for pretty well any install > configuration > on systems with 512M memory. Why 512? For one, it's a fairly common > configuration (particularly for those who might wish to reuse a not > exactly > cutting edge system to try Solaris - think of systems that can't run > Vista > as a target); for another, Sun still sell systems with 512M memory. > > (The latter implies to me that, with a 5-year support life, that it > should be > possible in 5 years time to install the then-current version of > Solaris on > such a machine.) > > I know that there is a trend - particularly over the last couple of > years - for > considerable amounts of bloat to have crept in, but realistically 512M > is a > lot of memory just to boot a machine and copy some files to a disk, so > we shouldn't have any difficulty in getting into 512M and ought to be > able > to do much better. > >> We're absolutely thinking about the Solaris future, and with our limited >> resources we actually tend to focus more on optimizing for that future >> than on the past. We're not wholly insensitive to the desires of >> developers who don't have the latest and greatest hardware, but by the >> time Nevada becomes an actual Solaris release, does it make sense to >> optimize our decision-making around, say, systems with a single 1 GHz >> processor and 256 MB of memory? It doesn't seem likely to me. > > Again, Sun are still selling 1GHz machines - indeed, recently introduced > new models at that speed. Sparc hardware tends to last forever, so we > are going to have to live with that level of performance (and early > US-III > systems) for a long time to come. As for memory, 256 is probably a bit > on the low side but such a machine would still be useful in many contexts > so it ought to be possible, although the optimization point probably > ought > to be 512. >
