I've been gaming my whole life, and I think that'd drive me to do something drastic. Like, go play frisbee or something.

I care. I don't want the government to have any excuses to selectively enforce bad laws. Bad laws should be removed, not simply scoffed at and ignored.

I have no idea how fb works because it's an abomination and I avoid it as much as possible, but - having coded sites and auth schemes from scratch (after 5 years in network security), I can say: it's a poor site that allows an http:/// cookie to perform a delete when they use https:/// for a login.

Generally, if there's a need to have some high-security functions but some low security interactions, you take the login over https:/// then set TWO cookies; one of them with the "ssl-only" flag set; browsers will only send that when returning to the site over an SSL connection. Then you restrict certain types of page views (which would include modifying your account) to https:/// pages. (And I don't tend to look too closely, but I assume this is what other sites are doing when they are saying, "Welcome back Matt...", and then asking for me to confirm my password anyhow and sending me back to SSL for things like a password change.

Creating a separate shell company to run your distribution center so you can claim your parent company does haven't Nexus is bullshit. Who wants to track their purchases to know what to file? What a pain in the ass.

Sales tax is just a shitty concept on a state-by-state level.

It's not at all different. I'm a prime candidate for ebooks - many devices, love digital, plenty of disposable income, love to read...

And I'm collecting paper books. In all the time you could only buy DRM music, I only acquired a handful of songs, sticking mostly with CDs - or more often - just boycotted. (Make it hard to buy, I won't buy.)

But I don't like seeing Apple use their customers as weapons.

Apple is presenting Amazon with a choice: either allow people to buy books in app, via Apple, and basically give apple the profit from those books, but keep the profit from people who buy through your site -- or remove the app, and lose ipad-only kindle buyers.

I hope Amazon calls their bluff, frankly. I expect it will provoke a class-action suit against Apple if they follow through with the threat.

When I buy a computer it is with the intent that I can load on it what I want to load on it -- not what Apple thinks I should be able to load on it.

Amazon locked themselves into this. They have a DRM that requires a custom app to read. If they sold PDFs or some other open book, then Apple couldn't do anything about it, because to stop Amazon from selling around them, they'd have to cut ever open-format reader from the app store, doing a huge amount of collateral damage to other developers and consumers. Amazon's DRM allows Apple to cut off just Amazon.

Point being - when you buy a kindle book, you can only read it on a kindle reader.

My first reaction to this story was to seethe at Apple too, but Amazon doesn't have clean hands. (And neither do the Publishers.)

Back in the 90s, we built a bunch of systems for managing firewalls (in particular, Checkpoint firewalls) out of shell scripts. We had commands to check in and check out policies, archive them, pull up customer contact and ip address data, do backups, etc, all from the shell. Years after we did it, Checkpoint released an "Enterprise Security Console" or some such, which cost $25k and was still not as good as our shell scripts.

We wrote shell scripts that provided full failover functionality, right down to using echo commands to send commands out the serial port to kill the primary firewall's power if we were forcing a hard failover. Again, we evaluated many failover solutions with complicated code for heartbeats and other things, and in the end, we could do a better job with shell scripts.

It's not a "shell script", but if you've seen the original facebook code, it was obviously very hacked together. Not badly, per se, but it also doesn't have the flavor of an enterprise architecture; it has the flavor of something cobbled together and then repeatedly iterated against.

To me, it seems like application architecture is more important than the code - you can always redo something, but when you have a framework of interdependent components, it can be very hard to change that in its entirety. An example of this dilemma being UI vs API - some people choose to build their API first and then build their UI on top of it. Other choose to build their UI and then build the API to have parity. The former, in my experience, leads to a much, much more effective, robust, and complete API; the latter risks an API which is an afterthought and his poor coverage against UI functionality. (And if you expect your API to matter a lot to your product/service, this is a very big deal.)

There's obviously going to be a judgment call at some point.

Are stories about boy wizard orphans all protected by copyright? Of course not.

But if you make a story about Larry Potter and his trip to Gogworts from platform 8 and 3/4s, you should expect to get sued as a copyright infringer.

