eBible.org Sword Repository

PocketSword
Main Bible reading screen of PocketSword

The newest repository for Bible translations for the Crosswire Bible Society’s Sword Project applications is at ftp://ftp.eBible.org/sword. It is also the largest, because it has all of the Bible translations that I have permission to distribute freely and have processed, so far (677 of them as of today). This new repository has just been added to the official master repository list for all Sword Project applications (which they call “front ends”). There are many of them, but here are my favorites:

Unfortunately, as I write this, AndBible doesn’t use the master repository list, and doesn’t have a mechanism to add another repository manually. However, you can manually add modules from the eBible.org repository via the Android file system. Just copy modules to a jsword directory on your sd card. Expand the module so that the .conf file is in sdcard/jsword/mods.d and the bible files in a subdirectory of sdcard/jsword/modules e.g. sdcard\jsword\modules\texts\ztext\engWEB2014eb. Hopefully, AndBible will eventually be upgraded so that this “side loading” of modules isn’t necessary.

Another issue currently is that PocketSword may report that no search index is available for any or all of these modules. Hopefully, that will be corrected before too long. In the mean time, Bible reading will work fine.

Other than that, the Sword Project Bible study applications provide an awesome way to read, study, and search the Holy Bible in many languages, all offline, and without paying more than whatever your Internet access and device(s) that you probably already have cost.

For some front ends, or to use the eBible.org beta repository, you might need to enter the following parameters:

  • Name: eBible.org
  • Protocol: ftp
  • Server: ftp.eBible.org
  • Directory: /sword
  • User name: anonymous or ftp
  • Password: insert any email address here

For the eBible.org beta repository, the directory name is /swordbeta. All of the other parameters are the same. You can also access the same repositories with http protocol, using the server name eBible.org.

For more details, please see the documentation for each front end program on its own web site.

Dancing with Elephants and Software Development

Elephant Shower
Elephant shower, a photo by kahunapulej on Flickr.

Over the weekend, I finally succeeded in getting the “free” Windows 8.1 update from Windows 8 installed on my desktop computer. It took about 7 tries. Why did I even bother? Because in the world of software development, it is kind of like dancing with elephants. It is safer to keep in step. Development tools work better. You find out earlier if there are issues with the new operating systems and other software that you need to deal with in your software. My latest upgrade to Mac OS X worked flawlessly the first time. Linux upgrades normally work flawlessly. So why was it so hard to upgrade Microsoft Windows? Perhaps because my hardware and software configuration was just far enough off of the beaten path that it contained something that the Microsoft software engineers, in spite of their awesome efforts, failed to anticipate. At least it did not harm my data or my computer in the process, other than making it unusable for an hour or two while it tried, stalled at a black screen of death that could only be broken with a power cycle, then rolled back, reporting that it couldn’t do what I asked it to do, and giving one tiny clue: the two hexadecimal numbers 0xC1900101-0x40019. I searched the Internet for solutions, and found that many people had the same problem, and many had solved the problem in various ways. Microsoft had even posted an official fix on their web site, involving fixing the master boot record using a bootable USB memory stick created with another working installation of Windows 8.1. I tried that. It didn’t work. Actually I tried lots of things. I did more research. One guy suggested sacrificing a chicken to some false gods, but I don’t do that. I did eat some chicken, though. The combination that finally worked was to uninstall any software that provided remote video access and remove all video drivers, unplug all USB devices, and try again. This time it worked. Sort of. It stalled out at a gray screen with a mouse pointer that actually moved, but did nothing useful. At that point, I selected Ctrl-Alt-Del and did an orderly restart, and then it worked. I could then reinstall a couple of missing pieces, hook up my USB devices, and carry on with electronic Scripture publishing.

Bugs and User Interface Design

I’ve been dealing with bugs a lot, lately. Not the living insect variety, but the computer bug sort. It is my job. Yes, I’m a missionary, and I do “missionary-like” stuff like living in a remote area in an exotic nation, preach in another language, and continually have faith in God to supply the needs of my family, my ministry, and myself, because I get no salary. My 40-hour-a-week job, though, is IT support and custom programming for a mission aviation organization with 7 aircraft. I support Bible translation work by supporting the people who get the Bible translators in and out of their villages, and who keep supplies coming in a land with very few roads.

