Hi Martin, * Martin Bochnig (martin at martux.org) wrote: > On Wed, May 27, 2009 at 1:20 AM, Glenn Lagasse <Glenn.Lagasse at sun.com> > wrote: > > Hi Martin, > > > > * Martin Bochnig (martin at martux.org) wrote: > >> ... ? both for Gtk- as well as for the upcoming Curses- based installers. > >> Then let's ask users at time of install-begin, if the want a setup > >> based on default choices (current installer), or rather if they prefer > >> to explicitly specify as many things as possible themselves. > > > > So, if I understand you correctly you're advocating two installation > > code paths for each installer type (gui and text). ?So a sum total of 4 > > possible installation scenarios, gui-simple, gui-expert, text-simple and > > text-expert. ?Is that right? > > > > Cheers, > > > > -- > > Glenn > > > Hey Glenn, > > 8 interactive installers, not 4 (don't forget SPARC please).
I'm not forgetting Sparc. Regardless, There are currently *zero* plans to implement a graphical installer for Sparc. Given graphics support on Sparc hardware (revenue generating), that's not likely to change any time soon. There's just no ROI. That said, when I refer to 'installers' I don't line them up based on the architectures they support. I fully expect the text installer to work on both Sparc and X86 but it's still just one installer. > > Yes, that's what most folks would expect. > IMO it makes sense. IMO, I don't think it does. :-) The gui installer's overriding goal was to be simple. Simple such that people who had never used Solaris/OpenSolaris could sit down and perform an installation with minimal support. While at the same time, doing enough things to actually produce a useable installation. I think we've nailed that on the head based on reviews and feedback we've received. The goal for users who needed more customization was to either do it post-installation (which presumably if you needed to do so you were more versed in how the system works and could do so) or use the Automated Installer which allows more choices. Adding more code paths as you're suggesting increases the burden on this gruop to not only implement such a thing, but to also keep it maintained. To talk nothing of the support cost and testing costs. For perceived little value imo. An installer should do the things that can't reasonably be changed post-installation and that's it (in my opinion). An example might be for setting ZFS compression on the root pool. While you can change the setting post installation, it has zero effect on the data that's already on the disk. I think any discussion about what to add to the existing installers in terms of what they do has to start around that premise. Having a 'simple' code path and an 'expert' code path (that differ widely) just seems unsound to me. Things which can't be reasonably changed post-installation are either candidates to include in an installer (like my ZFS example) or bugs in the system (where the reason is that there's no mechanism to actually make the change). > Fortunately the default OS/Net handles all the different platforms and > word-size of kernels automatically on Solaris, so including sun4u, > sun4v, (64bit only kernels), i86pc, (and xVM aka Xen) i86hvm, i86xpv > (each as 32bit i386-kernel plus as 64bit-amd64-kernel) the overall > list of supported platforms is meanwhile quite big. But that's not too > much the installers job. > Only that all the boot_archives/miniroots/microroots should be split > to save pre-install-boot-time RAM. > > To save more RAM it is further advisable, that the installer detects > low-memory configurations (from 256MB [later, now 512MB] to sub-2GB) > and should setup an install-time auxilliary swap volume after warning > the user of making sure that the disk is backed up and empty. Minimizing a liveCD to run in 512M of ram is challenging (to say the least, having been involved in that exercise). Getting it to run in a 256M environment is simply not attainable imo unless you want to really start dropping things that make the OpenSolaris LiveCD actually usable as a LiveCD. We could for instance, drop supporting both 32-bit and 64-bit on a single cd. We could also use some other window manager instead of Gnome that was perhaps more lightweight. But then you're not showcasing the system which is what I always believed a liveCD should actually try to do. That said, it's possible that the text installer could function in a memory configuration lower than 512M (if you were to say run it from a command line login off the liveCD without a windowing system. But that project isn't off the ground enough to know at this point. Cheers, -- Glenn
