I grew up on Linux using GNOME as my preferred desktop environment. I could grok KDE but I just didn't like it; it seemed heavyweight and clunky. This state of affairs continued for eight years, until I found myself switching to Mac OSX because I needed a UNIX that "Just Works" for my new life as a grad student. Since then I used Linux primarily as a server environment. Recently I've started exploring going back to Linux as my main desktop environment, as I've been really impressed with the quality assurance of the latest desktop releases. And after messing around for a while with Ubuntu, Mint, Fedora, OpenSUSE, etc, I've come to discover that my favorite distribution for everyday desktop use ... is Mint KDE. Whodathunk?

1. Get the FCC to allow ISPs to make sweetheart deals with content providers, but subject to FCC supervision. (Done)
2. Starve the FCC of resources so that supervision becomes impossible. One way to do this: refuse to appoint FCC commissioners, so that they can't form a quorum --- just as happened to the FEC in 2008.
3. Profit! (Literally!)

Headline: "Comcast predicts storage cap"

Story in a nutshell: Comcast exec predicts bandwidth cap.

WTF?

...is how do you get a job and then succeed at it for longer than a year or so.

For that second part, my main recommendation is this: Don't be a bottleneck. As to how to carry out that part, there's plenty of good advice in the comments above, but your goal should be to solve problems quickly and produce solutions faster than expected whenever possible.

90% of your changes won't have any effect on production systems. Just lump those together under "Routine changes to UNIX/Linux production environments" and explain that you've tested those on your sandbox network.

10% of your changes will impact your production systems, even if it's just because it's upgrading Apache or some Perl module that your systems use. This can be as trivial as "updated Perl module; ran complete unit, load and regression tests, everything works fine." to "This is a kernel patch that requires us to power cycle each box. Here is our plan to do this in a way that generates no application downtime." Those are the changes CAB is meant to catch. Document each one in a different request. Document them clearly and thoroughly. Run them by people whom you trust to write good English. Make sure that your deployment, testing, and rollback plans are solid, and document them thoroughly in each request.

After a while, you'll get really good at this, and people will trust your requests.

Belle later confirmed the existence of the Z(4430) with a significance of 5.2 sigma on the scale that particle physicists use to describe the certainty of a result.

I believe that "scale" is called the normal distribution; that is to say, the odds of getting that result as a fluke are the same as finding a point 5.2 standard deviations away from the mean of the normal curve. If so, everything in that sentence after "5.2 sigma" can be left out.