Solipsism Gradient

Rainer Brockerhoff’s blog

Maybe of the month. This is from Tricks of the Trade, by Matthew Baldwin (aka the Defective Yeti), my emphasis added:

Every year there seems to be a technical whatsit that management recognizes as the sexy-cool new thing but doesn’t really understand. This year, for instance, a programmer can always tack the phrase “and I’m thinking of incorporating some XML functionality” onto a project summary to explain why he’l need an extra week, account for a missed deadline, or impress a superior. In this respect, the gap between software engineers and birthday clowns is almost negligible.

Worth a read.

Re: Rich!?

No comments

Posted by Rafael Fischmann:
I’m not that bad either:

macmagazine.com.br

Combined Value Score: 128

Top Level Domain Score: 1

Unwanted Characters Score: 10

Dictionary Word Score: 50

Length Score: 8

Archive.org Score: 49

Google Search Results: 518

Yahoo Search Results: 0

MSN Search Results: 282

Search Engine Score: 10

Estimated Base Value: $384.00

Estimated Actual Value: $24,576.00

eBay is our friend! icon_lol.gif

Rich!?

No comments

John Walkenbach pointed at the LeapFish Domain Name Analyzer. The results are surprising:

brockerhoff.net

Combined Value Score: 144

Top Level Domain Score: 8

Unwanted Characters Score: 10

Dictionary Word Score: 8

Length Score: 8

Archive.org Score: 85

Google Search Results: 13,900

Yahoo Search Results: 1,140

MSN Search Results: 635

Search Engine Score: 25

Estimated Base Value: $432.00

Estimated Actual Value: $31,104.00

So. Anyone interested? I’ll sell it for $30K if you act now… icon_biggrin.gif

OK, so here are the details on remote debugging; I’ve finished this phase of XRay 2 development and will in the next few weeks be fully available for pressing on with it.

The basic idea is that I have only PowerPC Macs, and since nobody I know in Brazil has received an Intel Mac (except for a couple of DTKs, which I didn’t want to use), the solution was to use Xcode‘s remote debugging capabilites, running my executable at a machine in the ADC Compatibility Labs. These are open at no extra charge to paying developers, but most of what I’ll detail would apply to any other machine.

Most of it is explained in the Xcode User Guide. Note that I used Xcode 2.2.1, but I think this facility has been available at least since 2.0. Click on the “Remote Debugging in Xcode” section in the left frame. First, however, send e-mail to adc.labs(at)mail.apple.com and ask for machine time, explaining for how long you need the machine; I asked for 3 days (thanks, Joe Holmes!). Basically, they’ll set up a newly formatted Mac with everything standard installed, including the latest developer tools. You should check that you have the same version, I suppose. They’ll have ssh and Apple Remote Desktop activated, and will send you the IP address, usercode and password. For illustration, let’s say the IP number is 10.1.1.1 (NOT an actual IP!), the usercode is “adclabs” and the password is “stevejobs”; substitute the actual values as appropriate.

In other words, all you’ll do there will be inside the default home folder “adclabs”. This user is also an administrator, so you’ll be able to use the password whenever needed for that. If you have a second Mac handy, you could rehearse first with that, of course; it’s what I did, as I’m normally not that handy with the Terminal. (Thanks, by the way, to John C. Randolph, Mike Ash and several others for helping me with details.)

First step is to generate a public and private key pair; you can skip this if you already have done so in the past. Open Terminal and type:

ls ~/.ssh/

If it lists a few files, among them one called “id_rsa.pub”, you already have a key pair. If not, type:

ssh-keygen -b 2048 -t dsa

This will take about a minute and then prompt you for a file path; type <return> to use the default path. It will then prompt you for a passphrase, twice. Don’t leave this empty and don’t use too short a phrase. You now should have the id_rsa.pub file in the ~/.ssh directory.

Second step is to open Terminal and type:

ssh adclabs@10.1.1.1

wait for the Password: prompt and type in “stevejobs”, or whatever password they sent you. You should see the normal Terminal prompt now, with a name like “CE-Lab-ADC-Compatibility-Labs-Intel-iMac” at the start of the line.

Now you’d better change the password to the same passphrase you used for the RSA key – yes, usually it’s recommended to use different passwords here, but that way you won’t have to remember which one to use where; it’s just for a couple of days, anyway. Type

passwd

and you’ll be prompted for the original password, then twice for the new password. Create a .ssh directory with

mkdir ~/.ssh

and log out by typing

exit

Next step is to transfer the public key to the remote Mac. To do this, at your local prompt, type

scp ~/.ssh/id_rsa.pub adclabs@10.1.1.1:~/.ssh/authorized_keys

it will ask for your password again, and transfer the file over. Now log in again with:

ssh adclabs@10.1.1.1

and if all is well, it won’t ask for your passphrase or password again, but just log in. Now restrict permissions on your key by typing

chmod go-rwx ~/.ssh/authorized_keys

Now you need to set up a local build folder. The trick here is that both machines should see your build folder at the same absolute path. There are several ways to achieve that; on a local network, you could have one of the machines serve the entire folder to the other, then use symbolic links to map the same path. However, I found that over a long distance it’s most efficient to have mirrored folders at both machines, and copy the contents over with an extra build phase. Here’s what I did.

At the remote machine, type

mkdir ~/build

which will create an empty build folder in the Home folder. Log out and close Terminal.

