Archives For April 2014

longford, kansas

April 27, 2014

bethel evangelical united brethren church

I drove to the small town of Longford Kansas on Saturday to help my wife complete a part of her family story. Her father was born in Longford in 1905, and lived there until he was four, moving to Pennsylvania along with his older sister and mother when he was four. The circumstances surrounding their move back to Pennsylvania is heartbreaking.

In 1909 a third child, a daughter, was born into the family. While she was an infant, she became ill. A local doctor diagnosed the problem and a method of treatment that required medicine. The husband took the money and went off, ostensibly to buy the medicine. Instead he went off and got drunk. He didn’t buy the medicine, and the daughter died. Rather than go back and face his wife, he instead traveled to Reno, Nevada, and got a quick divorce with some of the money he had left. The mother, distraught over the loss of her baby, now had to deal with being a single parent with two young children, two children she refused to abandon. She wired back to her sister in Pennsylvania, and had the sister wire some money back to her to bury the child and then travel back east. They passed through Harrisburg, settling in Williamsport, where the mother became a school teacher and remained a school teacher for the rest of her life.

The four year old boy grew up to become a Methodist minister and the father of my wife, who was the youngest of his three daughters. He spent the majority of his ministry in the Harrisburg area, eventually moving to Emporium, his last charge.

Longford played a part in my father-in-law’s life even after he’d grown up and was a minister. He needed to travel to Oxford, England, as an outstanding Methodist minister in 1967 (the 200th anniversary of John Westley’s establishment of the Methodist church) and he needed a passport. Then, as now, you needed a birth certificate. But back then, in 1905, in Longford, you didn’t get a birth certificate, your birth was registered at the local church through baptism. Sure enough church records recorded his birth and baptism as well as who his mother and father were. With that information wired back east, he was able to give credible evidence of his birth as an American citizen and get his passport.

I drove out, looking around the town, took some photographs, and then tried to find the spot where the young infant might be buried. Unfortunately the church was closed, and I couldn’t find the parsonage where I might have spoken with minister. I found a close-by cemetery, but didn’t find anything that might have been a children’s section or even anything that might have been her final resting place. And I didn’t expect to. I believe that the mother barely had enough money to cover the cost of a funeral, let alone a marker for the grave. And even if she had, I can imagine it being simple, so simple that it either would have worn down, or completely disappeared after a century of exposure to the elements in Kansas. I’m still looking through other means to see if I can at least track down the cemetery where she might have been laid to rest. I don’t believe I’ll ever find the grave site.

My father-in-law (who has long since passed away) and his family’s story is not the only one, I’m sure. Turn of the 20th century life in America was still harsh (and in many ways, still is), and this story played out innumerable times across the west. Women had a hard time of it, particularly mothers with children. Although Kansas would pass full suffrage in 1912, and the 19th amendment granting women the right to vote would be passed in 1920, this was the first decade of the 20th century and out in the rural farmlands of Kansas. There was no structure in place to go after the wayward husband, neither for child support or the greater charge of manslaughter. To add insult to injury, a divorced woman at that time was considered a pariah, regardless of the circumstances. What husband would be so selfish to abandon his wife to such a fate, or a father so inhuman to allow their child to die?

chruch cornerstone

infant angel

city hall

edge of town

gathering of hay

For a town that was so small, I still managed to spend nearly three hours there, walking around. I spent a good portion of that time at one of the local cemeteries about three miles north of the town. While I was there in town it was totally quiet. No urban noises to be heard anywhere. The single spot in the business center of town consisted of a gas station, a bank, the town hall, and a place to eat. I grabbed a “beef sandwich” while I was there, which consisted of a bit of roast between two large pieces of white bread, with mashed potatoes on top and all of that slathered in gravy. I ate some of the mashed potatoes, and then dug through the bread to eat the beef. It was a short meal, with one of the patrons deciding to sit next to me to chat. I’m no chatterer, which made for long periods of silence at my table. I was quickly finished and left cash at my table, the cost of the meal plus a tip.

