Ugh. Exactly...

Cross-posting my comment I made over there:

They're still in the process of docking it (watching the live feed now).

There is no evidence Twitter themselves were "hacked".
This is likely the password file from a spambot c&c network.

All* the twitter accounts shown follow the same naming and password rules. This is not typical of how a random selection of users would set up their account.
In addition all/most of these accounts are or were suspended (typically this is for spam).

* I may have missed one, but given several others point out the same...

Ref: Reddit: 55.000+ Twitter usernames and passwords leaked

From TFA, it supports HDCP 2.0 - so it's encrypting that content, at least.

You'll need to set HDCP policies for your donkey porn from now on. (Please)

Why not? I hear Julian Assange knows a few hot swedish chicks...

*ahem*

From 2006: http://hardware.slashdot.org/article.pl?sid=06/06/01/1255225

"But isn't Git easy to install and use"
Yes, for certain users and environments.
In my experience, The folks who use Mercurial are more likely to be on Windows.

Mercurial tooling isn't as polished as the Subversion equivalents, but it's lightyears ahead of the Git tooling.

I'd be happy enough to pay for good Git tooling on Windows, but there doesn't appear to be a way to do so. Please correct me if I'm wrong.

All chicken breasts will need to be appropriately covered before being allowed on the intertubes.
Naked chicken breasts will be blocked unless an appropriate 'Proof of Age' mechanism is in place.

Anyone having pictures of naked chicken breasts from a chicken under the age of 18 will be reported to the AFP.

We're a dev shop. Having a VM farm has saved our IT guys so much time and money.
We used to buy dedicated boxes - some projects would get their own, most would share on some conglomerate box. Weird shit happened, stuff would never get uninstalled after a project was over, and people would be tripping over each other all the time (One person needs to reboot a box, the other was trying to debug some arcane issue). In short: a nightmare.

Now, we buy a AUD$6k box from $brand, hook it up to our SAN, and run anywhere up to 24 VMs on that one box at once.
Each project gets one VM, possibly two or three if we need to simulate complex setups, or need multiple concurrent environments. If one project needs to do something resource heavy like do load testing, we can allocate a bunch more resources, set up a virtual network with a series of load-testing clients on a 10GbE network, and have at it usually without affecting other projects.

At the end of a project, we shut the VMs down for that project, and eventually archive them off. If a client comes back needing changes - that VM can be back online within 15 minutes. It's still in the same state as when we last worked on the project - its a bit more difficult to do that with physical hardware.

Our internal 'production' servers (email, source control, wiki, intranet, etc) are all virtualised too - although they get their own dedicated hardware pool where appropriate.

Backups are as simple as snapshotting the SAN and exporting the backup to tape. Push one button, and in a few hours go to the server room to pick up tapes. Having a huge number of boxes needing to run the backups themselves takes longer, and is generally more error prone.

Even for client production environments we recommend clients use Virtualisation. Most of our clients don't need bare metal performance, and it's generally better (cheaper, faster throughput) to simply clone an existing machine and load-balance the VMs, than go to bare-metal OS+app installs.

If something weird goes on with the production instance that we can't reproduce - we get snapshots sent over.

I'm not sure we could go back to pre-virtualisation now.

It wasn't about him using Telstra equipment, time, or resouces (since he didn't - or so he claims).

It was that people assumed just because he worked for Telstra, that his opinions and mocking of Stephen Conroy were somehow planned by Telstra.

While GET does in practice change stuff on the server, the idea is that it should be repeatable without adverse effect.

So, calling GET on a document might increase a hit counter, or update some other information - having me repeatedly call that function again should be safe.

However using GET for Updating Account Details, or Moving money (just some purely /random/ examples) is just plain bad design.

The example of signing GET requests is useful in some situations, but *mostly* not necessary if the design is right.