Thursday, June 16, 2005

M'man, Barry.

In high school I was fortunate enough to take classes under Barry Moser. Read this interview with him.

Sunday, June 12, 2005

Whither Classic?

Edit: I should have read Daring Fireball more closely. Classic is apparently dead in the water, according to both the Apple Universal Binary Guidelines and whatever sources JG has. Also, apologies to John Gruber for unintentially pilfering his blog's subtitle. I've changed mine to something interimish.

One serious implication for OS x86: Classic. Darwin's platform independent, and Rosetta is there to handle PPC code before handing it over to the Darwin/OS X API.

Classic involves 68K emulation, and up until now it's gotten a free ride because PPCs run 68K code faster than native. How's Classic going to work in Teh New Architecture?

Apple has three possibilities.
  1. Keep the compiled PPC emulation code in OS X as a legacy chunk, and let Rosetta translate PPC code emulating 68K code, praying we don't care about performance. Emulation inside translation; this is asking a lot of a system.
  2. Assume Apple licensed more than just an x86 translation library from Transitive, and OS x86's Classic mode uses direct 68K to x86 translation. Why shouldn't they? The challenge of emulating 68Ks is nowhere near the heavy lifting PPC emulation entails. Moreover, Classic under OS X is essentially two parts: CPU emulation and hooks to Carbon APIs. The Carbon APIs will still be there in OS x86, and until Apple gets their shit together enough to port the Finder to Cocoa, they don't have a choice. Yes, there'll be endianness issues, but at least they're consistently flipped.
  3. Apple tells everyone that five years of Classic support is long enough, and that their engineers canna poosh the warp core no moore, cap'n. Childhood's end.
I'll hope for #2. It would be a feather in Apple's cap to carry two OSes through the transition, and with the loss of 64-bit coding (for now) and AltiVec, jettisoning Classic seems like one more sad goodbye. Classic may be cruft, but it's an occasionally useful bit of cruft.

Sometimes, Steve, you gotta do something just because it's cool to be able to, and being able to sell potential switchers on a box that runs not just the last five years' worth of apps but the last ten or fifteen is damned sweet. No one much gives a damn how you do it.

Friday, June 10, 2005

Stage 5: Acceptance.

Bob Cringley just blew his street cred wad. While his perspective on Intel pulling Apple's strings in the future has merit, most of his assumptions don't wash. He's fortunate that so many people are spouting nonsense from all directions right now, that in the future he'll be able to say we were all frightened fools.

"Question 1: What happened to the PowerPC's supposed performance advantage over Intel?"
It's fucking moot if IBM won't develop it any faster or smaller while Intel does both. Three years from now, with 4GHz x86 Intel CPUs on the market, if Apple was still making 2.5GHz Macs and unable to even put those in laptops, sales would flatline.

IBM decided to play it safe on PPC development by throwing in with console gaming where (for now) form factor's irrelevant, chip heat's irrelevant, developers won't embarrass your platform for not advancing, and the public's demands are modest. And they'll succeed anyway, even if they lost a sizeable chunk of mainstream developers.

