Robert Milkowski wrote:
> Garrett D'Amore wrote:
>>
>> You seem to have misunderstood what Darren and I have been saying.
>> Don't add complexity in the CLI tool that customers don't need or
>> really want. Do add the basic functionality that customers do want
>> -- simple historical tracking like netstat -i <interval> is probably
>> a good request.
>>
>> If customers want more than that, make it easy for them to build
>> it. (Because each customer is going to have a different want.)
>>
>> For customers that don't want raw data, but want a nicer analytics
>> thing -- that should be done with a GUI tool built on top of the
>> underlying stats. And you should still do the -i <interval> in the CLI.
> I believe that there is also a great need for tools in between
> raw-data and a full blown GUIs like Fishworks.
> That's why people are using 3rd party tools in Solaris like iftop,
> nicstat.pl, iotop, etc.
Obviously I don't think folks should have to grunge through kstat(1M)
output -- if we can provide the information that 90% of the people need
90% of the time in a simple CLI, hey, that sounds like something we darn
well ought to do.
Its the incremental changes beyond that 90% that concern me. (And yes,
I'm pulling these meaningless percentages out of my nether regions, but
the point is still valid I think.) If you have add 20% to the code
size, add architectural questions like "file stability" add a parser,
etc, and it only really solves a problem that 5% of the users of these
features need about 5% of the time, and which those 5% could easily
build themselves in less than 10 minutes of coding with a trivial bit of
shell script, then that sounds like a poor trade off to me.
So, the "-i" running increments are definitely a tool that I think hit a
large class of users a lot of the time, and which will satisfy a huge
number of customers. Probably nearly all the users would be happy with
just that.
The snapshot facility I suspect probably has a much lower threshold.
The really big paying customers already know how to solve that problem
(given the existence of a -i parseable format) themselves in the 5
minutes its going to take -- so I doubt that that particular feature has
shown up on any real product requirements. (It might have been a low
priority RFE mentioned... that I'd be inclined to believe....)
I don't really want to discuss this further... I think the team
understands my reservations, and I'm confident that while they'll make
their own decision on the matter, they've at least considered my opinion
on it.
-- Garrett
