HP Superdome and Green Computing

The HP Superdome is designed with a much different basis than most of its competition – and indeed, many computers. The design principles behind the HP Superdome lead to a lesser impact on the environment, and thus are a "greener" choice for heavy computing.

Why? The HP Superdome is designed in such a way that its pieces can be replaced as needed, and the need to replace the entire system (common with other systems, including mainframes) can be dramatically reduced. The HP Superdome is designed with at least a 10-year lifespan, meaning that it when other systems have to be replaced the Superdome will (at most) only need "refreshing" with new cells or perhaps other parts.

For example, in 2009, the original HP Superdome prototype is still running – and even has HP Integrity cells operating.

Most other systems will have to be replaced once or twice before a Superdome has to be replaced. Replacing the system generates, as a result, a certain amount of electronic waste – and a mainframe will create a large amount of waste.

This is on top of the fact that the HP Superdome uses less electricity than a mainframe. It is also possible to only use the cells that you need, leaving the others either inactive via iCap (no power) if they exist at all.

All of these facts suggest that an HP Superdome would be a good choice for green computing in contrast to its mainframe competition.

A update on the recent HP Superdome Tech Day: turns out that Jacob Van Ewyk blogged about it in a two part article (part 1 and part 2) on the blog, Mission Critical Computing. John Pickett wrote about the energy savings inherent in using an HP Superdome on the blog Legacy Transformation.

Contributing to Wikipedia: Getting Deep

Writing is much more a part of system administration than most people acknowledge. A good writer will be more likely to produce quality documentation and presentations and other documents.

Writing for Wikipedia can be one method that you can use to improve your writing (by seeing other’s writing, and by getting reviews from others). However, contributing to Wikipedia is also a way to give back to the community, a way to show appreciation for what Wikipedia provides.

The most obvious is to just edit any article that needs it, and to improve its wording and spelling. However, there are techniques that are not as obvious in which you can participate in the growth of Wikipedia.

First, there is the Wikipedia Community Portal – a sort of single point of entry for contributing to Wikipedia. This should be a starting point for anyone "going deep" into Wikipedia contributions.

One can also join a Wikipedia Patrol. Wikipedia patrols watch over a certain type of Wikipedia page for problems and assist in making pages better.

For example, one join the Recent Changes Patrol, watching the Recent Changes page (reloading every so many seconds for instance) for new edits, and check any that appear to need closer examination: edits that are from IP addresses, or that have no comments – or edits that come from users that are making a lot of edits rapidly.

One could also join the Random Page Patrol, selecting a random page to improve.

Another thing to do is to join a Wikipedia WikiProject. For instance, there is the Wikiproject Circus – which is focused on improving pages about circuses. (By the way – you really should visit the Circus World Museum in Baraboo, Wisconsin, sometime…)

Contributing – and improving your writing and others – is not limited to Wikipedia: you can add your abilities to Wikipedia’s sister projects:

• Wikiquote (quotations)
• Wikiversity (learning)
• Wiktionary (dictionary)
• Wikibooks (text books)
• Wikinews (news reports)

Add your voice to Wikipedia!

You can also work on similar sites that are not directly related to Wikipedia – such as WikiHow (how-to manuals) or others – but Wikipedia and its related sites are probably better because of their respectability, their focus towards writing (articles, etc) and their wide audiences.

Mainframe Linux: Pros and Cons

Why would one want to move Linux to the mainframe (such as IBM’s z10)? There are many reasons – and many reasons not to. Computerworld Australia had a good article describing (in part) some of the reasons the insurance company Allianz did just that. IBM has been pushing Linux on the z series for some time, and Red Hat and SUSE offer Linux variants for that purpose.

One common reason to move to a mainframe is that Linux servers have proliferated in the data center, taking up valuable space and becoming quite numerous. When all you need for a server is the hardware and a low-cost or no-cost Linux, then servers start popping up all over the place.

A single mainframe such as the z10 can handle thousands of servers (a test done in 2000 put 41,400 Linux servers on one IBM mainframe). The replaced servers can then be eliminated from the data center, freeing up valuable space and reducing the workload of current system administrators.

A common instance is where the company already has a mainframe in-house, running COBOL applications. Thus, the purchase cost of a mainframe (in the millions of dollars) has already been absorbed. Such a scenario also makes the case for a new mainframe much more appealing, as it puts the enhanced power to work immediately.

Replacing thousands of Intel-based Linux servers with a single mainframe will reduce cooling costs, power costs, physical space requirements, and hardware costs.

So why would anyone not want to use a mainframe?

