None of this post makes sense.

1. We're not talking about halfway around the world. They could put the datacenter 20 miles away and pay a small fraction of the property and maintenance costs.
2. Our primary datacenters are ~270 miles apart, and the latency is less than 10ms round trip. 20 miles is going to have negligible latency.
3. Datacenters have a tiny staff on site for a large number of servers. You don't need a huge talent pool to get someone to rack servers and run cables.
4. In the rare event that you want to touch a server physically (why?) driving 20 miles just isn't a big deal.
5. Wall Street stopped putting its servers in Manhattan after 9/11, so you wouldn't put servers there for high frequency trading.
6. Most major telecom nexus points to the rest of the world aren't in the middle of large cities. There's no reason to have them there. In a large city you have a nexus for the city, which then has a connection to a nexus point off someplace sensible.

From what I've seen from most carriers in the US, there is no difference between a plan that is paying for a phone under contract, and one that has no phone under contract. So unless one plans to change carriers before a contract ends, it would cost significantly more to purchase a phone outright and then pay for service. (Note that I'm speaking of major carriers, and this could be different if one were willing to accept a very minor carrier.)

This is not correct. The framework used on 7.5/7.8 still works on 8, and so applications released for 7.5/7.8 still worked, that framework has just been deprecated for new applications. MS released an additional framework for 8 that was not compatible with 7.5/7.8, so new applications developed with the new framework will not work on older phones. This is not particularly surprising given that I have encountered numerous applications for both iOS and Android that do not work with older versions of the OS.

No, I'm saying that there is a strong correlation, and suggesting action without understanding it better is reckless. But that may all be a little off topic.

It's been my personal experience that a significant number of people are getting married for legal reasons rather than societal ones. But let's face it, I really have no actual numbers, selection bias, etc, so I have no idea how representative my experience is.

The statistics I've seen impacting the success of children is in regards to legally recognized marriages. Parents who stay together without a legally recognized marriage suffer a statistically significant drop in the likelihood of success of their children. While you couldn't be certain without trying, I think that setting marriage up with the same legal significance as a promise ring might cause a global drop in success. Who knows for sure, but it's a big enough risk that I wouldn't even think about trying it without a significant amount of data saying that there wouldn't be an impact.

Unfortunately, that is probably a rather short sighted plan, much like communism sounds like a great way in theory to bring everyone up to the same level but practical problems with human nature prevent that end goal from ever being a reality. Whatever the reasons, children raised in families with married parents (in the government endorsed sense) have a significantly higher chance of success, and changes that are likely to decrease the likelihood of that situation should probably be avoided due to the long term negative economic and social impacts to a country. It's not that it wouldn't be better, it's that statistics and experience seem to indicate that it would be an extremely risky move.

I haven't had much cause to watch the changes in school policies in AISD, but I'm curious what is happening here. What sorts of new vocational training are being offered to middle and high school students?

No. Comparing an ARM SoC to a PowerPC with discrete graphics is just ridiculous.

I installed Server 2012 (same kernel as Windows 8) on a system with a cheap Silicon Image SATA controller. The only drivers I could find were from 2009, and they worked fine.

I think that would depend heavily on how many people's dogs like traveling in that fashion.

The patents/licensing issue is the reason that the BBC developed the Dirac codec. They have a few hardware boxes that they've developed that take uncompressed or analog audio/video in one end and spit it onto Ethernet on the other end. If you use those everywhere, then there are no compatibility issues. The BBC uses it right now, so it is certainly a possibility on current equipment.

I don't buy the "produced live" as an issue as you're not likely to see a full second delay at any point. Outside the studio, no one cares about a fraction of a second because everything else adds seconds of delay. Just turn on a "live" sports game on TV and the radio and you'll notice how the radio announcer is always a few seconds ahead of what you see on the TV. You would have to be filming a delayed stream in the same view as the live stream to know, and even then the delay is unlikely to be noticeable.

I could see a case where you have multiple timing planes with edits being made using circular dependencies that would wreak havoc. That sounds like more of a process issue though.

It still sounds to me like you're making the process difficult by holding onto ideas of how certain pieces have to be done, and that maybe the whole process needs to be rethought. That said, I know there are things going on that I just don't have the background to foresee or understand, so it may very well be impossible without moving around insane amounts of uncompressed data. It'll certainly be interesting to see what the next decade brings for this field.

The question was why does it matter, which was never answered. The GP did some hand waving about keeping in sync, which didn't answer the question. I pointed out that it didn't answer the question, and that sync isn't an issue.

Now you have managed to not answer the question, or rather say the equivalent of, "latency is important because latency". Good job.

H264 has vastly varying levels of compression and computational complexity. Heck, it even has lossless modes, so there is zero generational loss. And there was dedicated hardware out there years ago that could compress frames before the next frame was finished receiving. Really though, this scenario is probably better suited to one of the less complex and lower efficiency codecs, which is what the BBC is doing with the Dirac codec. And I'd imagine that a lossy codec that retained 99.9% of detail would be workable as a dozen recompressions would still leave about 99% of detail. Given the infrastructure gains, that seems like an easy win.

This didn't really answer the question. You can time stamp every frame coming in, buffer appropriately wherever you're trying to switch between viewed streams, and things will NEVER be out of sync. Never ever. Traditional A/V types get weird ideas about how things have to work. I've help design and work with digital video storage/transmission standards, and there is absolutely no reason multiple video/audio streams should ever go out of sync.

You're never likely to be more than a frame off that you'd need to buffer. It's not like you have to decode/encode at ever station either, you decode for the viewer, but pass on the already encoded data. And even if you have to buffer at 10 different stations (for reasons I can't imagine) you'd be delaying transmission by less than a second, which inconsequential. "Live TV" is delayed far more than that by the time it reaches a viewer anyway, and it's not like anyone could notice.

Or I could continue to live in my 5 bedroom house with a significantly cheaper mortgage payment, building equity, and deciding which fruit trees I should plant in the yard. I really don't understand all the suburb hate. Sure, I have to drive to get a number of places, but because I have a car I can go downtown, or out into the rural, or wherever else, and it takes about as long. Plus I get more/nicer living space, a nice yard, and nice neighbors, with essentially zero crime.