Stress Relief: Laugh Out Loud Humour

After a stressful day, if you don’t release that stress it will eat you alive – and there’s more truth than analogy in that statement.

The best humour is doesn’t make you smile – or chuckle – but rather laugh out loud funny. The ideal is humour that makes you laugh uncontrollably. Humour can be serious business, especially as a stress relief.

Humour is, indeed, a very personal thing: what makes some people laugh others will find offensive. After a recent particularly stressful and late night, I found myself wandering through YouTube for my favorite comics. Unfortunately, famous or not, some will be found more often than others.

My favorite comics are these:

• Bob Newhart
• George Carlin
• Bill Cosby
• Sam Kinison
• Robin Williams

Personally, I think George Carlin is a comic genius. One thing that I note of virtually every comic listed there: they can take the most mundane things and find the hilarity (I remember George talking about getting milk from the refridgerator!).

Teasers from George Carlin:

• About “non-stop flights”: “I insist that my flights stop – preferably at an airport!
• “Of course [the program] was “prerecorded”! When else you going to record it – afterwards?

10 Programming Languages Worth Checking Out [from H3RALD]

This article (10 Programming Languages Worth Checking Out) over at H3RALD is very interesting. If you seek out new things to learn, and new computer languages to program in, then this article should pique your interest.

The languages listed are: Haskell, Erlang, Io, PLT Scheme, Clojure, Squeak, OCaml, Factor, Lua, and Scala. There is also a To get you started… section for each language with pertinent links for learning more.

I was surprised to find that at least six of these languages have significantly caught my attention already. I find Lua to be absolutely beautiful and a delight to program in (my PalmPilot has PLua loaded all the time). Squeak is just Smalltalk-80 kept alive – and Smalltalk has been of interest to me ever since I learned of it decades ago. Haskell and Erlang are interesting, too – but I’ve not followed that up with learning yet.

Now Scala and Clojure have my attention. Unfortunately, Clojure almost seems like it takes the simplicity of Common Lisp and trades it in for complexity. I don’t find the “complaints” against Common Lisp to be valid; I’d rather see Common Lisp implemented in Java than a Lisp-derivative.

I expect I’ll be talking more about Scala as time goes on – this language has caught me good.

OpenVMS and Network Information

If you don’t know where to look, OpenVMS networking information can seem to be confined inside a mysterious black box. It doesn’t have to be.

The ANALYZE command can provide a lot of good information. Be sure to have a large enough scroll-back buffer on your terminal when you do this:


$ ANALYZE /SYSTEM
SDA> SHOW LAN /FULL


You can also find out a lot of good information in a hurry with the LANCP command:


$ RUN SYS$SYSTEM:LANCP
LANCP> SHOW CONFIGURATION


You can also look up information using the TCPIP command:


$ TCPIP
TCPIP> ifconfig -a


However, while this information is all good, it isn't complete without marking the back of the computer in some way so that you know which port is which. If you have to, you can hook up a laptop with a network cable and watch the traffic: the DECNet clustering traffic is such that you'll see it on every active interface - which provides you with the MAC address for that port.

Scripting on the Java Virtual Machine

Now that OpenVMS has Java, and that HP-UX has Java, I started wondering about the possibility of running a scripting language on the Java Virtual Machine (JVM) as a way of supporting all these diverse environments with the same code and tools.

Choosing a language can be difficult, especially when there are so many good ones to choose from. I’ll assume for purposes of discussion that one is already familiar with at least one or more computer languages already (you should be!).

So what are the criteria a system administrator should use to choose a language on the JVM?

• Does the language have a strong and vibrant community around it? The language might be nice, but if no new development is being done on it, it will eventually fail and stop working on the newer JVM. Bugs will not be fixed if development has halted. It also helps to have a large variety of people to call on when trouble arises, or when your code has to be maintained in the future.
• Does the language support your favored method of programming? If you have no desire to learn functional programming, then don’t choose a language that is a functional language. Find a language that thinks the way you do (unless you are specifically trying to stretch your mind…).
• Is your preferred langauge already available for the JVM? There are implementations of Ruby (JRuby), Python (Jython), LISP (Armed Bear Common Lisp), Tcl (Jacl) and many others. A language that you already know will reduce your learning time to near zero on the Java Virtual Machine.
• What are the requirements? For example, JRuby requires a dozen libraries; Clojure and Armed Bear Common Lisp have no outside requirements. Which is simpler to install onto a new machine?