If there is not already a mainframe in the data center, purchasing a mainframe just for the purpose of consolidation can be too much – mainframes typically cost in the millions of dollars, and require specially trained staff to maintain. Adding a mainframe to the data center would also require training current staff or adding new staff. A new mainframe also requires a new support contract. All of this adds up to not just millions of dollars of additional cost up front, but additional costs every year.

Another consideration is the number of Linux servers in the data center that would be moved. If there are dozens – or a hundred or two – it may not be entirely cost-effective to focus a lot of energy on moving these servers to the mainframe.

A supercomputer such as HP’s Superdome (with its attendant iCap and Integrity Virtual Machine capabilities) would probably be a better choice to consolidate dozens of Linux servers. The costs are lower, and the power requirements are lower – and you can purchase as much or as little as you need and grow with iCap. Most companies also already have UNIX staff on hand, and adapting to HP-UX is not generally a problem if needed.

Another benefit is that a server such as the Superdome offers virtualization of not just Linux systems, but Microsoft Windows and HP-UX as well – and soon, OpenVMS as well.

Using a large Intel-based server can virtualize a large number of servers with software from companies like VMWare and Sun.

These options won’t necessarily allow you to virtualize thousands of servers – but then, do you need to?

Why I Hate Radio (mobile – wifi – et al): A Rant

I’m fed up with how things are with radio – at least with amateur radio (which I enjoy thoroughly) you can do something about these problems.

Sitting here in the local library and using their wireless, my system is re-negotiating about once a minute (there it goes!) which means that any web pages stall or die half-way through, and Firefox may lock up entirely until the network either returns or fails outright.

Another (larger) library nearby provides the same service without the constant reconnection to a new wireless access point – although that library has poor reception in various areas; better take that laptop on a ride through the library to get the best reception. Some sections of that library have no reception at all (like the children’s section).

Yet another (but very small) library has excellent wireless – presumably because they have only one access point which blankets the entire library (I said it was small).

None of this talk of wifi talks about the speed: 11Mb/s is a theoretical maximum for 802.11b which was surpassed in the 1980s by 10BaseT (which is now obsolete).

Mobile phone response is no better. From my house, I can see the phone tower – though it is not overhead, but a half-mile away or so. Even so, I can’t get a connection, every phone call is a mash of incomprehensible clips, and the cellular internet comes and goes (but mostly goes, dropping off or not allowing connections at all).

This cellular reception is from a company that provides blanket service across the upper midwestern United States.

When will wifi and mobile phone carriers provide strong, constant access without dead spots, and with reasonable speeds?

SSL Protocol Vulnerability – and Confidentiality

There was an SSL vulnerability revealed last week – a design flaw in the protocol itself. There are two very notable things in this news: the vulnerability being in the protocol itself (like DNS and SNMP before it), and the way news of the vulnerability was broken.

The flaw in the protocol was discovered in August by researchers at PhoneFactor, and the vulnerability was released confidentially to those who could fix its problems and produce fixes for the vulnerability.

This flaw was then discovered by an independent researcher, who likewise released the vulnerability confidentially to an IETF security mailing list.

The problem was that a reader of that mailing list did an irresponsible thing and let the news of the SSL protocol vulnerability loose by sending a tweet message about it on Twitter to all of their friends – which meant that the news was set to be released to everyone. Mark Twain said: “Three people can keep a secret if two of them are dead.”. This problem of vulnerabilities and of when and how to release the news is not new; nor is the problem of the unknowing releasing confidential details.

The problem with security vulnerabilities and confidentiality is legend: it has become one of those arguments that never quits: do you release the details of a vulnerability as soon as they are known or do you wait for the fix to be released after confidentially notifying affected vendors? The uneasy answer most often reached is that a combination of both is necessary.

The problem of tweet messages releasing confidential information has happened before; one most notable incident was when Congressman Pete Hoekstra (R-Mich.) let slip news in Twitter about his trip to Baghdad. This news was then picked up by Wired, the New York Times, CNet, and – of course – the Congressional Quarterly.

In the security arena, confidentiality is much more critical – as is evidenced by the fact that Twitter itself was attacked with this vulnerability just in the last few days.

When you “speak” on the Internet, the world will hear: so be careful what you say.

Subversion joins Apache

ApacheCon 2009 ended recently – and like other good conferences, there were a number of announcements of interest.

One of the interesting announcements was on 4 November 2009, when the Subversion project (currently hosted at Tigris.org) announced that they would become absorbed under the Apache Foundation umbrella as part of the Apache Incubator. (Subversion has an excellent online book available).

