Buying books is such a mess right now, at least if you try to switch over to eBooks in one form or another. Let’s see what we have here.

Kindle

Kindle has the advantage of running on Kindle devices, Windows, OSX, iOS, whatever. Books are also usually cheap on Kindle, even though there are examples where the electronic version is actually more expensive than the paper version. The problem with Kindle is that it’s a proprietary and DRM’d format, and that doesn’t feel right. Non-technical litterature without illustrations are pretty nice on Kindle, but anything with code, drawings, or images sucks big time. Reading programming books on Kindle, at least on iOS and OSX, the platforms I use, is horrible.

iBooks

I’ve never bought a book on iBooks. They may be fine, I don’t know, but since iBooks, an Apple product, doesn’t run on OSX (and how sick is that), I wouldn’t invest in any book on that platform. The books are also more expensive than on Kindle, while being just as DRM challenged.

Protected PDF

APress used to sell protected PDF books, and it was really shitty. You had to use Adobe Acrobat to read them, with all the limitations, such as not being able to read them on the iPad. They fixed that by switching over to unprotected PDF. Several other publishers still use protected PDF, but you have to really scrutinize their sites to discover this vital fact. I’m avoiding doing any business with these people.

Online reading

I have to include online repositories such as O’Reilly bookshelf. I have access to a limited form via ACM, but it’s pretty shitty. The interface to the book is based on a Flash browser plugin, making it difficult to navigate. And, worse, it doesn’t work when you’re offline.

Plain PDF

I’ve found three publishers that sell unprotected PDFs, or at least they are not mandating that you use Adobe Acrobat; any PDF reader, including Goodreader and OSX Preview, is good enough. The only thing these guys do is sprinkle the document with the name of the purchaser, making it really easy to see who gave away copies to the torrent sites. I find this totally acceptable. The three publishers I’ve found are Pragmatic Bookshelf, Apress, and O’Reilly. Somewhat disturbingly, O’Reilly charges almost double for their eBooks as compared with Kindle for the same titles, which irks me enough to not buy the books I would normally have wanted to buy.

What a mess this is

You end up with some of your books on Kindle, some in Dropbox (where I put the unprotected PDF files), and some on your physical bookshelf. The advantages of carrying around a laptop or iOS device with all the books on it, are huge, though. PDF files can also be easily searched, even from Spotlight on OSX. Luckily, the three publishers I mentioned, publish enough good titles that I can simply ignore the rest, at least as far as modern programming goes. I actually think that this is the model that will dominate in the long run, at least as far as technical books are concerned.

I’ve downloaded and installed Mountain Lion (10.8) on several machines now, but I never paid for it. No, I didn’t pirate it, I got it from the App store, but it never gave me a chance to pay. Looking up the transaction in the App store via iTunes, I see this:

In other words, I did “buy” it, but got it for nothing. Officially. What I don’t get is why. I’m just guessing here, but since I’m a registered developer on the same account, and I’ve run the developer previews, that earns me a free release version as well. (Note that the 10.8 above is not a developer preview, but the released public version.)

Nice gesture, Apple. Unless it’s an error. If so, I really don’t mind paying for it; it’s not exactly expensive.

…in particular if you’re a European company. I got an invoice ten days back with VAT added from them. Went and checked my account and there’s a VAT field there now, empty of course. So I filled it in and filed a support ticket about it. Waited a week, filed a new support ticket, more upset, especially since they promise response within 24 hours. This morning I got a phone call from them that they can’t refund the VAT. The guy claims they’ve sent out a notification about this in email.

Ok, maybe they did, but Network Solutions is sending out so much spam all the time, that if there was a notification about a VAT field being added to the account, there’s no way I would have seen that. Occasionally, other US companies charge VAT when they shouldn’t, but they’ve always been able to refund that once they get the number. Not so Network Solutions. Too lazy, too greedy, or simply don’t give a shit, I don’t know.

In short, they’re more expensive than other registrars, their customer support is crap, they spam me, so why do I keep using them? Good question, I see no reason.

Today I noticed the RAID utility icon in the dock and I couldn’t remember having started it. Weird. Clicked on it and this is what I see:

(Click the image for full size.)

