Solipsism Gradient

Adam Knight the codepoet, whom I link to quite often from here, has an article out on Mac Geekery, ominously called “How a Malformed Installer Package Can Crack Mac OS X“:

There exists a pretty significant interface problem with the Apple Installer program such that any package requesting admin access via the AdminAuthorization key, when run in an admin user account, is given full root-level access without providing the user with a password prompt during the install. This is even explained in Apple’s Installer documentation as proper behavior. The distinction between the AdminAuthorization and RootAuthorization keys is, simply, whether or not the admin user is prompted for a password; the end powers are exactly the same and it is up to the creator of the package as to if he will be kind enough to ask for a password…

Well, at first glance this looks like a pretty serious security hole. Let’s see what that Apple documentation says about this:

This is actually quite clear. If the installer package asks for the same level of privileges that the logged-in user already has, authorization is not required; meaning, it won’t ask for a password. Which makes sense; after all, to log in as root or as an administrator you must know the root or an administrator’s password to start with – usually. If the packages needs higher privileges to do its stuff, the user will be “prompted for authorization”. This autorization will be used for two purposes: setting permissions on the installed files, and for running pre- and post-installation scripts. We’re concerned only about the second purpose. Before going into that, let me explain a few things.

First of all, using an installer package is pretty much, nowadays, a good thing only when you’re installing something that messes with the system’s folders, or that executes scripts that do restricted things. Installing a kernel extension, updating the system frameworks, setting up servers and startup/login items are common examples. It’s frightfully infra-dig to make a package just to install your application in /Applications. In other words, just the presence of an installer package on a disk image should be pretty much an indication that something uncommon will happen if you double-click it.

So, the common perception is that for an installer package to mess with the restricted system folders is that it should ask for root authorization, and therefore you’ll be asked for a password – since you’re not running as root to begin with. Or shouldn’t be; the root account comes disabled by default on Mac OS X. And since most packages do it this way, this perception is reinforced; it’s become pretty much automatic to double-click on a package, type in your administrator password at the prompt, and “boom” (can’t remember who says that ).

So Adam strongly recommends:

Run as a normal user. Open files you trust. Stick to that and you’ll be fine.

Read his recommendations and follow at least some of them. I’d add: use Charles Srstka’s excellent Pacifist software to see what’s being installed, and where, before running the Installer – for one, Pacifist doesn’t run pre- and post-installation scripts contained in the package, so it’s not an Installer replacement.

The tricky part comes when the package asks for admin authorization. Mac OS X installs the first user as an administrator, and it’s required to have an administrator account present – after all, if you had none, the system would become quite unmodifiable. So, the recommended practice is to set up your system in this first account, then set up a second non-admin user account and use this for your normal activities; switch back to the admin account only when installing software.

Unfortunately, Apple seems to have found this confusing for “normal” users, and I’d tend to agree. A significant amount of explanation would have to be inserted into the setup application, especially as this not-normally-used “user” would also have a home folder where stuff would not be visible by the day-to-day user. There’s even the option of setting the machine to boot automatically into a certain user, and I’d say many non-technical users click this to speed up booting and to avoid having to remember their password every day. Unfortunately, as a side-effect of these circumstances, most users are running as an administrator without having had to type in the administrator password at all.

Now let’s suppose you get a (underhandedly malicious) installer package and double-click on it without examining its contents beforehand. You think it can’t mess up much as it will ask for a password if it does anything serious, right?

Wrong. True, it will ask for a password if it wants root authorization – but then, you’re already conditioned to type in your password anyway. But if it asks for admin authorization and you’re already running as an admin, it won’t ask for a password at all, and merrily use the admin authorization you gave it (by logging in!) to muck about with your system.

Now wait a minute. Why does this admin authorization which is not root authorization let the installer run scripts as root, as Adam proved by a test package? Isn’t that a serious bug and security hole, as he claims?

Well, yes and no. The answer lies in a file called /etc/authorization. This is an XML file in property list format which defines the various rights a process can ask for when using the Authorization Framework, and defines a set of rules that are applied when this happens. The principles involved are quite complex, and I’m still learning to understand them fully. Here’s a paragraph from that documentation:

When a user who is a member of the admin group logs on to the system, for example, the user’s credential (that is, the fact that they have entered a valid admin user name and password) is saved in the global credentials cache. Then when this user attempts to modify a system preference, Security Server finds the credential in the cache and does not display an authentication dialog.

which confirms what I said above. And later on:

