111–120 of 187 posts
There is virtually no information on that page. I don't understand why this is getting voted so highly. I'm interested (this falls right in my area of expertise, see my other comments on this page) and I've heard about this proposal before, but the landing page this story links to is just a placeholder with no useful (technical or marketing) information.
At least that's my case :)
IMO, the problems that [U]EFI introduces (that far exceed the historical limitations it overcomes) should be self-evident . IMO, he should not have to argue against having multiple, redundant copies of drivers, shells and utilties each accessible only in its own "OS" (UEFI, GRUB, OS). It should not be a debate. This is definitely not "defense in depth". IMO, whomever controls the first OS controls the computer becaus…
Anyones guess what this means but at the least I think it shows users1 have opinions about UEFI. I think it is a good thing if computer owners care about initialization, bootloaders, owner control and freedom of choice. Clearly some do care. Hats off to those folks.
1 Besides only this one: http://yarchive.net/comp/linux/efi.html
Earlier quoted context omitted.
We should clarify that. Our example is an OCP Winterfell node, where boot time went from 8 minutes to 20 seconds.
That's an edge case. Asserting that boot is typically 20 times faster is misleading.
Earlier quoted context omitted.
This is in the hands of the firmware/hardware manufacturers. AFAIK, for instance, the version of Minix that serves as Intel's ME will continue to be operational even if the UEFI is replaced by Linux. The issue is that 'firmware' actually means many different blobs of software in various ROMs spread throughout the system, from disk controllers to GPUs to memory controllers to NIC and so on. You will never be able to v…
That's why it is important to not buy random shiny devices. Open source hardware like for example the Teres-1 [0] are what allows us to stay in control. I can't wait for even more open successors based on RISC-V processors. [0] https://www.olimex.com/Products/DIY-Laptop/
Earlier quoted context omitted.
I don't. Should I? Why?
It's now hosting this project, and seems to have created this page and reformed the project a bit. And have you seen the foundation's website? They have a tiered sponsor page to act as badge of honor for the tech companies with the most money. Their board of directors are 22 of some of the most powerful tech companies in the world. They "host" an amalgam of different tech products (actually working in legal entities…
If we use LinuxBoot to boot Linux (desktop or server), then why don't we boot direct into Linux (desktop or server)?
There's probably an argument to be made for a lean bootloader/kernel that does minimal work - and for a os kernel that's more general. But with network boot (ethernet, WiFi stack, network stack, one or more network transports ((t)ftp, nfs?..) and support for encryption... The line does blur. Might be worth it to have minimal Linux "profile" that support "booting" other Linux via kexec. But then, will you boot nt, fre…
We had that in Linux; it was called LILO (Linux loader), consisting of a 512 byte machine language program run from the boot sector which would load a canned sequence of more sectors, a slightly larger program, which would then load a kernel image from a sector map.
Before that, generations of machines going back to the dawn of computing had minimal bootstrap sequences.
But, on the flipside, idea of more capable boot firmware precedes Linux by probably ten years if not more, like on Sun workstations and whatnot.
Even if I were to find their approach appealing (I don't), Linux's monolithic design with no driver APIs doesn't even seem like a good fit for this; NetBSD's kernel size (and its cleaner design, and the RUMP kernels feature), Minix3 (high assurance, unlike Linux) or even Genode are far better suited.
But, seriously, we need less, simpler, cleaner code, and this "jam Linux into everything" approach seems nothing less than the old "when you have a hammer, everything looks like a nail" problem.
Does anyone else find The Linux Foundation to be creepy as hell?
I guess that explains why they're trying to jam Linux into the firmware.
I do like the coreboot + lightweight payload (such as u-boot or grub) approach, and simply can't see any benefit of jamming a Linux kernel in; Simplicity is itself value. Even if I were to find their approach appealing (I don't), Linux's monolithic design with no driver APIs doesn't even seem like a good fit for this; NetBSD's kernel size (and its cleaner design, and the RUMP kernels feature), Minix3 (high assurance,…
For example, if you fix a bug in an upstream Linux driver needed at boot time, then both your production system and your bootloader will automatically get it (once you rebuild and reflash). With the traditional UEFI setup, you have two separate codebases, each with their own sets of bugs. I don't see how that is simpler.