Gigante con pies de barro?

Y cualquiera que entienda esas frases e informes probablemente no se asuste al leerlo.

Todo el mundo sabe que Firefox apesta... y muchas de las razones por las que sabemos que apesta es porque podemos leer su código. Period.

- ferdy

Si empezamos a ver qué es lo que han analizado...

446 líneas de codigo nulas - ¿Ésto es una vulnerabilidad?
68 variables sin inicializar - ¿y?
Y un defecto no es un bug de seguridad...

Un usuario de otro foro usó este programa con el mítico "Hola mundo" y le daban 16 errores

SiC002 escribió:Un usuario de otro foro usó este programa con el mítico "Hola mundo" y le daban 16 errores

Por eso pregunto.

El caso es que si no fuera firefox nos creeriamos a pies juntillas lo de los fallos, sin mirar de que son.

Euler escribió:El caso es que si no fuera firefox nos creeriamos a pies juntillas lo de los fallos, sin mirar de que son.

Hola,

tú no te has enterado muy bien. Esos fallos SABEMOS EXÁCTAMENTE QUE SON, es más... si supieras, puedes mirar el código y decir: ¡andá un bug!, y pasearte por todos sus ficheros para ver la fauna que hay.

Esos no son "bugs" que afecten a la seguridad del programa. Afectan a la estabilidad, si todo un caso, ya que no tienen porqué. Muestran que hay errores por "malas costumbres", lo que no significa que eso sea la muerte.

Lo curioso de esto es que podemos saberlo perfectamente, porque vemos el código. Ya quisiera saber yo los "trapicheos" que hacen otros navegadores para conseguir un 0,4 segundos de incremento en la velocidad de procesado de JavaScript... te aseguro que más de uno se sorprendería. Pero, oh, no lo podemos saber porque son de código cerrado.

Cuando abres el código te expones a críticas como estas, las cuales te las has de tomar de manera constructiva. Hay empresas que no abren su código, no por miedo a que les "roben" (que es los que dicen los que hacen FUD), sino por VERGÜENZA a que vean la patraña de código que hacen.

Esa es la diferencia: esos "errores", "fallos", "bugs" o lo que tú quieras, no son peligrosos, sólo son feos... no deben afectar (si están bien hechos) a la estabilidad del programa o a su seguridad. Alguno puede que si, pero no han demostrado nada de eso.

Por cierto... escribe esto en el mismo directorio en el que tengas el código fuente del kernel:

egrep -ir "( fuck)|( shit)" *

Y disfruta con las frases que deja Torvalds y sus amigos en el código... es lo que tiene el software libre: todo se sabe.

Saludos.

Rurouni escribió:Cuando habres el código te expones a críticas como estas, las cuales te las has de tomar de manera constructiva. Hay empresas que no habren su código, no por miedo a que les "roben" (que es los que dicen los que hacen FUD), sino por VERGÜENZA a que vean la patraña de código que hacen.

Yo aquí al menos he visto un par de bugs bien gordos.

Pacorrr escribió:Yo aquí al menos he visto un par de bugs bien gordos.

La puta... últimamente no se que me pasa que cometo un webo de errores ortográficos tontísimos.

He de releerme los textos antes de enviarlos, que escribo mucho en muy poco tiempo y pasan estas estupideces.

Gracias

Edito
Arreglao... y de paso he revisado un presupuesto que iba a enviar... por si la disléxia se me ha propagado fuera de estos foros

Saludos.

De uno de los enlaces:

some guy escribió:
Disclaimer: I'm a former developer on the mozilla project and helped architect some parts of the mozilla codebase.

This is really bogus - many people have run code correctness tools on the mozilla/firefox codebase over the last few years and some good has indeed come out of it. There are always a few dangling pointers or missing null checks that could be added here and there. But to claim that there are 611 known, specific, real defects is just wrong.

With most of these tools the signal:noise ratio is very high. For example, most of these "dereferencing null" cases are either handled automatically by C++ template wrappers that do smart pointer management. Many of these "potential" memory leaks are handled automatically by XPCOM's refcounting.

To paraphrase jwz, (who normally I finally tremendously annoying) - these tools are helpful only if your time has no value.

This is not to say there aren't 141 other legitimate memory management defects lurking, but it takes a deeper (human) understanding of the codebase, as well as testing of actual codepaths in use, to flush them out.

To spend smart developers' time going over long reports of machine-generated lint would be a waste.

Quizá esto responda a tu pregunta.