johnnygood

There are two things here: business and technology.

AT&T and Verizon are both using "700MHz" spectrum. However, Verizon is using the upper-700MHz band and AT&T is using the lower 700MHz band. It is possible (clearly) to support multiple frequency bands, but it isn't free. Plus, AT&T is shipping 700/AWS devices. While Verizon has AWS spectrum, their current crop of devices are 700-only. So, it would mean AT&T supporting three bands 700L, 700U, and AWS.

Beyond that, carriers generally don't do roaming where they have service already. AT&T already has data service everywhere Verizon has LTE. It's slower data service, but it's still service. Voice works the same way. A company might have very low signal in an area, but as long as the phone can get any signal, it will prefer its home carrier. If they had the same policy with LTE, it wouldn't help customers. Heck, Sprint users are allowed to roam onto Verizon for data, but are restricted to 1xRTT (2G) when roaming on Verizon (save for legacy Alltel areas). It might be that Verizon's data roaming rates are so high for newer technologies that it would be unreasonable to offer roaming like that.

That's quite an accusation. It's incredibly unlikely that PC Magazine is risking the FTC going after it by publishing something paid for by AT&T without disclosing it. Frankly, that was an unjustified attack to discredit without providing a compelling counter-argument or other evidence.

Moreover, 40Mbps isn't unrealistic on an empty network for an absolute maximum. Average speeds of 22Mbps seem realistic given Verizon's 16Mbps performance and the fact that Verizon probably has a couple million customers on its LTE network. Likewise, Verizon's absolute maximum is 50% more than their average speed. On an empty network, I'd expect more divergence in speed from average to maximum making AT&T's ~85% difference believable. Likewise, if you visit wireless forums, you'll find plenty of Verizon users posting their maximum rates over LTE and seeing similar speeds.

And these tests were being done using Speedtest.net run by Ookla and endorsed by the FCC. While I don't know the specifics of how it works, it is the standard in testing broadband speed. Without evidence that it can be tampered with, I'd listen to the FCC.

The real question is how AT&T and Verizon's networks will hold up as more customers come on board. Last quarter, Verizon sold only 1.2M LTE devices. AT&T has just started selling LTE devices. We might see the speeds of both networks lowered as the number of customers on the networks increases.

Many people dislike AT&T. PC Magazine is testing an unloaded AT&T LTE network and a mostly unloaded Verizon LTE network. These numbers seem very reasonable given those conditions. It doesn't mean that AT&T will remain at these speeds or remain "better" than Verizon (if your purpose is to defend a cherished carrier). It's simply an initial test of an unloaded network that shows promise for the network. Whether that promise will be realized or not we'll have to wait and see.

In Rackspace's defense, this might be more of an issue of lack of community. Sometimes it's hard to get other people involved and excited about an open source project. It's a lot easier for them to go to NASA, Dell, CloudKick and others and get them to attach their name/logo to a participants page than to get real participants. OpenStack isn't something most web people will be interested in. It's infrastructure. Many, many companies need programmers and tools for them. Very few companies out there are saying, "you know, I'd like to build a server farm of 200 machines to give me a petabyte of distributed object storage with replication policies, failover, the works". Most people would rather just farm that out to S3 since, well, very few companies store that much. Like, OpenStack's Object Storage is a lot of work if you're just going to be storing 100GB. There's no way you could do it cheaper than the $15 S3 is going to charge for that storage since you'd need at least two machines.

How many of us could justify spending a lot of time on running our own object store rather than using S3? It makes sense that Rackspace is a lot more interested in it. I'd say that you'd need to be in the several terrabyte range before it makes sense to think about it. Clearly sites like Facebook, Flickr, and imgur want to run their own storage - they store a lot. But how many web firms do? I'm not saying it isn't an awesome project and I was excited when it came out. However, I'd have to be working on a site that stored a lot to justify building my own cloud storage cluster.

