Comentarios en: Software 100% Bug free http://blog.48bits.com/2006/08/14/software-100-bug-free/ 48Bits ... The one and a half architecture land. Wed, 08 Feb 2012 07:47:08 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Por: Alfredo http://blog.48bits.com/2006/08/14/software-100-bug-free/comment-page-1/#comment-40536 Alfredo Fri, 05 Sep 2008 12:38:28 +0000 http://blog.48bits.com/?p=59#comment-40536 Cuando la cantidad de Bugs tiende a cero, el costo tiende a infinito. El software 100% libre de errores, no existe. La prueba de esto esta en que para descubrir todos los errores de por ej, internet explorer, hacen falta tantos "testers" como usuarios tiene. y aun así, nadie puede decir que ya se hayan encontrado todos los bugs posibles. Cuando la cantidad de Bugs tiende a cero, el costo tiende a infinito. El software 100% libre de errores, no existe.
La prueba de esto esta en que para descubrir todos los errores de por ej, internet explorer, hacen falta tantos “testers” como usuarios tiene. y aun así, nadie puede decir que ya se hayan encontrado todos los bugs posibles.

]]> Por: Nacho.V http://blog.48bits.com/2006/08/14/software-100-bug-free/comment-page-1/#comment-8441 Nacho.V Fri, 22 Dec 2006 16:20:46 +0000 http://blog.48bits.com/?p=59#comment-8441 Los bugs son inherentes a la programación, cuanto mas se automaticen las tareas (teoricamente) menos bugs habrá. Con la apariciòn de lenguajes y herramientas como .NET ( y anteriormente Java ) se prima mas el esfuerzo en el analisis y diseño que en la implementación final. y progresivamente se tiende a dejar las menores responsabilidades posibles al programador. Obviamente, como apunta mballano, codear un driver es más que rellenar el codigo de unas clases (aunque sinteticamente se podria reducir a eso) y no se podrian aplicar frameworks o generadores de codigo facilmente. En caso de bugs, es mas facil buscar solo en el codigo que has escrito tu que en el de la aplicacion completa. si el fallo es de la herramienta se parchea y se regeneran todas las aplicaciones.. de esta forma se tiene la seguridad que ese bug no estara presente y no habra que parchear cada aplicacion generada por separado. Por cierto, es la primera vez que me paso por aqui y me he llevado una grata sorpresa, se tocan temas interesantes y hay gente de mucho nivel de la que se pueden aprender cosas :) Los bugs son inherentes a la programación, cuanto mas se automaticen las tareas (teoricamente) menos bugs habrá.
Con la apariciòn de lenguajes y herramientas como .NET ( y anteriormente Java ) se prima mas el esfuerzo en el analisis y diseño que en la implementación final. y progresivamente se tiende a dejar las menores responsabilidades posibles al programador.
Obviamente, como apunta mballano, codear un driver es más que rellenar el codigo de unas clases (aunque sinteticamente se podria reducir a eso) y no se podrian aplicar frameworks o generadores de codigo facilmente.

En caso de bugs, es mas facil buscar solo en el codigo que has escrito tu que en el de la aplicacion completa. si el fallo es de la herramienta se parchea y se regeneran todas las aplicaciones.. de esta forma se tiene la seguridad que ese bug no estara presente y no habra que parchear cada aplicacion generada por separado.