In this case, one example of problematic content that would, I think, be infringing, is the maze itself (shown on the developer page). There are almost an infinite number of ways to structure a maze but at a glance, it appears he has ripped off the exact layout of one or more of the Pac-Man mazes. (Pac-Man and the ghosts seem nearly identical, too; was the artwork literally copied? It doesn't need to be. If you sit down and sketch a mouse that is "inspired by" Mickey Mouse, it doesn't have to be a perfect copy for it to be infringing.)

Some other people have pointed this out, but there are two flaws with your understanding:

(1) This is not transit traffic, at least neither has described it as that. This is traffic being carried to end customers. In/out ratios matter a lot for transit traffic, where you're receiving traffic for another peer. This is where networks are connected:

A B C D

If C is sending B traffic for A, then B expects to be able to send just as much traffic to C for D.

(2) "Ratios" in the peering sense often are much less about local traffic ratios - they're about long haul. If A needs to send traffic from the west coast to B on the east coast, and it has a choice between giving them the traffic at the west coast exchange and letting B carry it across the country, or they can carry it across the country and give it to B. That "long haul" cost is over a lot more miles of fiber and is therefore a lot more expensive than local exchange - a lot of these providers will already have metro fiber rings that terminate in a multi-tenant telco building, and so adding bandwidth between them is just a matter of having a big enough router, and running a cable between the ports. Carrying the traffic across the country means having fiber buried in the ground. Peering disputes often happen because of the un-evenness of the network. Even if you exchange equal traffic, if provider A has customers all of the country/world, and provider B is just in LA, provider A is bearing all the long-haul costs, and provider B is "riding free". Yes, both A and B's customers want to exchange traffic, but peering (settlement-free peering) is based in general on the "meet me halfway" principle.

That said, there's an entirely different question here, because I've heard Comcast mention CDNs a few times. CDNs have nothing at all to do with "peering". If Comcast provides a bunch of CDN capacity on their network, if L3 wants to use a lot more CDN capacity, that's on L3 to pay. (At least as far as I know, it has always been the person delivering the content that bears the cost of a CDN. Consumer broadband providers may run and use caching servers that ACT like CDNs, but without configuration from the end sites, but they wouldn't be called CDNs.)

Perl, Python, and Ruby unable to match Java's performance.

I saw a comparison a while again of 3 sites implementing identical functionality in PHP, Python, and Java, and the performance characteristics were nearly identical, assuming that none of them were interpreting on the fly. (ie, php had a bytecode cash that was hot for the purposes of the test, etc.)

If anything, I'd say that while runtime speed might be similar, Java uses more memory per connection.

Sooo... since when?

Dude, if someone wants to hang out in front of your store to trade a game all day, I think you should probably not worry about it. That's a price in time almost no one is going to be willing to pay.

You could ask why not refer to Google App Engine as a Platform as a Service and leave it at that, or why not call gmail a software as a service, and leave it at that.

We're really only talking about semantics, so it's not like there's a right answer, per se. But I can say that I interact with people all the time in Fortune 500 companies, talking about cloud, and IaaS is firmly considered part of "cloud services" in the vernacular.

Amazon only provides IaaS but is clearly considered cloud. Even for large entirely private enterprises, they've begun referring to internal IaaS projects as "private cloud". (e.g., I know of a large bank that ditched 30k desktops in favor of 10k rackmount servers, delivered desktops to the vast majority of employees via KMS service, and then used the unused cpu for number crunching. They refer to their 10k servers as their private cloud.)

And then there are people using IaaS and paying for it, and they call it cloud, whether that's Zynga or Netflix or the like.

So I think IaaS-as-cloud is here to stay. Which isn't to take anything away from PaaS or SaaS usage of the term.

I was unclear. I was referring to Infrastructure as a Service Cloud. (Although newservers.com, for example, bills as "bare metal cloud", and comes very close to meeting the Gartner definition.)

And GAE and Gmail are definitely cloud services - a PaaS service and a SaaS service, respectively.

But there is a difference between a VM, and an IaaS Cloud service, even though ~all IaaS services will have a VM layer underpinning them.

There are a lot of vendors providing appliances now that recognize this, and especially now that VMware has entered the cloud market with their cloud director product, you can expect to see an even bigger proliferation of appliances. Want to run LogLogic? Don't buy a box, push a "deploy appliance" button at your provider. What, your new group needs a sharepoint server? Push buttan.