In combating computer software bugs, I have learned to recognize some really common ones. I have also learned some things about writing software to avoid them. Just like bugs in the animal kingdom, there is a taxonomy that can be used to describe them. One major distinction is the source of the bug: bad design, bad implementation of a good design, or both. The bad implementation side is the one people usually focus on. I have seen several lists of common errors, like stack overflows, arrays with indexes out of bounds, improper validation of input (especially if that input is going to be interpreted by another process like a SQL server), etc. Such things are important to pay attention to, but those are like miller moths (the kind of bug found in a relay of one of the first computers, and for which all computer bugs are named). They can’t bite you, don’t normally carry diseases, and as long as you keep them from laying eggs in your stored clothing or wedging their bodies into your relays, it takes a lot of them to really do much damage. Design problems, however, are more like centipedes, scorpions, and poisonous spiders. They can be lethal to a project.

One particular design problem that I have seen too much of is in the form of bad user interface design. Human interaction with machines is very complex, because humans are extremely complex and the machines they use tend to be a little complex, too. I enjoy the computers on Star Trek, because they are so speedy, recognize natural speech in almost any language in the galaxy, can store the collected information from multitudes of civilizations and search and analyze it all in seconds, and can produce any kind of food or beverage on command. They always seem to just understand what the user wants. Not so with the computer I’m typing this article on. I could name at least two projects that had serious user interface (UI) problems in the world of Bible translation and Bible translation support software, but I won’t, at least here. One of those is basically irrelevant except as a how-not-to lesson, as it is essentially dead, killed by lack of use. The other has credible hope of being resurrected with a UI make-over in at least the most critical areas.

