So, with everything else you said, wouldn't it make more sense for these
bits to live in /usr/lib (linux might be libexec), since they're not
something intended for end-users to run from the command line?
I confess I'm still unhappy with the justification here -- are the next
programs going to be a bunch of utilities to toggle interrupt status
registers on the CPU? Is it our goal to make it possible to write
device drivers in shell script? (I know Roland would just *love* to
write one in ksh93...)
These days we have libscsi and friends. Application developers should
be able to use those directly. Yeah, its not conducive to building
enterprise grade software out of sh or perl code (though I confess I'd
probably be less upset if this were delivered as a perl library... but I
am not sure I can really justify why, apart from the fact that it makes
clearer the target audience is for software development rather than for
end-user consumption.)
I know this isn't supposed to be a popularity contest, but are there any
concrete examples of 3rd party applications built upon these bits? Is
this case a solution looking for a problem?
-- Garrett
Matthew Jacob wrote:
>>
>> 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
>
