One of the biggest things that currently ticks ME off about the US is the fact that companys are treated exactly like individuals when it comes to defense of rights. Corporate rights should NOT be the same as personal rights. When personal freedoms and corporate freedoms come into conflict, personal freedoms should win.

Strictly speaking, you're correct - that is the current state of affairs; but SHOULD it be?

In a world where so much of the technology we use for communications are owned by private third parties and provided essentially free to the end user, or only leased by the user (rather than purchased); I find myself more and more bothered by the idea that we're protected from our government stifling free speech without being protected from government sized corporations doing the same thing, practically speaking. I really do wonder if it should be permissible for a private contract to sign away freedoms that are otherwise constitutionally protected.

Doesn't this state of affairs de facto circumvent the spirit of the first amendment, if obviously not its strict wording? After all, the idea of leasing a communications medium would probably never have occurred to the authors of the amendment.

Shouldn't the very protections that save these companies from liability simply by saying "we're not responsible for content" also protect the people who ARE responsible for the content from meddling by the same company?

You're completely incorrect. As the article specified, they DO catch "rolling stops", if a rolling stop didn't end up in a citation, it's simply because the officials managing the particular municipality's red light enforcement chose not to issue a citation (whether because they felt it was too close to call, or they felt no traffic hazard existed, or because of an internal policy, or a technical problem, or just human oversight). In fact, the article specifically mentioned "pulling into the junction to let the ambulance past" as one of the reasons a citation wasn't issued to some of the recorded incidents.

I was more impressed when that bunch of Catalan Highschool Students did the same thing. They also had some fairly impressive photos as well.

In theory, WIMAX can give you usable (if somewhat slow) speeds out to 50km - which might get some villages close to Iran's borders but won't help Tehran at all.

Anyone who has the right sort of CPE, the right knowledge, and proper credentials can use a dish subscriber network to get as much as 2mbps down and 1mbps up. The latency blows, but it's not like the service is meant for playing the latest FPS. The big downside is the customer equipment - satellite dishes are thick on the ground in most areas of the middle east, but I'd be a little surprised if enough of them are the right sort of dish to matter. If they are, it may not matter - Iran's been taking various measures to reduce citizen's access to satellites

Yes

Really. Check it out

This is news? Redhat (like every OS vendor I've ever dealt with) have been pushing out updates with broken assumptions for years.

In fact, this isn't even the first time they've done something similar when updating bind:
back in 2004 they released RHEL 3 update 4 and many people had precisely the same experience. Additionally, when applied, Update 4 removed the /etc/rc*.d/S*named and /etc/rc*.d/K*named and then shut named off.

As a quick glance at redhat's bugzilla shows, the first problem (the same one you experienced in this release) wasn't a schoolboy mistake on the packagers part, or a bug. It was the result of a poorly understood choice on the part of the person who originally provisioned the machine.

Rather than installing just the original bind-9.2.4, the people who had their named.conf overwritten had installed bind plus a package called caching-nameserver. It's that package that, when updated, backed up and overwrote their bind config. The "caching-nameserver" package should only be installed if you want to run a caching nameserver, because the caching-nameserver package isn't an application at all - it's simply a named.conf file.

The real bug (back in 2004) wasn't actually in Update 4's bind package. As it turns out, the package it replaced incorrectly contained a `chkconfig --del named` in its uninstall script.

Anyone without proper alerting and a good QA process found that one out the hard way. I had customers who'd gotten so blasè about performing nighttime maintenances without proper reversion testing that they scheduled nightly cronjobs that ran up2date at midnight and rebooted the production machine, Naturally, they woke up in the morning to find they'd just suffered 8 hours of downtime.

Lesson? Don't trust the vendor's QC work, don't install unnecessary packages, and make sure to QC your own work! Ask any experienced Windows admin about unintended consequences from "trusted" vendor patches...