Lo que no dicen de Safari 17
ACTUALIZACIÓN: la situación actual entre KHTML/Safari es sustancialmente diferente tal y como apunta eduo en los comentarios.
Todos los blogs se regocijan ante el increíble golpe que ha dado Apple en el mercado lanzando Safari para la plataforma de Microsoft. Lo que no saben muchos de los autores de esos blogs es que Safari reposa en la espalda de KHTML, un motor de render open source programado por la gente de KDE. Y lo que todavía menos saben es que la gente de KDE está ya muy muy quemada con Apple por la poca gratitud, por no decir desprecio, que muestra después de tomar una pieza de software tan buena, maquillarla y venderla.
Esto es lo que responde Zack Rusin a todos los que esperan impacientes que los chicos de KDE incorporen los parches de Safari en Konqueror:
No te puedes imaginar como odio esa pregunta. La verdad es que “probablemente nunca”. Acabo de leer el artículo en SlashDot que habla sobre que Safari soporta todo el test Acid2 y la gente desvaría sobre lo bueno que es todo eso para KHTML. La verdad es que KHTML probablemente nunca tendrá esos parches. Lo más probable es que cualquiera de nosotros simplemente lo reimplemente desde cero (y por el momento la cruda realidad es que si no lo hace Allan o Germain es algo que nunca va a pasar).
El código de Safari es enormemente inconsistente y los cambios son siempre interdependientes. Básicamente no hay manera de incorporar un sólo cambio sin tener que añadir un montón de los demás. ¿Y sabes qué? No me digas de incorporar cosas como render_canvasimage.[h,cpp]. Eso utiliza indiscutiblemente las API’s de OS X. Nunca seremos capaces de aprovechar algo así —alguien tendrá que implementarlo. ¿Y que sucederá cuando alguien lo haga? Algún imbécil en /. u otro estupido sitio elogiará a Apple.
En el pasado cuando alguién invertía largas horas implementado algo en KHTML, como minimo obtenía un “gracias” de la gente que utiliza Konqueror. Ahora es “¡Hombre por fin! Estaba funcionando en Safari. Los desarrolladores de KHTML son unos vagos”. ¿Qué tiene eso de divertido?
¿Tienes la menor idea de lo difícil que es mezclar cambios entre dos árboles completamente diferentes cuando uno de ellos no tiene historial? Esta es la situación en la que se encuentra KDE. Creamos la lista khtml-cvs para la gente de Apple, incluso tienen cuentas para el CVS de KDE. ¿Que es lo que obtuvimos? Periódicamente tenemos bombas de código cada vez que lanzan alguna versión de WebCore. Muchos de nosotros queríamos incluso firmar NDA’s con Apple para por lo menos tener acceso al historial de cambios de su sistema de control de versiones interno y ser capaces de ir integrando los cambios poco a poco, de la misma manera que ellos lo hacen hoy en día. Nunca hubo respuesta. Hacen el mínimo (muy mínimo) exigible por la LGPL.
¿Y sabes qué? Estan en su derecho. Han tomado la decisión consciente de no trabajar con el equipo de desarrollo de KDE. Todo lo que pido a toda esa gente despistada es que pare de hablar sobre la colaboración entre los desarrolladores de Safari/Konqueror y lo maravillosa que es. No hay nada de maravilloso. De hecho ni siquiera existe. Tal vez para Apple —o mejor dicho su gente de marketing. ¿Está claro?
Una parte nada despreciable de la plataforma de Apple es o tiene base en el software libre. La manzanita de lo alternativo, lo moderno y lo “guay” debería tener un respeto para con los que han cedido su trabajo y esfuerzo desinteresadamente.
menéame