Por cierto, es la primera vez que me paso por aqui y me he llevado una grata sorpresa, se tocan temas interesantes y hay gente de mucho nivel de la que se pueden aprender cosas :)

]]> Por: Zohiartze Herce http://blog.48bits.com/2006/08/14/software-100-bug-free/comment-page-1/#comment-450 Zohiartze Herce Fri, 08 Sep 2006 08:20:47 +0000 http://blog.48bits.com/?p=59#comment-450 En relación con algunos comentarios anteriores, os dejo este link del blog de Bruce Schneier: http://www.schneier.com/blog/archives/2006/09/microsoft_and_f.html Para las empresas, arreglar bugs unicamente supone perdidas (a no ser que sean empresas de servicios que vendan un mantenimiento posterior a la instalacion del producto). Creo que Schneier lo explica bien: si no fuese por la cada vez mayor notoriedad que se les da a los bugs hoy en dia, las empresas no parchearian o lo seguirian haciendo tan mal como lo hacian antes. Las grandes compañias prefieren que los bugs se les notifiquen a ellas y que ademas se les deje decidir cuando parchear. http://www.securityfocus.com/columnists/415 Ademas dicen que quien encuentra un bug y lo detalla de cara al publico, esta actuando mal. Y sin embargo gracias a esta actitud estas empresas se han visto forzadas a mejorar sus medidas para distribuir patchs. Mas aun, como hoy en dia estan obligadas a parchear y a hacerlo rapido y como hemos dicho que eso solo les supone perdidas, ahora se encuentran con el siguiente dilema: ¿Que sale mas barato, realizar bien el software desde el principio o verse obligadas a parchear gratuitamente mas adelante? Si deciden desarrollar bien el software desde el principio, podran calcular cuanto dinero les va a costar desarrollar el producto y calcular el precio adecuado de venta, pero ¿quien puede calcular de antemano las perdidas que les generara el parchear bugs gratuitamente? Por lo tanto, cuanto mejor este desarrollado el software, menos incertidumbre tendra el fabricante sobre los costes de mantenimiento de su producto. La solucion ideal para estas grandes empresas seria tal vez una tercera: que sean terceras empresas las que desarrollen soluciones a sus fallos (soluciones temporales), dandoles tiempo a las ratitas a parchear su software en los plazos que crean preciso y haciendolo por lo tanto algo mas rentable. Empreas como iDefense, representan en el fondo una idea similar. En relación con algunos comentarios anteriores, os dejo este link del blog de Bruce Schneier:

http://www.schneier.com/blog/archives/2006/09/microsoft_and_f.html

Para las empresas, arreglar bugs unicamente supone perdidas (a no ser que sean empresas de servicios que vendan un mantenimiento posterior a la instalacion del producto). Creo que Schneier lo explica bien: si no fuese por la cada vez mayor notoriedad que se les da a los bugs hoy en dia, las empresas no parchearian o lo seguirian haciendo tan mal como lo hacian antes. Las grandes compañias prefieren que los bugs se les notifiquen a ellas y que ademas se les deje decidir cuando parchear.

http://www.securityfocus.com/columnists/415

Ademas dicen que quien encuentra un bug y lo detalla de cara al publico, esta actuando mal. Y sin embargo gracias a esta actitud estas empresas se han visto forzadas a mejorar sus medidas para distribuir patchs. Mas aun, como hoy en dia estan obligadas a parchear y a hacerlo rapido y como hemos dicho que eso solo les supone perdidas, ahora se encuentran con el siguiente dilema: ¿Que sale mas barato, realizar bien el software desde el principio o verse obligadas a parchear gratuitamente mas adelante? Si deciden desarrollar bien el software desde el principio, podran calcular cuanto dinero les va a costar desarrollar el producto y calcular el precio adecuado de venta, pero ¿quien puede calcular de antemano las perdidas que les generara el parchear bugs gratuitamente? Por lo tanto, cuanto mejor este desarrollado el software, menos incertidumbre tendra el fabricante sobre los costes de mantenimiento de su producto.

La solucion ideal para estas grandes empresas seria tal vez una tercera: que sean terceras empresas las que desarrollen soluciones a sus fallos (soluciones temporales), dandoles tiempo a las ratitas a parchear su software en los plazos que crean preciso y haciendolo por lo tanto algo mas rentable. Empreas como iDefense, representan en el fondo una idea similar.

]]> Por: mballano http://blog.48bits.com/2006/08/14/software-100-bug-free/comment-page-1/#comment-426 mballano Thu, 07 Sep 2006 14:45:37 +0000 http://blog.48bits.com/?p=59#comment-426 tenemos foros, y IRC aunque este último no lo estamos usando mucho ultimamente (y no está levantado ahora mismo), pasate por los foros Diego, tienes un enlace en la parte superior de esta web. Un saludo! :-) tenemos foros, y IRC aunque este último no lo estamos usando mucho ultimamente (y no está levantado ahora mismo), pasate por los foros Diego, tienes un enlace en la parte superior de esta web.