I mention the lack of noise, but it wasn’t silent. What I did hear was birdsong and the constantly blowing Kansas wind. It was strong enough at one point to push forcefully against me, up on a hill in the cemetery. I can’t even begin to imagine what it might be like to live with constantly blowing wind like that. And yet, in spite of it, I find a strong spiritual pull to the land.

The trip to Longford was nearly three hours one way, from Lansing just south of Leavenworth, west on I-70 through Topeka, and further west out to Longford. I’m a product of my American culture, from the mid-twentieth century, and one of the things we like to do is drive. And drive I did. The speed limit on I-70 is 75, and I was driving even faster, between 80 and 85. I have a Ford Fiesta rental this time, and its gas mileage, regardless of speed, averages 32MPG. If I’d had my Prius I’d have done at least 15MPG better.

I drove through a lot of Kansas history on the way to Longford. I expect to be coming back out to Leavenworth later in the year, so I’ll be headed back out to spend more time at some of those historical spots. Although Kansas City is a lot closer, and has a lot more conventional activities, I’d rather spend my time studying the “real Kansas.” Life’s too short to let those kind of opportunities pass by.

Camera

It’s been a very long time since I wrote about the camera I used when I posted an entry with photographs. But perhaps not this time. I’m in Kansas with my Olympus E-M5 and three primes; the Olympus 1.8/17mm, the Pan-Leica 1.4/25mm, and the Olympus 1.8/45mm. It’s the 17mm that’s the latest, and for all practical purposes, last addition.

This is the third 17mm I’ve purchased, the first two being the 2.8/17mm pancake lenses. The first was sold, the second given away. This third was bought the Saturday before I flew out to Leavenworth, with funds I got from KEH on the E-PL3 I traded in at Colonial Photo and Hobby in Orlando. I got pretty much all the money back I originally spent on the E-PL3, and Olympus had an additional $100 off sale on the 1.8/17mm at the time, so I picked up that lens.

It’s a very nice lens, all metal. I got the silver version, and to be honest, it looks good on the all-black E-M5. It’s not a true silver, but more a champagne color. I don’t care about lens colors any more. The lens is totally silent in operation and very quick to auto focus. The results are quite good to my eyes, especially the lack of chromatic aberrations. I pixel peeped the raw files a bit, and didn’t see any, especially in the branches. It was all over on the 2.8/17mm, especially in bright back lighting. But I had a lot of fun with the 2.8, and I’m having fun with this latest version.

For reasons I won’t get into just yet, I’ve been looking at cleaning up my moldering Python skills. It’s been years since I coded anything of significance in Python, and “back in the day” I did it because I had few other options, one of them being Perl. I refuse to write anything in Perl anymore, even though I started my long journey into interpreted languages with the pink Perl book published in 1991.

In the early days I fell upon Perl like a man dying of thirst falls upon an oasis in a desert. In my case, the desert was a mix of bourne and AWK scripting (and I came away positively loathing TCL). With Perl 4 I could build highly sophisticated tooling completely in Perl, and just use my shell scripts to launch my more sophisticated Perl scripts. I started with Perl sometime around 1993 and kept using it until 2000 when I upgraded to Perl 5. With Perl 5, Perl fell out of favor with me, and Python began to rise in its place. I found that Python, in spite of its FORTRAN-like use of spaces to determine scope, was close to C++ and Java than Perl. I found it easier to user Python, both as wrapper for Java and C++ applications as well as being a powerful development language in its own right.

But time moved on and the reasons for using Python fell away. I stuck with C++ and Java, with occasional forays into JavaScript.

And then, for reasons as I said I won’t go into just yet, I had a need to brush up on my Python skills. Except this time, rather than staying in Python 2, I decided to jump whole sale into Python 3, or 3.4.0. I grabbed a copy of the source tarball off the Python website, unpacked it in my Ubuntu 14.04 VM, built it with the configure/make/make install kabuki dance, and started to work with it.