Oh, sh*t, a drive just died. “Just” died? No, not really, it died a week ago, and I didn’t notice. That’s not good. Normally, RAID Utility pops up at start to tell you something is going wrong, but what happens is that with Snow Leopard all apps restart in the state they were when closed down, so RAID Utility gets covered by all that other stuff. Any dire warnings are hidden, unless you look for them.

What RAID Utility should do is scream bloody murder, bounce the dock icon, send emails, create Growl popups, any and all of that, but it does none of them. Considering that running on a degraded RAID set is actually several times more risky than not running on RAID at all, the system really should take notifying the user more seriously.

A week… could just as well have been a month or until the next drive failed. Now let’s see if I get a new one from Seagate before another one goes titsup. Checking my backups as we speak…

With the new iBooks and iTunes U app, I’m missing a piece of the puzzle. Just as truckloads of schools have given the kids MacBooks, Apple rolls out the new textbooks to iPads only. Are we supposed to switch over the schoolkids to iPads now, and lose the OSX apps they use?

It would seem logical that iBooks and iTunes U would be available in versions for OSX as well, but there’s no sign of that. Or is Apple planning on running iOS apps on OSX in something like the iOS simulator? What’s going on here? As it stands now, it makes no sense.

This is about Cocoa, and in particular about class clusters. The problem I wanted to solve was having a class cluster with easily extendable hierarchy without too much interdependency. In my case, I want to create a number of different UITableViewCell descendants, depending on the particular data element the cell should handle. If the data element has a field “string value”, then a UITableViewCell with a text field for such a string value should be created. If the data element has a field “check” representing a yes/no answer, then a UITableViewCell with a yes/no functionality widget should be created instead, and so on. In total, I have less than ten different kinds of UITableViewCell derived classes, but they could become more at any time.

Read the rest of this post »

I’ve subscribed to Dr Dobbs journal off and on for decades, probably for ten to 15 years in total. Wherever I turn in this house, I encounter stacks of old issues of DDJ, even though I’ve thrown away quite a number. A couple of years ago I stopped subscribing, since the main focus of DDJ was drifting away from my main focus, or vice versa, or both. Since Microsoft started buying up all the people central to the C++ evolution, then riddling their version of it with proprietary “extensions” (or rather limitations), that language has become more and more of a dead end and both I, and DDJ moved away from it. But during the years, I’ve often read parts of DDJ on the web and I do get the “Dr Dobbs Update” through email every now and then. The most recent arrived two days ago and had the weirdest “Editor’s Note” ever, at least as far as one would expect from DDJ.

Read the rest of this post »

Check out this article on “Improbable Research”. In short, it’s an application that can take raw data and write an article around it. Personally, I think it’s a good thing if the result is more objective and complete than most journalistic writing we see today. Can’t be less researched, at least.

But it also goes to show the opposite, which has a bearing on medical publications. In medicine, we have a huge problem with the sheer amount of articles published. If you want to find out the state of art in some particular disease or treatment, you have to collect a number of articles, skim through them, try to get at the original data that was used (very hard) and make up your mind. There’s not much guarantee of objectivity in selection or interpretation of the articles, and very little objective data on how reliable the articles are. If you can find a (reliable) meta study, it’s easier.

If a machine can produce medical articles based on study data, and those articles look like the real thing, this proves that the prose in the article is not a real value add. In other words, nothing in the text adds information beyond what the raw data already contains. And if it does, it’s probably misleading and wrong, anyway.

In conclusion, this only goes to show that what we need is more studies and less articles. What we need is immediate access to the raw data of all relevant studies and a desktop application that lets us view and manipulate the total of that data according to our needs, without going through the complications of reading articles and reverse-engineer the texts down to the objective facts hiding behind them.

Maybe this heralds the death of medical publishing as it looks today, and if so, good riddance.

Once I got tftp working on IPv4, I still couldn’t get the Macbook client to download the boot or image files. Wireshark showed that the client didn’t get any file when it sent “acknowledge data block 0″. Nothing. So I installed tftp-hpa from Macports, hoping that would solve my problem, which it didn’t. But a few tips on that:

Install tftp-hpa using the “server” variant like so:

sudo port install tftp-hpa +server

Then go into the preference file (which isn’t in the same place as most plist files):

sudo pico /Library/LaunchDaemons/org.macports.tftpd.plist

