I honestly think this would be a better topic for Penn&Teller Bullshit to cover, particularly text messaging charges.

I did however dig out my cellphone bill from about 15 years ago. Somehow I don't remember things being as bad as they were because my bills in 1994 dwarfed my bill today.

You're telling me; I start getting reports from users all around the office that sites are failing to respond -- looks like a bigtime BGP barf, but then I realize it's all google ads and google analytics hanging pages all over creation. I couldn't think of a good way to mitigate this other than to blackhole Google's Georgia datacenter, and I figured by the time I did that, Google would have it fixed. Imagine my surprise when they didn't after a few hours. I guess there's a first time for everything.

http://en.wikipedia.org/wiki/Luminous_efficacy

If the data there is current, LED's max around 100 lm/W (15%), CFL's around 72 lm/W (11%), high efficiency fluorescent around 120 lm/W (18%) and things like low pressure sodium (orange-hued street lamps and the like) around 200 lm/W (29%). Incandescent hang out in the 5 - 18 lm/W range (~ 2.5%)

So right now in commercial products, the expensive LED based bulbs built with very good LEDs offer about the same performance as CFL's and usually are outperformed by your standard fluorescent fixtures. They do actually last a great deal longer and are arguably more environmentally friendly. They are easily justified by any installation where changing a bulb costs considerably more than the bulb (such as commercial installations requiring scaffolding to accomplish the feat). However the LED bulbs you can find in the retail stores these days that represent that a 5W LED bulb compares to a 13W CFL and a 100W incandescent are telling absolute lies. Then again, most retailers wouldnt dare put a decent $120 LED bulb on the shelf either - it simply wouldn't sell.

IMO the whole system for advertising bulbs is broken. If there's going to be any change to the laws about lighting it should not be to ban the sale of incandescents but to require better labeling. If bulb packaging were required to display the luminous output, the power consumption, and the color temperature we'd all be better off. There is some other useful information they could put in there too such as PF, weight, hazmat, lifetime, etc. -- sort of a "Nutritional Information" for bulbs. They already require similar labeling on appliances but I could see this type of requirement really helping out on power consumption. Once that garbage battery charger has to actually put a label on its box that says it ships with a crap 10% efficient wall wart that draws 300mA idle is the day it will instead start shipping with a better power supply.

The CA certificate system isn't supposed to be a 'web of trust' though. It COULD be but honestly users wouldn't make the effort. Most PGP users don't bother with the 'web of trust' either anymore which is why it's all but dead. Allowing companies to become authoritative CAs for their own domains is a good solution in theory, but the end user still needs someone to step in and help them do the identity proofing because, again, they won't make the effort; plus how do you secure it? DNS? Whois? Have them buy CA certs? All of these have flaws. Does the current system suck? A little bit - maybe about as much as the current system for domain registration, but

A company can already become a CA if it wants to and have users choose to trust them or install their CA certs on end users machines or use them within their own applications. Many enterprises run internal CAs anyway. In your example there is really nothing preventing capitalone from distributing a small installer that makes them a trusted CA same as Verisign or any of the others whose CA certs are bundled with the browsers. But if you think that these companies who are too already too disorganized to correctly author and secure their current web apps are going to go through the rigamarole of running their own CA and talking their users through trusting them? You are just talking crazy.

FWIW there is apparently malware that already does this -- a CA cert, a hostfile entry and suddenly paypal.com is showing green bars on nigerian servers no problem.

This is pretty much the only comment needed in this thread. I came to post basically the same two links.

Due to memory overcommit, ESX or the free ESXi on a whitebox is really the only viable lab platform to play with this kind of thing at home (or even at work) without breaking the bank. When you look at *any* other vm platform you can't test complicated infrastructure or scaling/paralleling techniques inside of 8GB. Once you start needing 16GB+ ram for your experiments, you start either run out of DIMM slots on most consumer-level boards and have to look at server motherboards -- or you have to shell out for 4GB DIMMS -- either way you start running into expensive territory.

S3's transfer fees start at 17c to 10TB/mo. and decline to 10c at 150TB/mo. At the volumes we are talking about for game downloads at ~1-2GB each download you'd easily be at the top end.

And amazon isn't really that cheap either when it comes down to content delivery. It's nice because it's more or less on demand but if you can do a little bit of forward planning, a content delivery network like Akamai can give you better pricing.

Anyway the article is a stupid gripe about a nonexistent problem. Microsoft doesn't charge the publisher bandwidth fees because they choose to charge the customer. Furthermore anyone who thinks they can do it for "free" on their own website is under some serious delusions. A publisher unable to budget for this correctly is a bad publisher. I think perhaps they are just pissed because they can't provide the service and charge for the bandwidth themselves - I bet they would charge a lot more than 16c/GB.

Sony picked a price and terms that are reasonable and cost competitive in the market. There are some ways around it too - game downloads from PSN could contain only skeleton executable files which would download the rest of the data on first start from a publisher's own content servers. The fact that we're not seeing any of this is probably because it's just not that big of a deal. $200K in bandwidth fees to expose a million people or more to your game demo is money well spent. It comes out of the advertising budget and will give a better return than $200K spent on billboards, that's for sure.