So what languages am I looking at? I am looking at these:

• Clojure – a LISP-like functional programming language which seems to be taking off handsomely.
• JRuby – Ruby is my all-time favorite scripting language, and having it available whereever the Java VM is is a very tintillating prospect. It’s also directly supported by Sun, the makers of Java.
• Groovy – this is a new language that takes after Ruby and Smalltalk, and it is growing in popularity at a dramatic pace.
• Scala – this is a language with a strong developer base and an object-oriented and functional design. Don’t know much more about it yet.
• Armed Bear Common Lisp – ABCL is a full Common LISP implementation for the Java VM, and is used as part of the J editor. Unlike ABCL, development on J seems to have stopped; development on ABCL has gone through a resurgence after not quite dying for several years. ABCL is the closest thing to LISP on the JVM, and is usually the first mentioned – even though its development community is not nearly as strong as Scala or JRuby.

These are only the ones I’ve chosen to focus on; there are many, many more.

Two New Admin Resources: ServerFault.com and StackOverflow.com

I’ve discovered two new question and answer resources for administrators: one is specifically for system administrators, and one is for programmers.

These are StackOverflow.com and ServerFault.com. These sites look and work similarly, though the topics and logos and color schemes are different, so while it is as easy to use one as it is the other, there is no doubt as to which one you are using.

These sites combine a number of things together to provide excellent community answers to questions posed by anyone. There is no registration required (!) but if you register, you can do more and you can build a reputation that allows you to do quite a lot. If you get a high enough reputation, you almost have full access – just like the administrators of the system.

The answers are excellent and the Q&A sets are building rapidly.

Perl Tidbits: Annoyances and Surprises

Having given up Perl at one time to use Ruby almost exclusively, I have returned to Perl in recent years since Ruby is not available for HP-UX 11i v3 nor for OpenVMS 8.3. Perhaps some Ruby folks are listening; it is abominable that HP-UX 11i has gone without Ruby for so long. It would be nice to be able to say that it is shameful that Ruby doesn’t exist on OpenVMS 8.3 – but we know how popular OpenVMS is…

Here are some of the things I’ve discovered in bits and pieces about Perl since my “return”:

• HP-UX does not use the Perl core, but rather ActiveState Perl. This may not sound like much, but it can be important when using modules. For instance, the Net::FTP module has a bug in it that causes the last character of ASCII transfers to be “snipped”, and several Perl core modules are missing entirely.
• It is possible for Perl to quietly abort without warnings. This makes no sense, but I’ve experienced it. Only stepping through the code with the debugger will show what line it is – and removing the line in question makes the program start working again.
• Using CPAN can corrupt your HP-UX Perl installation. I suspect this is because CPAN assumes that you are using the Perl core, and if not, then things can break. In my case, the module Data::Dumper was hosed so bad I needed to reinstall Perl.
• Perl requires an additional module to emulate Ruby’s p command. This was a real disappointment; attempting to print data in a readable format (no matter what its type) is a simple command in Ruby; in Perl, you must include an additional module and use a function with a confusing name (is it Dump? or is it Dumper? or is it dump?) – I often have to correct my code to use the right one.
• Testing for a module’s existance is easy. Use the command perl -e 'use My::Module;' to see if the module is there.
• Don’t think of $var as the name of a variable, but as the value of a variable. Just this one change in thinking has made a tremendous amount of difference in programming. When you think this way, you see an entry like @myarray[4] for what it is: a list with a single element in it. Likewise, $mine{entry} is a scalar value returned from a hash. The same “variable” can be found with differing leading punctuation based on its value, not on its type.
• If your script needs to be portable across platforms, then write it in Perl. The Korn shell is nice and even more ubiquitous than Perl, and Ruby is (in my opinion, anyway) much nicer than Perl, but Perl is where ksh and Ruby are not. Being there is a significant part of the battle: if that snazzy scripting language isn’t installed, you can’t use it – and Perl is there.
• The documentation (in perldoc) is tremendous! Use perldoc whenever you can: it includes more than a man page would. It includes tutorials, frequently asked questions (FAQs), module documentation, function documentation, and more.

