Well, you're not paying for the use of the infrastructure so much as you're paying for the fact that there is only one iCloud, and the people who run it can charge whatever they want for you to use it.
When you pay a VPS or VM provider you're paying for infrastructure, because there are a bazillion of them and chances are you only need to tweak a few things to switch from one to another.
This is my biggest complaint with the move to the cloud - there are few open standards. Amazon is actually pretty good in this regard as just about everything they do can be built open-source on your own in an almost-completely-compatible way. Their value actually is in the fact that you don't have to do it yourself, and they're not trying to build on access to some pool of data they've collected that everybody wants in on.
Use LBE Privacy Guard. You can control individual permissions like location detection and such. Don't ask Facebook to not check in - just block its access to the location API.
This is a lousy design. Why do you think worms and botnets are such a problem? You assume that software from "trusted" sources never contains flaws, and that there are only two levels of trust - all or none.
Imagine that when you double-click on a PDF file in an email your PDF viewer launches in a jail with permissions that include only being able to open that PDF file. Then it doesn't matter how many vulnerabilities that viewer contains - it can't tamper with my system or send a copy of my data to who-knows-where.
Why should my spreadsheet app be able to edit my.bashrc? Why should it be able to open arbitrary network connections?
There are many benefits from systems that provide more granular security. The challenge has been in making these permissions easy to manage. If anything PCs are moving more in the direction of what has been happening with phones, and I welcome this.
Or, maybe there is a choice other than using an application with a suboptimal experience, or using a lousy interface?
I use LBE Privacy Guard. It blocks most of the more intrusive application behaviors but still lets me use the applications (unlike alternative implementations like CyanogenMod's, which usually just crashes the applications and the people who add it insist that you shouldn't be using it anyway).
Take-it-or-leave-it is a lousy design, and it is an unnecessary one. When displaying the user a list of permissions let them select which ones to grant, and the API should not allow an application to reliably detect which permissions were granted, so that they can't cause bugs. If you don't grant access to contacts, then the application doesn't see any contacts, and if they add new ones they go into a private namespace that nothing else sees. If you don't grant access to location, then the GPS is "turned off" 24x7. If you don't grant access to the network then there is no network service. That keeps app designers from "punishing" users who block access (believe it or not I've seen this kind of behavior).
A good OS protects the overall integrity of the system from misbehaving applications.
Imagine if Android didn't use pre-emptive multitasking, but instead had a permission of "allow application to run in background." These tasks would have to yield time back to the OS for anything else to run. When your phone ends up hanging every 20 minutes would you still say that it was your choice to install apps that run in the background?
Software WILL have bugs. Software that is well-behaved today WILL get an update that causes it to misbehave tomorrow. The OS needs to acknowledge imperfection and deal with it. Take-it-or-leave-it security just ticks people off.
True, but the defect in this case is not having sufficient privilege granularity. A user should be able to grant access to Facebook to add info to contacts and modify the info it maintains, but require explicit approval to modify content that is managed elsewhere. All-or-nothing isn't the right solution.
Well, the argument used to be that good applications have idle loops that yield and are deigned to not hang in event handlers.
Then somebody came along and built pre-emptive multitasking and process separation into the OS, so that we can run systems with more than three applications on them and not have to reboot the thing every 20 minutes.
You could say that it was a bad design to not give phone owners control over WHICH email addresses Facebook could update.
That is the problem with accept-or-don't-install permission systems. You end up with either not using an app at all, or giving it access to modify anything in your contacts. Why not have an in-between setting like - allow the app to add info to contacts and modify the info it adds, but not touch what is already there? Then when the app asks for unconditional access give the user the ability to grant the reduced access instead?
The permissions systems on OSes like Android seem outdated. Arguments in their favor seem analogous to arguing that we don't need pre-emptive multitasking and process separation because users simply shouldn't run applications that crash the system.
While they have some similar goals, TPM and UEFI are different things. Almost all PC hardware in existance now is already capable of remote attestation since TPM modules have been around for years now. You can even set up a linux OS so that it can only mount an encrypted volume if it was booted via the trusted path - if you boot from a CD and chroot to the root volume it won't be able to mount the encrypted volume. Ditto if you change the bootloader or kernel. Google for trusted grub sometime.
I hear you, and I'm normally an advocate of databases, but you have to consider opportunity cost as well.
If a solution costs $10 and 15 minutes to deploy for your 3 people in a garage working on loaned money, but will require a six-month $100k project to replace in 10 years when you have 300 employees and substantial profits, then I'd call that the best $10 you could spend.
Sure, spending more up-front would might have saved absolute dollars later, but the costs would come at a time when the company could not afford them, and when other activities would better position the company for success.
This isn't unlike people who point out that many start-ups struggle with problems when they suddenly turn into the next Facebook and find they weren't designed to scale. Well, sure, that is a problem, but I'd rather be struggling with how to turn by $200M in advertising money into infrastructure improvements than the problem of how to pay the rent because while I was messing around with building a better solution somebody else came along and grabbed the $200M in ad money with their tossed-together solution.
Especially for a small business procrastination can be a virtue.
Yeah, but that is a database engine. You can't really compare it to Excel, or even Access.
Hey, I can appreciate the benefits of a good database engine - you're preaching to the choir here.
However, what people want is the ability to hit file new and start punching in values without having to understand what a data model or 3rd-normal form is. Simply giving users a good engine without that stuff isn't going to have much benefit anyway, other than eliminating some of the more glaring issues like what happens when you try to add the 65536'th row in Excel.
Ugh, broken build scripts just mean that no linux distro will bother to ship your software. So, unless the author of the software wants to limit distribution to whatever distros the author can personally maintain packages for (and get users to track), that isn't a good thing.
If your software isn't popular, this won't help it become popular. If you care that much about donations, that probably matters to you.
If your software is popular, then expect somebody to fork it and actually maintain a decent build system, and all the distros will ship that instead, thus meaning that nobody actually uses your "official" version. I maintain packages on a distro and I've on occasion essentially pointed the distro at what amounts to my own forks of projects just so that I can maintain code I can actually ship and the distro's requirements are met. I'd rather just use upstream's code directly, but not if it means I'm maintaining messes of patches and merging in new makefiles and such all the time. Easier to just maintain my own git repository and just pull in upstream changes from time to time. Oh, easiest way to get this kind of treatment is to not bother to tag your releases. No, I'm not going to ship out your binary - I'm going to build one that I know is clean - which means that if you don't want your user-base to be fragmented across 14 different commits you should mark which one is the official release version.
There is no fighting chance in the legal system. Judges don't like to grant dismissals or summary judgments, which means you have to litigate the case substantially. That means you've been punished regardless of outcome.
Fight pro se and you end up spending half your life in a courtroom or typing up documents, likely losing your job/etc in the process.
Have a lawyer go to court for you and you end up spending a fortune in fees.
The US legal system is a travesty of justice. They might as well replace summons with sentences - it wouldn't make much difference.
The grub config file and stage2 file can be on any partition. When you run grub-install the bootloader is pointed at the one that contains the file. If you move it or change the filesystem type of that partition then your system won't boot unless you re-install the bootloader first.
If you wipe out random partitions from time to time you're probably best off dedicating one for grub - it need not be large. With grub1 this is often necessary if you use non-supported features like LVM or raid striping.
The code does have to go somewhere - you can't fit all those fancy menus in a boot sector. The code in the 0th cylinder can decode your filesystem so it is no problem if the files are fragmented/etc.
The Nexus, unfortunately, is the only Google experience you can get and honestly I gave it an 8 initially, a 6-7 after a few months of use, and a 9 now that I have a prerelease Jellybean. The software evolution and polish has been HUGE.
The problem with Nexus is that often you have to pay more for it (varies based on carrier/year/etc), and it is often carrier-limited entirely (unless you want to buy one that is already old). It gets better support than any other Android phone, but Google rarely supports them with updates more than a year after they stop selling them (has a Nexus phone EVER gotten an update more than a year after they were last sold?). That's better than most of the other vendors who stop supporting their phones before they even stop selling them. However, if you replace an iPhone every two years chances are you'll never miss an OS update (though Apple of late has been spoiling that a bit by not releasing all the features to all the phones).
My desires are simple. I want stock Android without garbage on top. I want root on request without cracking the thing. I want updates for two years after the last one is sold (not two years after it is announced, or first sold - not that I've seen an Android phone do even this).
Sooner or later somebody is going to start writing exploits against old versions of android designed to flatten mobile networks (virus propagates phone to phone and then turns the radio into a jammer). Maybe then the carriers will wake up and decide to start deploying updates...
I imagine the drop size isn't nearly as important as the drop separation as far as resolution goes. The size of two stars viewed in a telescope is vanishingly small (WAY smaller than a pixel), and yet you can easily spot them. What matters where resolution is concerned is their separation. In the case of radar obviously relfectivity matters a great deal, as you basically pointed out.
I'd be interested on the dish size required to address diffraction. Even with a phased array I wouldn't be surprised if the sizes are quite large. Obviously quite a bit has already been done with radio telescopes, but I don't know that you can focus one of those on something a mere few miles away. That would be like trying to use a camera to take a picture of a bacteria sitting on the lens.
Yup, and doppler can be really sensitive because you can just filter out anything that isn't moving above some threshold velocity. That does mean that things moving tangentially to the radar can be hard to detect (something exploited by fighters when they evade radar-guided missiles).
I'm sure there are a bazillion refinements these days, but the principle is pretty simple. You generate a radar pulse, then take the returned pulse and mix it with the output signal. The return pulse is slightly different in frequency due to the doppler effect, so you get beats, which are easily filtered out with a low-pass filter.
To be stealthy an aircraft has to return VERY little radiation.
The big downside of stealth is that it actually tends to deflect radar and not absorb it so much. So, it is only invisible if the receiver is near the transmitter. Obviously most radars work that way, but I'd think that you could separate them considerably and defeat many stealth technologies. This also would allow you to use cheap transmitters and expensive receivers, and only the former would be exposed to easy attack. As long as the receiver could pick up the direct radar transmission as well as the reflection I'd think it could still implement doppler radar. Or, if your oscillator is stable enough maybe you can just generate the reference.
Note - I'm not even an EE let alone a radar designer. I just know enough to be dangerous (having worked in some fields that use RF).
If he did those things I'm all for punishing him. However, unless he admits to them, how could such a thing be proven? He says one thing, the women say something else. I don't see any hard evidence one way or another.
I'm the last person in the world to condone rape, but I'm also not a fan of punishing people purely on the word of a single witness.
A military device should assume any unauthenticated data is misinformation. If designed properly it would never use unencrypted GPS. That's been standard operating procedure in any military with half a brain for 50 years. The US should be particularly aware of this considering spoofing enemy communications was used against the Axis quite a bit in WWII (the brits would send false instructions by voice to German bomber pilots to vector them towards fighters).
If the satellite transmits 1kbps for 30 years, that is only 113GB of data. You could conceivably load all that onto a satellite before it is launched.
The issue is getting the key to the receiver. The key is only as secure as whatever method you use to transfer it. Also, unless you start multiplying that data volume substantially everybody has to share the same pads, which makes it easier to intercept (though this can be mitigated by only loading as much key as strictly necessary into any particular device - a ship won't stay at sea for more than a year and so on). You could have a few backup pads on the satellite in case one is compromised. Plus, if you never distribute pad more than a year is out and one is compromised then you could always go back to it a year later.
Key distribution is the big problem with OTP. Inevitably you end up transmitting it over conventional crypto, which reduces the problem to breaking that cipher. However, a OTP itself if used properly is indeed unbreakable unless the key is disclosed.
Why would you need a custom grub on top of a standard signed one? You sign the grub bootloader and install it. You add your key to the EFI firmware. You point that grub at whatever you want to boot, and lock it down as much or as little as you like.
You only need one bootloader. The issue isn't that grub doesn't work - it is just that it won't be signed by any key recognized by your firmware. The easiest solution to that is to just replace the key in your firmware, and if you want to dual-boot windows re-sign the windows loader.
Actually, what you're describing has been available in x86 PCs for years - remote attestation and such. Nobody really uses it, but it is already available.
Secure boot blocks unsigned code from running. The existing technologies allow code to determine if untrusted code has been run before.
If MS just enabled support for it in their bootloaders they could detect MBR rootkits already. Each stage in the boot process registers itself with the TPM module, and any later stage can find out what came before.
You can even do this on linux - just google for Trusted GRUB. I'm fine with the concept, as long as the computer owner is issued a copy of any keys preinstalled by the vendor (including associated private keys), and is able to replace them with their own. That is what is missing in most TPM implementations, which is what makes it "treacherous computing." If you just fixed that one bit this would be a powerful way for system owners to prevent attacks on their devices while blocking attempts to use it for DRM.
The only thing that keeps the secondary brake locked in place is lack of driver skill.
That, and the fact that the design on my car is push pedal to lock, push even harder past the stop and let go to unlock. That does make me a bit concerned - one of these days I'll have to test it out for emergency braking in a parking lot and figure out just how far you have to push it in to toggle it back to unlocking. No, there is no release lever. It really does seem like it is just a "parking brake."
Slashdot Mirror
Well, you're not paying for the use of the infrastructure so much as you're paying for the fact that there is only one iCloud, and the people who run it can charge whatever they want for you to use it.
When you pay a VPS or VM provider you're paying for infrastructure, because there are a bazillion of them and chances are you only need to tweak a few things to switch from one to another.
This is my biggest complaint with the move to the cloud - there are few open standards. Amazon is actually pretty good in this regard as just about everything they do can be built open-source on your own in an almost-completely-compatible way. Their value actually is in the fact that you don't have to do it yourself, and they're not trying to build on access to some pool of data they've collected that everybody wants in on.
Use LBE Privacy Guard. You can control individual permissions like location detection and such. Don't ask Facebook to not check in - just block its access to the location API.
This is a lousy design. Why do you think worms and botnets are such a problem? You assume that software from "trusted" sources never contains flaws, and that there are only two levels of trust - all or none.
Imagine that when you double-click on a PDF file in an email your PDF viewer launches in a jail with permissions that include only being able to open that PDF file. Then it doesn't matter how many vulnerabilities that viewer contains - it can't tamper with my system or send a copy of my data to who-knows-where.
Why should my spreadsheet app be able to edit my .bashrc? Why should it be able to open arbitrary network connections?
There are many benefits from systems that provide more granular security. The challenge has been in making these permissions easy to manage. If anything PCs are moving more in the direction of what has been happening with phones, and I welcome this.
Or, maybe there is a choice other than using an application with a suboptimal experience, or using a lousy interface?
I use LBE Privacy Guard. It blocks most of the more intrusive application behaviors but still lets me use the applications (unlike alternative implementations like CyanogenMod's, which usually just crashes the applications and the people who add it insist that you shouldn't be using it anyway).
Take-it-or-leave-it is a lousy design, and it is an unnecessary one. When displaying the user a list of permissions let them select which ones to grant, and the API should not allow an application to reliably detect which permissions were granted, so that they can't cause bugs. If you don't grant access to contacts, then the application doesn't see any contacts, and if they add new ones they go into a private namespace that nothing else sees. If you don't grant access to location, then the GPS is "turned off" 24x7. If you don't grant access to the network then there is no network service. That keeps app designers from "punishing" users who block access (believe it or not I've seen this kind of behavior).
A good OS protects the overall integrity of the system from misbehaving applications.
Imagine if Android didn't use pre-emptive multitasking, but instead had a permission of "allow application to run in background." These tasks would have to yield time back to the OS for anything else to run. When your phone ends up hanging every 20 minutes would you still say that it was your choice to install apps that run in the background?
Software WILL have bugs. Software that is well-behaved today WILL get an update that causes it to misbehave tomorrow. The OS needs to acknowledge imperfection and deal with it. Take-it-or-leave-it security just ticks people off.
True, but the defect in this case is not having sufficient privilege granularity. A user should be able to grant access to Facebook to add info to contacts and modify the info it maintains, but require explicit approval to modify content that is managed elsewhere. All-or-nothing isn't the right solution.
Well, the argument used to be that good applications have idle loops that yield and are deigned to not hang in event handlers.
Then somebody came along and built pre-emptive multitasking and process separation into the OS, so that we can run systems with more than three applications on them and not have to reboot the thing every 20 minutes.
Buggy apps are bad. Poor OS design is worse.
You could say that it was a bad design to not give phone owners control over WHICH email addresses Facebook could update.
That is the problem with accept-or-don't-install permission systems. You end up with either not using an app at all, or giving it access to modify anything in your contacts. Why not have an in-between setting like - allow the app to add info to contacts and modify the info it adds, but not touch what is already there? Then when the app asks for unconditional access give the user the ability to grant the reduced access instead?
The permissions systems on OSes like Android seem outdated. Arguments in their favor seem analogous to arguing that we don't need pre-emptive multitasking and process separation because users simply shouldn't run applications that crash the system.
While they have some similar goals, TPM and UEFI are different things. Almost all PC hardware in existance now is already capable of remote attestation since TPM modules have been around for years now. You can even set up a linux OS so that it can only mount an encrypted volume if it was booted via the trusted path - if you boot from a CD and chroot to the root volume it won't be able to mount the encrypted volume. Ditto if you change the bootloader or kernel. Google for trusted grub sometime.
I hear you, and I'm normally an advocate of databases, but you have to consider opportunity cost as well.
If a solution costs $10 and 15 minutes to deploy for your 3 people in a garage working on loaned money, but will require a six-month $100k project to replace in 10 years when you have 300 employees and substantial profits, then I'd call that the best $10 you could spend.
Sure, spending more up-front would might have saved absolute dollars later, but the costs would come at a time when the company could not afford them, and when other activities would better position the company for success.
This isn't unlike people who point out that many start-ups struggle with problems when they suddenly turn into the next Facebook and find they weren't designed to scale. Well, sure, that is a problem, but I'd rather be struggling with how to turn by $200M in advertising money into infrastructure improvements than the problem of how to pay the rent because while I was messing around with building a better solution somebody else came along and grabbed the $200M in ad money with their tossed-together solution.
Especially for a small business procrastination can be a virtue.
Yeah, but that is a database engine. You can't really compare it to Excel, or even Access.
Hey, I can appreciate the benefits of a good database engine - you're preaching to the choir here.
However, what people want is the ability to hit file new and start punching in values without having to understand what a data model or 3rd-normal form is. Simply giving users a good engine without that stuff isn't going to have much benefit anyway, other than eliminating some of the more glaring issues like what happens when you try to add the 65536'th row in Excel.
Ugh, broken build scripts just mean that no linux distro will bother to ship your software. So, unless the author of the software wants to limit distribution to whatever distros the author can personally maintain packages for (and get users to track), that isn't a good thing.
If your software isn't popular, this won't help it become popular. If you care that much about donations, that probably matters to you.
If your software is popular, then expect somebody to fork it and actually maintain a decent build system, and all the distros will ship that instead, thus meaning that nobody actually uses your "official" version. I maintain packages on a distro and I've on occasion essentially pointed the distro at what amounts to my own forks of projects just so that I can maintain code I can actually ship and the distro's requirements are met. I'd rather just use upstream's code directly, but not if it means I'm maintaining messes of patches and merging in new makefiles and such all the time. Easier to just maintain my own git repository and just pull in upstream changes from time to time. Oh, easiest way to get this kind of treatment is to not bother to tag your releases. No, I'm not going to ship out your binary - I'm going to build one that I know is clean - which means that if you don't want your user-base to be fragmented across 14 different commits you should mark which one is the official release version.
There is no fighting chance in the legal system. Judges don't like to grant dismissals or summary judgments, which means you have to litigate the case substantially. That means you've been punished regardless of outcome.
Fight pro se and you end up spending half your life in a courtroom or typing up documents, likely losing your job/etc in the process.
Have a lawyer go to court for you and you end up spending a fortune in fees.
The US legal system is a travesty of justice. They might as well replace summons with sentences - it wouldn't make much difference.
The grub config file and stage2 file can be on any partition. When you run grub-install the bootloader is pointed at the one that contains the file. If you move it or change the filesystem type of that partition then your system won't boot unless you re-install the bootloader first.
If you wipe out random partitions from time to time you're probably best off dedicating one for grub - it need not be large. With grub1 this is often necessary if you use non-supported features like LVM or raid striping.
The code does have to go somewhere - you can't fit all those fancy menus in a boot sector. The code in the 0th cylinder can decode your filesystem so it is no problem if the files are fragmented/etc.
The Nexus, unfortunately, is the only Google experience you can get and honestly I gave it an 8 initially, a 6-7 after a few months of use, and a 9 now that I have a prerelease Jellybean. The software evolution and polish has been HUGE.
The problem with Nexus is that often you have to pay more for it (varies based on carrier/year/etc), and it is often carrier-limited entirely (unless you want to buy one that is already old). It gets better support than any other Android phone, but Google rarely supports them with updates more than a year after they stop selling them (has a Nexus phone EVER gotten an update more than a year after they were last sold?). That's better than most of the other vendors who stop supporting their phones before they even stop selling them. However, if you replace an iPhone every two years chances are you'll never miss an OS update (though Apple of late has been spoiling that a bit by not releasing all the features to all the phones).
My desires are simple. I want stock Android without garbage on top. I want root on request without cracking the thing. I want updates for two years after the last one is sold (not two years after it is announced, or first sold - not that I've seen an Android phone do even this).
Sooner or later somebody is going to start writing exploits against old versions of android designed to flatten mobile networks (virus propagates phone to phone and then turns the radio into a jammer). Maybe then the carriers will wake up and decide to start deploying updates...
I imagine the drop size isn't nearly as important as the drop separation as far as resolution goes. The size of two stars viewed in a telescope is vanishingly small (WAY smaller than a pixel), and yet you can easily spot them. What matters where resolution is concerned is their separation. In the case of radar obviously relfectivity matters a great deal, as you basically pointed out.
I'd be interested on the dish size required to address diffraction. Even with a phased array I wouldn't be surprised if the sizes are quite large. Obviously quite a bit has already been done with radio telescopes, but I don't know that you can focus one of those on something a mere few miles away. That would be like trying to use a camera to take a picture of a bacteria sitting on the lens.
Yup, and doppler can be really sensitive because you can just filter out anything that isn't moving above some threshold velocity. That does mean that things moving tangentially to the radar can be hard to detect (something exploited by fighters when they evade radar-guided missiles).
I'm sure there are a bazillion refinements these days, but the principle is pretty simple. You generate a radar pulse, then take the returned pulse and mix it with the output signal. The return pulse is slightly different in frequency due to the doppler effect, so you get beats, which are easily filtered out with a low-pass filter.
To be stealthy an aircraft has to return VERY little radiation.
The big downside of stealth is that it actually tends to deflect radar and not absorb it so much. So, it is only invisible if the receiver is near the transmitter. Obviously most radars work that way, but I'd think that you could separate them considerably and defeat many stealth technologies. This also would allow you to use cheap transmitters and expensive receivers, and only the former would be exposed to easy attack. As long as the receiver could pick up the direct radar transmission as well as the reflection I'd think it could still implement doppler radar. Or, if your oscillator is stable enough maybe you can just generate the reference.
Note - I'm not even an EE let alone a radar designer. I just know enough to be dangerous (having worked in some fields that use RF).
If he did those things I'm all for punishing him. However, unless he admits to them, how could such a thing be proven? He says one thing, the women say something else. I don't see any hard evidence one way or another.
I'm the last person in the world to condone rape, but I'm also not a fan of punishing people purely on the word of a single witness.
A military device should assume any unauthenticated data is misinformation. If designed properly it would never use unencrypted GPS. That's been standard operating procedure in any military with half a brain for 50 years. The US should be particularly aware of this considering spoofing enemy communications was used against the Axis quite a bit in WWII (the brits would send false instructions by voice to German bomber pilots to vector them towards fighters).
If the satellite transmits 1kbps for 30 years, that is only 113GB of data. You could conceivably load all that onto a satellite before it is launched.
The issue is getting the key to the receiver. The key is only as secure as whatever method you use to transfer it. Also, unless you start multiplying that data volume substantially everybody has to share the same pads, which makes it easier to intercept (though this can be mitigated by only loading as much key as strictly necessary into any particular device - a ship won't stay at sea for more than a year and so on). You could have a few backup pads on the satellite in case one is compromised. Plus, if you never distribute pad more than a year is out and one is compromised then you could always go back to it a year later.
Key distribution is the big problem with OTP. Inevitably you end up transmitting it over conventional crypto, which reduces the problem to breaking that cipher. However, a OTP itself if used properly is indeed unbreakable unless the key is disclosed.
I'll have to reboot my system. As far as I can tell it doesn't have a cat command - v0.97. Maybe I just missed it.
Sure, and while I'm doing this I have no access to any of the other grub command options...
Why would you need a custom grub on top of a standard signed one? You sign the grub bootloader and install it. You add your key to the EFI firmware. You point that grub at whatever you want to boot, and lock it down as much or as little as you like.
You only need one bootloader. The issue isn't that grub doesn't work - it is just that it won't be signed by any key recognized by your firmware. The easiest solution to that is to just replace the key in your firmware, and if you want to dual-boot windows re-sign the windows loader.
Actually, what you're describing has been available in x86 PCs for years - remote attestation and such. Nobody really uses it, but it is already available.
Secure boot blocks unsigned code from running. The existing technologies allow code to determine if untrusted code has been run before.
If MS just enabled support for it in their bootloaders they could detect MBR rootkits already. Each stage in the boot process registers itself with the TPM module, and any later stage can find out what came before.
You can even do this on linux - just google for Trusted GRUB. I'm fine with the concept, as long as the computer owner is issued a copy of any keys preinstalled by the vendor (including associated private keys), and is able to replace them with their own. That is what is missing in most TPM implementations, which is what makes it "treacherous computing." If you just fixed that one bit this would be a powerful way for system owners to prevent attacks on their devices while blocking attempts to use it for DRM.
The only thing that keeps the secondary brake locked in place is lack of driver skill.
That, and the fact that the design on my car is push pedal to lock, push even harder past the stop and let go to unlock. That does make me a bit concerned - one of these days I'll have to test it out for emergency braking in a parking lot and figure out just how far you have to push it in to toggle it back to unlocking. No, there is no release lever. It really does seem like it is just a "parking brake."