Computers

Now you see me

/ hsoi / 2 Comments

I’ve never been one to hide my identity. I’m John C. Daub, millionaire; I own a mansion and a yacht.

I admit in my early online days I was a bit more reluctant about sharing my identity because hey… there are crazies out there. But while I may not have been as forthright with my identity, I didn’t lie or hide or refuse. If someone wanted to know who was behind the moniker, it wasn’t hard to find out either by searching or just asking me.

The advantage of “Hsoi”? Well, plug it into Google and apart from some acronyms and foreign words, Hsoi equals me. It’s nice to have a globally unique identifier, because there are other John Daub’s out there.. There are disadvantages to being unique, a discussion for another time.

The one thing I have still been reluctant to do is post my picture online. Oh sure, there are some pictures of me online, but usually my face wasn’t directly visible. I’ve had some bad experiences in the past with posting pictures online, mostly because there are assholes in this world and I have better ways to spend my time and energy.

Nevertheless, a friend of mine who is really into social media made a good point. Your avatar is who you are online. It makes a big impact and impression. I recall meeting lots of people in real life that didn’t ring a bell until I was able to put their email address with their name and face. That was kinda weird to know them more by their email address than anything else, but yes it’s a unique identifier. I’d rather know people by their faces. Call me old school that way, but it’s far more personal to be able to associate a name/blog/email address/twitter account/username/etc. with a face.

So, I finally hooked into Gravatar and put my face back online. We’ll see how it goes.

Questions from the search stats

/ hsoi

It’s always interesting to see what the search stats turn up.

Ruger SR-22

This has been an amazingly popular search term. I haven’t seen anything like it in my blog stats before. People are really curious about this firearm. It’s interesting for sure, and to me the real interesting factor is the possible side-effects of producing such a firearm. I still have no compelling reason to buy one tho.

Hornady Critical Defense

This is another very popular term. My initial posting is here, but if you search my blog for it you’ll find other postings on it as well. The ammo is certainly interesting and I applaud Hornady for continuing to find ways to serve the civilian self-defense market. I also applaud their efforts to focus on “small calibers” popular for concealed carry and trying to find ways to improve upon the terminal effectiveness of cartridges in those calibers. That all said, I’m not yet sold on this ammo being something for me to trust my life on. It’s too new to the market and there just hasn’t been enough testing beyond some simple ballistics gel and newspaper wetpack testing. I’d like to see more data. Meantime, I’ll stick with Gold Dots for my 9mm and the LSWCHP’s for my .38 snub.

is a 9mm gun good self defense

Nope. It’s a good tool that can help you physically defend yourself, but really the best self-defense is using your gray matter. Get training, get skills, gain awareness, and conduct your daily life in a manner that works to keep you safe. That’s really better for self-defense. But if it comes to that point, I feel my 9mm handgun is a useful tool to have.

how to expand compress in snow leopard

StuffIt

(but I’m biased)

can you shoot a 45 bullet with a 9mm

Sure, if you’ve got really good aim and a steady hand… amazing what those sharpshooters and trick shooters can do. 🙂

But if you mean can you chamber a .45 ACP cartridge in a gun chambered for 9mm Luger? Nope. A .45 bullet has a larger diameter, just won’t work.

kimber with dawson precision sights

Envy. A 1911 is in my future… someday.

what does chl exam looks like

If you are curious about the Texas Concealed Handgun License course of fire, here it is.

“fear of girls”

Funny stuff.

9mm +p+ in any pistol

No. Only in pistols specifically rated as being able to handle +P+ (means that the round has about 15% greater pressure than a standard round). Using +P+ in a gun not rated as being able to handle it could have catastrophic results. If you’re not 100% sure the gun can handle it, don’t do it. If you’re not 100% sure, contact the manufacturer and ask (or check their website, they may have manuals online).

martial arts canes

Damned if I can find sources other than Cane Masters and Goju-Shorei for good fighting canes. I myself am looking for others. Not that I have a problem with what these guys are doing (I hear only good things about the quality of the CM canes) but I just want to see more selection.

If you know of any other cane makers, especially small guys that do good hand-crafting, please let me know.

selecting a gun for kids

Depends what you want to do with them (and I’ll avoid the obvious jokes and snark on this one), plus it depends upon the kid. But IMHO the best way to start out is with a .22. This is because for most kids, the power of recoil may be more than they can handle. Plus larger calibers are going to be louder, which can affect a lot of kids in negative ways. Ease them into things. Make it fun, make it easy (e.g. put the target at 5 yards not 50). If they can do something like shoot at some cans or gallon water jugs… i.e. make the target do something, that helps to make it fun.

But even tho they’re kids, don’t overlook getting them good training and ingraining proper safety habits. Safety is paramount.

OmniObjectMeter, I love you

/ hsoi

Last night and this morning I’ve been dealing with some odd behaviors in the code I’ve been writing. I know it’s my mistake, the trouble is finding just where the mistake is. I spent time in the debugger observing behaviors that lead me to believe some object instances were not being released thus causing the side-effects I was seeing. As well, the lack of deallocation is a pure memory leak. So, find and fix the leak and many things should improve.

