A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Happy New Year!

Happy New Year from the kind folks at CompuBlab! We hope 2018 is a year of great health and prosperity for you and your loved ones.

At this time, we also are making several special announcements. In the early part of 2018 we will be launching:

    Our online training school called the CompuBlab Academy
    Our Youtube channel called CompuBlab
    Our private facebook forum called CompuBlab

There is much planned for CompuBlab for 2018! More details coming soon…

How to Contact Amazon.com Customer Service via Telephone

It has rarely been the case that I have ever needed to speak to Amazon.com’s technical support staff via telephone, but I have to say, the few times I’ve needed to do so it has not always been a breeze to locate their telephone number. Since my wife just recently needed to do exactly that, here is the number that she used:


Of course, this number is only known to be valid as of yesterday: October 4, 2014. Hopefully it will continue to be valid, but we all know how quickly telephone numbers can change.

Rules for Running an Open Source Project

Rules to follow when setting up and running an open source project:

  • Your project must have an unintelligible name that cannot possibly be linked to the actual purpose/use of your product. The stranger the better (e.g. Zynga, Apache, Redis, Firefox, Chrome, etc.)
  • Your website must be written from the point of view that everyone viewing your site already knows all about the project.
  • At least half of the download mirror sites listed on your website must have broken links
  • At no time do you ever put a date anywhere on your website, on your downloads, or on your documentation. You don’t want anyone figuring out that your project was abandoned 15 years ago…
  • Every book regarding your project must have a really large opening chapter that tells the uninteresting story of how your project began.
  • All white papers and blog articles on your main website should be written as sales ads rather than offering anything of engineering value.
  • You need to program your online support forums so that whenever anyone asks a technical question, the forum automatically picks a team member name at random and forges a reply post asking “why do you want to do that?”
  • You set up a kickstarter project and once you get the money and start developing your project…you sell out as fast as you can to the first bidder then grab the money and run, leaving all of your donors who thought you’d continue development after your kickstarter project was completed twisting in the wind. It is best if you can be bought out by a very rich punk who runs a social networking site that has no foreseeable use for your technology.

Just lessons learned from a lifetime of working in technology…

The Dolt with the Raspberry Pi (and the Beagle Bone Black)

As you saw in my last post, I didn’t really plan carefully for the arrival of my Raspberry Pi and Beagle Bone Black boards. Sadly, the saga continues…

So what MORE could go wrong you ask? Plenty, as it turns out. And in this case, my enemies were:

  • Rapidly moving technology
  • Failure on my part to read the specs carefully (a.k.a. being a dolt)!

So after my (mis)adventures with the power supply, I finally got a few moments to begin to load up my Raspberry Pi with the base software to boot a Linux distribution. I downloaded the NOOBS software (as it is called…a set of software that you load on an SD card so that you can easily load up one of several popular Linux distributions with the touch of a key) but ran into problems when I tried to transfer it to my brand new class 10, 32-gig micro SD card.

You see, I kept getting “crc check errors,” meaning that I wasn’t getting a clean copy to the card. After several attempts, I began to suspect that maybe I had received a bad memory card. Since I had purchased two cards (one for each board), I tried writing to the second card…only to get the exact same error messages again. At this point I began to suspect that the problem was NOT the card. Not just because TWO cards were failing, but because I had purchased these two cards several weeks apart. I doubted that they were from the same lot (I COULD believe that two cards from the same lot were bad), so it was probably not the card.

Now my suspicion turned to my micro SD card reader.

Was it the speed of these SD cards (class 10)? Was it the size of these SD cards (32 gig)? I had never used micro SD cards of this size or speed before with our current USB card reader, so I began to suspect that the card reader might not be up to the task. Whether it was the card speed or the size didn’t really matter. It looked like I was dealing with obsolescence…and no true geek TOLERATES obsolescence!

A quick check at Amazon showed a micro SD card reader that several reviewers indicated they had used with class 10, 32 gig micro SD cards, and since the price was a ridiculously low $7 delivered to my door thanks to Amazon Prime (click here for the Transcend card reader that I purchased), I only had to wait the three days for it to arrive.

Once the reader arrived it was two days before I had time to unpack and test the reader. In less than two minutes I had the micro SD card loaded up…problem solved!

I figured from this point onward it was smooth sailing. All I had to do was plug the memory card into the board, connect the board to my monitor using the HDMI cable that I had purchased with the board, and I should be ready to “rock and roll.”


As I unwound my brand new cable, I began scouring my monitor for the HDMI port. Simply put: there wasn’t one.

