Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Cox sobre Tolvards

pbenavent's Diary
Por pbenavent
departamento no penseis en guarrerias , Sección Diarios
Puesto a las Wed Mar 2nd, 2005 at 08:05:25 AM CET
Cox sobre Tolvards no tiene que conduciros por caminos escabrosos, Alan Cox vierte algunas opiniones sobre Linux Tolvards...

 


Llego por mis feeds a una nota de Slashdot en la que se menciona un artículo de ZDNet (casi acaban con mis i-nodos de tanta cookie que ponen) en el que recojer algunas opiniones de Alan Cox expresadas en el FOSDEM... podemos citar el atículo de manera sensacionalista:

  -Linus es un buen desarrollador pero un ingeniero terrible
o de manera más seria si incluimos la apostilla que el propio Cox añade

  ...estoy seguro que él estará de acuerdo con esto

No voy a destriparos el artículo ni a traducirlo (mi chaval tiene examen de inglés mañana y quiero concienciaros de lo importante de saber idiomas) pero añado unas notas.

Cox sostiene que Linus y él se aproximan a los problemas de forma muy distinta, Linus prefier un código limpio y fácilmente leíble y mantenible, Cox prefiere estabilidad el el kernel, código que funcione.

Por eso ocurre que Cox prefiere hacks pequeños, aunque sucios (guarretón diría algún conocido mio) y Linus prefiere más cierta reescritura, lo que es una pena por que requiere mucha refactorización.

También es curioso leer lo que dice acerca de las correciones de seguridad que Linus hace ... (leedlo, practice your english, turn off TV, turn on your mind como decía la bruja averia)

