Portada
mis comunidades
otras secciones
#14:
#11 Sí, un proyecto fracasado que es el más usado en supercomputación, en servidores, lo usa la NASA, Amazon, Wikipedia, Facebook,Google, la FAA, el CERN, en conducción autónoma de vehículos, en sistemas de entretenimiento y domótica...y sin olvidarnos del sistema operativo más usado en dispositivos móviles ANDROID....todo un fracaso
#39:
#24 Si Stallman no hubiera tenido un kernel con el que poder funcionar (Linux) posiblemente le hubiera dedicado mucho más esfuerzo a Hurd y bastante menos al resto de GNU (con lo que habríamos salido perdiendo). Y Linux tampoco hubiera llegado donde está porque Linus Torvalds habría tenido que programar todas las utilidades de GNU sin la ayuda de estos, cosa que había comenzado a hacer, pero como llegó GNU se centró en el kernel y pudo dejar ese trabajo a otros.
"Estoy haciendo un sistema operativo (gratuito, sólo un hobby, no será nada grande ni profesional como GNU) para clones AT 386(486). Llevo en ello desde abril y está empezando a estar listo. Me gustaría saber su opinión sobre las cosas que les gustan o disgustan en minix, ya que mi SO tiene algún parecido con él.[...] Actualmente he portado bash(1.08) y gcc(1.40), y parece que las cosas funcionan. Esto implica que tendré algo práctico dentro de unos meses..."
Ninguno de los dos habría llegado donde está sin el otro y sin que Hurd pasara a ser algo secundario. Decir que han fracasado por dejar a Hurd en segundo plano es, cuando menos, un poquito exagerado.
"Estoy haciendo un sistema operativo (gratuito, sólo un hobby, no será nada grande ni profesional como GNU) para clones AT 386(486). Llevo en ello desde abril y está empezando a estar listo. Me gustaría saber su opinión sobre las cosas que les gustan o disgustan en minix, ya que mi SO tiene algún parecido con él.[...] Actualmente he portado bash(1.08) y gcc(1.40), y parece que las cosas funcionan. Esto implica que tendré algo práctico dentro de unos meses..."
Ninguno de los dos habría llegado donde está sin el otro y sin que Hurd pasara a ser algo secundario. Decir que han fracasado por dejar a Hurd en segundo plano es, cuando menos, un poquito exagerado.
#33:
#24 Stallman no lleva años apropiarse de Linux.
Linux (SO) es tanto o más GNU que Linux (kernel).
La contribución de GNU a Linux (SO) es enorme.
Para empezar no habría Linux hoy en día si no fuese por el gcc de Stallman.
Además se os olvida que aparte de Linux existen otros kernel disponibles como el de BSD.
Linux (SO) es tanto o más GNU que Linux (kernel).
La contribución de GNU a Linux (SO) es enorme.
Para empezar no habría Linux hoy en día si no fuese por el gcc de Stallman.
Además se os olvida que aparte de Linux existen otros kernel disponibles como el de BSD.
Comentarios
#11 Sí, un proyecto fracasado que es el más usado en supercomputación, en servidores, lo usa la NASA, Amazon, Wikipedia, Facebook,Google, la FAA, el CERN, en conducción autónoma de vehículos, en sistemas de entretenimiento y domótica...y sin olvidarnos del sistema operativo más usado en dispositivos móviles ANDROID....todo un fracaso
#14 Creo que se refieren a GNU... no al núcleo Linux.
#20 Si estamos comentando la noticia hablamos de Linux, pero si quiere atribuirlo a GNU puedo decirle lo mismo
#23 Ya... pero al leer "sistema operativo fallido", yo entiendo que no se refieren al núcleo Linux (nunca tuvo vocación de ser un OS); sino al proyecto GNU, que si consistía en crear un OS compatible sin código de los UNIX propietarios.
#16 #14 Sí, se refiere al proyecto GNU fundado por Stallman y al núcleo Hurd
https://www.gnu.org/software/hurd/hurd.html
#22 Ya, pero que tiene eso de "querer apropiarse de Linux".
Solo alguien que no tenga la más remota idea de Linux y del software libre en general puede afirmar tal aberración.
#14 ¿Hoy si toca que Android es Linux?
#28 Android lleva un núcleo Linux. Punto.
https://es.wikipedia.org/wiki/Android
#14 El proyecto fracasado no es Linux, es GNU (el sistema operativo GNU basado en el kernel Mach, que en 36 años no ha logrado sacar una versión 1.0 operativa). O no me he expresado bien o ha fallado tu compresión lectora.
#29 GNU usa varios Kernels como kFreeBSD, Hurd o Linux que es el mas usado. Pero vamos, decir que GNU es un fracaso es un error. Lo que es un fracaso es Hurd
#38 eso es despreciar GNU. Lo que estas llamando GNU es sólo el servicio de compatibilidad POSIX. Es como si dijeras que FreeBSD es igual que macOS cambiando Darwin por kFreeBSD.
Pero es que además tienes Linux que no usan bash o glibc y siguen siendo sistemas Linux tradicionales. Es más, Linux no ha usado glibc como implementación de libc durante años.
Pero sobre todo, son proyectos diferentes e independientes y que no comparten diseño más allá de ser compatible POSIX los dos (igual que Windows).
Si fuesen consecuentes llamarían a esos Linux de la Windows Store GNU/Windows.
#40 Si Windows fuera software libre tal vez lo harían, pero como de libre tiene muy poco probablemente GNU no quiere que le relacionen con Windows ni en pintura, seguramente preferiran algo como Ubuntu/Windows (por aquello de que esos "Linux" suelen estar basados en Ubuntu y este es el responsable de eso y no GNU).
Si por GNU fuera dudo que eso existiera.
#41 Pero eso no es ser consecuente. Si Stallman quería que los sistemas operativos que compartiesen código de GNU se llamase GNU/algo lo debería haber puesto en la licencia, pero no es así y decir que el GNU "original" es igual al SO Linux cambiando Hurd por el kernel Linux es mentir. Sólo tienes que comparar una puñetera Debian GNU/Linux con una Debian GNU/Hurd. Hay más diferencias que entre OpenSuse Linux, FreeBSD y AIX.
#43 Para empezar la licencia es libre y puedes llamarlo como quieras, Android también es Linux pero no lo menciona por ninguna parte, además, para incluir algo así en la licencia necesitaría que todos los autores estuvieran de acuerdo, y Linus Torvalds creo que no está por la labor (tampoco se opone, pero dudo que aceptara a obligar a hacer tal cosa).
En cuanto a las diferencias Android es Linux pero se parece a cualquier otro SO basado en Linux bastante menos que FreeBSD o AIX. ¿Y? Sigue siendo el código de Linux (aunque tenga algunas modificaciones, que para eso es libre, y se use de forma distinta) y Debian GNU/Linux sigue teniendo el código de las utilidades GNU (no será el mismo pero será de GNU) lo mismo que en Debian GNU/Hurd aunque funcionen de distinta forma.
En mi opinión, si el SO usa la base de utilidades de GNU decir GNU/Linux da más información que decir sólo Linux, puedes no usarlo, pero si unos lo usan y otros no también puede dar lugar a errores (más de los que ya hay por usar la misma palabra para referirse a 2 cosas distintas) y habiendo gente que ya la usa prefiero hacerlo (ocurre como con la "i" en KiB, MiB, GiB,... para indicar que es múltiplo de 1024, hay quien todavía no la pone y si te hablan de KB, MB, GB nunca sabes si te están hablando de múltiplos de 1000 o de 1024 salvo que te den alguna pista)
#46 Pero es que Linux puede o no puede usar las utilidades GNU sin dejar de ser una distribución Linux tradicional.
Android es un SO con kernel Linux pero no es un SO Linux tal como entendemos habitualmente.
Pero es que la cuestión de peso es que glibc y las gnu-utils no son la base del sistema GNU, sino que es la capa de compatibilidad POSIX y que además muchas ni tan siquiera se implementaron ni en hi para GNU, sino para diferentes sabores UNIX.
Y sobre todo, es que hi conceptualmente, ni por implementación, ni por compatibilidad, ni por diseño el SO Linux es lo mismo o se parece al SO GNU y decir que una distribución Linux es lo mismo o tan siquiera comparable al SO GNU cambiando el kernel Hurd por el kernel Linux es mentir.
Que los señores de Debian quieran llamar a su distribución Linux Debian GNU/Linux están en su derecho, pero que no intenten obligar que el resto llame igual a sus propias distribuciones, ni decir que es lo correcto, porque no lo es, ni mucho menos intentar convencernos que Debian es la única y verdadera distribución ni demás monsergas.
#47 Android no es un SO Linux como lo entendemos habitualmente, posiblemente porque estos son GNU/Linux (o pueden no serlo pero lo que sí son es equivalentes) y Android no lo es (va a su bola y no hace casi nada de lo que hace una distro Linux con las utilidades GNU).
No he entendido muy bien tus tercer y cuarto párrafo. No entiendo a lo que quieres llegar, que las utilidades GNU con Linux, con Hurd o con BSD no funcionan igual porque lo que hay debajo no es lo mismo y no lo pueden hacer (incluso el que haya que poner o quitar aplicaciones) no veo en qué afecta a que esas utilidades básicas que necesita el SO las hayan programado desde el proyecto GNU en todos esos casos.
#46 Perdón por el offtopic, pero yo creo que los que tendrían que cambiarse el nombre son los sufijos de los múltiplos de 1000, ya que Kb es kilobyte de toda la vida. Si quieres cambiar los múltiplos, utiliza otra nomenclatura, pero no obligues a cambiar el original, porque aparte de hacer obsoleta la literatura anterior, no tiene sentido.
Pero igual me equivoco.
#70 Ya, pero es que lo han hecho porque los prefijos K, M,..., ya existían mucho antes como múltiplo de mil, por ejemplo Km (kilómetro, 1000 metros),..., y es sólo en informática, algo bastante reciente, cuando se ha usado como múltiplo de 1024. En el fondo lo más lógico es lo que han hecho: mantener la nomenclatura más antigua y de uso más amplio y modificar la nomenclatura más reciente y específica, la informática.
Eso sí, lo de la literatura va a ser un follón que va a durar décadas.
#71 Lo de los prefijos es cierto, es el sistema internacional, pero en este caso tan específico, en el que ya existe una cultura internacional homogénea al respecto ( no es lo mismo que usar onzas o galones ), me parece absurdo. También se siguen usando las millas marinas, y los nudos para velocidad marina y aérea, y no se ha muerto nadie ( bueno, sí, la Mars Climate
), querer revertir un estándar global de este calibre me parece absurdo, y de hecho en mi opinión no han conseguido nada. Cuando todo el mundo conoce el estándar, no pasa nada porque kilo en informática se refiera a 1024.
El problema, en general, es el contrario, que no exista consenso, que se añadan complejidades donde no las hay. Y en mi opinión, aparte de algunos problemas históricos ( velocidades de transmisión medidas históricamente en kbps, en potencias de 10 ), lo lógico sería tener una medida universal que todo el mundo entienda y acepte. En gran medida creo que los fabricantes de discos duros y las compañías de cable se han beneficiado de utilizar la nomenclatura que mostraba mayores números, sin importarles nada el consenso.
En cualquier caso, prefiero usar KiB en potencias de 2, que kb en potencias de 10 para medidas de tamaño en informática.
#72 Creo recordar que el problema que originó el cambio se debe a que los fabricantes de hardware utilizan múltiplos de 1000 en vez de múltiplos de 1024. De ahí que si compras una unidad de 1TB (según el fabricante) no tenga un TiB ni de lejos (y la culpa no es del formateo, por mucho que ellos afirmen eso). Y creo recordar que a pesar de haber sido denunciados en varias ocasiones por ello resulta que han ganado los juicios, con lo que pueden seguir usando múltiplos de 1000 por su cara bonita.
Así que no quedaba otra, o usar una unidad que para los fabricantes es una cosa y para los consumidores es otra o cambiar de unidades.
Lo de los jueces y la informática eso sí que no tiene explicación.
#73 Eso puede influir también, pero es cierto que en algunos ámbitos no se puedan permitir tales ambigüedades en la nomenclatura ( véase el caso de la ya mentada Mars Climate, el tiro al plato más caro de la historia ), y también el sector de transmisión de datos vía internet, que tradicionalmente ha usado siempre kilobits de base 10, con lo cual ya tenemos el pollo montado.
Mi opinión es que es más sencillo mantener en este caso lo que ya todo el mundo había aceptado como un estándar. Lo de los discos duros, en realidad da un poco igual cuando le coges el tranquillo, cuando todo el mundo sabe que sus TB no son los mismos que los del resto, ya calculas un 20% menos a ojo, el truco no va a durar toda la vida...
#74 Hay un montón de servicios, aplicaciones,'sistemas operativos, fabricantes que utilizan medidas en bytes y no hay forma de saber si usarán múltiplos de 1000 o de 1024.
Como dices es tu primer párrafo no se pueden permitir ambigüedades, no puedes depender de aplicar un truco a ciegas sin saber si vas a acertar o no.
Además, tampoco es un 20% de diferencia, esta crece conforme aumenta el valor, entre KB y KiB es de un 2,4%, entre GB y GiB es de un 7,37%,...
Pero lo peor es que hasta que no pase un tiempo, todo el mundo adopte el nuevo sistema y "desaparezcan" las aplicaciones y la bibliografía que están obsoletas tampoco lo estás. Una cagada enorme por culpa de una decisión judicial
#14 se refiere a Hurd no a Linux.
#24 Stallman no lleva años apropiarse de Linux.
Linux (SO) es tanto o más GNU que Linux (kernel).
La contribución de GNU a Linux (SO) es enorme.
Para empezar no habría Linux hoy en día si no fuese por el gcc de Stallman.
Además se os olvida que aparte de Linux existen otros kernel disponibles como el de BSD.
#24 Si Stallman no hubiera tenido un kernel con el que poder funcionar (Linux) posiblemente le hubiera dedicado mucho más esfuerzo a Hurd y bastante menos al resto de GNU (con lo que habríamos salido perdiendo). Y Linux tampoco hubiera llegado donde está porque Linus Torvalds habría tenido que programar todas las utilidades de GNU sin la ayuda de estos, cosa que había comenzado a hacer, pero como llegó GNU se centró en el kernel y pudo dejar ese trabajo a otros.
"Estoy haciendo un sistema operativo (gratuito, sólo un hobby, no será nada grande ni profesional como GNU) para clones AT 386(486). Llevo en ello desde abril y está empezando a estar listo. Me gustaría saber su opinión sobre las cosas que les gustan o disgustan en minix, ya que mi SO tiene algún parecido con él.[...] Actualmente he portado bash(1.08) y gcc(1.40), y parece que las cosas funcionan. Esto implica que tendré algo práctico dentro de unos meses..."
Ninguno de los dos habría llegado donde está sin el otro y sin que Hurd pasara a ser algo secundario. Decir que han fracasado por dejar a Hurd en segundo plano es, cuando menos, un poquito exagerado.
#11 Llevo toda la vida en esto y no me queda claro a quién te refieres.
Más que nada por que creo que estás confundiendo churras con merinas.
¿Puedes aclarar a quién te refieres?
#12 yo diría que a Stallman. O eso parece.
#12 creo que habla de stallman, que lleva años queriendo apropiarse de linux porque claro, un kernel sin programas no vale para nada,y seamos serios, hurd es un fracaso
#12 Richard Stallman, por supuesto.
GNU (Gnu is Not UNIX) es su proyecto estrella de crear un sistema operativo 100% libre compatible POSIX pero que vaya más allá del paradigma UNIX.
Para empezar, debía usar un microkernel, en principio GNU-Mach, dónde la compatibilidad POSIX sería suministrada por un servicio en espacio usuario corriendo como un proceso Mach (un diseño similar a Windows NT y a macOS X, ambos también basados en Mach). La principal diferencia es que en la mayoría de sistemas operativos basados en Mach los servicios de sistema se implementan sobre un único servidor (un único proceso Mach) mientras que en GNU cada servicio se implementa en servidores independientes.
Como se puede ver, nada que ver con Linux, que "solo" pretende ser un S.O. estilo UNIX. Reutiliza componentes de GNU (a veces, no siempre, y no obligatoriamente) que originalmente eran reimplementaciones de librerías o aplicaciones UNIX que se desarrollaron en sistemas UNIX y que GNU reutilizó para su proyecto. Dicho software esta licenciado con licencias GPL/LGPL, que solo exigen que el software derivado mantenga la licencia y el crédito de los desarrolladores, pero no exige, ni recomienda ni nada sobre el nombre que deben tener los proyectos derivados. Así que usar glibc o bash no te obliga a que tu proyecto se llame GNU/loquesea ni nada parecido.
Desde 1982 hasta hoy, Richard Stallman y sus muchachos no han logrado sacar una versión funcional de GNU, ni tan siquiera acaban de tenerlo diseñado. Además, la razón "política" de desarrollar GNU, la necesidad de tener un S.O. libre, ya esta ampliamente cubierto con Linux, los diferentes sabores BSD y otros sistemas más exóticos. Así que menospreciando su propio diseño y trabajo, para salvar algo de su ego, defienden que las distribuciones Linux sería algo así como el sistema GNU pero en vez de usar el kernel GNU-Mach y los servidores Hurd usa el kernel Linux y por tanto en realidad el S.O. sería GNU/Linux en lugar de GNU/Hurd. Lo que pasa es que no es cierto, a menos que simplifiques mucho (es como si dijeses que FreeBSD y macOS X son básicamente el mismo S.O. con un cambio de kernel).
#27 Me lo figuraba. Churras Merinas.
No hay persona que haya insistido más en no apropiarse de el kernel de Linux que Stallman.
#27 No he visto nada en todo tu comentario que de a entender que se quiere apropiar de algo.
#58 Del nombre de un proyecto ajeno e independiente. Mejor dicho, quiere hacer pasar el proyecto de otros por el suyo propio, pidiendo a otros lo que él mismo no ha hecho, porque no tenía porque hacerlo, ya que la licencia no le obligaba, y Linux tampoco está obligado porque la licencia no le obliga.
Pero sobre todo, lo principal es que el SO GNU no es un SO Linux con mikrokernel Mach (eso ya ha existido y se llamaba mklinux) ni Linux es un sistema GNU con kernel monolítico tipo UNIX porque GNU es un sistema intrínsecamente pensado para microkernel.
GNU se ha aprovechado de una implementación de la libc, que les fue donada, llamada glibc y de una implementación de las UNIX utils, que tanto una como las otras ya fueron muy populares en sistemas UNIX en los 80 y 90 y que Linux también utiliza. Pues perfecto, de eso se trata el software libre. Pero ni esas UNIX utils son la base de GNU (porque GNU is Not UNIX) igual que las UNIX utils de FreeBSD no son la base de macOS; ni la glibc es la principal interfaz de programación de GNU.
#61 " Mejor dicho" --> Te corrijo, "tu dices". Deja claro que es una opinión tuya. Sigo esperando pruebas de que ese sea el deseo de Stallman. No te moleste en escribir chorradas kilométricas. O presentas pruebas de lo que afirmas o no te va a creer ni tu padre.
#62 Lo dijo él mismo, no es una ida de olla mía.
#42 sí, claro, lo suyo es actualizar todo, pero viendo que intel ha recomendado no instalar alguno de los parches yo esperaría a instalarlo. Realmente es difícil de explotar, y si estás en la nube los proveedores ya han hecho lo pertinente para que no puedas acceder a la memoria de otra VM que esté funcionando en la misma máquina física.
#49 la cuestión es que salen nuevos kernels continuamente, de manera periódica así que que saquen una nueva versión no depende de Meltdown u otros bugs...
El tema de la mejora para AMD ya tocaba....
#0 las perdidas de rendimiento son iguales que las que hay en windows?
#3 No sabria decirte, no uso windows en mis equipos personales y en los de mi trabajo (donde si tengo win) el rendimiento es igual de malo antes y despues del parche, por ahora mi unico problema viene siendo que VirtualBox me dejo de funcionar con el repositorio oficial de Ubuntu, pero se arregla insralando la ultima version desde la web de VB
#3 Si usan la técnica o método "retpoline" optimizado de AMD, no solo hay pérdida sino una pequeña o mayor ganancia en procesadores Ryzen y EPYC.
Fíjate en las gráficas donde ponen "Minimal AMD retpoline" y básicamente en las barras de color gris.
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.15-FX-Zen
Salu2
Lo acabo de instalar e Instagram va más rápido
#6 Te hemos cazado la mentira. Todo el mundo sabe que un verdadero linuxero lo primero que hubiese probado es xhamster.
#21 mentira. Hubiese compilado el kernel quitando todos los modulos y features que no necesita. Mientras, en terminal, hubiese visto xvideos en ascii
#26 parece el plus:
Y ahora mi pregunta porque tengo un poco de lío (también reconozco que no me he dejado los ojos buscando información, mea culpa): ¿para solucionar el agujero de seguridad es suficiente con actualizar Linux, es suficiente con actualizar la BIOS o es necesario actualizar las dos cosas para que sirva de algo?
#18 necesitas cambiar la CPU por una que no tenga esos agujeros. Los parches del Kernel y de Intel solo dificultan su explotación, arreglan el error para el tipo de ataque publicado, pero no sé sabe si hay más posibilidades de ataque que sigan funcionando aún con estos parches.
#30 gracias por la explicación.
Supongo que es mejor actualizar tanto firmware como sistema operativo que solo una de las dos cosas, ¿no?
#18 Para "solucionar" el agujero... es necesario actualizar el procesador, cuando tengan a bien sacar nuevos sin estos fallos, y/o les dé la gana sacar parches de microcódigo (estos pueden ir incluidos en una actualización de la BIOS, o cargarse con el kernel, o como sea).
Pero por el momento eso no existe, así que lo que se puede hacer es actualizar Linux (el kernel) para evitar las consecuencias más graves de estos fallos. Seguirán existiendo en el sistema afectado, pero "se supone" que no afectarán "tanto" a la seguridad de todas las cosas.
#63
+***
En mi sistema, la misma instalación/actualización de nvidia mete los módulos en blacklist y carga el que yo le diga.
**
Cierto pero en el mio tenía en modo a prueba de fallos tenía el nouveau corriendo. En algunas nvidia es necesario instalar el VESA general, desinstalar manualmente el nouevau, reiniciar, compilar e instalar el NVIDIA si es ese
*
Como he dicho, se compila en segundos el s
*
En minutos. Pero si te falla algo no puedes entrar en el kde/plasma, etc... Sobre todo cuando el nouveau en esa tarjeta concreta hace fallos un poco "arbitarios" y puedes perder rato y rato si no sabes que debías de quitar el nouveau incluso en modo texto por el VESA genérico (aunque tenga menor resolución y muchas menos prestaciones que el nouveau no están peleados de la misma forma)
*
pero imagino que en tu caso usas el controlador de nvidia en lugar del que te proporciona tu distro.
*
no. NO funcionaba aunque se instalaba bien y daba errores en el OpenGL. Uso el de la propia NVIDIA de su web
*
pero no impide su compilación ni que funcione luego el sistema mientras desinstales/metas en blacklist a nouveau,
**
En mi caso sí.. En algunas tarjetas NVIDIA nouveau no puede estar cargado en el kernel o ya puedes sudar días, y perder horas einicializando, probando, cargando, etc
En la información del driver de la web de NVIDIA de hecho se indica que se cambie por VESA genérico y se descargue el nouveau del kernel y se esté seguro que no esté cargado
Además no es el driver concreto para la tarjeta en sí, con el driver mete un montón de versiones de archivos para las X y OpenGL
Y es que algunos modelos se exceden un pelín. Pero una vez instalado bien y con suficiente RAM, pues es de cine eso sí...
#11 madre mia colega, tu comentario da CÁNCER.
Lider de un proyecto fracasado? Seguro que tu eres capaz de montar un kernel y un ssoo como UNIX o POSIX desde cero, y en un par de horitas... Madre mia vaya lammer...
#11 ¡Hooostias!
que bien. intel ya ha corregido las meteduras de pata de las semanas anteriores? o esto va de parte de linus y sus amigos?
#7 Intel no puede solucionar el problema, sólo han emitido parches de seguridad para mitigar el riesgo.
#8 y esos parches hacen que se reinicien los servidores aleatoriamente. han corregido esos problemas? ya no se reinician?
#10 Aleatoriamente no... sólo cuando es posible que pudiese ser explotado alguno de los fallos.
#8 Ha publicado y han aconsejado no aplicar esa actualización ya que provoca reinicios aleatorios.
#7 Esto va de Linus y sus amigos. Hasta que no saquen una actualización de las CPUs en condiciones seguiran afectados los equipos aunque los parches del kernel dificultan muchisimo su explotación. De todas formas al ser un problema de diseño de las CPU, me da que el "parche" de Intel va a ser más de lo mismo y tampoco solucionarán el problema.
#8 Lo mismo con arm: https://developer.arm.com/support/security-update
#7 A la espera: https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File
Y se deberán en algunos casos compilar (por enésima vez) controladores para el nuevo kernel
¡que bien!
#44 no sé qué pŕoblema le ves, la verdad, lo que haya que compilar que dependa del kernel son cosas que se deberían hacer de manera automática. Además, hay mejoras.
«En la ‘gran’ fotografía, 4.15 se ve perfectamente normal, con dos tercios de todos los parches de 4.15 yendo a parar a los drivers, no para mitigaciones de errores de la CPU”»
#48
**
#44 no sé qué pŕoblema le ves, la verdad, lo que haya que compilar que dependa del kernel
**
En las horas (muchos) que me he pasado yo para instalar los controladores de nvidia de mi tarjeta y funcionaran...
Simplemente no podían compilar e instalarse si estaba el controlador "nouveau" cargado en el kernel en modo texto al arrancar el PC (se ha de cargar el VESA genérico, desinstalar nouveau y que no haya rastro y luego pasar a compilar y cargar los drivers de algunas de esas NVIDIA que o es así o así, que además necesita su versión de OpenGL y su control de RAm porque unen algunas RAM de la tarjeta gráfica con RAM del PC para que funcione el CUDA)
Bueno. ya veremos ahora tengo el 4.13.12 y no se, no se...
#49 Pues no sé que usarás tu, pero en mi sistema el controlador de nvidia se compila el solito automáticamente cuando hay alguna actualización, conviviendo perfectamente con nouveau, y no son horas lo que tarda, más bien segundos... De todas formas, me pregunto que tendrá que ver el que venga el kernel 4.15 con los parches para mitigar la posible explotación de la vulnerabilidad y los controladores gráficos...
#53 tardé muchas horas en poder hacer que rulara por problemas. Algunas tarjetas NVIDIA necesitan imperiosamente que el nouevau no esté presente (no todas, pero la mía es una de ellas) de ninguna forma y se afectan mútuamente
*
el kernel 4.15 con los parches para mitigar la posible explotación de la vulnerabilidad y los controladores gráficos...
**
El tener que volver a compilar con riesgo de que el sistema deje de funcionar y que algunas tarjetas NVIDIA parecen sensibles también a alguna de esas vulnerabilidades
#56 pues en realidad lo que ha hecho es ralentizar el desarrollo así que no sé que es lo que te parece mal: La realización de Linux 4.15 se convierte en la versión más lenta desde 2011
La realización de Linux 4.15 se convierte en la ve...
maslinux.esSi no quieres que esté noveau desistálalo y márcalo para que no se instale. Y lo de compilar me suena raro, como si estuvieras usando gentoo. Yo uso Arch (Manjaro) y sólo compilo lo que necesito y nunca he compilado cosas gordas (kernel, drivers) precisamente porque a) se tarda la vida. b) mi ordenador no tiene espacio suficiente para compilar cosas de varios gigas.
¿Seguro que no tienes otra opción?
#60
**
Si no quieres que esté noveau desistálalo y
**
No es que no quiera sino que el driver concreto y nouveau no pueden estar presentes a la vez, O falla la composición y otras cosas... Se llevan mal, el driver propietario es que lleva montón de versiones de archivos de las X y de openGL
*
¿Seguro que no tienes otra opción?
*
No, pero ya me he acostumbrado... Cuando empecé en GNU/linux entonces la slackware 2.0 ya le cogí costumbre, controlar bibliotecas, versiones...
Es lo que hay pues en fin
#66 espero que no me pase lo mismo alguna vez porque suena difícil.
#56 Algunas no, todas, no puedes tener dos módulos cargados para el mismo dispositivo. En mi sistema, la misma instalación/actualización de nvidia mete los módulos en blacklist y carga el que yo le diga. Como he dicho, se compila en segundos el solo si hay actualización de éste o del kernel. No sé que distro usas tú, pero imagino que en tu caso usas el controlador de nvidia en lugar del que te proporciona tu distro. No necesita que esté "descargado" el controlador libre, el error que te puede dar es en el momento en que vaya a hacer la configuración y te avise de que son incompatibles, pero no impide su compilación ni que funcione luego el sistema mientras desinstales/metas en blacklist a nouveau, lo que hará que el sistema use automáticamente el privativo en el siguiente reinicio sin necesidad de configuración extra alguna.
Y respecto al tema del que trata el artículo, pues ya te contaré si quieres, no creo que tarde mucho en entrar en mi sistema, aun con el retraso del lanzamiento para haber incluido los parches necesarios (mi sistema sigue siendo vulnerable, como la mayoría, a Spectre, no siendolo ya a Meltdown).
# head /sys/devices/system/cpu/vulnerabilities/*
Mitigar? Suena a puta mierda.
#37 Eso decía Linus el otro día
Querrá decir kernel?
#1 Linux es el Kernel
#1 En este caso no hace falta aclararlo pero para el que no conozca bien, el nombre del kernel es Linux. Llamamos genércamente Linux a las distribuciones que contienen el kernel Linux (y los puristas se quejan mucho por ello) pero estrictamente hablando es el nombre del kernel.
#9 Puristas no, los fans del líder de un proyecto fracasado que lleva más de 30 años intentando desarrollar un sistema operativo compatible POSIX pero independiente de UNIX y que para mitigar su sensación de fracaso, y contradiciendo sus propias licencias y filosofía, intenta apropiarse de un proyecto ajeno consistente en desarrollar un sistema estilo UNIX.
#9, los más puristas no, Linus Torvalds mismo no es partidario del uso del termino GNU/Linux (aunque tampoco lucha contra ello)
#15 Bueno, los más puristas no. Los más pedantes.