In case it wasn't clear, this case would void the TCR for PSARC 2009/585.
Assuming that a +1 is received in before then, it was agreed at PSARC to
shorten the timeout on this case to allow it to be approved earlier than
would normally be done.
-- Garrett
Garrett D'Amore - sun microsystems wrote:
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
> EOF sag
> 1.2. Name of Document Author/Supplier:
> Author: Garrett D'Amore
> 1.3 Date of This Document:
> 16 November, 2009
> 4. Technical Description
> EOF of sag
> ----------
>
> As part of the process of unravelling dependency trees to allow
> removal of some other antiquated software, we have run into a situation
> where sag(1) is the last linchpin preventing cleanup of a bunch of other
> legacy components.
>
> sag is a tool that generates Tek 4014 format graphs from the output of
> "sar". These graphs can be viewed using either the Tek mode window
> in xterm(1), or by further converting them to PostScript using posttek(1).
>
> It turns out that the mechanism which sag uses to generate graphs is
> incompatible with more modern graphing solutions as it has a few hacks
> that depend on the specific quirks of legacy graph(1). An initial
> effort at converting the tool to use GNU graph proved to be ... non-trivial,
> due largely to the very hackish nature in which the sag abuses graph.
>
> Additionally, these hacks, and other limitations in the tools, actually
> produce suboptimal output... indeed this author would even go so far as
> to call them outright "ugly", compared to what can be generated with
> more clean solutions based on gnuplot, etc.
>
> While it is certainly the case that sag could be updated to use
> gnuplot much more elegantly, it is our belief that the effort required
> to do so, and to preserve complete command line syntax, is an expense
> that is out of balance with the rewards of any such effort. The sag tool
> itself is so limited, unfriendly and awkward that we believe that most
> sites that have wanted graphical display of sar data have sought
> other solutions: either implementing scripts around gnuplot or spreadsheet
> programs in house, or by using other 3rd party solutions.
>
> It turns out that there are a much more functional, and usable, options
> available from third parties. One example we've looked at in some detail
> is kSar (http://ksar.atomique.net/), which is available as an Open Source
> Java application. While still having a few rough edges, we believe that
> this product (and other options like it) represent a much better solution
> for administrators looking to graphically process sar data.
>
> With this in mind, we are requesting to EOF the sag application altogether.
> We believe that its loss will be felt by very few, and that the expenses
> of keeping sag around far outweigh any benefit we gain by doing so.
>
> We are expressly requesting permission to do this without having a plan
> to integrate a "replacement". kSar could potentially be integrated in
> the future, but we would prefer not to have this as a dependency for
> this effort. Ultimately we believe that this is a case where 3rd party
> tools should be used to answer the different needs of administrators.
> There is no "drop in" replacement for "sag", in any event.
>
> (Aside: the use of sar based statistics itself is perhaps something
> that warrants further examination. In the OpenSolaris era, we have
> other options, such as JKstat, and DTrace, which might arguably be
> claimed offer far more options for detailed observability into the
> system workings. That said, many many organizations over the years
> (decades!) have come to rely on raw sar data to help them better understand
> what their systems are doing. We believe sar is likely to have utility
> for some years to come, as a result.)
>
> 6. Resources and Schedule
> 6.4. Steering Committee requested information
> 6.4.1. Consolidation C-team Name:
> ON
> 6.5. ARC review type: FastTrack
> 6.6. ARC Exposure: open
>
>