To refresh my skills I started with simple apps, to get a feel for the basics in Python 3. I quickly put together a factorial application, the source and output of which follows:

#!/usr/bin/env python3

import sys

def fact(n):
    a = 1
    print( n, end="! = ")

    while n > 0:
        a, n = a * n, n - 1

    print(a)

if __name__ == '__main__':

    if len(sys.argv) <= 1:
        print("Factorial calculator. Must call with at least one number as argument.")
        sys.exit()

    for i in range(1, len(sys.argv)):
        fact(int(sys.argv[i]))

There’s not much to say about this application. It has one function (fact()). It can test for command line arguments and print out a message with no arguments. It has a tight, simple iteration in main to walk through any and all arguments. The output shows that Python can easily handle arbitrarily large numbers without invoking special features. That alone is one reason it’s used in scientific computing.

While I don’t like how spacing is used to delineate scope, it does remove the need for curly braces used in other languages such as C++, Java, and Ruby, to name but three. What follows is the same application, this time written in Java 8.

import java.math.BigInteger;

public class Fact {
    public static void fact(String num) {
        System.out.print(num + "! = ");
        BigInteger a = new BigInteger("1");
        BigInteger n = new BigInteger(num);

        while (n.compareTo(BigInteger.ZERO) > 0) {
            a = a.multiply(n);
            n = n.subtract(BigInteger.ONE);
        }

        System.out.println(a.toString());
    }

    public static void main (String[] args) {
        if (args.length < 1) {
            System.out.println("Factorial calculator. Must call with at least one number as argument.");
            System.exit(1);
        }

        for (String number : args) {
            fact(number);
        }
    }
}

The syntax is radically different between the two, which is to be expected. Of significant difference is the use of java.math.BigInteger to match Python’s ability to use numbers of arbitrary size and precision. When I first wrote this I used regular integers (int) and could only calculate factorial 11 (11!) before the integer product became negative (sign overflow) and then went to zero. Using BigInteger solved that problem, but introduced a far more complex coding method. While the Java application is only six lines longer, its fact() function is a lot more complex than the fact() function in the Python example. Whereas the Python code can handle the numbers with the same old syntax, special functions within the BigInteger class have to be used to perform basic math (multiplication and subtraction) and the while loop comparison is a somewhat obscure big class function in Java, while with Python its the straightforward comparison we’ve all come to know and love.

In this specific example, the Python code wipes the floor with the Java code, or at least it does for me. There’s a certain sparse (dare I say beautiful?) elegance with the Python code not needing all the matching curly braces that Java requires (and C++, too, for that matter). From a purely coding standpoint, and with this very very narrow example, I find I prefer writing in Python. Maybe larger, more complex coding projects will continue to favor Python over Java, and then again, maybe not. While I want to continue working this kind of duality and comparison, it’s going to reach a point where I’ll need to make a decision when to use which, and stick to it.

I’m surprised, however, how much I like coding in Python. Have I reached a point in my coding life where I should do the majority of my work in Python, moving on from C++ and Java? Maybe even from JavaScript as well.

No sooner had I written about the folder sharing problem between Ubuntu 14.04 VM running with VMware Player 6.0.1 and the Windows 8.1 update 1 host than VMware 6.0.2 update arrived and fixed the problem. I was able to successfully build the vmhgfs driver, after which I could mount the C:\Share folder as /mnt/hgfs/Share under Ubuntu 14.04. You can see the screen capture of File’s view of Share.

