[uylug-varios] linus, un amigazo ... de la nsa ??

[Fernando Da Rosa]

Ahora que pienso, lo anterior se podría resumir en la siguiente frase:

Con relación al kernel de un sistema operativo Linux no Linus es la mejor
opción.

Saludos
Fernando



El 10 de septiembre de 2013 13:51, Fernando Da Rosa
<fedaro at adinet.com.uy>escribió:

> Eduardo:
>
> Muy interesante.
>
> Finalmente es importante destacar el valor de pensar con cabeza propia y
> no seguir ciegamente a nadie.
>
> Saludos
> Fernando
>
>
>
> El 10 de septiembre de 2013 12:15, Eduardo Trápani <etrapani at gmail.com>escribió:
>
> > ¿Dónde empiezo una petición para elevar el cociente intelectual y del
>> > kernel de las personas? Chicos, id a leer drivers/char/random.c.
>> [...]
>> > los números aleatorios que obtiene de /dev/random. Respuesta muy corta:
>> > sois ignorantes”.
>>
>> Yo invito a leer el hilo donde se discutió eso, con la participación de
>> Linus. Es muy inteligente en mandar leer el código de *hoy*. Lo que no
>> dice es que lo que está hoy ahí no es lo que él quería. (más abajo van
>> los enlaces y la cita para que vean por ustedes mismos).
>>
>> Theodore Ts’o dice: "Estoy muy contento de haber resistido la presión de
>> los ingenieros de Intel para que /dev/random se basara únicamente en la
>> instrucción RdRand."
>>
>> ¿Saben quién estaba de acuerdo con esos ingenieros de Intel? Sí, Linus,
>> que quería darles "el beneficio de la duda" y devolver directamente lo
>> que diera el generado sin pasar por el pool[1]:
>>
>> > And for x86 CPU's with the RDRAND capability bit, I'd give
>> > Intel the benefit of the doubt and just make it do a single "rdrand"
>> > and return the full 64 bit (or is it a 32-bit interface? I should
>> > know, but I didn't look it up).
>>
>> Ahora puede decir lo que quiera. Pero de lo que dijo y apoyó no lo salva
>> nadie. Lo que nos "salvó" fue Ts'o que siguió peleando y no quiso darle
>> "el beneficio de la duda" a Intel. Con razón dice estar contento, fue un
>> visionario en cierta manera.
>>
>> No hay backdoor, pero pudo haber habido. Hay fuse, pero pudo no haber
>> habido. Linus es humano y le emboca y le erra. Eso sí, maneja tan bien
>> el asunto que las cosas buenas entran igual y las malas eventualmente
>> quedan afuera.  Y ahí estamos, sin acceso exclusivo al generador de
>> Intel y con fuse. Felices :). Aplaudible totalmente su laburo de
>> coordinador. Y lo mejor de lo que dice arriba es el "nosotros".
>>
>> De repente los demás tendríamos que aprender y no jorobar tanto con lo
>> que Linus quiere o deja de querer (y Linus ser más dulce, pero ya no
>> sería Linus ;)). El kernel es un equipo al que además entra y sale gente
>> según los subsistemas y el hardware. Sí, Linus hubiese dado la
>> posibilidad de un backdoor. Le falló la paranoia. ¿Y? Para que eso
>> entrara tenían que estar de acuerdo los otros mantenedores y no
>> estuvieron. Ahí entra el "nosotros".
>>
>> Y hay algo medio filosófico en esto, algo relacionado con velocidad e
>> inmediatez. Linus quería la mayor velocidad (por eso tira abajo también
>> el argumento arquitectónico de Matt) aceptando esa entrada sin
>> verificar. Queremos todo ya, pero el costo de la rapidez y facilidad (no
>> había que hacer ningún cálculo) podía haber sido medio alto. Es como una
>> indicación de que algún día vamos a tener que empezar a frenar un poco
>> para ver a dónde vamos tan apurados ... (perdón, me fui medio lejos).
>>
>> Eduardo.
>>
>> [1] http://article.gmane.org/gmane.linux.kernel/1173542
>> _______________________________________________
>> Uylug-varios mailing list
>> Uylug-varios at listas.uylug.org.uy
>> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy
>>
>
>
>
> --
> Fernando da Rosa
> fernando.darosa at gmail.com
> http://www.fedaro.info
>



-- 
Fernando da Rosa
fernando.darosa at gmail.com
http://www.fedaro.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.uylug.org.uy/pipermail/uylug-varios-uylug.org.uy/attachments/20130910/ffe5ecbf/attachment-0002.htm>