Not all installers require authorization – only those that need special privileges to copy files to restricted directories, make changes to restricted files, or set setuid bits.

An installer is a special case because unlike other applications, an installer is usually run only once. Due to the limited use, Authorization Services provides a function to invoke your installer to run with root privileges. It is up to the user to determine if the installer is from a trusted source.

So far so good; but why in, practice, do admin privileges mean “run as root”? Well, in that XML file we have the following section:

      <key>system.privilege.admin</key>
      <dict>
         <key>allow-root</key>
         <true/>
         ...
         <key>group</key>
         <string>admin</string>
         <key>shared</key>
         <false/>
         <key>timeout</key>
         <integer>300</integer>
      </dict>

Translating this into a slightly less geeky form, this is the autorization right requested by the AuthorizationExecuteWithPrivileges() call, which is the one used by the Installer. It can be granted to users of the “admin” group, is granted automatically to the root user, and times out in 5 minutes. AuthorizationExecuteWithPrivileges(), in turn, is the system call to run a script as root; which is allowed for administrators, as we’ve seen.

In other words, everything is certainly “behaving as expected”; it’s not a bug, it’s a mistaken assumption: “anything that runs as root will ask for authentication when run by an admin user”. That’s certainly not true. However, I don’t deny that the Installer could be more explicit here, either not calling AuthorizationExecuteWithPrivileges() for its scripts when admin authorization is asked for (which might break some existing packages), or by showing a separate alert at the beginning, saying “this package will run its scripts as root”. Let’s suggest this to Apple and see what happens…

I just found a very nice and interesting gallery of disk images. I decided against using disk images early on when I found that, more often than not, some local setting of the user’s Finder would make the icons move around, usually confusing less experienced users.

But these look so nice, I may change my mind now; I wonder if it might be worth it to file a bug suggesting that icons on locked disk images should snap back into their positions.

Many thanks to Jim Matthews of Fetch Softworks for remembering that I had the original idea of putting a symbolic link to /Applications on the disk image. I now see that most people are simply putting in a Finder alias instead of a symlink… I’m not so sure this is a good idea. It works quite well in Tiger, but it will store your boot disk name at the very least, and perhaps even break if the user has a secondary volume which has that same name.

The codepoet has got right what I wanted to say about the iTunes 7 interface:

I do like how it looks as a finished product, but it doesn’t make me feel like I’m using a Mac at all. It looks like the new iTunes Store does, right down to the scroll bars and buttons.

The only reason for this that I can put forth is that they needed one unified interface for both Mac, Windows, and the iTS and we thus have this new concept. It’s interesting, and it’s not entirely unusable, but it’s kind of annoying to have this iconic Mac application turned into a bastion of wishy-washy cross-platform interface design, from a place of pure principle.

So, they tried to make something both Mac OS X-like and Windows XP-like, and at the same time abstract it out into a distinct iTS look. Which in turn was probably inspired by Dashboard widgets. If so, they’ve pulled it off quite well. At least in the main window; preferences and popup menus use the native UI, I suppose because users might get (more) confused.

On the other hand, this means that the new UI should not be used as a guide or inspiration for other applications. Or websites for that matter; I imagine Apple’s lawyers will be very zealous in their defense of the iTS theme/platform’s look & feel.

I just realized iTunes is slowly morphing out of being just another application; instead it’s becoming an emulator running the iTunes/Store platform. Inside a window, just like Virtual PC or Parallels. Interesting. (This paragraph actually surprised me while I watched myself typing it out .) I wonder if other hybrid desktop/web multiplatform apps will follow this course… not that I can think of any right now, hm.

Things seem to be moving along well. Here are some random observations.

As I thought, Time Machine is starting to prompt manufacturers to begin offering affordable RAID backup systems. First out there was the D-Link DNS-323, which has 2 SATA drives and a gigabit network interface, and now there’s the Iomega UltraMax (no URL yet), 2 SATA drives and USB/Firewire interface. At WWDC I actually looked for such a product but couldn’t find anything suitable; they were all too large, too expensive or both. Time Machine without RAID means putting all your backups into one basket, so expect lots of better and less expensive backup drives to show up before or at next MacWorld Expo in January 2007.

The 64-bit iMacs are just out, as well as speed-bumped Mac minis. The timing on this is significant. There’s the mysterious “showtime” event announced for Sept.12, the initial day of Apple Expo Paris – and also the final day of IBC Amsterdam, the “content creation” conference. On the end of the month Apple will be present at Photokina. Of course this means that the upgrade are not significant enough to be presented at these events; rumors are flying about what media-related products will be announced. I suppose that movie sales over the iTunes Music Store is pretty much a given, although that’d a pretty unexciting, US-centric, thing by itself.