THEN I remembered how, many years earlier, when I had purchased my first flat screen monitor (which is the one I’m still using), that I made the decision to save myself a whole bunch of money and buy the monitor that only had the DVI interface, and not the HDMI interface as well. It was a good move at the time as I did not own, and did not expect to own any time in the near future, a device with an HDMI output. Now it had come back to bite me. Obsolescence had reared its ugly head a second time!

Once again it was Amazon to the rescue!

After a quick search I found that there is indeed an HDMI to DVI cable to be had for the low, low price of $7.99 delivered to my door with Amazon Prime (click here to see the HDMI-to-DVI cable that I purchased). Another three days…and my cable finally arrived.

I have not, as of yet, had time to test my board with the cable or with the new loaded memory card. Maybe within a week I’ll a get a few minutes to do so.

But if you haven’t been paying attention all this time, I’ll lay it out for you: If you don’t want to be a dolt, read the specs and check your equipment! Fortunately the solutions are cheap…but they will cost you time…and geeks HATE to waste time!

Until next time…

Raspberry Pi and BeagleBone Black…and Roku to the Rescue!

Recently I acquired both a Raspberry Pi and a BeagleBone Black computer boards. My purpose for obtaining these boards is of course, to further my geek status, but also to explore the possibility of using one or both of these boards for some projects I’ve been toying with.

At the top of my project list is a task to create a computer system that is small enough to be easily portable and that can be run from a battery (or at least some portable power supply) to allow me to add it to my portable amateur radio station, which runs off of a deep-cycle battery and a solar panel. More specifically, I desire to be able to run digital modes like PSK31 on my portable radio station, and for that I need a computer.

Both the Raspberry Pi and the BeagleBone Black appear to be capable of the job…if I can locate or create the proper software. However, I discovered I had a misconception about these boards and thought that perhaps a reader might be under the same misconception.

Specifically, when I purchased the two boards, I also purchased a single power supply, thinking that both boards would utilize the same power input scheme. Why did I think this? I have no idea! Well, it turns out that this is NOT the case.

The Raspberry Pi uses a USB-type cable to supply power to the board. This is handy because most cell phone chargers will work with the Raspberry Pi board. However, the BeagleBone Black board uses a rounded plug similar to the plugs you see on home network routers. In fact, some network router power cords work just fine with the BeagleBone black. Unfortunately, none of the extra cords I had on hand from old routers worked. They either had the wrong type of cord/connection or else did not provide 5 volts (many provide 12 volts).

Now enter the Roku…

It turns out that a few years ago we purchased Roku box…one of the first generation devices. We stopped using it in favor of our Wii because the software on the Roku was atrocious. However, the power cord for the Roku works PERFECTLY with the BeagleBone Black. It has the correct connector and produces the proper 5 volt output.

Speaking of power, I need to see if you can power the BeagleBone Black board solely by its USB port. I’m guessing that you can, but keep in mind that the BeagleBone Black board only has ONE USB port, whereas the Raspberry Pi board has TWO. However, if you want to power the BeagleBone Black board from its specifically designated power port, you will need a 5 volt power cable with the rounded plug at the end.

No matter what I end up doing with these boards, I do expect that when I have my plans fully realized, the boards will be running separate from a computer…or at least part of the time be needing to run separate from a computer. Therefore, it is wise to understand how you can supply power to these boards.

Merry Christmas Everybody!

A very Merry Christmas to all from Compublab.com!

Using the Raspberry Pi for PSK31

Recently I have been working in Amateur Radio to develop a portable communications package that I can use both for the Amateur Radio field day as well as for emergency communications deployments…whether official or just for personal experience. Since digital modes are very handy when it comes to making contacts in emergencies, I have been looking for a method to include a computer in my portable equipment.

The Raspberry Pi is very much an ideal choice as it is small, has low power requirements, and is priced to sell ($35). As such, I have just begun to investigate the possibilities of this relatively new device.

In my first exploration into this area I have come across a blog post that talks about one user’s experience with trying to run PSK31 on a Raspberry Pi. I include the link below because I think his experience would be useful to anyone endeavoring to do the same thing.

Raspberry Pi as a platform for PSK31

Amateur Radio Category Added

Yes, it’s true! In addition to being a certified geek, I’m also an avid fan of Amateur Radio. As such, I have added a new category called Amateur Radio to be used to mark posts that involve topics related to that field.

Stay tuned for some amateur radio goodness…

The C++ Programming Language (4th edition): Bjarne Stroustrup, Thou Art The Man!

Scripting languages today are incredibly useful and certainly varied. Perl, Python, shell scripting, etc. These are all incredibly useful tools that I use on a daily basis. But I have to admit, my heart lies with traditionally compiled languages. A lover of Pascal, alas, the world has moved past Pascal to the point where I feel I have no choice but to embrace C++ nowadays for my compiled code fix.