Un saludo! :-)

]]> Por: Diego Bauche http://blog.48bits.com/2006/08/14/software-100-bug-free/comment-page-1/#comment-392 Diego Bauche Wed, 06 Sep 2006 15:46:21 +0000 http://blog.48bits.com/?p=59#comment-392 Estoy completamente de acuerdo contigo, y tenia muy claro lo que intentabas explicar. El problema es que esto ya existe, se entiende "Metodos automatizados" como: 1. Algoritmia, la solucion a muchisimos de tus problemas. 2. Especificaciones (RFCs, documentacion de protocolos, etc.) 3. Reusar codigo. 4. Bibliotecas. Y el problema es que, aun usando todo esto, el codigo especifico de una aplicacion, el codigo reusado, el algoritmo, la biblioteca, o las especificaciones tambien suelen tener fallas. Otro problema es que siempre existen protocolos nuevos, algoritmos nuevos, herramientes nuevas, y todo tipo de cosas que hacen que las bibliotecas, el codigo reusado, y hasta las especificaciones, sean relativamente nuevas y tengan fallos, es una carrera contra el tiempo. En alucion a esto: > "Esta claro que ni hoy ni mañana se van a llevar a cabo lo que propongo, te aseguro que a muchas empresas les saldria mucho mas barato realizar una auditori ade codigo exaustiva que los costos que con lleva descubrir el fallo" No se que tipo de programador seas, o si tengas experiencia en la auditoria de codigo, pero en lo que respecta al resto de nosotros, hacer una busqueda de fallos en un codigo, sea una auditoria exhaustiva o parcial, es con el proposito de encontrar bugs Y PARCHARLOS, a final de cuentas, no entiendo como es esto diferente, yo nunca hable de como encontrar bugs, yo hable de reparar bugs. Estoy de acuerdo con tu propuesta de la separacion de privilegios en Windows, el problema es que siempre existe un punto en la aplicacion en la que la mayoria de los servicios de, svchost.exe por ejemplo, tienen que comunicarse al kernel, por lo tanto no se puede hacer una separacion de privilegios de servicios criticos que realmente necesiten tener privilegios altos. La idea de separacion de privilegios se creo para aplicaciones en user-land. Pero a final de cuentas, es una propuesta buena, de la que estoy seguro que Microsoft ya debe estar estudiando. Tal vez estoy equivocado y puede haber alguna solucion para este problema de la comunicacion con el kernel o hasta RING-0. Saludos. PD: Tienen algun IRC o algo parecido esta comunidad?, tienen temas bastante interesantes y de habla hispana, eso es dificil de encontrar en mi opinion. Estoy completamente de acuerdo contigo, y tenia muy claro lo que intentabas explicar.

El problema es que esto ya existe, se entiende “Metodos automatizados” como:
1. Algoritmia, la solucion a muchisimos de tus problemas.
2. Especificaciones (RFCs, documentacion de protocolos, etc.)
3. Reusar codigo.
4. Bibliotecas.

Y el problema es que, aun usando todo esto, el codigo especifico de una aplicacion, el codigo reusado, el algoritmo, la biblioteca, o las especificaciones tambien suelen tener fallas. Otro problema es que siempre existen protocolos nuevos, algoritmos nuevos, herramientes nuevas, y todo tipo de cosas que hacen que las bibliotecas, el codigo reusado, y hasta las especificaciones, sean relativamente nuevas y tengan fallos, es una carrera contra el tiempo.

En alucion a esto:
> “Esta claro que ni hoy ni mañana se van a llevar a cabo lo que propongo, te aseguro que a muchas empresas les saldria mucho mas barato realizar una auditori ade codigo exaustiva que los costos que con lleva descubrir el fallo”

No se que tipo de programador seas, o si tengas experiencia en la auditoria de codigo, pero en lo que respecta al resto de nosotros, hacer una busqueda de fallos en un codigo, sea una auditoria exhaustiva o parcial, es con el proposito de encontrar bugs Y PARCHARLOS, a final de cuentas, no entiendo como es esto diferente, yo nunca hable de como encontrar bugs, yo hable de reparar bugs.

Estoy de acuerdo con tu propuesta de la separacion de privilegios en Windows, el problema es que siempre existe un punto en la aplicacion en la que la mayoria de los servicios de, svchost.exe por ejemplo, tienen que comunicarse al kernel, por lo tanto no se puede hacer una separacion de privilegios de servicios criticos que realmente necesiten tener privilegios altos. La idea de separacion de privilegios se creo para aplicaciones en user-land. Pero a final de cuentas, es una propuesta buena, de la que estoy seguro que Microsoft ya debe estar estudiando. Tal vez estoy equivocado y puede haber alguna solucion para este problema de la comunicacion con el kernel o hasta RING-0.

Saludos.

PD: Tienen algun IRC o algo parecido esta comunidad?, tienen temas bastante interesantes y de habla hispana, eso es dificil de encontrar en mi opinion.

]]>