On Sat, Jun 27, 2009 at 2:17 AM, Sunay Tripathi<Sunay.Tripathi at sun.com> 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 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. > >>>> 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.
As someone who is currently a sysadmin (but does a bit of development on the side), and having worked at both large and small Sun customers, here are the use cases I can think of off the top of my head: 1. Data collection for long(er) term storage & analysis. Think RRDs or such. Essentially, provide the raw counters in an easily parseable format. Whatever is collecting the values can take care of any necessary calculations (rrdtool for example understand the notions of counters and can take care of generating interval values or rates from the raw data). This allows me to compare current behavior with past behavior, do trending, etc. 2. Formatted output (for humans) for immediate troubleshooting. Think vmstat, mpstat, or especially nicstat (I know it's not included, but it should be :P). This would mean calculating differences over a user-supplied interval, and ideally calculating average rates over that interval as well. In this case, readability is more important than parseability, though it doesn't mean you can't have both (just not required). It is possible with #1 to write a script to do this, however, my experience is that a lot of places consider 'scripting' to be an advanced (or sometimes very advanced) skill, so I'd rather see it included in some fashion. I don't think meeting these two requirements would be too complex and I think would strike a good balance between minimal & too much. #2 is probably good enough for most people just wanting a tool they can look at, while #1 would allow for those that want something more feature-rich or complex to develop it on their own (which I suspect would be a minority of people).
