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.

(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…

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.

I prefer building stuff like this with an object factory in the base class. In this case, my base class is called ItemTableCell and has a factory method with a prototype like this:

+ (ItemTableCell *)cellForItem:(IDRItem *)item;

This function needs to determine exactly which ItemTableCell child class can hande the item passed as parameter, and then create an instance of that class. It’s easy to solve in a naive way, like this:

#import "ItemTableCellStringInput.h"
#import "ItemTableCellCheckInput.h"
... another ten or so imports

+ (ItemTableCell *)cellForItem:(IDRItem *)item {

  if ([item hasStringInput])
    return [[[ItemTableCellStringInput alloc] initWithItem:item] autorelease];
  else if ([item hasCheckInput])
    return [[[ItemTableCellCheckInput alloc] initWithItem:item] autorelease];
  else if .... (another ten or so if statements)
}

There are several things I don’t like about this solution. The first one is the imports, namely that the base class needs to import and know about every child class, while the child classes need to import the base class. This kind of mutual dependency works (at least it does in Objective C), but offends my sense of esthetics. What also disturbs me greatly is that stupid if-statement that is necessary to decide which class gets to create an object. That statement contains knowledge about the capability of handling data objects that properly belongs only in the particular child class that can handle the data object. The way I wrote it here, the knowledge about the data is kept in two places: the base class and the derived class. Not good.

To get to grips with this, I came up with the following freakishly simple solution which I think only works in Objective C, and not in C++, C# or similar. (It may very well work in any number of other languages I don’t know that much about, though.)

In this pattern, the child class knows about the base class (duh), but the base class does not import the child class. Instead, the base class learns about the existence of the child class at runtime, just as the app starts up. It also delegates to the child classes the decision of which class can handle a particular data item. The result is that if you add a new kind of data item and a matching kind of ItemTableCell child class, you don’t need to touch the ItemTableCell base class code at all. It still works.

The key to this little miracle is the NSObject class function +load. This function gets called on every class in the system at startup. In case of derived classes, it gets called on the base class first, then on child classes. In my solution, I use this function to register derived classes with the base class. The base class then keeps these child classes in an array, so it can call them one by one to ask them if they can handle a particular data item, and if so it creates an instance and hands that instance the data item. It actually turns out to be pretty simple to do. Minimalistic example code follows:

@implementation ItemTableCell
static NSMutableArray *subclasses;

+ (void)load {
  [super load];
  subclasses = [[NSMutableArray alloc] initWithCapacity:5];
}

+ (void)addSubclass:(Class)cls {
  [subclasses addObject:cls];
}

+ (ItemTableCell *)cellForItem:(IDRItem *)item {
  ItemTableCell *cell = nil;
  for (Class cls in subclasses) {
    if ([cls canHandle:item]) {
      if (cell != nil)
        [NSException raise:@"Ambiguous canHandle" format:@""];
      cell = [cls subCellForItem:item];
    }
  }
  if (cell == nil)
    [NSException raise:@"No cell could handle item" format:@""];
  return cell;
}

You will note that the cellForItem function does not return the first child it finds can handle an item, but runs through them all to make sure there isn’t a second child class that claims it can handle the same item. Also, it throws an exception if no subclass at all finds itself able to handle an item. Believe me, this little extra runtime effort is well worth finding obscure bugs.

A derived class looks like in the following (I’m just showing one, you can imagine the others):

#import "ItemTableCellString.h"
@implementation ItemTableCellString

+ (void)load {
  [super addSubclass:self];
}

+ (BOOL)canHandle:(IDRItem *)item {
  return [item hasStringInput] && [item doesWhateverElse] && ![item doesNotDoSomething];
}

+ (ItemTableCellString *)subCellForItem:(IDRItem *)item {
  ItemTableCellString *cell = [[[self alloc] initWithItem:item] autorelease];
  return cell;
}

The gist of the editor’s note is that Microsoft isn’t as bad as it’s often made out to be. Andrew Binstock, DDJ’s executive editor, takes great pains in the note to show that he is definitely not a classic Microsoft apologist, and that’s fine and credible, but way down the note towards the end, there’s this paragraph:

No other company — not Apple, Adobe, HP, IBM, or Oracle — offers such a wide range of products from the consumer level to the enterprise. In many ways, this exposes Microsoft to criticism from which other companies are immune. For example, no one takes Apple to task for its failed (and now withdrawn) server. Yet it was clearly technology that significantly misjudged its audience. The execrable Objective C language barely raises a grumble. And so on.

(Emphasis mine.)

Wha… what? WTF? “Execrable Objective C”? According to whom and which standard? One would assume that there ought to be a reference here to a study done by IEEE or at least DDJ staff which objectively had determined that Objective C belonged solidly in the “execrable” category as defined by an ANSI or ISO standard. This is the kind of writing you expect as an anonymous comment on a PC devoted web site or Apple hate site, not as editorial text, and most certainly not from DDJ. What’s going on here? So, naturally, I sent Andrew Binstock an email complaining about this. I half expected a response like “Yes, that’s overdoing it, sorry”, but what I got instead was an explanation that “[he is] not the first person you’ve run into who has this opinion.” I didn’t get much anywhere in the ensuing discussion. It seems that Andrew views it as the most natural thing in the world to have DDJ proclaim publicly that Objective C is “execrable” simply because Andrew knows some people who say they hate it. (While in the same sentence actually saying the opposite: “…barely raises a grumble”. It really makes no sense.)

My solid opinion is that an executive editor of DDJ simply can’t say things like this. It’s unscientific and simply way beneath the level of discourse one expects from such a journal. Additionally, there is not a single computer language out there that can be objectively called “execrable”. All of them are more or less suited for any particular purpose, that is all. And Objective C definitely doesn’t have more haters than any other language, if we were to sink to that level, which I don’t think we should.

I am including the full email exchange below, with the permission of Andrew Binstock. I think it is interesting reading, and I think it clearly shows that DDJ is circling the drain, as far as editorial standards go. Too bad, I used to love the mag. First, read the original editor’s note from DDJ’s site. Then the emails, in order as follows.

From: Martin Wehlou
To: Andrew Binstock
Date: 15 March 2011

Andrew,

– Martin

Here the discussion ended, and I just sent a mail to ask if it was ok to copy the emails to a public blog, and Andrew graciously agreed.

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.

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.

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

In order to follow along, you need to understand the gift card process. When you buy a card, it is “activated” at the store’s cash register. It’s only after “activation” that the card exists in the iTunes system. Vice versa: if it is “activated” it was duly bought and paid for in a store. Once the recipient of the card wants to use it, he/she has to “redeem” it, which you do using the iTunes application. So, “activate” and “redeem” are two different steps in the process.

So I contacted iTunes support and what they said is this:

Martin, I did little investigation on this issue and my records indicate that your iTunes Gift Cards (<here the numbers were repeated>) have been canceled and that Best Buy provided a refund for the purchase price. I’m sorry that I could not  reactivate the card for you.

The key terms here are: “canceled” and “could not reactivate”, both of which make very clear that the cards were indeed activated at the point of purchase, but later canceled.

I checked with my friend, and he had no such refund on his credit card. So I asked again to find out more exactly when this refund was supposed to have happened, and got this reply:

Martin, I did research on this and found that the Gift cards with serial numbers …, … and … were cancelled on 09/16/2010. The reversed or the refunded might be deposited back onto your credit card. Please look for the receipt on your email and  also the credit card statement of this particular date.

Ok, so on September 16, according to Apple, Best Buy requested that the cards should be cancelled. I tried to redeem them a week after that. My friend then called Best Buy about it, and they could not find any record of any refund connected to this. They didn’t find any record of the cancellation either. Another round with iTunes support and I got this:

As the Gift cards were cancelled by the Best Buy,  with our resource I could only see that these cards were cancelled and refunded. Please contact Best Buy (1-888-BEST BUY/1-888-237-8289), with the receipt and they will be able to provide the more information and help you on this issue.

So now I called Best Buy and got Rick W. aka “Mitch” on the line. I gave him the story and he looked up the sales transaction. He confirmed that there was no refund requested or given. He even said he had no idea Best Buy could cancel iTunes gift cards. But he promised to look into it. I sent him forwards of the mails I had got from iTunes support, and he was going to take care of this pronto.

A few more back and forths, while Rick W’s enthousiasm clearly waned, response times becoming longer and longer, messages becoming more and more terse, until he finally said:

Martin

Best I can do is 75 dollar gift card to the purchaser

Mitch

My reaction to this was… “WTF??!”. His email was rude, late, brief, and wrong. The only reason I can imagine why I would accept half the amount is if I was trying to scam Best Buy and he didn’t find it worth his time to prove it. Oh, boy, do I dislike Best Buy customer support now… I wrote back saying it was entirely unacceptable. It’s my money and I want it back. Nothing more was heard from Best Buy, even though I sent reminder mails. Stone dead cold.

So, it’s back to iTunes. This time I get the following request:

In order to help you further, please take scans of the front and back of each Gift Card and include the scans with your response. I’ll need to see a photocopy or scan of the cards themselves. I’ll also need to see the receipt for each card.

This request makes sense, since iTunes support probably wanted to make sure I had the cards in my possession. So I scan in the cards, include an email with the scans explaining that my friend does not have the paper receipt, but that we do know the transaction number and they can use that to check with Best Buy that the cards were sold there. Response from iTunes:

Thank you for including the scans of the Gift Cards. I have verified that they are adequate scans. Finding a solution for you is important to me, so I have requested assistance with the issue you reported. You will receive an email after the matter has been investigated and further information is available.

We’re already past half november, but now I’m starting to see the light at the end of the tunnel. But then, a week later, “Tim, senior advisor” responds:

I appreciate your patience while I’ve been reviewing the information you sent about your gift card. Unfortunately, I will have to have a scanned copy of the receipt itself in order to assist further; I’ve been unable to verify the purchase of the card with the information you provided, since we don’t have direct access to Best Buy’s systems.

You may be able to contact the store in question to request a reprint of this receipt, but I won’t be able to assist further without an image of the actual receipt itself. I apologize for any inconvenience this may cause, but I look forward to your reply.

At this point, I started to lose my cool. I sent this to Tim:

I’ve been giving your message a day’s thought and it doesn’t make sense. Both Apple and Best Buy have confirmed to me that these three gift cards are the real thing, that they’ve been properly purchased, properly activated at the register, and properly activated in Apple’s systems. There has never been a doubt about that. A copy of the receipt will prove nothing to you that you don’t already know. It will only cost me hours on the line with Best Buy again.

*After* being properly activated, these cards were then de-activated September 16 this year. Apple told me so, and you know it. Best Buy tells me they don’t know that. The problem then is to find out if Best Buy did get a refund from you or not. They claim not. There is no way for me to prove a negative.

So, in conclusion, you know for a fact these cards are bona fide. If you have doubts about Best Buy having been refunded or not, *you have to take that up with Best Buy*! I can’t do this for you!

What we have here is Apple and Best Buy both knowing one or both of you cancelled my cards for no good reason and without refunding them, but you keep giving me the run around. I’ve spent two months and untold hours on this, and it has to stop right now. If you have any sense of customer service, you fix this without bothering me again. OR you state clearly and unambigiously that you’re not planning on honoring the gift card commitment. But I will not keep spending time on this.

Needless to say, Tim didn’t even respond, didn’t even acknowledge my message. I even sent a brief synopsis to Steve J himself. He didn’t bother either. This kind of thing, the theft of customer’s money, doesn’t seem to interest anyone.

So, back to phoning Best Buy again, trying to get a copy of the receipt, only to run up against another wall: they won’t send a copy to anyone else except the original purchaser. But my friend in the meanwhile, was incommunicado in Africa somewhere. Another two weeks go by, he returns, calls Best Buy and finally gets an email with a receipt, which is just a listing from their accounting system, not the “scanned image” iTunes support requires. And, interestingly, the credit card number was in the clear in that listing; makes one wonder…

So I send this non-scanned-image-of-a-receipt to Tim at iTunes, and finally, on December 21, I get this:

Thank you for the additional information. With this receipt information I’ve been able to obtain replacement codes for your gift cards; here are the codes:

You could say it all turned out allright, but I don’t think so. I’ve wasted untold hours on this crap. Right from the start, iTunes and Best Buy both knew with absolute 100% certainty that the cards were entirely legit and that no refund had been given. Both knew I, or my friend, had not cancelled them. Both totally refused to pick up the phone and call each other, instead letting the customer (me and my friend) do all their legwork. Finally, the only point they actually should have verified, namely that Best Buy never got the refund Apple says they gave them, never was verified.

My theory, which I’ve shared with all three (iTunes, Best Buy, and Steve J, even though he probably never even read it) is that someone at Apple or Best Buy has a scam going, where he/she is “cancelling” iTunes gift cards which have not been redeemed for a number of months after purchase, taking the money somehow and (usually) never get caught. Neither BB or iTunes have ever responded to my theory. They seem totally uninterested.

Another point is brought home by the request to scan my cards for iTunes. The only reason to ask for that is probably to see if I bought my iTunes “codes” over the internet, and refuse me a refund or replacement if I did. This strikes me as highly dubious. If I had indeed bought them over the internet, what right does iTunes have of not honoring them? Maybe such a clause is buried somewhere in the iTunes user agreement, I really don’t know, but it doesn’t sound very fair to me. In any case, that was not my problem, so I’m not going to research the EULA just for that.

My main conclusion is: iTunes gift cards are a really, really dangerous purchase. They are not to be trusted, since Apple by no means stands behind them. It’s a toss-up if they’re going to honor them or not. If you do buy any for friends or family, give them a copy of the receipt and ask them to redeem pronto. Which all seems to make the “gift” in “iTunes gift card” a very dubious term.

My second conclusion is that someone has found a nice extra income by ripping off late redeemers, and Apple doesn’t seem to care. That worries me as an Apple shareholder.

First, open System Preferences…:

Then, select “Accounts”:

Once in the accounts panel, you’ll see your accounts to the left. Chances are you’ll only have one, while I have a bunch on this system. The one you have will probably have the subtitle “Admin”:

You’ll see a checkbox to the right that says “Allow user to administer this computer”, but you can’t unselect this unless there is at least one other account that is set to “administer this computer”, so we need to create another account with that ability first.

So, click the “+” down to the left, and what you’ll see then is this:

See to it that the dropbox at the top says “Administrator”, then fill in the rest as you wish. You can use the same password for this account as for your regular account, but see to it that it is a strong password (long and complex). I see no reason why you should necessarily choose another password here. It could look like this, when you’re done:

Click “Create Account” and this is what you should see in the “Accounts” pane:

Now you can select your original account and deselect “Allow user to administer this computer”:

You’ll probably be asked to reboot at this point, at least if you were logged in as “Noobie Json” as in this example (which I wasn’t). Once you start up again, log in as “Noobie Json” or whatever your account is called, not as “NoobieAdmin”. You should probably never log in as “NoobieAdmin”, ever.

From now on, whenever you need to do something that requires admin level rights, the system will ask you to provide an admin username and password in a dialogbox. For example, if I try to delete an application from “Applications”, the system pops up a dialog box and I have to provide the “NoobieAdmin” credentials:

Now, this never happens without me knowing exactly why it happened, so don’t ever go input your admin credentials unless you know why you should. If you have any doubt, click on the “Details” and it will tell you a little bit more:

In this particular case, “Details” didn’t tell me much I didn’t already know, but when in doubt, in may often tell you exactly what you want to know. If some malware is requesting admin credentials, the app that issued the request will be clearly shown.

If you’re really paranoid, click the double arrow to the right and you’ll see the entire folder hierarchy leading to the app that requested the credentials. Just in case some malware called itself “Finder” for instance. In this case we’ll see that “Finder” is part of “Core Services” which in turn is in the System/Library. Totally kosher, in other words:

OSX very rarely asks for admin rights, so there is very little risk of you getting into a habit of just entering your credentials without thinking. Yes, the first day you use your new Mac, you will do this a number of times until it is all set up, but after that, it becomes a rarity.