Rather than detailing all that is wrong with the UI designs I have seen, I prefer to be a little more positive, and focus on what is good and right about the best UI designs that I have seen. Here are some things to keep in mind when designing a new program or program suite that may save you some grief:

  • Before writing a single line of code, design at least the basics of the user interface. What are the inputs, outputs, and interactions? How do they fit with the work flow of your customers? Is this the same as what they do, now, or better? (If it is not the same or better, then scrap the idea and start over.) To really do this right, you need a good understanding of what problem(s) you are trying to solve, and good lines of communication with your customers. (Yes, you have customers, even if you write free software.)
  • Know your customer base. Know their education level range, their familiarity with computers, other programs, and operating systems. Know what kinds of computers they use and are likely to use. Know why they would want to use your new and/or improved program. Talk with them frequently before, during, and after design and development of the program. If the entire user base is too daunting and could consume all of your time, talk to a few truly representative users, and make some way for others to send feedback (i. e. bug reports, feature requests, etc.).
  • Make your UI intuitive. That means make it so obvious how things should be used that someone who has never used it before can use it. In reality, the only way you will get this done is to copy the good ideas and behaviors of other common programs that users have likely used, before.
  • Read up on good UI design. Microsoft and GNOME both have good things to say in this regard. Even if you don’t like all of their ideas, you need to use most of them or your interface will seem strange to people, because it is different.
  • Use a good UI design toolkit/library. Not only does this save you from “re-inventing the wheel,” it makes it easier to both be consistent and be more like other programs (and therefore more intuitive).
  • Do not get too “creative” with your UI. Sometimes even something that is arguably better is much less intuitive, because people aren’t expecting whatever you are throwing at them. Choose a “normal” way of doing things. Read Microsoft’s Common User Interface guidelines and the Gnome project’s user interface guidelines for some good ideas that you should probably stick to unless you have a good reason not to.
  • Match the UI to the task. For example, if it is a control system for a physical system with fluid or material flows, lay out your UI in an easy schematic diagram of that system. If is a calendar, make it look like one. If it is a recipe book, make sure it is easy to find the recipe “cards,” and once you present them, they look like what cooks are used to seeing. If it is a flight simulator, make it look like a cockpit. I once visited a business web site that was programmed like a video game, but the business had nothing to do with video games. Match the form to the function.
  • Make the common stuff easy to do and easy to find. Minimize the number of mouse clicks and keystrokes it takes to do stuff that is done frequently.
  • De-emphasize the more esoteric or “advanced” stuff, lest it confuse the beginners and casual users of only the basic functions.
  • In de-emphasizing the advanced or infrequently-used features, take care not to hide things too well. Make such things reasonably obvious to find, too. Sometimes it is better to have a larger set of options shown at once, and sometimes you need to show just a few. Knowing when to do which is a matter for experience and wisdom. Usually, this balance has to do with putting “advanced” features on a separate dialog box, or having a less/more button on a dialog box. It also explains the partially-hidden menus in some programs, although I never liked that feature myself. So, if you do that, make sure the users that are annoyed by that can turn the menu-hiding off.
  • Be consistent. This includes layouts of dialogs (i. e. normal locations of OK and Cancel buttons) as well as when and how things get saved. Some programs automatically save everything you do instantly, with no “save” button needed, but some require an explicit “save” function. Try to do it the same way within the same program.
  • Give the user good feedback. When something happens, make it look like it happened. Users are ALWAYS confused if you don’t do this. Better yet, give feedback of exactly what happened, visually, audibly, or both. Make it obvious what is going on.
  • Provide an “undo” function where appropriate. People goof. Often, they recognize immediately that they goofed (especially if you give good feedback), and they want a way to repent, undo, and avoid disaster. Make it possible.
  • “Are you sure you want to launch a nuclear missile?” messages are no substitute for a good undo function. Choose wisely where you put “Are you sure?” prompts, and don’t over-use them. Otherwise, they will be ignored when they are really needed.
  • Avoid overusing modalism, or the shifting of controls into different modes. Computer interfaces are inherently modal. Different menus, buttons, controls, etc., appear on your screen at different times in different situations. This is both flexible and annoying. It is both powerful and non-intuitive. Consistency is intuitive and easy. Consider the automobile. The accelerator pedal is on the right. The brake is to the left of it. Turning the steering wheel clockwise turns the car to the right when moving forward. It is always the same, in all cars, all over the world. I like that. When practical, keep the same kinds of controls in the same places.
  • Keep it SIMPLE! This is probably the most important suggestions. It takes careful balance. Don’t bedazzle & befuddle the user with too many things at once, but don’t make it too tedious to find all of the things that the user wants to do. Group things together that logically go together in the user’s normal work flow.
  • Make the program forgiving. I detest programs that you have to press 3 buttons exactly once, in order, exactly one time per month, or things get messed up. If one of the buttons doesn’t work, programmer intervention is required. Don’t do that. If a button can be pressed, make it do something safe and useful. If not, disable or hide it. If something has to be done exactly once a month, reconsider the design.
  • Write clear, concise, indexed, illustrated instructions. If you can’t write well, find someone who can to help you. Include the instructions with the program and keep them up to date with the program.
  • Keep the design of the over-all program simple. If you have trouble explaining to someone how to use it, chances are that it really is too hard to use, and needs to be changed.
  • Keep the number of controls to the minimum needed to accomplish the task efficiently. Remember that for each control you add, you raise the minimum I. Q. of the operator by 3 points.

Now I’ve reminded myself of what I’m shooting for as I redesign some software. I hope it helps you, too.

The Great Technician

I was really happy to have succeeded at fixing a satellite relay station of the Papua New Guinea Christian Broadcasting Network (Wantok Radio Light) in Kainantu. The man in the picture is smiling because I just gave him a solar-powered fix-tuned radio, playing Wantok Radio Light. That nice little Galcom radio is really good for PNG, because batteries cost lots of money relative to people’s income, and people don’t always have access to electrical power. The thrill of victory turned to the agony of defeat quickly when I got back to Aiyura, and the station had gone off the air, again, then drifted on and off rapidly enough to make the station pretty useless. I had done all I knew to do. I just turned to the Lord, and asked Him to either fix it Himself, send an angel to fix it, send someone else to fix it, or show me how to fix it. That evening, the radio station came back on. And stayed on. I’m listening to it, now. Glory be to GOD! He is a better electronics technician than I am. He is the master architect, engineer, designer, and Creator of all that is used to make anything electronic.

Missionary Rocket Science

In a land where only about 10% of the people have electrical power in their houses, you might wonder what good such technology as electronics, satellites, radio, and cell phones might be. Actually, such technology is very useful, indeed. Technology is no substitute for living and proclaiming the Word of God. It can, however, make it easier to reach people with the Word of God and make the logistics of getting the Word of God to new people groups much easier.

