Ahora que Google ha decidido crear su propio motor de renderizado para Chrome y Chromium, la gente de WebKit piensa aprovechar la oportunidad para limpiar el código de su proyecto. En una conversación iniciada por Geoffrey Garen, desarrollador Webkit de Apple, se propuso eliminar todo el código instalado para que el motor funcione correctamente en los navegadores de Google.
Aligerar el código es bueno.
La competencia será buena para todos, incidirá en mejoras a medio plazo. Diferentes enfoques traerán consigo que se avance más rápido.
Como hace cualquier proyecto de software libre del universo, código que no es mantenido código que se queda fuera, y teniendo en cuenta que Google ya no va a mantenerlo y que no creo que haya nadie que quiera hacerlo, más que nada porque es bastante inútil y quien quiera el código de Chromium o Android se irá a Google, lo normal es que se borre.
Lo mismo hizo el kernel de Linux cuando Google no cooperaba manteniendo el código que aportaba de Android, tener código que no se mantiene solo trae problemas y no solo por hacer más pesado el programa sino por temas de integración, seguridad, ...
#3 Eso no fue exactamente así. El problema es que los parches que necesitaba el proyecto Android eran rechazados en la rama principal del kernel. Ahora eso ya no ocurre, al menos no con la mayoría de los parches, y se puede encontrar código del proyecto en el kernel.
#4 Sí, si que fue así. Luego evidentemente los siguientes parches eran rechazados hasta que Google se comprometió a mantenerlos, pero inicialmente el código llego a estar en el kernel. Por ejemplo:
"But the larger problem, he continues, is that Android uses a new lock type, new hooks for its "sometimes bizarre" security model, and a revamped framebuffer driver infrastructure. All this, he says, prevents "a large chunk" of Android drivers and platform code from merging into the main kernel tree."
Lo que viene a decir es que el código de Android chocaba con algunas de las características del kernel Linux. Android tenía que adaptarse a Linux y no al revés.
De hecho, si no recuerdo mal, el código de Android volvió al git al poco tiempo de que el kernel recibiese los parches de wakeup y el nuevo sistema de lock (que, supongo, es el que usa Android ahora).
#8 Ese es otro problema adicional que impedía que parte del código estuviese en el kernel, de ahí no puedes deducir que no hubo código de Android en la línea principal de Linux y que tuvieron que quitarlo, entre otras cosas porque esas otras partes que no enviaban eran necesarias para que funcionasen las que si que habían enviado. Vamos, que como he dicho, no mantenían correctamente el código que tenían en el kernel.
De esta forma google garantiza que podra obtener mas información sobre los habitos de navegación algo que en Gecko es imposible.. por algo sera mozilla no quiso negociar..
#5 WebKit es un motor de renderizado. Además, nada impedía a Google añadir cualquier parche a WebKit en Chromium, si realmente fuese necesario para obtener más información de los usuarios.
#6 WebKit es mas moldeable, su código es mas simple, aunque también es verdad que Geckos tiene matices que aprender de Webkit.. pero porque Chromium no se beneficia de Geckos?.. solo el tiempo nos dira cual es el camino a seguir.. puede hechar un vistazo a: http://arstechnica.com/information-technology/2008/09/mozilla-committed-to-gecko/1/
Comentarios
Aligerar el código es bueno.
La competencia será buena para todos, incidirá en mejoras a medio plazo. Diferentes enfoques traerán consigo que se avance más rápido.
Como hace cualquier proyecto de software libre del universo, código que no es mantenido código que se queda fuera, y teniendo en cuenta que Google ya no va a mantenerlo y que no creo que haya nadie que quiera hacerlo, más que nada porque es bastante inútil y quien quiera el código de Chromium o Android se irá a Google, lo normal es que se borre.
Lo mismo hizo el kernel de Linux cuando Google no cooperaba manteniendo el código que aportaba de Android, tener código que no se mantiene solo trae problemas y no solo por hacer más pesado el programa sino por temas de integración, seguridad, ...
#3 Eso no fue exactamente así. El problema es que los parches que necesitaba el proyecto Android eran rechazados en la rama principal del kernel. Ahora eso ya no ocurre, al menos no con la mayoría de los parches, y se puede encontrar código del proyecto en el kernel.
#4 Sí, si que fue así. Luego evidentemente los siguientes parches eran rechazados hasta que Google se comprometió a mantenerlos, pero inicialmente el código llego a estar en el kernel. Por ejemplo:
http://www.theregister.co.uk/2010/02/03/android_driver_code_deleted_from_linux_kernel/
#7 No.
"But the larger problem, he continues, is that Android uses a new lock type, new hooks for its "sometimes bizarre" security model, and a revamped framebuffer driver infrastructure. All this, he says, prevents "a large chunk" of Android drivers and platform code from merging into the main kernel tree."
Lo que viene a decir es que el código de Android chocaba con algunas de las características del kernel Linux. Android tenía que adaptarse a Linux y no al revés.
De hecho, si no recuerdo mal, el código de Android volvió al git al poco tiempo de que el kernel recibiese los parches de wakeup y el nuevo sistema de lock (que, supongo, es el que usa Android ahora).
#8 Ese es otro problema adicional que impedía que parte del código estuviese en el kernel, de ahí no puedes deducir que no hubo código de Android en la línea principal de Linux y que tuvieron que quitarlo, entre otras cosas porque esas otras partes que no enviaban eran necesarias para que funcionasen las que si que habían enviado. Vamos, que como he dicho, no mantenían correctamente el código que tenían en el kernel.
Aquí tienes el commit de git donde se quitó el código de Android: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b0a0ccfad85b3657fe999805df65f5cfe634ab8a
Vamos, está bastante claro que hubo código de Android en el kernel y que se tuvo que quitar.
Si te vas te ayudo a poner tus trastos de patitas a la calle.
Chincha rabincha.
De esta forma google garantiza que podra obtener mas información sobre los habitos de navegación algo que en Gecko es imposible.. por algo sera mozilla no quiso negociar..
#5 WebKit es un motor de renderizado. Además, nada impedía a Google añadir cualquier parche a WebKit en Chromium, si realmente fuese necesario para obtener más información de los usuarios.
#6 WebKit es mas moldeable, su código es mas simple, aunque también es verdad que Geckos tiene matices que aprender de Webkit.. pero porque Chromium no se beneficia de Geckos?.. solo el tiempo nos dira cual es el camino a seguir.. puede hechar un vistazo a: http://arstechnica.com/information-technology/2008/09/mozilla-committed-to-gecko/1/