< Concurso de Diseño del Logo de aKademy 2005 (0 comments) | Envios de Anónimos, ¿sí o no? (18 comments) >
Enlaces Relacionados
· Slashdot
· nota de Slashdot
· artículo de ZDNet
· More on pbenavent's Diary
· Also by pbenavent

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Cox sobre Tolvards | 6 comentarios (6 temáticos, editoriales, 0 ocultos)
No estoy de acuerdo con Cox (none / 0) (#1)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Wed Mar 2nd, 2005 at 01:23:40 PM CET
(Información Usuario) http://speedball.servemp3.com

Más que nada estoy en desacuerdo en sus definiciones de ingeniero y de desarrollador.

Es una actividad más ingenieril el intentar hacer un buen diseño limpio y replantearse el diseño. Mientras que es mas de desarrollador el enguarrarse en hacer que algo funcione.

Poniendo un ejemplo más evidente para el profano: es de ingeniero diseñar un motor que funcione mejor que los existentes y es de mecánico hacer que funcione un motor estropeado o mal diseñado.

En lo que si estoy de acuerdo es que Linus es mejor desarrollador que ingeniero, pero básicamente porque "ha" desarrollado un buen kernel con un diseño algo desfasado.

Por ejemplo Hurd es un kernel mejor diseñado pero desarrollado fatal.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar


Yo lo que no entiendo es... (5.00 / 1) (#3)
por jorginius ("jorginius" en Google Mail) a las Wed Mar 2nd, 2005 at 07:54:18 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Cómo puede estar reñido hacer un código más limpio y más simple de entender (y de mantener) con la estabilidad y la seguridad.

A nivel intuitivo, si más personas entienden lo que hace un código más difícil es que haya fallos ocultos en él, luego más seguro y estable será, ¿o no?.

Quizás a corto plazo, durante la refactorización, haya cosas que no funcionen, pero a la larga el código será más estable que un conjunto de hacks que sí, que funcionan pero que sólo entiende Alan Cox y dos más. La solución de Linus parece mejor.

¿Hay algo que se me escapa?.

[ Padre ]


Lo que yo entiendo... (5.00 / 1) (#5)
por Draco a las Thu Mar 3rd, 2005 at 07:30:13 PM CET
(Información Usuario)

...es que a Linus le importa poco estar en una rama estable y ofrecer en todo momento un kernel que se pueda poner en producción con ciertas garantías y sin romper nada. Si cree que debe reescribir todo un subsistema en medio de una rama estable lo hace, y si no, ver el jaleo del 2.4 con la VM de Rik Van Riel y de Andrea Arcangeli. Probablemente si por Cox hubiera sido se hubiera mantenido la de Van Riel, y la refactorización se hubiese dejado para la rama 2.5. Yo creo que ésto es lo que subyace en las palabras de Cox, más que otra cosa.

Por cierto, también es conocida la ligereza con que Linus cambia la ABI del kernel...
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


Las "release candidates" (4.00 / 1) (#6)
por jorginius ("jorginius" en Google Mail) a las Fri Mar 4th, 2005 at 10:52:37 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

No hablan de reemplazar o añadir subsistemas enteros, al menos no en el artículo. Ni Alan Cox Linus ni otros hacen eso en la rama estable por norma. Lo de la VM fue algo bastante atípico y no se refieren aquí a cambios radicales sino a los pequeños cambios entre "release candidates".

A lo que se refiere Cox, o lo que yo entiendo, es que Linus prefiere reescribir parcialmente el código dónde está el fallo (durante el ciclo de "release candidates") que parchearlo para que funcione sin más.

El inconveniente de la "forma Linus" es que, reescribiendo y simplificando, a veces se cuelan errores colaterales en otras partes del código que dependían de algún hack (feo y contrario a la práctica de la ingeniería, por definición de hack) que hubiera en lo reescrito. Por contra, con la "forma Cox" se modifica menos código y hay menos posibilidades de que se rompa algo.

Pero a la larga es mejor la forma Linus: primero porque el código tiende a ser de mayor calidad (más estable, limpio y fácil de mantener) y segundo porque si algo se rompe al reescribir una parte que, en principio, no tiene que ver nada con lo que se ha roto, es que eso estaba mal escrito en primer lugar: la forma de hacer las cosas de Linus saca a la luz esos errores.

También puede mostrar errores de diseño, ayudar a darse cuenta de que el diseño actual hace los interfaces más complicados de lo que deberían ser o con más acoplamientos de los que deberían tener, por ejemplo.

[ Padre ]


 
No estoy de acuerdo con Ed hunter O:-) (none / 0) (#2)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Wed Mar 2nd, 2005 at 06:02:24 PM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Por ejemplo Hurd es un kernel mejor diseñado pero desarrollado fatal.

Creo que confundes arquitectura (software) con diseño (software). La arquitectura de Hurd (microkernel) puede ser o no mejor que la de Linux (S.O. modular por capas) --es otra discusión en la que ahora no voy a entrar--. Pero el diseño es otra cuestión que no tiene que ver directamente con la arquitectura elegida, y de hecho arquitecturas iguales pueden tener diseños completamente diferentes.

Piensa por ejemplo que los patrones de diseños (design patterns, Gamma et. al) se aplican a un nivel diferente (y son distintos) que los patrones "arquitecturales" (-> el libro de Fowler).

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]


 
Primeros principios (none / 0) (#4)
por pbenavent a las Thu Mar 3rd, 2005 at 09:46:30 AM CET
(Información Usuario) http://www.benavent.org

Precisamente, unos artículos antes del que motiva la entrada se habla de el código es el diseño -que también han comentado en barrapunto-.

Quede claro que NO soy desarrollador pero a veces escribo mis propias utilidades (bash, perl, php) y una cosa tengo clara: órden, simplicidad, identación, ... dos semanar después releo un script y no entiendo nada.

Los hack's más guarretones te sacan del paso, pero

-> si te sacan del paso entonces es que son útiles
-> si son utiles entonces es probable que lo vuelvas a utilizar
-> si lo lo utilizas más de una vez es probable que: modifiques, releeas el código
+ conclusión escribe claro, limpio, estructurado, mantenible ...

Lo que sea escribir claro es otra guerra, algunos hacen florituras, como decía Terencio moderación en todas las cosas

--
"El hombre es la medida de todas las cosas"
Protágoras


 
Cox sobre Tolvards | 6 comentarios (6 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda