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

[Germán Póo-Caamaño]

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/fog0000000069.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/