I've always been tempted to bring a half tube of toothpaste or drink bottle just so I can duck and cover when they take it and toss it into the trash behind them. I'm pretty sure they wouldn't see the humour in it though and instead I'd end up at the least being detained for several hours..

Will it finally support remote tuners? (or does it do that now?) One thing I love about my sage setup (and about Mythtv, before that) was that I could have one server in my basement with a few tuners and all the noisy drives, and then have a silent, tiny box sitting next to my TV with just power, ethernet and HDMI out, and an IR remote. I just pick a channel to watch and it figures out an available tuner to use (truthfully, I usually just pick a show to record, and never watch live tv nor even think about "channels"). It doesn't matter that I have an analog cable tuner, a digital OTA antenna, and a couple digital cable tuners -- there is a single guide, with a single list of channels, and when you watch a show you have no clue where it comes from. That's the way it should be.

On top of that, of course, I do NOT want the complication of a full PC on my TVs, such as security updates, fighting to ensure no other apps steal focus, absolutely never requiring a keyboard/mouse, etc. That's part of the reason I switched to Sage from Myth, actually (that, plus I could not even get close to building a silent, disk-less PC for the $150 that it used to cost for the Sage HD extender, not to mention getting it to play 1080p video or boot in 5 seconds).

So what have they done up to this point? Shouldn't all plants require safety inspections, all the time, and if they're not up to standards they get shut down? Age of the plant shouldn't matter at all -- in fact, a plant built 50 years ago should be held to the same standards as a plant built 2 years ago. It doesn't matter if putting generators in the basement next to the ocean was deemed to be okay in 1967. If current standards say your backup power has to be protected from tsunamis, then the plant has to be fixed, or shut down.

Development environments and reference materials don't help you if you don't understand the logic.

When I ask people to write code or solve fizzbuzz-style problems, I tell them to do it in any language they want. I don't care about syntax errors, wrong function names, etc. I don't even care if you use % to take the modulus and your language doesn't even have a modulus operator, or you're writing in a language that doesn't even exist. What I care about that you knew you needed to use modulus, and really, that you solved the problem. If you can't solve fizzbuzz, how the hell are you going to write a multi-threaded high-performance ETL process?

Missing a semi-colon or closing brace doesn't make you a bad coder. An off-by-one error that you still can't spot after I hint at it, that may. Complete failure to solve the problem, well that definitely does.

Funny.. I also don't have an HDTV* - my old cathode ray tube is still going strong, unfortunately, and I can't justify replacing it for no other reason than to replace it.

(*I do have an HDTV in my basement, which just means we end up watching most movies and stuff down there, the living room tube is for more casual viewing).

Anecdote from a friend with kids (who are 6-8 years old):

They have always had a DVD player. One day, my friend hooked up his old VCR so they could watch some old movies he had on VHS. They thought it was an amazing new technology, because it had a great feature where if you took the tape out and then later put it back in, it resumed right away from where you left off.

You're bang-on with this. Reverse DNS entries and SPF are critically important. Your forward DNS should also match, eg; if you send from 1.2.3.4, you should have a PTR record for that IP to "mail.mycompany.com" and "mail.mycompany.com" should have an A record that points to 1.2.3.4.

Though as you point out, not all "business class" IP ranges are created equally. Notably, if the ISP allows many other businesses to send spam (from virus infections) in the same range as your IPs, you'll probably eventually be blacklisted as well.

This setup will get you a good outbound setup. I did something similar when I joined the company I'm at now, though took it a step further, and because we have some servers in a data center anyways, I changed our Exchange server to relay it's outbound mail (aka use the stupidly-named "smarthost" thing) to a server running postfix, when then sends to the rest of the internet. The reason I did this was two-fold: I don't really trust our cable co's IPs, and we have a secondary DSL line: if we fail-over to that, I still wanted outbound email to work. This setup allows both, since our mail always comes from an IP in our datacenter netblock. In the 2.5 years we've been using it, we've had no problems with people getting our mail.

The other side of this is inbound: personally, inbound mail on a cable modem hosted in a regular office is a recipe for disaster, eventually. In fact, one of our clients had it happen to them, their office flooded, and their ability to get email was down for several days while they tried to get a new server up and relocate it. Email was actually bouncing back to people sending to them, because nothing was responding. Since their phones were also down at first, it looked like they were out of business, except that they called us to tell us what was going on. You don't want this to happen to your business.

