![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Design arrogance
Recently Yet Another Rantwar developed on an Apple dev mailing list about the lack of statically linked libraries on MacOS X... and it led to a great response.
On MacOS X, all libraries are dynamically linked at runtime. Static libraries, where the library code is copied into the final executable, just don't exist for any of the Apple supplied OS or UI code. This seriously bugs the hell out of some people, particularly those coming from Linux or Unix environments where you really have no idea what libraries may be installed on a user's machine. It's a way of ensuring that your app has what it needs, period.
Unfortunately, it has the side effect of making sure that your app doesn't get free updates of underlying libraries. Say you use a dozen libraries, and bugs are found in all of them, but the library developers are on different release cycles. You have to re-link all of the libraries into your app, to ship the update to your users. Do you...
a) wait for them all to release their libraries bug-free, then update?
b) push an update out to your users every time one of the underlying libraries gets updated?
If you chose a, you'll never update... at the very least, you'll update so rarely that your users will be constantly behind on the bug patches to the underlying libraries. When some of those libraries are, say, SSL or another security protocol, this becomes important to stay on top of.
If you chose b, your users will come to hate you. "What, *another one*??"
Most devs choose a middle ground, waiting for a few libraries to get patched, then rolling them into a big periodic update.
A way around this conundrum is dynamic libraries - the library is only linked in with the application when the app *launches*. When deploying on a known environment (like MacOS X), this is great, because you can be sure that the users have what you need. Better, when the library gets updated, *you* get updated, for free. (There's always a chance it will introduce a new bug, of course, but you don't have to recompile your app, and what's better, your users don't have to go get an update from you... but they get the updated behavior.) This is why, when Safari gets updated, *all* the apps on MacOS X that use the underlying HTML rendering library, WebKit, get the bug fixes, the enhanced behavior, and new widgets, for free. Everyone wins.
Apple chose to go the dynamic library route, because it makes updating applications just brain-dead simple. More to the point, they have been able to avoid the 'DLL hell' that Windows, and to a different extent, Unix and Linux systems have, with a nifty trick hoisted from NeXTstep: frameworks. A framework is a bundle that includes the libraries, headers, and other bits and pieces that a conceptual chunk of API needs... with invisible versioning. There's no version problem. The loader gets the right version of the libraries you need. Slicker than snot. (And it's only been around since 1987. One of my great disappointments with Eclipse is that they ran smack down DLL Hell Alley with their versioning, and created a completely avoidable plugins quagmire.)
But, given that a lot of devs coming from other platforms are (rightfully) wary of dynamic libraries, some insist on sticking with static libs. Which gets us to the periodic rant that pops up on MacOS X dev lists. "Why doesn't Apple give us static libraries?!?" Cries of fascism, nazis, arrogance, etc, get tossed about as you would expect.
The above explanation doesn't work, because this isn't a desire rooting in rationality, it's a legacy belief based on pre-existing experience that doesn't apply in the current environment. Sure, there are boundary cases where static libraries are preferred even on MacOS X, but I've yet to run into someone who *actually* had one of those occurring. However, for those who really, really, *REALLY* do need static libraries, Apple provides full details on how to create them yourself on their developer pages, starting with the foundational GNU crt0.o, and working your way up. Which is, really, kinda like working in Linux, pre-apt.
A pain? Yeah, it is. As one Apple engineer put it: "There IS an option for you to statically link, it's just BY DESIGN a big, fat, painful process" He went on to say "You want to work against the architectural design goals, fine, but don't expect anyone to make it easy for you, beyond telling you it's possible. It's a pain because we want to discourage people from doing it, for sound technical reasons."
And the punchline, IMO: "We'll let you shoot your foot off, but we're not going to sell you the bullets."
Apple design in a nutshell. Rarely does Apple go out of its way to *actively prevent* a user from going off the beaten path on their system or device... but they're not going to *help* you do it. ie, the iPhone. *Could* Apple lock down that puppy tighter than a drum, and prevent jailbreaking? Yeah, I kind of have to believe they could. They control the hardware, the firmware, and the OS. That they *haven't*, and what's more, that they have actively worked *around* jailbreaking with their updates, says to me that they really don't care that much. You can do it if you want, but don't go crying to them if it breaks something. Seems reasonable. It's the $5 padlock approach - for the average person, the light locks they put in place keep them from doing something ill-advised in their ignorance, while for the really determined knowledgeable folk, it's not really a barrier at all.
What I find interesting is that apparently the burning fundamental need to have static libraries is *so huge*... that no one has stepped up to provide a build system to do it easily. I dunno, maybe someone has, and I haven't found it in my tens of seconds of googling, but this seems to be an itch that not many people have a need to scratch.
Which kind of says to me... right design decision.
On MacOS X, all libraries are dynamically linked at runtime. Static libraries, where the library code is copied into the final executable, just don't exist for any of the Apple supplied OS or UI code. This seriously bugs the hell out of some people, particularly those coming from Linux or Unix environments where you really have no idea what libraries may be installed on a user's machine. It's a way of ensuring that your app has what it needs, period.
Unfortunately, it has the side effect of making sure that your app doesn't get free updates of underlying libraries. Say you use a dozen libraries, and bugs are found in all of them, but the library developers are on different release cycles. You have to re-link all of the libraries into your app, to ship the update to your users. Do you...
a) wait for them all to release their libraries bug-free, then update?
b) push an update out to your users every time one of the underlying libraries gets updated?
If you chose a, you'll never update... at the very least, you'll update so rarely that your users will be constantly behind on the bug patches to the underlying libraries. When some of those libraries are, say, SSL or another security protocol, this becomes important to stay on top of.
If you chose b, your users will come to hate you. "What, *another one*??"
Most devs choose a middle ground, waiting for a few libraries to get patched, then rolling them into a big periodic update.
A way around this conundrum is dynamic libraries - the library is only linked in with the application when the app *launches*. When deploying on a known environment (like MacOS X), this is great, because you can be sure that the users have what you need. Better, when the library gets updated, *you* get updated, for free. (There's always a chance it will introduce a new bug, of course, but you don't have to recompile your app, and what's better, your users don't have to go get an update from you... but they get the updated behavior.) This is why, when Safari gets updated, *all* the apps on MacOS X that use the underlying HTML rendering library, WebKit, get the bug fixes, the enhanced behavior, and new widgets, for free. Everyone wins.
Apple chose to go the dynamic library route, because it makes updating applications just brain-dead simple. More to the point, they have been able to avoid the 'DLL hell' that Windows, and to a different extent, Unix and Linux systems have, with a nifty trick hoisted from NeXTstep: frameworks. A framework is a bundle that includes the libraries, headers, and other bits and pieces that a conceptual chunk of API needs... with invisible versioning. There's no version problem. The loader gets the right version of the libraries you need. Slicker than snot. (And it's only been around since 1987. One of my great disappointments with Eclipse is that they ran smack down DLL Hell Alley with their versioning, and created a completely avoidable plugins quagmire.)
But, given that a lot of devs coming from other platforms are (rightfully) wary of dynamic libraries, some insist on sticking with static libs. Which gets us to the periodic rant that pops up on MacOS X dev lists. "Why doesn't Apple give us static libraries?!?" Cries of fascism, nazis, arrogance, etc, get tossed about as you would expect.
The above explanation doesn't work, because this isn't a desire rooting in rationality, it's a legacy belief based on pre-existing experience that doesn't apply in the current environment. Sure, there are boundary cases where static libraries are preferred even on MacOS X, but I've yet to run into someone who *actually* had one of those occurring. However, for those who really, really, *REALLY* do need static libraries, Apple provides full details on how to create them yourself on their developer pages, starting with the foundational GNU crt0.o, and working your way up. Which is, really, kinda like working in Linux, pre-apt.
A pain? Yeah, it is. As one Apple engineer put it: "There IS an option for you to statically link, it's just BY DESIGN a big, fat, painful process" He went on to say "You want to work against the architectural design goals, fine, but don't expect anyone to make it easy for you, beyond telling you it's possible. It's a pain because we want to discourage people from doing it, for sound technical reasons."
And the punchline, IMO: "We'll let you shoot your foot off, but we're not going to sell you the bullets."
Apple design in a nutshell. Rarely does Apple go out of its way to *actively prevent* a user from going off the beaten path on their system or device... but they're not going to *help* you do it. ie, the iPhone. *Could* Apple lock down that puppy tighter than a drum, and prevent jailbreaking? Yeah, I kind of have to believe they could. They control the hardware, the firmware, and the OS. That they *haven't*, and what's more, that they have actively worked *around* jailbreaking with their updates, says to me that they really don't care that much. You can do it if you want, but don't go crying to them if it breaks something. Seems reasonable. It's the $5 padlock approach - for the average person, the light locks they put in place keep them from doing something ill-advised in their ignorance, while for the really determined knowledgeable folk, it's not really a barrier at all.
What I find interesting is that apparently the burning fundamental need to have static libraries is *so huge*... that no one has stepped up to provide a build system to do it easily. I dunno, maybe someone has, and I haven't found it in my tens of seconds of googling, but this seems to be an itch that not many people have a need to scratch.
Which kind of says to me... right design decision.