In the last post I wrote that Unbuntu 14.04 LTS was one of the best, if not the best, operating system you can install on today’s personal computers. By personal computer I mean desktop or notebook. For other devices, such as phones and tablets (read ARM-based) I have no idea. Making some sort of sweeping claim in that domain, based on preliminary software running on preliminary hardware, is a foolish action. Let me just say that based on my experiences with both iOS and Android[1] that Ubuntu does have a chance, although they’ll need to pay very close attention to the user experience to gain a foothold. The user experience with Ubuntu Desktop is excellent, which is why I heartily endorse its use (Richard Stallman’s FUD notwithstanding).

While I certainly understand all the attraction with portable devices, the real interesting work is being done on the server side. Ubuntu is positioning its server products for both individual use and as part of the “cloud” infrastructure. Ubuntu is now marketing the Ubuntu Server software stack with OpenStack, the open source virtualization/”cloud” framework. OpenStack is interesting in that its genesis came about as part of a collaborative effort between NASA and Rackspace in 2010. They developed it on Ubuntu, which became the default OS for deployment. Over the years that followed, just about everybody of note within the “cloud” vendor community joined in. It should be noted that NASA dropped out of active participation in 2013 citing “lack of technical progress [PDF].” It instead decided to look at using public “clouds” to use. Personally I look at this as some bean-counter having gotten into the middle if it. After all, if there’s anyone who should be providing technical leadership to drive technical progress, I can’t think of anyone better suited than NASA. But then, what do I know…

It was Ubuntu 11.04 that started to officially begin integration of OpenStack, starting with the OpenStack “Bexar” release. Full support came about with Ubuntu 11.10 and the OpenStack “Cactus” release. It wasn’t until 2012 and OpenStack “Essex” that Redhat announced a preview for RHEL (they may have started earlier with Fedora, as I remember Fedora 18 having OpenStack in its repository system). Formal Redhat support came at the end of 2012 with the OpenStack “Grizzley” release. Canonical had started integration and support within Ubuntu a full year before Redhat. The fact OpenStack was initially developed on Ubuntu, and official Ubuntu support starting with 11.04, are big pluses for Canonical over Redhat in my book.

Having written all those positive words, there are some negatives to consider. Just google for “openstack problems” and see what pops up. For example, there’s this story, titled ““Backbreaking” OpenStack migrations hinder enterprise upgrades,” with the following lovely summary:

OpenStack’s promise of an open-source cloud infrastructure free of vendor lock-in is big. But difficulties upgrading from one release to the next are a major kink that needs to be worked out before widespread adoption can begin.

Or consider this article written on The Register November 2013, titled amusingly enough, “Gartner: OpenStack in the enterprise? Ha ha ha, you must be joking,” in which they cite a Gartner analyst:

The OpenStack world has come in for criticism from a Gartner analyst because the claims made by companies backing the open-source project frequently don’t line up with reality.

In a forthright post published on Tuesday Gartner analyst and research director Alessandro Perilli chided the OpenStack community for a lack of clarity, lack of transparency, lack of vision, and lack of pragmatism.

OpenStack is touted as being an open-source infrastructure deployment and management engine that lets companies load up a free software suite to help them take on proprietary cloud giants such as Amazon, Microsoft, and Google.

But besides Rackspace and HP, few public implementations of the product exist, and it doesn’t seem to have accrued the level of cash necessary for it to slow the rise of the mega-clouds.

Perilli put some of the blame for this slow growth at vendor marketing (and credulous tech press reports) that have claimed OpenStack is making huge strides into the enterprise, when in fact it’s barely there at all.

“Don’t believe the hype generated by press and vendor marketing: OpenStack penetration in the large enterprise market is minimal,” Perilli said. “Yes, there are some ongoing deployments that can’t be disclosed yet, but for one promising or successful deployment there are several that fail and that will forever remain undocumented.”

The criticisms line up with a recent wave of discussion that has percolated through the cloud industry as the community starts to wonder why after three years of major development the OpenStack technology is still lacking key features at its core, and why so few people seem to be making much money from it.