Though I’d still write in Ruby at the drop of a hat, I have indeed rediscovered the joy of Perl. Part of this is due to a book that has illuminated the dusty corners of my knowledge: Effective Perl Programming by Joseph Hall with Randal Schwartz – an awesome book!

Solaris 2009.06 (and 2008.10) on an HP nc4010 Laptop

This laptop is a delightful little machine, and borders on being a “netbook” though it has better specs than what would normally be called a netbook. Last night, I overwrote my Solaris 2008 install (of no more than a week or two) with the very latest Solaris 2009.

Since I had problems with running the LiveCD with a full X display, I opted for the text console and began the installation from there. Installing from text mode is simple, but mostly undocumented:

1. Find an X server to use. There are nice X servers out there, not to mention the ones included with every UNIX and Linux installation. I use the Xming server for Windows.
2. Boot the OpenSolaris LiveCD into text mode.
3. Configure the OpenSolaris client to use the remote X server display. This could be as simple as logging in as root (password opensolaris) and setting the DISPLAY variable. This, of course, is not secure: to be secure, log in as root, start the ssh server, and log in over the network using the command ssh -X.
4. Start the install process. This involves the code: pfexec /usr/bin/gui-install. After this, the GUI install process should appear on the remote display and the expected install process can begin.

Installing OpenSolaris this way onto the HP nc4010 was smooth, and the environment works well and is clean. There is a lack of official applications, but this may be expected, though disappointing: open source focus on OpenSolaris is not what it is for FreeBSD or for Linux.

The machine has a 1.7GHz Pentium M and 1Gb of main memory; this seems sufficient – so far. This machine is likely to become my secondary: the primary is Linux Mint – with all of the applications that a Debian/Ubuntu derivative can count on.

Quality User Interfaces: Only for the Young and Very Old?

I was reading up on the Jitterbug – a phone that was designed to be easy to use. I thought that here, finally, was a product that took user interface design seriously – but imagine my surprise as I found myself getting angrier and angrier as I read more about this product.

What is there to get upset about? Just this: the product sales talk suggests that a quality user interface and ease of use is only for those who aren’t “able” to handle the more complex (and harder to use) interface of today’s typical mobile phone.

This plays to a common misconception among users and the public at large: if something is “hard to use” it is because you haven’t yet taken the time to learn how to use it. When I’ve complained about poor user interfaces in the past, I’ve been told it’s easy once you learn how.

The CMO Council (the CMO is the Chief Marketing Officer) and the Forum to Advance the Mobile Experience (FAME) teamed up in 2007 to survey mobile phone users around the world. The survey is the Global Mobile Mindset Audit and has some interesting bits of information. One particular tidbit was noted in the headline in the USA Today article Cellphone Users Complain about “Function Fatigue”: too many functions on the phone that will never get used. This was also noted in the article A Phone without Frills written December 7, 2007, for SignOnSanDeigo about the Jitterbug.

To quote from the Global Mobile Mindset Audit survey:

The industry’s preoccupation with one-upmanship on features and functions does little to improve the elegance and appeal of products. The number one problem voice by users in every region was “too many functions I did not use.”

Other problems included the fact that typical phones are difficult to use – quoting again:

[...] other reported problems [included] user manuals not being very good, devices being hard to configure or customize, and simple product requirements, like volume control, being deficit.

The article from the April 6, 2006, Fortune (discussing the introduction of the Jitterbug and other devices at the 2006 CTIA Wireless conference) by Peter Lewis titled Cellphones for Kids – and Seniors shows the previaling thoughts when he writes:

Jitterbug, also launching later this year, consists of a simplified mobile phone and service designed especially for baby boomers and their parents.

Peter later refers to the “technology-phobic baby boomers.” I wonder what Tom Peters would say about that?