Now, on your local machine, you need to prep Xcode for what you’ll do. Double-click on your main project group and go to the “General” tab. Click “Place Build Products In: Custom location” and type in “/Users/adclabs/build” as the location. (Supposing, of course, that you don’t have a user called “adclabs”…)

Also check “Place Intermediate Build Ïiles In: Default intermediates location”, which probably will already be checked. Now click on your target and, from the Project menu, select “New Run Script Build Phase”. Make sure the new build phase is the last one, and enter this line as the script:

rsync -rz /Users/adclabs/build adclabs@10.1.1.1:/Users/adclabs

Finally, double-click on your executable in Xcode, and in the “Debugging” tab, select “Use Pipe for standard input/output”, check “Debug executable remotely via SSH”, and in the “Connect to:” field, type

adclabs@10.1.1.1

Now you’re ready. You’ll notice a delay of a few minutes while the last build phase transfers the files over, and on the start of a debugging run there’ll be several errors logged to the debug console, but eventually you’ll be debugging and single-stepping as usual, albeit more slowly. For GUI debugging, of course, you’ll have to use Apple Remote Desktop; I wish Apple would include a 1-user license for this in the Select package, as it’s rather expensive…

Have fun! I’ve tried to double-check most of this as I typed it in, please tell me if something didn’t work.

Update: fixed a typing error.

Rainer Brockerhoff wrote:

Hm, I really must find some time to update the page with recent users of RBSplitView… I think about a dozen or so…

OK, the page‘s up-to-date now. A couple of other apps are still in beta. Please tell me if you’re using RBSplitView in a shipping application and I’ll include it in this list!

Since releasing RBSplitView 1.1.3 nearly a year ago, lots of people have sent in bug reports and suggestions. I’m using RBSplitView in XRay II, so as soon as I get back to the UI I’ll start working on the new and improved version.

NetNewsWire 2.1 is out, and works much better. I hadn’t read the changenotes yesterday, but today I found this inside:

The splitview is now one-pixel wide, like the kids like so much these days. There?’s a little grabber thing below the subscriptions list too. (Using RBSplitView, which rocks: /src/rbs.html)

Thanks for the kind words Brent! Hm, I really must find some time to update the page with recent users of RBSplitView… I think about a dozen or so…

Miksang

No comments

I’ve uploaded a couple more pictures to my Flickr page and added a new tag to most of what’s there – Miksang:

Miksang is a Tibetan word meaning “Good Eye” and represents a form of contemplative photography based on the Dharma Art teachings of Chögyam Trungpa, in which the eye is in sync with the contemplative mind.

…Miksang involve nothing fancy, no special setup, just a visual capture, in the proper state of mind, of everyday’s reality.

Well, I’ve been interested in Buddhism – especially Zen and Tibetan Buddhism – for many years; I have several of Trungpa’s books; and I’ve even visited Karmê Chöling, the Trungpa-founded meditation center in Vermont, about a decade ago.

But I’d never heard of this Miksang thing until a few days ago, when I visited a friend and showed him my Flickr photos, and he exclaimed “but that’s Miksang!”

Well, after reading up on it, I have to agree that most photos on Miksang galleries remind me very much of my own photos, and the descriptions I’ve read on the process are also quite familiar. Not that I want to claim undue credit or extra specialness for these pictures… but I feel they belong somehow.

There’s a Miksang class in Berkeley which, unfortunately, partially overlaps WWDC, which I can’t miss. Drat. I’ll try to e-mail the organizers and and see if I can attend the first days…

hmafra wrote:

He did it again! One of his takes now is the kernel thing. Speed, he says.

What he writes makes some of sense, like the part on cross-licensing agreement. I still don’t buy it, though.

I was about to comment on that.

I checked with some friends who know more about the kernel, and they say he’s completely wrong. In fact, there are two myths at work here. The first one says that Mac OS X uses a Mach microkernel, which is wrong. XNU, which is the Mac OS X kernel, is effectively monolithic as the whole BSD stuff runs right alongside the Mach stuff in the same context. The Mach code takes care of memory allocation and thread scheduling, the BSD code does most of the rest. None of the switching that would make a pure microkernel inefficient. Granted that there are some kernel functions which are slower than the equivalent calls in, say, Linux; but this just means that Mac OS X isn’t currently suited to huge server farms, and that Apple can tinker with this if necessary without switching kernels at all. In fact, they’re probably already doing this with the Intel versions of Leopard.

The second myth is that only Avie Tevanian was holding Mach in place by sheer orneriness, and that now that he’s gone, everybody will heave a sigh of relief, throw Darwin out, and shoehorn Linux (or even XP) into its place. That too is completely wrong. Bertrand Serlet has been in charge of the OS policy for at least two years now. And consider that XNU, because of the Mach component, is well-suited to scale to a larger number of processors. And consider that Intel is coming out with new chips that supposedly will scale well to 4, 8 or even more cores…

The idea of Leopard implementing the Windows API is, at first look, interesting. (Let’s discard the misinformation about “Microsoft saving Apple”, and that the cross-licensing included the Windows API.)

After all, Mac OS X already has several APIs for writing applications. BSD with X11, Carbon, Cocoa, Java, and so forth. Why not an additional one? Well, it’s possible in theory. In fact, the WINE people are working on such a thing. However, why should Apple make it too easy to move applications into Mac OS X? Such apps would never be full-class citizens, the appearance would be awkward, drag&drop would probably be impossible… no, virtualization is the way to go. Running Windows inside a secondary window would also be a constant reminder of which environment is the native one, which is more in Apple’s interest.

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2025 by Rainer Brockerhoff.
Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.