#3 Admin, banea a este tio. Un chiste tan malo no debe permitirse.

#32 #3 #16 #5 Hace tiempo salió otra noticia sobre torio en MNM y salieron los mismos chistes y más. A ver si la encuentro.

P.S. China da luz verde a un reactor nuclear que quema torio, un combustible que podría abastecer al país durante 20.000 años (EN)

Hace 1 año | Por --557077-- a scmp.com

Publicado hace 1 año por --557077-- a scmp.com

China da luz verde a un reactor nuclear que quema ...

scmp.com

#52 Mente colmena. Me pasa con mis amigos comentando noticias, hago un par de chascarrillos, entro en meneame a leer la noticia y los mismos chistes estan en los comentarios.
No lo he robado conscientemente. Todo el crédito para el primero.

#3 además de ser un bonito río Leonés

#3 Acabas de provocar una epidemia de cancer... pero me he reido

#3 Te voy a dar una guantá que vas a parecer un tio vivo giratorio... Que gira y gira pero nunca torio...

#3 Ya lo dice el dicho: "Hasta el rabo todo es torio"

#3 ¿Se puede poner un comentario en portada?

#38 Debería por decreto ley

#3 me has provocado un cáncer de sida.

#3 Y eso es algo muy complicado de conseguir.

#10 Pues bastante, impera el centralismo económico frente a unas capitales de provincia que han cedido en el pulso y que asumen su labor geriátrica y de dormitorio.

#3 Claro que si, porque todos sabemos que Guadalajara, Ávila, Segovia, Toledo y Cuenca eran unos polos vibrantes de actividad económica puntera. Además, Guadalajara es a día de hoy una de las provincias que más crecen en empleo, empresas y actividad económica.

#39 Las desigualdades macroeconómicas crecen, no lo digo yo, es la estadística.

#87 exactamente lo mismo que había que hacer para arreglar lo de Crowdstrike. Modo seguro + borrar el driver.

#85 Si no ha salido en el telediario es porque el uso de Debían y Red Hat, aún siendo de las distros más populares, es testimonial en comparación con Windows.

#72 Pero si te acabo de poner dos ejemplos de que a Linux le ha pasado exactamente lo mismo .
El acceso a ring0 puede reventar cualquier sistema operativo y hay software (como los controladores del hardware o los EDR) que necesitan dicho acceso para realizar su trabajo.

#73 Por eso han salido en el telediario hablando de la caida de los sistemas Linux.

El Kernel Space de Linux no es el Far West de Windows

https://www.kernel.org/doc/html/v5.0/security/self-protection.html

#85 Si no ha salido en el telediario es porque el uso de Debían y Red Hat, aún siendo de las distros más populares, es testimonial en comparación con Windows.

#72 "Si Windoes lic..." El kernel panic pasaría en cada distribución windoes que hubiera cargado el módulo.

Que no solo ocurrió en Debian en Red Hat también.

#63 Si lo de Crowdstrike fue un fallo de diseño del SO, el mismo fallo tiene Linux.
https://www.theregister.com/2024/07/21/crowdstrike_linux_crashes_restoration_tools/

#66 Casos aislados por la heterogeneidad de las instalaciones Linux que a diferencia de las de Windows que son todas cortadas por el mismo patrón. Si Windows licenciara el kernel para que hubiera múltiples distribuciones de Windows esto no le pasaría.

#72 Pero si te acabo de poner dos ejemplos de que a Linux le ha pasado exactamente lo mismo .
El acceso a ring0 puede reventar cualquier sistema operativo y hay software (como los controladores del hardware o los EDR) que necesitan dicho acceso para realizar su trabajo.

#73 Por eso han salido en el telediario hablando de la caida de los sistemas Linux.

El Kernel Space de Linux no es el Far West de Windows

https://www.kernel.org/doc/html/v5.0/security/self-protection.html

#85 Si no ha salido en el telediario es porque el uso de Debían y Red Hat, aún siendo de las distros más populares, es testimonial en comparación con Windows.

#72 "Si Windoes lic..." El kernel panic pasaría en cada distribución windoes que hubiera cargado el módulo.

Que no solo ocurrió en Debian en Red Hat también.

#115 En #66 la tienes

