<html><head><title></title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" >
</head>
<body class='pod'>
<!--
generated by Pod::Simple::HTML v3.28,
using Pod::Simple::PullParser v3.28,
under Perl v5.014002 at Sun Oct 18 17:41:52 2015 GMT.
If you want to change this HTML document, you probably shouldn't do that
by changing it directly. Instead, see about changing the calling options
to Pod::Simple::HTML, and/or subclassing Pod::Simple::HTML,
then reconverting this document from the Pod source.
When in doubt, email the author of Pod::Simple::HTML for advice.
See 'perldoc Pod::Simple::HTML' for more info.
-->
<!-- start doc -->
<a name='___top' class='dummyTopAnchor' ></a>
<h1><a class='u'
name="HISTORY"
>HISTORY</a></h1>
<p>This module spawned because <a href="http://search.cpan.org/perldoc?Proc%3A%3AProcessTable" class="podlinkpod"
>Proc::ProcessTable</a> has fallen into <a href="http://matrix.cpantesters.org/?dist=Proc-ProcessTable-0.45" class="podlinkurl"
>bugland</a> for the last 4 years,
and many people just want to be able to get a simple <code>PID+cmdline</code> from the process table.
While this module offers more than that as a bonus,
the goal of this module is to have something that JFW,
and continues to JFW.</p>
<p>With that in mind,
here my list of what went wrong with <a href="http://search.cpan.org/perldoc?Proc%3A%3AProcessTable" class="podlinkpod"
>Proc::ProcessTable</a>.
I have nothing against the authors of that module,
but I feel like we should try to learn from our failures and adapt in kind.</p>
<ul>
<li><b>Too many OSs in one distribution.</b> I dunno about you,
but I don't happen to have 15 different OSs on VMs anywhere.
At best,
I might have access to 2-3 different platforms.
So,
trying to test out code on a platform that you don't actually own is especially difficult.
<p>Thus,
this module is merely a wrapper around various other modules that provide process table information.
Those guys actually have the means (and the drive) to test their stuff on those OSs.
(The sole exception is the ProcFS module,
but that may get split eventually.)</p>
</li>
</ul>
<ul>
<li><b>Too much C/XS code.</b> The C and XS code falls in a class of exclusivity that makes it even harder to maintain.
If I were to conjure up some wild guess,
I would say that only 20% of Perl programmers could actually read,
understand,
and program C/XS code.
People aren't calling the process table a 1000 times a second,
so there's really no need for a speed boost,
either.
<p>Alas,
sometimes this is unavoidable,
with the process information buried in C library calls.
However,
the <code>/proc</code> FS is available on a great many amount of UNIX platforms,
so it should be used <i>as much as possible</i>.
Also,
I take this moment to shake my tiny little fist at the BSD folks for actually <b>regressing</b> the OS by removing support for <code>/proc</code>.
All of the reasons behind it are unsound or have solutions that don't involve removing this most basic right of UNIX users.</p>
</li>
</ul>
<!-- end doc -->
</body></html>