The housing bubble did actually stimulate the economy. Not because of construction, but because we borrowed all of that money from the banking sector, then spent it to keep the economy going.

But what goes up, must come down. It's inevitable that when we collectively try to pay back (or are forced to default on...) our mortgages, our income and money supply will shrink. Austerity policies will hasten the inevitable.

Yep. I'd be on board, IFF this list had nothing with more than the 10% GST markup.

Pointing out a flaw in someone else's software should not, by itself, be a criminal act. Once the information is public, automating the exploit could be done by anyone proficient in the art.

But selling a tool that uses the vulnerability? They crossed a line, but throwing the book at them seems a little harsh.

Use the same USB trick, but run your OS in a VM under the TreVisor hypervisor. When the USB device is removed simply put the machine to sleep.

TreVisor only stores your encryption key in the debug registers of the processor. It places restrictions on running op-codes to read these registers or to overwrite itself via DMA. It encrypts both the disk and inactive pages of memory.

Once the CPU suspends, the debug registers are lost and you have to enter your passphrase before the guest VM can do anything at all.

A junior programmer fresh out of Uni, joining my team. Learning a new language / framework / application, working full time. Will usually take more of my time to help them than if I just wrote the code myself. I have to explain which existing functions they should use. I still have to flesh out most of the design and implementation of the tasks they are assigned. I may need to take over their keyboard and type some of the code in for them, as the fastest way to get the point across that I'm trying to teach them. And getting their patches up to scratch can take a number of iterations.

After about 3 months, this equation should start to shift. Even though they will still take far longer to complete a task than I would, it should take less of my time to get the same work done. At this point, the addition of someone to the team starts to pay back the initial training period. We can evaluate if this new person is still worth investing time in.

And that's for the graduates that I'd consider hiring in the first place. Most CompSci graduates I wouldn't consider employing at all.

Yeah, I've noticed the FOSS driver basically freezes when I move my mouse over VNC with debian testing. But 3D gaming works well enough that I don't notice any difference. Not saying there isn't any, just that the FOSS drivers are good enough for me now.

They're playing a set number of hands, or for a set amount of time. So there's no chip limit.

If you look at the video posted yesterday, the rocket was coming down straight. Then it deliberately tipped itself over, shed the last of it's vertical and horizontal velocity, and tried to right itself. IMHO, if more of the horizontal velocity was shed earlier, It'd be easier to stay balanced at the end.

And I'm not telling you where...

When the rocket booster has already done it's primary job and would otherwise be lost anyway. The only real loss is the damage to the barge.

Grab one of the available databases of hacked passwords. Train an arithmetic compressor on that dataset, so that if any part of the password is predictable it will be compressed better. It's the kinds of statistics you feed into this training process that are the key. Passing a random bit-sequence through your decompressor will generate something that could be a password, similar to those in the database you trained on. So enumerate through all short bit-patterns to generate a set of easily guessed passwords.

C# -> MSIL / CIL (CLR) -> LLVM bitcode -> machine code.

The summary is slightly misleading. Though they are working towards using LLVM, they currently have about 90% of their core JIT tests working with LLVM on windows x64, the rest fall back to their current JIT. So you won't be able to use this to run C# on linux / arm for a while yet.

There's been quite a bit of recent development on JIT support in LLVM. They had an old JIT a few versions ago which had it's own machine code generation pipeline. This was replaced with MCJIT, that leveraged the same code generation pipeline as the AOT path. More recently there's an effort called ORC to build a more flexible API to better handle the use cases that various JIT writers typically wish to implement. Their existing MCJIT API will still exist but it will become just one example implementation of using this underlying API.

While it is possible to implement garbage collection and exception handling in LLVM, these areas of the compiler could benefit from more improvement. Particularly in the area of compatibility with the native Microsoft stack.

So you don't like UAC, but you want there to be some things that a user can't change? But that's exactly what UAC is *for*. Preventing users from changing system settings. What, you want more than one kind of admin user?

Yes, a regulated monopoly, that is forced to do business with everyone equally.

Or you could copy something like Australia's NBN model. A single wholesaler builds and maintains the cables. They *must* run a cable if required for anyone in their service area. But they are only allowed to offer and charge for a link layer transport between end points. Any ISP can then include the rent of the link in the price for internet access and other services for their customers.

Though of course the NBN has screwed up. They bowed to pressure from the incumbents in a number of ways that made running a small ISP unprofitable. They based the pricing of link capacity on the current cost of bandwidth over existing services. And the new government has been trying to compromise the quality of the network by building curb side nodes instead of running fiber end-to-end.