Garrett D'Amore wrote:
I could easily implement all of the kstat functionality except regular
expression/glob matches, in a similar number of lines of C, and the
result would be just as readable and maintainable. (Most of the meat in
kstat(1) is really in the Sun::Solaris::Kstat module. :-)
I've looked at psrinfo, and its straight-forward to do in C as well.
(Once upon a time it was in C.)
I eagerly await the webrevs.
From casual examination, I think this is true of the project managment
If you can't see that, then I suspect it may be a result of your
particular inclination towards perl, and not a natural result from the
languages themselves.
Actually, I write very little perl any more. It's mostly Java, and I
wait with bated breath for the day when someone comes to take the perl
maintenance albatross from around my neck.
Off the cuff, it does strike me that the very need for a separate
perl584core, as well as backwards compatibility 5.6.1 and 5.8.4 (and
previously 5.003, etc. ad naseum) demonstrates very well the problem
with deploying core applications written in perl. They don't work well
in constrained environments without creating _extra_ headaches
associated with maintaining separate versions of the runtime, and there
can be a complex runtime compatibility matrix between version of the
application and the run time used.
I'm sorry if maintaining backwards compatibility for our customers
offends you, I'll endeavour to do better next time. Obviously the
entire Solaris perl situation is a complete disaster, is preventing many
important things from happening, and it's all my fault. Consider me
thoroughly chastised. *
* Judge for yourselves exactly where my tongue was when I wrote the
above paragraph ;-)
--
Alan Burlison
--
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code