I'd assume they don't want apps granting permission to other apps bypassing the security system. But we'll have to see.
"Granting permission" applies to sandboxed App Store apps, and the sandbox in which they run might well just block exec and posix_spawn calls completely. Apps that happen to be signed by an identified developer have the same permissions that unsigned apps do, so it's not as if there are other permissions to grant - all signing does is protect against the app being modified by some piece of malware (that would invalidate the signature) and let Apple flip the kill switch on it if they decide it should be killed because, for example, it turns out to be malware.
The kernel code to require all apps to be signed by Apple already exists.
...and it's not even clear whether that code is being used here. This might be done well above the exec/posix_spawn calls, just as the "you just downloaded this app from the Intertubes, do you really want to run it?" dialog is.
"Ask them. Ask them every time. Make them tell you to stop asking if they get tired of you asking."
Or just ask them the first time they try to run the app, and then, if they say "run it anyway, even if it's not from an identified developer", don't ask them again. I haven't seen anything to indicate how it behaves, but if it's anything like the quarantine stuff that's been there since Snow Leopard, it's probably "ask once".
My assumption is that this is couched in security, but is actually a deliberate inconvenience to make sure that application developers see a sales loss if they don't fall in line.
If you're talking about Mountain Lion, presumably by "fall in line" you mean "sign up for the Mac Developer Program at USD 99/year and get a signing key"; you obviously don't mean "start shipping your app through the App Store and paying Apple 30%", because the default setting is "allow App Store apps or apps signed by identified developers".
You miss the point. It's not about where it presently is, it's about where it seems likely to be headed. I wonder if you'll still defend Apple when/if they do start forcing you to jailbreak your computer before installing outside of the official store?
No, I wouldn't (and it doesn't seem likely to me to be headed that way). I, like John Gruber, think it'd be cool if these options want "back to iOS"; whether that'll happen is another matter. (Of course, one disadvantage to Apple of them doing that is that if it reduces the demand for jailbreaking enough, it'll reduce the number of third-party developers finding security holes for Apple, so they'll have to do more work themselves.:-))
so what my sex game that apple will put in the store why should my uses have to do jump though hoops to run it?
If you can afford USD 99/year for a Mac Developer Program membership, so you can get a signing key, they won't have to jump through hoops to run it unless they've explicitly told Gatekeeper to warn about non-App Store apps from identified developers.
Even TFS details cosmetic changes that make OSX 10.8 more like iOS.
ZOMG THEY SPLIT THE TO-DO LIST INTO ITS OWN APP AND RENAMED iChat to MESSAGES THE NEXT STEP IS HAVING TO PERSONALLY PLEAD WITH TIM COOK TO BE ALLOWED TO RUN AN APP!!!!!!1111ONE!!!!!!!!!
Considering that Steve Jobs said that he planned to lock down Macs (stated that iOS was the future of computing),
The two are inequivalent; I don't know exactly what he said (did he literally say "iOS is the future of computing", or did he say something else that some could interpret as meaning that?), but it could be that he said something that amounted to "most people would be fine with an iOS-style system, and the Mac is there for the people who need more" (which is what his "car vs. truck" statement amounted to).
go through the Mac App Store (which means your apps work with all settings for Gatekeeper);
go through the Mac App Store or register as an "identified developer" and get a key and sell the software however you want (which means your apps work with the default setting for Gatekeeper as well as the "run anything" setting);
do neither (which means your apps require that the user either set Gatekeeper to "run anything" or run your app by control-clicking and selecting Open - which I suspect only has to be done the first time it's run).
I.e., they do, for the Mac, have a choice to avoid the App Store.
I think that if you want to distribute outside the Mac store, then you can get an apple signature and the warning won't pop up.
The default setting is "Mac App Store and identified developers", so if you want to sell software that works with the default Mountain Lion setting, you can get a signing key and use that.
Note that the default, according to both Daring Fireball and MacWorld, is "App Store or identified developers", not "App Store only", so it's not as much of a lockdown as iOS by default.
requiring admin privileges to change,
Perhaps they're changing it in Mountain Lion, but the first user account created on a machine is given admin privileges by default. It's up to that user to, if they create accounts for other users, whether to trust those users to run arbitrary apps.
and no doubt coming with scary warnings about how you'll get hacked if you disable it.
In effect, it offers all the security benefits of the App Store, except for the process of approving apps by Apple. Users have three choices which type of apps can run on Mountain Lion:
Only those from the App Store
Only those from the App Store or which are signed by a developer ID
Any app, whether signed or unsigned
The default for this setting is, I say, exactly right: the one in the middle, disallowing only unsigned apps.
Being the default, it's as good as there being no other option, because users don't know enough to tell the difference.
"But what if you want to run an older app, or download a utility that was written by someone who hasn't paid Apple's $99 fee for a developer's license? If you're an administrative user, you can Ctrl-click on the App, choose Open from the pop-up menu, enter your OS X password, and tell Mountain Lion to trust this app in the future."
Or just fucking set "Allow applications downloaded from:" to "Anywhere". (At least according to Daring Fireball, the default setting is "Mac App Store and identified developers"; I'm curious whether that's also the default setting if you upgrade a machine, or if it defaults to "Anywhere" on an upgrade for the benefit of already-installed unsigned apps, or if it's using Quarantine so that it pesters you only for newly-downloaded apps. For that matter, I'm curious whether it's in the exec code, so that it vets all executable images, or if it's in Launch Services so that it only vets applications launched through LS.)
One step closer to all apps needing to come from the app store.
Or not. It might just be a heavier-duty version of the "warning when you first open a newly-downloaded application from the UI" stuff that's been there since at least Snow Leopard; the MacWorld article on Gatekeeper makes it look a bit like the latter.
I still wonder why Apple is hanging on to OSX (OS 10) when that are up to OS XVIII (18) now. Could it be that the big flying X when you start the computer looks really good and the flying XVIII would not?
And I still wonder why Solaris used to go from 2.{n} to 2.{n+1} and then started going from {n} to {n+1}, and Windows used to go from {n} to {m > n} and then went from {yy} to {yy} or {yyyy} and then went from {yyyy} to XP to Vista and then to 7 and then went back to going from {n} to {m > n} (with the OS version number reported to apps sticking at 6.{n} so that apps that don't try to gracefully adapt to the major version number don't shit their pants). (Not to mention NT starting out at version 3.1....)
In other words, OS version names are, to a large degree, bullshit dictated by marketing departments; don't try to apply reason to them.
Hear that, Microsoft? You could bundle a years worth of Windows Updates, give it a catty name, and sell it for $30! Wake up and smell the revenue!
The equivalents to "Windows Update" in [Mac] OS X are Security Updates and Software Updates, and both are free, just like Windows Updates, but thank you for sharing.
The OSX dock is unusable too. The fact that an app is running is indicated by a tiny dot under the icon. The fact that a second instance is running (rather difficult to do BTW) is indicated by a second icon located nowhere near the normal dock icon. You don't get a second dot. Seriously, WTF?
For better or worse, the Mac OS X model is "for a document-based application, one process handles all open documents, and, for non-document-based applications, one process handles everything", so running the same app in more than one process in one session is not expected to be a common case.
The ability to see, for example, a protocol or API spec and the code I'm working on that depends on them.
Maybe most people don't need that, but I do. Fortunately, I'm running an OS that doesn't force me to have only one full-screen window visible. (Yes, I'm being snarky; when Apple is allowing more user choice than you are - Lion allows you to run full-screen-capable apps full-screen, but it doesn't default to that - either you're a genius or an idiot. Which of those you are may depend on the user.:-))
And with the new MacOSX on ARM you'll have to buy ALL your software over again as it won't run on it, just like you had to when they switched from powerpc to x86..
No, you didn't, at least not until you upgraded to Lion.
In English there is a similar pattern to German, for instance. People will very frequently say things like "I'm teaching tomorrow" or "I'm grabbing donuts with my friend tomorrow morning."
Well, the latter of those might well explain the health differences.
Furthermore, in this decade we have seen research indicating that native speakers of tonal languages may be more likely to develop the musical skill known as "perfect pitch". (Short version here). If the very tonal structure of a language can dramatically shape the brain's ability to acquire/process/interpret/sort tones in general, can we so easily scoff at the possibility that the semantic structure of a language might shape the brain's ability to acquire/process/interpret/sort concepts in general?
People are healthier in Germany? Maybe because Germany has universal health care.
Which, of course, noEnglish-speakingcountry has. (And if you want to quibble about those being English-speaking countries, either you're being snarky about the variants of English spoken there, in which case you should be ignored, or you're talking about the second of the countries listed there, where English is one of the official languages, and the other one is also a "strong-FTR" language, to use Chen's terminology, just as English is.)
The less code one has to directly translate into a new assembly language, the lesser are the chances of buggy code. With a microkernel OS, only the microkernel code needs to be translated into assembly
Presumably you mean "translated from one assembly language into another assembly language".
since userland is all calls to the microkernel.
I'm not sure what "userland is all calls to the microkernel" means here.
You obviously can't mean that there is nothing in userland but calls to the microkernel, as that would require the "micro"kernel to include all the functionality that's actually does useful work, which would render it far from "micro".
If you mean that all the calls to the microkernel are from userland, that's probably true, but tautologically so if you have just the microkernel and userland - any call to a microkernel from within the microkernel isn't a call "to" the microkernel.
However, in any case, whilst there's little code in userland that is required to be assembler-language code, some low-level code is often in assembler language, such as memory copy and string manipulation routines. If you meant that userland would call into the microkernel for all operations whose implementations are written in assembler, I see no point in putting those routines into the microkernel and requiring a change of privilege - they don't require kernel-mode privileges.
As for non-microkernel OSes, it's not as if all kernel code is necessarily assembler language, so it's not as if a bigger kernel ipso facto means more assembler-language code.
It is not directly tied to the size of userland, but rather, how much of assembly code is involved.
And it's not tied to microkernel vs. non-microkernel, either.
With NT, that kernel kept growing, so that more code had to be ported,
The former does not imply the latter. Kernel code is not ipso facto non-portable code (having written my share of code that runs in kernel mode, I can state that for certain).
Also, when some assembly code is included for certain routines, that increases the non-portability of the OS. NT did include more assembly code while going from 4.0 to 2000.
Was that additional assembly code all kernel code?
Problem was that while NT was a hybrid architecture to start with, more and more things were moved from user to kernel when NT went from 3.1 to 3.5 to 4.0. As a result, unlike NEXTSTEP, NT became less portable.
It's not as if running in userland magically makes code more portable. Most of XNU and the associated kexts are portable; the non-portable bits sit in places such as subdirectories of and some of the subdirectories of the osfmk directory. And as for userland, the platform-specific bits of the "libc" part of libSystem sit in subdirectories of the top-level directory in the Libc project, and the non-portable bits of the run-time linker are #ifdeffed in files such as dyld_stub_binder.s.
I believe it uses the Mach microkernel, and therfore can be ported quite quickly
At this point, XNU probably isn't significantly easier to port to another architecture than, say, the Linux kernel or one of the *BSD kernels or the SunOS 5.x kernel. (And, in any case, XNU's already been ported to ARM, as have the other userland bits of Darwin; that's what iOS is built atop. What he did was port the ARM version of Darwin to a new piece of hardware - one that had an ARMv5 processor, which required, among other things, cleaning up some bitrot in the ARMv5 support. Read The Fine Thesis.)
Slashdot Mirror
I'd assume they don't want apps granting permission to other apps bypassing the security system. But we'll have to see.
"Granting permission" applies to sandboxed App Store apps, and the sandbox in which they run might well just block exec and posix_spawn calls completely. Apps that happen to be signed by an identified developer have the same permissions that unsigned apps do, so it's not as if there are other permissions to grant - all signing does is protect against the app being modified by some piece of malware (that would invalidate the signature) and let Apple flip the kill switch on it if they decide it should be killed because, for example, it turns out to be malware.
The kernel code to require all apps to be signed by Apple already exists.
...and it's not even clear whether that code is being used here. This might be done well above the exec/posix_spawn calls, just as the "you just downloaded this app from the Intertubes, do you really want to run it?" dialog is.
"Ask them. Ask them every time. Make them tell you to stop asking if they get tired of you asking."
Or just ask them the first time they try to run the app, and then, if they say "run it anyway, even if it's not from an identified developer", don't ask them again. I haven't seen anything to indicate how it behaves, but if it's anything like the quarantine stuff that's been there since Snow Leopard, it's probably "ask once".
My assumption is that this is couched in security, but is actually a deliberate inconvenience to make sure that application developers see a sales loss if they don't fall in line.
If you're talking about Mountain Lion, presumably by "fall in line" you mean "sign up for the Mac Developer Program at USD 99/year and get a signing key"; you obviously don't mean "start shipping your app through the App Store and paying Apple 30%", because the default setting is "allow App Store apps or apps signed by identified developers".
You miss the point. It's not about where it presently is, it's about where it seems likely to be headed. I wonder if you'll still defend Apple when/if they do start forcing you to jailbreak your computer before installing outside of the official store?
No, I wouldn't (and it doesn't seem likely to me to be headed that way). I, like John Gruber, think it'd be cool if these options want "back to iOS"; whether that'll happen is another matter. (Of course, one disadvantage to Apple of them doing that is that if it reduces the demand for jailbreaking enough, it'll reduce the number of third-party developers finding security holes for Apple, so they'll have to do more work themselves. :-))
so what my sex game that apple will put in the store why should my uses have to do jump though hoops to run it?
If you can afford USD 99/year for a Mac Developer Program membership, so you can get a signing key, they won't have to jump through hoops to run it unless they've explicitly told Gatekeeper to warn about non-App Store apps from identified developers.
Even TFS details cosmetic changes that make OSX 10.8 more like iOS.
ZOMG THEY SPLIT THE TO-DO LIST INTO ITS OWN APP AND RENAMED iChat to MESSAGES THE NEXT STEP IS HAVING TO PERSONALLY PLEAD WITH TIM COOK TO BE ALLOWED TO RUN AN APP!!!!!!1111ONE!!!!!!!!!
Considering that Steve Jobs said that he planned to lock down Macs (stated that iOS was the future of computing),
The two are inequivalent; I don't know exactly what he said (did he literally say "iOS is the future of computing", or did he say something else that some could interpret as meaning that?), but it could be that he said something that amounted to "most people would be fine with an iOS-style system, and the Mac is there for the people who need more" (which is what his "car vs. truck" statement amounted to).
Personally, I agree with John "Daring Fireball" Gruber when he says about the Gatekeeper options "Call me nuts, but that’s one feature I hope will someday go in the other direction — from OS X to iOS.". Whether that'll happen is another matter.
Well it's not like devs have much choice.
Yeah, the only choices they have are:
I.e., they do, for the Mac, have a choice to avoid the App Store.
I think that if you want to distribute outside the Mac store, then you can get an apple signature and the warning won't pop up.
The default setting is "Mac App Store and identified developers", so if you want to sell software that works with the default Mountain Lion setting, you can get a signing key and use that.
Yep. It's time you Export yourself outside the walled garden. It'll be a strange feeling for a few months. But boy is it liberating.
I.e., by opening up System Preferences, going to the Security pane, and setting "Allow applications downloaded from:" to "Anywhere"? (Or were you talking about iOS, which unfortunately lacks that option?)
By being default-enabled,
Note that the default, according to both Daring Fireball and MacWorld, is "App Store or identified developers", not "App Store only", so it's not as much of a lockdown as iOS by default.
requiring admin privileges to change,
Perhaps they're changing it in Mountain Lion, but the first user account created on a machine is given admin privileges by default. It's up to that user to, if they create accounts for other users, whether to trust those users to run arbitrary apps.
and no doubt coming with scary warnings about how you'll get hacked if you disable it.
Yes, although the warning also tells you how to override the option on a per-app basis.
This, pretty much. The OS is set to, by default, spread FUD about apps not coming from the App Store.
Or, if John Gruber's claim is correct, the OS is set to, by default, spread FUD about apps coming neither from the App Store nor from identified developers :
Being the default, it's as good as there being no other option, because users don't know enough to tell the difference.
Hopefully the dialog that pops up when you try to launch an app not in the category specified by the setting will also point you to the setting for changing that behavior. (That article also says the default is "App Store or identified developer.)
"But what if you want to run an older app, or download a utility that was written by someone who hasn't paid Apple's $99 fee for a developer's license? If you're an administrative user, you can Ctrl-click on the App, choose Open from the pop-up menu, enter your OS X password, and tell Mountain Lion to trust this app in the future."
Or just fucking set "Allow applications downloaded from:" to "Anywhere". (At least according to Daring Fireball, the default setting is "Mac App Store and identified developers"; I'm curious whether that's also the default setting if you upgrade a machine, or if it defaults to "Anywhere" on an upgrade for the benefit of already-installed unsigned apps, or if it's using Quarantine so that it pesters you only for newly-downloaded apps. For that matter, I'm curious whether it's in the exec code, so that it vets all executable images, or if it's in Launch Services so that it only vets applications launched through LS.)
One step closer to all apps needing to come from the app store.
Or not. It might just be a heavier-duty version of the "warning when you first open a newly-downloaded application from the UI" stuff that's been there since at least Snow Leopard; the MacWorld article on Gatekeeper makes it look a bit like the latter.
I still wonder why Apple is hanging on to OSX (OS 10) when that are up to OS XVIII (18) now. Could it be that the big flying X when you start the computer looks really good and the flying XVIII would not?
And I still wonder why Solaris used to go from 2.{n} to 2.{n+1} and then started going from {n} to {n+1}, and Windows used to go from {n} to {m > n} and then went from {yy} to {yy} or {yyyy} and then went from {yyyy} to XP to Vista and then to 7 and then went back to going from {n} to {m > n} (with the OS version number reported to apps sticking at 6.{n} so that apps that don't try to gracefully adapt to the major version number don't shit their pants). (Not to mention NT starting out at version 3.1....)
In other words, OS version names are, to a large degree, bullshit dictated by marketing departments; don't try to apply reason to them.
Hear that, Microsoft? You could bundle a years worth of Windows Updates, give it a catty name, and sell it for $30! Wake up and smell the revenue!
The equivalents to "Windows Update" in [Mac] OS X are Security Updates and Software Updates, and both are free, just like Windows Updates, but thank you for sharing.
The OSX dock is unusable too. The fact that an app is running is indicated by a tiny dot under the icon. The fact that a second instance is running (rather difficult to do BTW) is indicated by a second icon located nowhere near the normal dock icon. You don't get a second dot. Seriously, WTF?
For better or worse, the Mac OS X model is "for a document-based application, one process handles all open documents, and, for non-document-based applications, one process handles everything", so running the same app in more than one process in one session is not expected to be a common case.
And what do multiple windows really give you?
The ability to see, for example, a protocol or API spec and the code I'm working on that depends on them.
Maybe most people don't need that, but I do. Fortunately, I'm running an OS that doesn't force me to have only one full-screen window visible. (Yes, I'm being snarky; when Apple is allowing more user choice than you are - Lion allows you to run full-screen-capable apps full-screen, but it doesn't default to that - either you're a genius or an idiot. Which of those you are may depend on the user. :-))
And with the new MacOSX on ARM you'll have to buy ALL your software over again as it won't run on it, just like you had to when they switched from powerpc to x86..
No, you didn't, at least not until you upgraded to Lion.
In English there is a similar pattern to German, for instance. People will very frequently say things like "I'm teaching tomorrow" or "I'm grabbing donuts with my friend tomorrow morning."
Well, the latter of those might well explain the health differences.
Furthermore, in this decade we have seen research indicating that native speakers of tonal languages may be more likely to develop the musical skill known as "perfect pitch". (Short version here). If the very tonal structure of a language can dramatically shape the brain's ability to acquire/process/interpret/sort tones in general, can we so easily scoff at the possibility that the semantic structure of a language might shape the brain's ability to acquire/process/interpret/sort concepts in general?
Are you assuming here that the tonal structure of the language is shaping the brain, rather than the brain shaping whether the language is tonal or not? It's possible that genes that affect brain development can predispose populations towards tonal or non-tonal languages; could those genes also affect the ability to develop perfect pitch? (I.e., "A correlates with B" does not ipso facto imply "A causes B"; B could cause A, or C could cause both A and B.)
People are healthier in Germany? Maybe because Germany has universal health care.
Which, of course, no English-speaking country has. (And if you want to quibble about those being English-speaking countries, either you're being snarky about the variants of English spoken there, in which case you should be ignored, or you're talking about the second of the countries listed there, where English is one of the official languages, and the other one is also a "strong-FTR" language, to use Chen's terminology, just as English is.)
Sounds like the return of the Sapir-Whorf hypothesis
Captcha: "nonsense".
...which The Fine Paper mentions.
The less code one has to directly translate into a new assembly language, the lesser are the chances of buggy code. With a microkernel OS, only the microkernel code needs to be translated into assembly
Presumably you mean "translated from one assembly language into another assembly language".
since userland is all calls to the microkernel.
I'm not sure what "userland is all calls to the microkernel" means here.
You obviously can't mean that there is nothing in userland but calls to the microkernel, as that would require the "micro"kernel to include all the functionality that's actually does useful work, which would render it far from "micro".
If you mean that all the calls to the microkernel are from userland, that's probably true, but tautologically so if you have just the microkernel and userland - any call to a microkernel from within the microkernel isn't a call "to" the microkernel.
However, in any case, whilst there's little code in userland that is required to be assembler-language code, some low-level code is often in assembler language, such as memory copy and string manipulation routines. If you meant that userland would call into the microkernel for all operations whose implementations are written in assembler, I see no point in putting those routines into the microkernel and requiring a change of privilege - they don't require kernel-mode privileges.
As for non-microkernel OSes, it's not as if all kernel code is necessarily assembler language, so it's not as if a bigger kernel ipso facto means more assembler-language code.
It is not directly tied to the size of userland, but rather, how much of assembly code is involved.
And it's not tied to microkernel vs. non-microkernel, either.
With NT, that kernel kept growing, so that more code had to be ported,
The former does not imply the latter. Kernel code is not ipso facto non-portable code (having written my share of code that runs in kernel mode, I can state that for certain).
Also, when some assembly code is included for certain routines, that increases the non-portability of the OS. NT did include more assembly code while going from 4.0 to 2000.
Was that additional assembly code all kernel code?
Problem was that while NT was a hybrid architecture to start with, more and more things were moved from user to kernel when NT went from 3.1 to 3.5 to 4.0. As a result, unlike NEXTSTEP, NT became less portable.
It's not as if running in userland magically makes code more portable. Most of XNU and the associated kexts are portable; the non-portable bits sit in places such as subdirectories of and some of the subdirectories of the osfmk directory. And as for userland, the platform-specific bits of the "libc" part of libSystem sit in subdirectories of the top-level directory in the Libc project, and the non-portable bits of the run-time linker are #ifdeffed in files such as dyld_stub_binder.s.
I believe it uses the Mach microkernel, and therfore can be ported quite quickly
At this point, XNU probably isn't significantly easier to port to another architecture than, say, the Linux kernel or one of the *BSD kernels or the SunOS 5.x kernel. (And, in any case, XNU's already been ported to ARM, as have the other userland bits of Darwin; that's what iOS is built atop. What he did was port the ARM version of Darwin to a new piece of hardware - one that had an ARMv5 processor, which required, among other things, cleaning up some bitrot in the ARMv5 support. Read The Fine Thesis.)