When I first did the email setup described above, I also got an account at dyndns using their Mailhop Forward service. Effectively, you point your MX records at their server, and then they deliver mail via SMTP to your (possibly dynamic) IP. If the office connection goes down, they spool mail for you for up to a week, and deliver it once you come back online. No mail lost, even if your connection is down. In a disaster, you can easily redirect the service to send to another mail server, without having to wait for DNS changes to propagate and all those other servers to retry sending and/or people to manually re-send.

Since then, we got tired of the spam (whatever crappy software we had that integrated with Exchange sucked), and so probably a year ago, we switched to Messagelabs, which provides a similar service to Mailhop but also does virus/spam filtering. Spam went to effectively 0. I HIGHLY recommend using an external company for this.. it costs us a few dollars per person, well worth it, and we don't have to manage anything ourselves. I see Dyndns is now offering something similar as well, I can't vouch for that service specifically but we continue to host our DNS with Dyndns and I have nothing but good things to say about them.

Security that relies on a policy of changing passwords regularly is inherently flawed. Generally when that policy is enacted, you're also forced to not reuse passwords, and have fairly high complexity.. the combination of which leads to passwords that most people can't remember, and so you end up with sticky notes underneath keyboards with passwords.

The reasons you'd want to require people to change passwords are to try and protect the system if other people know the password. The problem is, at the very best, it allows the compromise to happen for a few weeks/months until the next password change. That's more than enough time to do a lot of damage, extract info, etc. So I'd say the policy totally fails in that respect. This includes causal password sharing among co-workers ("hey, can you on to my email to get me that phone number?").

You're also right about being forced to have a "different enough" password.. but consider people who use passwords like "winter2011". The next one will be reasonably different, on a character-by-character basis, but I bet you can still guess what it will be..

So really, password policy is only a small part. Force some amount of complexity, but it doesn't need to expire. Instead, the IT infrastructure needs to detect and handle compromise by itself. Multiple invalid password attempts should gradually take longer to respond (so after your 4th wrong password, it might take 10 seconds to respond, and soon after that take 30 seconds to respond), which makes brute force attacks infeasible. A user logging in simultaneously from multiple locations should at the least be flagged. Logging in at odd times, or new locations should be flagged (if an employee who works in New York and doesn't travel is suddenly trying to log in from Nigeria, something is probably not right). Restrict what they have access to.

Of course, all of this actually makes the IT department do actual work, instead of blaming users when a compromise happens. I mean, IT even sent a memo saying not to write down or share passwords, how can they be blamed that the user didn't listen? And yet, that's the mentality that puts these stupid policies into effect, despite a couple decades of it not working.

Or just buy a long HDMI cable.. or HDMI-over-Cat5 adapter.. or (if you have the luxury during construction or like to retrofit) install HDMI in your walls. This is just .. too obvious. It's probably less effort and more effective than trying to soundproof a PC, cheaper than liquid cooling+SSD drives, and is stil noise-free for anyone in the room not using headphones.

I had one of my mythtv frontends (which also happened to be the server - lots of fans/drives, quite noisy) in the utility room behind the wall my TV is mounted on. HDMI and USB cable coming in was all I needed, and I had a remote (and keyboard/mouse - when needed), and sound/video. And it was totally silent. (I've since switched to another system with a no-moving-parts frontend, so now it sits in the same room).

The 20 seconds spent by a slow typist is likely more than double the time spent by a decent typist. That is (lets say) 13 seconds more time spent thinking about typing that could have been used to think about programming.

I also think that spending so much extra time thinking about typing makes the poor typist more likely to (partially) forget what the next line was going to be, and thus spend more time thinking about it.

Personally, I think more in 'sections' than lines, and when I think up a way to write a particular bit of code - which may involve a loop iterating through an array, for example - I can just pound out that section very quickly. This lets me get thinking about the next block sooner, since I spend almost no energy thinking about typing.

There's definitely also times where my typing is too slow for my thought process - for example I decide to solve some particular problem, I need to write a class to represent my data and a collection class to hold it - and so my brain is waiting for my fingers to catch up so I can actually start writing the real logic. I don't know if that's really a good explanation; I just get into spurts where tens of lines of code just stream out very quickly, and then I sit back for a few seconds to think, before streaming out another chunk of code.