One of my most favorite commercials is the Apple “Manual Ad” – in this collection of old Apple ads, it starts at 2:30. It presents an IBM PC – then its manuals. Then it presents an Apple Macintosh – and its manuals. The contrast is striking.

What is it about the mobile phone industry that it just will not listen to its users and give them something easy to use? That’s why the iPhone is so popular: it comes from a company that shows time and time again that it listens to its users and designs its user interface for usability. As soon as I can use an iPhone on my choice of carriers – a carrier known for customer service and for blanket mobile phone coverage in the Midwestern United States – I’ll look at the iPhone. Until then, I’ll stick with the iPod Touch – if ever I get one.

Why You Should Learn Perl

Previously I spoke on why one should learn vi (summary: learn vi because it’s on every UNIX and Linux system you’ll install…). Well, why should one learn Perl?

Because it’s only every UNIX and Linux system you’ll install…. and on OpenVMS… and available for Windows, too.

Unlike vi, I’m not as big a fan of Perl as I once was: having been interested in (and a fan of) object-oriented programming (OOP) for years – it only took Ruby little time to dislodge me from my interest in Perl (that would have been just prior to Perl 5).

Yet, this does not matter: Ruby is nice, but not ubiquitous. In particular, making Ruby run on HP-UX has proven to be extremely difficult in recent years – and it is not loaded by default in any case. I don’t know of any UNIX that installs Ruby as part of the base package (or that makes it available at all).

Learning Perl is not as hard as it may seem: since it is ubiquitous, there are many excellent books from which to learn Perl – and excellent references as well:

• Learning Perl by Schwartz, Phoenix, and Foy
• Programming Perl by Wall, Christiansen, and Orwant
• Effective Perl Programming by Joseph N. Hall with Randal L. Schwartz
• Perl in a Nutshell

I have all of these, and find all of them to be useful. In my progression of learning Perl (or relearning it…) I find that Effective Perl Programming is fantastic. Specifically, presents a series of items (or tips) then shows you how to use and understand the tip in detail. I recommend this book fully.

Don’t neglect Perl, as it is everywhere, unlike any other language (including Korn shell!). If all you write is Korn shell, then your program will be unusable in any environment that does not provide ksh (think Linux and FreeBSD and OpenVMS for three). It’s true: ksh is not installed on Linux by default: bash is – and FreeBSD uses the C shell. However, all three environments provide Perl.

Using NET-SNMP and HP-UX SNMP together

Why would one want to do such a thing? A major reason is that the HP-UX SNMP daemon only supports the EMANATE protocol for subagents; this means that subagents that support the AgentX protocol (which NET-SNMP – provided as part of HP’s Internet Express – supports) are not supported and cannot be accessed via HP’s SNMP daemon.

However, the HP-UX specific information is only available via the HP-UX native SNMP daemon. What is the answer?

Change one or the other to run on a non-native port, that’s the answer. With the two daemons listening on different ports – in essence, acting like to discrete damons – the capabilities of both can be exploited. Since the native HP-UX snmp daemon does not provide the capability of specifying the port, the net-snmp daemon can be moved – and it is relatively trivial to do so as well.

There is probably already a line that says:

agentaddress 161

Change this line to a new port – I used 166:

agentaddress 166

Restart the daemon. Once the NET-SNMP daemon has been moved, enable HP’s SNMP daemon (if you’ve not already done so) and start it up again:

cd /sbin/init.d
SnmpMaster start

This should enable your two SNMP daemons on different ports. Now you can access whichever one holds the data you want. For example, using the command snmpwalk, getting Caché data can be as simple as:

snmpwalk -m ALL -v 2c -c public my:166 .1.3.6.1.4.1.16563

Whereas getting HP-specific data can be retrieved this way:

snmpwalk -m ALL -v 2c -c public my .1.3.6.1.4.1.11

Note the contrast between the two commands: one accesses the host my with the standard port (my); one uses the host my with the port 166 (my:166).

As a side note, note that Caché provides AgentX subagents, and note, too, that OpenVMS supports SNMP and AgentX as of v8.x. Thus, there’s no fighting with the SNMP daemon on OpenVMS.