I suppose that the putative iPhone might be counted under “media”, as everybody seems to expect a phone-capable iPod instead of a music-capable cellphone under that name. While I’m a happy owner of a 3rd-gen iPod – by coincidence bought in Paris shortly after Steve Job’s last Apple Expo keynote 3 years ago – I can’t see why I would want a cellphone built into it. Or a PDA; I bought the original Palm Pilot when it came out and couldn’t get used to that either.

Should Apple bring out a product that might be classified as a “phone”, as a stockholder I seriously hope it’s not a me-too cellphone/music player/PDA. Just look at the restrictions that have so far hampered world-wide deployment of the iTMS. Combine that with the hundreds of technical and regulatory circumstances that govern cellphones in the various countries, and it’s a recipe for disaster; just check out what happened to that Motorola/Apple phone. So, hopefully, Apple will bring out something pioneering and generally usable – perhaps involving new wireless and VoIP technologies.

The iMac announcement also has deeper meaning. With the new 64-bit chips supposedly running faster at the same price point, it’s mostly a question of chip availability to convert all the line. I seriously expect all Macs to be 64-bit capable in January. Converting the iMacs at this time also means that more developers will have extra time to port their apps, if necessary. When Leopard comes out sometime between January and March a surprising number of applications will be ready for it.

Update: Apple has patented a “multi-functional hand-held device” that purports to:

… include two or more of the following device functionalities: PDA, cell phone, music player, video player, game player, digital camera, handtop, Internet terminal [and/or] GPS or remote control.

The patent covers:

Touch Screen, Touch Sensitive Housing, Display Actuator, Multi-Functionality, Form Factor, One-Handed vs. Two-Handed Operation, Footprint/Size, Full Screen Display, Limited Number of Mechanical Actuators, Adaptability, GUI Based on Functionality, Switching Between Devices (GUI), Operating at Least Two Functionalities Simultaneously, Configurable GUI (User Preferences), Input Devices, Pressure or Force Sensing Devices, Force Sensitive Housing, Motion Actuated Input Device, Mechanical Actuators, Microphone, Image Sensor, Touch Gestures, 3-D Spatial Gestures, Perform Action Based on Multiple Inputs, Differentiating Between Light and Hard Touches, Example of a New Touch Vocabulary, Speaker, Audio/Tactile Feedback Devices, Communication Devices (wired & wireless) and Change UI Based on Received Communication Signals.

…all that’s missing is a biological signal sensor and a recreational pharmaceutical dispensing device, to make this the functional equivalent of the “Joymaker” Frederik Pohl wrote about in his 1965 book The Age of the Pussyfoot. I wonder if that counts as “prior art”…?

WWDC 2006 had two main topics: the new Mac Pros and Leopard. Regarding the Mac Pros, they seem quite competitive and well-built. I’m very content with my current iMac G5 (which I bought at last year’s WWDC), so I haven’t looked at them closely; desk space is important to me. By the way, it seems that Apple Brazil has just released the local price of the standard configuration, and it comes out to US$5400. Ouch.

Regarding Leopard, there’s a nice write-up at Wikipedia, so I won’t try to enumerate everything here.

All in all, I can say this was one of my best WWDCs yet. As I’ve said before, the timing was excellent. Apple has obviously made the most of the (unusual) June-to-August delay and from the developer standpoint all important stuff was in place. Most of the Leopard APIs seem to be well-defined, reasonably stable, and of course the tools are all in place. Xcode 3.0 and the new developer tools “just work”. In one Q&A session Chris Espinosa, was asked about the stability of the tools – whether developers should rely on them for new products, or should wait for the GM release – answered “we all use them daily for building Leopard, so they have to work well!”

So, this is important news for developers. Before, existing tools were used to build a new system and the next generation of tools came out with (or after) the GM release. Now, Apple has obviously been working on the new stuff iteratively; first versions of the new frameworks were used to build first versions of the new tools, then those were in turn re-used to work on the new frameworks. Certainly this has always happened to some extent, but I believe that this synergy between tools and frameworks has now hit an important inflection point.

Apple has clearly been working towards this for years. Mac OS X ‘s frameworks are now 4-way universal, containing binaries for PowerPC 32, PowerPC 64, Intel 32 and Intel 64 bits. Therefore, applications can now be built for all 4 environments, and all are fully supported by the new developer tools. This is a well-known capability of the Mach-O executable format by the way, not a new thing; NeXT applications were also distributed for several architectures, and the Virtual PC 7 executable has binaries optimized for 5 (!) different PowerPC variants.