…and remove the “-s” command line parameter, while changing the path to “/private/tftpboot/”. The “-s” parameter forced a chroot which won’t allow tftp to follow symlinks outside the given path, making netbooting impossible.

Then, and this is the crucial step, change the block size to max 512 by adding the “-B” option with the value “512″. What seemed to be happening in my installation is that the client requested a block size of 8192, the server approved it, and things just stopped working. Probably something to do with the switches I have, but crimping it to 512 fixed the problem. Of course, if you’re doing netbooting on a regular basis, or run diskless workstations, 512 may be intolerably slow, so then it could be worth experimenting with higher values.

I ended up with a plist file for tftp-hpa looking like this:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd" >
<plist version='1.0'>
<dict>
<key>Label</key><string>org.macports.tftpd</string>
<key>ProgramArguments</key>
<array>
        <string>/opt/local/bin/daemondo</string>
        <string>--label=tftpd</string>
        <string>--start-cmd</string>
        <string>/opt/local/sbin/tftpd</string>
        <string>-B</string>
        <string>512</string>
        <string>-L</string>
        <string>/private/tftpboot/</string>
        <string>;</string>
        <string>--pid=exec</string>
</array>
<key>Debug</key><false/>
<key>Disabled</key><true/>
<key>OnDemand</key><false/>
</dict>
</plist>

After modifying the file, stop and restart tftp-hpa by:

sudo launchctl unload /Library/LaunchDaemons/org.macports.tftpd.plist
sudo launchctl load -F /Library/LaunchDaemons/org.macports.tftpd.plist

It’s entirely possible I never needed to switch tftp servers from the default to tftp-hpa, but now I did, I don’t know if I’ve got the courage to switch back to try the original. Checking the man pages for the original tftpd server, I can find no setting for max block-size, so maybe tftp-hpa is necessary after all, just to be able to crimp the blocks enough.

…then this may be the reason… took me hours to figure out. Had to get it going for a netboot project, and the netboot just kept circling around the boot image download without getting much anywhere. First, check out Bombich’s troubleshooting, which put me on the right track without actually giving me the solution, but maybe that’s because my particular problem is relatively new. It may have been introduced with Snow Leopard.

What happened in my case is that I was able to download an image using the form:

tftp myserver.local
get NetBoot/NetBootSP0/Netinstall.nbi/i386/booter

…but not using the form:

tftp 172.25.26.27
get NetBoot/NetBootSP0/Netinstall.nbi/i386/booter

even though the “myserver.local” name pointed to the IP 172.25.26.27. At least, that’s what I presumed until I whipped out Wireshark and found out that using the “myserver.local” name resolved to an IPv6 address, not the IPv4 address I expected.

Next, I ran this on the server:

sudo lsof -i :69

COMMAND PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
launchd   1 root  144u  IPv6 0x0a9ab4a0      0t0  UDP *:tftp

Aha! The tftp server only runs IPv6 for some reason. That explains it.

To fix this, go into the tftp.plist file with pico:

sudo pico /System/Library/LaunchDeamons/tftp.plist

and add the optional key for IPv4 a bit down:

...
<key>Sockets</key>
<dict>
    <key>Listeners</key>
    <dict>
        <key>SockServiceName</key>
        <string>tftp</string>
        <key>SockType</key>
        <string>dgram</string>
        <key>SockFamily</key>
        <string>IPv4</string>
    </dict>
</dict>
...

After that, all you need to do is stop and restart tftp:

sudo launchctl unload /System/Library/LaunchDaemons/tftp.plist
sudo launchctl load -w /System/Library/LaunchDaemons/tftp.plist

Then check that the port is working on IPv4 as well:

COMMAND PID USER   FD   TYPE     DEVICE SIZE/OFF NODE NAME
launchd   1 root  144u  IPv6 0x0a9ab4a0      0t0  UDP *:tftp
launchd   1 root  150u  IPv4 0x07e2ee14      0t0  UDP *:tftp

After that, retry the tftp get command using both IPv4 and “myserver.local” addressing. Should work now. I must admit I don’t understand why IPv6 keeps working, though. Oh well, not that it bothers me, but it bothers me a little bit.

Update: this post is correct, but it still didn’t solve my problem, so please see next blog post for more, at least if you’re doing netboot stuff on Snow Leopard