Online Biblical Language Resources

Since I posted a bunch of embedded Linux links earlier today, I feel like the "theologian" part of the blog is feeling a little anemic. With that in mind, here's some links for online Biblical langauge resources.


  • Mechon Mamre includes parallel Hebrew and English texts, grouped according to Torah, Prophets, and Writings. It also includes links to audio files of the passages being read in Hebrew. I've not had the chance to use this very much, but I want to. Hebrew is a wonderful and interesting language, and I don't want what little skill I have with it to atrophy.

  • A parallel Hebrew OT is avaialble via the HTML Bible. There is also a parallel Greek NT as well. Oddly enough, the Hebrew includes both Hebrew and transliterated texts, while the Greek only includes transliterated text. Odd.

  • There's also online versions of the Septuagint, the translation of the Hebrew OT into Koine Greek, available from the Bible Database.

  • Biblos.com includes a lot of different langage translations online, including four Chinese translations. It also includes a parallel Greek, Hebrew, and Latin translation for both the OT and NT.

  • All of which are nice, but my workhorse of online Bibles is the Blue Letter Bible. It's a bit on the slower side, but the amount of data it provides - verse-by-verse links to translations, original text, lexical definitions, commentaries, cross references, and the like - are all presented very nicely.

Embedded Linux Activity

There's a lot going on in the embedded Linux community these days. Just some points of interest:


  • There's a new official linux-embedded mailing list, linux-embedded, that's seeing quite a bit of activity. Very encouraging. Lots of participation from the likes of Tim Bird, Mike Frysinger, Matt Mackall, Rob Landley, Wolfgang Denk, Robert Schwebel, Sam Ravnborg, Bill Gatliff, Paul Mundt... if you recognize any of those names, you know this is a list you want to keep track of. To quote Matt Mackall, "Linux-embedded is the place to be, folks. It's intended to be the catch-all list for embedded kernel work."

  • Rob Landley's Firmware Linux project is plugging along. Firmware Linux uses qemu to build systems natively under emulation, though version 0.4.0 includes support for using distcc to accelerate a native build by calling out to the cross compiler. Supported platforms include arm, mips, ppc, x86, and x86-64, and Rob's stated goal is to support all the emulation targets that qemu supports. Neat stuff.

  • Once again showing that mere mortals can't hope to keep up with his pace, Rob is also working on toybox, a set of standards-compliant command line utilities in a single binary. Rob was involved with busybox , and was the maintainer of that project for a while, so toybox is definitely interesting in light of the "let's start from scratch and do it better" approach he's taking.

  • Fedora has several architecture-specific projects going on, including Fedora for ARM, SPARC, and PPC. My former boss-man at TimeSys, Manas Saksena, now works for Marvell, and is apparently involved with the Fedora on ARM project.

  • If you've ever built a toolchain using crosstool, you may want to look into crosstool-ng, an attempt to take the ideas behind crosstool and re-implement them in a more user-friendly way.



Aaaaand that's it for today. Enjoy!

From the "What were they thinking?" Files

When I shut down my laptop, there are - inevitably - one or two programs running in the background that do not shut down properly. I haven't investigated what they are, but I suspect they're tray notification applets or something similar. In any case, I get a nice little Windows dialog telling me that the system is trying to shut down those programs, but gosh darn it, they just won't listen! A progress bar slowly fills, and when it reaches 100%, Windows (probably with much regret, and maybe just a little glee) kills off those unruly processes so it can finish shutting down my computer.

This is a momentary annoyance. If I'm waiting for the laptop to shut down, I can just click on the button that says "Go ahead and kill these processes now", and everything is OK. If I'm not waiting, then the timer runs out, and Windows does my dirty work for me.

What got to me as I did this - for the Nth time this morning, when I shut down my laptop to pack it away and head to work - was that this is absolutely insane.

Not the way Windows handles things. That's (shockingly) pragmatic. There's a recognition that not everything will work perfectly, and sometimes, you might need to apply a little brute force to smooth out the rough edges. What annoys me is that somewhere, there are apparently software developers - corporate software developers, folks making and selling software for a living - that have apparently managed to design, implement, build, debug, and test their stuff without ever shutting down their computers.

Because, you know, if they had ever shut down their systems, they would see that their software doesn't work.

What were they thinking?

This is like having a car where, when you turn off the engine, you need to pop the hood and disconnect the battery to finish turning off the radio. I mean, sure, it works, sort of. The car manufacturer has dealt with idiot radio designers long enough that they include a specialized bit of machinery that will even automatically disconnect and reconnect the battery for you so you don't accidentally leave your radio playing all night. So it all works, kind of.

The sloppiness and sloth involved in not even bothering to make sure that your software reacts properly when the computer shuts down is staggering to me. There are guidelines for this kind of stuff. Windows messages to handle. SDK examples galore about how to do it properly. And yet, professional software developers still manage to get it wrong.

I'd like to blame it all on management - the idea that someone, somewhere, decided to ship this software, even though there were some "non-critical" bugs, like, oh, not shutting down properly. Unfortunately, I think it's probably more likely that someone got sloppy, spent a few minutes poking at the problem, and said, "Oh, that's just the way Windows is. It's good enough."

So my annoyance doesn't really come from some software that doesn't shut down properly. It comes from the fact that there's someone, somewhere, in my chosen profession who just doesn't care enough about good software to bother fixing a glaringly obvious problem in their code, even though that's what they're paid to do.

That's just plain disheartening.