[...]
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: CD_partition_scheme Audio CD *620.3 Mi disk3
[...]
kalevala:~ leeg$ diskutil mountDisk disk3
Volume(s) mounted successfully
Job is, as they say, a good 'un.
Darwin, Mac OS X, Cocoa, OpenStep, NeXTSTEP. Mac security. All the things you expect from a tech blog, including complaints about the temperature of my coffee.
Title linkies to a post by an F-Script guy (the F-Script guy? I'm not sure, I don't really follow F-Script development) about nice things he likes about the Objective-C language. Remembering that he wrote a Smalltalk scripting environment for Cocoa, some of the list is fairly unsurprising, much is made of the dynamic runtime, multiple-level dispatch and so on. I think the article is mainly bang on, though I do disagree with the author in a few places. The next paragraph is not one of those places.
Classes are objects. ++ This is the coolest thing ever about proper object-oriented languages, and one of my strongest arguments for design patterns are not language independent. Do patterns such as Prototype need to exist in ObjC code, when the Factory Method +new will give you an unconfigured typical instance?
Dynamic typing... Optional static typing. This is one of those slippery slopes where both edges are sharp enough to give you the rope required to shoot yourself in the foot. Duck typing (i.e. if an object looks like a duck, and quacks like a duck...) is useful in some cases and damned annoying in others. To avoid runtime exceptions with duck typing you either have to [i]mentally assert correctness in your code, [ii]perform all the runtime introspection needed to ensure your messages will be handled, or [iii]eschew the duck type completely and downcast to either an instance of a class or a conformant of a protocol (or both; you could do something like GLModelObject <NSCoding> * if you really felt like it). Another issue with the ObjC implementation of duck typing is that it doesn't always work as you'd think. When it does work, it's very powerful - when it doesn't, you probably won't find out until runtime, and could be spending a long while working out what happened.
Categories. No, afraid not. Nice idea, badly implemented. The point of categories is to let you decorate a class with additional functionality by adding methods - currently not ivars - in additional code objects, not all of which need be present at launch. This lets you work around the visibility contract of the class (can't see an @private ivar? Just chuck an instance method in!), though in fairness so does KVC. But perhaps the worst crime a category can commit is killing someone else's category. Or overwriting an "undecorated" method.
I still love Objective-C, mainly because I love Cocoa and GNUstep and making code that works like them, it's definitely powerful and fun too. But it's not without its rough edges and sharp spiky bits.
For some reason, even though l10n and i18n have been fashionable terms in computing for the last few years, no-one seems able to localise properly into the lingua franca of computing, English. It may surprise some readers to learn that there's more than one dialect of english, and some of these even have their own ISO codes (such as en_GB, en_US and so on...I'm ignoring the "ang" language for now). Some words in these different dialects are not spelled in the same way. I live in the United Kingdom of Great Britain and Northern Ireland (Land of hope and glory, mother of the free...) and therefore those round things are known as discs. Indeed, when I insert my Mac OS X installer disc, it is called "Mac OS X Install Disc 1". Then I launch the Firmware Password application, which tells me: "The firmware password is used to prevent others from starting your computer with a different disk." Gah!
Due to a lack of digit extraction I'm not at FOSDEM this weekend. That's unfortunate because as well as catching up with my friends at Brainstorm and on GNUstep, I really enjoyed the weekend last year and drank plenty of great Belgian beer and ate plenty of nice moules-frites.
So I've been spiritually living the Free lifestyle by reading what RMS and Torvalds have to say. Mostly I've been going over the essays in Free Software, Free Society. I find it very easy to accept the premises RMS uses, easy to follow, comprehend and agree with the arguments he presents but then somehow (perhaps for illogical reasons on my part, his part or both) hard to agree that the conclusions he draws are inevitable.
For instance, I agree that copyright law exists directly to benefit the public, and indirectly to benefit the authors (by providing incentives for authors in the shape of limited term monopoly over their authored content) and not at all to benefit Industry Associations. It even says that here, in the first ever copyright law: ...for the Encouragement of Learned Men to Compose and Write useful Books; May it please Your Majesty, that it may be Enacted...
certainly doesn't seem to mention greedy lawyers or management.
Letters patent were never created for the same reason, of course. But because it became clear that patents from the Crown were obtained uppon Misinformacions and untrue pretences of publique good, many such Graunts have bene undulie obteyned and unlawfullie putt in execucion, to the greate Greevance and Inconvenience of your Majesties Subjects, contrary to the Lawes of this your Realme, and contrary to your Majesties royall and blessed Intencion soe published
, so the whole system was rebooted so that patents were only grantable ... to the true and first Inventor and Inventors of such Manufactures, [...] soe as alsoe they be not contrary to the Lawe nor mischievous to the State, by raisinge prices of Commodities at home, or hurt of Trade, or generallie inconvenient...
.
The situation we find ourselves in now is that industries claim copyrights and inventions from the authors and inventors and lobby for more and more restrictive variants of the above laws, ignoring the previously-granted rights of the public at large and extending the previously-ungranted rights of the rights-owners, simultaneously removing those rights from the people granted the rights in the first place. So why in the case of copyright do the FSF assume copyright, but in the case of patents they refuse to deal with them? That inconsistency I don't understand.
It's getting there, now has the ability to display load commands (though it only reports useful information for LC_SEGMENT and LC_SEGMENT_64 commands):
Again the screenshot depicts the OmniDazzle binary for no reason other than it's a nontrivial file. The directions in which to take the filesystem are now numerous: I can add info about the remaining load commands (v. useful), the raw data for each segment (somewhat useful), and the sections in each segment (v. useful). Whether the filesystem will eventually get to the level of symbol resolution, I'm not sure :-).
When looking through some of the configuration options on my laptop (well, it's either that or go to the pub and socialise with humans) I came across something I couldn't account — pardon the pun — for. A new user account on the system, short name messagebus, full name "Message\ Bus" user id 506. Now messagebus looks like the name of a system daemon user, but that full name looks like some clueless skiddie made a mistake creating the user account, especially as the uid is that of a regular user. That's the kind of mistake no self-respecting installer would make.
So, what had this phantom user done? Well, thankfully, nothing. Neither the shell nor home directory was real, and wtmp/utmp showed no activity. Neither did the ssh logs - but in looking for them I realised that I don't actually use ssh on the box, so turned it off.
Anyway, it turned out to be an innocuous issue - the MacPorts installer for dbus creates this bogus user, which I've since deleted. This Apple forums discussion explains more.
It needs some polishing and more functionality before I'd call it useful, then I have to find out whether I'm allowed to do anything with the source code ;-). But this is at least quite a cool hack; exploring a Mach-O file (thin or fat - in this case, I used the OmniDazzle executable which is a fat file) as if it's a file system. FUSE of course makes it easy, so thanks to Amit Singh for the port!
One reason that microkernels win over everything else (piss off, Linus) is that stability is better, because less stuff is running in the dangerous and all-powerful kernel environment. MacFUSE, like FUSE implementations on other UNIX-like operating systems, takes the microkernel approach to filesystems, hooking requests for information out of the kernel and passing them to user-space processes to handle. Here's the worst that can happen when screwing up a FUSE filesystem:
Now that might sound not only like a recipe for lower-quality code, but also like I'm extolling the capability to create lower-quality code. Well no it isn't, and yes I am. The advantage is that now the develop-debug-fix cycle for filesystems is just as short as it is for other userland applications (and HURD translators and the like). This provides a lower barrier to entry (meaning that it's more likely that interesting and innovative filesystems can be created), but also a faster turnaround on bugfixes (no panic, restart, try to salvage panic log... no two-machine debugging with kdb...) so ultimately higher-quality filesystems.
The justification for the iPod Touch upgrade fee (to enable the new apps, which are actually deployed-but-disabled by a free firmware upgrade) is the same as the justification given for the MacBook wireless upgrade fee last year - that adding new features to a product that isn't sold as a subscription service needs to be charged for. That in itself is odd - it means that the regulators in the States get to set a price (if not the price) for hitherto free products offered by companies. But it raises a more interesting question - what constitutes a new feature? If a bugfix renders a previously-unusable feature usable, is that charged for? If a security fix makes it possible to use a system in a different environment, should that be charged for?
About nine and a half years ago, a sixteen-year-old gadget boy in Weymouth made a simple mistake. Given the already near-complete shift of the music industry from the cassette tape to the Philips compact disc, and the superior portability and resilience of the Sony MiniDisc format, this boy decided that it was obvious the world was going to adopt this format. So our protagonist went out and bought a MZ-R35 walkman. Three years later, and although the writing was by now on the wall for the storage format, he added an MD-M3 to his collection.
I now believe I own all five pre-recorded MiniDisc albums ever made (though I don't remember when I bought Hours by Bowie, and can only think that I bought Recurring Dream because at the time I fancied a girl who liked Crowded House), and have swathes of my vinyl and tape collection "backed up" to recordable MDs. But the rest of the world forgot to catch up with me! Where are the Hi-MD drives built in to laptops? Even Sony don't offer that... Come to that, why do we still put up with crappy scratchable CDs? iPods may be a damn sight more convenient than my MD walkman is, but the bandwidth of an amazon package containing MiniDiscs is still far higher than the connection between my laptop and iTunes.
I still intend to find the required cable and port the rest of my LPs to the format though, as MDs are definitely more portable and resilient than is vinyl. And I haven't actually listened to Bauhaus' 1979-1983 in years.
As in any good mystery, the question is who done it? MacNN reports a flaw in Tiger, Leopard in which an authenticated copy operation gives the destination files (the copies) the ownership of the logged-in user, not of the name they used to authenticate. The question is, which user did the copy?
Let's say there's a system with Alice Administrator and Richard Regular-User. Richard downloads a new application from the intarwebs, and wants to put it in /Applications (though why? Why can't he just put it in ~/Applications like a good little user? Never mind). The thing is, he doesn't have the right to do that. Finder presents him with an authentication dialogue, and no matter how many times he enters his username and password correctly, he can't acquire that right. However, he sees Alice walking past in the corridor and asks her to enter her admin credentials. For whatever reason, she agrees - now Alice has authenticated and Alice has acquired the right to copy the files. So even though Richard requested the copy, it was actually Alice who performed it. Therefore Alice created the files at the destination, so they should be owned by Alice.
The only thing which muddies the waters (and leads to the conflict of convenience vs. security which is described in that article) is that in many, or indeed most, cases on OS X where this will arise, Alice and Richard are actually the same person - Sammy the Single (Security-conscious, hence separating their use of the system into regular and admin accounts) User. It's a convenience that as Richard wanted the files copied, Richard now owns the copy - but this defeats the point of Richard existing, which is that Sammy doesn't want to be able to change /Applications without being warned.
Interestingly the same question doesn't get asked of the sudo command - it's clear that if I type sudo ditto Foobar.app /Applications/Foobar.app it's the super-user who does the work.
A frequently-heard rider on the statement that Mac OS X "is more secure than Windows" is that fewer people are prodding its weak spots, because it has fewer users. Well, Windows Vista has a market share comparative to Mac OS X (all versions), and this report describes the security statistics as being somewhat comparable, too. So there we go.
Yes, really, every problem. Don't think of Cocoa as "simple things simple, complex things possible" (actually, was it Cocoapenextstepsody or Perl who started with that tagline? Or someone else? I digress) but "simple things simple, complex things simple but you're looking at it wrong". With Objective-C 2.0 (particularly properties), Core Data, Cocoa Bindings and Cocoa Scripting, almost every "it doesn't work" moment comes down to getting something wrong with KVC or with KVO - either observing the wrong key, or typoing a method name such that you aren't KVC-compliant for a key you need to be, getting validation wrong or unexpectedly going down the -setNilValueForKey: path. So do yourself a favour:
#define GLInstanceMethodEntryLog(format, ...) NSLog(@"-[%@(%p) %@] entry: %@", NSStringFromClass([self class]), self, NSStringFromSelector(_cmd), [NSString stringWithFormat: format, ##__VA_ARGS__])Now because all of the retain count bugs disappeared when you turned the garbage collector on, the remaining issues are with that bit of code the PHBs are paying for ;-)
I was going to write, am still going to write, about how silly project names get bandied about in the software industry. But in researching this post (sorry blogosphere, I've let you down) I found that the Software-generated Gannt chart was patented by Fujitsu in the US in 1998, which to me just explains everything that is wrong with the way the US patent system is applied to software. For reference, Microsoft Project was written in 1987 (although is not strictly prior art for the patent. Project does everything in its power to prevent the user from creating a Gannt chart, in my experience).
Anyway, why is it that people care more about the fact that they're going to be using Leopard, Longhorn, Cairo, Barcelona or Niagara than about what any one of those is? As discussed in [1], naming software projects (though really I'm talking about projects in the general sense of collections of tasks in order to complete a particular goal) in the same way you might name your pet leads to an unhealthy psychological attachment to the project, causing it to develop its own (perceived) personality and vitality which can cause the project to continue long after it ought to have been killed. For every Cheetah, there's a Star Trek that didn't quite make it. And why should open source projects like Firefox or Ubuntu GNU/Linux need "code names" if their innards are supposed to be on public display?
I've decided that I know best, of course. My opinion is that, despite what people may say about project names being convenient shorthand to assist discussion, naming your project in an obtuse way splits us into the two groups which humanity adores: those of us who know, and those of you who don't. The circumstance I use to justify this is simple: if project names are mnemonics, why aren't the projects named in a mnemonic fashion? In what way does Rhapsody describe "port of OPENSTEP/Mach to PowerPC with the Platinum look and feel"? Such cultish behaviour of course leads directly to the point made in the citation; because we don't want to be the people in the know of something not worth knowing, we tend to keep our dubiously-named workflow in existence for far longer than could be dispassionately justified.
Of course, if I told you the name of the project I'm working on, you wouldn't have any idea what I'm working on ;-).
[1]Pulling the Plug: Software Project Management and the Problem of Project Escalation, Mark Keil. MIS Quarterly, Vol. 19, No. 4 (Dec., 1995), pp. 421-447
Certain events at work have turned me into a bit of a design patterns geek of late, and as such I stumbled across this DDJ article from 1997 (the title of this post is the link). According to del.icio.us not many other people have stumbled across it, but it's a great article. The code listing links seem to 404 even though the listings are at the bottom of page 1 of the article.
Something very important can be learned from this article, which is at best covered tangentially in the GoF book: Design patterns are not language-independent. Calling the C++ and Objective-C ways of writing code "pattern idioms" ignores the point that actually, the code you come up with is more important than the design (customers don't typically want to pay the same cash for your UML diagrams that they do for your executables), and gasp different languages require different code! Different patterns can be used in ObjC and Smalltalk than in C++, and different patterns again in object-oriented Perl. Different patterns will be appropriate for working with Foundation than with the NeXTSTEP (pre 4.0) foundation kit or with ICPak101. Designing your solution independent of the language and framework you're going to use will get you a solution, but will not necessarily produce the easiest solution to maintain, the most efficient solution or one that makes any sense to an expert in the realm of that language and framework.
I have organised a NSCoder Night for this coming Tuesday, November 27. It shall be in the Jericho Tavern pub at 8pm; bring yourself, bring an interest in Cocoa, and perhaps bring some code to talk about or work on. There won't be any agenda as such, just a group of NSCoders talking about NSCoding.
In January, PaulHR and I shall be entertaining OxMUG on the subject of Getting Things Done™ - in particular I have now started braindumping my many to-do lists into OmniFocus and I'm finding it very expressive and useful. In fact preparing that talk has just zoomed its way over to my OF inbox :-). That talk shall be Tuesday, January 8th.