Peter Tribble wrote: ... > First thoughts: > > Section 2 > > Audience - you're looking at the SMB/Developer segment, and the > enterprise segment. This ignores another important class, specifically > the lone user. (Some use the term "hobbyist", but I want to avoid that.) > The lone user may have the opportunity to play with Solaris - either > installing it themselves, or using a system installed by a friend or > colleague. This class of user may well become a developer or customer > later, and carries their experience with them. They have less > experience and knowledge, less motivation, and much lower tolerance > than developers. >
We were positing that what you term a hobbyist is a developer for our purposes, but perhaps that's lumping them too coarsely. We'll consider it, though I'm not sure how much difference it would actually make in the requirements and recommendations - if you see places where it would, I'd appreciate you pointing them out. > > 2.1 You say that the scale of operations is not necessarily large > enough to justify complex automation techniques, yet I would argue that > (a) automation shouldn't be complex, and (b) automation is justifiable > even for single-system setups (think recovery). In other words, while > they would not initially have an environment in which automation were > possible, we should ensure that they find it as easy as possible to > automate procedures thereafter. > Good points. > > 2.1.1 We should aim that *everyone* finds the software easy to > use. Even "experts" could save time and make fewer mistakes. > Agreed, there's every intention that it'll be easier, faster, and less error-prone for everyone. ... > The two biggest problems *I* have with the install: > > 1. How abysmally painfully slow it is. More on that later... > > 2. The software selection system is useless. > > Software selection: the fundamental problem is that there are far too > many packages. (Note that the notion of package here does not imply the > SVR4 packaging system - I'm simply using a package as a related group > of files, and a cluster as a related group of packages.) The way the > product is split up into packages and clusters has no relevance to the > end user whatsoever. > I've taken a fairly weak position on the granularity, because there are reasons for fine-grained packages, and Solaris isn't particularly unique in this respect - it seems common in the Linux and BSD realms, too. The relevance of what's presented to users is the principal issue that I think this strategy can address, and I agree with your high-level point that the clusters and other grouping elements need to become first-class objects within the software maintenance system. ... > > > 2.1.7 > > I can't understand the lukewarm comparison of Solaris install > performance with others. "It's the perception that we're slower." It's > not a perception: -it's reality. And the gap is *huge*. Experience in > the late S9/S10 beta timeframe was that Solaris is slower than (say) > RedHat by a factor 5-10. > Since we haven't run controlled comparisons to generate objective numbers, I didn't feel it was justifiable to make too much of anecdotal data. We will be running those comparisons and baselines to establish performance objectives. ... > > 2.2.1 > > Saving jumpstart - not only from an interactive installation - > ideally the install choices would be saved as a jumpstart profile (and > sysidcfg file) to a standard location, but also from an installed > system, so that you can go to a system, and generate a jumpstart > profile and sysidcfg file that would reproduce that system. > Agreed. > > Section 3 - Requirements. > > 20. Or select an alternative nameservice. On the same screen as the > account set up, have an extra entry with a check box "use a network > nameservice for accounts" and a dropdown of NIS/NIS+/LDAP. It may even > be possible to guess. I don't see any nameservice integration mentioned > - it's a crucial component. > Good point. > 29. Absolutely. But this isn't an installation issue so much as > ensuring that the appropriate subsets (metaclusters) are independent of > the underlying OS version. > > > Section 4 - Caiman > > (Let's hope that Caiman doesn't inherit Anacaonda's propensity for > crashing.) > We'll apply our usual quality standards, so I assume not. > Perhaps the Solaris best practices should be made availabele and > pointed to - are they correct and still relevant? > Where they exist, they're usually published under the blueprints program. We have a number of other recommendations that we've never formalized, as well. I'm not sure whether we'll have a lot of resources to put into this, but it's one thing I think the sysadmin community might be able to help out with here. > 4.1.1 > > I talked about metaclusters above. I'm unsure whether a choice of the > entire Solaris release is sensible. What services are enabled or > disabled? Is it advantageous to discriminate based on system type (if > graphical install desktop...)? > I think on an advanced path we can offer all sorts of alternatives. But I really want the main path to be a streamlined, get you running as quickly as possible, experience. As a first approximation, I think the whole release is reasonable and avoids some of the sticky software management problems. As we get those improved, then a cut-down default might be more feasible. Thanks for the feedback, Peter! Dave