We rely heavily on communication satellites. All of our telephone calls from Ukarumpa to anywhere farther than Kainantu are carried by satellite, no matter which way we make them. The Papua New Guinea Christian Broadcasting Network (also known as Wantok Radio Light) uses a satellite channel to distribute its programming to FM radio stations scattered all over the country. Our Internet connection is via satellite. In a country consisting of about 600 islands, including the very large and mountainous island of New Guinea, satellite links are the most practical way to communicate in many cases. Running cables all over the place is way too expensive, and far to vulnerable to damage by vandals, earthquakes, and other problems. We also make heavy use of HF and UHF radio links.

A few weeks ago, the local Wantok Radio Light station in Kainantu stopped working. Its receiver (shown in the picture) apparently suffered damage to its RF front end in a lightning storm. The station manager sent a replacement up via an SIL flight, and I put the new one in place. Many people were happy to be able to hear their favorite Christian programming, again.

Although few people have electrical power in their houses in Papua New Guinea, there are many battery-operated radios listening in. We have distributed about 700 fix-tuned, solar powered radios to people in Wantok Radio Light’s service area, so far.

Yes, the Good News of Jesus Christ is simple enough for a child to believe. Rocket science can help deliver that good news.

Mobile Telephone Service in Ukarumpa!

Our last field term in Ukarumpa, there was no mobile phone service at all in Ukarumpa, except for bulky and expensive hand-held satellite phones. Now, there is service from two different companies! One of those (B-Mobile) has excellent signal strength in Ukarumpa but high airtime prices. The other (Digicel) has better coverage most places in PNG and better prices, but weak signal strength in Ukarumpa. It is interesting to watch the culture changes that happen when technology like this comes to where it wasn’t available, before. The introduction of competition for telephone service has been resisted by the existing telephone company (Telikom and B-Mobile) and some people in government. Therefore, the newer and larger mobile phone network (Digicel) has been blocked from interconnecting with the existing telephone company, so far. Because of this political state of affairs, it takes two telephones to be able to talk to anyone with a telephone in the country. Both networks connect internationally, but there is a significant price difference ($1.97/minute for Telikom vs. $0.36/minute for Digicel). Fortunately, accepting inbound calls is free on both networks. I hope that Telikom wakes up, lowers prices, and makes an interconnect agreement with Digicel and Green Communications (the other licensed mobile phone service provider) before everyone cancels their B-Mobile and Telikom service and just goes with Digicel because of better service and lower prices.

Having these additional telephone services has significantly increased our communication reliability from Ukarumpa. In the last week or so, the “land line” service of Telikom from Ukarumpa to the outside world has gone out of service twice for about a day at a time, but mobile phone service was available at those times. (Telikom has had significant difficulties maintaining service due to theft and vandalism of their lines and equipment.)

The expansion of mobile telephone service in Papua New Guinea is a valuable additional communication option for many people, including Bible translators.

Missionary Email Security in Sensitive Areas

When doing Christian mission work, it is often necessary to consider the effects of email and the Internet when going into areas with opposition. Much mission work goes on in technologically advanced, developed countries. (That isn’t a good description of where I work, but I did take this picture within about 200 meters of a mobile phone sales booth.) Although I work in a country where I can be open about what I do, some don’t. One brother asked me for advice on email security in his country, which is less friendly than mine to Christians. Here is my answer to him and brothers and sisters like him:

* Be like Jesus. He doesn’t lie, but He doesn’t tell everyone everything, and often uses parables. Choose wisely what you reveal to whom and how.

Don’t say things that attract terrorist attention. Avoid saying things that sound like blasphemy or illegal activities. Avoid using religious key words that a terrorist might look for, or at least be very careful of the context of that use. Keeping the text clear of incendiary comments and personally identifying information and exact locations is a good practice when operating in some areas, but that should never be all that you do. It isn’t enough.

Be anonymous. Don’t get real specific about identifying information of individuals and locations. Maybe a common first name, pseudonym, or initial is enough to talk about a person. Use large geographic units (like “Southeast Asia” or “North Africa”) instead of precise addresses. Use of a specific country name may or may not be OK, depending on the country. Consider carefully what pictures to send, and how to crop or selectively blur them. If someone with murder in his heart intercepted your email and decided that he hated you and what you do, but couldn’t identify or find you or your brothers and sisters, then that email leak did no actual harm.

