Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LinuxBoot: Linux as Firmware

linuxboot.org

Post reply on HN
Print view View original

121–130 of 187 posts

Re: LinuxBoot: Linux as Firmware

#121

Post by jiggunjer »

gnufied wrote: post #54
BenjiWiebe wrote: post #52

BTW, on the flip side of the UEFI haters, i.e. things that I can do with UEFI more easily than BIOS (or at all). I can now have a normal partition to put my boot loaders in rather than a hidden chunk at the beginning of the disk. I can easily update, add and remove boot entries from the OS command line. I can forgo bootloaders entirely and use Linux as UEFI application. I can use GPT and finally partition as much as…

On other hand - a common partition that is shared among all operating systems has too high chance of getting corrupted or simply blown away by another install. Just yesterday - RHEL7.5 beta install overwrote UEFI entry of Ubuntu for me and Ubuntu became unbootable. On another laptop - Fedora blew away my Windows bootloader from UEFI partition and I have been too lazy to recover it. Also - because UEFI partition actua…

I always thought it a design flaw in OSes that always keep EFI partitions mounted (and writeable).

I also read horror stories where someone bricks their pc/laptop by corrupting the UEFI (not the EFI partition, the actual firmware).

Re: LinuxBoot: Linux as Firmware

#122

Post by jgowdy »

peterwwillis wrote: post #105
gatmne wrote: post #102

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…

Are you aware that the Linux Foundation employs Linus Torvalds? And that a very vast majority of Linux (and most other) open source development is done by developers who are paid employees of major corporations like Red Hat, IBM, Oracle, etc? Some people seem to have the idea that it’s developed by hippie volunteers living in a commune, but the fact is, open source development is done by interested parties who are typically employees of corporations who stand to benefit from their work. And that’s okay.

As a donor to the Linux Foundation, I don’t find it creepy. Same goes for the Cloud Native Computing Foundation.

Re: LinuxBoot: Linux as Firmware

#123

Post by snvzz »

pcwalton wrote: post #120
snvzz wrote: post #118

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,…

On servers, you're already booting a Linux kernel. IMO, it's simpler to boot an older version of Linux that ultimately shares almost all the relevant code with your production version of Linux than to have two entirely separate codebases. 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 r…

>For example, if you fix a bug in an upstream Linux driver needed at boot time

Or, for example, if there's a bug in a Linux driver, neither linux nor the bootloader (which is also linux) will work.

>With the traditional UEFI setup, you have two separate codebases, each with their own sets of bugs.

Except Linux is a multi-megabyte-clusterfuck, and the bootloader likely is simple and easy to understand/debug, and will keep working as long as the hardware it needs to boot remains the same, which is usually the case.

Re: LinuxBoot: Linux as Firmware

#124

Post by ComputerGuru »

steeve wrote: post #111
ComputerGuru wrote: post #94

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.

This is probably because people saw the LinuxCon video and are excited that it's out. At least that's my case :)

Thanks, that explains a lot!

Re: LinuxBoot: Linux as Firmware

#125

Post by orionblastar »

I remember my Commodore 64 days where you turned on the C64 and it booted right into BASIC because it loaded BASIC from a ROM, or it loaded software from a cartridge. The 1541 floppy drive was extra, or the tape or modem etc.

The thing I liked most about the C64 was booting into BASIC as soon as you turned it on.

If Linux becomes the Firmware or installed on Firmware on an EEPROM or whatever, it can boot into a LiveCD Distro of Linux from an EEPROM faster than from a hard drive or USB drive or DVD whatever.

I have to say some computers are getting rid of DVD/CD/BluRay drives and booting from USB Drives, which makes download a Linux Live CD/DVD and test it out, now it can just boot from BIOS with the bare minimum LiveCD distro, and allow you to have tools to work on hard drives and fix them etc.

If I ran Commodore, and brought it back from the dead, I'd make Intel/AMD PCs, and I'd also make Commodore Bridge Cards that run a 68M/PPC Amiga on a PCIe/PCI card that can run in the host OS as a Window or Full Screen and can make virtual hard drives and floppies out of files, etc. Maybe a C64/C128/C65 on a card with ports from the Commodore series to hook up real 1541 drives etc. The Commodore Colt PCs will have a VIC-20 series that is low end, and a Mad Max series that is high end and built for video games and SteamOS or run Windows. They will come with Debian Linux but can be reformatted for Windows or SteamOS and make a deal with Steam to run C64 games in emulators the same way Sega Genesis games are run in emulators.

I'd also try to make ARM-based PCs running Linux for under $100 based loosely on the Raspberry PI but assembled. Contribute to the Raspian or whatever it uses with an emulator app for 8-bit Commodores and they can buy ROMs from a store in the emulators to download and run, after getting permission from the software companies if they still exist to license them and pay 10% or whatever the fee is to the customer.

Re: LinuxBoot: Linux as Firmware

#126

Post by zokula »

snvzz wrote: post #118

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,…

> NetBSD's kernel size (and its cleaner design,

Don't make me laugh.

Re: LinuxBoot: Linux as Firmware

#127

Post by djsumdog »

I don't understand what's wrong with Grub. UEFI loads Grub which loads your OS. The previous "OS" gets replaced in each iteration (except for the Intel ME stuff .. which is off running somewhere in its own little world).

Grub supports raid, lvm2 and luks. I literally have a 1 partition with LUKS that contains an LVM with a swap and root (/) volume. Yes, that means I have an encrypted boot. The only thing unencrypted is my EFI/SPI partition.

Re: LinuxBoot: Linux as Firmware

#128

Post by jchw »

djsumdog wrote: post #127

I don't understand what's wrong with Grub. UEFI loads Grub which loads your OS. The previous "OS" gets replaced in each iteration (except for the Intel ME stuff .. which is off running somewhere in its own little world). Grub supports raid, lvm2 and luks. I literally have a 1 partition with LUKS that contains an LVM with a swap and root (/) volume. Yes, that means I have an encrypted boot. The only thing unencrypted…

UEFI has more privileges than your OS, just like ME has more privileges than UEFI. How do we know it hasn't messed with the environment in ways we can't see? How do we know our UEFI firmware wasn't compromised? I'd argue it's very hard to tell.

Re: LinuxBoot: Linux as Firmware

#129

Post by jchw »

zokula wrote: post #126
snvzz wrote: post #118

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,…

> NetBSD's kernel size (and its cleaner design, Don't make me laugh.

Most of us have not read the NetBSD kernel source code (I have not.) I've read a small bit of the Linux source code. Please inform me of why I should laugh at this claim.

Re: LinuxBoot: Linux as Firmware

#130

Post by ploxiln »

snvzz wrote: post #123
pcwalton wrote: post #120

Earlier quoted context omitted.

On servers, you're already booting a Linux kernel. IMO, it's simpler to boot an older version of Linux that ultimately shares almost all the relevant code with your production version of Linux than to have two entirely separate codebases. 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 r…

>For example, if you fix a bug in an upstream Linux driver needed at boot time Or, for example, if there's a bug in a Linux driver, neither linux nor the bootloader (which is also linux) will work. >With the traditional UEFI setup, you have two separate codebases, each with their own sets of bugs. Except Linux is a multi-megabyte-clusterfuck, and the bootloader likely is simple and easy to understand/debug, and will…

This "LinuxBoot" is trying to replace most (or all) of UEFI on systems it can support, not just grub. UEFI is also multi-megabyte, and arguably more of a "clusterfuck", forked from intel's UEFI upstream some years ago and sloppily adapted by motherboard vendors.
Post reply on HN