No CA is (currently) issuing wildcard EV certs. I personally understand the convenience of the wildcard cert, but I do also accept and support the practice of disallowing wildcards in high security applications.

EV certificates are available with multiple Subject Alternative Names, though so the whole "dropped www." or a couple of virtual shouldn't be a big deal if things are done correctly. Unfortunately they aren't and some sites (paypal) that are using EV SSL certs don't even bother with this simple feature.

The correct failsafe implementation which will always result in a no-prompt situation is to ensure that you only deploy EV certificates on an IP addresses that have only one DNS name. You then deploy a frontend redirection server on a second IP using a wildcard SSL cert that occupies the alternative dns names for the namespace of the original app. This server will pass cert checks more easily and then redirect to the EV server with its specific dns name which will then show the green bar. Any existing deep links to the application on an incorrect DNS name will be handled correctly and any direct references will work in the future. There are of course implications for securing said redirection proxy, but they aren't really that hard to overcome.

The dealership always gets all the money right away unless they carry the note themselves; and honestly, the only dealerships I've seen still doing that are the insanely shady "Auto Sales & Finance" type places that are likely to pack a clunker's radiator with eggs and sawdust then force it on a poor person so that they can beat $100 out of them every month. The reputable dealerships have figured out that it's much easier and better to find a couple banks to handle this dirty work for them.

Buying a car on an Amex)is actually a pretty good idea. Amex has all kinds of good buyer protections that can really save your ass when you need them. Note though that I'm talking about a real "charge card" amex not one of those new stupid blue ones that let you carry a balance and otherwise abuse it.

So, if your friend bought the car on *his* Amex, you might give his "supidity" a second thought. However, I would think it's rather unlikely that anyone in college could have earned an amex capable of purchasing a car without some kind of assistance -- was it his dad's Amex? That's a bit different.

Actually it sounds like they have a transparent web proxy that is malfunctioning. You can probably request that your traffic not be sent through the proxy.

Yes; this discrepancy is accounted for in two ways:

1) The burst rate allows the 12mb connection to achieve the ~22mb rates for a brief period of time

2) The XP box cannot achieve > 10-12 mb on this particular connection; most probably due to the way the TCP window scaling is limited in the default configuration. This particularly affects high bandwidth, high latency connections, particularly when peak available bandwidth is irregularly available. There is also likely a problem where selective ACKs are not being properly used and XP may be saturating the smaller upstream bandwidth.

All programs are smart enough to guess the upstream bandwidth. It's a basic built-in feature of TCP. It would usually be considered best practice not to implement any kind of rate limiting logic in the app and instead simply rely on TCP to do what it's supposed to. The problem is that (in general) consumer-grade routers use FIFO-type queuing implementations that are terrible for asynchronous connections like most people have.

"Smart applications", QoS and traffic shaping are really not the first line of defense here. The real solution is for consumer routers to implement better queuing algorithms such as WFQ or WRED so that when you want to start applying QoS and traffic shaping, they actually have the ability to do what they are supposed to. None of that stuff is going to help you when you have FIFO queues on your crappy little router and you experience congestion upstream of your connection -- the only way you can provide traffic control with a FIFO queue is to flat out keep the packets out of it.

When you put it that way, why bother with lights when you can burn candles, heat when you can just make a fire, and a fridge when you can just preserve everything in brine? Electronics, seriously? All you need is a thermometer, barometer, and a pair of eyes!

Anwyay, it was just an example of a "major appliance" and in any case it would still use less power by itself than running an electric stove or oven and electric furnace at the same time - probably less than an electric furnace by itself.

You are confusing "Publicly Routable" with "Directly Accessible" This is a distinction which cheap consumer-grade "routers" have blurred and it's even starting to seep up into the minds of network engineers.

You can have devices using NAT to RFC-1918 address that are just as "directly accessible" as any other host. Likewise you can have machines with routable addresses that are not in any way connected to the Internet. There are lots of valid reasons to do both depending on the applications, the hardware and the infrastructure.

Woah buddy; important point -- don't forget to de-rate your generator!

If you actually use even close to 80% of your 100A service, that 17kw Kohler running on natural gas is going to fry.

Most gas generators can be fueled with either LP or NG, but when you burn NG, your efficiency is diminished. In addition, utility companies like to keep the BTU content of their gas close to the minimum they are legally allowed, so it's good even to overestimate. Rule of thumb on this is around 15% total below the advertised rating or 5-10% lower than the official NG rating of the generator. For that 17kW Kholer that puts you at around 14kW that you can realistically produce out of that genset at peak.

Also keep in mind that for a number of other reasons, you're not going to be able to get peak power out of that generator for a while after it starts up, and most "standby" generators are not rated for peak power during continuous duty. There is also power factor to consider, as well as some other minor unfavorable types of things that the marketing numbers don't really include, so you really need to de-rate about 10% more to figure the nominal size load you can protect.

SO just being conservative on that Kholer (which you need to be when you are considering an EMERGENCY generator), you could reasonably ask it for 55A or so. That might be sufficient for a whole home without major electric appliances, but it's not going to deal with electric heaters, ovens, clothes dryers, etc. all that well. You'd need either a larger genset or to do some selective circuit protection using a sub-panel.