Portada
mis comunidades
otras secciones
#9:
#_8
No está entre el UEFI y el sistema operativo. Forma parte de lo que actualmente es el UEFI.
El diagrama lo deja bien claro. LinuxBOOT sustituye el payload del UEFI/Coreboot/u-boot. LinuxBOOT reside en la misma memoria SPI Flash del UEFI/Coreboot/U-boot. Sólo que el payload es distinto: LinuxBOOT en vez de UEFI DXE.
https://blog.hansenpartnership.com/anatomy-of-the-uefi-boot-sequence-on-the-intel-galileo/
UEFI boot officially has three phases (SEC, PEI and DXE). However, the DXE phase is divided into DXEBoot and DXERuntime (the former is eliminated after the call to ExitBootSerivices()). The jobs of each phase are
SEC (SECurity phase). This contains all the CPU initialisation code from the cold boot entry point on. It’s job is to set the system up far enough to find, validate, install and run the PEI.
PEI (Pre-Efi Initialization phase). This configures the entire platform and then loads and boots the DXE.
DXE (Driver eXecution Environment). This is where the UEFI system loads drivers for configured devices, if necessary; mounts drives and finds and executes the boot code. After control is transferred to the boot OS, the DXERuntime stays resident to handle any OS to UEFI calls.
Después de esto se lee el primer sector de disco como siempre se ha hecho, pasando el control al cargador del sistema operativo.
cc #6
No está entre el UEFI y el sistema operativo. Forma parte de lo que actualmente es el UEFI.
El diagrama lo deja bien claro. LinuxBOOT sustituye el payload del UEFI/Coreboot/u-boot. LinuxBOOT reside en la misma memoria SPI Flash del UEFI/Coreboot/U-boot. Sólo que el payload es distinto: LinuxBOOT en vez de UEFI DXE.
https://blog.hansenpartnership.com/anatomy-of-the-uefi-boot-sequence-on-the-intel-galileo/
UEFI boot officially has three phases (SEC, PEI and DXE). However, the DXE phase is divided into DXEBoot and DXERuntime (the former is eliminated after the call to ExitBootSerivices()). The jobs of each phase are
SEC (SECurity phase). This contains all the CPU initialisation code from the cold boot entry point on. It’s job is to set the system up far enough to find, validate, install and run the PEI.
PEI (Pre-Efi Initialization phase). This configures the entire platform and then loads and boots the DXE.
DXE (Driver eXecution Environment). This is where the UEFI system loads drivers for configured devices, if necessary; mounts drives and finds and executes the boot code. After control is transferred to the boot OS, the DXERuntime stays resident to handle any OS to UEFI calls.
Después de esto se lee el primer sector de disco como siempre se ha hecho, pasando el control al cargador del sistema operativo.
cc #6
#1:
Gran nueva iniciativa de la comunidad del Software Libre. Código fuente incluido.
#7:
A ver cómo lo digo sin que resulte muy malsonante...
UEFI ES UNA MIERDA DE DIMENSIONES CÓSMICAS.
UEFI ES UNA MIERDA DE DIMENSIONES CÓSMICAS.
#36:
#17 UEFI es una especificación en principio más moderna y segura, las implementaciones están escritas en un lenguaje a más alto nivel (al contrario que el ensamblador puro y duro de las bios, con lo cual en principio es más fácil de mantener y depurar). Está pensado para una era postPC (pensando en que un PC es un "compatible IBM-PC", o sea, algo que no necesite tener un nivel de compatibilidad hacia atrás tan acusado o directamente ninguna compatibilidad); de hecho, quien primero empezó a usar un subconjuto de esta especificación fueron los MacIntel, que son PCs pero no son PCs. Luego podemos discutir si algunas de sus características son mejores o peores (el firmado de del arranque y demás, que como todas las ideas que en principio podrían parecer sensatas (que sólo se arranque desde arranques confiables y que si hay una modificación por parte de un elemento extraño, digamos un virus- al no reconocer la firma no deje arrancar, que luego derivó en un "si la firma no pone MS entonces no te arranco" y tener la propia MS que repartir firmas a fabricantes o a distribuidores de software empresarial para poder arrancar sistemas no windows). También tiene cosas cuestionables como arrancar una pila de red completa (que puede tener sentido para actualizar UEFI sin necesidad de entrar en el SO o tener que usar pendrives, pero a la vez resulta un problema de seguridad bastante claro y supone un consumo de recursos sin sentido.
Sobre el arranque en linux también depende de qué tipo de boot uses . En principio las distintas etapas de arranque de linux van tras la bios o UEFI de turno (siendo la bios/UEFI la encargada de arrancar la máquina y luego ceder el control al SO). El número de etapas que se usa suele ser dos, una que monta un minisistema con los drivers de los distintos filesystems necesarios para cargar la imagen de sistema (lo que nos permite arrancar linux en filesystems tan dispares como ext4, brtfs, zfs, xfs, ntfs, etc) y luego el arranque del propio sistema. Pero hay sistemas de arranque que aprovechan algunas ventajas de UEFI para eliminar una de estas etapas o gestores de arranque que tienen más etapas aún (cada uno con sus ventajas e inconvenientes) o directamente usan UEFI (que puede programarse en cierto modo para que en los arranques se comporte de un modo u otro... otra cosa cuestionable de una UEFI, tiene elementos escribibles y por lo tanto, manipulables y en caso de bugs, puede ser causante de intrusiones -las uefi funcionan con muchos privilegios o incluso de rootkits indetectables).
Luego vienen las herramientas que sustituyen lo que es la bios por una bios alternativa y abierta, que serían los coreboot/libreboot y compañía. Y luego vienen las herramientas que sustituyen lo que es UEFI como es linuxboot.
SystemD no es en ningún caso parte del arranque como tal, aunque tenga parte de lo que es el setup de toda la parte de usuario del sistema. Es un gestor de inicio (o sea, gestiona los procesos del sistema, el inicio, parada y estado de servicios, etc) y como tal es un elemento intermedio entre el kernel y el usuario (monta los sistemas de ficheros y datos de usuario, arranca los servicios necesarios para tener red, entorno gráfico, servicios web, de ficheros, backups, en fin, todo lo que esté configurado para arrancar y todo lo que el usuario quiera gestionar luego). Lo mismo que hacían los scripts de arranque del SysV Init.
Los iniciadores gráficos (gdm, lightdm, kdm, etc) simplemente gestionan las sesiones de usuario (cada usuario puede tener un entorno gráfico distinto o siendo el mismo toda una configuración completamente distinta, desde un entorno completamente asistido para una persona con algún problema o discapacidad hasta un entorno de ventanas tabulado o un paradigma de control de escritorio basado en realidad virtual, sea usando el protocolo X11 o sea usando Wayland.
Cada etapa desde que enciendes el ordenador hasta que el usuario tiene el control en su escritorio preferido tiene un sentido y está especializada en una cosa concreta, aunque a veces alguna parte se encargue de hacer más de una.
Cada vez es más rápido el arranque porque cada vez se paralelizan más ciertas tareas (antes era todo secuencial) y se optimiza el uso de los recursos y (evidentemente) el hardware cada vez hace menos de cuello de botella (discos más rápidos, memorias más seguras que se autotestean y no hace falta estarlas testeando a mano, hardware más autónomo, etc).
Sobre el arranque en linux también depende de qué tipo de boot uses . En principio las distintas etapas de arranque de linux van tras la bios o UEFI de turno (siendo la bios/UEFI la encargada de arrancar la máquina y luego ceder el control al SO). El número de etapas que se usa suele ser dos, una que monta un minisistema con los drivers de los distintos filesystems necesarios para cargar la imagen de sistema (lo que nos permite arrancar linux en filesystems tan dispares como ext4, brtfs, zfs, xfs, ntfs, etc) y luego el arranque del propio sistema. Pero hay sistemas de arranque que aprovechan algunas ventajas de UEFI para eliminar una de estas etapas o gestores de arranque que tienen más etapas aún (cada uno con sus ventajas e inconvenientes) o directamente usan UEFI (que puede programarse en cierto modo para que en los arranques se comporte de un modo u otro... otra cosa cuestionable de una UEFI, tiene elementos escribibles y por lo tanto, manipulables y en caso de bugs, puede ser causante de intrusiones -las uefi funcionan con muchos privilegios o incluso de rootkits indetectables).
Luego vienen las herramientas que sustituyen lo que es la bios por una bios alternativa y abierta, que serían los coreboot/libreboot y compañía. Y luego vienen las herramientas que sustituyen lo que es UEFI como es linuxboot.
SystemD no es en ningún caso parte del arranque como tal, aunque tenga parte de lo que es el setup de toda la parte de usuario del sistema. Es un gestor de inicio (o sea, gestiona los procesos del sistema, el inicio, parada y estado de servicios, etc) y como tal es un elemento intermedio entre el kernel y el usuario (monta los sistemas de ficheros y datos de usuario, arranca los servicios necesarios para tener red, entorno gráfico, servicios web, de ficheros, backups, en fin, todo lo que esté configurado para arrancar y todo lo que el usuario quiera gestionar luego). Lo mismo que hacían los scripts de arranque del SysV Init.
Los iniciadores gráficos (gdm, lightdm, kdm, etc) simplemente gestionan las sesiones de usuario (cada usuario puede tener un entorno gráfico distinto o siendo el mismo toda una configuración completamente distinta, desde un entorno completamente asistido para una persona con algún problema o discapacidad hasta un entorno de ventanas tabulado o un paradigma de control de escritorio basado en realidad virtual, sea usando el protocolo X11 o sea usando Wayland.
Cada etapa desde que enciendes el ordenador hasta que el usuario tiene el control en su escritorio preferido tiene un sentido y está especializada en una cosa concreta, aunque a veces alguna parte se encargue de hacer más de una.
Cada vez es más rápido el arranque porque cada vez se paralelizan más ciertas tareas (antes era todo secuencial) y se optimiza el uso de los recursos y (evidentemente) el hardware cada vez hace menos de cuello de botella (discos más rápidos, memorias más seguras que se autotestean y no hace falta estarlas testeando a mano, hardware más autónomo, etc).
Comentarios
Gran nueva iniciativa de la comunidad del Software Libre. Código fuente incluido.
A ver cómo lo digo sin que resulte muy malsonante...
UEFI ES UNA MIERDA DE DIMENSIONES CÓSMICAS.
#7 Y ahora a ver si eres capaz de justificarlo
#11 Digamos que supera por poco el desastre que es el estándar ACPI de control de energía, que casi nadie soporta muy bien porque es inmensamente complejo y funciona porque los fabricantes ponen parche sobre parche. El caso es que las especificaciones y el diseño dejan mucho que desear y por lo tanto, las implementaciones también.
#13 Creo que no tienes ni idea.
ACPI es bastante simple: https://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html
"El problema" que hay será con algunos componentes hardware que no están bien diseñados. Pero esto es como culpar al premio novel de física de que a mi hijo en el colegio no le enseñan mecánica cuántica.
Por otro lado ACPI es solo una pequeña parte. Es como decir que un tesla es un coche de mierda porque las pinzas de freno son rojas.
#14 "El problema" (como tú dices) es que cada fabricante se pasa los "estándares" por el arco del triunfo e implementa como les sale de los cojines y con código CERRADO, casi imposible de auditar y mucho menos reparar. Baste el ejemplo citado por #13 donde algo tan "simple" como es la gestión de energía funciona correctamente en unos equipos y en otros NO.
UEFI no ha solucionado nada, y sólo ha añadido una capa de complejidad más al proceso de configuración y arranque de un sistema operativo en una máquina.
Y además da la posibilidad al OEM del equipo de decidir en TÚ MÁQUINA que sistema operativo puedes correr o no.
Y por favor, no me digas que TPM se puede deshabilitar porque sólo faltaba...
#15 Que UEFI no ha salucionado nada... no, solo ha unificado gran parte del esfuerzo de inicializacion de la maquina, que antes era una casa de putas. Me da que la gente habla sin saber mucho, sin haber mirado lo que es UEFI y por que es como es, por no hablar de que no habran programado ni lo mas minimo sobre ello.
#9 #13 #16 Por favor, este tema me intera ¿Podrias dar más información entendible a nivel usuario? (Hasta la polla de política, grafeno, baterias o el impuesto al sol....).
El regustillo que me quedo de uefi es que era como una "bios mas moderna y segura" (mensaje marketiniano) pero controlada por MS. Y que eso suponia que a efectos era más dificil instalarte otra cosa que no fuera windws. incluso que los creadores de SO tendrian que pagar algo para poder arrancar en hardware que la llevase.
Por otro lado, sobre el arranque de Linux, yo ya me pierdo...¿Cuantos niveles hay ya? Esta la bios/uefi, los coreboot, y demas historias que comentais, luego esta el lilo/grub, despues el kernel, despues el systmV/systemd, los inicializadores (gráficos (statx/kdes/gnomes, etc) y otros... ¿Supuestamente cada vez es mas rápido el arranque? Pues no me lo explico, sera porque metes un i9 overcloqueado.
#17 UEFI es una especificación en principio más moderna y segura, las implementaciones están escritas en un lenguaje a más alto nivel (al contrario que el ensamblador puro y duro de las bios, con lo cual en principio es más fácil de mantener y depurar). Está pensado para una era postPC (pensando en que un PC es un "compatible IBM-PC", o sea, algo que no necesite tener un nivel de compatibilidad hacia atrás tan acusado o directamente ninguna compatibilidad); de hecho, quien primero empezó a usar un subconjuto de esta especificación fueron los MacIntel, que son PCs pero no son PCs. Luego podemos discutir si algunas de sus características son mejores o peores (el firmado de del arranque y demás, que como todas las ideas que en principio podrían parecer sensatas (que sólo se arranque desde arranques confiables y que si hay una modificación por parte de un elemento extraño, digamos un virus- al no reconocer la firma no deje arrancar, que luego derivó en un "si la firma no pone MS entonces no te arranco" y tener la propia MS que repartir firmas a fabricantes o a distribuidores de software empresarial para poder arrancar sistemas no windows). También tiene cosas cuestionables como arrancar una pila de red completa (que puede tener sentido para actualizar UEFI sin necesidad de entrar en el SO o tener que usar pendrives, pero a la vez resulta un problema de seguridad bastante claro y supone un consumo de recursos sin sentido.
Sobre el arranque en linux también depende de qué tipo de boot uses . En principio las distintas etapas de arranque de linux van tras la bios o UEFI de turno (siendo la bios/UEFI la encargada de arrancar la máquina y luego ceder el control al SO). El número de etapas que se usa suele ser dos, una que monta un minisistema con los drivers de los distintos filesystems necesarios para cargar la imagen de sistema (lo que nos permite arrancar linux en filesystems tan dispares como ext4, brtfs, zfs, xfs, ntfs, etc) y luego el arranque del propio sistema. Pero hay sistemas de arranque que aprovechan algunas ventajas de UEFI para eliminar una de estas etapas o gestores de arranque que tienen más etapas aún (cada uno con sus ventajas e inconvenientes) o directamente usan UEFI (que puede programarse en cierto modo para que en los arranques se comporte de un modo u otro... otra cosa cuestionable de una UEFI, tiene elementos escribibles y por lo tanto, manipulables y en caso de bugs, puede ser causante de intrusiones -las uefi funcionan con muchos privilegios o incluso de rootkits indetectables).
Luego vienen las herramientas que sustituyen lo que es la bios por una bios alternativa y abierta, que serían los coreboot/libreboot y compañía. Y luego vienen las herramientas que sustituyen lo que es UEFI como es linuxboot.
SystemD no es en ningún caso parte del arranque como tal, aunque tenga parte de lo que es el setup de toda la parte de usuario del sistema. Es un gestor de inicio (o sea, gestiona los procesos del sistema, el inicio, parada y estado de servicios, etc) y como tal es un elemento intermedio entre el kernel y el usuario (monta los sistemas de ficheros y datos de usuario, arranca los servicios necesarios para tener red, entorno gráfico, servicios web, de ficheros, backups, en fin, todo lo que esté configurado para arrancar y todo lo que el usuario quiera gestionar luego). Lo mismo que hacían los scripts de arranque del SysV Init.
Los iniciadores gráficos (gdm, lightdm, kdm, etc) simplemente gestionan las sesiones de usuario (cada usuario puede tener un entorno gráfico distinto o siendo el mismo toda una configuración completamente distinta, desde un entorno completamente asistido para una persona con algún problema o discapacidad hasta un entorno de ventanas tabulado o un paradigma de control de escritorio basado en realidad virtual, sea usando el protocolo X11 o sea usando Wayland.
Cada etapa desde que enciendes el ordenador hasta que el usuario tiene el control en su escritorio preferido tiene un sentido y está especializada en una cosa concreta, aunque a veces alguna parte se encargue de hacer más de una.
Cada vez es más rápido el arranque porque cada vez se paralelizan más ciertas tareas (antes era todo secuencial) y se optimiza el uso de los recursos y (evidentemente) el hardware cada vez hace menos de cuello de botella (discos más rápidos, memorias más seguras que se autotestean y no hace falta estarlas testeando a mano, hardware más autónomo, etc).
#15 "UEFI no ha solucionado nada,"
Venga, hombre. Si no sabes no hables.
#15 Todas esas dificultades que pone UEFI a quien quiere instalar otro sistema operativo se las pone también a un atacante que quiera actualizar microcódigo del controlador o cargar algo antes de que arranque el kernel del sistema operativo.
#11 Este mismo artículo dice unas cuantas cosas sobre la dudosa seguridad de uefi.
Por otro lado, yo siempre he tenido problemas instalando en equipos con uefi. Al final siempre lo logro pero es cosa de probar hasta dar con la combinación correcta porque de entrada rara vez funciona.
#19 con linux, no?
#22 Si utilizas el windows que ya viene preinstalado en los equipos obviamente no hay problema. Pero he visto problemas al tatar de cambiar por otro windows. O en equipos a los que les habían cambiado el windows por otro (windows 7) y después no había forma de que arrancaran con windows 10.
Otro problema muy usual con windows es que falle el disco duro. Quieres cambiarlo y resulta que el instalador no crea correctamente la partición EFI. Una vez tuve que pinchar el disco por USB en un linux para fabricarle a mano la partición EFI.
#26 Pues los casos que has visto tú, no son problema de UEFI sino de quien ha creado las particiones.
#27 Pero en un bios sin UEFI no habrían ocurrido esos problemas. UEFI sólo ha servido para agregar complicaciones pero no ha aportado ninguna ventaja.
#29 Que no tío, que no. Infórmate un poquito.
Privativo, no propietario.
#3 Tienes razón, error mío al traducir.
Aunque creo que se entiende bien.
Ron Minnich es uno de los principales desarrolladores de Coreboot y autor de este nuevo proyecto. También ha trabajado con el sistema operativo Plan9.
#10 Supone que en lugar de usar rutinas de inicialización de componentes hechas una vez y (quizá actualizadas alguna otra) hechas para siempre, cerradas, inseguras (después de x años, ningún fabricante actualiza ya), etc. como paso previo a que el SO tome el control y probablemente use sus propios sistemas de control para esos recursos, hacer que el SO directamente tome esos recursos desde el principio. O al menos una versión específica y recortada de linux sólo para eso, con las ventajas que ello supone (código testeado, estable y auditable, parches, nuevas características,...).
¡Qué lío!
¿coreboot y LinuxBios no son el mismo proyecto? Y creo que LibreBoot es un fork de coreboot sin binarios. Eso reemplaza la Bios.
¿Y esto es un proyecto paralelo para reemplazar el UEFI?
#4
Sí. Ya van 3 o 4 proyectos para lo mismo.
#_8
No está entre el UEFI y el sistema operativo. Forma parte de lo que actualmente es el UEFI.
El diagrama lo deja bien claro. LinuxBOOT sustituye el payload del UEFI/Coreboot/u-boot. LinuxBOOT reside en la misma memoria SPI Flash del UEFI/Coreboot/U-boot. Sólo que el payload es distinto: LinuxBOOT en vez de UEFI DXE.
https://blog.hansenpartnership.com/anatomy-of-the-uefi-boot-sequence-on-the-intel-galileo/
UEFI boot officially has three phases (SEC, PEI and DXE). However, the DXE phase is divided into DXEBoot and DXERuntime (the former is eliminated after the call to ExitBootSerivices()). The jobs of each phase are
SEC (SECurity phase). This contains all the CPU initialisation code from the cold boot entry point on. It’s job is to set the system up far enough to find, validate, install and run the PEI.
PEI (Pre-Efi Initialization phase). This configures the entire platform and then loads and boots the DXE.
DXE (Driver eXecution Environment). This is where the UEFI system loads drivers for configured devices, if necessary; mounts drives and finds and executes the boot code. After control is transferred to the boot OS, the DXERuntime stays resident to handle any OS to UEFI calls.
Después de esto se lee el primer sector de disco como siempre se ha hecho, pasando el control al cargador del sistema operativo.
cc #6
#6 https://imgs.xkcd.com/comics/standards.png
#4 Según la web del proyecto está entre la uefi y el sistema operativo. La función es la de usar la estabilidad y el desarrollo de los drivers de hardware en linux y no usar los propios que trae uefi que son muy inestables y casi no han sido probados. Supongo que esos drivers lo utilizan para configurar la BIOS o como se llame ahora con uefi.
Según el gráfico sería arrancar uefi o coreboot y le dan paso a linuxBoot y luego arranca el sistema operativo. LinuxBoot es también más rápido en el arranque.
#8 ¿Pero un paso mas para el arranque no supone que el sistema tardsa mas en estar operativo?
#10 En realidad son los mismos pasos. Al que se le añade un paso previo de seguridad.
Donde se notará mucho el tiempo es en la parte de servidor. Las máquinas Unix hace mucho que tiene firmwares equivalentes a UEFI. Más complejos incluso. Por ejemplo depende de como estén conectadas las systemboards con el mismo hardware puedes tener un chasis con más procesadores o memoria, o menos, los cajones con las tarjetas de Red y otro hardware están asignados a una systemboard u otrá, etc... Y eso hace tiempo decidieron que eso se tenía que hacer por software en lugar de tener que entrar al datacenter a quitar una tarjeta de red a un servidor y ponérselo a otro, sin rebotar las máquinas. Eso si, los firmwares de máquinas Unix tienen las mismas pegas que las UEFI propietarias. Están protegidas por secretos industriales, con lo que la falta de escrutinio hace que el suministrador te la pueda meter doblada y los bugs se corrijan tarde o nunca.
Obviamente son más pasos que para arrancar desde BIOS, porque UEFI es infinitamente más compleja.
BIOS hacia un chequeo de Hardware muy elemental y comenzaba el arranque del sistema operativo leyendo el primer sector del disco que le dijeras.
BIOS era completamente cerrado y todavía hay partes que los que trabajan en proyectos libres aún no saben que hacen.
Habia solo dos o tres suministradores de BIOS, actualizarla era un engorro porque solías necesitar utilizar una disquetera (la mayoría de BIOS no sabían leer pendrives o discos Sata sin alguna actualización) y a demás los fabricantes de BIOS solían tener cogidos pornos huevos a los fabricantes de placas.
Sin tener en cuenta que aunque es un mecanismo sencillo como un sonajero (visto por fuera) por dentro no lo es y dependía completamente del chip de BIOS.
Cualquier atacante con acceso físico a la máquina podía instalar alguna actualización de hardware o de microcódigo. Si la BIOS tiene password pues le quita la pila y respetes lonque esta guardado en la CMOS y listo.
Este va a ser el año de Linux en el … Boot
¿Y las páginas de venta avisarán de que el pc de turno tiene LinuxBoot / UEFI? Porque con el tiempo quiero ir renovando el PC actual (de 2010) y me gustaría ya pillarlo con LinuxBoot. Me refiero a la sección de características/specs, que digo yo que sería lo suyo notificarlo, pero a lo mejor no lo consideran un dato relevante.
Creo que tú eres el que no has entendido. Esa es una versión concreta de la especificación, que habrán implementado X fabricantes en X hardware. Te olvidas de las especificaciones anteriores (que a cada cual peor).
Por otro lado, deberías enlazar esto, que si son las especificaciones y no en enlace que has puesto:
http://www.acpi.info/DOWNLOADS/ACPIspec50.pdf
1000 paginitas con perlitas del tipo:
"This section describes the format of the Multiple APIC Description Table (MADT), which provides OSPM with information necessary for operation on systems with APIC, SAPIC or GIC implementations. ACPI represents all interrupts as "flat" values known as global system interrupts.
Therefore to support APICs, SAPICs or GICs on an ACPI-enabled system, each used interrupt input must be mapped to the global system interrupt value used by ACPI. See Section 5.2.13. Global System Interrupts,” for a description of Global System Interrupts.
Additional support is required to handle various multi-processor functions that implementations might support (for example, identifying each processor's local interrupt controller ID). All addresses in the MADT are processor-relative physical addresses"
Como ves, no es algo tan trivial.
Ya sólo falta hardware libre que se pueda fabricar en casa
Estoy suficientemente informado como para decir que no ha aportado nada realmente útil. Que sí, que mucha propaganda sobre las maravillas de tener un bootloader gigante que hace un montón de cosas hermosas, pero lo que necesitamos de verdad es que arranque lo que haya en el disco y listo, y eso se puede hacer perfectamente con el viejo bios de siempre.
Con menos egos, y mas coordinacion los SOs basados en Unix dominarian el mundo del servidor y del escritorio. Pero asi estamos, salen versiones como churros.
#20 el sistema del que habla la noticia no es ni de escritorio ni de servidor. Ya sé que has leído el artículo, pero por hacer énfasis.
#20 Los SOs basados en Unix hace décadas que dominan el mundo del servidor