...guitar players prefer tube amps.

Not bashing tube amps here, but this is something entirely different. Guitar players, and their amps, are creating music. Not reproducing it. In this context, the amp can be considered a musical instrument.

I've been using http://unblock-us.com/ for a few months (not affiliated in any way), and I like their approach. You change the DNS servers in your router, and it directs the traffic for you. That way, you can use Netflix et.al from devices that don't support VPN clients (like your smart TV/XBOX/AppleTV etc).

The thing is, the best tool for any one user might not be the best tool for all users. Putting aside the cost aspect, an enterprise license for many tools cost more than for one tool, there is the question of both compatibility, fragmentation and duplication. (Security too, of course. That has already been extensively debated)

Imagine a sales department with 2 Macs and 8 PCs. One of the Mac users decides to use Keynote instead of PowerPoint, stating that it will enable him to create better presentations while increasing his productivity. He goes on vacation, leaving one of the PC users his task of doing the presentation. As he has no way of accessing the presentation it has to be redone from scratch. To versions of the same document, double the work.

An Excel workbook with all sorts of calculations and macros will not work correctly after a round in Open Office, even if one employee thinks Open Office (substitute with Apple Numbers if you will) is the better tool.

A group of users may think the external website (knowledge base/ticket handling/code repository( is suboptimal and create a competing version. Confusing the users/customers, duplicating information or maybe even give contradictory information.

There simply is no best tool if your task is to cooperate using computers.

Hehe, I've actually administered Alcatel telephony switches running CP/M on a 286-chip...

I realize I'm late to the party, but this is just begging for the comment.

I just spent 90% of the retail price of a MBP, with Apple Care Protection Plan, to fix one filled with Lipton's Yellow (why is it that the price of fixing a non-warranty failure on a Mac always costs 75-90% of the retail price btw?) I found that I was unable to remove the battery due to an unknown screw that I immediately dubbed the holy trinity. Now this pentalobular screw is nothing but a pentagram in disguise.

The trip from heaven to hell is truly a short one. (And I'm sure I'll follow the same path because of this post, but so are you for those chuckles...)

Are driving me crazy. The drinks turn out good though, I just read it as a squirt of this, two thumbs of that and mouthful of that other stuff. Plant a cocktail berry and an umbrella somewhere in there and drink up.
Luckily, I RTFA and it says they have metric units as well. The first time I've seen a (decent) drink recipe app that has centiliters. Just in time for new year's eve!

You are, of course, completely right.
It made sense, it was cheaper and easier to build the equipment. Which in turn made it more widespread.

And we are lucky they did. Not that it mattered that much with the manual switchboards of the time. But in the 70's we started to get digital telephone switches. If the bandwidth had been higher, it wouldn't have possible to build those switches. But as we all know, by then (with already modest CPUs) we got non-blocking switches that handled both analog and digital signaling and 8 trunks or muxes (giving either 32 phone lines or an interconnect with 32 phone lines). Hey, you could even encrypt whole trunks!

They even built in "normalizing" in the phones. No matter how much you yell into a phone you will only reach a defined maximum volume. That made for an even easier transition to digital switches. Not only was the sample frequency low (because of the modest bandwidth), you also didn't need as many bits for each sample.

Finally, POTS ran on physical transmission lines, potentially able to deliver much higher throughput than we needed. Nowadays, it's all wireless. You want as many (preferably encrypted) channels as possible, with the addition of data traffic. These modest limits (together with more modern inventions, or adaptions of them, as spread spectrum and phase) make it all possible.

I, for one, am happy they made these choices. It has given cheap full duplex voice communication to the masses.

Having participated in designing control rooms, and been dependent on the people actually doing the monitoring, it's safe to say that I know how NOT to do this.
First of all, I was hoping you're not doing a show-piece. Making a functional control room that doubles as a way to show how cool you are doesn't really mix. I've seen this done a few ways.

First, there is the adjacent room with glass windows to the control room. Highly disturbing for the people doing the monitoring. Then, the one way mirror. Even more disturbing, as you get paranoid after a while. Lastly, video surveillance. Not doing any wonders for the people working in the control room either.

Not knowing what you're monitoring, or the workload, this is usually a job that requires a lot of concentration. Ideally, there should always be more than one person there. If something bad happens (the reason why you have monitoring in the first place), you don't want people panicking. Having seen the same old alarm for the 200th time, there could be a tendency to ignore it. Being able to consult with someone at 3 AM (other than the person on-call), is important.

While it's nice to see everything in full working order, the important thing is to make people notice if there's something wrong. (Even better, early warnings before things go bad.)
You should have one large monitor showing things that have gone wrong, and it should be the focal point in the room. If at all possible, make the system give a sound signal (or make the lights and/or monitors blink) to get your attention. The surrounding monitors can show how your systems are doing. You just don't want to miss that critical error. It's bad for you, your systems and your customers.

You are going to depend on the monitoring equipment. Duplicate the systems, have all kinds of redundancy. You don't want to miss those important alarms because the monitoring system is down or unavailable. This means that you need people who can administer the system and modify it if you have equipment that is not supported by your monitoring software. These people will be vital in ensuring that all systems are monitored correctly.

Guessing that the people in the control room won't have a deep knowledge about all the systems they are monitoring, you will have a number of people on-call.
The two most annoying things for a person who is on-call are: false positives and missed positives. That's right, while you get grumpy about unnecessary wake-up calls, you get angry if there is a missed important alarm.

I have worked with systems that have a very high number of real alarms, hundreds each day. The people in the control center will get reluctant to call for the 20th time that night. They will hope that the problem goes away, or they will deliberately misjudge alarms so they don't have to disturb the people on-call. This will escalate if you have a high degree of false positives.

Finally, the last thing you will want to avoid is confusion. Keep short, up-to-date, easy to read instructions for each and every system. What is the check-list for every known system/alarm? Who do you inform? How do you inform them? How do you escalate a problem if the person on-call is not answering?

So, not going into the discussion of which kind of soda/chair/toilet paper you will need, here is my list of advice:

  * Try to avoid making the control room a show-piece.
  * If possible, always have more than one employee in the control room.
  * Focus on catching alarms and problems.
  * Make audible or strong visual alarms if possible.
  * Do what you can to avoid down-time on the monitoring system.
  * Have personnel that can administer and modify your monitoring system.
  * Make sure that all systems are monitored, and monitored correctly.
  * Find a way to avoid false positives.
  * Don't ignore alarms.
  * Document all procedures.

A wiki?

I don't know what Plone can do. But you know it, that could help you save a lot of additional work.
As for digital documents, you don't only want them to be signed. You want to know that nobody tampered with it too.

I would go for PGP/GPG. Even if it has to be manually applied before you stuff it into Plone. Plone may have PGP functionality, a quick Google search seems to indicate it.

In short, with PGP, you distribute your public key to as many as you can while keeping your private key secret.
Somebody encrypts a message or document with your public key, and you're the only one who can read it.
But if you encrypt or sign a document with your public key, everybody else can read it. With the added benefit that they can be certain that you signed it. (Because you're the only one that has access to your private key.)

In addition to signing, you can also make sure that nobody changed your document after you signed it.

If you bring this into your company, you'll not only be able to sign and verify documents. You'll also get secure email communication, which is a Good Thing(tm).

These threats, and counter threats, happen all the time. He says so himself in the article, which is why they needed a good base of patents.
Not exactly damaging to the company.

...and couldn't say these things?
Somehow, I find that hard to believe.

Odds are the web server is protected by a firewall.

If you only intend to serve web pages from this server, open port(s) 80 (and 443) on the firewall towards that host.
To reach other services, VPN into the DMZ or another network that has access to your DMZ and initiate SSH from there.

No SSH visible on the Internet, no SSH bot attacks.

I didn't realize there was more than 1 kind of hay, but hey, I'm a goat...