Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
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 ]


 

Cox sobre Tolvards | 6 comentarios (6 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

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