There doesn’t seem to be any licensing change. It should not affect other projects based on Subversion; most notably for this author is SVNKit, the Java-based client library – which, in theory at least, will run under OpenVMS with Java.

About Blogging – and Journalism

There is a very interesting article over at the Columbia Journalism Review about how U.S. Supreme Court Justice Antonin Scalia was misquoted, and the diversity of reactions by the various media outlets (including old school and new school) that had to correct their words.

What makes this even more interesting is the article by Mike Masnick over at TechDirt: he views blogging as a conversation between the blogger and the readers. This caught my attention, since I have a strong interest in journalism in general, including blogging.

I’ve often thought about this – correcting articles – and what the style of my corrections should be. Unlike Mike in his article, I view this endeavor (and others like it) as a form of journalism: thus, small edits will crop up in my articles from time to time. Large edits (or additions) warrant an appropriate journalistic notification: I use the word “Update” (in bold) to expand an already written article.

To me, the conversation is about the article and takes place in the comments – which conversation has proven valuable more than once. I view each article as a journalistic piece and try to fix any errors as they show up without a lot of fuss (except for giving thanks to whoever might have pointed an error out).

Speeding up the Web: a new protocol

Google has revealed a new protocol – SPDY – that has been part of a research project to speed up the HTTP protocol that makes up the Internet. The speed increase is amazing – and sorely needed.

There is already a development version of Google’s Chrome browser available that supports SPDY; the branch is code-named Flip.

This new protocol requires a modified web server; this will be forthcoming from Google in the future. This is an exciting development that bears watching.

Laissez-faire Security – A Good Thing

Bruce Schneier wrote today about a paper that describes something it calls laissez-faire security: the idea that tight role-based security (RBAC) will lead to situations where the security prevents people from doing what they need to do for their jobs, which subsequently leads to normal people finding ways to circumvent (and weaken) security.

The proposal presented in the paper Laissez-faire Security (by two researchers from Columbia University and two from Microsoft) suggests that rather than tightening things down, one should audit strongly instead. One of the authors, Steven M. Bellovin, is a luminary steeped in the history of the Internet, in the security arena, and one of the founders of Usenet.

The results of RBAC can be seen by every administrator sooner or later – many times, experienced personally. SELinux is a perfect example: despite its acknowledged security benefits, it is commonly disabled or left in an “advisory” state only because of the problems in implementing such a restrictive policy.

From a user perspective, there are numerous examples of people bypassing security in efforts to share data or to utilize tools to get work done.

Laissez-faire Security is about letting users select the appropriate security rules within a framework of policies – which they can ignore (after notification and auditing) – at their own peril. The policy violations can then be handled outside of the computing environment in other ways if needed.

The paper compares computer security to an economy and to the workings of the free-market economy in particular. This paper is very interesting reading and would be worth reading for any security-minded administrator.

The Domain Name System (DNS), Internationalization, and More

The DNS service has been in the news recently, most specifically when ICANN held the 36th ICANN Conference in Seoul, South Korea and decided to allow internationalized country code top-level domains (abbreviated as ccTLDs). The Russians and the Chinese have been after ICANN to do this for some time – and not with any real resistance from ICANN either. Over at the CircleID blog, they have a nice recap of the meeting.

The biggest problem was technological, and over the last several years ICANN and the DNS powers-that-be have worked diligently to implement a method of supporting Unicode domains – the approved method was the Internationalizing Domain Names in Applications (IDNA).

The biggest problem – which unfortunately hits the Russians and other users of the Cyrillic alphabet hardest – is that some of the domains will look like Roman (alphabet) domains. The most prominent example is the counterpart to the current .ru domain; the equivalent cyrillic example would be .py (which is the Republic of Paraguay). Of course the computer has no problems – the letters are different – but the human user could confuse the two, making a new angle to phishing attacks.

The presence of new internationalized domains may make a difference to you if your company is international – especially if it is located in another country. Countries such as France and Canada and Mexico won’t be affected, but many others will be – Japan and China and many Middle Eastern countries come to mind (with Japanese, Chinese, Arabic, and Hebrew domains coming to mind).

Getting a new international domain will mean making sure that all programs can handle the internationalized domains – such as mail clients, mail servers, local DNS servers, and more. Unless a complete conversion is mandated, it can be done alongside of the current working DNS service. Make sure that you brainstorm and work with as many affected individuals as possible to make the new DNS domain work; this becomes especially critical during a total conversion.

On the heels of the wrap-up of the meeting in Seoul is Paul Vixie’s article in the ACM Queue entitled What DNS is Not. He talks about how DNS is not a policy-making protocol, but rather an expression of facts (mapping names to addresses).