Comments on: Producir software de calidad no es fácil

By: maeghith

maeghith — Sun, 16 Dec 2007 16:45:08 +0000

En el caso de que aparece un bug o una compatibilidad en uno de los componentes, la empresa se calla la boca y se soluciona en el siguiente release.

Eso es el mejor de los casos, que es cuando el bug lo descubre la propia empresa desarrolladora. ¿Y si lo descubre alguien de fuera?.

Y por otro lado, con el sistema de dependencias, tampoco el usuario necesita saber cual de los paquetes depende de cual otro, para eso están los sistemas de paquetes con gestión de dependencias. Y si la cosa es ocultar las dependencias, pues en realidad te da igual:
- los usuarios que no se preocupan, no se van a poner a investigar ahora,
- y un usuario de “los que sí se preocupan” lo hará, uses el sistema que uses.

By: Pau Sanchez

Pau Sanchez — Thu, 13 Dec 2007 23:23:16 +0000

Jose el nombrar Perforce como ejemplo, no es para decir que es un sistema de control de versiones cojonudo, que lo es, (subversion tampoco está mal, no quiero entrar en polémicas), a lo que me refiero en el artículo es que realizar código multiplataforma que sea fácilmente instalable por los usuarios(expertos o inexpertos) y que evite problemas de compatibilidad, no es algo que muchas empresas consigan.

Dar soporte de un software para distintas versiones de distintos sistemas operativos es un quebradero de cabeza. Y Perforce tiene soporte para Linux 2.4.x y 2.6.x en arquitecturas x86, x64 y IA64; para MS Windows en x86,x64 e IA64 también; para MAC OS X en PPC, x86 y x64; Solaris, FreeBSD, AIX… y ya paro de enumerar.

El punto clave de este comentario y de este artículo no es que sea multiplataforma como muchas otras aplicaciones GNU (como por ejemplo subversion), el punto clave es que es superfácil instalarlo, y a mi de momento siempre me ha funcionado a la primera, ya sea en Windows o en Linux. Y me juego el cuello a que en MAC también va perfectamente.

By: Jose

Jose — Thu, 13 Dec 2007 06:46:22 +0000

Mi voto por Subversion.

No tienes que gastar dinero y para trabajar con varios “trunks” va de perlas.

Muchos problemas de multiplataforma tienes que tener para justificar el gasto en Perforce.

By: Pau Sanchez

Pau Sanchez — Wed, 12 Dec 2007 14:28:48 +0000

También existe otra opción en ese caso. Lo que comunmente viene llamandose: Plan B.

En el caso de que aparece un bug o una compatibilidad en uno de los componentes, la empresa se calla la boca y se soluciona en el siguiente release.

Si el bug es del propio programa te da igual hayas hecho enlace estático o dinámico, y en el otro caso, efectivamente te expones, pero por otra parte terceras personas no tienen porque saber que componentes utilizas.

By: maeghith

maeghith — Tue, 11 Dec 2007 14:34:51 +0000

Sobre lincado estático, la ventaja que tiene para la empresa es que nadie va a romper compatibilidad con el binario. Se van a ahorrar muchas llamadas a soporte técnico. Imagina que usan lincado dinámico, y el cliente depende del paquete X. Ahora supon que los desarrolladores del paquete X deciden hacer un pequeño cambio que soluciona algún tipo de bug, pero que produce incompatibilidades.

Si aparece un bug entonces la empresa tendrá que elegir:
- cubrirse el culo y corregir el bug, arriesgandose a perder compatibilidad, pero asegurandose que está actualizado: toca llamar a soporte en caso de que se pierda compatibilidad;
- o seguir trabajando sin corrergir el bug (por que han visto en el changelog que no les afecta), arriesgandose a que el bug le impida trabajar en algún momento futuro o que suponga un riesgo de seguridad que no pueden solucionar por otros medios (firewall, etc..): toca llamar a soporte en caso de que se queden con el culo al aire o de que el bug no les deje trabajar.

A soporte se acaba llamando, antes o después, es inevitable XD

By: Pau Sanchez

Pau Sanchez — Sun, 09 Dec 2007 10:24:21 +0000

Acabo de verificar que tanto “p4″, “p4d” y “p4v” son binarios de linux (con formato ELF). P4V no es una aplicación java, aunque yo no descartaría que hubieran metido directamente una maquina virtual java en el EXE, y tuvieran varias llamadas a funciones nativas, y por eso al ejecutar “nm p4v” salen tantas funciones.

Sobre lincado estático, la ventaja que tiene para la empresa es que nadie va a romper compatibilidad con el binario. Se van a ahorrar muchas llamadas a soporte técnico. Imagina que usan lincado dinámico, y el cliente depende del paquete X. Ahora supon que los desarrolladores del paquete X deciden hacer un pequeño cambio que soluciona algún tipo de bug, pero que produce incompatibilidades.

Sobre las dependencias, ahora la verdad es que están bastante pulidas, aunque sigo echando en falta la funcionalidad de deshacer la última instalación (superutil cuando algo falla después de actualizar).

En cualquier caso, aun con las dependencias funcionando bien, ellos no tienen que preocuparse de definirlas en el instalador.

Conclusión: el único incoveniente que le veo a esta solución es el tamaño de los ejecutables: ~530KB (p4), ~1.6MB (p4d), ~14MB (p4v).

By: maeghith

maeghith — Sat, 08 Dec 2007 12:44:23 +0000

¿El cliente de p4 de linux lincado estático?, creía que linux usaba el cliente java (por eso parece que no tenga dependencias).

Hay proyectos en linux que utilizan lincado estático, como el klik (http://klik.atekon.de/).

Y el problema que se le achaca al lincado estático es el de falta de seguridad por desactualización: si se actualiza una biblioteca de la que dependen 20 paquetes, hay que actualizar los 20 paquetes por separado y puede que alguno no se actualice por el motivo que sea, mientras que si se usa un sistema de dependencias, al actualizar el la bibioteca en el sistema, se actualizan automáticamente todos los paquetes.

Ahora, esto lleva el problema de las dependencias rotas, cíclicas y demás historias harto conocidas, aunque últimamente está bastante pulido el tema (creo yo).

Conclusión: cada decisión acarrea sus inconvenientes, y cuando no se pueden corregir, hay que saber aceptarlos y convivir con ellos :)