Linus Torvalds ha sido una de las voces más críticas contra Intel cuando se destaparon los primeros problemas derivados de Meltdown y Spectre. El creador de Linux no dudó en disparar con toda su furia contra las soluciones propuestas por el gigante de chip, etiquetándolas como de “total y completamente basura”. Según cuentan en ZDNet, el conocido “dictador benevolente” de Linux ha vuelto ha hablar de Intel en el Open Source Summit North America que The Linux Foundation ha organizado y celebrado en la ciudad canadiense de Vancouver.
#4:
Greg Kroah-Hartman, posiblemente la segunda cara visible y el principal mantenedor de Linux en la actualidad, entró en detalles sobre el por qué arreglar los primeros problemas derivados de Spectre fue difícil para los desarrolladores del kernel, explicando que “no fue hasta el 25 de octubre del año pasado cuando la comunidad se enteró de los rumores sobre el fallo. Eso es mucho tiempo, y solo escuchamos rumores porque otro proveedor de sistemas operativos muy grande le dijo a Intel que nos lo contara”. Intel creó grupos aislados con SUSE, Red Hat y Canonical, pero parece que no contó nada a Oracle y no permitió una comunicación fluida ente empresas y comunidades. Y es más, a Debian no se le “permitió ser parte de la divulgación, por lo que la mayor parte del mundo fue pillado con los pantalones bajados.”
Debian es de hippies guarros y merecen ser tratados como escoria.
#10:
#8 Al hombre del saco le amenazaban sus padres con Torvalds cuando no se comia la comida.
#6:
Lo único que está haciendo es curarse en salud, para que cuando alguien tenga ganas de chillar porque el parche x.y.z ha reducido el rendimiento, le chille exclusivamente a Intel.
#17:
#12 Sigue siendo problema de hardware, no de software.
Greg Kroah-Hartman, posiblemente la segunda cara visible y el principal mantenedor de Linux en la actualidad, entró en detalles sobre el por qué arreglar los primeros problemas derivados de Spectre fue difícil para los desarrolladores del kernel, explicando que “no fue hasta el 25 de octubre del año pasado cuando la comunidad se enteró de los rumores sobre el fallo. Eso es mucho tiempo, y solo escuchamos rumores porque otro proveedor de sistemas operativos muy grande le dijo a Intel que nos lo contara”. Intel creó grupos aislados con SUSE, Red Hat y Canonical, pero parece que no contó nada a Oracle y no permitió una comunicación fluida ente empresas y comunidades. Y es más, a Debian no se le “permitió ser parte de la divulgación, por lo que la mayor parte del mundo fue pillado con los pantalones bajados.”
Debian es de hippies guarros y merecen ser tratados como escoria.
Lo único que está haciendo es curarse en salud, para que cuando alguien tenga ganas de chillar porque el parche x.y.z ha reducido el rendimiento, le chille exclusivamente a Intel.
#12 que no quita que tenga toda la razón del mundo,el fallo es de Intel no de del Kernel Linux ni del de Windows ni siquiera Mac que me imagino que también se habrá visto afectado
#12 La mayor parte de los programadores del kernel que contrata intel se dedican únicamente a hacer drivers de sus dispositivos, y lo digo con conocimiento de causa. Si bien es cierto que si tienen contribuidores a partes del core.
#9 Yo al mío lo llamaría "putísima mierda sin ninguna garantía de ningún tipo" para dejar las cosas claras desde el principio. El código lo liberaría bajo licencia Cthulhu-GPL 2.0
Digoyomelotoito... cuando me venden una tostadora con un defecto de fábrica la marca está obligada a cambiarmela por una nueva que funcione. ¿Porque no es igual con las CPUs? Hay dos años de garantía, al menos en España.
#20
Los defectos de fabricación o de diseño también están cubiertos por la garantía.
No sería la primera llamada general de un fabricante de coches por que haya alguna pieza mal de fábrica y/o diseño.
En unos se pone en peligro la integridad física del usuario. En otros casos se pone en peligro la privacidad de los usuarios.
#33 Muy complicado veo eso. Siempre va a haber vulnerabilidades. Es cierto que en el caso del software la actualización de seguridad siempre va a ser gratuita. En cuanto al coche, los errores de diseño se corrigen en las campañas sobre ese coche, no te dan uno nuevo. Como tampoco te van a dar un procesador nuevo ( y obviamente un procesador no se puede modificar internamente para arreglarlo).
En fin, que como dice Linus, al final tendrán que ser los desarrolladores de software los que solucionen la papeleta ( y lo harán) con toda la pérdida de potencia que ello supone.
#44
¿Que no te dan un coche nuevo? Pues mira lo que ha ocurrido con el DiéselGate en EEUU. Ahora VW tiene escampados enormes con coches sin oficio ni beneficio.
#19 Porque no son defectos de fábrica. Esto no es como los famosos bug FDIV o F00F, en los que instrucciones legales tenían comportamientos erróneos. En este caso las CPUs ejecutan las instrucciones correctamente, de acuerdo con las especificaciones. Meltdown y Spectre son ataques de canal lateral (https://es.wikipedia.org/wiki/Ataque_de_canal_lateral), y estos son mucho más difíciles de prever y de resolver.
#5 Benevolente en cuanto a su forma de actuar. Otra cosa es que le mente la familia a cualquiera que haga una metida de pata o que sostenga alguna opinión que considere que es una parida.
Los compiladores ya se encargan de generar el código necesario. No sé porqué habría que modificar el código de Linux.
Claro, hay mucho software privativo que no se recompilará nunca
#48
El que no tienes puta idea eres tú. Parchear el kernel no es obligatorio. Pero por ciertos motivos como los mencionados más arriba hay que hacerlo.
Subnorpedo.
Qué risa que me da eso de que un fallo HW de un procesador se puede solucionar por SW. Se lo voy a explicar este curso a mis alumnos de Arquitectura de Computadores.
En todo caso parchear, pero el villano siempre encontrará la entrada si tiene los conocimientos y herramientas adecuadas
Comentarios
Greg Kroah-Hartman, posiblemente la segunda cara visible y el principal mantenedor de Linux en la actualidad, entró en detalles sobre el por qué arreglar los primeros problemas derivados de Spectre fue difícil para los desarrolladores del kernel, explicando que “no fue hasta el 25 de octubre del año pasado cuando la comunidad se enteró de los rumores sobre el fallo. Eso es mucho tiempo, y solo escuchamos rumores porque otro proveedor de sistemas operativos muy grande le dijo a Intel que nos lo contara”. Intel creó grupos aislados con SUSE, Red Hat y Canonical, pero parece que no contó nada a Oracle y no permitió una comunicación fluida ente empresas y comunidades. Y es más, a Debian no se le “permitió ser parte de la divulgación, por lo que la mayor parte del mundo fue pillado con los pantalones bajados.”
Debian es de hippies guarros y merecen ser tratados como escoria.
"... ha vuelto ha hablar..."
#11
Lo único que está haciendo es curarse en salud, para que cuando alguien tenga ganas de chillar porque el parche x.y.z ha reducido el rendimiento, le chille exclusivamente a Intel.
#6 Normal, quienes deberían arreglarlo son los señores de Intel.
Pues teniendo en cuenta que como la mitad de programadores del kernel están en nómina de Intel, no sé quién tiene exactamente la sartén por el mango.
#12 que no quita que tenga toda la razón del mundo,el fallo es de Intel no de del Kernel Linux ni del de Windows ni siquiera Mac que me imagino que también se habrá visto afectado
#12 Sigue siendo problema de hardware, no de software.
#17 Que es la misma respuesta que la de ¿cuántos programadores hacen falta para cambiar una bombilla?
#12 La mayor parte de los programadores del kernel que contrata intel se dedican únicamente a hacer drivers de sus dispositivos, y lo digo con conocimiento de causa. Si bien es cierto que si tienen contribuidores a partes del core.
Si algún día saco un sistema operativo le llamaré Jusetex
#9 flipao
#23 Soy programador y desarrollo software. Dime que el nombre es una mierda pero de flipado nada
#25 Yo soy administrador de sistema y tengo que lidiar con tus chorra aplicaciones
#41 Y lo seguirás haciendo mientras me sigan pagando por hacerlas.
#42 flipaos los dos
#9 Un tal Nestor Soriano creó Nextor
https://www.msx.org/news/en/nextor-20-final-released
#9 Yo al mío lo llamaría "putísima mierda sin ninguna garantía de ningún tipo" para dejar las cosas claras desde el principio. El código lo liberaría bajo licencia Cthulhu-GPL 2.0
#28 Debe ser un puto infierno hacer un SO, la parte de sistemas de la informática me da dolor de cabeza sólo pensarlo. Never.
#29 Cómo hacer un SO:
1. Coge una distribución de Linux.
2. Cambia el papel tapiz por defecto.
3. ¿Problem?
#30 te dejas "cámbiale el nombre" entre el 1 y el 2.
#31 na, en el "papel tapiz" le pintas el nombre y no se nota. Problem?
Eso no vale para una nada. En OpenBSD han tirado el soporte SMT al cuerpo desde el arranque. Puedes activarlo de nuevo, pero solo bajo demanda.
AMD con la nueva vulnerabilidad se ha librado, por cierto.
Digoyomelotoito... cuando me venden una tostadora con un defecto de fábrica la marca está obligada a cambiarmela por una nueva que funcione. ¿Porque no es igual con las CPUs? Hay dos años de garantía, al menos en España.
#19 porque funcionan, realizan sus tareas, procesan la información... El pc está bien. Otra cosa es que hayan descubierto la forma de colarse en él.
Tu tostadora funciona pero seguro que hay alguna manera de romperla. No creo que sea muy difícil provocar un cortocircuito.
La cerradura de tu casa funciona pero a lo mejor es vulnerable a alguna técnica para forzarla y abrirla (bumping, por ejemplo)
Tu coche funciona pero se puede robar
Sigo?
Un saludo
#20
Los defectos de fabricación o de diseño también están cubiertos por la garantía.
No sería la primera llamada general de un fabricante de coches por que haya alguna pieza mal de fábrica y/o diseño.
En unos se pone en peligro la integridad física del usuario. En otros casos se pone en peligro la privacidad de los usuarios.
#33 Muy complicado veo eso. Siempre va a haber vulnerabilidades. Es cierto que en el caso del software la actualización de seguridad siempre va a ser gratuita. En cuanto al coche, los errores de diseño se corrigen en las campañas sobre ese coche, no te dan uno nuevo. Como tampoco te van a dar un procesador nuevo ( y obviamente un procesador no se puede modificar internamente para arreglarlo).
En fin, que como dice Linus, al final tendrán que ser los desarrolladores de software los que solucionen la papeleta ( y lo harán) con toda la pérdida de potencia que ello supone.
Un saludo
#44
¿Que no te dan un coche nuevo? Pues mira lo que ha ocurrido con el DiéselGate en EEUU. Ahora VW tiene escampados enormes con coches sin oficio ni beneficio.
#46 Y en España? O Europa? Yo no conozco a nadie al que le hayan dado un coche nuevo por fallos. Es más, preguntando a conocidos tampoco conocen ningún caso e incluso me remiten a casos en los que propietarios han quemado coches como protesta. http://www.caranddriver.es/coches/planeta-motor/el-cliente-mas-furioso-de-bmw-quema-su-serie-7-delante-del-museo
Saludos
#53
Pues eso, depende de las leyes de cada país. Pero que estamos ante el mismo caso es algo innegable. Coche defectuoso y procesador defectuoso.
Sin embargo un procesador genera unos ingresos del orden del 200 - 400% con respecto a su coste de fabricación. Un coche no pasa del 20-30%.
#19 Porque no son defectos de fábrica. Esto no es como los famosos bug FDIV o F00F, en los que instrucciones legales tenían comportamientos erróneos. En este caso las CPUs ejecutan las instrucciones correctamente, de acuerdo con las especificaciones. Meltdown y Spectre son ataques de canal lateral (https://es.wikipedia.org/wiki/Ataque_de_canal_lateral), y estos son mucho más difíciles de prever y de resolver.
debian es la mejor distro del mundo mundial, sucio capitalista.
Madre mía, madre mía, pero que os pasa en los dedos....pero que idioma habláis.....estáis poseídos y entonais cánticos satánicos...
Firmado por un analógico informático
#7 Son idiotas que pueden contar hasta uno.![:lol: lol](https://cdn.mnmstatic.net/v_149/img/menemojis/36/lol.gif)
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQlB0SWJY3rg02DwsIPFOHXPKuqDK4R07BrXL0fG2VpSO6H1aaX
https://en.wikipedia.org/wiki/Bob_Widlar
Se dice GNU/Linux... ah no, espera
Esto con Hurd no pasaría
¿Linus desde cuándo es un dictador benevolente?
#5 Benevolente en cuanto a su forma de actuar. Otra cosa es que le mente la familia a cualquiera que haga una metida de pata o que sostenga alguna opinión que considere que es una parida.
#5 Desde que no ha ido a tu casa a ejecutarte mientras tus padres, pareja e hijos miran.
ha vuelto ha hablar
Que suelten la guita.
Los compiladores ya se encargan de generar el código necesario. No sé porqué habría que modificar el código de Linux.
Claro, hay mucho software privativo que no se recompilará nunca
#1
La Glibc está de adorno
#1 me encanta la ignorancia que demuestras.
#35
La que demuestras tú
#36 si no tienes ni puta idea de por qué hay que parchear el kernel y crees que el compilador hace él sólito estas cosas... Es que eres un ignorante.
#48
El que no tienes puta idea eres tú. Parchear el kernel no es obligatorio. Pero por ciertos motivos como los mencionados más arriba hay que hacerlo.
Subnorpedo.
#1 el que menos idea tiene es el primero en comentar
#55
El más inútil es el penúltimo en contestar
Qué risa que me da eso de que un fallo HW de un procesador se puede solucionar por SW. Se lo voy a explicar este curso a mis alumnos de Arquitectura de Computadores.
En todo caso parchear, pero el villano siempre encontrará la entrada si tiene los conocimientos y herramientas adecuadas
#32 Si les has enseñado las unidades de control microprogramadas... muchos de estos fallos se solucionan reprogramando el microcódigo de la CPU.
#40 donde reprogramar significa desactivar las optimizaciones que causan el problema con su consecuente pérdida de rendimiento
A mí el señor Torvalds me da miedo sólo con mirarlo.
#8 Al hombre del saco le amenazaban sus padres con Torvalds cuando no se comia la comida.
#10 Y a Torvalds le amenazaban con Stallman
#26 Nah, Stallman no mete miedo. Yo creo que en las pesadillas de Torvalds sale Ballmer con el "developers, developers, developers...".
#10 No te equivoques, al hombre del saco le amenazan con mandarle a John Wick.
Con nada porque los bugs de Intel a no ser que desactives SMT vas a comértelos si o si. No son solo Spectre y el nuevo, hay OTRO más.
Feliz día. Yo desde OpenBSD como que me trae sin cuidado lo que haga GNU.
https://thehackernews.com/2018/06/openbsd-hyper-threading.html
Solo por eso (y por más cosas hacia OpenBSD) Intel merece irse a tomar por culo.
hablo del que menos idea tiene, no es incompatible con ser inútil