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.

Easy access to credit plays a big part of the equation. Newly borrowed money creates demand, income, jobs and economic growth. Of course exponential growth cannot be sustained. Eventually paying back or defaulting on that credit will destroy demand, income, jobs and economic growth.

Most of the companies that built rail, went bankrupt. After they were built, nobody was willing to pay the rent they needed to break even. Sometimes construction should be paid for from general tax revenue, because nobody can make money from it.

Using https everywhere does have some downsides, things like Javascript that contains executable code is either cachable or secure from MITM tampering. Why don't we have a way to sign content without encrypting it?

Unintended consequences. We want people to be able to afford houses, so we give them a grant so they can pay a deposit. What happens? Everyone goes to the bank with their $7K, the bank manager gives them 95% LVR and allows them to borrow $140k more. Then they go and find the house they want, and offer what the bank manager said they could. End result? House prices go up and housing ends up *less* affordable.

A couple of little easter eggs in bespoke software;

Hold a couple of modifier keys and click on the icon in the about dialog, "The developers [names] would like to present you with a complimentary cup holder" followed by opening the CD ROM tray. Every new developer checked in a change with their own name once they'd passed their probationary period.

Leave the about dialog open for 5 minutes, the dialog goes black and the developers names start floating around like the game asteroids. Click on a letter and it will disappear, splitting the name in half. With both parts moving slightly faster. Probably should have made it slightly hard to start though. The customer had a ball, but the manager was not happy.