> > So I'm confused here. You've made some claims, which is that legato > needed this kind of package. I'll take that for granted. But what I > don't understand is *why*.
Because Sun didn't either provide a changer driver or generic SCSI bus access. Even if Sun had provided a changer driver, generic SCSI bus access would have been preferable. There are always cases where the native feature set provided by a platform is less than the market needs, or is outright broken. It's not that Legato shipped command line tools that user could use- it incorporated them into internal libraries and provided a generic uscsi access. This was so it would write software once and use a generic uscsi interface across win32, AIX, Linux, IRIX, SunOS (yes, Solaris 1), Solaris and so on. > > I freely admit I don't have years of experience with SCSI. But I do > work on device drivers for a living. I can't imagine a situation > where I need a shell utility to perform actions on a bus, *except* > when I'm doing debugging. And in those cases, honestly, I usually > wind up either downloading something or using a custom written tool. > (Usually the latter.) > > I *never* ship any of those bits (the test bits) to my customers, nor > do I make my software depend on them. I have a hard time > understanding why these kinds of low-level tools would be provided by > a 3rd party ISV to users. That is one perspective on development. In principle, I agree with you. This is not entirely the reality on the ground now. Incorporation of command line tools to perform device functions, or subsuming the io control paths used by those functions into non-CLI type tools certainly is not a big surprise. I can easily see a case where I would ship a production package that would use something out of sg3_utils to collect information, parse it, and use it. If it's not part of a critical data path but is an important adjunct to, say, configuration, or FRU information gathering, I'd use it just like I'd use smartmontools. Why rewrite things when they work "well enough"? If someone (my boss in a startup) says "this function needs to be done next week" you can bet I'm not going to say "the product absolutely cannot work unless we do a formal design, document, review, prototype, etc.." if it's something straightforward like "run lsscsi and grep for device "FOO"". It's swell if you work for a company that allows you the luxury of doing traditional engineering. My experience with consulting over the last 15 or so years has indicated that this kind of approach is getting harder and harder to find. In fact, the whole reason I came back to Sun for the current gig was that doing so would afford me the time one rarely gets to try and do things correctly. I'm not arguing therefore that we shouldn't respect such practices and try and follow them. I'm just suggesting that the customer base for where a lot of this seems to be going has a much less restrictive set of expectations than you express, and has less patience with "we can't give you your favorite tool BAR because it doesn't meet *our* standards" than you can possibly imagine. > > Again, I'm just trying to understand the utility here to end users > that justifies integrating this as a first class package (with RBAC > and such) into Solaris. Why do ordinary end-users need this stuff? > (Or even ordinary developers. I don't include developers for storage > products because their needs are special, and I *suspect* they fall > outside the target audience that the "familiarity" justification was > intended for.) > > So it may not need to be a first class package. This is what I was groping for in other mail. You want to provide correctly engineered systems. But you also want to provide tools for developers who might not share your opinion about what is correctly engineered. Whether it's a first class package or not, having it there without requiring people to install it or dork with it is a win. End users who use this system for non-development purposes could care less about what packages are included or whether they're first, fifth or completely unsuipported- they just want it to work. But is this the target market? It's not like we are marketing decisions here, but if the game is to try and capture mindshare (again), then it's developers, not end-users, who need to be stroked, and a lot of these developers don't necessarily even understand the issues you talk about let alone agree with your take on them. Like I said, it's a balance that has to be struck, and from what I've seen over the years since I've been back is that, IMHO, the balance is still to much toward the classic Solaris SDF model. Again, IMHO. -matt
