PHP 4 en RHEL (y otras distro enterprise) [Was: Re: Canonical does not contribute to Linux plumbing.]
On Tue, 2008-09-23 at 02:21 -0400, Rodrigo Fuentealba wrote: 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? Windows es un perfecto ejemplo de mantener compatibilidad hacia atras a todo nivel. O al reves, Linux es un perfecto ejemplo de matar la compatibilidad hacia atras: - Los binarios de hace 3 an~os ya no sirven sin workarounds, adios software propietario! ; - El codigo de hace 6 meses ya no compila, acabo de bajar eog-2.23.92 y me exige intltool-0.40.0 ; - GNOME ha cambiado varias veces de implementaciones de CORBA hasta volver a D-Bus y bibliotecas compartidas; - Otros ejemplos mas que no se me ocurren... Pues bien, la tonica aca es rehacer sin asco. Y ha funcionado muy bien, mira donde hemos llegado. Asi que no pelees con tratar de mantener funcionando algo por 5 an~os, si no ha sufrido cambios es probable que nadie lo use... eso hasta que aprendamos a escribir codigo sin bugs desde el principio, y estamos lejos de aquello. -- Aldrin Martoq [EMAIL PROTECTED] http://aldrinvideopodcast.podshow.com/
PHP 4 en RHEL (y otras distro enterprise) [Was: Re: Canonical does not contribute to Linux plumbing.]
On Tue, 2008-09-23 at 09:49 -0400, Aldrin Martoq wrote: On Tue, 2008-09-23 at 02:21 -0400, Rodrigo Fuentealba wrote: 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? Windows es un perfecto ejemplo de mantener compatibilidad hacia atras a todo nivel. O al reves, Linux es un perfecto ejemplo de matar la compatibilidad hacia atras: - Los binarios de hace 3 an~os ya no sirven sin workarounds, adios software propietario! ; - El codigo de hace 6 meses ya no compila, acabo de bajar eog-2.23.92 y me exige intltool-0.40.0 ; Creo que el ejemplo de EOG no concurre. Porque si quieres utilizar cualquier característica nueva de otros programas que dependes, necesariamente debes instalar nuevas versiones de dichas dependencias. Es decir, si quieres utilizar una nueva función que te provee una versión nueva de una biblioteca, no veo para que no utilizarla? Aún puedes instalar intltool 0.40. Aunque probablemente, el requerimiento no sea tan extremo. Si quieres comparar compatibilidad hacia atrás, lo que tendrías que hacer es tomar una versión más antigua de eog e intentar compilarla ahora. - GNOME ha cambiado varias veces de implementaciones de CORBA hasta volver a D-Bus y bibliotecas compartidas; 2 veces. MICO es sus muy primeros inicios, luego ORBit. Siempre se culpó a CORBA por ser lento, pero la verdad es que ORBit es rápido. Y para compatibilidad entre escritorios, es más fácil/rápido crear un nuevo componente (agnóstico), que elegir una tecnología por sobre otra. - Otros ejemplos mas que no se me ocurren... Netscape. Reescribir todo el código. Pero ello ameritó el artículo Things you should never do. http://www.joelonsoftware.com/articles/fog69.html -- Germán Póo-Caamaño http://www.calcifer.org/
PHP 4 en RHEL (y otras distro enterprise) [Was: Re: Canonical does not contribute to Linux plumbing.]
On Tue, 2008-09-23 at 12:39 -0400, Aldrin Martoq wrote: On Tue, 2008-09-23 at 10:44 -0400, Germán Póo-Caamaño wrote: On Tue, 2008-09-23 at 09:49 -0400, Aldrin Martoq wrote: Windows es un perfecto ejemplo de mantener compatibilidad hacia atras a todo nivel. O al reves, Linux es un perfecto ejemplo de matar la compatibilidad hacia atras: - Los binarios de hace 3 an~os ya no sirven sin workarounds, adios software propietario! ; - El codigo de hace 6 meses ya no compila, acabo de bajar eog-2.23.92 y me exige intltool-0.40.0 ; Creo que el ejemplo de EOG no concurre. Porque si quieres utilizar cualquier característica nueva de otros programas que dependes, necesariamente debes instalar nuevas versiones de dichas dependencias. Es decir, si quieres utilizar una nueva función que te provee una versión nueva de una biblioteca, no veo para que no utilizarla? Es solo un ejemplo. Precisamente, en otros ambientes lo normal es que se mantiene una version/API/interfaz etc; esto porque la mayoria del codigo esta en la misma plataforma (como Swing o las cosas de i18n en java, cosas _bastante_ estables). Pero tienes Java 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, ... Tu aplicación en Java 1.6 no correrá en Java 1.0. Probablemente al revés sí. Aún puedes instalar intltool 0.40. Aunque probablemente, el requerimiento no sea tan extremo. Si quieres comparar compatibilidad hacia atrás, lo que tendrías que hacer es tomar una versión más antigua de eog e intentar compilarla ahora. Precisamente el punto, aqui no esta el problema de botar la compatibilidad hacia atras y asi se avanza mas rapido. Gnome tiene compatibilidad de la API/ABI hacia atrás en toda la serie 2.x. GTK+ también. Lo que no puedes garantizar es compatibilidad hacia adelante. Pero es distinto a compatibilidad hacia adelante. Es como reclamar que decir que Python 2.5 no es compatible hacia atrás porque incluye generadores, que no existían en 2.0. Y por lo tanto, una aplicación con generadores no correrá en 2.0. - GNOME ha cambiado varias veces de implementaciones de CORBA hasta volver a D-Bus y bibliotecas compartidas; 2 veces. MICO es sus muy primeros inicios, luego ORBit. Siempre se culpó a CORBA por ser lento, pero la verdad es que ORBit es rápido. ORBit puede ser rapido, pero es la arquitectura la lenta y costosa. Ah, y falto Bonobo... Bonobo está sobre ORBit, no lo consideraría algo extra. Sin bonobo, no necesitas ORBit. El problema es su complejidad, no el rendimiento. Aunque siempre le han achacado el rendimiento. Nautilus 1.4 era lentísimo, pero Nautilus 2.0 mejoró ostensiblemente el rendimiento. Habían partes mal programadas o de O(n^2). Y para compatibilidad entre escritorios, es más fácil/rápido crear un nuevo componente (agnóstico), que elegir una tecnología por sobre otra. - Otros ejemplos mas que no se me ocurren... Netscape. Reescribir todo el código. Pero ello ameritó el artículo Things you should never do. http://www.joelonsoftware.com/articles/fog69.html Quizas me exprese mal. No es reescribir todo, es botar lo malo sin asco. En la practica reescribimos todo pero no se parte de cero. La idea de GTK+ 3, es precisamente poder botar toda esa mochila de funciones que se mantienen por compatibilidad. -- Germán Póo-Caamaño http://www.calcifer.org/
PHP 4 en RHEL (y otras distro enterprise) [Was: Re: Canonical does not contribute to Linux plumbing.]
2008/9/23 Horst H. von Brand [EMAIL PROTECTED]: Rodrigo Fuentealba [EMAIL PROTECTED] wrote: El día 22 de septiembre de 2008 11:37, Jens Hardings Perl [EMAIL PROTECTED] 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*! si migrar implica hacer correr una aplicacion hecha en PHP4 en un servidor web con PHP5 entonces basta con activar algunas opciones en el archivo de configuracion php.ini y listo (si alguien dice lo contrario es porque no se ha dado el tiempo de revisar la documentacion respectiva). si migrar implica modificar una aplicacion hecha en PHP4 para aprovochar lo nuevo que trae PHP5 entonces *obviamente* va a doler... a Red Hat no le queda otra que dar soporte a PHP4 por el tiempo que ellos mismos se comprometieron, su negocio es justamente ese, y si le fallan a sus clientes se acaba su negocio. lo no comprensible es porque a algunos les molesta tanto el tema, es patologicamente extran~o... -- Ricardo Mun~oz A.
PHP 4 en RHEL (y otras distro enterprise) [Was: Re: Canonical does not contribute to Linux plumbing.]
El día 23 de septiembre de 2008 10:02, Ricardo Mun~oz A. [EMAIL PROTECTED] escribió: 2008/9/23 Horst H. von Brand [EMAIL PROTECTED]: Rodrigo Fuentealba [EMAIL PROTECTED] wrote: El día 22 de septiembre de 2008 11:37, Jens Hardings Perl [EMAIL PROTECTED] 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*! si migrar implica hacer correr una aplicacion hecha en PHP4 en un servidor web con PHP5 entonces basta con activar algunas opciones en el archivo de configuracion php.ini y listo La razón por la cual no hacer eso, es que las configuraciones por defecto de muchas aplicaciones en PHP 4 son horriblemente inseguras y mal diseñadas (me he encontrado con un sinnúmero de aplicaciones que usan register_globals en On, o en las que hay que hacer embrujos relacionados con Unicode que en PHP 5 no son necesarios). Y encuentro insano no preocuparse de eso. Otra cosa, que el súper hiper mega overrated Joomla funcione en PHP 5, quiere decir sólo eso: que funciona. Pero usar var para declarar variables es un PITA. Y con el hecho de que PHP 5 use public/protected/private, la única manera de asegurarte de que PHP 5 soporte bien a PHP 4 es haciendo que var sea public... ¡¡¡echando por la borda las buenas costumbres!!! (si alguien dice lo contrario es porque no se ha dado el tiempo de revisar la documentacion respectiva). *cough* si migrar implica modificar una aplicacion hecha en PHP4 para aprovochar lo nuevo que trae PHP5 entonces *obviamente* va a doler... See above. a Red Hat no le queda otra que dar soporte a PHP4 por el tiempo que ellos mismos se comprometieron, su negocio es justamente ese, y si le fallan a sus clientes se acaba su negocio. lo no comprensible es porque a algunos les molesta tanto el tema, es patologicamente extran~o... Es tan sólo la visión de un buen programador con la opción de elegir un buen entorno o un mal entorno. Si no tuviera la opción, entonces procedería a usar lo que venga (por ej. lo que pasa con Visual Basic 6 y DAO). -- Rodrigo Fuentealba ( Website Unavailable :( )
