Post a Comment
Looks like a lot of the use of the word "binary" in the summary is inaccurate - since it appears a large percentage of the crap removed as stuff OTHER than the actual compiled binary.
Why not use the term "bundle" as the linked article does? This seems to be a more accurate description of what is going on.
if similar changes were made to the printer drivers - it's ridiculous to have 2.1 gigs of printer drivers, much less a third of that being nothing but Epson.
The not removing unused elements of the library in the linker would explain a lot about the heft of OSX. Given that the applications on the whole tend to be self contained packaging all elements of a library, even those that are unused would indeed be unneccessary bloat - but an easy thing for a programmer who doesn't even understand what a linker IS to miss.
Edited 2008-06-28 00:13 UTC
Just to be clear about one idea flying around recently.
Applications bundles on OS X DO NOT duplicate any system libraries (more generally called framework), absolutely not. If an application needs to have its custom frameworks then it does put in its bundle, but the system framework are not duplicated in the bundles.
What do yo mean unused elements of the library? Which library?
Frameworks are dynamically linked to the executable, they are not added to the executable. So what's your point?
What do you packaging all elements of a library?
Again frameworks are contained in one location /System/Library/Frameworks
there is no packaging or whatsoever. Again, besides its custom frameworks, an application bundle does not contain any other duplication of the system frameworks.
What are NIB files but a library file included at packaging? How is the packaging process any different from a linker when it comes to condensing a bunch of separate files into the same 'file' - it's the same concept. (Closest comparison windows side would be a resource file or set of resource files compiled to a DLL)
Including unused NIB's in the package is the same as including unused DLL's in a .msi or compiling unused libraries into an executable.
That they are packaged into the same distributable 'file' though means it could incur slowdowns, as package files are basically handled as a filesystem and it's more files to wade through trying to get to the ones that are actually being used. The slowdowns from this could be compared to the old interpreted BASIC days where you could speed up some programs and make them practical to exchange at 150 baud just by deleting a few REM statements and trimming unused subroutines - stuff that was/is good during development but has no place in a distribution.
Edited 2008-06-28 08:29 UTC
WTF?! I was using Monolingual (thanks for reminding me btw, I already had it but forgot about it) and was removing languages and they had an entry for klingon. Do they seriously have an entry fo klingon? How pathetic do you have to be to learn a fictional language and use it on your machine daily. Do they have all of the Lord of The Rings languages as well?
Support for Klingon in Mac OS makes perfect sense. Historical sense. Read:
http://lowendmac.com/orchard/05/star-trek-mac-os-intel.html
I know my apps the binaries are very small. However to make it look just right I use a lot of high resolution graphics. Lossy compression only makes it look bad. So I put the lossless high resolution graphics. Sure it takes up space but it makes my customers happy, and my customers pay the bills. There are rumors that Apple are going to use Video hardware acceleration to the next level Vector Graphics 2.0 which could account for a good file saving.
Xslimmer works really well. It's $13 US but it's worth it. Takes out all the extra junk like languages you don't need and also makes all apps processor specific.
So if you are on an Intel Mac you don't need any code for PPC. Xslimmer will remove all that from almost all applications.
Made everything on my white Imac (In Leopard) work much faster. (Apps start faster and it freed up like 2 GB of space)
It may be a placebo effect but from my personal experience before I slimmed apps on my computer most apps on leopard would have that stupid blinking light that would blink on the dock 5 or six times before the app would open.
Now most apps are one or two blinks and they are up and running.
Long as my mind is happy with it, I am good to go. LOL!
A myth?? Xslimmer works very well and does speed things up on my MacBook. Loading FireFox, iTune, Entourage is much faster after slimming them down.
The OS feel snappyer now than it was before.
I feel sorry for the Xslimmer devs, I wonder if this app will still have it's place with Snow Leopard.
The OS feel snappyer now than it was before.
I feel sorry for the Xslimmer devs, I wonder if this app will still have it's place with Snow Leopard.
Definitely not, if apple is really serious about optimization then it is definiteyl going the route of doing the easier tasks first. Which means stripping out the unneeded code and adding something similar for third party apps.
Yeah, and the thing is, XSlimmer really does reduce apps by about half their size *by getting rid of the PPC part*. However, this only seems to be the case for certain apps, mostly non-Apple ones. Maybe the added size for PPC binaries is a lot bigger for Carbon apps than for Cocoa.
When using Xslimmer on my mac it worked just as well on universal Apple apps just as well as on non Apple Apps.
For instance on Quick time 7.4.5 It was 29.1 MB and it was slimmed down to 7.23 MB
For Safari 3.1.1 Was 65.7 MB now it's 7.59 MB
For Address Book was 58.2 MB but now it's 4.46 MB
For IMovie it was 119 MB now it's 60.5 MB
For Iphoto it was 211 MB now its 82.3 MB
For Itunes it was 137 MB now its 34.4 MB
So my Apple apps seemed to of slimmed down pretty good.
For instance on Quick time 7.4.5 It was 29.1 MB and it was slimmed down to 7.23 MB
For Safari 3.1.1 Was 65.7 MB now it's 7.59 MB
For Address Book was 58.2 MB but now it's 4.46 MB
For IMovie it was 119 MB now it's 60.5 MB
For Iphoto it was 211 MB now its 82.3 MB
For Itunes it was 137 MB now its 34.4 MB
So my Apple apps seemed to of slimmed down pretty good.
The reduction comes mainly from localization packages being stripped.
The executable is already small and dynamically loads the localization package configured from your System Settings.
The real change will be when much of Apple's design around their bundles and interaction with various level of frameworks adjust for Cocoa versions of their flagship applications and standard OS applications.
Being a NeXT Alum, OS X 10.6 is the first release that will be what we discussed in 1997/98--Cocoa OS X.
Too bad it only took a decade to silence the Mac faithful who wouldn't have an OS today to cling to if it weren't for the merger.
You know, for a company that prides itself on "hardware hardware hardware", Apple sure knows how to dip it's collective feet in the software racket. Is Ballmer giving tips to Jobs?
This release is nothing more than OS optimizations that should have been done at the time Leopard was released, or at some point along the life cycle. It's hardly a major rev that requires a $129 expenditure from even the most zealous of fanboys.
There are going to be a lot more changes other then slimming down apps.
Most of the slimming of apps are the fact that it seems Snow Leopard is going to be Intel only anyway.
But there are a lot more underling changed being made to security, and almost all the underlying technology.
I think that 129 is a little pricy though.
This release is nothing more than OS optimizations that should have been done at the time Leopard was released, or at some point along the life cycle. It's hardly a major rev that requires a $129 expenditure from even the most zealous of fanboys.
So use Linux if you have an aversion to paying for software. Or just stick with the version you are currently using if it works?
All software upgrades are incremental. That's the nature of *any* product development. You get one huge revolutionary upgrade once every so often, and then the subsequent upgrades are all incremental evolutionary ones. Look at cars (lol, another car analogy). All Fords should be free, since everything they're bringing out should have been in the original model T anyway.
"This release is nothing more than OS optimizations that should have been done at the time Leopard was released, or at some point along the life cycle. It's hardly a major rev that requires a $129 expenditure from even the most zealous of fanboys."
I am glad Apple figured this one out. I've been using Xslimmer, deleting useless font families, adding the Liberation font family and performing other minor things which annoy me.
"So use Linux if you have an aversion to paying for software. Or just stick with the version you are currently using if it works?
I use open or free more-often-than-not and pay a programmer when their software is excellent. Either way, I am contributing to both to free choice and a free market.
Good lord the Microsoft animation on this page is annoying as hell.
Edited 2008-06-28 17:36 UTC
Ok, then explain to me what technology is so new in 10.6 that warrants the pricetag? They're deleting fonts, drivers, and removing backwards compatibility with PPC. I'd say that makes a nice 10.5.6, but not 10.6. Maybe they've got some other newfangled software tech up their sleeves....who knows. All I'm saying is the list of "changes" reads like a Windows service pack, as it stands today.
Wait, did I miss where Apple released the price of 10.6? I'm not saying they won't charge $129 for it, but it's also possible that they may offer it at a reduced cost to those that already purchased Leopard (maybe those software update coupons will be useful for once). I guess we'll know more at MacWorld in January.
Somehow this strikes me as very funny, seeing the savings that are coming from compressing the XML files. The only difference between a Z/gz/bz2 xml file and a binary config is that you might be able to unzip and human-parse the former. Next thing you know, they'll be using ODF!
Whitespace is a bitch.
:-)
Maybe they'll be using a "Binary XML" format, which is fast and easily parsable, as well as being able to be transparently opened and edited by XML editors (provided they support the file format).
http://en.wikipedia.org/wiki/Efficient_XML_Interchange
That looks pretty cool, actually, and I wouldn't put it beyond Apple to use something that isn't necessarily a fully developed standard in their products. At the same time, Occam says they just compressed the existing formats.
Still, this issue is something I've been thinking about lately, having had to dig more into Active Directory GPOs on a project I'm tasked to at work. While I had always viewed the Windows registry as just an annoyance in the past, when I had to modify a policy that was a stored registry value, the speed of parsing became very apparent to me. My colleague, who doesn't have any programming background beyond VB, couldn't wrap his head around why there was one registry value for a bunch of different things. It's like, it's a lot easier and quicker to parse if it's one binary value! :-)
Convert human-readable (and editable) configuration files into a proprietary binary format and call it a feature...
Seriously, while the ability to only install the localizations and platform binaries needed on your machine would be nice (and, as I recall from playing with NeXT in VMware, was a feature present in the pre-Mac versions of the OS) the amount of space savings gained from moving from human-readable (and modifiable) plists to binary ones is SO minimal thatI suspect the real reason their doing so is to make life harder for the OSX86 crowd, who often have to edit the plists of control panels and drivers in order to get stuff working on their frankenboxen.




. Thanks!