For what it's worth, it would be awesome for everyone if this engineer went on to create a Cloud Files and Cloud Storage competitor using Open Stack and worked with Rackspace without any grudge. Sometimes that's how openness happens. However, there tend to be fewer infrastructure vendors than web apps and so an infrastructure project like this can't be expected to garner the same attention as something like Apache or nginx which lots of people will be running rather than mostly a few infrastructure vendors. For most web operations, it doesn't make sense to pay a lot of money to build this infrastructure when you can get it for cheaper from Amazon, Rackspace, and others.

It might not be that Rackspace is being closed. It might just be that there are few operations that want to help develop these tools and most of them already have their own tools. Flickr and Facebook aren't going to drop their storage engine for OpenStack. Amazon isn't going to replace S3's software with OpenStack. SoftLayer does have their own cloud storage solution, but it isn't as widely used so there's a possibility there, if not a large one.

It's great that it's open source and if Rackspace keeps up the development and it's of high-quality it might start getting used by the next Facebook and Flickr style companies that need that type of storage. But it will happen slowly compared to the adoption of nginx, Django, MongoDB, etc.

It doesn't break them. Safari doesn't accept cookies from across domains (by default). Safari still sends cookies to iframes across domains.

Even if Safari blocked sending cookies to other domains, it would still be possible for both commenting and the like buttons to work. On a low-tech level, rather than working by Ajax (which is how I assume they work - I haven't actually used them), they would work as a standard link or form to Facebook's site. Once not in the iframe and on Facebook's site, it would realize that you were logged in and rather than asking you for your email and password would record the like or comment. In fact, when you try to press a like button not logged in, a small window pops up asking for your email/pass so that it can log you in and do just that. It's easy to imagine that the window would pop up, offer a little "thank you for your comment" confirmation with a close button.

Facebook could also decide that it wanted to use Flash cookies which would work if Safari blocked sending cookies to other domains. Safari isn't in control of whether Flash is loaded in an iframe and a Flash cookie is requested from another domain. This is part of the reason why it's more significant on the iOS platform. Advertisers do use Flash a lot and that usage can be used to set a Flash cookie that the browser doesn't control and Flash doesn't have a setting to disallow Flash cookies from sites you don't visit.

The big deal is that many people see Yahoo as a company that time has passed by. There was a time when its properties were the tops. Everyone used Yahoo Mail or AOL, Flickr was the tops if you wanted to share photos, Yahoo.com was the home page of so many more and they used Yahoo search. Today, a lot of our community looks at Yahoo and sees a search engine they wouldn't want to use, a bloated homepage more about flash than utility, a Yahoo Mail that doesn't hold a candle to Gmail, etc. EXCEPT: Flickr. Flickr's still pretty good. Facebook has overtaken Flickr, but Flickr still offers more high-res options, decent topical search, a clean interface that's been spared a lot of the nonsense Yahoo is pushing, etc. But it hasn't progressed lately.

If Yahoo is to make a comeback, they need the types that have been in charge of Flickr (or so the community's reasoning goes). Flickr is the one thing we like that Yahoo's doing (well, maybe add Delicious in there too). And yet Yahoo is letting those properties languish and the talent that works on those properties leave. Sure, Google loses talent, but generally speaking I don't find certain Google properties to have an interface that is so markedly terrible compared to other Google properties. Our community looks at Google's ventures and while they might not understand social, we see that there's a decent consistency of engineering. However, we do look at Yahoo's different properties and many feel like they came from a different company - partly because Yahoo bought their way into Delicious, Flickr, and Upcoming (yea, I added another that I've almost never used).

Imagine that Google had bought YouTube and YouTube's interface and engineering was just so markedly better (to you) than the rest of Google's properties. Then the employees who created this, in your view, superior product started leaving constantly. You'd think: c'mon Google, you bought yourself into the good stuff and we want to those engineers bring that good stuff to the rest of your line, not leave with their products languishing!

People move around, but I think many of us feel that Yahoo has markedly varying quality depending on the division of the company. It might not have any actual significance and engineers might not be leaving those divisions more often than other divisions, but it does have an emotional significance for our community. Many thought that Flickr heralded a new Yahoo. It makes it feel like Yahoo doesn't get where it's gone wrong (in our ultra-hip, we know what's best not some CEO the investors have hired, why isn't the world listening to me as I type away at my keyboard on the internets way).

/Apologies for speaking for everyone; it's more just a theory.

You're right. Coins are cheaper than bills, but $183M per year isn't going to balance the budget. Basically, keeping the $1 in bill form is costing 60 cents per American per year.

The signature database is where they'll get more money from. However, this is still bad for them. It gives people the chance to look through the code for vulnerabilities and it allows competitors to look at any techniques they're using. But the worst part is that they're a computer security company that couldn't keep their source code secure. Clearly, accidents happen even when one has the best policies and such in place. Sometimes it's merely chance as opposed to an indicator of something in a statistically valid way. However, it's still embarrassing. I don't find that there's a lot of testing of the efficacy of anti-virus software out there and so purchases are partially made on faith (would love to know if I'm wrong here since I'd be interested in the results). Anyway, as a purchase made partially on instinct, this makes purchasers feel less happy in their gut (so to speak).

I guess I don't see how BankSimple can be truly better. First, there are already no-branch banks like ING-Direct. Second, Credit Unions exist.

BankSimple seems to be a no-branch bank like ING-Direct. They're presenting themselves as being better. How are they different? Well, they're pushing the idea of no-fees, better customer service, and better mobile banking. In order to achieve that, they'll have to be more efficient or accept a lower profit margin. Banks have healthy margins so there is some room there, but there are other industries with higher margins.

The second piece is that there are already not-for-profit banks. They're called Credit Unions. They exist to give their customers (who are their owners) the best deal they can. In order to be better than credit unions, they'll have to be significantly more efficient rather than simply relying on lower margins.

Part of what makes me skeptical is that they aren't creating a bank. They're partnering with currently chartered banks. This is probably because it's very difficult to create a bank and there's a lot of regulation to deal with. However, this somewhat limits what they can do to give me a better deal than a bank (since they're just reselling the product of another bank). Now, banks vary in how good of a deal they give you so part of their product might simply be getting you a good account under their brand. But part of this means that BankSimple won't be doing what banks normally do with deposits. Banks normally lend it out or invest it. BankSimple will be parking it in another account. So, if they aren't charging fees, how will they make their money? Maybe they've found an account that will give them 1% interest and they'll pass on 0.5% interest to me. However, why shouldn't I just bypass them? If they're doing things like refunding ATM fees, covering overdraft fees, etc. will the interest difference cover that?

I'm not saying that it can't be done. They stress no-fees and earning more interest. If they aren't lending the money out themselves, that will be hard to do - especially considering that they're claiming the best customer service, best software, etc. Where are they making their money? Not off fees and they aren't lending it out, but rather relying on other banks.

I'd really love to see their business plan since I assume they've addressed these things. Maybe wholesale banking exists and offers them a lot more. Maybe credit unions are woefully inefficient. I'm excited for their launch, but I'm not unhappy with my credit union.

ATT isn't saying that your iPhone is 4G. Your iPhone supports HSPA 7.2. ATT's network is HSPA+ but they don't have any HSPA+ phones yet. HSPA+ is what ATT and T-mobile are calling 4G.

This is something that has bothered me about my Ruby usage. A lot of the time, I feel like I'm writing "dynamic" code that really just needs to be pre-processed.

  class Cool
    [:ice, :soda, :snow].each do |item|
      define_method item do
        #some code
      end
    end
  end

There isn't a real reason why that couldn't be pre-processed. I don't know a ton of Java, but the idea of compile-time code generation is appealing. Does anyone know more about this?

I'm not trying to be harsh on your concept, but if one takes it a little further: "If the citizens can't be mustered to volunteer their taxes. . ."

One of the ideas behind government is that certain situations are prisoner's dilemmas and that a central authority can make sure that the situation comes out equally for all. Rather than having people volunteer taxes, we write laws forcing people to pay them so that some person doesn't get to skip taxes yet get the benefit of the taxes being volunteered by others. Likewise, Israel is compelling their citizens to do military service. Heck, if you're an American male, you were compelled to register for the draft from 18-26 years of age and notify them if you moved residences - under the premise that such registration would make a future draft more equitable.

I'm somewhat just playing devil's advocate here since I tend to think that putting one's life in jeopardy is different from being compelled toward other ends. Would you object as strongly if you were compelled to serve the military, but could choose a non-life-endangering position? Say, IT support? What if the United States compelled people to do Americorps for a year or two after graduation? Does that qualify as slavery?

I guess I'm curious whether your objection is a more libertarian "any time the government compels its citizens, it's a form of slavery" or a life-ethic "when the government forces its citizens against their will to put their life in jeopardy, it's wrong."

I have no internal knowledge of Zencoder, but. . .

Because Zencoder is running a service, they can have lots of boxes going at the same time. You might want to encode 50 things at once which would have to be queued up if you were doing it on one box, but can run simultaneously on Zencoder using their many boxes.

Likewise, Zencoder can fire up high CPU boxes that will get your videos encoded faster. The faster they turn around videos, the more capacity they have. If you're low (or bursty) volume, you can't justify that cost and you go with a small instance that's slow and queue things up if there are multiple jobs at once.

Plus, Zencoder is probably knows ffmpeg and the like better than you do. It's their whole company. Unless the focus of your work is video encoding, the likelihood that you will have any reason to be as knowledgeable is low.

I'm not saying that Zencoder is right for everything. They have certain economies of scale since they're encoding video for many people that kick in which mean that you can have 20 boxes encoding things for you at the same time for a few hours without having to pay for them all the time or going through the hassle of creating 20 encoding boxes and then getting rid of them so that you can use that capacity for an hour or so. That said, if you have a slow, steady flow that isn't too concerned with time or you're popular enough that you've hit those economies of scale yourself, Zencoder might not be right for you.

Oh, plus you might not want to deal with ffmpeg and such. Some people would rather it be abstracted away a bit.

I came here to post that too. The only thing I can think that means is that it is laid out better for large teams to program on without stepping on each other's toes. Sort of like a Java argument against dynamic languages - those cool scripting languages are fun and productive for an individual, but large teams would just screw each other up with that.

There really isn't "scalability" in client-side JavaScript. Scalability is usually thought of as the ability to serve many users at once (as opposed to speed which is how fast you serve one person). So, sure Ruby is slower than Python, but it doesn't matter too much since you can have 4 web servers and a load balancer rather than 2 web servers and a load balancer and you're fine.

However, client-side JavaScript isn't serving multiple users at once. It's trying to serve one user as fast as possible.

Maybe someone has a better explanation? It's early and I haven't had my coffee.

EDIT: It seems like YUI might allow you to pull independent pieces by calling YUI.use(some-cool-piece-of-functionality). That could reduce download times, but it could also increase HTTP requests and the associated overhead. That's pretty cool. If 90% of your users aren't going to be using a piece of functionality, it doesn't load that code, but can load it dynamically if needed. While cool, I don't think I'd call this more scalable - this is about speed. And I don't know if it would be faster in a meaningful way since JS can be nicely cached. I shouldn't have said that - in the absence of evidence from testing, I shouldn't make assumptions. Maybe someone else can shed some light on how well this works in the real world.

Actually, high fructose corn syrup is a combination of fructose and glucose - the same sugars in most fruits.

For example, grapes are 52% fructose, 46% glucose, and 1% sucrose. Pears are 63% fructose, 29% glucose, and 8% sucrose. High fructose corn syrup used in sodas is usually 55% fructose and 42% glucose.

The "natural" sugar you're thinking of is sucrose. Sucrose is not the dominant sugar found in fruit. Fructose and glucose are the predominant sugars found in fruits and in high fructose corn syrup.