Why not just put an ethernet controller into it, and use it as a USB network adaptor?
I think that is exactly the point the grandparent was trying to make. If it had an actual ethernet interface you would only have to transfer the packets over the USB interface once, thus you'd reduce the load on the machine. You'd also get better security since the machine would no longer be connected to the network without going through the firewall. You'd avoid hacking the network stack, and the result would be something working on more systems without the need for special drivers. And you'd free up the ethernet port on the machine, so it could also be used in situations where the machine did not have exactly as many ethernet connections as you'd want. Basically adding a real ethernet interface to this gadget would have increased its value by at least a factor of two.
You have a point with that beowulf cluster, there is slightly more to it than a simple joke though. What this incident really proves is, that a race car with a penguin painted on the side does not perform as well as a race car designed by a beowulf cluster of linux machines. (And this is probably not the only one, it was just the first I found).
despite the fact they were going too fast, and obviously not paying attention to signs
Did you notice the police car arriving 13 seconds after the accident? Coincidence? I think not. This guy was probably trying to escape from the police.
What triggers a problem with flaky hardware doesn't have to be a driver change. If it happens rarely, there is no guarantee a developer would find it, even if he had the actual hardware. OTOH, if the circurmstances and the symptoms are known, they could be simulated in a unit test, and the probability could be increased to the point where you are bound to see them in a test run. Also such problems are likely to only show up with certain combinations of hardware. I have for example seen a system where Linux would lock up if sound card and harddisk were in use at the same time, but only if a network interface was present in the system. However it didn't make any difference whether the driver for the network interface was loaded or not. If an additional ATA card was added to the machine, the problem would also show up in Windows. Do you think Creative would have discovered this, had they written the driver themselves? I think not, because they probably never tested the card with this hardware combination. Would the problem have showed up if you tested it with an emulation of the same set of hardware components? Maybe not, but nevertheless it would have been a useful tool when debuging the problem. Simply seeing the difference between emulation and real hardware could provide a hint about the cause. And a problem can often be easier to figure out, if you have a working instance to look at.
Now the next question is who's responsible for running the unit test to make sure the code is really OK after the kernel was refactored. Is it the guy that wrote the code originally, has hardware samples and knows how to run the test, or the kernel maintainer who knows about the change but doesn't have hardware or the time/knowledge to test it?
The unit test really should include sufficient emulation of the hardware to test the driver. If the hardware vendor supplied such a unit test, you could run it after a refactoring without access to the hardware. If the driver which passed the unit tests turns out not to work, somebody with enough knowledge of the hardware should improve the unit tests.
In case the driver does something which is out of spec, the emulation code would have two options, either behave as the real hardware would, or cause the unit test to fail. Actually I have sometimes been thinking how much easier a lot of things would be if every hardware vendor would provide such emulation code. I'd be perfectly happy with getting the emulation code as binary blobs, as long as I can just run them isolated in a user mode process for the purpose of testing interaction. Whether the CPU emulation in such a case would be similar to xen, qemu, vmware, or a complete emulation provided by a CPU vendor might depend on exactly what you wanted to test. Before anybody say vendors would not do this, because then people would use the emulation rather than buying the hardware, I'd like to point out, that obviously the performance of the emulation would suck compared to the real hardware.
As for the licensing question, I don't see any problems in having the hardware emulation code beeing a propertary license as long as we are allowed to copy it and use it for testing of interaction between hardware and drivers. This code is not being linked against the kernel, thus it does not have to be GPL. If a vendor is able to do some good planning, they could even release this code before the hardware enters the market. AMD was able to do this with the 64 bit architecture, and for that reason Linux supported the architecture even before the hardware was finished. (Too bad it took Intel and Microsoft years to catch up, and when they finally did made it sound like Intel invented the whole thing).
A random fluctuation in internal traffic levels seems equally unlikely. Why? Because it has worked for some time, and I doubt the reactor was doing anything unusual at the time.
This is not about the network being highly loaded with lots of packets comming from all sorts of places. This is about a single device for some reason flooding the network. I have seen the results of units flooding a network with broadcast traffic. I don't consider it highly unlikely for one unit to eventually start doing that because of a design flaw. Somebody should take a closer look on the design of that PLC to see if there is a likely explanation. Maybe a physical defect could have caused it to send a broadcast packet and afterwards think it had not been sent yet and send it again and again. Maybe the explanation is something else. There is no way I can say for sure without having seen the PLC.
Network drivers may also be event-driven, but if the interrupt handler is buggy - which would usually mean the handler can be interrupted by itself indefinitely - it's hardly the fault of the network.
If the handler could interrupt itself, it would probably result in a stack overflow and crash the unit. But that is not the most likely bug to introduce. A more likely and almost as bad problem would be if by the time the interrupt handling ended, it would immediately take another pending interrupt. In that case it would never be processing more than one interrupt at the same time, but yet it would spend all of its CPU time handling interrupts. The unit would appear locked up, but would come back to life shortly after the flooding stops. I have seen the later happen with Linux machines (I don't remember which kernel version, I think 2.4.something). I later repeated the experiment with a Windows ME machine, which also locked up, but didn't come back to life when the network cable was disconnected. This situation was quite easy to test, just loop a cheap 100Mbit/s switch back to itself. It would probably take a 1000Mbit/s network to actually cause this with the last generation of CPUs. I don't know if switches and/or network drivers have been improved to avoid the exact scenario I tested.
In my case this was not a problem, but of course in some critical systems, it can be. I see at least two problems. Units not tested against this scenario, and having redundant units communicate to each other over the same ethernet. Of course just having two ethernets does not solve the problem of one of them being able to take down units. Redundant units protect you against physical defects in one unit, not against design flaws.
The reason for allocating so much for each netsegment was to allow for ways to assign IP addresses within the segment without involving a DHCP server or a configuration that had to be set up on each machine. Two of the approaches used to choosing the lower 64 bits of the address are either random or based on the MAC address. But even in that case 64 bit seems like just a bit of overkill.
Can you imagine what a pain it would be to type 512 bit addresses by hand?
You should rarely have the need to type on by hand. Besides there are short hand notation for IPv6 addresses with many zeros in them. If the addresses had been made 512 bit, but until everybody had upgraded from IPv4 to IPv6 there would only be handed out addresses in which the most significant 400 bits were all zero, they wouldn't be that difficult to type.
Hence why Unix updates don't require reboots and instead result in the problems you've mentioned.
The possibility to update without rebooting is great. The problems you mention are very rare. In fact I have only seen that kind of problem once, in the 10 years I have been using Unix systems. And the case where I saw it, it was not even two programs using different versions, but rather one program being started while it was in the middle of being updated causing it to end up with different versions of the different libraries in the package. And even if that had happened every time I upgraded software, it would still be less of a problem than having to reboot every time.
I've always wondered how someone could consider the Unix design a good idea.
Considering how well the Unix way works, I wonder how anybody could consider Windows a good idea. In Windows updates requires a reboot far too often. And in Windows you often get errors about files being busy for no good reason. OTOH with Unix you can upgrade a running program and not even notice. The running instance keeps running, any new instance will use the new version. Only problem is, that this usually works so smoothly, that you don't even notice. I recall once noticing, that I had KDE using libraries that had been deleted a month earlier. (Yes, I had in fact not logged out for a month).
Two different programs can open what they think is the same file, yet get completely different results.
If you get completely different results, there is a design flaw. We are talking about bug fixes here. The old version have a bug, and if the program triggers that it might crash or even worse produce undefined results (which could be to let in an attacker). The new version does not have the bug. As long as you don't produce the condition, which would trigger the bug, the two versions are supposed to behave exactly the same. And if you do trigger the condition, it is obviously an advantage that the new version behaves as intended. Of course it is not good that the old version doesn't, but the only way to avoid that is by never introducing bugs, which we all know is rarely feasible.
You do realise that the address space of IPv6 is completely insane don't you? Something like "1 address for every atom in the universe" kind of scale
Would have been true, if they had made each address 256 bit. But that is not the case. An IPv6 address is only 128 bits. And it is not like they are going to get assigned in small chunks. There is supposed to be assigned a 64 bit range to every single net segment. And IIRC you are supposed to be getting at least 16 bit to address the segments in your own network, which means anybody getting an IPv6 range is going to have 80 bit of addressing. That leaves only 48 bits to address each such network. So if there is going to be more than 281 billion households on the Internet we are going to run out of IPv6 addresses.
Even though that number is large enough to be pretty unrealistic, I still don't get why they didn't take it a step further and really made the addresses 256 or 512 bits. Or at least something which was guaranteed to scale to that size. If they ain't going to give every person in the world that personal/48, it means there are too few addresses, or maybe political reasons to block the usage of IPv6.
I think the real reason the change to IPv6 is going so slow is neither the complexity of the protocol, nor the number of addresses. The real reason is the not so carefully designed transition plan. I have the impression that most core routers and most operating systems already support IPv6. But creating a network of routers with IPv6 support does not necesarilly mean you are creating an IPv6 network, and I think that is why IPv6 has not gained momentum. There are different ideas on how this should have been done, but of course it is easy to point out the problems in retrospect. It is much less obvious which of the many alternative solutions would have worked. It wasn't even obvious beforehand, that the current design would not be an immediate success.
A better approach might have been to first create a system where initially only 2^32 IPv6 addresses where used, such that there would be a 1:1 correspondance between IPv4 and IPv6 addresses. The same packet could change between IPv4 and IPv6 as it was being forwarded. And routers would be required to use IPv6 if they knew the next hop supports it, or if the source or destination IP happened to be outside the range that could be mapped to IPv4. Once such a system had been rolled out to most of the Internet, it would make sense to start creating routes that could not be mapped IPv4. Once that was happening there would be a significant insentive to upgrade the remaining parts of the Internet to IPv6.
Great, this could help phishing attacks... against banks.
Yes,.bank would be too specific. We need something which will help all businesses against phishing attacks. How about a new tld that only businesses are allowed to use? We could call it.biz or something like that.
When I was a kid, we not only had to share one keyboard, we only had the ONE screen and had to each only use one half, or 40x12 apiece.
Hear the spoiled kid talking. No, when I was a kid, there was no computer at home, only at school. Oh and there where 600 pupils in that school, and we had to share just four computers. And we couldn't run the same program on more than one compute at a time, cause we had only one copy of each floppy. You see, I had never seen a computer with a harddrive. I had heard about harddrives, but those are pretty difficult to imagine when you are used to floppies. Even a 5.25 inch floppy seemed like high tech back in the day where tape drives where the norm.
Does this file system also provide a new implementation of the sendfile system call? Since it already does CoW, it should be possible to make sendfile also do CoW as long as both source and destination are on the same file system. If cp would then make use of the sendfile system call, then even cp would give you CoW, that would be really cool.
Personally, I'd be upset if web designers had precise control over font rendering. I've overridden Firefox's default fonts with ones that I prefer, and regularly use ctrl + and ctrl - to adjust font sizes.
I completely agree with that. Originally all text layout decissions were left to the browser, and it probably would have been better if it had stayed that way. Obviously the current situation doesn't work. Browsers do a fairly good job by default, but web designers don't like the result and make hacks to change the look of the page, which happens to only work with few browsers and only if you stick with the default settings. In reallity I find that very often a page made by somebody who wouldn't call themselves designers ends up looking a lot better than what a web designer produces.
The comment that better font designs won't work online is ridiculous though. You can view online content with a nice font, if your browser uses a nice font. It is not the job of a web designer to choose a good font - let alone design one. If they want to produce nice looking fonts for web pages, they should be designing browsers.
If the BIOS is functional enough to load a boot record from disk, there shouldn't be any need to update it. Rather than only providing a BIOS update, the manufacturer should provide a piece of code that can be chained from the boot record to fix those hardware registers that got initialized incorrectly. And another one that can be loaded into memory by the operating system and used instead of calling functions in the BIOS, of course they should use the exact same API as they would for a BIOS upgrade.
I suppose that for a bit more money, you could do an unwritable base image with a reset button, but that only helps if you know about the reset button. Your typical user would simply see it as a dead device.
If the hardware manufacturer won't spend that bit of extra money, they shouldn't allow the firmware to be updated at all. Of course that would mean they'd have to actually finish the firmware before sending the device on the market. Few hardware manufacturers are willing to wait that long. As for users not knowing about how to reset the device, that is obviously a problem. I guess it would help to accompany the device with documentation, but that of course only helps for those users who read it.
There's a warning in x86config when setting monitor refresh rates that warns you that your choice may destroy your monitor.
That shouldn't be true with modern hardware. Five years ago I got a new CRT (replacement for an old one which was kind enough to die shortly before the end of the warranty). The shop had told me, the new one supported the same frequency ranges as the old one, so I just connected it and started up the computer. Once X started, the monitor went black and showed a message stating the input frequency was outside the supported range. And I guess that kind of protection was pretty much standard at monitors at that time. The monitor didn't break, but of course I returned it anyway, cause I was supposed to get a new one at least as good as the old one. (Apparently the sales people didn't know that 75kHz was less than 85kHz.)
Badly written drivers CAN destroy hardware, in rare cases.
No. Badly designed hardware can destroy hardware. If there is any way in which the software can destroy the hardware, it is by definition a latent flaw in the hardware. Yes, a badly designed driver can expose the flaw, but the hardware was already flawed. And yes, sometimes manufactures do produce an entire series of equipment where all of it suffers from the same latent flaw. As long as it is one component destroying itself, it may be reasonable to deal with. It of course gets worse if one piece of hardware has a flaw which causes it to destroy other hardware. (Imagine a flaw in a graphics board that allows a bad driver to drive up the output voltage to the point of breaking the monitor. Luckily that scenario is probably highly unlikely, but I guess high voltage is the most likely thing which isn't trivial for hardware to protect itself against).
but layer 0 knows nothing about layer(s) at level 2.
In general I'd say that is a good thing. Knowledge about more layers is going to make the implementation more complicated, and we'd rather have emulators be simpler than more complicated. A lot of the complexity in emulators is due to the history of the architecture they are emulating. (The PC is a nasty mess of patches rather than a well designed system). But the simpler the emulation can be made, the more reliable I'd expect it to be.
What I'd like to see is not really a system where each layer has knowledge about a lot of layers below, but rather one where the designer has the knowledge. Figure out what the cost of multiple layers of your own virtualization is going to be, and improve on that without assuming that you are necesarilly going to be running under your own virtualization in the end.
Current "hypervisors"...
Current hypervisors are not really designed for running under themselves, in fact the architecture is not even designed with virtualization in mind. There are attempts to improve on this, but I haven't yet had the oppertunity to play with any of those. Of course being able to virtualize yourself is the first step, only then can you start considering performance.
Just you get execution speed and available memory progressively downgraded/shrinked
If you do a full emulation of the instruction set, you are going to get a slowdown which is exponential in the number of layers. OTOH if you want an architecture to emulate itself, it might be possible to virtualize it, such that the actual computations (which should be where you spend most of the CPU time) actually run natively thus no slowdown. However even in that case, there will be some privileged operations, which have to be emulated. I guess they will typically have an exponential slowdown, thus when you start having a few layers, they are going to be so expensive that adding another layer is infeasible. I wonder if it is possible to design an architecture such that it can virtualize itself in a way where no instruction have a cost that is more than linear in the number of layers.
As for memory usage, you are obviously going to need at least a constant amount for each layer, thus there will be a linear overhead in the number of layers. But is it going to be worse? Are page tables going to cause an exponential overhead in memory usage as well? (And is the base going to be large enough for that to matter? 1.001^n isn't that bad a complexity).
The first thing I typed at the prompt was "keyb sf" and it hangs... Great...
That is kind of interesting. At some point I wrote a PC emulator myself (using virtual 86 mode), I found it easier to get KEYB working than to implement the full keyboard handling normally provided by the BIOS. Though I did find that the MS DOS version of KEYB does require all the nasty details of interrupt handling to be working. I don't know if the FreeDOS version of KEYB is better or worse in that respect, I never got FreeDOS booting on my own emulator.
You are writing random bytes to the interrupt controler. What did you expect to happen? Just reload the page to reboot the virtual machine. (I'd have tested it on a different emulation as well, but I don't know how to get the disk images they are using).
I have a new laptop and it seems to take over two minutes (while plugged in) to boot up. Oddly, it takes ~1 minute to boot up when it isn't plugged in. I don't understand how that works
You mean it boots faster when running on battery than otherwise? How often do you boot that machine? Some distributions have startup scripts to ensure that background jobs, which would normally be run overnight, does also get run on machines that are always powered off overnight. The details probably differs between distributions. Some delay these jobs for a few minutes, which should ensure that they don't start to run before the system has finished booting. But if Ubuntu don't delay them, they could influence on the speed at which the system boots. I have seen a distribution, where the jobs would not be started on boot, if the system was running on battery. That could be part of the explanation why you see different boot times depending on whether you are running on battery or not.
How carefully did you meassure the boot times? If you just meassured each case once, the difference could be for a lot of other reasons. If you want to be sure, do the following. Flip a coin to decide whether you are going to plug the power or run from battery, then boot the machine. Repeat this ten (or more) times, meassuring the boot time each time.
And Quicksort technically has a O(n^2) worst case (reversed list)
The worst case depends on how you choose the pivot element. If you choose the first or last element as pivot, the worst case will be something sorted in one direction. But if you choose the midle element as pivot, a sorted list will actually be the best case. What the worst case is for that choice of pivot, is a little more complicated to compute, and not something I'd expect to see except for adversarialy constructed lists. It is even possible to compute the meridian in linear time. Using that you could do quicksort with a worst case of O(n log n). But the overhead for computing the meridian would be so big, that other sorting algorithms would be a better choice.
Slashdot Mirror
You have a point with that beowulf cluster, there is slightly more to it than a simple joke though. What this incident really proves is, that a race car with a penguin painted on the side does not perform as well as a race car designed by a beowulf cluster of linux machines. (And this is probably not the only one, it was just the first I found).
What triggers a problem with flaky hardware doesn't have to be a driver change. If it happens rarely, there is no guarantee a developer would find it, even if he had the actual hardware. OTOH, if the circurmstances and the symptoms are known, they could be simulated in a unit test, and the probability could be increased to the point where you are bound to see them in a test run. Also such problems are likely to only show up with certain combinations of hardware. I have for example seen a system where Linux would lock up if sound card and harddisk were in use at the same time, but only if a network interface was present in the system. However it didn't make any difference whether the driver for the network interface was loaded or not. If an additional ATA card was added to the machine, the problem would also show up in Windows. Do you think Creative would have discovered this, had they written the driver themselves? I think not, because they probably never tested the card with this hardware combination. Would the problem have showed up if you tested it with an emulation of the same set of hardware components? Maybe not, but nevertheless it would have been a useful tool when debuging the problem. Simply seeing the difference between emulation and real hardware could provide a hint about the cause. And a problem can often be easier to figure out, if you have a working instance to look at.
In case the driver does something which is out of spec, the emulation code would have two options, either behave as the real hardware would, or cause the unit test to fail. Actually I have sometimes been thinking how much easier a lot of things would be if every hardware vendor would provide such emulation code. I'd be perfectly happy with getting the emulation code as binary blobs, as long as I can just run them isolated in a user mode process for the purpose of testing interaction. Whether the CPU emulation in such a case would be similar to xen, qemu, vmware, or a complete emulation provided by a CPU vendor might depend on exactly what you wanted to test. Before anybody say vendors would not do this, because then people would use the emulation rather than buying the hardware, I'd like to point out, that obviously the performance of the emulation would suck compared to the real hardware.
As for the licensing question, I don't see any problems in having the hardware emulation code beeing a propertary license as long as we are allowed to copy it and use it for testing of interaction between hardware and drivers. This code is not being linked against the kernel, thus it does not have to be GPL. If a vendor is able to do some good planning, they could even release this code before the hardware enters the market. AMD was able to do this with the 64 bit architecture, and for that reason Linux supported the architecture even before the hardware was finished. (Too bad it took Intel and Microsoft years to catch up, and when they finally did made it sound like Intel invented the whole thing).
If the handler could interrupt itself, it would probably result in a stack overflow and crash the unit. But that is not the most likely bug to introduce. A more likely and almost as bad problem would be if by the time the interrupt handling ended, it would immediately take another pending interrupt. In that case it would never be processing more than one interrupt at the same time, but yet it would spend all of its CPU time handling interrupts. The unit would appear locked up, but would come back to life shortly after the flooding stops. I have seen the later happen with Linux machines (I don't remember which kernel version, I think 2.4.something). I later repeated the experiment with a Windows ME machine, which also locked up, but didn't come back to life when the network cable was disconnected. This situation was quite easy to test, just loop a cheap 100Mbit/s switch back to itself. It would probably take a 1000Mbit/s network to actually cause this with the last generation of CPUs. I don't know if switches and/or network drivers have been improved to avoid the exact scenario I tested.
In my case this was not a problem, but of course in some critical systems, it can be. I see at least two problems. Units not tested against this scenario, and having redundant units communicate to each other over the same ethernet. Of course just having two ethernets does not solve the problem of one of them being able to take down units. Redundant units protect you against physical defects in one unit, not against design flaws.
You should rarely have the need to type on by hand. Besides there are short hand notation for IPv6 addresses with many zeros in them. If the addresses had been made 512 bit, but until everybody had upgraded from IPv4 to IPv6 there would only be handed out addresses in which the most significant 400 bits were all zero, they wouldn't be that difficult to type.
Considering how well the Unix way works, I wonder how anybody could consider Windows a good idea. In Windows updates requires a reboot far too often. And in Windows you often get errors about files being busy for no good reason. OTOH with Unix you can upgrade a running program and not even notice. The running instance keeps running, any new instance will use the new version. Only problem is, that this usually works so smoothly, that you don't even notice. I recall once noticing, that I had KDE using libraries that had been deleted a month earlier. (Yes, I had in fact not logged out for a month).
If you get completely different results, there is a design flaw. We are talking about bug fixes here. The old version have a bug, and if the program triggers that it might crash or even worse produce undefined results (which could be to let in an attacker). The new version does not have the bug. As long as you don't produce the condition, which would trigger the bug, the two versions are supposed to behave exactly the same. And if you do trigger the condition, it is obviously an advantage that the new version behaves as intended. Of course it is not good that the old version doesn't, but the only way to avoid that is by never introducing bugs, which we all know is rarely feasible.
Even though that number is large enough to be pretty unrealistic, I still don't get why they didn't take it a step further and really made the addresses 256 or 512 bits. Or at least something which was guaranteed to scale to that size. If they ain't going to give every person in the world that personal
I think the real reason the change to IPv6 is going so slow is neither the complexity of the protocol, nor the number of addresses. The real reason is the not so carefully designed transition plan. I have the impression that most core routers and most operating systems already support IPv6. But creating a network of routers with IPv6 support does not necesarilly mean you are creating an IPv6 network, and I think that is why IPv6 has not gained momentum. There are different ideas on how this should have been done, but of course it is easy to point out the problems in retrospect. It is much less obvious which of the many alternative solutions would have worked. It wasn't even obvious beforehand, that the current design would not be an immediate success.
A better approach might have been to first create a system where initially only 2^32 IPv6 addresses where used, such that there would be a 1:1 correspondance between IPv4 and IPv6 addresses. The same packet could change between IPv4 and IPv6 as it was being forwarded. And routers would be required to use IPv6 if they knew the next hop supports it, or if the source or destination IP happened to be outside the range that could be mapped to IPv4. Once such a system had been rolled out to most of the Internet, it would make sense to start creating routes that could not be mapped IPv4. Once that was happening there would be a significant insentive to upgrade the remaining parts of the Internet to IPv6.
Does this file system also provide a new implementation of the sendfile system call? Since it already does CoW, it should be possible to make sendfile also do CoW as long as both source and destination are on the same file system. If cp would then make use of the sendfile system call, then even cp would give you CoW, that would be really cool.
The comment that better font designs won't work online is ridiculous though. You can view online content with a nice font, if your browser uses a nice font. It is not the job of a web designer to choose a good font - let alone design one. If they want to produce nice looking fonts for web pages, they should be designing browsers.
If the BIOS is functional enough to load a boot record from disk, there shouldn't be any need to update it. Rather than only providing a BIOS update, the manufacturer should provide a piece of code that can be chained from the boot record to fix those hardware registers that got initialized incorrectly. And another one that can be loaded into memory by the operating system and used instead of calling functions in the BIOS, of course they should use the exact same API as they would for a BIOS upgrade.
No. Badly designed hardware can destroy hardware. If there is any way in which the software can destroy the hardware, it is by definition a latent flaw in the hardware. Yes, a badly designed driver can expose the flaw, but the hardware was already flawed. And yes, sometimes manufactures do produce an entire series of equipment where all of it suffers from the same latent flaw. As long as it is one component destroying itself, it may be reasonable to deal with. It of course gets worse if one piece of hardware has a flaw which causes it to destroy other hardware. (Imagine a flaw in a graphics board that allows a bad driver to drive up the output voltage to the point of breaking the monitor. Luckily that scenario is probably highly unlikely, but I guess high voltage is the most likely thing which isn't trivial for hardware to protect itself against).
What I'd like to see is not really a system where each layer has knowledge about a lot of layers below, but rather one where the designer has the knowledge. Figure out what the cost of multiple layers of your own virtualization is going to be, and improve on that without assuming that you are necesarilly going to be running under your own virtualization in the end.
Current hypervisors are not really designed for running under themselves, in fact the architecture is not even designed with virtualization in mind. There are attempts to improve on this, but I haven't yet had the oppertunity to play with any of those. Of course being able to virtualize yourself is the first step, only then can you start considering performance.
As for memory usage, you are obviously going to need at least a constant amount for each layer, thus there will be a linear overhead in the number of layers. But is it going to be worse? Are page tables going to cause an exponential overhead in memory usage as well? (And is the base going to be large enough for that to matter? 1.001^n isn't that bad a complexity).
How carefully did you meassure the boot times? If you just meassured each case once, the difference could be for a lot of other reasons. If you want to be sure, do the following. Flip a coin to decide whether you are going to plug the power or run from battery, then boot the machine. Repeat this ten (or more) times, meassuring the boot time each time.