Monday, November 21

Frameworks are Teh Suck, Err.

abstract

Apple's shared frameworks are very useful for sharing executable code and its associated resources among multiple applications, but were historically not designed to be created by authors of consumer applications. I discourage developers from creating frameworks as a method of sharing code, because they encourage code bloat, increase launch times, complicate the developer's fix/compile/link/debug cycle, and require extra effort in setting up correct and useful developer and deployment builds.


article

The Origins of Shared Frameworks on NeXTstep

It will help us to understand the limitations of shared frameworks if we examine the prevailing conditions for the time when they were created on NeXTstep. The user-base of NeXT machines was largely businesses and schools; institutions which generally had a knowledgeable system administrator in charge of clusters of machines and which typically ran suites of custom applications; consumer software for the NeXT was not as common. The net was not as broadly adopted, so application patches were largely unheard of; bug fixes and new versions were relegated to major releases.

Application installation in those days was done by the Installer, which could install resources in different directories throughout the disk, and left a record ("receipt") of what it had done so the installations could be reversed. Many sites also had a server machine vending a shared disk of applications and resources, so application installation only had to be done once.

Disk space was much more expensive, as was RAM. Any way to minimize the use of both was a huge win.

Shared frameworks were created by NeXT (and many others at the time) to allow multiple applications that need to use common code (eg, window handling or graphics drawing code) to link against a single binary, and thus even when, say, ten applications are running that use graphics, only a single version of NeXT's graphics drawing code has be to physically in memory.

NeXT's take on shared frameworks was more clever than most, in that frameworks took the form of directories, containing the code and its associated resources: localization files, images, sounds, and interface descriptions (NIBs). This provided a very convenient encapsulation of shared system resources (although there weren't provisions for multiple applications sharing a single copy of these).

Initially NeXT kept shared framework creation to themselves, but in a later release they allowed third-party developers to create them as well. For developers of custom applications for businesses, this was a godsend, as typically custom applications come in suites, and have a ton of shared code. For instance, at AT&T Wireless (an early NeXT adopter), they might have an application where they can look up the last call a subscriber made, and another application where they can change a subscriber's rate plan. The basic code to look up and display subscribers could now be shared between the two applications, which saves on disk space and physical memory when the program is run, and provided an easy way to re-use code and resources in multiple applications for developers.

The distinction between the two functions is important to make, because almost all third-party developers now take advantage of only the second benefit when they create their own shared frameworks, and the crux of my argument is that shared frameworks are a relatively inefficient way to accomplish this one result.

In order to benefit from the savings in disk space and physical memory in an installation, an end-user need two critical things: she needs to have installed two applications from a single vendor, and she needs to have installed the frameworks associated with those applications in a shared folder (typically, /Library/Frameworks/), so that all the applications know where to look for them.

This was not a problem when applications were installed with the Installer, because the Installer could, as stated, put files in multiple directories throughout the system. However, the trend in consumer applications (started by Omni, and rewarded with one of our first Apple Design Awards) became to have simple drag-and-drop installation of the application to wherever the user chose, which precluded installing frameworks in a well-known shared folder.

But not only did application creators who had a suite of applications that all used the same frameworks not know where the user might install those applications, they also didn't know which applications might be installed, so all "shared" frameworks had to be bundled inside even the smallest of applications.

This is the case today with Omni's applications; if you look inside the application wrapper (control-click on an application, and select "Show package contents") you'll find a Contents/Frameworks folder with copies of all relevant Omni frameworks in every Omni application you own.

Thus, there is no space savings from third-party frameworks, either in RAM or disk space.


Difficulties for Developers

But, the situation is worse than this. Frameworks are made of position-independent code, so they can be relocated in memory when linked against any arbitrary client application. This code is larger and slower than non-position-independent code, AND requires a quick fix-up at run-time when the client application launches. This fix-up time can become quite lengthy if there are lots of frameworks with lots of symbols used by any given application; in the old days Omni applications would spend many seconds loading their frameworks on launch.

