Garrett D'Amore...
gd78059@sac.sfbay.su...
|
|
|
|
EOF of plotting components [PSARC/2009/540 FastTrack timeout
10/21/2009]
Posted:
Oct 7, 2009 10:56 PM
|
|
The following fast track (submitted on my own behalf) straddles (IMO) the
boundary between a full-case and a fast track, primarily because of the
impact it has on what are presumed to be Committed interfaces.
It seems fairly straight-forward to me, but other members may feel otherwise.
With that in mind, if a member feels discussion or an explicit vote is
required, please don't hestite to derail it. I've also used a two-week timer
to ensure that sufficient time is given for members to review and derail if
that is appropriate. Thanks.
- Garrett
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 of plotting components
1.2. Name of Document Author/Supplier:
Author: Garrett D'Amore
1.3 Date of This Document:
07 October, 2009
4. Technical Description
EOF of plot, graph, lpr -g, and related legacy
----------------------------------------------
As part of my analysis of UCB legacy we can potentially clean up, one of the
items that came up is the support for legacy plotters via the plot(4B)
file format, libplot, graph(1), and the various /usr/ucb/ plotting commands.
It turns out that these bits are used to support physical devices which are
no longer readily accessible, and probably have not been so in quite a long
time. (These devices largely date back to the 70's, 80's, and early 90's.)
Modern devices use PostScript or HP-GL/2, neither of which are
supported by the current Solaris plotting infrastructure, but are well
supported via the same infrastructure used to support ordinary printers.
There is also support for plotting to a terminal device, either a graphics
or a text based terminal. The graphics terminals that are supported are
quite ancient (although "xterm" can emulate a Tek 4013 device), and the
project team feels that the plotting support for character
based terminals is of rather limited use.
Note also that users who might still have such ancient hardware (or want
to plot to a terminal device) might find they are able to plot to it using
the "gnuplot" command, which has output drivers for it. (Gnuplot is not yet
integrated, but this is expected as it was approved as part of PSARC 2009/395.
If the PSARC members feel the rest of this case warrants sufficient risk
to justify it, this project team is willing to accept delivery
of PSARC 2009/395 as a pre-requisite, although we don't particularly
feel that it should be so.)
Proposal
--------
1) We propose to entirely remove all of the plotting commands from
/usr/ucb. This consists of
/usr/ucb/aedplot
/usr/ucb/atoplot
/usr/ucb/bgplot
/usr/ucb/crtplot
/usr/ucb/dumbplot
/usr/ucb/gigiplot
/usr/ucb/hp7221plot
/usr/ucb/hpplot
/usr/ucb/implot
/usr/ucb/plot
/usr/ucb/vplot
/usr/ucb/t300
/usr/ucb/t300s
/usr/ucb/t4013
/usr/ucb/t450
/usr/ucb/tek
We don't believe any applications will be impacted by this removal.
2) We propose to remove /usr/bin/graph. We believe this program is also
not terribly useful, since the only way to generate plotting output from it is
with one of the above commands, which almost certainly precludes being
able to get hardcopy. (And graphical display is probably limited to output
in an xterm tek window, for users with enough savvy to figure this part out.)
Note that gnuplot offers a vastly superior superset of graph(1)'s capabilities,
and is capable of processing graph(1) input files. (It would probably be
only a small task to provide a shell-script called "graph" that offered
the same command line switches as graph(1), but used gnuplot to generate
its output. The utility of this seems questionable, however, unless the
output format is changed from plot(4B) -- which gnuplot can generate -- but
which would also defeat any compatibility purpose.
3) We propose to obsolete libplot(3plot) and its brethren, but leave the
libraries in place for the benefit of applications which may have linked
against them in the past. (It is impossible to know what those applications
might be.)
The specific taxonomy changes are (note that no stability was ever mentioned
before for these libraries, so we assume Committed for this use):
/usr/lib/libplot.so.1 Obsolete Committed
/usr/lib/lib300.so.1 " "
/usr/lib/lib300s.so.1 " "
/usr/lib/lib4014.so.1 " "
/usr/lib/lib450.so.1 " "
/usr/lib/libvt0.so.1 " "
Note: Its likely that these libraries could be safely removed -- despite
the "Committed" level -- or replaced with stubs that simply resolve the
symbols but don't actually generate any output. We simply don't believe
any real programs use these libraries but we don't know for sure.
4) We propose to remove the "-g" option to /usr/ucb/lpr, which was intended to
support the plot(4B) format. Again, real devices which could benefit
from these filters are just not to be found in the modern era. Lpr would
exit with an error number if this option is supplied.
Note that /usr/ucb/lpr is already effectively obsolete, by virtue of being
delivered in /usr/ucb. Also, CUPS lacks support for this option, so
eliminating it will facilitate an eventual replacement of our legacy printing
stack with the far more functional and better-maintained CUPS implementation.
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
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
Posts:
1,582
From:
US
Registered:
6/14/05
|
|
|
|
Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009]
Posted:
Oct 8, 2009 4:05 AM
in response to: Garrett D'Amore...
To: OpenSolaris » arc
|
|
> Note also that users who might still have such ancient hardware (or want
> to plot to a terminal device) might find they are able to plot to it using
> the "gnuplot" command, which has output drivers for it. (Gnuplot is not yet
> integrated, but this is expected as it was approved as part of PSARC 2009/395.
> If the PSARC members feel the rest of this case warrants sufficient risk
> to justify it, this project team is willing to accept delivery
> of PSARC 2009/395 as a pre-requisite, although we don't particularly
> feel that it should be so.)
GNU plotutils (_not_ gnuplot, something different, I gather) looks like a
superset of all the old traditional plotting tools. Unfortunately, it also
looks like even its libraries may be GPL and not LGPL, which may preclude
it as a drop-in replacement, unless the commands linking to its libraries
are also GPL. (at least given the common interpretation of these matters)
[...]
> Proposal
> --------
>
> 1) We propose to entirely remove all of the plotting
> commands from
> /usr/ucb. This consists of
>
> /usr/ucb/aedplot
> /usr/ucb/atoplot
> /usr/ucb/bgplot
> /usr/ucb/crtplot
> /usr/ucb/dumbplot
> /usr/ucb/gigiplot
> /usr/ucb/hp7221plot
> /usr/ucb/hpplot
> /usr/ucb/implot
> /usr/ucb/plot
> /usr/ucb/vplot
> /usr/ucb/t300
> /usr/ucb/t300s
> /usr/ucb/t4013
> /usr/ucb/t450
> /usr/ucb/tek
>
> We don't believe any applications will be impacted by
> this removal.
So tplot(1) and /usr/lib/t[0-9]* and /usr/lib/vplot won't be affected?
What about sag(1)?
[...]
> 4) We propose to remove the "-g" option to
> /usr/ucb/lpr, which was intended to
> support the plot(4B) format. Again, real devices
> which could benefit
> from these filters are just not to be found in the
> modern era. Lpr would
> exit with an error number if this option is supplied.
[...]
Any of the lpr filter-type options imply (for a remote printer)
something in lpd protocol. Even if the local system doesn't
implement the corresponding content type (and it could,
since postplot(1) implements plot(4b) format and lp -Tplot
equates to lpr -g, as far as I can tell (non-CUPS)), the remote
system might. So I don't see the value of removing any of the
lpr(1b) options prior to getting rid of lpr altogether.
|
|
|
|
|
Posts:
1,172
From:
US
Registered:
3/9/05
|
|
|
|
Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout
10/21/2009]
Posted:
Oct 8, 2009 10:06 AM
in response to: Garrett D'Amore...
|
|
Garrett D'Amore - sun microsystems wrote:
> The following fast track (submitted on my own behalf) straddles (IMO) the
> boundary between a full-case and a fast track, primarily because of the
> impact it has on what are presumed to be Committed interfaces.
Thanks for doing this; it's well past time for these to go.
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber dot eng dot sun dot com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout
10/21/2009]
Posted:
Oct 21, 2009 7:30 AM
in response to: Garrett D'Amore...
|
|
On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems
wrote:
> The following fast track (submitted on my own behalf) straddles (IMO) the
> boundary between a full-case and a fast track, primarily because of the
> impact it has on what are presumed to be Committed interfaces.
>
> It seems fairly straight-forward to me, but other members may feel otherwise.
> With that in mind, if a member feels discussion or an explicit vote is
> required, please don't hestite to derail it. I've also used a two-week timer
> to ensure that sufficient time is given for members to review and derail if
> that is appropriate. Thanks.
I don't see a release binding associated with this case. I give this
case a +1 assuming that the binding is not less than Minor (i.e., this
is not applicable for Patch or Micro).
-Seb
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Garrett D'Amore
gdamore@sun.com
|
|
|
|
Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout
10/21/2009]
Posted:
Oct 21, 2009 2:44 PM
in response to: seb
|
|
Sebastien Roy wrote:
> On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems
> wrote:
>
>> The following fast track (submitted on my own behalf) straddles (IMO) the
>> boundary between a full-case and a fast track, primarily because of the
>> impact it has on what are presumed to be Committed interfaces.
>>
>> It seems fairly straight-forward to me, but other members may feel otherwise.
>> With that in mind, if a member feels discussion or an explicit vote is
>> required, please don't hestite to derail it. I've also used a two-week timer
>> to ensure that sufficient time is given for members to review and derail if
>> that is appropriate. Thanks.
>>
>
> I don't see a release binding associated with this case. I give this
> case a +1 assuming that the binding is not less than Minor (i.e., this
> is not applicable for Patch or Micro).
>
> -Seb
>
>
>
Yes, it should have been minor. Thanks. This case was approved at
PSARC today, and has minor binding.
- Garrett
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Garrett D'Amore
gdamore@sun.com
|
|
|
|
Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout
10/21/2009]
Posted:
Oct 21, 2009 8:37 PM
in response to: Garrett D'Amore
|
|
So, in the process of going about the work to remove these utilities, I
found a few surprises.
First off, it is possible to take "graph" output, and generate
postscript, using the "postplot" utility (located in
/usr/lib/lp/postscript).
Second, it turns out that there are other postscript filters related to
postplot in some way, but which possibly could also be removed as they
are unlikely to be found useful in modern systems. (I'm speaking
specifically of posttek and postdaisy, which convert Tek 4014 and Diablo
630 format files into PostScript.)
What isn't clear to me here is what the best approach is. Some options:
1) Decline to remove "/usr/bin/graph" at this point, and remove it only
later when/if we find we can remove the postscript commands.
2) We could also leave the "-g" option in LPR, although I think its
better to remove it since CUPS can't support it.
3) We could remove "postplot" (which mostly exists for the purpose of
dealing with "lpr -g"), as well.
4) We could decline to implement the case at all, although I think that
is silly. There is clearly at least *some* baggage here that we can remove.
My personal preference is to just remove it all, probably in two
phases. Phase 1 will implement the stuff specified here, as specified
and approved. Phase 2 would be a new case to remove the "posttek",
"postplot", "postdaisy" utilities, subject to separate PSARC and
C-Team/P-Team review.
Any strong opinions here?
- Garrett
Garrett D'Amore wrote:
> Sebastien Roy wrote:
>> On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems
>> wrote:
>>
>>> The following fast track (submitted on my own behalf) straddles
>>> (IMO) the
>>> boundary between a full-case and a fast track, primarily because of the
>>> impact it has on what are presumed to be Committed interfaces.
>>>
>>> It seems fairly straight-forward to me, but other members may feel
>>> otherwise.
>>> With that in mind, if a member feels discussion or an explicit vote is
>>> required, please don't hestite to derail it. I've also used a
>>> two-week timer
>>> to ensure that sufficient time is given for members to review and
>>> derail if
>>> that is appropriate. Thanks.
>>>
>>
>> I don't see a release binding associated with this case. I give this
>> case a +1 assuming that the binding is not less than Minor (i.e., this
>> is not applicable for Patch or Micro).
>>
>> -Seb
>>
>>
>>
> Yes, it should have been minor. Thanks. This case was approved at
> PSARC today, and has minor binding.
>
> - Garrett
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Garrett D'Amore
gdamore@sun.com
|
|
|
|
Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout
10/21/2009]
Posted:
Oct 27, 2009 8:52 AM
in response to: Garrett D'Amore
|
|
In the absence of feedback, I've decided that the best approach is to
leave the functionality that is potentially still useful, and remove the
functionality that is not. I'm doing this as an update to this case; I
don't believe restarting the timer is necessary. Here's the actual changes:
1) Remove the /usr/ucb plotting commands, as indicated.
2) Leave graph and lpr -g alone for now.
3) Leave any other commands (posttek, postplot) alone for now.
A future case will be necessary if /usr/bin/graph, or any of the other
stuff (outside of the /usr/ucb commands) that deals with plot(4UCB) is
to be removed.
Personally, I believe the time is ripe to eliminate that stuff, but I
don't want to broaden the scope of *this* case without properly
reviewing it. I'll file a separate case to do that later.
- Garrett
Garrett D'Amore wrote:
>
> So, in the process of going about the work to remove these utilities,
> I found a few surprises.
>
> First off, it is possible to take "graph" output, and generate
> postscript, using the "postplot" utility (located in
> /usr/lib/lp/postscript).
>
> Second, it turns out that there are other postscript filters related
> to postplot in some way, but which possibly could also be removed as
> they are unlikely to be found useful in modern systems. (I'm
> speaking specifically of posttek and postdaisy, which convert Tek 4014
> and Diablo 630 format files into PostScript.)
>
> What isn't clear to me here is what the best approach is. Some options:
>
> 1) Decline to remove "/usr/bin/graph" at this point, and remove it
> only later when/if we find we can remove the postscript commands.
>
> 2) We could also leave the "-g" option in LPR, although I think its
> better to remove it since CUPS can't support it.
> 3) We could remove "postplot" (which mostly exists for the purpose of
> dealing with "lpr -g"), as well.
>
> 4) We could decline to implement the case at all, although I think
> that is silly. There is clearly at least *some* baggage here that we
> can remove.
>
> My personal preference is to just remove it all, probably in two
> phases. Phase 1 will implement the stuff specified here, as specified
> and approved. Phase 2 would be a new case to remove the "posttek",
> "postplot", "postdaisy" utilities, subject to separate PSARC and
> C-Team/P-Team review.
>
> Any strong opinions here?
>
> - Garrett
>
>
> Garrett D'Amore wrote:
>> Sebastien Roy wrote:
>>> On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems
>>> wrote:
>>>
>>>> The following fast track (submitted on my own behalf) straddles
>>>> (IMO) the
>>>> boundary between a full-case and a fast track, primarily because of
>>>> the
>>>> impact it has on what are presumed to be Committed interfaces.
>>>>
>>>> It seems fairly straight-forward to me, but other members may feel
>>>> otherwise.
>>>> With that in mind, if a member feels discussion or an explicit vote is
>>>> required, please don't hestite to derail it. I've also used a
>>>> two-week timer
>>>> to ensure that sufficient time is given for members to review and
>>>> derail if
>>>> that is appropriate. Thanks.
>>>>
>>>
>>> I don't see a release binding associated with this case. I give this
>>> case a +1 assuming that the binding is not less than Minor (i.e., this
>>> is not applicable for Patch or Micro).
>>>
>>> -Seb
>>>
>>>
>>>
>> Yes, it should have been minor. Thanks. This case was approved at
>> PSARC today, and has minor binding.
>>
>> - Garrett
>
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
523
From:
US
Registered:
3/9/05
|
|
|
|
Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout
10/21/2009]
Posted:
Oct 29, 2009 10:17 PM
in response to: Garrett D'Amore
|
|
Garrett asked me for codereview, and in looking, I've noticed that xterm still
supports the crufty old Tek 4014 mode, and one can actually make it work with
graph and plot (at least). So it's *conceivable* that someone is still using
this, although it would have to be nasty moldy old code, I'd think.
Given that those people can certainly use graph | postplot, we may officially
not care about them. I'm willing to accept that; I just want to make sure those
with an opinion know that we're removing the bundled stuff that someone might be
using, because, strictly speaking, it's one of the few workable things we have
in Solaris at the moment.
Given the followups for plotutils, I can't imagine this will be any kind of
issue for long, so this is only a nit to make doubly sure the committee agrees.
Garrett D'Amore wrote:
> In the absence of feedback, I've decided that the best approach is to
> leave the functionality that is potentially still useful, and remove the
> functionality that is not. I'm doing this as an update to this case; I
> don't believe restarting the timer is necessary. Here's the actual
> changes:
>
> 1) Remove the /usr/ucb plotting commands, as indicated.
> 2) Leave graph and lpr -g alone for now.
> 3) Leave any other commands (posttek, postplot) alone for now.
>
> A future case will be necessary if /usr/bin/graph, or any of the other
> stuff (outside of the /usr/ucb commands) that deals with plot(4UCB) is
> to be removed.
>
> Personally, I believe the time is ripe to eliminate that stuff, but I
> don't want to broaden the scope of *this* case without properly
> reviewing it. I'll file a separate case to do that later.
>
> - Garrett
>
>
> Garrett D'Amore wrote:
>>
>> So, in the process of going about the work to remove these utilities,
>> I found a few surprises.
>>
>> First off, it is possible to take "graph" output, and generate
>> postscript, using the "postplot" utility (located in
>> /usr/lib/lp/postscript).
>>
>> Second, it turns out that there are other postscript filters related
>> to postplot in some way, but which possibly could also be removed as
>> they are unlikely to be found useful in modern systems. (I'm
>> speaking specifically of posttek and postdaisy, which convert Tek 4014
>> and Diablo 630 format files into PostScript.)
>>
>> What isn't clear to me here is what the best approach is. Some options:
>>
>> 1) Decline to remove "/usr/bin/graph" at this point, and remove it
>> only later when/if we find we can remove the postscript commands.
>>
>> 2) We could also leave the "-g" option in LPR, although I think its
>> better to remove it since CUPS can't support it.
>> 3) We could remove "postplot" (which mostly exists for the purpose of
>> dealing with "lpr -g"), as well.
>>
>> 4) We could decline to implement the case at all, although I think
>> that is silly. There is clearly at least *some* baggage here that we
>> can remove.
>>
>> My personal preference is to just remove it all, probably in two
>> phases. Phase 1 will implement the stuff specified here, as specified
>> and approved. Phase 2 would be a new case to remove the "posttek",
>> "postplot", "postdaisy" utilities, subject to separate PSARC and
>> C-Team/P-Team review.
>>
>> Any strong opinions here?
>>
>> - Garrett
>>
>>
>> Garrett D'Amore wrote:
>>> Sebastien Roy wrote:
>>>> On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems
>>>> wrote:
>>>>
>>>>> The following fast track (submitted on my own behalf) straddles
>>>>> (IMO) the
>>>>> boundary between a full-case and a fast track, primarily because of
>>>>> the
>>>>> impact it has on what are presumed to be Committed interfaces.
>>>>>
>>>>> It seems fairly straight-forward to me, but other members may feel
>>>>> otherwise.
>>>>> With that in mind, if a member feels discussion or an explicit vote is
>>>>> required, please don't hestite to derail it. I've also used a
>>>>> two-week timer
>>>>> to ensure that sufficient time is given for members to review and
>>>>> derail if
>>>>> that is appropriate. Thanks.
>>>>>
>>>>
>>>> I don't see a release binding associated with this case. I give this
>>>> case a +1 assuming that the binding is not less than Minor (i.e., this
>>>> is not applicable for Patch or Micro).
>>>>
>>>> -Seb
>>>>
>>>>
>>>>
>>> Yes, it should have been minor. Thanks. This case was approved at
>>> PSARC today, and has minor binding.
>>>
>>> - Garrett
>>
>
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris dot org
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Gary Winiger
gww@sac.sfbay.sun.com
|
|
|
|
Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout
10/21/2009]
Posted:
Nov 4, 2009 12:22 PM
in response to: Garrett D'Amore...
|
|
> Garrett asked me for codereview, and in looking, I've noticed that xterm still
> supports the crufty old Tek 4014 mode, and one can actually make it work with
> graph and plot (at least). So it's *conceivable* that someone is still using
> this, although it would have to be nasty moldy old code, I'd think.
>
> Given that those people can certainly use graph | postplot, we may officially
> not care about them. I'm willing to accept that; I just want to make sure those
> with an opinion know that we're removing the bundled stuff that someone might be
> using, because, strictly speaking, it's one of the few workable things we have
> in Solaris at the moment.
>
> Given the followups for plotutils, I can't imagine this will be any kind of
> issue for long, so this is only a nit to make doubly sure the committee agrees.
At today's PSARC meeting Garrett asked for a follow up to this
comment. Since graph is not part of the removal, and there
appears to be an OpenSolaris follow up. I don't see an issue
surrounding cleaning up the 4014 stuff in a Minor release.
Gary..
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
523
From:
US
Registered:
3/9/05
|
|
|
|
Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout
10/21/2009]
Posted:
Nov 4, 2009 8:27 PM
in response to: Gary Winiger
|
|
Gary Winiger wrote:
>> Garrett asked me for codereview, and in looking, I've noticed that xterm still
>> supports the crufty old Tek 4014 mode, and one can actually make it work with
>> graph and plot (at least). So it's *conceivable* that someone is still using
>> this, although it would have to be nasty moldy old code, I'd think.
>>
>> Given that those people can certainly use graph | postplot, we may officially
>> not care about them. I'm willing to accept that; I just want to make sure those
>> with an opinion know that we're removing the bundled stuff that someone might be
>> using, because, strictly speaking, it's one of the few workable things we have
>> in Solaris at the moment.
>>
>> Given the followups for plotutils, I can't imagine this will be any kind of
>> issue for long, so this is only a nit to make doubly sure the committee agrees.
>
> At today's PSARC meeting Garrett asked for a follow up to this
> comment. Since graph is not part of the removal, and there
> appears to be an OpenSolaris follow up. I don't see an issue
> surrounding cleaning up the 4014 stuff in a Minor release.
>
> Gary..
I've approved the integration. Thanks for the followon consideration.
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