Use generic email addresses. There should be nothing to capture unwanted attention or reveal too much identity in either the user name part of an email address or in the domain name. There should be nothing incendiary that pops up if you visit http://www.networksolutions.com/whois/index.jsp with the domain name or surf to the corresponding web site. Something like imaketents@gmail.com or languagestudent@yahoo.com is much better than something like Joseph_David_Smith@name-of-disliked-organization-here.org.

* Use link encryption. For most people, that means requiring TLS or SSL connections between their email server and their email client. Some commercial mail clients automatically use link encryption, but they aren’t the cheapest solution, and not as easy to integrate with GnuPG. With standard email clients, like Thunderbird, Outlook Express, Eudora, etc., there is usually a little non-default setup that needs to be done. Link encryption is supported by all good email providers and email programs. If yours doesn’t, get another one that does. You can get free email accounts supporting encryption at gmail.com and other places, and high-quality free email software that supports encryption, so this need not cost money. Exactly how you set it up depends on your ISP and your email program. Thunderbird, in the account settings box, the “SSL” or “TLS” radio buttons should be checked, depending on what your ISP supports. Another option is to use SSH or VPN tunneling instead of or in addition to SSL or TLS, but that most likely requires some expert help to set up. Note that link encryption just protects the privacy of the email from your computer to the server and back, and does nothing to protect it on the server, on your local computer, in transit between the server and your correspondents, or on their computers. That might not seem like it is worth much, until you consider that it probably covers the portion of the email route where the worst threats are.

* Use a mail server in friendly territory, preferably in the country where most of your email correspondents live. There is no guarantee that email between your server and others will not pass through an enemy’s server, but the odds of that happening are lower than if you choose a mail server in a land populated primarily by the kinds of people you would least like reading your email.

* Use secure web mail. Web mail access is great on the road. Make sure the connection is secure, however, with https, not http. Don’t use web mail from untrusted cybercafes and stranger’s computers. Using your own notebook computer at a wireless hotspot is better.

* Use GnuPG where practical. Unfortunately, that isn’t in very many cases, unless you set it up for people… but if you really want to pour your heart out in an email, it may be just the thing if your intended recipient also is set up to handle GnuPG mail. This takes planning ahead, and it probably means having at least one GnuPG expert per working group. Once set up, it is really easy to use, if you use GnuPG with Enigmail and Thunderbird. (If you are using an email solution that doesn’t have OpenPGP integration, you should consider getting another account and email client for this task.) There are some other similar combinations that work, too, but I like Thunderbird + Enigmail + GnuPG, because it works for me on Windows, Linux, and Mac OS, and because it is really easy to use once set up. GnuPG is not a realistic thing to expect all of your partners to use, though.

* Practice safe computing. Enable a firewall. Protect yourself from viruses. Don’t install unnecessary software on your working computer. Don’t leave sensitive information unencrypted on your computer. Sensitive information is anything that would cause you significant concern if your computer was stolen and you were thinking about the thieves looking at it, like maybe bank account information and passwords, personal correspondence, etc. Scan for spyware and viruses regularly. Your email can be perfectly secure, but if you have a keystroke logger reporting your passwords and email contents to someone else, someone else can get it all, anyway.