#63 esos pantallazos no son responsabilidad de Microsoft sino de los proveedores de terceros.
Si Linux no dá esos problemas es porque apenas hay proveedores de terceros que generen módulos de linux (ni software comercial apenas). No porque sea más seguro, porque el diseño del sistema operativo a día de hoy es bastante parecido en los dos: kernels monolíticos.

#82 Hay una cantidad incalculable de firmwares privativas que corren integradas con el Kernel muchas son de una dudosa calidad.

#48 Lo peor de esa noticia es el poco caso que hicieron en CrowdStrike.

Lo mejor que el daño fué muy menor.

#48 Aislado o no, el caso de Crowdstrike en Windows no es un fallo de diseño del sistema operativo. Lo mismo que sucedió en Windows puede suceder (y ha sucedido) en Linux.

#53 Es un fallo de diseño del sistema operativo y de política empresarial, Linux no da ni la centésima parte de pantallazos que da Windows que es una masa informe de bloatware que a la mínima salta.

#63 Si lo de Crowdstrike fue un fallo de diseño del SO, el mismo fallo tiene Linux.
https://www.theregister.com/2024/07/21/crowdstrike_linux_crashes_restoration_tools/

#66 Casos aislados por la heterogeneidad de las instalaciones Linux que a diferencia de las de Windows que son todas cortadas por el mismo patrón. Si Windows licenciara el kernel para que hubiera múltiples distribuciones de Windows esto no le pasaría.

#72 Pero si te acabo de poner dos ejemplos de que a Linux le ha pasado exactamente lo mismo .
El acceso a ring0 puede reventar cualquier sistema operativo y hay software (como los controladores del hardware o los EDR) que necesitan dicho acceso para realizar su trabajo.

#73 Por eso han salido en el telediario hablando de la caida de los sistemas Linux.

El Kernel Space de Linux no es el Far West de Windows

https://www.kernel.org/doc/html/v5.0/security/self-protection.html

#72 "Si Windoes lic..." El kernel panic pasaría en cada distribución windoes que hubiera cargado el módulo.

Que no solo ocurrió en Debian en Red Hat también.

#115 En #66 la tienes

#63 esos pantallazos no son responsabilidad de Microsoft sino de los proveedores de terceros.
Si Linux no dá esos problemas es porque apenas hay proveedores de terceros que generen módulos de linux (ni software comercial apenas). No porque sea más seguro, porque el diseño del sistema operativo a día de hoy es bastante parecido en los dos: kernels monolíticos.

#82 Hay una cantidad incalculable de firmwares privativas que corren integradas con el Kernel muchas son de una dudosa calidad.

#14 totalmente de acuerdo

#14 Que sea incomparable no quiere decir que sea imposible. Y el agente de Crowdstrike ya provocó kernel panic en dos distros recientemente. Los sistemas operativos se protegen de esto a nivel de confianza (origen de los módulos/drivers), y cualquier sistema operativo va a otorgar confianza a un fabricante como Crowdstrike.

#43 #46 Lo llamo un caso aislado.

#48 Lo peor de esa noticia es el poco caso que hicieron en CrowdStrike.

Lo mejor que el daño fué muy menor.

#48 Aislado o no, el caso de Crowdstrike en Windows no es un fallo de diseño del sistema operativo. Lo mismo que sucedió en Windows puede suceder (y ha sucedido) en Linux.

#53 Es un fallo de diseño del sistema operativo y de política empresarial, Linux no da ni la centésima parte de pantallazos que da Windows que es una masa informe de bloatware que a la mínima salta.

#63 Si lo de Crowdstrike fue un fallo de diseño del SO, el mismo fallo tiene Linux.
https://www.theregister.com/2024/07/21/crowdstrike_linux_crashes_restoration_tools/

#66 Casos aislados por la heterogeneidad de las instalaciones Linux que a diferencia de las de Windows que son todas cortadas por el mismo patrón. Si Windows licenciara el kernel para que hubiera múltiples distribuciones de Windows esto no le pasaría.

#115 En #66 la tienes

#63 esos pantallazos no son responsabilidad de Microsoft sino de los proveedores de terceros.
Si Linux no dá esos problemas es porque apenas hay proveedores de terceros que generen módulos de linux (ni software comercial apenas). No porque sea más seguro, porque el diseño del sistema operativo a día de hoy es bastante parecido en los dos: kernels monolíticos.