The current tool from Apple for finding memory leaks is the “leaks” tool of Instruments. I do think Instruments is cool and very powerful, but it’s also extremely obtuse and complex. It’s a tool that I don’t need to use all the time (in fact, rarely). Consequently what I learned the last time I needed it has left my head so I have to ramp up all over again. That’s just too much precious time spent, and too many brain cycles distancing myself from the problem at hand. Tools should not get in the way of solving your problem. Before Instruments, Apple had tools like MallocDebug and ObjectAlloc, which were useful and simpler tools but still weren’t the best in terms of interface and usability.

Some years ago I discovered OmniObjectMeter from The Omni Group. It was a godsend. It allowed me to pinpoint and track down memory leaks quickly and easily. It was so simple, so logical, so well thought out. It was easy to get going with it, it was easy to use it, and most importantly you could find your problems very quickly. Unfortunately OmniObjectMeter was left to languish and didn’t work for some time (there was a “secret beta” that helped it limp along). But I’m happy to report it’s back up and kicking with version 2.6 that was released February 2009. You see, I tried using Instruments this morning and while I could see the leak I couldn’t exactly pin down the location that caused the leak. I lamented for OmniObjectMeter, checked the Omni website on a whim, discovered v2.6, downloaded it, and within 5 minutes my leak was found, fixed, and verified.

That’s testimony. 🙂

I’m glad she’s still working. Plus, now OmniObjectMeter is free! I’m proud to say I paid for my copy (well, I got the company to pay for it) all those years ago. So FTC, yet again this is just a satisfied customer telling the tale of his happy experience.

AppleScript is not dead (yet)

/ hsoi / 5 Comments

Jason Snell @ Macworld has an article reacting to Jonathan “Wolf” Rentzsch‘s declaration that AppleScript is dead.

Hrm… get this. That previous link to AppleScript takes you to the developer web pages for AppleScript. I originally wanted to link to Apple’s user/commercial page for AppleScript: www.apple.com/applescript. But if you click on that, notice what it takes you to: Automator. That tells you what Apple thinks about AppleScript as a technology.

It’s scripting for the rest of us.

Continue reading →

Snow Leopard’s file system changes

/ hsoi / 2 Comments

Mac OS X 10.6 “Snow Leopard” brought a slew of under the hood changes. There are two distinct but related changes that Apple made that most users will probably never notice and many developers probably never will either. But if you happen to be someone who works with the file system, these changes may affect you. These changes are:

1. KB vs. KiB. That is, is a kilobyte 1000 bytes or 1024 bytes.

2. file-system-level compression of files

Since I recently went around with these, I felt it’d be worthwhile to share what I discovered, since there isn’t much information out there on the topic. The only thing I found that remotely discussed the matter was this page of Ars Technica’s Snow Leopard review.
Continue reading →

But what if you need more when installing?

/ hsoi / 6 Comments

As a developer of Mac OS X software, how to deliver that software is an issue of constant battle.

Long long ago, everything was shipped as either an installer or just in a StuffIt archive. Typically applications came in installers and the only thing in StuffIt archives would be non-applications (documents, pictures, other data).

Mac OS X tries to change this by simplifying things using drag-installs. It’s actually a very simple process of download, drag the application icon to the Applications folder, and off you go. But, even something as simple as that can prove too confusing for the lay person, or at least it allows for a host of problems. Installers still exist as well, and there are many other modes of delivery and installation out there.

Various bloggers have been discussing the issue. It starts with FireFox distribution issues, where they ultimately conclude that you should just ship an installer and piggy back off other mechanisms (e.g. automounting of .dmg’s). John Gruber counters that we should just use .zip files, and makes rather compelling arguments for that approach. Chris Clark also agrees with using zip archives. Andy Kim takes it a bit further and actually starts to touch on what I’m going to hit at.

All of these solutions are nice, but they all seem to target one thing:

Very simple applications.

If all your application is is itself, then I guess that’s fine. But what if your application has more than just the application itself? What if it needs to install drivers or other kernel extensions? What if it had launch agents or daemons? How about other plugins that need to be installed? Maybe something that requires a restart of the machine? What if you need to run scripts to deal with housekeeping (e.g. to help upgrading past users to the new version of the software)? All of these simplistic approaches just do not cut it.

Some would argue this should be a part of the application itself. That is, self-healing applications. I see merit in that approach and it could be a solution that solves this and the initial download-and-install problem. But it is not a panacea.

