Sunay Tripathi wrote:
>
>>>>
>>>> Systems administrators, for whom commands like this are
>>>> targetted, are regularly writing scripts in perl, shell, python,
>>>> whatever.
>>>>
>>>> So, yes, I do expect them to because I know they do.
>>>>
>>>> Been there, done that - it's part of the "job description".
>>>
>>> Huh!! Would love to meet some people who fit that description.
>>
>> Here! I was a UNIX admin at Qualcomm for about 4 years before I
>> joined Sun. Ran a network of some 800 Sun's, a variety of PCs, etc.
>> Did most of the tools development for the group at the same time.
>
> And you think few of you (who also happen to be Solaris developers)
> fit the common profile of a system administrator
> of today? Or because you were once a system administrator, we
> should design based on your requirement. I have been on
> customer trip for last 2 months (having met over 30 customers) and
> most of them don't have people or time to do our work. Perhaps
> instead of arguing with me on customer requirements, make a tour
> and get your facts straight.
I think too many times in the past such data collection was gathered by
talking to CEOs and CIOs, and not talking to the grunts in the field who
really know what they want. If that's not what has occurred here, then
its a refreshing change. (I've seen so many tools come out of Sun built
by what are perceived market requests, but which suck so badly just
because either the market requests came from folks who don't use the
tools -- like executives -- or were interpreted by engineers at Sun who
have no day-to-day sysadmin experience and so don't really understand
the requests.
Again, I'm not saying that it is what has happened here, just wanting to
make sure it *isn't* what happened. You've already indicated it isn't.
>
> I apologize if I am sounding a bit hard but its preconceived notions
> like this (without any facts) that makes it harder for Solaris to
> penetrate new markets on new customers. Instead of trying to make
> things simple and incrementally better (where we can), we end up
> arguing that if I am able to it, then so should everyone else. And
> the result is we constantly get slammed for being too complex and
> hard to use.
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.
>
>>>> While there's an obvious need for the likes of "dlstat -i 2",
>>>
>>> As long as we are clear on that .
>>
>> I don't think anyone is contesting that.
>>>
>>>> it's building in the "diff" capability that I'm questioning.
>
> And how do you think dlstat -i 2 will do the diff? Anyway, I
> noted the concerns around more intricate snapshot option (and
> kind of agree with that). We will look into simplifying it. If
> you or Darren have any other tangible concerns, please let us
> know.
Its the snapshotting ability (named snapshots or whatever) that I was
contesting. Any admin can come up with a solution of his own in about 5
minutes for that by just redirecting the output to a named file.
Keeping a running tally the way vmstat/netstat -i do is a reasonable
feature plan.
I'm done on the topic now.
- Garrett
>
> Cheers,
> Sunay
>