#82 Hay una cantidad incalculable de firmwares privativas que corren integradas con el Kernel muchas son de una dudosa calidad.

#14 La grandísima mayoría de BSOD son por fallos de hardware y en este caso en particular es por software de terceros, lo primero es inevitable en cualquier situación, lo segundo pasa exactamente igual en Linux o en cualquier otro sistema que permita instalar controladores o programas de terceros con permisos de root/administrador.

El sistema de actualización de Windows si da puto asco pero está pensado para forzar a actualizar a gente que tiene cero conocimientos informáticos y que no lo harían nunca si no fuese tan intrusivo (lo que le lleva a liarla a veces), pero si, da puto asco.

#4 Linux puede reventar exactamente igual que Windows, ya pasó en mayo, y también la semana pasada

#10 En mi experiencia el número de pantallazos azules frente a los Kernel Panics es incomparable. Además el sistema de actualizaciones de Microsoft da puto asco.

#14 totalmente de acuerdo

#14 Que sea incomparable no quiere decir que sea imposible. Y el agente de Crowdstrike ya provocó kernel panic en dos distros recientemente. Los sistemas operativos se protegen de esto a nivel de confianza (origen de los módulos/drivers), y cualquier sistema operativo va a otorgar confianza a un fabricante como Crowdstrike.

#43 #46 Lo llamo un caso aislado.

#48 Lo peor de esa noticia es el poco caso que hicieron en CrowdStrike.

Lo mejor que el daño fué muy menor.

#48 Aislado o no, el caso de Crowdstrike en Windows no es un fallo de diseño del sistema operativo. Lo mismo que sucedió en Windows puede suceder (y ha sucedido) en Linux.

#53 Es un fallo de diseño del sistema operativo y de política empresarial, Linux no da ni la centésima parte de pantallazos que da Windows que es una masa informe de bloatware que a la mínima salta.

#63 Si lo de Crowdstrike fue un fallo de diseño del SO, el mismo fallo tiene Linux.
https://www.theregister.com/2024/07/21/crowdstrike_linux_crashes_restoration_tools/

#66 Casos aislados por la heterogeneidad de las instalaciones Linux que a diferencia de las de Windows que son todas cortadas por el mismo patrón. Si Windows licenciara el kernel para que hubiera múltiples distribuciones de Windows esto no le pasaría.

#115 En #66 la tienes

#63 esos pantallazos no son responsabilidad de Microsoft sino de los proveedores de terceros.
Si Linux no dá esos problemas es porque apenas hay proveedores de terceros que generen módulos de linux (ni software comercial apenas). No porque sea más seguro, porque el diseño del sistema operativo a día de hoy es bastante parecido en los dos: kernels monolíticos.

#82 Hay una cantidad incalculable de firmwares privativas que corren integradas con el Kernel muchas son de una dudosa calidad.

#14 La grandísima mayoría de BSOD son por fallos de hardware y en este caso en particular es por software de terceros, lo primero es inevitable en cualquier situación, lo segundo pasa exactamente igual en Linux o en cualquier otro sistema que permita instalar controladores o programas de terceros con permisos de root/administrador.

El sistema de actualización de Windows si da puto asco pero está pensado para forzar a actualizar a gente que tiene cero conocimientos informáticos y que no lo harían nunca si no fuese tan intrusivo (lo que le lleva a liarla a veces), pero si, da puto asco.

#4 vengo a hacer de "avocado" del diablo (🍐 👹).

Un mal módulo en el kernel te puede tirar un buen kernel panic. La diferencia es que a día de hoy no es muy común instalar módulos por tu cuenta: los sueles instalar a través del gestor de paquetes o a través de DKMS (que lo sueles instalar a través del gestor de paquetes también). Estos métodos vienen con scripts de configuración que lo hacen casi todo por ti, tanto los scripts como los binarios han pasado ya el control de calidad que aplica la distribución de turno por lo que tienes que esforzarte un poco si quieres romper el sistema. En los últimos años la única forma en la que he "roto" mi configuración es instalando (mal) los drivers de nVidia.

En Windows vas instalando cosas de aquí y allá, cada una de su padre y su madre, y las garantías son las que son: unas mejores y otras inexistentes.

