Chris Rijk wrote: > Hi, thanks for posting this. I was impressed with the PDF content - > very good work. >
Thanks! > The rest of this post is a bunch of semi-random thoughts and ideas, > some trivial and some would be major long-term projects. Please view > this as a collection of ideas that I think might be interesting or > useful, not a list of demands. > OK. > > *) In general, I really like the idea of the Live DVD, particularly > the "install without reboot" possibility. However, for people who have > already installed Solaris before and know they want to install it > again, particularly those wanting to install OpenSolaris, one request > I have would be to try to eliminate the requirement for burning DVDs > (or CDs). It seems really lame to have to download an ISO image, then > burn it (hoping it went okay) then boot off it. > No, you won't have to do that, but I didn't make it very clear in the version that was published. I'm envisioning that Sun or other vendors of OpenSolaris-based systems would be able to provide a direct installation service based off of some of the concepts our WAN install technology uses. Burning ISO's should be a last resort, actually. > For most stand-alone computers though, this is hard to avoid. So my > idea is as follows: make use of bootable USB (and Firewire) devices - > particular CompactFlash cards. That is, a simple boot program could be > downloaded and installed onto such cards (something based on GRUB > perhaps). The main install files would be on the hard disc. > > Imagine a person who has just bought a new Windows laptop and wants to > install Solaris/OpenSolaris. The process would go something like this: > 1) download a single install file and place it in a fixed location (eg > c:\SOLARIS_INSTALL\ or something), (2) download program which creates > bootable Flash card for current OS (Windows). (3) reboot computer (4) > The Flash card's boot program looks at the hard disc(s) for install > binaries and finds some in c:\SOLARIS_INSTALL\, and gives the user the > option to install from it (and also sort out the partitions if > necessary), (5) install begins. > > A similar process could be used for users with just Linux installed. > > Obviously such a function would require the Flash card boot program to > be able to read various file system types. > > As well as removing the need (and time taken and possibility for > errors) to burn a DVD, this also makes it MUCH easier to do custom > installs, and also to include other software packages. ie in the > c:\SOLARIS_INSTALL\ directory could include a file listing > configuration options. That file could then be used instead of an > interactive installer, making the entire install process automatic. > Interesting thoughts. We definitely would like to make it possible to initiate an install strictly from something like a USB memory stick; with sufficient hacking around with GRUB you should be able to run a network install from one right now. Pretty soon the capacities will be such that I think we'll want to publish directly usable images for that case. We'd been kicking around some ideas around using virtual machine technology to run the install under Windows or Linux as it would be simpler for us architecturally, but that also has the problem of requiring the user to have an OS and virtualization platform which can do that. Being able to grab the install image out of a Windows or other filesystem would be another possibility. One of my colleagues suggested the other day that perhaps we should just skip the whole "coexist in FDISK" problem in the belief that virtual machine technology will prove to make installing multiple OS's that are separably bootable a quaint practice. He does have a point, but I'm not sure it's the right answer within the next couple of years. > > *) As an side note to the above, being able to install and run Solaris > itself from a USB/Firewire Flash card could be fun for the appliance > market. (Some companies offer "Flash drives" that are basically Flash > with a hard disc form factor and ATA/SATA interface) Eg, for server > blades, instead of having a hot little hard disc, you could have a > cool little Flash card to boot off. > > When it was announced that Niagara / UltraSPARC T1 was GPL'd, a > start-up announced that it was going to create a 1 core chip for the > embedded market. Imagine a little embedded system with such a chip, > 512MB of main memory and a 2-4GB Flash "drive", and one or two 1 Gb > Ethernet ports. Super low-power, super compact and no moving parts. It > won't be long before cheaper 4GB CF cards cost $100. In a few years > they'll be $25. One of our main problems there is how to handle the writable portions, since the duty cycles for flash drives aren't quite up to hard drive standards. I think we'll have to do a stronger job of separating software from configuration and logging to make that a reality. In principle, though, it's not too different from our suggested diskless direction, wherein we'd just download and run images in memory. So perhaps we'll have it almost there, anyway. > > > *) Above I suggest using a pre-created file to automate installation. > In general about automation, I would say that any complex task that > many people will need to do frequently should be automated as much as > makes sense. After all, that is one of the basics of IT - to save > "costs" (time, reduce errors) by automation. For any sort of > installation automation scripts, there should be a "central" (probably > separate for OpenSolaris and Solaris though) repository of up-to-date > examples for common scenarios. > > The availability of installation automation options should also be > made clear in the interactive installer - and they should be hard to > miss as well (not buried in some help sub-menu). It should also be > clear from the website to download install files that automation > options are available. The reason I say this is that it would be a > shame to have a nice useful feature and then people don't realise it > exists. > As one of the goals is to have the best automation capabilities, these are good ideas to help achieve that. Keep an eye out as we proceed on design, we're going to try to address it. > > > *) A minor observation on interactive installers: Every one I've seen > separately asks for locale specific information several times - eg > what keyboard, what timezone and what language. Most installers simply > default to assuming everyone is from the US and using US specific > components. > > It would be nice to see installers try to smartly guess locale > information from the hardware - or at least make use of previous > selected options. Eg, if someone selects a timezone for the UK, they > probably have a UK keyboard and want a "UK english" locale - such > choices shouldn't be hardwired, but the installer to change the > default offering. This minimises the amount of changes users have to > make when going through the install options. Saves time and increases > the chance of the user making the correct/best selections. > We're working on some things to improve this already, but one problem, as I understand it, is that a lot of the really cheap keyboards don't give you any usable type codes so we have to go manual far more often than we'd like. But leveraging one input to handle others is certainly a good principle to apply. > Similarly, when forced to select the type of keyboard, it can be > rather hit and miss - most keyboards don't have their type code > printed on them. So it would be nice to have a way to double > check the keyboard type after selecting one from a list. > As I recall, Red Hat (or was it SuSE?) used to have some sort of option for testing that you'd picked the right layout. I'll make a note to look into that one. > > *) For the graphical user interface to the interactive install, I > would suggest something like this: have a window with a set of > coloured and labeled tabs on the left. The colouring would be based on > whether information is required (coloured red say), whether changes > may be required (coloured orange), and whether they're okay (coloured > green). The bottom left tab would essentially be "start install". Each > tab would be a stage in the install. This would be in addition to > "next" and "previous" buttons in the main window. > > The reason for this being that if *all* you get is next and previous > you can't tell how many stages you have to go through to get to the > end. With the buttons, advanced users can also take short cuts through > the installer in a simple way. > My UI designer will probably have some interesting reactions to the specific suggestions ;-), but yes, your main point that wizards which don't tell you where you are in the process, and don't provide ways to move around more gracefully than pressing the back button 20 times, are unfriendly is a good one. We'll try not to make that mistake. > > *) It should be relatively simple to create secure (reasonably > locked-down) installs, even with the interactive installer. Maybe this > would better be part of post installation and general configuration - > since confirming that an OS is nicely locked down right now and being > able to fix common issues is a reccuring problem, though secure on > install means less of a window of opportunity for attacks. At a > minimum, "legacy" (ie where there are better/more secure options > available) server software should not be active by default - though > maybe installed by default. > This one gets into controversial territory. The hard-core minimizers argue that any bits that they don't need to run should never even be installed. We've had a lot of discussion on this topic in recent months, and at some point I'm going to have to put together a reasonable story to address it. But yes, we completely agree that locking down shouldn't be purely an install-time decision, and older, deprecated services shouldn't be on by default in most cases. You'll start seeing some movement here in Solaris Nevada really soon now. > > *) Now that Sun's C/C++/Fortran compilers are available for free, it > would be nice if the Sun Studio C/C++ command-line tools (at a > minimum) came with the OS as standard. > Yeah, wouldn't it? Not something I can make a decision about, but it's a constant topic of conversation. > > *) This is more of a high-level package management comment, while I'm > in the area, as it were: for any package, some nice meta information > to include would be details about support (possibly including links). > For example, the Apache HTTPD package that comes with Solaris should > include some meta information say that it is a *supported* package - > and maybe also reference forums where free support may be available. > For software on the "companion CD", the packages would include > information about it not being supported, but could obviously provide > links which may help. > Yes, tying the package database more directly to the documentation and support would be a very good enhancement. Noted. > > *) How well can Solaris x86 live with MacOS X on x86? > Seems like Apple's going out of their way to discourage this, but perhaps they'll see the error of their ways eventually. I imagine we'll be in the same situation as Linux here, but I haven't been paying too close attention to this specific issue. Perhaps someone else can pipe up if they have any thoughts. Thanks for all the thoughts, Chris! Dave
