Apple Announces Mac OS X 'Mavericks'
macrumors.com
macrumors.com
;)
(Things called maverick which are not operating systems are irrelevant for that!)
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. :)
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.
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.
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.
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.
[1] https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_%26_W...
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.
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/
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.
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.
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"
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
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
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.