"Question 2: What happened to Apple's 64-bit operating system?"
Do your fucking homework, Cringely. OS X is largely 32-bit, and programmer guidelines repeatedly discouraged 64-bit dev, in some cases making it impossible (Objective-C won't compile 64-bit code under XCode).

"Question 3: Where the heck is AMD?"
You're SJ and you've just been corporately embarrassed for the third time in your company's history by a chipmaker's whims or lack of ability. Time to switch. Your choices are the following:
  • Blue chip industry leader with zero manufacturing problems and a drooling fascination with your company. Modest current product but secure pipeline.
  • Company with brilliant ideas but a lot less time in the business, a shaky record and a snarky CEO responsible for one of those embarrassing episodes.
Do the math, Einstein.

"Question 4: Why announce this chip swap a year before it will even begin for customers?"
Translated: "Osborne effect, Osborne effect, Osborne effect." First off, this announcement was at WWDC, not Macworld (where you debut product about to hit shelves). Even if they've busted ass for five years to make the transition easy, they have to tell the coders/manufacturers soon enough to iron out the bugs. There was no way in hell they could have been making these in secret for a year and then spring them on everyone Monday, and dropping the bomb simultaneous to releasing the product is suicide given the limitations of Rosetta.

Apple wants this box to sing, not oink, and that'll take reeducation camp for the remaining CodeWarrior developers who figured they'd never have to migrate to XCode. From Apple's perspective, CodeWarrior = Motorola, and the objective fact is that CW's backed off from both Win/Mac development in favor of embedded systems.

That said, IMO a six month window would have been a smarter compromise; more pressure on small developers, with the implicit assumption that migration isn't all that hard. Given the rumors of how little modding it took Apple to make a G5 box into a Pentium box, it may not take twelve months to retool and go to market.

"Question 5: Is this all really about Digital Rights Management?"
No. Pull your head out of your ass. Apple has much better inside relations with the recording/film industry than Microsoft, and in case you forgot, SJ runs a business which is directly part of the film industry. If the industry demanded that the next gen movie format require a hardware chip to encode and another to decode, there'd be no reason or advantage to make it CPU dependent -- in fact, doing so would make it easier to reverse engineer by crackers, DMCA be damned.

Cringely goes on to say that Intel hates Microsoft. The only thing Intel hates is not having money, and Microsoft can't exactly turn the screws on Intel beyond ensuring that one particular line of processors continues to generate obscene revenues for Intel.

Cringely hints that HP could become Apple's "hardware partner." This one's been pulled out of the woodwork for close to a decade, on par with Tandy becoming Apple's OEM. Somehow I don't see the Taiwanese who make Macs giving much of a damn which yellow haired devils are paying their $2/hour wages, or Apple deriving a particular benefit from this partnership. It's debatable what Apple and HP view as the benefit of selling branded iPods, beyond HP's distribution network (why you can buy iPods at Radio Shack).

Intel has enough money to buy Microsoft, never mind Apple. Antitrust legislation is what keeps them out of the OS market, not missed opportunities or alliances. That doesn't mean they can't milk their relationship with Apple "in Apple's best interest," of course, and it's something SJ expects them to do.

Expect to see Intel pressuring Apple to come out with smaller and smaller devices, and continually providing the hardware to make it possible. You're laughing now, but right now there are $130 battery-powered Linux-based x86 computers on cards small enough to fit inside an iPod Shuffle (or close enough).

Jobs was right, if hurried, about ditching the Newton. Palm did an excellent job stewarding the only platform you can't replace with Linux, but after 10+ years the Palm economy is hurting as it becomes further and further removed from general purpose OSes going into smaller and smaller places. OS development there has stagnated considerably, with nothing new to show each year except more expensive models losing ground to laptops. Palm's splitting its own product line into thirds: disposable contacts managers for students, phones for salesmen, and ur-laptops price competitive with nothing.

Prediction's a fool's game. What I will say is that Jobs saw the trend away from desktops and toward laptops, understood IBM wasn't interested in making that possible for Apple, and Jobs took the only road he could to stay in the game.

If you visualize a 7x10 tablet Mac with a wireless keyboard, a cover that hinges back into an easel for QuickTime 7 theatre DVD playback or Grand Theft Auto pimpin', a more visual jukebox interface for iTunes, and a considerably less junked up Finder, that's your business.

Me, I have a more specific vision of the next WWDC surprise, but I can't say. Too early.

Wednesday, June 08, 2005

More like twenty steps backward.

Mac card vendor finds indications x86 Macs likely to use BIOS rather than EFI.

Fuck.

Mac controller card vendor George Rath isn't spelling out his argument clearly enough, so I will. Disclaimer: I'm not a developer, I'm just putting two and two together.

So far Apple's being real tight-lipped on what firmware the x86 Macs will use. Try googling 'BIOS' site:apple.com and after you've sifted through tons of Biography pages, what you'll mostly find is ancient articles referring to the difference between PowerMac and Intel architecture. Google 'EFI' site:apple.com and you'll get references to a color proofing system that uses the same acronym, and a handful of references to OpenDarwin libraries for Extensible Firmware Interface. Good, right?

Wrong. For one thing if you google 'extensible firmware' site:apple.com you get zero hits. Nada. Zilch.

Where the shit hits the fan is here. I'll skip repeating the part in the Apple Universal Binary Specifications which baldly states x86 Macs aren't using Open Firmware (but avoids saying what they are using):

Apple Univ. Binary Tips Ch. 5, Section 7 - "Disk Partitions"

"The partition format of the disk on a Macintosh using an Intel microprocessor differs from that using a PowerPC microprocessor. If your application depends on the partitioning details of the disk, it may not behave as expected. Partitioning details can affect tools that examine the hard disk at a low level."
Let's compare this with Amit Singh's older article explaining the difference between OF and BIOS for kernelthread.com, More Power to Firmware (emphasis mine):
The PC partitioning scheme is tied to the BIOS, and is rather inadequate, particularly when it comes to multibooting, or having a large number of partitions. PC partitions may be primary, extended, or logical, with at most 4 primary partitions allowed on a disk. The first (512-byte) sector of a PC disk, the Master Boot Record (MBR), has its 512 bytes divided as follows: 446 bytes for bootstrap code, 64 bytes for four partition table entries of 16 bytes each, and 2 bytes for a signature. Thus, the size of a PC partition table is rather limited, hence the limit on the number of primary partitions. However, one of the primary partitions may be an extended partition, and an arbitrary number of logical partitions could be defined within it. Note that Apple's partitioning scheme is much better in this regard.
Or rather, it used to be. About the only sunny side to this is Intel's EFI specification (PDF) which indirectly mentions backwards compatibility to "PC-AT" partitioning schemes.

We're left with the following possibilities.

Hopeful: Rushes have led to developer boxes using BIOS, but consumer Macs will use EFI.
Taking a long view: Developer boxes are using EFI but even EFI's advances still require Apple to spell out non-OF partitioning differences.
Pessimistic: Developer boxes are using BIOS, consumer boxes are using BIOS and ultimately we're fucked.

To some extent the die's already cast. A PPC Mac is two things at the same time: GUI Unix and hot iron. An x86 Mac is a pretty OS in a sea of pretty x86 OSes struggling with legacy hardware issues -- except for the other two, most of their apps aren't also spending the next 2 years running at 70% under software emulation. Longhorn can afford to hamstring its performance until IA64 is the norm. Linux sells itself on local compiles and generous variety of readymade builds.

Tuesday, June 07, 2005

Shiny epaulets.

After careful lobbying on my part, I have been reclassed from Library Specialist to Applications Systems Analyst. The former is a general description which could apply to virtually any clerical/paraprofessional in the building, and in five years I haven't learned dick about librarianship or for that matter worked close to librarians outside of the web development team. As one of my co-workers introduced me to a new hire and tried to explain to her what I did compared to what Brian does, I said, "Brian writes the music, I create the instruments we play it on." Seems pretty accurate to me. After several years doing graphic design, I'm continually surprised with Brian's aptitude with no formal experience or training.

And yes, it comes with a raise, which is good since Ruth plans to stay at home with Maryalee this year. In late 2002, we moved out of the apartment into a house, and this spring we refinanced. No mean feat; my piss turned to ice when I read this week that over 1 in every 3 Arizona mortgages are now interest-only (in 2000 that figure was closer to 1 in 100). FWIW there are apartments in Flagstaff whose rent is higher than our refi'd mortgage payment. It's obscene. Literally, morally obscene.

My duties won't really be changing; what I've been doing for the last few years has fit the new job description better, and it's not arrogant to ask for formal recognition. As in previous jobs, I've piloted innovations and improvements in this position which have benefited everyone and made less work for us down the road. I am fortunate to work with people who appreciate it; I know people who have improved their skills only in spite of being treated badly at work, but they only do so with an eye on their next job elsewhere. Tacked on the corkboard behind my monitor at work is a worn, folded, hand-told half sheet of LaserWriter paper from 1992, handed to me with a job offer for a graphic designer/resume writer position (mentioned in this blog's first entry). 13 years later, I keep that printout as a pointed reminder; in good times it reminds me of how far I've gone. In bad times it reminds me how much tougher things were at one point, and that I survived.

Web standards have come a long way since I started working at Cline Library, and I've striven to adhere to them and maintain browser compatibility, when management would have let me get away with coding the site for IE, with table-based layouts and JavaScript widgets everywhere. Paradoxically as I continue doing my work better, the result gets more and more invisible to the end user. Random content like images used to be hand-coded JavaScripts inlined on the pages, then was refined and externalized and finally replaced altogether with server-side includes harvesting Perl CGIs. Even image-based rollover links are now possible with CSS rather than JavaScript, due to a technique I haven't yet seen elsewhere. The programming component of the job is still there, but it's become a lot subtler.

A current (and ongoing) frustration is with accessibility. My chief motivation for abandoning table based layouts is the amount of extra work it takes to make a complex table layout render in a logical fashion by screen readers. Check out our website in a screen reader or Lynx or a web phone -- it just works. To CSS unaware browsers, the content renders first and the navigation last. It's a common solution now; it wasn't when I suggested it to CSS-discuss 3 years ago.

And yet, screen readers are still hideously primitive. JAWS still refuses to honor the only HTML tag specifically aimed at it, to prevent it from importing screen-only stylesheets, and limits you to using IE. Apple's VoiceOver only works with Safari, and gives every impression of being rushed to market. Opera's reader doesn't automatically read pages when they load, and Opera's designers sincerely believe we're going to return to designing separate XML-based pages requiring a different extension and MIMEtype, only to serve one browser for one platform. All three largely ignore label tags when encountering forms. Despite the label tag being designed as a wrapper for form elements, WAI insists on labels being outside those elements and declared with FOR=ID, and prebuilt sample text in all fields.

The simpler we try to make things for ourselves, the more complex they get. A simple CSS pseudo-selector, :hover, which by W3C spec should be available to all elements, is only available to A links in IE. This limitation is what's kept CSS/unordered list-only dropdown menus off web pages for the last 3 years. A German developer discovered an elegant HTC-based solution which essentially rewrites IE's own handler code to behave according to spec. No alteration of your existing CSS, except for a line of non-spec code all non-IE browsers will ignore.

But if the stylesheet loading the behavior is on a different server than the page requiring it, IE refuses to load the behavior for security reasons -- even though both servers are within the same domain and Microsoft's own documentation is clear that the security restriction is supposed to only apply between domains. After some guessing I found a line of JavaScript which relaxes this restriction.

My predecessor was three times the graphic designer I am. But I think faced with the same problem, he would have stuck with a 3 year old, accessibility unfriendly, 30K noncacheable DHTML solution.

We're doing a retread of the site soon. It won't have the same technical hurdle the prior retread had; abandoning tables, developing CSS layouts, migrating boilerplate to SSI includes... But it refines the prior commitment to CSS and accessibility, with a more hierarchical, centralized and flexible stylesheet, and exploits fluid layouts not possible with IE 5.0 (the leading version during the prior retread). All visible telephone and fax numbers are silently becoming tel: and fax: links, restyled for screen browsers to look like plain text. Anyone browsing with phones now will see the links; selecting them will dial the numbers. We're also making some tougher decisions about graceful degradation across all browsers as Netscape 4 becomes a distant memory and IE 5.0 is nearly unheard of; I detest CSS hacks and those which exploit parser bugs especially. Older online exhibits for Special Collections and Archives are being duplicated and the offline versions converted to CSS and checked against the originals.

Monday, June 06, 2005

Apple: The Road Ahead

Christ almighty. Keynote speech is over, and the worst has been confirmed. PPC is effectively dead and Marklar is the future of the Mac platform. Tiger demoed on a stock x86, not a word about proprietary hardware.

Apple's and Intel's press release pages are glowing. I don't think my brother who just bought a Powerbook is going to be glowing. The $2500 I sunk 18 months ago into a dual G5 isn't leaving me glowing. I can't imagine the salesfloor staff at Apple stores are cheering, either. Even with a 2 year transition period and all the promises in the world that apps will ship with fat binaries, I can't see PPC Mac sales remaining positive before the Intel boxes are shipping.

Here's what I can't understand.

Apple's entire business model is selling turnkey systems. Computers you don't need to be smart to use, music players an idiot could load and play. Note the emphasis on nouns referring to hardware, hardware that doesn't have clones. In other words, you want the Apple experience, you have to buy the Apple hardware to run it on. And Apple turns a tidy profit selling that hardware, and effectively killed the clone market when it started to dilute their sales.

So, if Leopard is going to run on generic x86 hardware, how does Apple make money when their OS can run on Joe Schmuck's Alienware box and Joe's busy getting Leopard off P2P? Apple's only current software revenue stream is OS upgrades and niche video editing software.

Presumably Intel's recent news about chip level DRM could make it impossible to pirate Longhorn/Leopard, but I don't know.

Second thing: this is putting Apple's feet to the fire on the matter of whether OS X is actually more secure than Windows. Now that OS X will run on stock x86es, how many existing x86 virii will be retooled slightly for it? Is the gamble that virus authors won't bother trying to crack a niche OS, and by the time that its market share is significant enough to be attractive, the OS will be so robust as to make the prospect daunting?

Nothing makes sense any more.

By predicting the future based on what's reasonable, I seem to consistently alter it for the worse. So, here's my "bad rice" prediction.

To Apple's dismay, the mainstream media will not trumpet this as a Good Thing. The blogosphere will be filled with hate, fear and confusion, and the mocking laughter of Apple-bashers. Angry, embittered Mac loyalists will divide between flocking to Windows and Linux, where their financial investments are minimal.

Without any regulation from Republicans in Washington, Microsoft will continue patenting everything and start using the courts to effectively destroy open source. Our future trade agreements with the EU will not-so-thinly imply that not following suit will be considered an act of war. Linux will disappear outside of China.

Within five years Steve Jobs will get on stage and wax about Apple's bright future, right before Bill Gates walks out of the curtains and they jointly tell us MS bought them out, but not to worry, "we have a firm commitment to the future of OS X." Within another twelve months MS management decisions will convince Apple developers to jump ship, and MS stockholders will snuff Apple.

Overnight, Microsoft will "purchase" System V UNIX from their holding company SCO. Congress will pass murkily-worded IP legislation further putting the nails in the coffins of non-commercial licenses, and Microsoft will exploit it to effectively criminalize the existence of FreeBSD, and most likely extort a promise from OpenOffice that it no longer read or write Microsoft formats. The EFF will bankrupt itself trying to defend cases like these; the few that make it to SCOTUS will see Bush appointees ruling solidly in favor of the ownership society.

With naysayers telling us that it couldn't happen, everything will become a monoculture: processors, formats, OS. Windows will transition to a POSIX infrastructure, but they'll have free rein to bastardize its compliance beyond recognition.

This is supposed to be my 12th wedding anniversary. I feel utterly fucked.

Wednesday, June 01, 2005

Open Letter To Dreamweaver Development Team

As a general rule I think Dreamweaver rules. I've been using it since 3.0 and it's still the best Win/Mac site development tool there is. It won't arbitrarily rewrite your code like Netscape Composer/Nvu or FrontPage, and it doesn't default to creating browser-centric code like FP. Its JavaScript based framework (preceding Firefox's conception by years) has allowed many useful extensions to be added (disclaimer: I wrote some rather modest extensions myself). They worked most of the kinks out of the FTP problems.

It still hits the brick wall on one issue. Site-root-relative URLs. URLs typically fall into three types:
  1. Absolute
    <img src="http://www.nau.edu/library/images/doggy.png" />
    Upside: Excellent for guaranteeing stable links; can be used everywhere in your site.
    Downfall: Dependent on you never changing your domain. DW's Display View won't resolve them and shows you broken image links (or in the case of stylesheets, they aren't applied).
  2. Document-relative
    <img src="../images/doggy.png" />
    Upside: short, easy for DW to understand and display correctly in DV. Portable if you change a site's server/domain.
    Downfall: unless you only move pages inside DW's own file manager these links break.
  3. Site-root-relative
    <img src="/library/images/doggy.png" />
    Upside: all the stability of absolute links, with document-relative's domain agnosticism.
    Downfall: DW is incredibly stupid about resolving these in Display View because it considers that URL to be relative to the top of your local site root instead of resolving it relative to server.domain.tld like every browser on the planet since the beginning of the internet.
Macromedia's aware of the problem. Or rather, they're not aware of it as a problem, suggesting you maintain a local directory structure parallel to the entire server you're working with, and going so far as to say only massive content aggregators like ESPN truly need site-root-relative URLs.

In a campus environment we're a lot less likely to use a local/remote FTP model for site management and a lot more likely to map the servers to local drives.

My personal space on the campus staff server is /webhome/ar24/public_html/ which equates to http://www2.nau.edu/~ar24. I have privs to map my public_html to a drive, G:\

[No sysadmin in their right mind would give me privs to map /webhome/ directly, and even if they did, every time I opened DW's Files tab it would slow down to a crawl trying to refresh its internal listing.]

I create a site in DW using G:\clockwork\ as the Local Root Folder and http://www2.nau.edu/~ar24/clockwork/ as its HTTP address just as I should. Inside my site are the following:

http://www2.nau.edu/~ar24/clockwork/pages/yarbles.html
http://www2.nau.edu/~ar24/clockwork/images/alex.gif
http://www2.nau.edu/~ar24/clockwork/moloko.css


yarbles.html links to the stylesheet at src="/moloko.css" and has an image link where src="/~ar24/clockwork/images/alex.gif".

In Display View, the stylesheet will be applied but the image comes through as a broken link. When I view the page in a browser using http://www2.nau.edu/~ar24/clockwork/pages/yarbles.html the exact opposite happens; the image comes through but the stylesheet is not applied. Why?

Because DW's Display View pseudo-browser renderer only understands your local site topology.

It doesn't see a ~ar24 directory below G:\ so it assumes the URL is incorrect. It does see a moloko.css at the "root" of G:\ so it wrongly imports the stylesheet.

Second real-world example: the Cline Library website at http://www.nau.edu/library. In reality www.nau.edu is on one server (mutt) and www.nau.edu/library is on another (jeff), where /library redirects to jeff's root-level /public_html. This is far more common than you might think.

In this case we've mapped jeff's entire root to a local drive H:\ and created the DW site at H:\public_html\, being sure to define http://www.nau.edu/library/ as the site URL. However, remember that valid SSR URLs must start with /library/ because the server delivering the pages is still using this bit of redirection.

So, a page with a correct SSR link to an image at /library/images/logo.png will fail in Design View because H:\ doesn't have a /library. An incorrect link to /images/logo.png will show the image in Design View but fail in the real world.

In both cases DW's Design View fails because it can't conceive of a site root corresponding to anything except a URL directory coming immediately after the domain name. And strictly speaking, it doesn't have enough information to reliably make that call.

All it would require of DW to correctly resolve SSR URLs is one more site definition field: the relative SSR URL equivalent to the local root folder. Prototype below:



Note to engineers: I'm aware that this means parsing work for "Preview in Browser," since PiB serves file: rather than http: tempfiles to browsers, and SRR URLs are unreliable inside file:-browsed pages. However, the above dialog gives DW everything it needs to replace SRR URLs with relative URLs in the tempfile. Considering that PiB routinely simulates server behaviors by inserting/substituting content, this isn't exactly asking you to forge new territory.

I respect completely that DW gives a lot of support to relative linking, e.g. moving files around in the File browser automatically updating those links. I also think this functionality is being used as a crutch to avoid implementing a standard many web developers have asked for, and whether or not Macromedia likes it, the future of content management includes pages being moved around, independently of Dreamweaver.

More importantly, if a site has a clear definition of the relationship between URL and local site root, there aren't any more excuses why resources inside the site root linked to with an absolute URL cannot display in Design View. This is string comparison, not DNS resolution, and a 7 year old product should be expected to understand it.