The ultimate problem is there is no one-size-fits-all solution, which seems to be what people are proposing… or at least, they’re not considering the wider scope that some developers may need in the install process. Apple seems to have the tools in place, but isn’t quite there. What ought to come would be:

  • A new installer format. It could be an archive holding all the parts to be deployed, but it should allow for logic to be applied during the install (e.g. use of shell scripts, etc.).
  • This format is understood by the OS, so when applications such as Safari download them, they can start the install process. Of course, we have to be mindful that some people could use this for nefarious purposes, so being fully automatic is not ideal… asking the user would be helpful. Using code signing and other forms of trusted computing may help here.
  • The notion of installing then isn’t just some file format, but is also considered an end-to-end process, from either downloading the software or inserting the removable media that has the software on it, to getting the software installed, configured, registered, and cleaned up after (optionally removing older versions of the software and its support files, removing any archives, trying to leave the machine in a cleaner state than before it started). Get the users going the whole way through. It should “just work”; Gruber’s mention of how the iPhone works is apt.
  • To publish a set of tools AND guidelines on installer creation. Apple goes through a lot of trouble to establish human interface guidelines on how applications should work. Apple can and should do the same with installers so that the experience of getting software to users can be as simple and pain free as possible, but also as consistent as possible.

The big problem we have today is too many approaches to installing software. Everyone has different needs and different thoughts on how best to approach it. I’ve had debates at my office about how we should deliver our software, and it’s difficult to achieve consensus because all approaches have strengths and weaknesses. This only serves to hurt the user because there isn’t one way that “just works” for them to get to know and be comfortable with. Every install process is different and unique, and for the non-geeky types, just frustrating and confusing.

I hate to say it but the movement to improve this will ultimately have to come from Apple. It’s their platform, it’s their user experience that they wish to control and dictate. Ultimately Apple must be the one to improve this.

Can we 3rd party developers do something about it? Sure. We could work to tackle the problem, publish our own guidelines, create tools to help out. But I’m not sure how far it would get. Efforts like Growl, Sparkle, solve some great problems and didn’t come from Apple and have gained a tremendous amount of traction in the developer world. Still, some venture to do it themselves. Code solutions are good, but guidelines are better so if you have to do it yourself, at least some guiding principles can be followed with the hope of still making things good for the user.

Where to start?

Mac OS X x86 debugging

/ hsoi

It’s been ages since I’ve had to do anything dealing with assembly language. And while I may not have to do much programming in it, it’s still a useful thing to know when it comes to debugging.

Today I’ve been trapped in debugging hell. We’ve got some code that works fine on Mac OS X versions prior to Snow Leopard (10.6) but seems to hang under 10.6. The code flat out executes differently. I watch how our code is invoked and things just don’t happen in the same order across the OS versions. Apple must have done some major under-the-hood changes to NSBrowser and NSTreeController. And since we’re using Cocoa Bindings, it’s a bitch to debug. Everything that’s happening is happening because of Key-Value Observing (KVO). I get somewhere into the bowels of NSBrowserBinder and it appears to be looping… looping… and never exiting the loop for some reason.

Now that we’re in the new x86-based world order of Macs, I went looking for some tips to help me work with debugging the x86 assembly so I could see what the OS was doing. I found a few useful resources.

Greg Parker at the Hamster Emporium has a great article about crashing in objc_msgSend and how to decipher the crash. I wasn’t crashing, but still there are some nice gdb commands and interpretation of the registers.

Then over at the Google Mac Blog, a 2 part article on spelunking. Part 1 and Part 2. These aren’t debugging articles (more like trying to hack around and discover how undocumented functions work), but they still explain a bit about how the x86 ABI works, AT&T syntax, and how Mac all mesh together. Note that Avi Drissman previously published the same article in his own personal blog, but edited it a bit for republishing in the Google blog.

Clark Cox provides a handy table on how to inspect Objective-C parameters in gdb.

And you thought the only thing I knew how to blog about was guns. 😉

Why did Apple do this?

/ hsoi / 3 Comments

No sorry… nothing about today’s Apple fan-boy event. More as to why I didn’t post much today.

Apple’s new OS version is 10.6, named “Snow Leopard.” Snow Leopard brought about a lot of under the hood changes to the OS. One of them is fairly well covered on this page of the Ars Technica review.

Basically, Apple did some stuff very very low level to help with reclaiming some disk space but also taking advantage of the volume format layout of HFS+ and how they can use that to their advantage to speed things up… RAM and CPU’s are wicked fast these days, and disk drives are still abysmally slow by comparison (physics can only go so far). So Apple did some neat things to improve speed and access times, and for the most part it works out great. Most people will never notice.

But in the line of work I do… I’m not most people.

The software I develop in my day job does a lot of working with the file system. So all of these changes that Apple made are actually wreaking havoc and hell on me right now. Long held maxims like a file’s logical size will never be larger than its physical size…. out the door. That calculating sizes is now base-10 instead of base-2 (i.e. 1 kilobyte is now being calculated as 1000 bytes instead of 1024 bytes)… changes a lot of things.

I’ve been reevaluating our entire codebase (which is huge) and this just doesn’t play well with us. All I can do at this point is formulate a lengthy email to Apple’s Developer Technical Support and ask for some help and guidance.

It’s been a trying couple of days.

I’m glad I have Kali class tonight. That should relieve a little stress. 🙂