Hey, it is interesting to discuss this whole "wad" further. In my opinion: We need some easy OpenSolaris4Fools installer (like now), and in addition one for the skilled loyal long-term Solaris Admins.
Ok, Xorg also went the path to hide most complexity from users, and to autodetect2TheMax. Even the previous /usr/X11/bin/xorgconf and xorgconfig utilities got EOL'ed, even xorg.conf is now optional. Well, this clearly has advantages. But for a system like Xorg there are less unknown variables. Less guesses must be made. The installation of an operating system involves much more unanswered questions. To find default answers for _everything_ is impossible. Maybe you can come close to it (while never reaching it for everybody at once). But it comes at a cost: Advanced users feel alienated by too option-less and too much simplified installers, just believe me. I talk to many educated admins and even some sophisticated distributors. Ok, for today it is a bit late. I respond later as I think through concrete steps which will be possible, and wait for further echo. A few small context diffs. Something which can be tried out. Maybe you change your original opinion in that process, maybe I do. Or everybody does. Thanks. -- kind regards, %martin On Wed, May 27, 2009 at 2:08 AM, Glenn Lagasse <Glenn.Lagasse at sun.com> wrote: > 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 >
