So, Leopard's out today. In approximately 3 hours, the NDA will be kaput, and I'll be able to tell you just how hard the new developer tools and frameworks kick Vista's ass. Meanwhile, there's some nifty consumer features as well, other than what's been in the press releases: http://www.macworld.com/2007/10/firstlooks/leopard_s_hidden_gems/index.php Calendar Attachments Built-in on-the-fly resizable partitions Smart unmounting Scrolling background windows
I'm rather impatiently waiting for Fed Ex to deliver my copy. I'll be very interested to read your take from the development side of things, though.
You have no idea how happy I am to find on-the-fly resizable partitions; means I can keep an 8 GB bare-bones Tiger installation on another partition along with an OS 9 System Folder, as Classic support is gone from Leopard, and I loves me my classic Maxis games. As for Development... 45 more minutes and then I can tell you all of the awesomeness that is the NS<censored by Apple legal> API.
Finally. 1. NSOperation and NSOperationQueue. Apple-easy object-oriented multi-programming. You have to use it to believe it. 2. I forget what it's called, but basically, it prevents buffer overrun exploits at the system level by adding a "canary" to the top of the function call stack, but just below the actual return address. If the canary is different at the end of the function from what it was at the beginning (determined at every function call, IIRC by a hash of the function memory image), the OS throws an exception and kills the process rather than letting it become dangerous. 3. Objective-C 2.0. Opt-in garbage collection down to the C level, with a generational, incremental garbage collector. Synthesizable, customizable properties, a foreach, and a host of other things which I don't have time to describe right now as I've got to go get a copy.
How often would that happen in a stable system run by someone who knows what they are doing...? (/me remembers welchia and blaster causing a massive stink, but only to the clueless...)
Too vague... care to elaborate on it when you get a chance? The buffer overrun vulnerability is, IIRC, solved at the hardware level via the NX bit present in current AMD/Intel processors (at least in terms of OS memory locations). This came out on AMD processers along with AMD64 architectures but was copied shortly thereafter by intel. Totally killing buffer overrun would prevent the Blu-ray / HDDVD cracking method (at least the one I heard described). Then again, Jobs has some eggs in the Disney basket so he's probably glad about this The other two things sound like Ruby features, but theres not really enough detail here for anything beyond speculation. Any information on this point? I didn't find a ton of info just really short blurbs. Edit: did a bit of checking on NSOperation... I guess I don't see where it is much different than other thread libraries that are out there.
Unfortunately, it appears to be buggy as hell. My install went kablooey. I'm trying to manually rebuild my mail and preference files (plus I'm going to have to reinstall most of my Adobe apps) and I have most of it fixed...but my mail is totally messed...it won't read the old mail files (yes, I moved them and carried over the mailbox settings I was using previously...and new mail is coming into the accounts). it looks slick, certainly, and seems faster. But the install hangs for a lot of people....and it didn't archive my old set up right. Thankfully, I had the data backed up, so I can rebuild it, but it is a PITA to deal with. I haven't had a mess this big since the OS X Beta. Looks like it needed a bit more time in Beta testing.
Christ, that was the scariest upgrade I've ever done. Aside from taking forever, I clicked on Mail only to get "Mail has quit unexpectedly." Fuck. It took me a half-hour before trying the Mail.app sitting in the Applications folder rather than the updated location I moved it in my "Communications" folder in Applications. Then it worked. It just assumed you would never move anything, and the prospect of that is not only scary as hell, but totally defeats the purpose of self-contained applications. So, thus far, A for the OS, F for the install.
I'm stick picking up the pieces. My install went awry and I'm going to have to reinstall most of my apps. Not a big issue, since I have all my discs...just a pain. On the plus side, my G5 2.0 dual is much more snappy — and seems to have lost the system grunge plaguing it for the last six months or so.
I upgraded two Intel machines this morning with nary a hitch. Biggest "Fuckin' A": No more network hangs! Biggest WTF: No groups of files in stacks. The new Dock and Menu Bar are not nearly as big of a deal as some were saying. I actually quite like them.
On that particular issue, a roaring from me. It's not like Apple doesn't provide a service to locate moved applications. They seriously need to USE it. I mean, I can understand when MS Office needs to be in the Applications folder. I can understand that, really. It's MS after all. But shame on Apple for not using their own damn Launch Services framework. Although the tradeoff is the ability to have multiple copies and/or versions of the applications spread out wherever, and thus it's not THAT surprising that a) the Dock icon would still point to the old Mail application, and b) that the Tiger version of Mail would fail to launch in Leopard. Powa: NSOperation isn't strictly a thread library; there's NSThread et al. for that. This API abstracts away the thready bits, as well as (with varying degrees of success in the developer builds) all the state synchronization stuff.
Well, frankly, if they're going to go this route, they need better fucking error messages. One like: "This version of [APPNAME] was designed for a previous version of Mac OS X, and cannot run in Leopard. Would you like to update it to the current version, which is also located in [APPPATH]?" It didn't really surprise me that the dock aliases pointed to where I had directed them to point, nor that the old versions wouldn't load in Leopard. Once I had figured it out, of course. When there's only one copy of it on the system, that copy should be automatically updated, no matter where it is. When there are multiple copies of the same version, they should all be updated. When there are different versions, one should be prompted which version, if any, they wish to update. It just reeks of laziness otherwise, and it totally ruined the OOBE for me. That's an experience that Apple values a lot.
Do you guys know if Leopard provides support for the Bluetooth stereo profile? I was disappointed to find out that Tiger didn't.
Yeah, I don't think that's likely to be fixed anytime soon because of the moronic Installer.app and it's oh-so-non-interoperable backend pax. I think I actually met the designer of Installer.app, at WWDC one year, or maybe I heard a talk he gave, or maybe it was secondhand (sorry ). It was mentioned at one point that the biggest frustration that people had had in the pre-X days was a) the lack of a standard installer, and b) "Searching Macintosh HD" from the VISE and Stuffit installers that took forever. Installer.app and Package Maker did fix both of those issues... they just opened up a host of new ones. And it is technically possible to do what you describe... but unfortunately, it would make the install about an order of magnitude slower, and it would rely on some pretty funky shell scripting. Let me explain: Installer.app works roughly like this: 1. Check given parameters to see if the software can be installed on a particular volume. 2. Run the preflight scripts, preflight, preinstall, and/or preupgrade depending on the scripts provided and the type of install (flight is both upgrade and install). These can be in any shell scripting language supported by the system. Notably, they can't be just any executables, they have to be shell scripts. 3. Install the contents of the .pax archive to the locations provided in the Bill of Materials (.bom) file. These locations must be absolute paths, because of fucking pax. 3a (developer's step). Lament the fact that Apple used pax instead of gzip. 4. Run the postflight scripts. If you need to move the files to a relative path (such as ~/anything), you do that here. What this means is that in the preflight script, one must call "/absolute/path/to/my/finding/proggy" executing a real executable which would then use Launch Services to find the moved application. That program would have to write the location of the moved application to the working temp directory (which can't be /tmp for a from-CD installation!), which postflight could then use as a root to cp the recently installed files to, unless of course the installed path is the correct install path. All well and good. In fact, I think Adobe does almost exactly that when installing updates. Here's the rub, and why it's especially problematic for a from-CD install: to reduce memory footprint, the Launch Services cache is maintained in persistent store which is normally the hard disk, but when booted from a CD, is the CD. If the cache is out of date, it must be rebuilt. In semantics, it's fairly similar to the locate database. The problem is, of course, that once the thing is built, it can't be saved, because you're on read-only media. So we're talking about an update.locatedb-equivalent for every single package, of which there's a couple dozen in the installer metapackage, some of which are metapackages themselves, for a total of I think around 100 runs (assuming it can do lists of programs at once (such as for the Essentials package), which is questionable), since that searching program doesn't remain open between packages! Oh my. So why not just fall back on more traditional searching techniques and incorporate them into the CD-based installer? Well, I don't know why they didn't in the first place (nor why on earth they switched from gzip to pax when moving from OpenStep to OS X... can you tell I didn't like that decision?), but at this point, probably because that would break 7 years of consistent, if undocumented, behavior; Mac users by now know that to prevent an Apple application from being upgraded, you hide it or a copy of it in another folder.
I know you guys are probably waiting for my snide comment, but I'm not gonna give you the satisfaction
I'm a mac newbie...had my intel powerbook for a few months now. It worked fine at first, but now the Finder "hangs" alot..especially when I am transfering files to and from external usb hard drives, and when I am using Azureus. Also sometimes when I am emptying the trash. Heck, it seems to hang a lot in a lot of situations. Nothing works but to reboot. I was hoping upgrading to Leopard would cure my hanging woes, but alas, not so much. Any suggestions?
very often. Sometimes, other programs crash, and I have to "force quit" several times for them to shut down. Other times, they won't shut down at all, which prevents me from restarting the computer. But very often it is the Finder that crashes, and there is nothing i can do but hard-restart with the power button.
How much RAM do you have, in what configuration is it (2x256MB? 1x1GB?), and how long does it take before symptoms develop?
Does the finder really find files instantly ( lets say under 0.5 seconds )? Or is it a bit slower? The search on Vista isn't what I'd call instant (although it is for applications that are on start menu). It's pretty good though. What really irks me is that if you get a new file from the internet, removable media, etc, then immediately try to search for it... no fuckin' go. Doesn't get put in the index until the next time indexing service rolls around I guess. Is finder able to know about files that you have just created/ripped/downloaded/copied?
^Depends how many files you have indexed. If you haven't customized what folders Spotlight indexes, then yes. (me, I have included /usr/include (and all of its subfolders), the Developer Documentation, and the /System and /Library folders - still only takes about 10 seconds in the worst case) For the second question, an enthusiastic "Yes!" thanks to the /dev/fsevents system: anytime ANYTHING happens to the filesystem, (create, delete, or modify), /dev/fsevents lets Spotlight know about it. IIRC, John Siracusa did a nice writeup on this bit in his Leopard review over at Ars Technica.
So, that functionality was new with Leopard, or its been out since finder's release? Or maybe I've been thinking of spotlight this whole time.
Spotlight (and /dev/fsevents) have only been around since 10.4 The Finder has been around since, oh... 1984. Back in the 80's and 90's, one would use a Norton (now Symantec) product to do local search! It was called FastFind.