This reminds me of my so-called early days in 2007 with Ubuntu. As I noted in the last post, I dropped Ubuntu (and Linux in general) because of the difficulties upgrading from one release to the next. Yes, those updates were a “major kink,” primarily because of hardware (read: video primarily) regressions. If OpenStack has been, essentially, a series of pre-releases with major changes in the product, then it’s a train-wreck in progress. My experience to date have been with VMware (ESXi 4 and 5), and it has worked flawlessly. When I handled an upgrade from ESXi 4 to 5, it went without a hitch. I had over 60 VMs on a small two-server stack, and nothing happened. Except it all came back up and everything continued on, as it should.

I like the promises being made, but I won’t get stuck with a poor product because it’s free and open. Ideology, no matter how pure, don’t pay the bills if it leads to poor or broken products. The only way to test this out is to actually invest in some decent hardware and install the software. It may be that 14.04 LTS is the best way to get started with this.

I truly hope that Ubuntu has invested some considerable effort to polish and harden OpenStack for 14.04. They seem to have established themselves on the server front, as that’s the area where they seem to be “cashflow positive.” And I take everything, both hype and hyper criticism, with a lot of skepticism. The truth, as usual, is somewhere in the middle of all that mess.

 

[1] I have not tried Firefox OS for mobile. And Tizen is a mess, what with Samsung having introduced three wearable product groups with Android, Tizen, and now Android Wearable, in that order.

Yesterday I updated to Ubuntu 14.04 LTS, or simply Ubuntu 14. For the first time in all the years of my experience with Ubuntu, I’m moving to a long term support (LTS) release with every intention of staying there. Whether I’ll stay with 14.04 for the full five years that Canonical guarantees security updates, or update to 16.04, depends on how much progress is made at the next LTS release two years from now in 2016. But as for installing the latest every six months, I think I’ve moved well past that point. And that’s actually a good thing. I’ve been a long time user of (and at times, battler with) Ubuntu going back to 2007 and Ubuntu 7.04. I started trying Ubuntu with the first alpha release of 7.04, and ended my first attempts at using Ubuntu with 7.10. That was the year I also wrote “It isn’t worth the trouble anymore” due to my experiences upgrading to Ubuntu 7.10 and openSUSE 10.3 on two home systems. I’d had all I could stand upgrading and then fighting introduced hardware support regressions. I was also using Windows XP at the time, and in spite of the fact Vista had been released nearly a year prior, I wasn’t going to dive into that “bag of hurt” while running away from the Linux bags of hurt. Nope, no way. But time heals all wounds, and even Linux can show improvements. In the case of Ubuntu the improvements are substantial and world class. Where I have, in past critiques, been quite brutal in my assessments, I have to say now that Ubuntu is one of the best, if not the best, Linux distributions you can get get. Period. In fact, I’ll make the following statement for the record;

Ubuntu is one of the best, if not the best, operating systems (including Windows 8.1 and Mac OS X Mavericks) you can install on any personal computer. Period.

If you’re considering an upgrade from Windows XP and don’t want Windows 7 or later, and further assuming you’re not beholden to some very specific software application that must run on Windows XP, then you should consider Ubuntu 14.04 LTS. It really does have what it takes to challenge Windows, especially anything older than Windows 8.

I upgraded my Samsung R580 notebook that had been running 13.10 to 14.04 without any incident. When it finished it came up with all my settings intact and everything functioned exactly as it did before the upgrade. I was quite impressed, since I haven’t had any major Linux upgrade that successful, and I’ve been a user of Linux since the very early days of S.u.S.E., when it was sold and shipped from Germany.