[I don't mean to keep picking on Omni, but since I had a big hand in creating their open source frameworks, which are one of the largest and most popular collections of open source Cocoa code out there, I know details of the problems we encountered, and that I solved by giving up on frameworks.]

This can be ameliorated by creating frameworks at a fixed location, but you have to (a) read a bunch to understand how to do this, (b) make sure no two of your frameworks overlap, and you don't overlap anyone else's third-party frameworks that you might use, and (c) set up your build system to do it. This was actually a huge hassle at Omni; I was on the team that tried to streamline the process and it's still not something that is easily grasped by newcomers to coding.

But the situation is worse than that, because even after an application loads a framework into the right place in memory, the application has to adjust all its own symbols to point to the correct places in the framework. Luckily, Cocoa handles all of this for you, but unluckily, it takes time.

Again, this can be ameliorated by prebinding against the frameworks to which you've already assigned a fixed address (from above). Again, this is kind of a complicated process, and you spend a bunch of time learning nm and other tools trying to figure out if your application is "correctly prebound" with the frameworks.

But, it gets worse. When developing, your application probably does NOT want to prebind against the frameworks, because prebinding takes extra time in the link cycle. So, you have more setup in Xcode to sometimes prebind and sometimes not.

These are just the problems and slowdowns with loading frameworks at run time. There are also myriad problems in having your source code split up into several projects in Xcode (eg, a client application project and a framework project).

For instance, you probably have some build settings you want to enforce on your project; you like to debug with optimization level -O1, but you like to deploy with -Os like Apple recommends this week. Well, you'll have to copy those settings to every Xcode project for every framework you have. And make sure they stay updated.

Does this sound like duplicated code? The thing I hate most in the world? Yes, yes it does.

Also, you need to make sure when you're doing a development build that you link against the development versions of the framework you built in your development directory (because it's a pain to copy in the enormous with-symbols versions of the frameworks into your application every time you do a debug build), but you also need to make sure your deployment rules correctly do copy the frameworks into the client application's wrapper, or the app won't run. So, you get to write a bunch more Xcode configuration code, and, hey, you get to copy it into every application you write. And, oh boy, if you update it one place, be sure to remember to update it everywhere. (I believe the very latest Xcode has shared settings to help this situation, but you still have to write the darn configuration code.)

And, you need to make darn sure you don't confuse which versions of the frameworks you are linked against at any one time; eg, if you make a special debug build of the frameworks with some odd options, then you debug one of your other applications which use the frameworks, you'll suddenly have some very odd behaviors. (This happens more than one might imagine.)

And, when you do a deployment build, you want to make sure you strip the headers from your frameworks, as well as any subversion files. Yes, you get to write more Xcode configuration code. And copy it around to all your applications. Oh, boy.


Difficulties for End-Users

Now, why are you creating shared frameworks again? Because you want to re-use code in multiple projects. This is a noble goal. However, frameworks make it too easy to just throw every dang class that might be useful into them, so the developer forgets to ever prune old files that are no longer used at all. Because, if you have multiple framework projects and multiple application projects which use them, and you wonder if any particular framework class is used, you have to search through all of these projects for references. At Omni, this was forty-something projects to open; just opening them all took minutes, let alone searching them.

So you end up with a lot of extra code in your application that none of you applications still use. How do I feel about extra code?

But also, even worse, you end up linking in a lot of extra code that some applications use, but not this application. Because, unlike a standard library, there's no such thing as partially including a shared framework; you either grab all of its functionality or none.

How bad of a problem is this? Well, consider OmniDictionary. It connects to the network, downloads a definition from a dictionary server, displays the HTML. Simple. It uses some of the classes from the Omni frameworks to do this, but not nearly all of them.

Still, it has to include ALL of the code from any framework it touches, and ALL of the associated resources (image files, NIBs, etc), and ALL of the frameworks which that framework uses, as well.

With OmniDictionary, the frameworks it bundles with take up 1.6 megabytes. The actual application takes up 448 kilobytes. The application takes up four times as much space because of the frameworks.


The Alternatives for Code Re-use

Download and install subversion, and store all your source code in it, religiously.

Create a folder in your source code repository for each of your applications, and a folder for shared code and resources. In each project, in Xcode, drag only the files you really need into your project, and tell Xcode not to copy them into the project directory, and instead refer to them relative to the source directory.

