On eMule, people usually rename files and keep them shared under a more descriptive name so the next people who download it can see alternate names come up when checking file details. If all people who downloaded a fake removed it at once, there would no longer be any internal indication of the file's fakeness. Of course, the same trick can also be used to make people think they got the wrong file.
That's right. The lyrics are in the song and a trained ear can get them off the stupid song unless the singing is so bad or trampled by "background noise" that lyrics become the only way to figure out exactly what was said.
For sheet music, I wonder what percentage of the studio's customer base actually gives a damn about them. Almost everyone may have an interest in music, 10% of people may have an interest in lyrics beyond finding a song or clarifying parts of them but sheet music? Probably well under 1%.
Well, I have learned that common sense and smart decisions are deprecated in the upper levels of the entertainment industry. The major labels/studios are too big for their own good, they lost sight of what their real objectives should have been and now they are well on their merry way to self-destruction through customer base alienation. Tunnel vision is dangerous.
All we need now is consumer-grade CRT-based TVs to survive the next 30-40 years and see how much this will affect them over time.
It is true that the first TVs were highly sensitive to the Earth's magnetic field to the point of needing re-tuning whenever the TV was moved but I seriously doubt modern CRTs (most things made over the last ~30 years) would have significant issues with that - try turning your TV around to simulate a pole inversion and see what happens.
In any case, most of these will have long been replaced by LCD/OLED/LEP/SED displays by then.
Whenever I tried an anti-virus, they caused performance degradation far worse than any spyware I ever caught and never found any virus so I always uninstall anti-virus software as soon as I am done with my occasional scan - new versions will be out by the time I scan again anyway. As for spyware and the rest, I now usually install and test software on a spare PC before putting it on my laptop and primary desktop - worst case I can simply re-image the spare PC's drive if something nasty came up.
The best anti-everything tools are common sense and knowledge, they make anti-virus&all almost completely redundant and a total waste of CPU/RAM/money/time.
I have never tried synthesis of a large multiple-ported register file on FPGA but I suspect it has very limited practical scaling. At the very best, it would require monstrous multiplexers. Guess I'll have to try it and see what happens with a 128x32bits 8xRead+4xWrite (12 addresses) register file - I will not be expecting anything usable. (IIRC, UltraSPARC is actually 512x64.)
As for FPGAs being better CPUs than CPUs can be FPGAs, this is pretty obvious given that FPGAs can do everything in parallel almost exactly like ASICs do while a CPU has to emulate all that parallel logic serially.
A microcontroller is not exactly in the same complexity league as a superscalar general-purpose 32/64bits CPU. Most microcontrollers are in-order, single-threaded, use internal program and data memory, have very tight per-instruction timing, fairly simple internal architecture and rarely need to access more than 2-3 internal registers simultaneously for any given OP since they only issue one OP every 1-3 cycles, this does not pose a major problem to FPGAs since a triple-ported register file is still quite manageable. Superscalar pipelined CPUs need much beefier register files since general-purpose CPUs have more complex addressing schemes, need to read up to three register for every issued OP and often needs to write a result at the end of the pipeline... if a CPU can issue four instructions per clock, its register files need to have at least octuple read ports and quad write ports to avoid frequent stalls due to register file contention, a construct that would be a major issue on FPGAs since most are designed for dual-ported registers, multi-port reading can be done via register duplication but there is no direct way of doing multi-port writes.
Microcontrollers on FPGA is feasible and practical because most are simple in-order, non-superscalar and non-pipelined, this makes them much more compatible with FPGAs' dual-ported registers. Anything significantly more complex than that will quickly become costly.
Try fitting a P4 or UltraSPARC in a Virtex4-1xxLX, you are going to run into several problems.
1) The ASIC runs at 1GHz+ frequency, the V4 implementation would run around 300MHz at best and cost over $10k for the FPGA alone. 2) Most FPGAs block-RAM and LUT-based RAM can be dual-ported at most, this is problematic for register files where a dozen registers may be concurrently accessed during any given cycle. This would require either register duplication or time-multiplexed register access and a corresponding down-clocking of everything else. 3) Logic is expended pretty fast if you do stuff like 64x64 multipliers using logic only. Sure, there are dedicated multipliers in most modern low-cost FPGAs but these are hard-wired to handle DSP-centric MAC operations. 4) People are upset with desktop CPU's power usage but building similar CPUs on FPGAs would require many times more power to achieve the same performance since FPGA's switch fabric and general-purpose programmable elements have way more parasitic capacitance than ASICs' internal hard-wired traces and circuits. With ASIC, 1M logic gates is only ~6M transistors but a ~1M gate-equivalent FPGA with switch fabric and configuration bits goes beyond 50M transistors with much longer routing delays.
FPGAs are not particularly suitable for general-purpose processing where the system has extensive subsystem interdependencies and shared elements. Where they can truly shine is in applications where the data flow is mostly regular and where processing can be broken down into well-defined self-contained stages like telecom, crypto and DSP. Another area where FPGAs can shine is hard-realtime where they can have dedicated logic to handle time-critical events with 100% deterministic deadlines, unlike modern CPUs and OSes where realtime applications have to put up with unpredictable branch mispredicts, cache misses, preemption, out-of-order execution, etc.
That said, the UltraSPARC's verilog source should make for really interesting reading for logic and digital system engineers and academics like myself. This move makes a lot of sense: CPU designers need to hire new talent and this new talent needs to learn about common practice in real-world designs to be of any use or they'll spend most of their first months just catching up. With a real-world design in the wild, CPU-designer job postings could ask people to specify which architectural components they would like to improve and the interviews could steer towards presenting those improvements instead of often irrelevant technicalities.
$15B would not be such a big deal for Intel... it already spends bilions in process research, spends many more building experimental fabs and production lines, it already has two working 65nm fabs with two others being upgraded from 90nm to 65nm during 2006 and many more at 90nm. With Intel's volume, a single 10nm fab may be insufficient for itself, I do not think they would share - at least not until they got a second or third one. Since unused 10nm fab capacity would be expensive, I would not be surprised to see a pattern of owning only as many fabs as necessary to meet sustained demand and outsource the rest - it makes no sense to spend $10B on a fab capable of producing a bilion chips per year when all that is needed is an extra 200M units per year.
Like you said though, most other IC firms have insufficient high-speed, high-density IC volumes to make building their own bleeding-edge fabs make economical sense, we have already seen this pattern with coop fabs (AMD/IBM/Motorola for the K7 debut while AMD was nearly bankrupt) and from the rise of fabs-for-hire like UMC and TSMC. When fabs become too expensive and high-capacity, foundry JVs and coops will become necessary - production lines have to run near full capacity 24/7 since it costs milions to stop and restart them.
I vaguely remember reading an article in a computer magazine nearly ten years ago where the writer pinned Moore Law's (transistor count doubles every 18 months) demise to be around 2010 and the practical limit at 10-15nm. So far, that prediction appears to be reasonably on-target.
I did guess it was a joke but still felt like writing something.
For the RAID0 mixup, that was a lapsus in the first paragraph. For the bank scenario, my thought behind 0 on 6 is that an hypothetical thief would have to steall all R6 arrays to have a complete data set.
RAID1 on RAID5 would only allow one failure in each set... RAID5 on RAID0 would allow at least two and up to six with 10 drives - but even RAID5 on RAID5 will still not give you anything anywhere near as strong as RAID6's error detection and correction on a reliability to drive-count ratio.
Composite RAID sounds sexy but RAID6 is cheaper and more resilient. Its only significant issue is that error correction is a lot more computationally expensive than RAID5's dirt-cheap XORs. The composite R6 of R5s or R0/R5 of R6s would be nice for banks and other such where each set could be stored in a separate vault to protect them from each other in case of any array catching fire or one of them being stolen. Now we're talking extreme (but justifiable) paranoia.
The official line some years ago was that Intel did not want to lock their CPUs into single standards. By decoupling the CPU from the memory controller, Intel allows 3rd party manufacturers to make bridges that can enable coupling any Pentium/Celeron with any RAM anybody may bother asking for. With built-in controllers, it is impossible to efficiently use anything other than what is directly supported by the CPU.
Things may change after FB-DIMMs become common... put 16xFBDIMM channels on the CPU and let the MoBo manufacturer put whatever bridges they feel like putting on-board for whatever memory standard they feel like supporting - or just put native FBDIMM slots and sell DDR/DDR2/DDR3/etc. riser cards with the necessary FBDIMM PHY/MAC chip to let people use the non-FBDIMM RAM of their choice.
Having one-liner comments all over the place makes comment maintenance more troublesome and can distract from actual comprehension of what is going on while reading the code, particularly when there are bits of orphaned antique leftover comments. A single comment blob before a function or large code sections tells the reader about the spirit of code to come without interfering with reading beyond there and makes it easier to maintain comment coherence when changes are made.
For more convoluted code, I often add blobs before major loop/switch/etc. too - adding comments while I write these things takes less time than what it may take me to re-read the code until I remember exactly what it does and how. (inputs, outputs, side-effects, etc.)
Right now, RAID6 is starting to gain popularity in high-availability environments.
With basic RAID5, the array can handle a single drive failure and can only detect odd errors with no possibility of correcting them. With RAID5+1, a hot-spare is available to start unattended rebuild when a failure occurs but costs and extra drive while still leaving the array vulnerable to a second failure during the rebuild process. With RAID6, error-correcting codes are generated for the N extra (non-data) drives to provide N/2 bits error correction, multi-bits error detection and recovery of up to N erasures/failures.
RAID6 is more computationnally expensive than RAID5 but it can be made arbitrarily resilient to subtle soft errors typical RAID5 would never detect. An external box 6xSATA/NCQ RAID6 with SATA-3G-uplink storage controller would be a nice companion for anybody who takes data integrity seriously but does not want to do TB-scale backups. (Of course, this still leaves data vulnerable to infection-induced or otherwise accidental trashing.)
1/8W dissipated in a 1kW resistor is still 1/8W, the 1kW resistor will only be much cooler.
Your post only said they substituted 1kW resistors where 1/8W resistors would have done the job, that explains the brick's size but not the overheating... that's where my linear regulator 'theory' came in.
Since this specific problem class is heat-related, I would recommend waiting until next September before concluding that brick malfunctions are isolated issues.
With some aging and temperature spikes, I am expecting many more "isolated" cases to come up.
Being dumped behind furniture or other stuff is the life of a power brick, let's see how well they'll surf heat waves.
Using larger resistors of the same value will make the thing cooler because it has more surface area to dissipate the heat.
Maybe M$ used linear regulators combined with non-regulated switchers.
Had they used/designed a more efficient PSU, they would most likely have been able to fit it incide the main case by making it an inch-or-so taller... I have seen many PSUs in the 100W area that are only a 3-5 cubic inches in volume, an efficient built-in 200W single-rail (12V) open-frame PSU should add less than 8 cubic inches to the 360's size and about 25W to the box's heat output - I am presuming the 360 uses local regulators so it would make sense to have 12V bulk distribution, add up to a cubic inch and 10W if not.
Note: 200W is only a guess, I have no idea what the 360 brick's rating is and have no plan to buy one to find out.
If the ID is used for crypto, I think I would implement this programming procedure: 1) Program the fuses with ID# and S# 2) Read them back 3) Program the readback-disable fuse so the ID# can no longer be read back 4) Try reading the fuses again - should return garbage for ID# 5) Encrypt the test firmware image with the S#ID# and run the tests 6) Add the S# and ID# of working chips to the production database so firmware images can be encrypted by service/support people in case of flash bombs
Each unit would require an individually encrypted initial bootloader. For Flash updates, I imagine the 360's CPU is put in a "lock-down" mode which disables RAM and JTAG controllers to prevent external observability, makes the ID# available to software again so the updated firmware can be re-encrypted and requires power cycling to resume normal operation to ensure all registers and SRAM are cleared, reducing the risk of leaks even if someone forgets to insert register/memory-clearing code in some short-lived firmware revision.
Short from breaking into the S#-ID# database, this would make 360 BIOS hacking a per-box key-finding job if firmware updates are encrypted with the box-specific S#+ID# pairs at the source.
If I need to go downtown, I use the bus... one express bus line has a stop 200m from my apartment and it takes me there sort-of directly. It takes 10-15 minutes more than going by car but at least I do not have to waste 10-15 minutes finding a parking spot.
But public transportation is far from being so nice when my destination is some distance beyond the metro core... the distance is about 20 miles on the map, 30 miles on highways and over 50 miles with USB's anagrams.
At least there are free newspapers to keep me occupied throughout the morning and some of the return trip.
Moving closer would roughly double the rent or halve my living space or something in-between. Unless I compromised on space, buying a ~50MPG car (Yaris/Smart) would still make economical sense until gas reaches something like $5/gal.
Slashdot Mirror
On eMule, people usually rename files and keep them shared under a more descriptive name so the next people who download it can see alternate names come up when checking file details. If all people who downloaded a fake removed it at once, there would no longer be any internal indication of the file's fakeness. Of course, the same trick can also be used to make people think they got the wrong file.
Fakes are an annoying part of P2P life.
Don't just turn your TV around... Turn it upside down... remember the Earth is round
Yeah, sure... I may as well try face-up/down while I'm at it... no difference on my ~15 years old Sears-branded Hitachi.
That's right. The lyrics are in the song and a trained ear can get them off the stupid song unless the singing is so bad or trampled by "background noise" that lyrics become the only way to figure out exactly what was said.
For sheet music, I wonder what percentage of the studio's customer base actually gives a damn about them. Almost everyone may have an interest in music, 10% of people may have an interest in lyrics beyond finding a song or clarifying parts of them but sheet music? Probably well under 1%.
Well, I have learned that common sense and smart decisions are deprecated in the upper levels of the entertainment industry. The major labels/studios are too big for their own good, they lost sight of what their real objectives should have been and now they are well on their merry way to self-destruction through customer base alienation. Tunnel vision is dangerous.
All we need now is consumer-grade CRT-based TVs to survive the next 30-40 years and see how much this will affect them over time.
It is true that the first TVs were highly sensitive to the Earth's magnetic field to the point of needing re-tuning whenever the TV was moved but I seriously doubt modern CRTs (most things made over the last ~30 years) would have significant issues with that - try turning your TV around to simulate a pole inversion and see what happens.
In any case, most of these will have long been replaced by LCD/OLED/LEP/SED displays by then.
At least you can afford a laptop and a spare PC.
Geeky people who have had PCs for ~20 years tend to accumulate lots of spare parts.
Pretty much the same here.
Whenever I tried an anti-virus, they caused performance degradation far worse than any spyware I ever caught and never found any virus so I always uninstall anti-virus software as soon as I am done with my occasional scan - new versions will be out by the time I scan again anyway. As for spyware and the rest, I now usually install and test software on a spare PC before putting it on my laptop and primary desktop - worst case I can simply re-image the spare PC's drive if something nasty came up.
The best anti-everything tools are common sense and knowledge, they make anti-virus&all almost completely redundant and a total waste of CPU/RAM/money/time.
I have never tried synthesis of a large multiple-ported register file on FPGA but I suspect it has very limited practical scaling. At the very best, it would require monstrous multiplexers. Guess I'll have to try it and see what happens with a 128x32bits 8xRead+4xWrite (12 addresses) register file - I will not be expecting anything usable. (IIRC, UltraSPARC is actually 512x64.)
As for FPGAs being better CPUs than CPUs can be FPGAs, this is pretty obvious given that FPGAs can do everything in parallel almost exactly like ASICs do while a CPU has to emulate all that parallel logic serially.
BTW, IAAFAAVE. (V = Validation)
A microcontroller is not exactly in the same complexity league as a superscalar general-purpose 32/64bits CPU. Most microcontrollers are in-order, single-threaded, use internal program and data memory, have very tight per-instruction timing, fairly simple internal architecture and rarely need to access more than 2-3 internal registers simultaneously for any given OP since they only issue one OP every 1-3 cycles, this does not pose a major problem to FPGAs since a triple-ported register file is still quite manageable. Superscalar pipelined CPUs need much beefier register files since general-purpose CPUs have more complex addressing schemes, need to read up to three register for every issued OP and often needs to write a result at the end of the pipeline... if a CPU can issue four instructions per clock, its register files need to have at least octuple read ports and quad write ports to avoid frequent stalls due to register file contention, a construct that would be a major issue on FPGAs since most are designed for dual-ported registers, multi-port reading can be done via register duplication but there is no direct way of doing multi-port writes.
Microcontrollers on FPGA is feasible and practical because most are simple in-order, non-superscalar and non-pipelined, this makes them much more compatible with FPGAs' dual-ported registers. Anything significantly more complex than that will quickly become costly.
Try fitting a P4 or UltraSPARC in a Virtex4-1xxLX, you are going to run into several problems.
1) The ASIC runs at 1GHz+ frequency, the V4 implementation would run around 300MHz at best and cost over $10k for the FPGA alone.
2) Most FPGAs block-RAM and LUT-based RAM can be dual-ported at most, this is problematic for register files where a dozen registers may be concurrently accessed during any given cycle. This would require either register duplication or time-multiplexed register access and a corresponding down-clocking of everything else.
3) Logic is expended pretty fast if you do stuff like 64x64 multipliers using logic only. Sure, there are dedicated multipliers in most modern low-cost FPGAs but these are hard-wired to handle DSP-centric MAC operations.
4) People are upset with desktop CPU's power usage but building similar CPUs on FPGAs would require many times more power to achieve the same performance since FPGA's switch fabric and general-purpose programmable elements have way more parasitic capacitance than ASICs' internal hard-wired traces and circuits. With ASIC, 1M logic gates is only ~6M transistors but a ~1M gate-equivalent FPGA with switch fabric and configuration bits goes beyond 50M transistors with much longer routing delays.
FPGAs are not particularly suitable for general-purpose processing where the system has extensive subsystem interdependencies and shared elements. Where they can truly shine is in applications where the data flow is mostly regular and where processing can be broken down into well-defined self-contained stages like telecom, crypto and DSP. Another area where FPGAs can shine is hard-realtime where they can have dedicated logic to handle time-critical events with 100% deterministic deadlines, unlike modern CPUs and OSes where realtime applications have to put up with unpredictable branch mispredicts, cache misses, preemption, out-of-order execution, etc.
That said, the UltraSPARC's verilog source should make for really interesting reading for logic and digital system engineers and academics like myself. This move makes a lot of sense: CPU designers need to hire new talent and this new talent needs to learn about common practice in real-world designs to be of any use or they'll spend most of their first months just catching up. With a real-world design in the wild, CPU-designer job postings could ask people to specify which architectural components they would like to improve and the interviews could steer towards presenting those improvements instead of often irrelevant technicalities.
$15B would not be such a big deal for Intel... it already spends bilions in process research, spends many more building experimental fabs and production lines, it already has two working 65nm fabs with two others being upgraded from 90nm to 65nm during 2006 and many more at 90nm. With Intel's volume, a single 10nm fab may be insufficient for itself, I do not think they would share - at least not until they got a second or third one. Since unused 10nm fab capacity would be expensive, I would not be surprised to see a pattern of owning only as many fabs as necessary to meet sustained demand and outsource the rest - it makes no sense to spend $10B on a fab capable of producing a bilion chips per year when all that is needed is an extra 200M units per year.
Like you said though, most other IC firms have insufficient high-speed, high-density IC volumes to make building their own bleeding-edge fabs make economical sense, we have already seen this pattern with coop fabs (AMD/IBM/Motorola for the K7 debut while AMD was nearly bankrupt) and from the rise of fabs-for-hire like UMC and TSMC. When fabs become too expensive and high-capacity, foundry JVs and coops will become necessary - production lines have to run near full capacity 24/7 since it costs milions to stop and restart them.
I vaguely remember reading an article in a computer magazine nearly ten years ago where the writer pinned Moore Law's (transistor count doubles every 18 months) demise to be around 2010 and the practical limit at 10-15nm. So far, that prediction appears to be reasonably on-target.
I did guess it was a joke but still felt like writing something.
For the RAID0 mixup, that was a lapsus in the first paragraph. For the bank scenario, my thought behind 0 on 6 is that an hypothetical thief would have to steall all R6 arrays to have a complete data set.
RAID1 on RAID5 would only allow one failure in each set... RAID5 on RAID0 would allow at least two and up to six with 10 drives - but even RAID5 on RAID5 will still not give you anything anywhere near as strong as RAID6's error detection and correction on a reliability to drive-count ratio.
Composite RAID sounds sexy but RAID6 is cheaper and more resilient. Its only significant issue is that error correction is a lot more computationally expensive than RAID5's dirt-cheap XORs. The composite R6 of R5s or R0/R5 of R6s would be nice for banks and other such where each set could be stored in a separate vault to protect them from each other in case of any array catching fire or one of them being stolen. Now we're talking extreme (but justifiable) paranoia.
The official line some years ago was that Intel did not want to lock their CPUs into single standards. By decoupling the CPU from the memory controller, Intel allows 3rd party manufacturers to make bridges that can enable coupling any Pentium/Celeron with any RAM anybody may bother asking for. With built-in controllers, it is impossible to efficiently use anything other than what is directly supported by the CPU.
Things may change after FB-DIMMs become common... put 16xFBDIMM channels on the CPU and let the MoBo manufacturer put whatever bridges they feel like putting on-board for whatever memory standard they feel like supporting - or just put native FBDIMM slots and sell DDR/DDR2/DDR3/etc. riser cards with the necessary FBDIMM PHY/MAC chip to let people use the non-FBDIMM RAM of their choice.
When it is not socket, it is VRM... going from NW to Prescott on S478 or single-core to dual-core on LGA775.
Same for me.
Having one-liner comments all over the place makes comment maintenance more troublesome and can distract from actual comprehension of what is going on while reading the code, particularly when there are bits of orphaned antique leftover comments. A single comment blob before a function or large code sections tells the reader about the spirit of code to come without interfering with reading beyond there and makes it easier to maintain comment coherence when changes are made.
For more convoluted code, I often add blobs before major loop/switch/etc. too - adding comments while I write these things takes less time than what it may take me to re-read the code until I remember exactly what it does and how. (inputs, outputs, side-effects, etc.)
Right now, RAID6 is starting to gain popularity in high-availability environments.
With basic RAID5, the array can handle a single drive failure and can only detect odd errors with no possibility of correcting them. With RAID5+1, a hot-spare is available to start unattended rebuild when a failure occurs but costs and extra drive while still leaving the array vulnerable to a second failure during the rebuild process. With RAID6, error-correcting codes are generated for the N extra (non-data) drives to provide N/2 bits error correction, multi-bits error detection and recovery of up to N erasures/failures.
RAID6 is more computationnally expensive than RAID5 but it can be made arbitrarily resilient to subtle soft errors typical RAID5 would never detect. An external box 6xSATA/NCQ RAID6 with SATA-3G-uplink storage controller would be a nice companion for anybody who takes data integrity seriously but does not want to do TB-scale backups. (Of course, this still leaves data vulnerable to infection-induced or otherwise accidental trashing.)
I'm lazier than you are, I would have given 3M as an example instead.
If they do letters, they will probably do numbers as well. That's 10 more options for each TLD.
As a fellow introvert, I'll only add this: exactly.
1/8W dissipated in a 1kW resistor is still 1/8W, the 1kW resistor will only be much cooler.
Your post only said they substituted 1kW resistors where 1/8W resistors would have done the job, that explains the brick's size but not the overheating... that's where my linear regulator 'theory' came in.
Since this specific problem class is heat-related, I would recommend waiting until next September before concluding that brick malfunctions are isolated issues.
With some aging and temperature spikes, I am expecting many more "isolated" cases to come up.
Being dumped behind furniture or other stuff is the life of a power brick, let's see how well they'll surf heat waves.
Using larger resistors of the same value will make the thing cooler because it has more surface area to dissipate the heat.
Maybe M$ used linear regulators combined with non-regulated switchers.
Had they used/designed a more efficient PSU, they would most likely have been able to fit it incide the main case by making it an inch-or-so taller... I have seen many PSUs in the 100W area that are only a 3-5 cubic inches in volume, an efficient built-in 200W single-rail (12V) open-frame PSU should add less than 8 cubic inches to the 360's size and about 25W to the box's heat output - I am presuming the 360 uses local regulators so it would make sense to have 12V bulk distribution, add up to a cubic inch and 10W if not.
Note: 200W is only a guess, I have no idea what the 360 brick's rating is and have no plan to buy one to find out.
If the ID is used for crypto, I think I would implement this programming procedure:
1) Program the fuses with ID# and S#
2) Read them back
3) Program the readback-disable fuse so the ID# can no longer be read back
4) Try reading the fuses again - should return garbage for ID#
5) Encrypt the test firmware image with the S#ID# and run the tests
6) Add the S# and ID# of working chips to the production database so firmware images can be encrypted by service/support people in case of flash bombs
Each unit would require an individually encrypted initial bootloader. For Flash updates, I imagine the 360's CPU is put in a "lock-down" mode which disables RAM and JTAG controllers to prevent external observability, makes the ID# available to software again so the updated firmware can be re-encrypted and requires power cycling to resume normal operation to ensure all registers and SRAM are cleared, reducing the risk of leaks even if someone forgets to insert register/memory-clearing code in some short-lived firmware revision.
Short from breaking into the S#-ID# database, this would make 360 BIOS hacking a per-box key-finding job if firmware updates are encrypted with the box-specific S#+ID# pairs at the source.
If I need to go downtown, I use the bus... one express bus line has a stop 200m from my apartment and it takes me there sort-of directly. It takes 10-15 minutes more than going by car but at least I do not have to waste 10-15 minutes finding a parking spot.
But public transportation is far from being so nice when my destination is some distance beyond the metro core... the distance is about 20 miles on the map, 30 miles on highways and over 50 miles with USB's anagrams.
At least there are free newspapers to keep me occupied throughout the morning and some of the return trip.
Moving closer would roughly double the rent or halve my living space or something in-between. Unless I compromised on space, buying a ~50MPG car (Yaris/Smart) would still make economical sense until gas reaches something like $5/gal.