Sure such a system works well for slow moving carts but i'm not sure it would work so well for a car. For best milage you really want to avoid actively braking (even regenerative) as much as possible. Your proposal would make it very difficult to express to the car "I want to coast not actively putting power in but not actively taking it out either".

I'd also be worried about whether a speed pedal would be fine enough control to correctly select the desired speed over the wide range a car operates over.

And that whole range can be blocked in one go.

What matters for avoiding blocks is not merely having lots of addresses, it's having lots of addresses spread out through the address space so that people can't effectively block you without either causing massive collateral damage or painstakingly hunting down your addresses.

Another approach is to create fictional IDs with generic email addresses (gmail or similar), create keys for the fictional IDs and get them signed. Then use the keys associated with fictional IDs to sign the keys you plan to use for impersonation.

This is more work than just having shady people use their real IDs to sign the impersonation keys but reduces the risk of your accomplices being found out.

Ever noticed how intel have recently been using misleading part numbers to make it less obvious that their high end parts are a generation behind their mainstream parts?

I've pushed a cheap multimeter to the point it was showing "reading off scale" on the 1000V range and it didn't explode.....................

Afaict the problem with these cheap meters is not that they can't read 1000V safely in a low energy environment, it's that power distribution systems have large ammounts of energy available combined with spikes that go well over the nominal voltage. The spikes can blow out a cheap meter and then massive ammounts of energy can flow through the arc that the spike created.

Having said that a good set of fused test leads with HRC fuses will give you a lot of protection even if your meter is crap.

You could also buy machines that had a windows vista buisness (or ultimate if you wanted to throw money away) license but had XP pro installed under downgrade rights.

It sounds like your problem was not that you were using windows but that you had a crappy contract with your vendor that was somehow tying the version of windows you were running to the replacement of your hardware far more closely than it needed to be.

16GB regsitered ECC DDR3 server modules are only $158 according to newegg but at least on the intel side you need a server board and CPU to use them.

16GB unregsitered non-ecc desktop DDR3 modules are another matter. Afaict only one specialist manufacturer has announced that they are making them and when I google the part number they list I don't find anywhere actually selling it. Also from what I have read the standard init code that intel gives to bios manufacturers doesn't support 16GB modules and it is unclear whether it will ever be updated to do so.

Note that regsitered ECC modules can be quad rank while desktop modules are limited to dual rank. So a 16GB server module needs 4Gb chips while a 16GB desktop module needs 8Gb chips. A 32GB server module uses 8Gb chips and costs about $750 according to crucial which IMO gives a clue as to how expensive 16GB desktop modules are likely to be if and when they become available for purchase.

I'm not convinced of that, there may be a handful of apps that are written directly to target wayland or mir but for the most part I would expect apps to continue to use toolkits like qt and gtk which afaict will support multiple backends.

Apps that use x directly or use an older/more obscure toolkit that only has an x backend will be supported on mir and wayland through thier x compatibilty layers.

The thing is when you look more closely you find that most of those processes are spending most of their time asleep. So there is little to be gained from more than 2 cores (one for the program you actually care about, one for the background crap) unless the program you actually care about can effectively spread it's work across multiple threads*.

* There are a lot of processes that have multiple threads but only use one of them at a time to do significant work.

Memory is fairly cheap (though if you really want lots of memory in addition to the cost of the memory itself you have to consider the cost of the platform to accomodate that memory) but cache, particulally the lower levels of cache that are closest to the CPU isn't so cheap, if you have a pointer-heavy workload (e.g. data structures that are mostly cross-references implemented using pointers) then you can fit a lot less of your workload in cache with .64-bit pointers.

For java (which is very pointer heavy) this was so bad that they implemented tricks in the VM so that if the java heap size is below a certain level then "ordinary object pointers" can be stored in 32-bits.

On linux there is something out there called x32 which aims to combine the advantages of the 64-bit processor mode with the advantages of 32-bit pointers but it's unclear if it will ever catch on.

If you had left off the + then you would have been more on the mark. The largest reasonablly available modules of desktop memory are 8GB and the most slots you will find in a mainstream desktop board is 4 (and many boards only have two). If you want to go over 32GB you have to move to the high end desktop platform (and if you want to go over 64GB you have to move to workstation/server platforms).

I suspect it will be a pain when the platform first comes out but in time 16GB desktop DDR4 modules will become affordable while I doubt 16GB desktop DDR3 modules ever will (if the boards even support them)

Define "Enthusiast mobos", there are plenty of LGA2011 desktop boards with 8 dimm slots.

That's EP not E, it wouldn't surprise me if ddr4 desktop memory only supports 1 dimm per channel while registered ECC DDR4 server memory supports more. Just as with DDR3 the desktop stuff maxed out at two dimms per channel while the server stuff went up to three dimms per channel

It makes sense for a couple of reasons

1: Intel desperately want to stop the portable computing market moving away from laptops and laptop-like tablets towards smartphone-like tablets. To do that they need to get the most power efficient technology possible into ultrabooks and ultrabook-like tablets.
2: Making a design work properly with 2-4 cores on one chip for laptops and mainstream desktops is a lot simpler than making it work properly with 8+ cores and inter-chip links for a server part (and the high end desktop parts are basically server parts with the inter-chip links disabled and overclocking enabled).

It is a pain to the high end desktop users who have to choose between a low end platform and a core design that is a generation behind and as such it probablly cuts into intel's high end desktop sales but ultimately those high end desktop users are a small part of the market.

Yes and no, you can write fast efficient code in java but you have to fight the language to do so. In particular java lacks both user defined value types and parameter pass by reference. The obiovus way round this is to just create objects on the heap willy nilly thereby creating a load of extra work for the GC. There are more efficient methods (using paralell arrays, passing in an object purely so the next level down of functions can use it as parameter passing space) but they all make your code uglier and less maintainable.