En este caso la "ventaja" de Linux es que las distros suelen tener unos canales de distribución de software bastante centralizados (repositorios) y aceptablemente auditados, lo cual te filtra los desastres más gordos, pero tampoco es infalible.

#38 Pues no sé que estás defendiendo. En el caso que nos ocupa una actualización de un driver que se instala automáticamente rompe el sistema. Pero es driver es suministrado por producto dirigido a empresas y organizaciones que usan políticas de dominio y repositorios de parches.

Esto deja en muy mal lugar a las organizaciones que usan el producto en cuestión que emplea ese driver de funcionamiento incorrecto. En lugar de liberar la actualización para todos los ordenadores deberían haberlo liberado para unos pocos ordenadores que tengan configuraciones representativas de las que se usan en los departamentos de esa empresa. Una vez llevan funcionando una semana o dos sin errores liberan para todos los usuarios de esa organización.

El departamento IT no va a probar exhaustivamente si la cada actualización rompe algo, porque no tienen ni idea de usar todos los programas que se usan en cada departamento (por ejemplo no usan el programa de generar las nóminas), pero al menos van a detectar que tras una actualización el ordenador no arranca.

#54 Crowdstrike despliega un agente autoactualizable. Las políticas de actualización se gestionan desde su consola y permiten hacer pilotos y despliegues retardados, pero en el caso de esta actualización fallida se pasaron las políticas definidas por el forro.

#62 ¿Se pasaron las políticas por el forro el suministrador o fueron alginas empresa s clientes que no tienen esas políticas?

#113 Se pasaron por el forro las políticas de despliegue retrasado en empresas clientes que sí las tenían.

#54 claro... y mientras tanto dejas cientos de miles de pc's de empresas vulnerables porque "no puedes aplicarles el parche" frente a las últimas 20-30 vulnerabilidades descubiertas hasta que veas que el grupo canario no ha petado...

Si se hace así es para ofrecer protección en tiempo real frente a las últimas amenazas detectadas, lo cual en un entorno empresarial es lo más lógico (todos queremos estar protegidos frente a un 0 Day exploit tan pronto como se descubre)... otra cosa es que el QA haya sido una mierda y ese update no debiera se haber pasado a producción (y menos un viernes) bajo ninguna circunstancia...

#67 primera de cambio meten a producción a mas 8 millones de ordenadores. Modo psicópata.

#67 #54 Esperas una semana como máximo.

Estamos hablando de que potencialmente pueden petar servidores Windows con servicios empresariales ademas de workstation. Es un driver lo qué ha fallado. Qué sea Una mala configuration da igual. El driver no es lo bastante robusto para que ante una mala configuración no de un panic.

O esperar 24 horas. Si las cobayas se reinician bien se pasa el parche al repositorio general y que carguen el parche todos los demás ordenadores al siguiente reinicio.

Nosotros lo hacíamos en el laboratorio. El setup inicial no es difícil.

#54 En ppio el error no ha dado en un driver (que tiene que estar firmado por Microsoft para cargarse en el kernel), sino una configuración que carga el driver -este sí, firmado- (que habrá que ver si es una manera de cargar código en el kernel sin firmar ) que ha hecho que pete.

Como organización no puedes probar cada actualización, sobre todo porque si no lo tienes activado también te comes vulnerabilidades.

#4 esto te lo has inventado.

De hecho el kernel de Windows puede hacer esto que dices con drivers de tarjetas gráficas. Linux no.

#4 Llámalo como quieras, pero...
Relacionada https://www.meneame.net/go?id=3960830

#4 Cualquier módulo de linux da el mismo error que el de CrowdStrike y dá panic y tienes que reiniciar. De hecho si falla systemd entras en un bootloop como el del viernes pasado.

#79 Nope, si reinicias puedes hacerlo sin necesidad de cargar los módulos del Kernel. Y luego esta la pericia del administrador para que elimine el módulo conflictivo.

#87 exactamente lo mismo que había que hacer para arreglar lo de Crowdstrike. Modo seguro + borrar el driver.

#4 Esto… muy bien, y cuando tienes una solución de un tercero que te lo instala? No se como NVIDIA en Linux o CW en Windows?

¿Sabéis donde no entran? En macOS, que desde Catalina no acepta módulos que no sean de Apple de ninguna forma