Framework synergy is a marvelous thing. Apple has just released a short movie showing off CoreAnimation. The “city towers” effect in the second half can be now rendered in realtime on a MacPro – something that even two years ago would have been impossible. Looking very closely you can see that some of those squares are actually playing movies! But only a developer can fully appreciate the other important aspect: the code to generate this movie has shrunk down to less than 10% of what would have been necessary in Tiger.

Let’s talk somewhat vaguely (NDA mumble mumble) about how synergy might have made this happen in the CoreAnimation case. The MacPro has a faster, 64-bit CPU architecture, as well as faster video cards. 64-bit processes can use extra CPU registers and the new vector operations which seem to, finally, have equivalent power to the PowerPC G5’s AltiVec. The LLVM compiler is now used in the OpenGL stack to add a significant speedup (and this even for low-end machines!). Add in Quartz optimizations. Add in easy Cocoa support for all of these. Add in runtime efficiences introduced by Objective C 2.0. Add in new debugging and optimization made possible by implementing DTrace. Add in the ease of programming all this with less and more reliable code. Add in some extra stuff I can’t talk about… it adds up! And comparable gains are visible all through the new system.

At the risk of repeating myself, all this ho-hum talk about Leopard just being Spaces, Time Machine and some UI tweaks to iChat and Mail is so wrong. Granted that Steve Jobs had to show some non-developer news at the keynote, given the wildly unrealistic expectations. But, it really was a Developer Preview. It was released at the right time and to the right people in order to make sure that, whenever the Leopard GM comes out (my guess would be in January at MacWorld Expo), some hundred cool new applications will be available on the same day. And they’ll necessarily be Leopard-only; expect Leopard to be adopted by a significant portion of the user base in a very short timeframe.

Now to my own projects. I’d really love to have the upcoming XRay II to be Leopard-only, but that would delay release too much, and it doesn’t really need 64-bit capabilities. However, I’ll really need some fixes introduced in the last Tiger updates, so 10.4.7 will be the minimum supported version, which should be no hardship, as I can’t imagine anyone voluntarily staying with older Tiger versions. However, some of the stuff I’ve seen at WWDC has completely changed my plans regarding certain features and capabilities, so I’ll opt for implementing things in a way that might be a little constrained under Tiger but will really be much better under Leopard.

RBSplitView has been a marvelous experience for me. It’s been very widely adopted and even the Cocoa team has promised to take a look at it (no promises, of course). And it was very gratifying to be instantly recognized by many famous developers – of course my XRay II/RBSplitView t-shirt was intended to make this very easy! I’ve received lots of positive feedback and I’m working hard on implementing my own fixes and all suggestions. Hopefully I’ll have version 1.1.4 out in a very short time. This should be universal and fully compatible with Xcode 2.4. A 64-bit version compatible with the new Interface Builder will, unfortunately, have to wait until a more widely available Leopard beta comes out – I’m waiting for word from Apple about when it’ll be kosher, as I’ll necessarily have to include some new Leopard headers and APIs.

I have updated Nudge to be universal, and it seems to still be useful on Tiger for mounted network volumes. Expect the update to be available in a few days – I’m still doing some last-minute checking. Zingg! is, unfortunately, much harder to update at the moment. I haven’t touched it since 1.4.1 came out over 2 years ago, and the source code has been pushed out to some CDR backups – and the two I’ve found are, sadly, unreadable. I still have some hope of finding a copy someday (there’s a ton of stuff stashed away from my move), but don’t count on it. Recoding it from the ground up will have to wait for Leopard, where it’ll be much easier to do – there were some awful undocumented things I had to do at the time. Sorry about that. The USInternational keyboard layout will soon be repackaged in a way that (hopefully) will work around the “custom keyboard layout is randomly deselected” bug in Tiger. I’ll need to wait for a Leopard beta to come out to check if it’ll be upwardly compatible, though. I’m trying (again) to go through Apple channels to have it included with the standard system, perhaps this time it’ll work out?

Rainer Brockerhoff wrote:

Still, Steve Jobs said many features were still “top secret”. I suppose most of them will be revealed later under NDA.

And so they were. Well, at the least most of them that developers should be concerned about. I’ll talk about some fundamental issues here, but of course I can’t talk about details not released elsewhere.

Rainer Brockerhoff wrote:

