James Carlson wrote:
> Matthew Ahrens writes:
>
>> This project delivers the following executable perl script:
>> /usr/benchmarks/filebench/filebench
>>
>
> Not mentioned here is that this seems to establish a precedent for a
> directory called /usr/benchmarks, with subdirectories for each
> benchmark.
>
> It seems to be akin to /usr/demo/ (is that right?), but the semantics
> are somewhat unclear, as it seems unlikely that anyone would deliver
> more than handful of executables in any directory, and likely that
> it's just a single file per directory.
>
> Are there other things that might fit here? Future plans?
>
> An update to filesystem(5) to describe this new hierarchy would be
> helpful.
>
>
>> User Commands filebench(1)
>>
>> NAME
>> filebench - framework of workloads to measure and compare
>> filesystem performance
>>
>
> Nit: since it's on a non-default path, I think this man page should
> include the full path.
>
> Would it make sense to have a new subsection (say, 1BENCH) to collect
> these man pages together? Otherwise, I think it seems a little odd to
> have things in section 1 that aren't going directly into /usr/bin.
>
Not to pick on "Filebench", but it seems like we are throwing
everything, including
the kitchen sink, into Solaris. If we had a distribution repository
(like Ubuntu/Debian),
we would just make it available in the repository, and be done with it.
Hopefully,
we (Sun and/or OpenSolaris and/or "The State which can not be named") will
have such a repository at some time.
But alas, we don't have such a repository. We have a couple of
"Meta-Clusters", which
fit into each other like "Russian Dolls". Placing this in the
"Developer Cluster" (rarely
used) places it into the "ALL" bundle and ends up a lot of places.
It doesn't seem appropriate to push back against Filebench, because we don't
have "repository" today.
Can we do something (in OpenSolaris) to track which new items are
clearly items
which would not be included in "standard" bundles? Classifying this as
Uncommitted
goes a long way to make this feasible. Should I be concerned about more
than that?
Maybe this is only a *real* concern for something "Committed", but
"repository
appropriate"?
Comments?
Oh yea, a real observation on this proposal:
Why not Volatile? Benchmarks are often enhanced on a whim and sometime
those whims can be incompatible. What is the value (in this rare
case) of more
stability.
- jek3