Recently I heard about the new standards release for C++. Since I’ve been away from C++ for many years, and indeed was never all that deep into it (I preferred Pascal, and back then a company called Borland produced THE Pascal compiler of dominance), I wanted to see how the years have treated C++.

In the spirit of full disclosure, I was never C++’s biggest fan. I have always maintained that C was a great language if your alternative was assembler, but I always felt that C was over used at higher levels of programming. Large scale application development in C seemed like trying to do arithmetic in roman numerals. Well, actually it seemed to me to be much worse than that. C++ always seemed like it was “tacked on” to C, and thus I wasn’t overly fond of it.

So when I decided to refresh my understanding of C++, I wanted to find a source that would give me more than just the language facilities. I wanted a book that could explain how the philosophy of the language had evolved over the years, and how the language features should be used. In addition, I wanted a solid reference for the language along with a light tutorial of the newer features. I had seen Bjarne’s new book advertised for advanced sale on Amazon for many months. I toyed with the idea of buying an already available book both because of cost and because I was afraid that, like many technical people, Bjarne might not be able to write worth diddly. However, I read reviews of his previous editions and decided I’d take the risk and wait for this particular book to be published. Boy did I hit pay dirt.

The C++ Programming Language (4th edition) by Bjarne Stroustrup is absolutely a gem of a book, and I highly recommend it to anyone, but especially for people like me who have been away from the C++ scene for a long time and want to see how the language has grown. In case you don’t recognize the author’s name, Bjarne is in fact the man credited with designing/creating the C++ Language.

In a word, I think this book is GREAT!

While I have been reading the book casually (Solr, which I use at work, has been dominating my study for quite some time as I’ve been trying to come up to speed with it), I am already impressed with its content. It is thus far EXACTLY what I have been looking for.

Bjarne’s book is worth every penny in my opinion as it not only details the language features (old and new), but gives you the kind of analysis and comparison of features between the current C++, the older versions of C++, and other languages that you would only expect from a man who has spent the greater part of his professional career in the design of the language.

A small example (and really one of the smallest) is a tidbit that Bjarne leaves for us on page 862 of the book: “A standard library is not merely required to perform its tasks. It must also perform these so efficiently that users are not tempted to supply their own alternatives to what the standard offers. Otherwise, implementers of more advanced features are forced to bypass the standard library in order to remain competitive.”

On the surface this seems like a rather innocuous statement. However, when you ponder it carefully, these three sentences demonstrate a subtle insight into the design and use of language features that you don’t ordinarily find in lesser mortals. Time and time again in this book (of which I have only made it through about 25%) I find such insights and background as to WHY certain language features are present, the evolution of those features in cases where they’ve seen change over the years, and also a clear discussion of programming practices and classes of problems that the specific features were designed to solve. Indeed, you discover in reading this book that nearly (or perhaps every) feature of the language has very specific design goals and intended uses, and Bjarne has done an excellent job in pointing all of this out. So much so that I have abandoned my misinformed notion that C++ was simply C with a bunch of additional features tacked on.

Now I don’t know about you, but for me, after reading the previous paragraph, I’d be afraid that the book is filled with all sorts of self-aggrandizing drivel that I have to wade through just to figure out how a new feature is meant to work. Nothing could be farther from the truth. With Bjarne’s age and experience I think he has done as good a job as can be done in balancing the presentation of material such that you can find what you want quickly and efficiently, but can also delve into these other aspects of the language if you wish. His writing is very concise and well organized.

In the beginning of the book, Bjarne writes about it’s layout, designing the book to be suitable for both a partial tutorial of the language and as a language reference. Many have tried to write books to satisfy both of these demands. I cannot ever recall reading a book that managed to satisfy both roles so well. This book pulls off its goal with incredible aplomb. Of course, the book *is* 1346 pages in length. He didn’t skimp on the content at all.

I don’t want this post to get too long, but once again I will emphasize that this book demonstrates what I have to believe is a personality trait of Mr. Stroustrup: I don’t think he does anything without a clear purpose or without considering his end goal. Both the book, and the language, seem to highlight this fact.

In a profession that is being increasingly dominated by young, energetic individuals who can crank out code and applications in the wink of an eye, I find it refreshing to read the insights of a man with possibly more language design experience than 99% of the general population. If you are anything like me, you will find this book both useful and a good read.

Thank you Bjarne Stroustrup: Thou Art the Man!

Time to Make the Donuts…in the Cloud…

Some mornings I wake up and think: “Time to make the donuts.”

Today I woke up thinking: “Time to make the configuration management service for controlling solr search clusters serving up 300 million records in the computing cloud.”