Xcode 3.0 features a cool new debugging feature called… “Xray”. So. Good thing I’m at XRay II already. Where’s my lawyer…?

Well, I’ve had the opportunity to talk to Apple – informally, I hasten to add – and we’ve agreed there’s no conflict. A good thing too, as they have more lawyers than I do, hehe. Unofficially, I’ve heard that it was called PowerSomethingOrOther until nearly the last day before the show and then someone (marketing?) decided on the name change without doing a Google search. (Probably because PowerSomethings are on their way out, anyway.)

I’ve been floating ideas of possible name changes with other developers – GammaRay? CAT? PET? PowerSameThing? Nothing has quite the same zing, and I’d have to change the icon – and so I’ve decided keeping XRay II will be OK for me. It’s a full version ahead!

Anyway, I’ve been not-too-surprised about the mostly ho-hum reactions the keynote got among journalists, analysts and non-developer entities. And of course the stock is down. Well, no new iPod was revealed, right? And some people to this day think that Tiger was only Dashboard, Spotlight and some small cosmetic changes in the iApps…

…and from that point of view, the Leopard preview was only Time Machine, 64-bit support on some machines, and… HTML Mail templates? To-do in Mail. And erh, more effects in iChat and PhotoBooth, right? Personally, I was disappointed to see Steve Jobs waste so much detail on such trivia. And of course, HTML e-mail should be stamped out, not fomented!! Death to Mail templates!!! Argh. Sorry. Hm.

Well, it’s a developer conference and this was a preview for non-developers. The timing of this conference was very interesting. I’ve been to conferences where the timing was unfortunate. Way back when they showed the Copland preview absolutely nothing worked and most of the sessions were pure hand-waving. Last year, Tiger had already been out for a time and that conference was interesting more for its historical value (and for testing on the Intel kits, of course).

This time, the Leopard preview is at the right stage. Most of the new APIs and things are either working or in the final stages. There’s documentation! There are machines running the new system! The new system kernel panic a few times a day under hard use, but that’s normal. There’s the usual list of deprecated APIs we should avoid in the future, and the usual list of cool new APIs I’ll have to wait a year or more to really use. What is mostly not there is what those guys were looking for: a new kernel, a new Finder, the death of metal, new applications, radically improved applications (and I’ll explain below why they shouldn’t be here now).

More importantly, there’s a clear sense of direction. I’ve changed several ideas I had about XRay II’s implementation and most of them will make my life easier, mostly through having to write less code. Or, in the future, of being able to take code away, or to do cool new stuff on Leopard in the “just-works” mode.

So, what the non-developers don’t get is that Leopard is all about infrastructure – as was Tiger too, come to think of it. As someone (Lincoln?) is reputed to have said, “if I have 8 hours to fell a tree, I prefer to spend 6 hours sharpening my ax”. And that’s what’s going on. They’re sharpening the infrastructure. Then, a very short time (comparatively) before release, all the new infrastructure will make doing those cosmetic and application changes much easier, and they’ll be faster as a side-effect too. And they’ll be doing things not possible today. Some folks are catching this hint. For instance, Time Machine’s cool new UI is possible thanks to the new CoreAnimation framework, which itself rests on other stuff I can’t mention… and all this new infrastructure is interacting synergistically, so the rate of change of innovation is increasing without Apple having to add more engineers, or developers like me having to write more code. The new boring Mail features are based on new frameworks available to other apps, and so on.

More later…

Looks like I got most of it right… Xcode 3.0. 64-bit cleanness. Dual duo-core Mac Pro (Xeons), also in the new Xserves. No iPod or iAnything.

No new UI stuff was visible, but Time machine and CoreAnimation makes up for that; these were really cool. No new Finder, it seems.

No virtualization, unless they’re keeping the name “Boot Camp” for that. Still, Steve Jobs said many features were still “top secret”. I suppose most of them will be revealed later under NDA.

More later. Or not.

Update: Xcode 3.0 features a cool new debugging feature called… “Xray”. So. Good thing I’m at XRay II already. Where’s my lawyer…?

So, I’m just back from getting my WWDC badge. I’ve seen the famous banner and all icons on it are known – the only one I had doubts on (above the SpotLight icon) is supposedly from a Mac OS X Server utility. Even the 64-Bit icon was previously used when the G5 came out. Ah right, we now know what the Leopard “Big X” looks like – black with a white border. Drat, I need to change the XRay II icon to reflect that…

