| 1 |
On Thu, 5 Jan 2012 16:07:04 +0700 |
| 2 |
Pandu Poluan <pandu@××××××.info> wrote: |
| 3 |
|
| 4 |
> (As a side note, initramfs introduces not one, but *MANY* additional |
| 5 |
> breaking points: the tool used to generate the initramfs might be |
| 6 |
> buggy and/or feature-incomplete, the initramfs itself might encounter |
| 7 |
> an unrecoverable error, the pivot_root or chroot might snag upon some |
| 8 |
> not-so-edge cases, etc.) |
| 9 |
|
| 10 |
I completely agree. But if we take one more step backwards for a wider |
| 11 |
view we see something even more bizarre: |
| 12 |
|
| 13 |
|
| 14 |
I switch on a modern computer and it: |
| 15 |
|
| 16 |
- loads a feature rich OS (UEFI) from a fixed point in firmware which |
| 17 |
then |
| 18 |
|
| 19 |
- loads a feature rich OS (grub2) from a fixed point on a storage |
| 20 |
device which then |
| 21 |
|
| 22 |
- loads a feature rich OS (initrd) from a variable location on a |
| 23 |
storage device which then |
| 24 |
|
| 25 |
- loads the real OS (the thing I actually wanted). |
| 26 |
|
| 27 |
So, let's see now. I need 4 OSes to get one. Wow. If a design engineer |
| 28 |
pulled that stunt in almost any other field of technology, he'd be |
| 29 |
laughed out of Dodge in a heartbeat. |
| 30 |
|
| 31 |
Methinks someone (many someones) completely lost the plot a long time |
| 32 |
ago. |
| 33 |
|
| 34 |
|
| 35 |
-- |
| 36 |
Alan McKinnnon |
| 37 |
alan.mckinnon@×××××.com |
Archives