I’ve installed and upgraded it on both hardware and virtual machines, and it’s only on virtual machines that Ubuntu stumbles, and not because of Ubuntu. Ubuntu, as well as Fedora 19 and 20, and any distribution that uses a Linux kernel 3.13 or later, will not allow VMware Tools (from VMware 6.0.1) to install cleanly. Specifically the filesystem sharing driver, allowing a VM client to share a Window’s folder, fails to build due to arbitrary changes in how certain group and user permission data types are represented in the kernel vs how they’re represented around the rest of userspace. Normally, with my other VMs, I share common data via that shared folder, which makes development and testing across a heterogeneous environment rather easy. Failure to share and work well together is not a Good Thing. The only saving grace (or graces) are these: I can drag and drop bidirectionally between 14.10 and Windows 8.1. It’s slower, and I have duplication of files which I have to remove when I’m done, but it’s what I have to do for the time being. And because it works so well and looks so good I’m willing to put up with it until VMware pushes out an update adding support for this latest kernel.

The system does look really good. It’s a handsome looking environment. Ubuntu 14.04 shows even more subtle visual refinements over 13.10, and I was (and still am) very happy with Ubuntu 13.10. In spite of running into the folder sharing issue, installing a bog-standard new Ubuntu 14.04 virtual machine took all of ten minutes from start to finish. Yes, I dinked around with the background, but really, if you want something that you can load and go with RIGHT NOW, you can’t beat Ubuntu at this point in time. I have come to enjoy working with Unity. I’ve had my mixed reactions to Unity along with everybody else, but after 12.04 was released all those issues were addressed and I never looked back. What has made Unity the #1 desktop choice for me is the final tweak of allowing me to put the application menus back on each application, instead of leaving them at the top left corner of the desktop control bar, à la Mac OS X. The solution of having application window menus in-line with the window top is a reasonable and clean compromise. Windows 7 and 8 have tried to tackle the waste of screen real estate with the ribbon task bar (see Windows file explorer, for example), to the complaints of many. I actually liked that idea, but then I liked the original Metro look and I like Unity, so I guess there’s no accounting for taste. This last screen shot is my farewell to Ubuntu 13.10. It’s running Java 8 update 5 and  the JavaFX demo Ensemble. It’s interesting in that IMHO the JavaFX demos run better on Ubuntu 13.10 and 14.04 than they currently do on Windows 8.1 update 1. This leads me to my final prediction: my next notebook, the one I buy after my Samsung Series 7 Chronus running Windows 8.1 update 1, will be a notebook running Ubuntu 14.04 LTS. Yes, Ubuntu’s that good. Update Some folks have asked about Ubuntu vs Arch Linux for Arm. They’re wondering if Ubuntu can be installed on the Raspberry Pi instead of Arch Linux Arm. The answer was “NO.” The last version that was installed on the R-Pi was Ubuntu 9.06 cross-compiled to run on the ARM V6 architecture of the R-Pi. After that release (starting with 10.04) Ubuntu was optimized to run on more advanced ARM architectures. The 14.04 release is optimized to support 64-bit ARM V8, such as the ARM Cortex A57 used in AMD’s Opteron A1100 processor. I’ve modified my declaratory statement above with one world; personal. Personal is primarily my notebooks and desktop systems running with Intel processors. That may change to include tablets running more capable ARM processors, but only if you want a complete end-to-end solution. For R-Pi work I still recommend and support Arch Linux Arm. The Arch ARM distribution is highly granular, more easily granular, and works quite well on the Raspberry Pi as they’re currently shipping. Even if there was a Raspberry Pi that was released with a 64-bit processor, I’d still stick with Arch Linux ARM if for no other reason than the body of experience and good will I’ve built up with this distribution on the Raspberry Pi. I’d be a fool to abandon that.

Update 13 May 2015

I have upgraded to Ubuntu 14.10 (see October) and now Ubuntu 15.04. Still feel the same way about Ubuntu. The fact that a five year old Samsung notebook is running the current Ubuntu release without issues is amazing. This notebook originally came installed with Vista, then was upgraded to Windows 7. It reached a point where Windows 7 was very unstable, which is why I switched to Linux, Ubuntu 13.10 specifically, December 2013 (read here).

Trust me. It’s all still very, very good. In spite of its noisy and noisome critics.