The relative sizes and positions give no hints. There are a few hardware icons. One iPod Nano. 3 iMacs, 2 laptops and one desktop – the latter one from the side, so the front may be different. Or the banner might just be there as a misdirection and may be changed on Thursday… the Xcode icon is very large – so large that one can read the small print on it, but then it’s a developer’s conference. On the other hand, people “in the know” did tell me to make sure not to miss the developer tools sessions.

Certainly a major release of Xcode is in the works. 2.5 or 3.0, it doesn’t matter, but my personal hunch is that the superannuated Interface Builder application will be phased out and integrated into Xcode. Let’s hope that connections like outlets and bindings will be easier to visualize and debug, and that the IBPalette interface is finally officialized so that we can write non-trivial palettes.

I’ll be under NDA for details – things announced at the keynote excepted – so these will be my final pre-WWDC speculations. On the hardware front, 64-Bits is of course guaranteed, with one of the new “Core 2 Duo” chips. A Mac Pro will certainly be out, although the name may not be exact, and the casing will probably be a minor variation on the current one. There’s a good Ars Technica writeup about the new Intel CPUs, and expectations are that the whole new range will fit nicely into the spectrum from MacBook Pros to the Mac Pros – possibly with a dual-core, dual-CPU at the top, although it might also be that Intel has been reserving their quad-core chip for Apple to announce. Intel Xserves might also appear.

I don’t expect a new iPod to be announced in a big way, except as a footnote to the usual summing-up of past sales; at a developer’s conference, it’ll be big news only if it had an official API for developers to extend its functionality, which might actually be a neat way for Apple start a new iPod generation in a privileged position; stranger things have happened.

I’m reasonably certain that we’ll each get a Leopard preview DVD. I’ve seen rumors of changes to applications, which I consider less interesting as they’re not really a part of the OS itself, at least from my developer’s standpoint. I use relatively few of the iApps every day – Safari and iChat are the ones I leave open, and my wishlist for those is small.

Real Leopard features I expect to see:

– RBSplitView adopted! Well, not likely, but it’d be nice… I’ve told Apple I’d gladly give them the code, anyway.

– A new UI theme, or at least a migration of the default windows theme to the new “cool gradient/smooth metal” look.

– Some new Cocoa widgets, especially the more successful ones from the Tiger iApps. I hope to see them do Brent Simmon’s “big time tabs control”; I need it badly for XRay II.

– A new Finder. I’ve mostly gotten used to the old one, but still…

– Resolution independence. We need to get away from the pre-rendered bitmap widgets. People are already starting to use object-based PDF files for that, but they’re a pain to make and don’t look good at all resolutions. My ideal solution here would be a new NSImageRep and corresponding file format that would do for images what the TrueType format did for fonts: resolution-independence with special hinting for small sizes.

– More extensions to Objective-C. Garbage collection should be a given. Unloading NSBundles is supposed to be in the works. Frameworks included inside applications can’t be easily updated and versioning is pretty much useless for practical purposes.

– Hopefully we’ll see expanded metadata capabilities and a more useable SpotLight. I hardly use it in Tiger because it’s so slow and limited. The ability to have additional named forks should go hand-in-hand with full NTFS support. Other file systems would also be nice (ZFS, anyone?).

– Virtualization. I’ve written about this several times. My personal opinion is that Apple should write a fully trusted hypervisor into the EFI (using the TPM) and run everything inside virtual machines, including Mac OS X for Intel itself. Booting some version of Windows into a second VM would be easy, then, and there wouldn’t be a full version of Mac OS X for Intel for people to run on standard PCs either. I don’t think dual-booting is a good solution, I believe Apple was just testing the waters with BootCamp. No idea what would happen to Parallels in this scenario; they might be bought out by Apple, or by Microsoft, I suppose. Here are more thoughts on virtualization from Daniel Jalkut and Paul Kafasis.

– 64-bit “cleanness”. Meaning, Carbon and Cocoa and everything else running in 64-bit apps. And very probably, also, on the G5s. However, I’m not sure (and no time to research at this moment) how mixing 32 and 64 bits works on the Intel CPUs. I remember reading somewhere that it’s not as easy as it is on the G5, where you can have 32-bit processes co-existing with 64-bit processes.

Unlikely or even impossible:

– A new kernel.

– iPhone, iPDA, iGame, iTablet. iAnything in fact. There are rumors about VoIP support and there might be some sort of hardware for that, but I can’t see Apple doing a me-too cellphone.

– Some goodie under the seat (like when the iSight was introduced, which I missed out on, argh!).

In the meantime, I’d better get back to my coding… more after the keynote!