Are you serious? Mavericks is awesome. One of the greatest surf breaks ever. Every bit as lethal as any of those cats and more a testament to human achievement. Personally I am looking forward to releases like Cloudbreak, Teahupoo, Waimea, and Shipsterns.
It can only be places that inspire them near their offices, so expect a good stream of Californian and Chinese names. Probably mostly Chinese given that most of the sweatshops are there.
I'm glad they are _finally_ solving the multiple desktop issue, its definitely the most frustrating aspect of OSX. Also, loved how it worked with AppleTV.
The apple tv desktop extension is something apple was way behind on. AirParrot has had that for 1.5 years. http://www.airparrot.com
*disclaimer: I'm a former employee of AirSquirrels the maker of AirParrot. I have no real interest in making them money other than I have some friends that still work there. :)
We all knew a UI refresh was coming, but most of the iOS7 interface concepts were unexpected. Same with trashcan Mac Pro and 12hr Air: we knew there'd be refreshes, but the details were surprising.
Also, while there's not much glitz to 10.9, the list of iterative improvements is extremely promising, assuming it delivers.
Actually the details aren't that surprising, given what processor and gpu tech's available at present. I'm surprised there haven't been leaks about Maverick and the Mac Pro - I work for The Foundry, and tomorrow Pixar artists are demoing an early beta port of Mari on OS X with OpenGL4 (rather ironically, as Pixar mostly use Linux).
We've known about the OpenGL 4 in OS X and the AMD graphics cards in the new Mac Pro for a while.
I love my NanoWatch to pieces, and eagerly await any company that can make something better. But it's not really something I see fitting into the Apple way.
Yes, the keychain is encrypted with your OS X user login password and only unlocked on login. I imagine this will still be the case as Apple mentioned AES256 encryption on their iCloud Keychain slide, though they could change it to use your Apple ID password if they plan on having mobile device support.
> Yes, the keychain is encrypted with your OS X user login password and only unlocked on login
The "login" keychain is encry..... (the rest of your sentence).
You can have many more keychains, and they can have far more sophisticated passphrases. I have an "Internet Identities" keychain (for iCloud, Gmail, Dropbox, VPSs, Github, ...) that has a very long passphrase and is not unlocked at the login, nor it stays open after you enter the password (so, if Safari asks for the password and I enter it, the keychain doesn't just stay "open" for all apps to feast upon).
I don't think Firefox saves logins in the OS X keychain, and mapping which credentials go with which urls is something that Firefox is responsible for, not Apple.
Lots of people are already doing this with 1Password either in iCloud or on Dropbox. As long as it's encrypted with the appropriate algorithms, what's the issue?
They have 'suggested passwords' feature. It sounds a lot like 1Password, but is there going to be a PC client or web client to access those passwords?
I wouldn't dare use it if I was on another machine I hope (I have a mix) and not have access to my passwords. If it's Mac-only, that's going to be a problem.
Because I'm the kind of guy who doesn't want to share his keychain if its not necessary, is why. Its not necessary unless I reason to share a keychain .. and .. having this choice being taken away from me would be a suitable reason to abandon the platform.
I'm kind of surprised and amused that the NBA expansion team chose the name of a Roast Beef Sandwich restaurant in Minnesota. http://www.mavericksroastbeef.com
I'm kind of surprised and amused that a Roast Beef Sandwich restaurant in Minnesota chose a name that refers to a cow that has escaped from a ranch and lived out its days stringy and free from the slaughterhouse.
"Mavericks" is different than both the singular noun/adjective found in Ubuntu, "Maverick" and the plural adjective/noun NBA team, "Mavericks". It is a singular place name - "Mavericks". Cook got it mixed up a few times in the keynote too. It's a tricky one to use...
Any guesses as to when Apple will drop the "X" from "OS X"? The name "OS Ten" is getting a little long in the tooth. I hear people pronouncing it "OS Ecks" more frequently these days.
At the code level, I assume we will live with the 10.x version numbers forever, like Solaris 11 is also "SunOS 5.11".
Are you kidding? X is an letter that, even after many decades of over-use, denotes mystery and excitement. It is surprisingly powerful for something so simple and widespread.
My baseless speculation is that they will dial iOS up to version ten and merge the OSes at iOS X.
Note that the "10.9" part was extremely diminished in today's announcements. While those underlying version numbers may live in, I suspect they won't be using the numbers in public in future.
It looks like the center is a separate zone entirely, so that the heat sink could gather dust, but there is little air flow over the actual components themselves. In other words you might be able to pull a Swiffer pad through the center fins, where you'd risk damaging things if you did that over a circuit board directly.
Funny thing about the iMac I have, you can't turn off the embedded monitor and just run an external monitor. It seems the new multiple monitor situation doesn't have any call outs for the iMac or anything sensible. I actually think they prevent this specifically in the sense that I should just want a Mac Mini or Apple TV and shouldn't doubt the ability to buy a way out of the problem.
OS X was the first operating system to ship as a single
install that could boot into either a 32-bit or 64-bit
kernel, either of which could run 32-bit and 64-bit
applications at full native performance. OS X now
exclusively uses a 64-bit kernel, but it continues to run
both 32-bit and 64-bit applications.
I believe Solaris was actually the first to do this:
To be clear, Apple are claiming the ability to install both 32-bit and 64-bit kernels on a single disk, and select the correct one at boot time so that boot disks are transportable between 64-bit and 32-bit machines.
I'll clarify then: I believe Solaris has had the first part (ability to boot into a 32-bit or 64-bit kernel) since 1998. That's well before Apple even provided a 64-bit kernel or ever shipped an OS X release.
Solaris has long had a single, unified architecture for 32-bit and 64-bit and until recently delivered both a 32-bit and 64-bit kernel on a single disk. That's why on Solaris you'll generally find the 32-bit libraries installed in 'usr/lib' and the 64-bit under 'usr/lib/64'.
The only exception is for processor architectures (SPARC/x86) where it made less sense.
But even then, Solaris 11 has multi-variant packages, so a single package provides support for both x86 and SPARC.
It's true that (as far as I'm aware) Solaris never supported the 64-bit application on 32-bit kernel hack that OS X did (which comes with significant performance tradeoffs).
So at most, Apple can claim that achievement, but they can't claim to be the first to provide a single install image supporting 32-bit and 64-bit.
"It's true that (as far as I'm aware) Solaris never supported the 64-bit application on 32-bit kernel hack that OS X did"
It also is true that (as far as I am aware) Solaris never had lots of 32-bit customers running applications and drivers that neither Sun nor those customers could recompile for 64-bits.
That and the fact that some of those customers desperately wanted/needed to access more than 4 GB of memory forced Apple's hands. They had to keep the kernel 32 bits to support older drivers, and had to provide a user space that supported more than 32 bits.
The world is so much simpler if you can force al your customers to recompile their applications. If you doubt that, ask Microsoft or Intel why Itanium didn't even get a chance.
It also is true that (as far as I am aware) Solaris never had lots of 32-bit customers running applications and drivers that neither Sun nor those customers could recompile for 64-bits.
That is definitely not true. In fact, many of the binaries distributed with Solaris itself (even now that it has a 64-bit kernel) are still delivered as 32-bit because there's no need for them to be 64-bit (yet).
The world is so much simpler if you can force al your customers to recompile their applications. If you doubt that, ask Microsoft or Intel why Itanium didn't even get a chance.
Except Sun/Oracle (Solaris) never required that. In fact, Solaris is famous for its backwards binary-compatibility. In fact, on Solaris 10 you can run binaries that were compiled decades ago without issue.
Apple would have lost many of its top of the range customers if it had jumped directly to full 64 bit, because, due to lack of drivers (note the italics in my original post), those users would have lost the use of their expensive hardware.
Sun, AFAIK, was much more in control of its drivers, so it could move its systems to 64 bit easier.
The key phrase is "either of which could run 32-bit and 64-bit applications." OS X supported 64-bit apps on a 32-bit kernel. This enabled users to run 64 bit apps, and use >4 GB address space, without any device driver incompatibilities.
I think Solaris (and Windows and Linux) require a 64 bit kernel to run 64 bit apps. Correct me if I'm wrong.
With that said, OS X's hack support for 64-bit applications on a 32-bit kernel certainly wasn't at the same performance level as a 64-bit kernel as they claim. It's a dubious achievement at best given the performance tradeoffs.
It seems like you are casting aspersions. In what way was it a "hack" and what performance tradeoffs were there? Apple's claim is that 64 bit apps ran at native speeds, which is true, since they just used the native ISA.
Apple lists a few benefits of K64 at https://developer.apple.com/library/mac/#documentation/MacOS... , specifically more efficient support for systems with lots of RAM, a larger buffer cache, and better support for multiple video cards with over 2 GB of RAM. These are pretty specialized, and I certainly don't remember my Mac getting a lot faster when it switched to K64. (I sure wish it had!)
But, there was a cost to that dependent on architecture. If you read the document I linked above, you'll see that there is a cost to this 64-bit translation -- the performance is not completely equivalent to a 64-bit application running on a 64-bit kernel where there is no need for translation.
And yes, there were performance tradeoffs. A 64-bit application running on a 32-bit OS still had all of the 32-bit limitations enforced (limit on maximum process size, number of file descriptors, etc.).
And once Apple made the transition to x86 from PowerPC they lost the built-in hardware advantage. x86 can also run 64-bit applications on a 32-bit kernel, but the cost of doing that hardware switch is not as cheap as it was on PowerPC. I also think it's very telling that Solaris, Linux, and Windows opted to never do this as well.
And now that OS X no longer offers a 32-bit kernel, this all seems moot anyway.
Hardly. Anyone who ever has to use a non Apple device - Windows desktop, Android phone, etc. - is going to still need a cross-platform solution like 1Password.
Maybe this will be the kick up Agilebits' ass to fix their Windows and Android apps, and perhaps even deliver a Windows Phone app as well. The Android 1Password app in particular is embarrassing.
My understanding is that the API presented control of all desktops to one application. An app could address displays individually and make full use of it.
Clearly that wasn't the right approach, but it wasn't as blatantly broken as everyone makes it out to be.
Most users don't use multiple displays. For the vast majority of users, nothing was broken. Also, the multiple-menubar thing illustrates that it's not exactly a simple or uncomplicated fix following the introduction of fullscreen app support.
I would think that Apple devs would use multiple monitors and would have coded the base functionality so that it made sense working.. Even Windows has had pretty decent multi-monitor support for about 5 years now.
Anyway, I look forward to proper multi-monitor support without have to purchase an expensive 3rd party add on, or manually resizing my windows on different screens.
I'm also hoping that like windows, OS-M will remember what apps are where when I plug in different screens (like home vs office).
Windows has had excellent multi-mon support since at least the XP era, (when I started using dual monitors at work and home in, I think Win98 wasn't that bad either), and to make you feel old, realize that WinXP has been out for 11 years.
I think it was a philosophy more than anything. Fullscreen is not just "taking up the whole screen", it's the idea that you are working on only one application. So if you are fullscreen on one screen, the other screens should be blanked out so they aren't a distraction.
Many disagreed with this philosophy, but that was why it was "broken."
And Spaces/Mission Control dragging of apps between multiple displays!
Basically they made someone actually use 2 monitors on Mountain Lion and said "Make a list of everything that sucks." Then they actually fixed it. Pretty simple.
Not a lot of technical specificity around "memory compression". Edit: Ok, I stand corrected, somebody's done some research and found the code.
Windows 8 does a similar-sounding trick. At some timer interrupts they de-dupe pages and make them copy-on-write when they are identical. I seem to recall also reading that some VM products (VMware?) do this - so if you have a few instances of the same OS, only unique pages end up getting stored.
From the presentation I wonder if they're doing this, or if they might be putting the pages through a compression algorithm. (I hear "compression" and I think this, but it seems like that would make page faults needlessly costly.)
Google added this to the Linux kernel quite some time ago for Android.
Basically, it inserts a step before the "move to swap" step where it compresses the page. This a) allows Linux to write a compressed page to swap which allows both faster writes but also faster reads, b) allows you to use more memory before hitting swap.
Major distros are considering enabling this functionality in their kernels by default.
What you're describing sounds like samepage detection, which Linux also has thanks to Google and Android.
Memory compression still hasn't been merged into mainline linux; right now it's looking like zswap will make it into 3.11. I think zswap was developed by IBM.
I think kernel samepage merging was developed by Red Hat.
I really hope iCloud can be disabled in OSX-M. As far as I am concerned iCloud is a disaster. It causes all manner of data loss on iDevices, generally without the user having a choice. For example, my wife lost her entire calendar -all events- just for turning off calendar synchronization. All events had been originally entered through her phone. Somehow iCloud decided to delete anything that was also stored in the cloud, which meant everything. I really don't get the logic behind this behavior. It's really dumb. You never loose user data. So, I don't trust it now. I don't care to have anything to do with it.
A mountain lion (10.8) and a puma (10.1) are the same animal. A panther (10.3) is a subtype of leopard (10.5).
But even with these redundancies, they are running out of large cat names to use and would have to go with the likes of "jaguarundi", "serval", and "manul" to keep the theme going. These are cool animals, but have nowhere near the emotive power that "Jaguar" or "Lion" had.
129 comments
[ 3.7 ms ] story [ 191 ms ] thread[1] https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_%26_W...
This is named after: https://en.wikipedia.org/wiki/Mavericks_%28location%29
Obviously multiple monitors have needed a fix for ages but spaces are my pet issue so I have to ask.
Each display can now have it's own virtual desktops, and each screen can have their own full screen app without showing linen on the other.
Easy dragging of apps from one screen to another and more.
*disclaimer: I'm a former employee of AirSquirrels the maker of AirParrot. I have no real interest in making them money other than I have some friends that still work there. :)
Also, while there's not much glitz to 10.9, the list of iterative improvements is extremely promising, assuming it delivers.
We've known about the OpenGL 4 in OS X and the AMD graphics cards in the new Mac Pro for a while.
If so, I guess I'm abandoning Apple faster than I thought I would, a day or so ago .
The "login" keychain is encry..... (the rest of your sentence).
You can have many more keychains, and they can have far more sophisticated passphrases. I have an "Internet Identities" keychain (for iCloud, Gmail, Dropbox, VPSs, Github, ...) that has a very long passphrase and is not unlocked at the login, nor it stays open after you enter the password (so, if Safari asks for the password and I enter it, the keychain doesn't just stay "open" for all apps to feast upon).
* appleid.apple.com
* daw.apple.com
* id.apple.com
* secure1.store.apple.com
* secure2.store.apple.com
If they have trouble getting something as simple as that right, I'd like them to stay away from my keychain.
It's unknown how many of those bits the NSA knows already.
I wouldn't dare use it if I was on another machine I hope (I have a mix) and not have access to my passwords. If it's Mac-only, that's going to be a problem.
I mean, you could tell us WHY you think it's a bad idea.
Informing us of that you'll leave OS X? We could not care less.
;)
(Things called maverick which are not operating systems are irrelevant for that!)
At the code level, I assume we will live with the 10.x version numbers forever, like Solaris 11 is also "SunOS 5.11".
My baseless speculation is that they will dial iOS up to version ten and merge the OSes at iOS X.
I just don't think Apple marketing would go for "Ten point ten" or "eks point eks" or even "eks point 10"
Personally, the only issue I had with it was opening a new tab/window/shell being somewhat slow. Fixed with "touch ~/.hushlogin"
2. Forget about Terminal.app
Sea Lion was 100x better
And Keychain stored in iCloud, yeah, nice try there Apple.
Finally - the new MacPro looks like a roll of toilet paper encased in glossy plastic. What is that thing.
FTFY
http://en.wikipedia.org/wiki/Solaris_%28operating_system%29#...
OS X has had this ability since 64-bit PPC days.
Solaris has long had a single, unified architecture for 32-bit and 64-bit and until recently delivered both a 32-bit and 64-bit kernel on a single disk. That's why on Solaris you'll generally find the 32-bit libraries installed in 'usr/lib' and the 64-bit under 'usr/lib/64'.
The only exception is for processor architectures (SPARC/x86) where it made less sense.
But even then, Solaris 11 has multi-variant packages, so a single package provides support for both x86 and SPARC.
It's true that (as far as I'm aware) Solaris never supported the 64-bit application on 32-bit kernel hack that OS X did (which comes with significant performance tradeoffs).
So at most, Apple can claim that achievement, but they can't claim to be the first to provide a single install image supporting 32-bit and 64-bit.
It also is true that (as far as I am aware) Solaris never had lots of 32-bit customers running applications and drivers that neither Sun nor those customers could recompile for 64-bits.
That and the fact that some of those customers desperately wanted/needed to access more than 4 GB of memory forced Apple's hands. They had to keep the kernel 32 bits to support older drivers, and had to provide a user space that supported more than 32 bits.
The world is so much simpler if you can force al your customers to recompile their applications. If you doubt that, ask Microsoft or Intel why Itanium didn't even get a chance.
So I'm not sure what your point is.
Sun, AFAIK, was much more in control of its drivers, so it could move its systems to 64 bit easier.
I think Solaris (and Windows and Linux) require a 64 bit kernel to run 64 bit apps. Correct me if I'm wrong.
With that said, OS X's hack support for 64-bit applications on a 32-bit kernel certainly wasn't at the same performance level as a 64-bit kernel as they claim. It's a dubious achievement at best given the performance tradeoffs.
Apple lists a few benefits of K64 at https://developer.apple.com/library/mac/#documentation/MacOS... , specifically more efficient support for systems with lots of RAM, a larger buffer cache, and better support for multiple video cards with over 2 GB of RAM. These are pretty specialized, and I certainly don't remember my Mac getting a lot faster when it switched to K64. (I sure wish it had!)
Apple's claims about performance primarily applied to OS X when run on a specific version of the PowerPC processor:
http://www.ece.uprm.edu/~nayda/Courses/Inel4215F03/power64.p...
(See pages 304-306.)
But, there was a cost to that dependent on architecture. If you read the document I linked above, you'll see that there is a cost to this 64-bit translation -- the performance is not completely equivalent to a 64-bit application running on a 64-bit kernel where there is no need for translation.
And yes, there were performance tradeoffs. A 64-bit application running on a 32-bit OS still had all of the 32-bit limitations enforced (limit on maximum process size, number of file descriptors, etc.).
And once Apple made the transition to x86 from PowerPC they lost the built-in hardware advantage. x86 can also run 64-bit applications on a 32-bit kernel, but the cost of doing that hardware switch is not as cheap as it was on PowerPC. I also think it's very telling that Solaris, Linux, and Windows opted to never do this as well.
And now that OS X no longer offers a 32-bit kernel, this all seems moot anyway.
Clearly that wasn't the right approach, but it wasn't as blatantly broken as everyone makes it out to be.
Anyway, I look forward to proper multi-monitor support without have to purchase an expensive 3rd party add on, or manually resizing my windows on different screens.
I'm also hoping that like windows, OS-M will remember what apps are where when I plug in different screens (like home vs office).
Many disagreed with this philosophy, but that was why it was "broken."
Basically they made someone actually use 2 monitors on Mountain Lion and said "Make a list of everything that sucks." Then they actually fixed it. Pretty simple.
Windows 8 does a similar-sounding trick. At some timer interrupts they de-dupe pages and make them copy-on-write when they are identical. I seem to recall also reading that some VM products (VMware?) do this - so if you have a few instances of the same OS, only unique pages end up getting stored.
From the presentation I wonder if they're doing this, or if they might be putting the pages through a compression algorithm. (I hear "compression" and I think this, but it seems like that would make page faults needlessly costly.)
http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/iok...
http://static.usenix.org/event/usenix01/cfp/wilson/wilson_ht...
Basically, it inserts a step before the "move to swap" step where it compresses the page. This a) allows Linux to write a compressed page to swap which allows both faster writes but also faster reads, b) allows you to use more memory before hitting swap.
Major distros are considering enabling this functionality in their kernels by default.
What you're describing sounds like samepage detection, which Linux also has thanks to Google and Android.
Memory compression still hasn't been merged into mainline linux; right now it's looking like zswap will make it into 3.11. I think zswap was developed by IBM.
I think kernel samepage merging was developed by Red Hat.
https://lwn.net/Articles/551401/
https://lwn.net/Articles/545244/
https://lwn.net/Articles/330589/
But even with these redundancies, they are running out of large cat names to use and would have to go with the likes of "jaguarundi", "serval", and "manul" to keep the theme going. These are cool animals, but have nowhere near the emotive power that "Jaguar" or "Lion" had.