Jim Grisanzio wrote: > I love how the writer thinks we "began to expose" these "weak points" > "earlier this year" when in fact engineers have been working on this > for quite some time. The install process is greatly improved from S10, > and we as a community are going to improve it even more. Typical > clueless media with almost zero knowledge of the history of the > OpenSolaris project. > I'd venture that the problem here could be addressed most effectively by creating some helper libraries cf libapt, making it easy to master a live CD, and *documenting* (or making such documentation more accessible) what needs to be in place on the disk for a successful boot - and what utilities exist for hardware detection etc.
In principal, creation of an installer should be a straightforward user interface development task, and it seems to me that its one that can be done quite effectively in any number of RAD languages. I think Shawn is completely mistaken by suggesting that there is any justification to write the installer GUI as a C program for any sort of performance reason, though I'd think that Java is probably a poor choice due to the minimal footprint. Personnally I'd be tempted to look at wxLua or something similar, but there's plenty of choice. For a while, Linux distributions had some differentiation in usability of installer (including hardware detection) and its clearly been quite a big deal - it seems to me that in an ideal world the task of actually doing the install should be orthogonal to creating what will be installed, and it should be possible to regard the installer as just another package to put onto a live CD that can work with resources to create a bootable disk image -- and it may be possible to provide a selection of installers which can run against the same packages and hardware detection. Then we're not stuck with 'one size fits all' and can encourage geeky competitiveness.