* Encrypt the email (and other sensitive documents) stored on your disk. The easiest way I have found to do that is to use TrueCrypt (http://www.truecrypt.org) to create an encrypted volume, then install the PortableApps version of Thunderbird in that volume. The encrypted volume can be on a large capacity USB memory stick, if you like. See http://portableapps.com/ for more about portable applications. All of the care protecting the transmission of your email isn’t worth much if your computer (or memory stick) is suddenly stolen, and the data isn’t encrypted. Do this before you need to do it. (In other words, shut the barn door before the cattle stampede across the highway, even if you don’t see the kid with firecrackers hiding in the barn.) Some versions of Microsoft Windows allow you to encrypt certain directories with your login credentials. This feature is easier to use than Truecrypt, but I prefer to use Truecrypt for several practical reasons, including the ability to backup and recover from disk disasters in a more straight-forward manner. (There are other disk encryption programs, but Truecrypt is free, uses sound cryptography, and I know how to use it.)

* Separate your sensitive and non-sensitive data. Make a habit of keeping your sensitive data in an encrypted volume on your computer, and backing it up to an encrypted volume on a memory stick that you keep in a separate place. Most of your non-sensitive data is also probably worth backing up, but you don’t have to keep it encrypted.

* Use good passwords/passphrases. Don’t use things that are easy to guess, things that are in any dictionary, etc. Use first letters of a long phrase. Throw in some special characters. Make it long. Make it easy for you to remember and very hard for others to guess, even if they have automated help guessing. Longer passwords are usually better (as long as you don’t forget them). Even long passwords that you use regularly aren’t all that hard to remember.

* Keep remote backups in a safe place. If you have some really important data, make sure you back it up and store it in a separate place, preferably in another country. If it is sensitive data and you have any doubts about if it will be intercepted in transit or stolen from its destination, encrypt it. Remember the password to decrypt it.

Ask correspondents not to forward or post newsletters. There are things you might like to tell your partners in your home country that might not be appropriate to share with all of your neighbors. One forward to a mailing list with a public list archive that gets indexed by search engines could drastically increase the potential readership of your newsletter.

* Protect home and office networks. Use encryption (WPA or WPA2) on wireless networks. Don’t share more than you intend to via network. Turn off file sharing if you don’t need it. If you do, only share specific directories for specific purposes.

* Be careful what you publish to the world via the Internet. Make sure what you say is appropriate for your current situation, especially if you have a personal web site, blog, or photo-sharing site. Consider carefully how your near neighbors may view what they find out about you on the World-Wide Web. Google finds some amazing things.

*Items marked with an asterisk are good advice for missionaries even if they are not in places where terrorist attacks are likely.

Behind the Scenes

My Linux computerAnother missionary working in Papua New Guinea (and currently on another island) told my wife that they only got a newsletter out about once or twice a year. It is hard, and they just can’t “whip one out like [Michael] does.” I have a confession. I don’t just “whip out” a newsletter. OK, maybe a quick photo of the week email with no major content is pretty quick, but the “official” newsletter that we archive on our web site, email to our partners, and have printed and mailed to our email-less partners takes about two days of labor to produce. It would take less time if we made it longer, actually. We know that people are busy, so we endeavor to keep the newsletters short; no more than one sheet of 8.5 x 11 inch paper, printed on both sides, using type that most people won’t need a magnifying glass to read. In addition, we know that people like pictures. We like them, too. Pictures aren’t just fun to take, they are also effective tools to communicate a lot in a little time. Pictures tell stories. Of course, pictures bring to mind stories, too— usually more stories than I tell. Actually, one of the best things about our web site is that it gives me a place to put the overflow from stuff that didn’t make it into the newsletters. It also is a nice place to be able to post pictures without a really small size limit on the captions. Of course, I realize that not nearly as many people will read all that I post or enjoy the pictures as read our newsletters, but that is OK.

The richness of the full-color range of experiences and adventures with God here and in our travels just flat-out won’t fit in two pages every month or three. There are many significant things going on, times where God has gotten glory by protecting and healing His people, trials and victories over trials great and small, all mixed in with cross-cultural salsa and sprinkled with miracles. Sometimes it seems like a real struggle just to not lose heart, and other times, the joy of the Lord just overwhelms a guy. Through it all, God is faithful. Of course, adventures with God don’t require crossing large quantities of salt water. People struggle to grow close to the Lord in the busy USA, too. So, we keep trying to condense significant events, prayer requests, vision, thanks, and news of what we are doing into less than a page a month. Why do we even bother? Accountability. Reminders for both senders and sent of their dependence on each other. Reminders to pray. That makes it worth it.

Lately, I’ve been experimenting with making the newsletters a little “deeper,” at least for some people. By embedding hyperlinks in our newsletters, I make a way for people who are reading the electronic version online to dig a little deeper or see a little clearer picture with a simple click. At least that works for people who are on the Internet at the time. If they aren’t, or if they are looking at a printed copy, then they still get a decent newsletter.

I’ve also used prayer letter writing as a learning experience. I suppose that a normal person would figure out one software program for creating prayer letters and stick with it. I’ve used a wide variety of programs, sometimes just to learn to use that program. The most recent newsletter I produced was the first one that I produced with Scribus running under Ubuntu Linux. I like it. I think I’ll keep using Scribus for our newsletters for a while. It makes a really good PDF file for our purposes.

Blog Restored

Apple blossomIt turns out that my journal entries were not totally obliterated, just temporarily inaccessible. With a bit of labor, I was able to recover all of the posts in my blog. In the process, I decided to move the blog from the Rainbow Missions leased server to a “free” account on WordPress.com. Although this has the unfortunate side effect of breaking all of the “permanent” links to the individual articles, it has the advantages of (1) upgrading to the latest version of WordPress software (2) someone else maintains the server and keeps the software updated, and (3) it saves me the trouble of trying to get Plesk, WordPress, and various web pages working together with the same version of PHP and other programs on the same server. I can minimize the pain of the broken links by making the old main blog URL automatically forward to this one. Now, I’ll run one of my favorite features of the latest version of WordPress: export of the whole blog to an XML file that can be imported to restore the whole thing, later. 🙂

Backup!

My eyeYou would think that after more than three decades of working with computers, I would be better about backing up my data. Apparently, I’m not. I’m OK with regular files, but I hadn’t gotten around to setting up a proper backup system for MySQL data on my server, including my WordPress blog entries. A software glitch during remote upgrading of the Plesk software on that server killed it. This is sad. I’ll try to do better.

Toshiba Lemon Retired–Long Live the MacBook!

MacBook running Ubuntu LinuxThe last time I wrote about computers, I was happy to have found and fixed a serious problem with my Toshiba computer. I expressed high hopes that it would provide long and reliable service. Those hopes were disappointed as the Toshiba computer froze up a couple more times, one of which cost me about an hour of work. To me, having a computer that is so close to working well, but so far away, is frustrating. Fortunately, there is a good solution. A dear brother in the Lord gave me a MacBook notebook computer. I really like it. It has become my primary working notebook computer. The MacBook is smaller and lighter than the Toshiba computer, but it runs faster and has more RAM installed. I was pleasantly surprised at how well it runs not only its native Mac OS X, but (with a little help from Parallels) Microsoft Windows and Linux, as well. This is important for the cross-platform Bible translation software development that I’m working on. Praise God! It works!
The Toshiba computer isn’t totally out of service, yet. It has been assigned to entertainment duty and for use in places where I don’t want to have my primary working machine, such as showing photos in a display booth or as a loaner for other people to use for less critical and less demanding applications.

Loose-brained Toshiba

CPU photoThe saga of the Toshiba Satellite P35 notebook computer woes continues, but this time I have high hopes that things have turned around such that we will get our money’s worth of work out of this machine, yet. Its warranty has expired. It was working OK most of the time, at least running Ubuntu Linux, but it still flaked out at times. It seemed to be thermally sensitive. The environment I’ve been running my computer in has been a consistent 20 to 23 C, which shouldn’t be a problem at all, but at 2,425 meters above sea level, which might challenge the cooling system a little. This model of computer is notorious for overheating due to the heat sink over the CPU getting clogged with dust. I found instructions for disassembling and cleaning it, but didn’t want to perform that major surgery until I had a viable backup plan and ALL critical data was off of the computer. All the important data is mirrored to an external hard drive at least every other night, but it wasn’t until I had Linux set up on my desktop computer with all of the same applications and had another notebook computer that I felt that I could risk disassembling the computer.

Box of partsWhat I found surprised me. The heat sink wasn’t clogged. The canned air treatments that I had given it had effectively cleared out most of the dust, dog hair, and other junk. However, when I lifted the heat sink up, the CPU just fell out of its socket with no resistance. The latch on the zero-insertion-force socket was set about half-way between “open” and “closed.” No wonder the machine had been flakey! It had a loose brain! I’m amazed that it had done as well as it had, to be honest. The top picture in this article shows the CPU properly latched in place.

More Toshiba notebook computer parts.After smearing on some fresh thermal transfer grease and attaching the heat sink, and putting all of the parts back together again, this computer has run flawlessly, so far, doing normal stuff like downloading pictures from my digital camera, reading and writing email, and and writing this article. I have high hopes that it will keep running well. 🙂

Praise God! It almost feels like getting a new computer!