I'm still thinking "what could possibly go right". The claims made about this system are pretty hyperbolic. The FBI, for example, are stuck with a plethora of mostly non-interacting legacy systems with separate, often competing interfaces. And Trapwire supposedly integrates all these, plus a bunch from other agencies and organisations, and likes it live to CCTV with facial recognition? And they've also cracked the long-standing automated behavioural analysis problem?
It's verged striaght through "too good to be true" and right into "who is buying this nonsense?".
I too like it as a replacement for the start menu. I have no interest in metro apps, but the start screen is just more useful than the start menu. For one thing, it actually uses more than 1/5 of the screen (you've brought up the start menu to open something, do you really need to see that other 4/5 of the screen right now?). For anyone who hits the start key (who even uses the on-screen button?), types part of the application name and hits enter, the start screen works exactly the same as the menu.
I do think prohibiting users from booting to the desktop is a silly idea though.
Oddly enough, I like both the ribbon and the Start-screen-Formerly-Known-as-Metro. The ribbon, mainly because it organises things a bit better then endless nested drop-down menus (though you can still hit Alt and get the same menus if for some reason there's a situation where they'd be preferable).
The start screen: when opening the start menu, do you ever give a pair of foetid dingoes kidneys what is going on in the 3/4 of the screen that is to the right of it? I never have. Think of it was simply a wider start menu. Don't want metro 'apps'? Don't use them.
It also makes Reverse Polish Notation jokes and centres a good chunk of plot on the recovery of a biological experiment. For all the things they got right, I can begrudge them the implausibility of splashdown occurring in the same randomly selected small body of water twice.
The books are being translated into English by Haikasoru (novel publishing arm of Viz). Go buy them!
Dead wrong. Direct from the current (as of 19 Jul 2012) MS Win 8 certification requirements:
17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
1. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
2. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.
3. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.
Translation: for x86 systems, you MUST be able to modify keys yourself. This can be either by an interface to add new keys, or a way to wipe all keys and then add new ones (setup mode), meaning the Win 8 key needs to be entered manually. I can't see any manufacturers opting for the less user friendly latter option, especially with the jockeying for 'unique' BIOS features that occurs between motherboard manufacturers.
You can install whatever the hell key you want on x86 machines. You can self sign, you can have somebody else sign, whatever. There's nothing stopping you apart from having to press F8 during boot to enter the new key. That's all. Being able to turn off secure boot AND add your own keys is a REQUIREMENT for the 'certified for Windows 8' label.
1) Don't use hub motors.
2) DON'T USE HUB MOTORS. Really. They're elegant, they hide away in the wheels, they're an immensely cool idea. They're also hilariously inefficient compared to 'normal' motors, difficult as hell to gear, very damage prone, and massively increase the unsprung mass for each wheel. And have to pretty much be custom made for each wheel layout, so are very expensive.
3) Use a high charge/discharge rate battery, or large capacitor. Run the motors directly off this bank, so it needs to be able to get the vehicle going and keep it going for a few miles. The gennie is hooked to the battery/cap, and will cut in whenever it starts to discharge, and stops when the discharging stops and the batt/cap is full again (you could segment the batt/cap bank and cycle through them to make the charge/discharge circuity easier to handle). This allows the gennie to run at one speed only (and never need to idle), and thus can be made even more efficient than if it had to be throttled or geared and be only reasonably efficient over a range. This also opens up a lightweight (though more expensive) turbine gennie as well as the traditional piston-diesel. It also means your battery/capacitor bank doesn't need to be especially large, thus cutting down on cost significantly.
I never use it. Being the owner of a keyboard, I simply press the perfectly good button on that.
Besides, the start button is still there, it's simply hidden under a hot corner. Move your mouse to the same place you would normally, and click as normally, and you still still perform the same action as in older versions of windows. Of course, the menu is replaced with the start screen, but that's another matter.
'Retina' isn't even correct. Your eye is not a camera, and does not function in the same way. The "~100ppi" figure may work for discriminating between separate pixels, but is insufficient for vernier acuity.
The difference is paying for something that will probably work most of the time with a bit of fiddling occasionally, and something that can be put in a crate, bounced around on rough seas in wildly varying temperatures for a few months/years, then be pulled out by someone with a small pamphlet of basic instructions and still work.
I'd take issue that "user actually has to read the damn instructions" is somehow entrenching a monopoly position. Microsoft has pulled some dodgy things, but this isn't one of them.
It depends on where the problem lies: If the game is using the directX (or openGL) libraries correctly but the driver is mucking things up, then the game developer should not need to code around driver bugs. Conversely, if the game developer is using a 'clever hack' to eke out some more performance, this creates a headache for the driver developers to keep this hack working in one instance but stop it working for things written to the word of the API in other instances.
Not true at all. The big barrier is the shipping costs: once you can get stuff up there, the actual living in space bit is almost trivial with all the work already done on it. That's why Space-X's low launch costs are so exiting: cheaper launchers means more launches, and more launches means cheaper launchers (through mass production). Combined with their plans for partially and fully reuseable stages, they could eventually drive launch costs down towards fuel costs.
A better analogy would be attempting to build a 747 today, but stipulating that all parts and tools must first be carried to the factory from the other side of the planet by hand.
Because you can:
a - Choose not to use Secure Boot, and run whatever the hell you want (i.e. the current situation with regular BIOS and UEFI)
b - Add your own key to the mobo, and sign your distro with it.
Both of these are predicated on buying a motherboard or pre-built that allows you to do so. The onus is on the manufacturer to allow you to do stuff with Secure Boot, the microsoft requirements (for non-ARM architectures) do not require Secure Boot be fully locked, only that the default setting is "boot Windows 8 securely".
Most expensive, maybe, but best? Not if your goal is a transparent amplifier: one that takes an input, and reproduces that output as accurately as possible with a higher amplitude. Valves suck at this. An entire branch of mathematics (control theory) was developed to compensate for the horrendous non-linearities of vacuum tubes.
You may like the distortions produced by tube amps (or transistor amps outputting those same distortions via DSP), but don't pretend they're better at reproducing sound. They are demonstrably not.
Do you have anything conclusive that proves official sources (i.e. the IAEA and NISA) have reported anything incorrectly (or without later publishing the correction)? Media reporting inside of and outside of Japan swung wildly between "everything is fine" and "next Chernobyl?!?!?" with dizzying rapidity and little provocation. And I mean 'proof' other than dodgy blogs citing the-Geiger-counter-I-built-myself-but-never-had-calibrated.
They were aiming for in-expensive which means cutting corners.
The 'Pi can play 1080p h.264. At High Profile level 4.1 too, which means unfettered BluRay streams, not just main-profile low-bitrate transcoded video (as is usually the case with cheap devices advertising 1080p decode support).
This is cheaper, because it only needs 3 servos for the entire arm, rather than 3 for each arm segment, and still maintain independent segment motion. You can lock (jam) all arm segments, release one for motion, move it (reshape that segment) while keeping the others rigid, then lock it again.
The bytes on the NAND itself are encrypted and have not guarantee whatsoever of being contiguous. Even if you have a mythical public-key-breaking quantum computer at your disposal, you'd still need to arrange a few gigabytes of 4kb blocks (pages) into the correct order just to get the ciphertext to start with.
You appear to have fallen to the age-old (or rather, about 15 year old) myth that there is a readable 'echo' of a bit after it has been overwritten. This is false, and has been ever since the magneto-resistive head was introduced (and especially the GMR head around 2000). Even with a magnetic force microscope you're not going to be reading squat other than the current bit value (or rather, the current analogue value that would then have to be processed along with the preceding and following values into what is probably the bit that you wrote). While it may have been true - in the days when a R/W head actually had a little coil of wire in it and capacities were measured in megabytes - that you could throw a few hundred engineers at a platter with a MFM and maybe recover a little bit of coherent data, that is no longer true. The amount of data you'd need to comb through if you could recover it perfectly (which you can't) is so immense that you'd need an army working 24/7 for decades. Even if you knew the precise data you were looking for and it's precise location on the platter, if you wrote a single zero pass over that location no MFM would be able to read anything useful, or the same head that was used in the MHM would be used in HDDs and you;d be back to square one.
The ATA SECURE ERASE command tells the head to write zeroes over the entire surface of the platter. Regular write-random-crap-a-bunch-of-times software such as DBAN fail to erase sectors in the G-list, which could subsequently be recovered (albeit unlikely to contain anything interesting). it won't erase sectors in the factory P-list, but nothing was ever written there in the first place. This is sufficient to make any data that was on the drive totally unrecoverable. Hell, ATA SECURE ERASE is NIST-approved for government and military data destruction at the same level as physical destruction of the platters.
More like years rather than months unless you're pumping through terabytes of data a day. The point is moot, however: SSDs do not store data continuously like HDDs do: your data can be spread across blocks, across chips, compressed AND encrypted all at the same time. Take out the allocation table, and all that data is now randomly arranged bits. And because erased data on NAND is truly erased*, you just need to wipe that little bit of memory to effectively securely erase the whole SSD. If you wanted to be hilariously over-cautious, keep your allocation table on fast volatile memory.
* This is also true for any HDD in the last decade or two if you run ATA SECURE ERA SE command. All those fancy multi-pass erasers and mechanical destroyers are essentially pointless.
Tixati seems pretty nice and lightweight, but has the various back-end gubbins (scheduling, TCP/UDP options, etc) that uTorrent has without the bloat.
I'm still thinking "what could possibly go right". The claims made about this system are pretty hyperbolic. The FBI, for example, are stuck with a plethora of mostly non-interacting legacy systems with separate, often competing interfaces. And Trapwire supposedly integrates all these, plus a bunch from other agencies and organisations, and likes it live to CCTV with facial recognition? And they've also cracked the long-standing automated behavioural analysis problem?
It's verged striaght through "too good to be true" and right into "who is buying this nonsense?".
I too like it as a replacement for the start menu. I have no interest in metro apps, but the start screen is just more useful than the start menu. For one thing, it actually uses more than 1/5 of the screen (you've brought up the start menu to open something, do you really need to see that other 4/5 of the screen right now?). For anyone who hits the start key (who even uses the on-screen button?), types part of the application name and hits enter, the start screen works exactly the same as the menu.
I do think prohibiting users from booting to the desktop is a silly idea though.
Oddly enough, I like both the ribbon and the Start-screen-Formerly-Known-as-Metro. The ribbon, mainly because it organises things a bit better then endless nested drop-down menus (though you can still hit Alt and get the same menus if for some reason there's a situation where they'd be preferable). The start screen: when opening the start menu, do you ever give a pair of foetid dingoes kidneys what is going on in the 3/4 of the screen that is to the right of it? I never have. Think of it was simply a wider start menu. Don't want metro 'apps'? Don't use them.
It also makes Reverse Polish Notation jokes and centres a good chunk of plot on the recovery of a biological experiment. For all the things they got right, I can begrudge them the implausibility of splashdown occurring in the same randomly selected small body of water twice.
The books are being translated into English by Haikasoru (novel publishing arm of Viz). Go buy them!
17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
1. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
2. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.
3. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.
Translation: for x86 systems, you MUST be able to modify keys yourself. This can be either by an interface to add new keys, or a way to wipe all keys and then add new ones (setup mode), meaning the Win 8 key needs to be entered manually. I can't see any manufacturers opting for the less user friendly latter option, especially with the jockeying for 'unique' BIOS features that occurs between motherboard manufacturers.
You can install whatever the hell key you want on x86 machines. You can self sign, you can have somebody else sign, whatever. There's nothing stopping you apart from having to press F8 during boot to enter the new key. That's all. Being able to turn off secure boot AND add your own keys is a REQUIREMENT for the 'certified for Windows 8' label.
1) Don't use hub motors.
2) DON'T USE HUB MOTORS. Really. They're elegant, they hide away in the wheels, they're an immensely cool idea. They're also hilariously inefficient compared to 'normal' motors, difficult as hell to gear, very damage prone, and massively increase the unsprung mass for each wheel. And have to pretty much be custom made for each wheel layout, so are very expensive.
3) Use a high charge/discharge rate battery, or large capacitor. Run the motors directly off this bank, so it needs to be able to get the vehicle going and keep it going for a few miles. The gennie is hooked to the battery/cap, and will cut in whenever it starts to discharge, and stops when the discharging stops and the batt/cap is full again (you could segment the batt/cap bank and cycle through them to make the charge/discharge circuity easier to handle). This allows the gennie to run at one speed only (and never need to idle), and thus can be made even more efficient than if it had to be throttled or geared and be only reasonably efficient over a range. This also opens up a lightweight (though more expensive) turbine gennie as well as the traditional piston-diesel. It also means your battery/capacitor bank doesn't need to be especially large, thus cutting down on cost significantly.
I never use it. Being the owner of a keyboard, I simply press the perfectly good button on that.
Besides, the start button is still there, it's simply hidden under a hot corner. Move your mouse to the same place you would normally, and click as normally, and you still still perform the same action as in older versions of windows. Of course, the menu is replaced with the start screen, but that's another matter.
Which is why I've always considered high-frequency trading to essentially be a timing attack on stock market servers.
Instead, modify the sensors on existing CIWS to target speedboats.
Already done. The Phalanx Block 1B has an added FLIR sight to aid aiming at surface vessels.
'Retina' isn't even correct. Your eye is not a camera, and does not function in the same way. The "~100ppi" figure may work for discriminating between separate pixels, but is insufficient for vernier acuity.
The difference is paying for something that will probably work most of the time with a bit of fiddling occasionally, and something that can be put in a crate, bounced around on rough seas in wildly varying temperatures for a few months/years, then be pulled out by someone with a small pamphlet of basic instructions and still work.
Hold the Ctrl key, and the ribbon menu will display the keyboard shortcuts associated with each icon. It's a very nice way to learn them.
I'd take issue that "user actually has to read the damn instructions" is somehow entrenching a monopoly position. Microsoft has pulled some dodgy things, but this isn't one of them.
It depends on where the problem lies: If the game is using the directX (or openGL) libraries correctly but the driver is mucking things up, then the game developer should not need to code around driver bugs. Conversely, if the game developer is using a 'clever hack' to eke out some more performance, this creates a headache for the driver developers to keep this hack working in one instance but stop it working for things written to the word of the API in other instances.
Not true at all. The big barrier is the shipping costs: once you can get stuff up there, the actual living in space bit is almost trivial with all the work already done on it. That's why Space-X's low launch costs are so exiting: cheaper launchers means more launches, and more launches means cheaper launchers (through mass production). Combined with their plans for partially and fully reuseable stages, they could eventually drive launch costs down towards fuel costs.
A better analogy would be attempting to build a 747 today, but stipulating that all parts and tools must first be carried to the factory from the other side of the planet by hand.
Because you can :
a - Choose not to use Secure Boot, and run whatever the hell you want (i.e. the current situation with regular BIOS and UEFI)
b - Add your own key to the mobo, and sign your distro with it.
Both of these are predicated on buying a motherboard or pre-built that allows you to do so. The onus is on the manufacturer to allow you to do stuff with Secure Boot, the microsoft requirements (for non-ARM architectures) do not require Secure Boot be fully locked, only that the default setting is "boot Windows 8 securely".
Most expensive, maybe, but best? Not if your goal is a transparent amplifier: one that takes an input, and reproduces that output as accurately as possible with a higher amplitude. Valves suck at this. An entire branch of mathematics (control theory) was developed to compensate for the horrendous non-linearities of vacuum tubes.
You may like the distortions produced by tube amps (or transistor amps outputting those same distortions via DSP), but don't pretend they're better at reproducing sound. They are demonstrably not.
Do you have anything conclusive that proves official sources (i.e. the IAEA and NISA) have reported anything incorrectly (or without later publishing the correction)? Media reporting inside of and outside of Japan swung wildly between "everything is fine" and "next Chernobyl?!?!?" with dizzying rapidity and little provocation. And I mean 'proof' other than dodgy blogs citing the-Geiger-counter-I-built-myself-but-never-had-calibrated.
They were aiming for in-expensive which means cutting corners.
The 'Pi can play 1080p h.264. At High Profile level 4.1 too, which means unfettered BluRay streams, not just main-profile low-bitrate transcoded video (as is usually the case with cheap devices advertising 1080p decode support).
This is cheaper, because it only needs 3 servos for the entire arm, rather than 3 for each arm segment, and still maintain independent segment motion. You can lock (jam) all arm segments, release one for motion, move it (reshape that segment) while keeping the others rigid, then lock it again.
The bytes on the NAND itself are encrypted and have not guarantee whatsoever of being contiguous. Even if you have a mythical public-key-breaking quantum computer at your disposal, you'd still need to arrange a few gigabytes of 4kb blocks (pages) into the correct order just to get the ciphertext to start with.
You appear to have fallen to the age-old (or rather, about 15 year old) myth that there is a readable 'echo' of a bit after it has been overwritten. This is false, and has been ever since the magneto-resistive head was introduced (and especially the GMR head around 2000). Even with a magnetic force microscope you're not going to be reading squat other than the current bit value (or rather, the current analogue value that would then have to be processed along with the preceding and following values into what is probably the bit that you wrote). While it may have been true - in the days when a R/W head actually had a little coil of wire in it and capacities were measured in megabytes - that you could throw a few hundred engineers at a platter with a MFM and maybe recover a little bit of coherent data, that is no longer true. The amount of data you'd need to comb through if you could recover it perfectly (which you can't) is so immense that you'd need an army working 24/7 for decades. Even if you knew the precise data you were looking for and it's precise location on the platter, if you wrote a single zero pass over that location no MFM would be able to read anything useful, or the same head that was used in the MHM would be used in HDDs and you;d be back to square one.
The ATA SECURE ERASE command tells the head to write zeroes over the entire surface of the platter. Regular write-random-crap-a-bunch-of-times software such as DBAN fail to erase sectors in the G-list, which could subsequently be recovered (albeit unlikely to contain anything interesting). it won't erase sectors in the factory P-list, but nothing was ever written there in the first place. This is sufficient to make any data that was on the drive totally unrecoverable. Hell, ATA SECURE ERASE is NIST-approved for government and military data destruction at the same level as physical destruction of the platters.
More like years rather than months unless you're pumping through terabytes of data a day. The point is moot, however: SSDs do not store data continuously like HDDs do: your data can be spread across blocks, across chips, compressed AND encrypted all at the same time. Take out the allocation table, and all that data is now randomly arranged bits. And because erased data on NAND is truly erased*, you just need to wipe that little bit of memory to effectively securely erase the whole SSD. If you wanted to be hilariously over-cautious, keep your allocation table on fast volatile memory.
* This is also true for any HDD in the last decade or two if you run ATA SECURE ERA SE command. All those fancy multi-pass erasers and mechanical destroyers are essentially pointless.