PHP 4 en RHEL (y otras distro "enterprise") [Was: Re: Canonical does not contribute to Linux plumbing.]

[Rodrigo Fuentealba]

El día 23 de septiembre de 2008 1:41, Horst H. von Brand
<vonbrand en inf.utfsm.cl> escribió:
> Rodrigo Fuentealba <the.code.keeper en gmail.com> wrote:
>> El día 22 de septiembre de 2008 11:37, Jens Hardings Perl
>> <jens en hardings.cl> escribió:
>> > On Sun, 2008-09-21 at 23:51 -0400, Horst H. von Brand wrote:
>
> [...]
>
>> Las estrellas de esto se lo llevan la excepcionalmente molesta
>> presencia de PHP 4... ¡¡¡tres años después de la presencia de un
>> reemplazo 100% superior!!!, pero si RedHat adquirió el compromiso de
>                                             ----------------------
>                                                 Este es el tema!
>
>> mantenerlo junto con todo el resto por cinco (o eran siete?) años, no
>> pueden deshacerse simplemente de ello. Alguna vez discutimos eso en la
>> lista con el Doc, y a pesar de que comprendí las razones, no las
>> compartía para nada. Es por fortuna que PHP aún mantiene su versión
>> 4.4.9, pero ya casi nadie lo mira y llega a dar pena ver código
>> escrito en eso.
>
> Has migrado alguna cosilla escrita a la chancha, posiblemente incluso
> ex-profeso para ser ilegible ("para proteger nuestra inefable propiedad
> intelectual"; si, tambien hay de esos), de PHP 4 a PHP 5? *Duele*!

Sí, sé que duele. Por eso utilicé pretérito.

>> Ahora, tengo una pregunta:
>>
>> ¿Existe alguna posibilidad de planificar el diseño de un lenguaje de
>> programación teniendo en cuenta la necesidad de mantener la
>> compatibilidad hacia atrás?
>
> No creo... los errores de disen~o del lenguaje original nunca podras
> corregirlos, y deberas arrastrarlos por los siglos de los siglos en sus
> descendientes.

Python está cambiando eso a costa de tener que reescribir mucho código.

PHP está cambiando eso, e intentando borrar la horrible fama que tiene.

El grave (y clásico) problema es que cuando se intenta hacer un
estándar nuevo, ya no hay "un" estándar sino "dos" estándares, y si se
hace algo para unificarlos, el resultado es "tres" estándares, no uno.
¿Nunca ha habido alguna estrategia para evitar aquello?

> Como dice el dicho, "Para hacer tortilla, hay que romper huevos".
>
>>                             Se me viene a la mente la figura de hacer
>> lo mismo que Solaris, que es binariamente compatible desde tiempos
>> inmemoriales.
>
> Vade retro!

Solamente aludía a una situación que "podía" parecerse a lo que se
requiere. Soy el primero que no quiere algo así en un sistema
operativo, pero sí para muchos desarrolladores sería bueno poder usar
un lenguaje de programación en el que pueda usar código de versiones
antiguas (PHP 2 en PHP 6, por soñar un rato; aunque ni siquiera PHP 4
funciona bien en PHP5) para poder ahorrarme el trabajo sucio de tener
que reescribir código que es eficiente, haciendo que evolucione pero
sin perder la efectividad ni el tedio de tener que contar con una
versión antigua del lenguaje para hacerlo correr.

Volviendo a lo de los formatos, de hecho Microsoft tiene un mal chiste
de implementación de lo mismo (sus malditos formatos Portable
Executable o PE), que se han intentado modificar lo suficiente para
que un ejecutable de 32 bits de Windows 95 funcione en Windows XP,
pero un PE de XP no puede funcionar en Windows 95. Se suponía que con
la aparición de la plataforma .NET, el formato PE desaparecería, ya
que sólo se requeriría un cambio de framework para soportar nuevos
tipos y formatos ejecutables. Sin embargo, el resultado de Vista
intentando hacer que su código sea managed y separando muchas cosas
por una capa innecesaria, además de las imbéciles políticas de
seguridad... y el resto es historia.

> [Y me late que tus "inmemoriales" no son tanto tampoco... y es mas un tema
>  de seguir manejando formatos de ejecutables y bibliotecas antediluvianos,
>  y tener los paquetes del caso. Alan Cox durante an~os mantuvo tarros con
>  Linux en formato a.out, que se dejo de usar en serio a fines de los  '90...]

Tal vez; no estoy muy familiarizado con ello, me gustaría discutirlo
de manera más extensa pero esto es una lista Linux, no Solaris. Sé que
usted tiene un buen background en Solaris, en todo caso.

>>               ¿Es posible hacer lo mismo con un lenguaje de
>> programación? Sí, sé que lo es, pero, ¿existe algún lineamiento a
>> seguir para que de como resultado un lenguaje compatible hacia atrás?
>> Creo que eso aminoraría en un porcentaje (al menos pequeño) el
>> stupidity tax.
>
> Y aumentaria en forma impresionante los impuestos pagados al otro lado de
> la cerca. La (dura) experiencia demuestra que no vale la pena. Revisa
> Documentation/stable_api_nonsense.txt en los fuentes del nucleo Linux mas
> cercano para detalles.

¡Lo escribió Greg Kroah-Hartman!

Y yep. estoy de acuerdo con eso "a nivel de kernel". También lo
aprendí "the hard way" (con algunas cositas de openMosix).

> O mira los horrores de seguridad que significa hasta
> el dia de hoy en Windows el tener que (en parte) seguir manejando tonteras
> de Win95 y anteriores...

Eso es un error del Team MSDN. Yo ya colgué a uno una vez, y se lo he
comentado :-D

> Por lo demas, porque complicarse la existencia solo para que otros /no/
> paguen el costo de su propia estupidez?

Porque no son "otros". RedHat está pagando el costo de la estupidez de
los developers de PHP, y yo también. Lamentablemente, el impuesto a la
estupidez de Python también tendré que pagarlo cuando Python 3000
salga; ya decidí que no quería pagar el impuesto a la estupidez de
Perl y estoy evaluando si existe el mismo en Java, para moverme a algo
estable.

Además, lo que planteo es una razón de peso que da gente que sabe
programar muy bien pero que lamentablemente utiliza a Microsoft, para
promover a la plataforma .NET en sus desarrollos, que está diseñada
para correr side-by-side (código ASP.NET 1.0 con ASP.NET 2.0 en un
mismo IIS, sin necesidad de modificar nada) y que les está funcionando
bastante mejor que a nosotros el tema de PHP4 versus PHP5 en un mismo
Apache.

-- 
Rodrigo Fuentealba
http://www.thecodekeeper.net/