Removing dead code from your shared folder is easy; at the worst you can just delete the files and do a build of your applications, and if the build succeeds you're not using them. Or you can open only your applications' projects (because what were your 'frameworks' now don't have projects associated with them) and search for the code, because your source files will never have any header imports of the form "#import "; they will have each file imported separately, and thus listed out for you to review and remove. (Conversely, if you decide to sunset a particular piece of code, it's very easy to find where it is referenced and rewrite the code. This happened recently to me when 10.4's NSXMLNode replaced my custom XML reading and writing classes.)

You don't spend any time configuring the frameworks' build environment because there isn't one. You don't spend any time setting up your frameworks' header file (eg, OmniAppKit.h) because there isn't one. You don't worry about whether your framework is pre-bound or position-independed because it doesn't exist.

What are the drawbacks? Well, when you include a source file in your application from your shared directory, you'll have to pay attention to which NIBs and images the files requires from the shared directory, and drag those into your application yourself. I think this is actually kind of good, because it also makes it possible to sunset images and NIBs. And, if you forget to drag in an image or NIB initially, it's an error you'll find immediately, the fix is easy, and it only needs to be done once. Thus, this isn't a problem that needs a complex solution.

Of course, if you have multiple frameworks, you might create a separate shared source directory for each one just to conceptually organize them. Or, keep them in subfolders. Whatever you like.

Note that subversion makes it very easy to modify your shared code for one project and not worry about affecting other projects; you can branch your top-level directory for any given project in subversion, and it effectively creates a copy-on-write version of that project, so you don't burn your entire source disk with a thousand versions of all your frameworks. When you're happy with a project, you can merge it back to the head (with the shared code changes) and check at _that time_ that your other applications like your newer and hopefully improved shared classes.

This brings up another issue, which is that with only one project per application it's much easier to associate a single tag with any given build, and then if a user or beta-tester encounters bugs you can go back to that version of the your source code with a single command. The problem with frameworks is it is too easy to ship different versions of the frameworks with any given build, so you end up reporting all your framework versions to the user to mention in bug reports, which is just another thing for the developer to have to check, and another avenue for error.

To get around this, developers with frameworks will write scripts to update their frameworks in a clean place and do a brand new build, but then those scripts have to be maintained by someone, and developers have to be educated about a particular site's practices. For instance, at Omni, only a few people in know how to do a beta build of a particular piece of software (not including many of the developers, but including the support personnel), so the beta process can be entirely gated by the availability of the support team.

In my alternative system, creating a beta build is as easy as opening the Xcode project, updating (inside Xcode), changing the target to "deployment", cleaning, and building. These steps are well-known to any developer, as they are all the same (except one) as during development.


Who Should Create Frameworks

Apple should, for one; because their frameworks have static base addresses, and because we all link against them at compile time, we don't suffer the same overhead by default that we do for third-party frameworks. Further, because every application is going to use, say, AppKit, and AppKit is installed in a known location, Apple's frameworks are correctly shared and result in saved RAM and saved disk space.

Companies writing suites of custom software, where they can use an Installer package and write the frameworks in a standard location, are also encouraged to use frameworks for the same reasons that Apple is.


summary

Creating shared frameworks is a lot of hassle for third-party developers of consumer software, introduces instability into the development process, and encourages slower and larger applications. Code sharing is better accomplished through creating new directories for shared code in subversion and judiciously including only the files and resources needed by any application in its Xcode project.


finis

Irony and sarcasm do not translate well onto the web. The title of this article and the previous Unit testing is teh suck, Urr. (sic) are references to the teachings of the Mooninites Ignignokt (who speaks in a sarcastic singsong and flips off the entire earth as hard as he can; "The pain is excruciating, but it's worth it") and Err (who is the Beavis to Ignignokt's Butthead).

The Mooninites are know-it-alls who come from a land where everything is better than here on earth, and they are far superior to us in every way. They pity us and our pathetic three dimensions, because on the moon they have five...

Err: THOUSAND!

Yes, five THOUSAND dimensions. Don't question it.

Labels: code

posted by Wil Shipley at 11:57 AM 27 comments

Saturday, November 19

Failure is Success.

While I hate to lend credence to the current Republican habit of double-speak ("Fighting is Safety", "Dissent is Terrorism", "Religion is Hate"), there are some dissonant clichés which actually make sense.

So it is with, "We have nothing to fear but fear itself," for example. Now, obviously, we DO have other things to fear, like, say, having our democratic government completely co-opted by corrupt, tiny-minded men whose only interest is in gathering and preserving wealth and power, at any cost.

Wait, where was I? Oh, that's right. Fear. I think what our friend was trying to warn us away from was something I've been trying to fight all my life, which is a fear of failure which is greater than the consequences of actually failing.

I mean, if someone asked you to jump out of a plane, you might rightfully say, "Uh, if this fails, I'll be a thin layer, so, no thanks." And I'm not going to take you to task for that.

But if I say, "Hey, if you want to design games, you should look at modding some current games and then put them out there on the web," and you say, "Well, I could, but I'd probably suck at it, so it's easier to sit here and watch Blind Date," then I'd have a problem, and I might even give you a stern lecture during that extra-long commercial break that comes after the second date wrap-up and just before the "Hall of Shame," which is never really very good anyways.

Irrational fear of failure is endemic in our society; I think it's the primary factor keeping most people from doing the great things they're meant to do. I've personally never met anyone who worked hard and fearlessly at a field and did NOT succeed. I know there must occasionally BE people who fail despite their best efforts, because I've heard "the stories," but there are SO MANY MORE who simply won't try because they've heard that you can't win.

Failing is to be strived for! If you aren't failing, you aren't at the edge of the envelope of your abilities, and if you aren't at the edge, you aren't stretching yourself, so you aren't learning, so you're just wasting time. Failing is how nature succeeds. Evolution works through failure of the poorest (they get et) more than survival of the fittest. Muscles grow because you work them to failure, and they then respond by getting stronger. Your spinal cord learns not to touch fire by getting burnt. Failure is not just handled gracefully by nature, it is critical.

So, seriously, have you failed today? If not, why the heck not? I mean, think of the consequences of failing, and if they aren't deadly and/or permanently disabling, then go ahead and bite off more than you can chew. Try to cook something that you just made up. Take a bike ride that's too far. Take your car into an empty parking lot and do donuts until you learn where the tires give. Start a project that might be too big for you.

What's the worst that's going to happen? You'll get laughed at? By Erin Martens, that cute girl you had a crush on in 11th grade? And she'll say, "That's why I never went out with you, you stupid idiot, it's because you're such a failure all the time"? And you'll die alone and unliked, and they won't discover your body until it's half-eaten by your cats, who actually had enough food, they just ate you out of spite?

You're right. When's Blind Date on?

--

Blog redesign: You may notice my blog looks a wee bit different. I'd like to thank everyone who sent me entries; there were many lovely ones. 20-year-old Spaniard Alex Bendiken's struck me the right way, so he gets 15 seconds of fame (from me, at least), and his iPod will be sent off as soon as he sends me his address. Congratulations, Alex!

Labels: business

Saturday, November 12

Sound & Vision: Site for the Blind, and Towards Computer Understanding of Language

Sometimes I'm hesitant to post things in my blog because I don't have time to do research on every idea I think up, so a bunch of them are going to be things of which other people have already thought, and posting half-complete versions of ideas that others have fleshed out is at best an exercise in arrogance and at worst harmful (in its inaccuracy) to the field I'm exploring.

However, I recently decided, "Screw that, it's my blog, and I can ramble about whatever topics I like." I'll just preface some of my ideas with a disclaimer: I'm not an expert in this field, I'm just playing with ideas in my head, and I hope people who know more will expand and expound on what I'm explaining.

--

On 'seeing' for the blind: my previous post alluded to a device in which a blind person hooked a camera up to her forehead, a bunch of piezoelectric rods to her chest (or feet or tongue, maybe), connect the two, and could "see." This has already been done, as I thought, but I have been unable to determine if my twists have been implemented (I've actually done a bit of research here, and written one of the leading scientists, who is on the road and can't answer), so I'll explain my whole idea, and place it in the public domain.

The full idea is you run an edge-detection algorithm on the image from the camera (in real-time), so that instead of trying to present the full data you only present the edges, which is what the human eye is good at detecting anyways (cf, "mach banding"). I believe that, using this system, it would be very easy to detect, say, a post two feet in front of your eyes, because if you moved your head back and forth five or six inches the edges of the post would whizz across your chest in a very noticeable fashion, and even though the chest may not be innervated enough to detect subtle difference in a static field of poking rods representing complete image data, it can certainly feel if there's something brushing across it if you use edge-detection.

Thus, the emphasis would be on detecting motion, not depth or color or hue or brightness or anything like that. Many animals have relatively poor eyesight but are extremely good at detecting motion (cf, owls), and they do OK. Hell, owls can fly.

There are a couple of cool twists you could add to this system. One would be using an infra-red camera and adding a bright infra-red LED that was offset from the camera by a couple feet. This would provide 'hatchet lighting' in low-light or high-ambient-light conditions, which would give very dramatic shadows to close objects, which would enhance the edge-detection algorithm, and make detecting motion even easier for objects within about 15 feet. (You can also imagine military uses of this system; you could attach a back-facing camera to a special forces dude and put a piezo panel on his back, and he's got eyes in the back of his head.)

The other twist would be to add real-time optical character recognition and barcode reading to the system, so that every n frames you grab the scene and see if there are any words / codes that are recognizable, and if you so read them aloud to the wearer, while simultaneously vibrating the area in which you found the word / code. In this way, once a blind person found, say, a post at a street corner, she could look up it and have the street sign read to her. Or, if she were pawing through her cabinets, she could look at boxes and cans and have the items read to her.

I know real-time barcode reading is possible (because, uh, I invented it), I suspect real-time OCR is possible as well, given that we've had basic OCR forever.

--

I've been thinking about how to work towards teaching computers to "understand" languages, with the goal of creating a simple universal translator. (Simple!)

What I'd like to see is a system where we can translate sentences from any language into a neutral format, and then translate that neutral format into words in the target language, but NOT try to put them together into grammatically correct structures. This is why I call it a simple translator.

I don't think this is a particularly hard problem, really; I think it's mainly tedious, and I've been trying to think of how to divide up the work; possibly create a wiki or some other kind of public-supported site so we can build up a universal knowledge base once and for all, much like the wikipedia.

My thinking is: we need to assign a unique code (call it a number) to every concept in the entirety of our existence. (Simple!) For example, look at the sentence, "Mary had a little lamb." "Had" as in "owned" would be, say, concept number 23. But "had" can also mean "ate," which would be concept number 2,031. "Had", as in knew carnally, would be concept number 65,312.

So, the english word "had" would have a strong association with 23, and then weaker associations with 2,031 and 65,312. We might throw out the weaker associations if they aren't re-inforced by the associations found in the rest of the piece; there appears to be no more mention of Mary eating her lamb or loving it in a way that would make John Cornyn excited, so we can probably discount those associations.

We end up with a list of concepts for each word (or possibly phrase, in the case of idioms) in the source text. We can take it further by recognizing parts of speech, and building our little concept list into a tree, sixth-grade sentence-diagram style. (Eg, prepositions and clauses start their own little tree, and adjectives hang off of the nouns they modify.)

Now, what I'm curious about is just translating these raw trees into another language and then outputting them as trees, not as sentencces. That is, I don't want to create a grammatically correct English sentence from a Japanese one; I want to see how the Japanese sentence was structured. I am sure I could figure out its original meaning, and it would also be a fascinating learning experience. Also, it would introduce fewer translation errors into the equation to simply require people to learn the structure of other languages (which is pretty trivial, really, n'est-ce pas?).

The things we could do with a system like this are amazing. Imagine playing World of Warcraft and being able to talk to people from all over the world, in their language, automatically. Imagine hooking this up to iChat so that you could iChat with anyone in real-time.

But once you had this system, we could start working on teaching the computer to actually understand our speech, in limited amounts. We could teach the computer facts in its language (that is, the numbered concept language) instead of trying to teach them in some arbitrary human language. For instance, we could teach it that Granny Smith apples are red when ripe, and it would really know this. We'd have to be smart about associating concepts with each other; eg, the concept for "red" would have a link to its class, which would be the concept for "color". But once we did this, we could ask for the "color" of any object in the fact-base, and it'd work. In any language.

This is a huge undertaking, and I know that parts of this have been done before, but never on the right scale. The idea I'm playing with is how we can use the net to have people add concepts to the initial language database (leaving aside the knowledge base, which I see as a second step, after we have concepts in), and making something useful from that before we tackle associating the concepts which each other.

Ceci n'est-ce pas un pipe!

Labels: random ideas

Wednesday, November 9

The Impersistence of Vision

Ok, I had an idea the other day for software and an apparatus to help restore 'sight' to the blind. It is analogous to a device that I believe was described by John Varley in the short story collection "The Persistence of Vision," but has some modifications. The general idea is you hook a camera up to your head and have an n x n matrix of piezoelectric-driven rods strapped to your back or tummy that can poke you to convey information from the image. (Kind of like those toys you see in offices where there's two square pieces of black plastic with hundreds of tiny steel rods through them and a clear piece of plexiglass, and you make a 3D relief map of your face or hand with the rods.)

I've thought up some cool twists on this basic idea that I think could make it very useful. The idea itself doesn't require any science fiction any more; it is completely possible based on current technology. I've done a bit of research into what's currently available for the blind and everything I found was very paltry and crappy; I can't find links to current research being done. It seems pretty obvious (and apparently Varley thought of it long before it was practical), but is it being done?

I know that some of the students I had lunch with at WWDC this year were working in this general field, and I suspect some blog-readers may know a lot more about this than I.

My question for you is, do you know what state-of-the-art is for helping the completely blind form an image of the world around them? Obviously, I may have hit on an idea that others have already explored, and either discarded or already marketed. Also, it may be I'm trying to solve a problem that doesn't need a solution; maybe there isn't a lot of interest in conveying general environment images to the blind, and specialized devices (screen-readers, sonar obstacle finders) are more practical. I think I would want such a device if I lost my vision; I could easily imagine going out for walks with such a thing.

Also, does anyone know of an matrix of poking rods that's already been developed, regardless of whether it's been used for the blind? That is, something I could experiment with.

Labels: random ideas

Sunday, November 6

I invite you to wine.

In a few months, Apple's going to start selling machines with Intel chips in them. This isn't news, but I'd like to point out some things as we get closer.

Some things are easy to predict. For instance, graphics apps are going to be faster. There are a number of reasons for this; they tend to benefit more from x86's fast integer math, and they get a huge win from the write-combining on x86 that actually works.

Another prediction: we're going to triple our marketshare in the next two years. This is an easy one. We're already seeing an increase of marketshare from quarter-to-quarter, just based on how cool Mac OS X is and how many people are impressed with the iPod. When we can tell them, "Hey, you can install Windows on a partition and run your Windows apps as well," then, THEN, we're going to see a stampede. Everyone - EVERYONE - I've spoken to wants to run Mac OS X, but wants some particular Windows-only app that's holding them back. No more! Go forward, younglings, and frolic on a computer that doesn't hate you!

But what do I think the most interesting thing is going to be? WINE. Wine is a cool hack; some guys got together years ago and said, "Hey, wouldn't it be neat if we just rewrote all the Windows DLLs to the Windows specifications, so any program compiled against Windows could also run on Linux using our free DLLs?"

Yes, yes it would be cool. Of course, I don't want to run Linux, and Linux uses X-Windows, and I know X-Windows too well to want to ever go back. I want to run Wine on Mac OS X, so I can just launch any Windows game off the shelf and run it inside the Finder.

So, here's the call to arms, then, gentlemen and ladies. I am throwing down the glove, I am firing the starting pistol, I am painting the target, and I am pulling the flag from the cup.

You want to succeed as a programmer? Work on Wine. Get into it and kick butt. Maybe work on Darwine, which is the version being ported to Darwin already, but I honestly have reservations about that one, because their first emphasis is getting Wine to work with X11 on top of Darwin, eg, NOT the Mac OS X windowing system.

We can see the pieces here, folks. There's a ton of code in Wine that enables Windows applications to run, at full speed, without recompilation, on our new Macs. All that we need is the glue. We need for the graphics calls to call Quartz and the sound calls to call CoreAudio and the keyboard and mouse....

This is, essentially, like porting a game, something I've done several times. It's tedious and it requires a lot of knowledge about the depths of the system. But, here's the kicker.

This will be the last time we ever have to do it.

After this, we're done. We don't have to port games any more. Honestly, people, what's the difference between the Windows version of World of Warcraft and the Mac version? They both look the same to me, because THEY ARE FULL-SCREEN APPS. MOST GAMES ARE.

I DO NOT CARE what library my games are written using. I just want to play them. So does everyone else. And I don't want to wait from 9 months to two years to get slow ports of games that PC gamers are playing today.

When Wine for OS X comes out, it is going to be the end for Microsoft. The actual end.

Because nobody is going to want to pay for Microsoft's increasingly draconian licensing for Windows even as Window gets crappier and crappier. What's the average time from plugging in a Windows machine to it getting its first virus? 7 minutes? Windows has kinds of viruses Mac users have never even dreamed of.

THAT IS ALL GOING AWAY. When you can run Windows apps on Mac OS X, you'll still be protected by Mac OS X. Viruses are going to be dead. D-E-D. Ok, yes, there are certain kinds of pseudo-viruses (the kind where they trick dumb people into running them) that will still exist, but even those will NOT be able to infect the whole system, because even you don't have access to the whole system. The worst that'll happen is your personal account will get messed up, and you'll have to nuke it and create a new user. And then learn not to open mail messages that say, "Free PRON, just launch the executable!"

Now, some people say, "Well, if developers can just write to Windows and sell their software on the Macintosh, isn't that going to be the end of what makes the Macintosh so wonderful?"

No, no it won't. We're gonna get some really ugly Windows apps that some people need (like certain architecture programs, and Half-Life 2), but that doesn't mean our indigenous software is going away. If anything, it'll be enhanced. Windows users are going to see what good Mac software looks like, and they're going to start demanding Mac-specific alternatives to their favorite Windows apps. What's the most popular music player for Windows? iTunes. A Mac app.

Me, I relish the day when Visio comes to the Mac, inside Wine. Because then the whole Visio community will see how thoroughly OmniGraffle kicks Visio's copy-catting ass, up and down the block.

And, with the increase in market share, it's going to make more economic sense than ever to write Mac native apps, for all the reasons I gave before... Mac is on its way up, Windows is on its way down. If you're coming out with a new product, you want to be riding the crest, not circling the drain. Only extremely conservative users are going to be left running Windows, and that's going to be an incredibly hard market to sell into. Everyone who is interested in buying the latest thing is going to be running Mac OS X (and Wine for games).

So, that's the future. How does this affect you, you young, hungry programmer or documentation person or graphics guy, just looking to get noticed?

HELLO! WINE!

It needs to be finished. They've been working on it for 10 years, they've done most of the hard stuff. Now, you guys need to swoop in, make it run beautifully on Mac OS X, and grab your share of the glory.

I absolutely, 100% guarantee that Wine is going to be the shit-hot project over the next year and a half, and that the Wine engineers are going to be able to pick their jobs at Apple. Ask the KHTML team if you don't believe me. Or the iTunes team.

Wine is going to be getting press every single day after the Intel Macs ship. "Wine announces that DOOM 3 works..." "Wine announces that OpenGL works on nVidia cards..." "Wine announces that everything is 10% faster..." Every day, another press release, more fame, more excitement. Those guys are going to be rock stars.

Get on this project now. Get it headed in the right direction (dump X11, run under Finder / CoreGraphics). Get the glory. Get the job. Get the girl.

Labels: mac community

Thursday, November 3

Cat News, Site Redesign Contest Announced.

This morning, the word on the street (where the street is actually the foot of my bed) was that, sometime late last night, the cat food bowl ran almost empty.

This news was imparted to me with such urgency that I assumed it must have been meant for a much wider distribution, as if my fuzzy friends had used their super-keen senses to detect an imminent earthquake or another global-warming-induced hurricane.

It is well-known, of course, that cats can die to death from not eating for six hours. Or, in this case, from having to eat the kibble bits left on the bottom of the bowl, which is clearly less desirable, else why would it be left over? It was the kibble found wanting, and to have to eat it would be tantamount to death, at least.

--

Many people have complained to me that my blog is hard on their eyes, as if I were some sort of graphic designer and hadn't just picked one some default theme that I felt looked least like a blog by a 13-year-old girl.

Now, I finally intend to do something about. Well, I intend for you to do something about it. Thus, the enterprising person who spends a few moments creating me an elegant, understated, yet easy-to-read theme that I end up using will receive:

- My eternal gratitude.
- One (1) iPod Shuffle.
- Recognition on this site.

I know, I know, professional web designers make much more. But, I'm not looking for professionals. I'm looking for someone who is young and hungry and wants to impress. Let's remember what I said about how to get into the software industry (it's the same for the web industry): work your butt off for free, get your name out there, and then make the big bucks.

The winning theme will hopefully use dark text on a lighter background, will give me more horizontal space, and may incorporate more colors from nature. If you find a way to work in some of the themes on the Delicious Monster site, you get extra credit. (Those themes being the jungle, the merging of technology and art and nature, whimsy, organic design, stuff, and things.)

[Note that I reserve the right to decide I hate all entries and not award any prize. Life is tough that way.]

You have until November 15. Contest starts... now.

--

Update 11/8: I wasn't clear about how submission should work. What I'm looking for is a CSS template, like the one Blogger currently uses, except modified by you to be pretty. E-mail me your template, associated resources, and a snapshot of what the whole thing looks like.

Labels: stories