I think the thumbnails of the misted look awful, though that might be because I can see the original to compare. There seems to be weird semi-regular patterns around the images that I think I'd notice even without the comparison, though.
Not sure which pieces you're talking about. Code changes to various open source projects within OS X, iOS, and Xcode can be found here (and the referenced sites therein).
Those projects are often not in a state where they can be compiled, and when they are you find that they are heavily redacted. For example, none of the code required to make any of that run correctly on ARM devices is available. (Given the context from this thread about large projects, however, I feel the redactions of things like touch events from WebKit, are a more serious issue.)
On the other hand, for the i386 copies of FreeBSD (which the great-grandparent was talking about), Apple does release working copies of their FreeBSD-derived kernel.
The xnu kernel is pretty far from FreeBSD. It's based on CMU Mach 2.5 (mainly virtual memory and IPC), 4.3BSD (mainly networking and VFS) and the Apple/NeXTSTEP-developed device driver framework called I/O Kit (which is written in C++). I don't think any kernel changes have been merged back into BSD. At this point they've probably deviated too far anyway.
Building xnu from public sources is quite an undertaking. It does still seem to be possible (although it got a lot harder with the x86 transition due to more proprietary drivers). The PureDarwin distribution still seems to be based on the Snow Leopard kernel, I'm not sure why. http://www.puredarwin.org/
Fair enough, although the parent of that post just talks in general about larger projects (such as the toolchain) and the post I directly responded to talks about Xcode.
The price is actually ≈ $70 per month. From the article ...
Update: the initial version of this article mistakenly listed the price of Sonic's gigabit service at $79.95; it is actually $69.95.
That's amazing. Here I thought I was getting a bargain with 15Mbps SDSL for $25 per month (our mid-rise condo building in downtown San Jose, CA struck a deal with our ISP if some percentage of residents signed up).
>> Other stuff, like Preview, I don't use often enough to care about the load time, and I would probably configure it to exit when the last window closed.
Under Lion, that is (sort of) what Preview and TextExit do. When you close all open documents in Preview and then switch away from the app, the app will terminate.
So if they were both using "{" to set them off the parser doesn't know which one you mean until it hits the first ":" (and it can't guess from the type when the type is "id"). Now that's not impossible to write a parser that looks ahead to figure out what you mean, but it's much easier to parse if they have completely different syntax from the outset. And the "{" vs "[" distinction is very standard amongst the higher level languages, even if it isn't in straight C.
I think they chose the [] for arrays and {} for dictionaries as that is the style that seems to be most popular right now. Python for instance uses this.
When adding features to something, I tend to be a big fan of "when in Rome"[1]. If these were extensions to Python (or Ruby or JavaScript) then I would totally be for using '[' with arrays. As a C guy though, I would rather have seen them use '{' for NSArray and '[' for NSDictionary. Regardless, I'm glad to see this stuff added.
It's already custom in objc to use {} for dicts and [] for arrays when printing them out, unless I'm misremembering. It also matches the use of those characters in JSON, so it seems natural to me.
Could be in case they want to do literal NSValues later. Since {}-syntax is used in C for both array literals and struct literals, they needed to change one, and the picked the more common one. Otherwise is foo in:
id foo = @{ @2, @5 };
an NSArray containing two NSNumbers, or an NSValue containing a struct with two pointers (which happen to be NSNumber *s)?
I'd guess there were other edge cases they didn't want to deal with, so they didn't do literal NSValues for this release.
Or it could be that it's because []-style arrays are popular these days.
Or some of both; in picking which {} to change to @[], they reasoned that lots of people have experience with []-style arrays.
I'm glad to see Jawbone taking customer satisfaction seriously, but I hope this doesn't negatively impact them moving the product category forward.
I've been using an Up for about a week now and really like it. Yes, the battery life is half of what they claim (I only got 5 days on a fresh charge, not 10). Yes, it is annoying that it doesn't use Bluetooth LE for data transfer. Those two negatives aside, it is IMHO a good first generation product.
Their example Van Gogh images look okay as thumbnails but are really different from the originals when viewed larger.
Overall a neat project though.