Did you take a puff off of your bubble pipe after writing this? Your post describes a considerable amount of devshops but software advancement is alive and well. Not every developer out there is trying to throw things together for a deadline to "stuff their pockets".

I really don't know of anyone that supports Ron Paul because it's "cool".

Personally, I like him because he's in favor of ending big government, the current US Government is trying to do way too much, and most of its programs are failures. Paul recognizes that and has the balls to suggest what needs to be done. Paul also isn't afraid of pointing out the real cause of terrorism. The classic patriot response is that "terrorists hate freedom", no, people hate another country hanging out in their back yard, and you can expect eventual retaliation if you keep overstepping your boundaries. Early US colonists could have been considered terrorists during the revolutionary war, but I guess we forget about that. There are plenty of other free countries who have no problems with terrorist organizations, why do you think the US gets targeted? It's because the other countries aren't trying to police the rest of the world.

I was simply giving you an answer as to why it's recommended, it's not something that just "noob linux admins" do. I recommend it to anyone because most people new to sysadmin aren't aware that their server will start to get bruteforced as soon as it's setup, and most people aren't going to make their password a random string with 25 characters.

Also, nice job making fun of the document for recommending disabling services you don't need, then saying "disable services you aren't using". If you don't need something, disabling not only removes potential security threats, it provides additional resources for the utilities you actually need.

The other comments pretty much say this, but here's the NSA's take:

"Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access
the system via a unique unprivileged account, and use su or sudo to execute privileged commands. Discouraging
administrators from accessing the root account directly ensures an audit trail in organizations with multiple
administrators. Locking down the channels through which root can connect directly reduces opportunities for
password-guessing against the root account. ...

Root should also be prohibited from connecting via network protocols. See Section 3.5 for instructions on
preventing root from logging in via SSH."

http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

I've only used OSSEC which I can configure to permanently ban any brute force attempts. By default it just puts a temporary ban which is better than nothing.

So two things with bruteforcing, you need to know a valid user and you need to get their password. If you leave root enabled, you just gave away half of that puzzle, and unless you have some sort of monitoring to smack down bruteforcers you can expect your server to get hacked eventually. It's safer just having su priv's in my account because someone has to guess my actual account name to get access. On that note, it's good to avoid using common names, just check the sshd logs on any public facing SSH server, brute force attempts happen 24/7. Cert/no keyboard is okay, but leaving root enabled with a password is dumb.

These are arguably the best options for beginners. Both have great communities and any issue you have you can typically find a solution on Google in 5 minutes. Ubuntu even has a LAMP package that will setup everything(well, most everything) you need. Couple pointers: Disable root login via SSH as soon as possible. You're asking for a bruteforce attack if you leave that enabled. Set up something like fail2ban or OSSEC monitoring to help thwart bots that are trying to break into your server.

One of Spotify's biggest features is how social it is and how easy it is to share your music with you friends. Here's another deal killer, I can share my Spotify stuff with people that don't have a Blackberry. This is another terrible RIM idea, it won't take off beyond a small market of uneducated users that will soon be enlightened by their friends when they try to "show it off". Research in Motion is no longer research in motion.

Users stick with the platform because it works, it still does what it was designed to do extremely well and that's what most enterprise users are looking for. That's users though, RIM is losing developer support left and right. I attended a local dev group meeting and I was the only mobile dev that still supported RIM in the bunch.

Granted, the letter might be a little over the top, but he makes a lot of valid points. RIM's developer website is notoriously terrible, the organization sucks, it typically takes forever to find what you're looking for, and like the guy said, you have to enter your personal info over and over anytime you visit the site. RIM's infrastructure is plagued with issues, their signing servers go down routinely and AppWorld has constant hiccups. If they want to seriously complete with Android and iOS marketplaces, they have a lot of work to do.

He admitted to it being too dark a while ago because he was obsessed with having a high framerate.