But what’s surprising is that some of what seems to draw the most ire from those in favor of protecting content creators’ investments is the habit—especially in the Arab world— of “unscrupulous” publishers reprinting the texts of critical editions prepared at great expense. We’ll ignore the fact that many critical editions are actually masters and doctoral theses. The simple, plain truth is that a critical edition of a public domain work (and it would be extremely rare to find a critical edition of a non-public domain work) is not a copyrightable work in itself. Frontmatter, footnotes and so on will be subject to copyright, but the text itself is merely a reproduction of something already free to all—no matter how much effort and cost was expended in preparing it. I suspect that even those footnotes which point out variations between manuscripts are also part of the public domain as they constitute facts, and one can not copyright a list of facts. Yes, a pdf of a scanned copy of a critical edition is probably a copyright violation, but printing a separate edition based on the text prepared by the editor should be perfectly legal. And unless the proponents of shar`i copyright—which in my opinion has no leg to stand on aside from local law—are willing to contend that the sharia’s protection of creator effort and intellectual property extends beyond what the relevant statutes and treaties require, it must be ceded that this action is entirely permissible.

Meanwhile, there seems to have been a slight oversight in releasing the software. Insha’ Allah we can get them to devote a few minutes of tawajjuh to this and rebuild the executable they distribute.

The problem is this: the app depends on [something related to] the Jet DB Engine, which is not only deprecated, but does not run natively under 64 bit versions of Windows. This does not mean that the software cannot run under 64-bit OSes, but rather the OS needs to know to run it app as a 32-bit app. Unfortunately Visual Studio compiles apps by default as platform agnostic, and 64-bit users receive an error. IIRC the error is something like “Microsoft.Jet.OleDb.4.0 provider is not registered on the local machine.”

While we wait for a fixed version, there is a fix you can perform locally. To change the 32-bit execution flag, just run:

CoreFlags.exe FatawaeRazaviya.exe /32BIT+

(Determining the full path for each of these executables is left as an exercise for the reader.)

CoreFlags is a part of the .NET SDK. If this is not already installed, download the latest version of the installer. (You can use the “for Windows 7” version on Vista – and it will probably correspond to the version of .NET you have installed.) In the installer, you only need to check: Developer Tools > Windows Development Tools > .NET Development Tools.

After changing this one flag, the app will work beautifully, assuming you have taken the necessary language setup steps.

Allah reward Ala Hazrat رضی اللہ عنہ and Hazrat Maulana Ilyas Qadiri and all of those working for Dawat-e Islami, and especially the programmers and ulama who have taken part in this effort a thousand times for every click of every user, and 100,000 times for every time someone acts on a point learned from a work prepared or question answered using this software.

I’m not really a Windows or .NET person, so if I’ve made any mistake in my explanation, forgive me and correct me.

Thanks again, ImageMagick.

#update-alternatives --config java

Possibly the best reason someone who’s not interested in getting to know their network or doing fun things with it is the possibility to use just one OpenWRT/DD-WRT/Tomato device (along with any standard wireless router) to extend internet connectivity to another part of the house without running wires or using shaky (and unencrypted) Power-Over-Ethernet.

On my list of future projects to waste my money on, though, is a set of cheap 802.11n devices, replacing the “G” bridges I’ve had for the last few years. Apparently, that day is near or already here. Of course “N” speeds only matter if you’re concerned with moving data between machines in the home. For a normal residence, any available residential networking technology is faster (in most cases orders of magnitude faster) than even the best of the universally crappy available residential internet connections, and so the bottleneck will always be at the WAN side (especially for upload.) Of course these days, most small businesses are actually paying more for even crappier Internet service. But I digress…

On a last OpenWRT note, if I had known about this contest in time, I definitely would have put together a team and devoted a few months. Maybe it really does pay to read Slashdot.

The following worked for me with Debian Lenny running LTSP 5.1.10 installed fromt the repositories, other distros may require different paths:

In /etc/config/dhcp, add in the “config dnsmasq” section:

option dhcp_boot ltsp/i386/pxelinux.0,$LTSP_SERVER_HOSTNAME,$LTSP_SERVER_IP
option dhcp_option 17,'$LTSP_SERVER_IP:/opt/ltsp/i386/'

The first path is relative to /var/lib/tftpboot, the second is the ltsp chroot directory which should be in /etc/exports. The second option is equivalent to the root-path option offered by dhcpd (AFAIU) and solves the “need path” error. Apparently this is not necessary when the DHCP and LTSP servers are the same.

Etherboot clients may require different path information. And if you have a mixed set of clients, you can use the dhcp-vendorclass syntax demonstrated here (the paths in the dnsmasq section of this document are out of date, though they have been fixed in the rest of the page.)

In /etc/init.d/dnsmasq add in the “dnsmasq()” function:

append_parm "$cfg" "dhcp_boot" "--dhcp-boot"
append_parm "$cfg" "dhcp_option" "--dhcp-option"


Run:
# /etc/init.d/dnsmasq restart

Then boot one of your thin clients, hopefully to an LDM login screen.

(Credit where credit is due: This post on general PXE booting with Kamikaze got me halfway to getting this to work.)

(A similar problem exists with Xorg where many, many users who aren’t and don’t want to be X gurus but who know a few tried and true xorg.conf hacks have gone into their systems over the last year only to discover they no longer have an xorg.conf. Now, maybe you can just add a file to replace the non-functioning background magic, but you’ll be left wondering what you’re giving up, what might break down the line, and so on. And you probably wont find a simple answer for a modern system yet. You’ll have to wade through mountains of mailing list and forum postings, and reconstruct the workings of the new style X server in your own mind, which is exactly what you wanted to avoid.)

So, for those who don’t pay much attention to these sorts of goings on in OpenWRT land (how often do most of us reconfigure our networks?), here’s a set of rules of thumb for recognizing the version of OpenWRT any given online tutorial applies to:

• If you will be changing NVRAM settings, it’s for the old WhiteRussian release. (You should probably upgrade if you’re still using this.)
• If you are editing config files which resemble those of a normal Linux system in /etc, it’s for Kamikaze 7.x series. Many of these config files will still be read in the current 8.09.x series if present, but don’t necessarily count on it. You should be able to figure out the launch process for each package by reading the init scripts.
• If you are editing files in /etc/config or using uci, this is for Kamikaze 8.09 or later. In this series the LuCi web interface is also on by default, if that’s your thing.* Occasionally something shows up in the forums which uses uci directives which don’t seem to exist in stable. Also, you may find yourself adding options which the init scripts do not yet process, so you will have to edit them in.

OpenWRT is indispensable, and like much great software, those using it would rather keep using and improving it than document it and clean up the existing mess of documentation. Hopefully this helps with a little of that weeding for the new user.

* You can remove the LuCi web interface from OpenWRT Kamikaze by killing the process and running:
opkg remove -recursive luci-*

<dl> <dt>Animals</dt> <dd>
<ul>
<li>Cat</li>
<li>Dog</li>
<li>Horse</li>
<li>Cow</li>
</ul>
</dd> </dl>

– Kevin Marks on [whatwg] List captions

It seems more correct than the alternative he proposes (with each of the li’s here as dd’s) in that the list is an ostensive definition, whereas each of the items is a mere example. Practically, it saves me from having to deal with some lousy CSS on nested lists. And it does feel more semantic-ish than the nested list (for this case) anyway, and certainly better than the usual headings or paragraphs inside lists.

Now, about the competitors:

1. Google’s ta3reeb: I guess the existence of this makes it more likely to be integrated everywhere, on the heels of (maybe even within, like I dreamed in the last post) the Indic scripts gadget. It also makes it less likely that Google will acquire Yamli. Insha’ Allah, those guys will get rich anyhow.
   At present, though, note that this means I don’t have to give my contact list to anyone who doesn’t already have it. The URL for adding this gadget to GMail is http://www.google.com/ig/modules/arabic_transliteration.xml.
   Ta3reeb responds more quickly than yamli but in a choppy and not altogether useful way. If you’ve used word completion you can understand how over-responsiveness is not always conducive to efficiency.
   Now, why haven’t Google added this in the Language options on GMail? There is—as you might expect—a Google Group where you can go and pester them about all of your hopes and dreams.
2. Eiktub has a Windows Notepad-like editor you can download, in addition to the on-screen keyboard. The behavior is a little bit different than Yamli or ta3reeb – there’s no drop down suggesting completions. I did not test the app, though it looks nice for what it is. It could stand as a Windows substitute for Katoob. Really the only app I switch to Windows for is InPage. So this might be redundant. I will try it, eventually, though. Tashkil in the web interface is a nice touch, though it seems to eat the fathas on lin vowels. They lose points on the “openness” scale, though.
3. The last of these is Onkush. This is really the least effective – or rather the only ineffective – of the online dynamic keyboards. My “hello world” for testing these is to type “salam.” Onkush is the only one that defaulted to سالم. I don’t really know how the weighting is done in the others, but this is a bit of a failure. The interface also takes a long time to do the analysis and conversion, and seems to freeze with too many backspaces. It is interesting that they have pages for different types of search like Google. Though I’m not sure about their default set of pics on the image search page.
   Onkush was the only one of these where I started to fire up Firebug and look at how it was working. I knew when I started that it would crash my browser, and it did.

Now if any of these were Open Source projects, I would put up a bounty for expanding the character set, or do it myself. I’m sure an entire free replacement might be doable as well, to which I would probably be willing to contribute my time, so-so JavaScript skills, or maybe even money. Anyone interested? Does such a project already exist? I always seem to fall behind on these sorts of developments and have to catch up once a year or so. (As evidenced by the fact that either I didn’t know about ta3reeb or just forgot.)

Yamli also offers a stand alone “editor”—really a bigger text box with the ability to print what you type or save it as an RTF document. ([RW]TF?!?! I’m sure there’s a reason for that, but there’s a thousand arguments I can think of against it.) On top of that, there’s an embeddable version (quite customizable), and they’ve pre-created widgets for iGoogle and Facebook.

I’ve become quite addicted to yamli over the last few months, and these are a few things I’ve thought about that would be great to see done:

• Obviously, the first thing I would want to see is it extended to at least the Farsi and Urdu character sets. Sindhi and Pashto would probably just overwhelm the options, so I’m comfortable discriminating against them. I’m Kidding! (Those are two language groups you probably shouldn’t piss off…) These are all in Presentation-Forms-A anyway. (Burushaski and Divehi, on the other hand…) Maybe there could be embedding options to turn off extended character sets. And automatic conversion for things like: ﷺ.
• I would love it if the search bar version worked like the version on the site. (This should be possible, right, considering the way Google and Wikipedia suggest search plugins work?)
• It would be great if in addition to suggesting character conversions it hooked into Google suggest and suggested search term completions. That might be overload though.
• Google could buy out yamli or both parties could open source their work, and we could have a combined widget for Indic and Arabic-based scripts. On top of this, add whatever else is out there for Hebrew, Cyrillic, Greek, and CJK scripts. Allow some sort of configuration to enable and disable language sets. Make it an option throughout Google and embeddable everywhere. (Why not just make this a default behavior of text inputs in html5? I’d even settle for a unicode-typing-text element. I’m sure the working groups are all reading this.)
• I’d really like to have this same unified phonetic typing magic in a text editor or as something OS-wide, or at least DE-wide. This would eliminate a lot of pain and wasted time. Take me as a case study. I type text daily in the following scripts in descending order: English, Urdu, Farsi, Arabic, Roman script with diacritics, Hindi, Telugu. On my main keyboard I have Arabic key stickers. I have memorized the Urdu phonetic keyboard from CRULP . And Indic keyboards are mostly phonetic, but I do have to do a lot of backtracking to get things right. There are a few diacritic shortcuts I know, and the rest I cut and paste or use an on-screen keyboard. I know there are plenty of people who type in a number of scripts on a daily basis. We could all use a tool like this. I’ve transitioned from mostly Emacs to mostly Vim, but I would switch in a heartbeat to whoever enabled this first. In an editor, the Google suggest integration could be replaced with actual word completion based either on a dictionary or the rest of the document, similar to other word completion interfaces.

I’m pretty sure it should be possible to write a user script which yamlifies the Gmail editor. This would be a second-best in my book to the unified version, but most Arabic typing types probably could care less about Indic scripts. So the next best thing until someone does that is to have a yamli widget in Gmail itself. This, it turns out, is within reach of even the laziest among us. There are three simple steps:

1. Go to your Gmail settings and enable “Labs.”
2. Go to the Labs tab which is now in your Settings, scroll down to the bottom (enabling anything else you like along the way) until you find “Add any Gadget by URL.” Enable this and save changes.
3. You now have a “Gadgets” tab in addition to the “Labs” tab. Go to this new tab and add the URL for the yamli iGoogle Gadget: http://www.yamli.com/google_gadget/

If you are using NoScript (you are using NoScript aren’t you?) you will need to enable $crazylonghash-opensocial.googleusercontent.com, and clicking in the yamli box without doing so will result in clickjacking warnings. I suppose this also means that yamli’s developers have access to your “friend’s list”—i.e. your Gmail contact list. Which might make you wonder if it’s worth it. But who am I to make that decision for you, I’m just the guy who wants to rewrite w3c specifications for my own obscure purposes.

UPDATE: You can have your dynamarabic keyboard magic and your privacy too! (Or what little is left after Big Brother Goo is done with you.)