OK this is pretty basic computer science people. I have the Snow Leopard preview but I'm not going to break NDA. However, I will go on a road of self discovery and enlightenment with ya'll together.
As was stated earlier, executable code is a very small portion of an application's disk footprint. Take Mail.app for example in Leopard:
du -h /Applications/Mail.app
<snip>
289M\t/Applications/Mail.app
Mail.app takes up a whopping 289MB. This is a MacBook Pro, basically fresh off the truck from China and updated to 10.5.3. Now, look at the executable:
du -h /Applications/Mail.app/Contents/MacOS/Mail
5.7M\t/Applications/Mail.app/Contents/MacOS/Mail
The Mail executable is 5.7MB, or 1.97% of the overall footprint. Even if LLVM and all the other "compiler magic" (oy) in Snow Leopard reduced the executable to a measly 4K (impossible given the Mach headers, static data and load commands alone would be more than that), the bundle would still be around 284 MB.
So let's look at the resources. The real heft is in Resources:
du -h /Applications/Mail.app/Contents/Resources
279M\t/Applications/Mail.app/Contents/Resources/
So 279MB, or 98% of the footprint, is taken up by resources. Which resources then?
du -h /Applications/Mail.app/Contents/Resources/ | sort
So to take an educated guess: Snow Leopard will dramatically reduce the footprint of the operating system by only installing one localization--the localization choosen by the user when they boot from the CD and choose which language to use for the installer. Other languges will be on the install disk as an Optional install. Perhaps some images will be replaced by PDF and other vector art, but bearing in mind that vector art is still much more expensive to render, and Apple has typically discouraged that route except for very simple graphics (look at the Apple Icon Guidelines), I still assert almost all the savings will come from installing fewer resources.
Or better yet, have a Framework of Localization Nibs dylib'd in when needed upon loading your application, based upon the localization settings for the User.
Or better yet, have a Framework of Localization Nibs dylib'd in when needed upon loading your application, based upon the localization settings for the User.
I was thinking about that as an option, too. There would be localizations aspects that would not be found in localization.framework, but it seems like there is a lot of redundant data from app to app.
I was thinking about that as an option, too. There would be localizations aspects that would not be found in localization.framework, but it seems like there is a lot of redundant data from app to app.
It does? You should take a look sometime. There is actually very little redundant data that is of any size. Look at the resources in Mail again and compare them to iChat. The nib files are not even close to eachother. If you think that nib files are commonly shared, you have obviously never used a nib file.
Anyway, the whole point of my post was that Apple is NOT doing anything uber-cool with LLVM and NSA-powered optimization techniques to magically make executables super-small. I was pointing out that it's just impossible if you do the math on the Resources folder(s). Without having Apple legal knock on my doors, I can say that you can piece it together by reading the posts above without having to even have a copy of Snow Leopard--R.I.P. .nib, hello .xib. As I said before, nib files are the largest space gobblers, and in SL "they are installing fewer resources", no magic Localization framework required.
Funny how that original posting has been deleted but people are still quoting from it...
Quote:
So to take an educated guess: Snow Leopard will dramatically reduce the footprint of the operating system by only installing one localization--the localization choosen by the user when they boot from the CD and choose which language to use for the installer. Other languges will be on the install disk as an Optional install. Perhaps some images will be replaced by PDF and other vector art, but bearing in mind that vector art is still much more expensive to render, and Apple has typically discouraged that route except for very simple graphics (look at the Apple Icon Guidelines), I still assert almost all the savings will come from installing fewer resources..
I still don't understand why they are suddenly doing this now. Why was the default install set up to install every language under the sun? I can appreciate that one computer may be shared between users of two or maybe three languages, but all of them?
One of my wife's co-workers has a last name spelled "Taht". It was almost impossible for anyone to write him a letter in a Microsoft application without it coming through as "That".
If I knew someone named Taht, I would simply remove Taht from the auto-correct list in Word. Problem solved.
That would be nice. I don't think it would be too hard to create a deamon that would monitor what files/folders are created by an app while it's running, that would then create a small DB of the apps that would delete the appropriate files.
Receipts already have this. Anyone who uses Apple's installer can make use of this.
It does? You should take a look sometime. There is actually very little redundant data that is of any size. Look at the resources in Mail again and compare them to iChat. The nib files are not even close to eachother. If you think that nib files are commonly shared, you have obviously never used a nib file.
Anyway, the whole point of my post was that Apple is NOT doing anything uber-cool with LLVM and NSA-powered optimization techniques to magically make executables super-small. I was pointing out that it's just impossible if you do the math on the Resources folder(s). Without having Apple legal knock on my doors, I can say that you can piece it together by reading the posts above without having to even have a copy of Snow Leopard--R.I.P. .nib, hello .xib. As I said before, nib files are the largest space gobblers, and in SL "they are installing fewer resources", no magic Localization framework required.
Individual nib files may not share much of the same data, but they share much of the same behavior and using a central RDBMS ala SQLite that has a custom interface to interact with IB and work with Localization content, xml plist files, etc., can be abstracted as can much of IB once Carbon is gone.
NeXTSTEP applications weren't abhorrent pigs and yet we did have a good dozen localization options per release.
We didn't do the all resources thrown in our bundle solution, but then NeXTSTEP didn't have Carbon to huck it up.
Taking a page out of Redmond's handbook for once, Snow Leopard will also leverage text processing features originally conceived by Microsoft as features for Word.
That, in a nutshell, it what's wrong with virtually every word processing and text application around. Whether for Macs, Windows or Linux, they're all following Microsoft's lead, adding silly, clumsy, bothersome features simply because Microsoft put those features in Word.
There's a lot Apple could do to improve the text-handing abilities of OS X that don't require slavishly imitating Microsoft. Suggestions include:
1. Building in GREP search and replace. I use it with InDesign and it's absolutely amazing what it can do. The code is probably open source. Put it into OS X and every text application could tap the power.
2. Almost no one uses named styles in Word because it's so badly done. But done right, named styles (paragraph and character) save a lot of time. Users want it. Virtually every full-featured commercial text application supports it. Almost none of the more innovative 'shareware' applications do, because creating it from scratch requires more time and cost to implement than they can afford. Apple needs to build named styles into OS X, doing it right, and allow them to be cut and pasted between applications. When I cut and paste between Word and InDesign, I don't want the Word formatting to come along. I want the distinction between headings and body text to be maintained.
3. There's useful open source OCR software out there. OS X has speech recognition. It needs to add text recognition. Let us scan or take a picture of some text and easily convert to text as easily as OS X does text to speech.
If I knew someone named Taht, I would simply remove Taht from the auto-correct list in Word. Problem solved.
Better yet: having the auto-correct and spelling infrastructure know about your contacts, so that it automatically accepts those spellings as correct. The information is already in the system, it should leverage what you've already told it.
Newton did this, iPhone does this, no reason why Mac can't do it as well.
The observed smaller application footprint is definitely not from resolution independence. More likely missing localizations or ZFS's smaller minimum file size.
That, in a nutshell, it what's wrong with virtually every word processing and text application around. Whether for Macs, Windows or Linux, they're all following Microsoft's lead, adding silly, clumsy, bothersome features simply because Microsoft put those features in Word.
There's a lot Apple could do to improve the text-handing abilities of OS X that don't require slavishly imitating Microsoft. Suggestions include:
1. Building in GREP search and replace. I use it with InDesign and it's absolutely amazing what it can do. The code is probably open source. Put it into OS X and every text application could tap the power.
2. Almost no one uses named styles in Word because it's so badly done. But done right, named styles (paragraph and character) save a lot of time. Users want it. Virtually every full-featured commercial text application supports it. Almost none of the more innovative 'shareware' applications do, because creating it from scratch requires more time and cost to implement than they can afford. Apple needs to build named styles into OS X, doing it right, and allow them to be cut and pasted between applications. When I cut and paste between Word and InDesign, I don't want the Word formatting to come along. I want the distinction between headings and body text to be maintained.
3. There's useful open source OCR software out there. OS X has speech recognition. It needs to add text recognition. Let us scan or take a picture of some text and easily convert to text as easily as OS X does text to speech.
GREP is built-in to every UNIX system for the past 2 plus decades.
NeXT had a very nice implementation available for applications.
Autocorrect is an untter pain-in-the-ass. I turn it off in every application I use. I'm writing more than one novel so there is no way in hell I want it on, especially whether I'm using a direct LaTeX editor or something like LyX.
Indeed. Like some people have said, Microsoft made this terrible feature popular. 'Popular' because people naively use it thinking it's ok for it to make occasional mistakes or 'popular' because its foisted upon the user without a clear and easy way to disable it for novice users. Either way, popular features does not automatically mean it is good. In this case it's bad.
For a tool to be considered excellent, it has to work with 100% accuracy. Imagine if a screwdriver had a 95% accuracy. You turn it clockwise and the screw would dig into a surface 95% of the time, but there's a 5% chance that it instead pulls out of the surface. Of course, this couldn't be...or wouldn't be acceptable. This is why the screwdriver is an excellent tool for the job of driving a screw into a soft surface. It works 100% of the time (barring no user error...attempts by the tool to prevent user error is simply icing on the cake. As long as the tool works 100% when no user error is made, it's an excellent tool).
A tool must work 100% of the time to be considered excellent. If it doesn't work 100% of the time...it's not the right tool for the job since there a chance that it becomes counter-productive. And that counter-productivity can cancel some or all of the productivity brought by the time that the tool actually does work.
This is why autocorrect fails as a tool. Barring no user error, the tool does *not* work 100% of the time. It has to take a guess. And I'm sure that mdriftmeyer and other people can attest that the time spent coaxing the tool to work like it should destroys any benefits that it might bring otherwise.
A tool must work 100% of the time to be considered excellent. If it doesn't work 100% of the time...it's not the right tool for the job since there a chance that it becomes counter-productive. And that counter-productivity can cancel some or all of the productivity brought by the time that the tool actually does work.
This is why autocorrect fails as a tool. Barring no user error, the tool does *not* work 100% of the time. It has to take a guess. And I'm sure that mdriftmeyer and other people can attest that the time spent coaxing the tool to work like it should destroys any benefits that it might bring otherwise.
There's an important caveat to this: autocorrect is important and desirable on the iPhone because text entry itself is heuristic. You can't touch-type.
Autocorrect has always infuriated me on machines with actual keyboards because I touch-type, so I know exactly which keys I hit, and if I hit a wrong one three characters back I've already hit delete three times and retyped the end of the word (a habit I learned using vi on terminals with la-a-a-a-a-a-a-g) before my conscious mind can weigh in.
The first thing I do when I get an upgrade to Word on my machine at work is spend 45 tedious minutes spelunking through its endless, disorganized preferences and shutting off every single "smart" thing I can find. There's no way to prevent it from meddling altogether, but it's possible to beat it into something civilized.
Comments
OK this is pretty basic computer science people. I have the Snow Leopard preview but I'm not going to break NDA. However, I will go on a road of self discovery and enlightenment with ya'll together.
As was stated earlier, executable code is a very small portion of an application's disk footprint. Take Mail.app for example in Leopard:
du -h /Applications/Mail.app
<snip>
289M\t/Applications/Mail.app
Mail.app takes up a whopping 289MB. This is a MacBook Pro, basically fresh off the truck from China and updated to 10.5.3. Now, look at the executable:
du -h /Applications/Mail.app/Contents/MacOS/Mail
5.7M\t/Applications/Mail.app/Contents/MacOS/Mail
The Mail executable is 5.7MB, or 1.97% of the overall footprint. Even if LLVM and all the other "compiler magic" (oy) in Snow Leopard reduced the executable to a measly 4K (impossible given the Mach headers, static data and load commands alone would be more than that), the bundle would still be around 284 MB.
So let's look at the resources. The real heft is in Resources:
du -h /Applications/Mail.app/Contents/Resources
279M\t/Applications/Mail.app/Contents/Resources/
So 279MB, or 98% of the footprint, is taken up by resources. Which resources then?
du -h /Applications/Mail.app/Contents/Resources/ | sort
15M\t/Applications/Mail.app/Contents/Resources//Dutch.lproj
15M\t/Applications/Mail.app/Contents/Resources//English.lproj
15M\t/Applications/Mail.app/Contents/Resources//German.lproj
15M\t/Applications/Mail.app/Contents/Resources//Italian.lproj
15M\t/Applications/Mail.app/Contents/Resources//Japanese.lproj
15M\t/Applications/Mail.app/Contents/Resources//Spanish.lproj
15M\t/Applications/Mail.app/Contents/Resources//da.lproj
15M\t/Applications/Mail.app/Contents/Resources//fi.lproj
15M\t/Applications/Mail.app/Contents/Resources//ko.lproj
15M\t/Applications/Mail.app/Contents/Resources//no.lproj
15M\t/Applications/Mail.app/Contents/Resources//pl.lproj
...
As you can see, each localization takes up 15 MB. With 18 localizations installed by default, that's 270MB.
Now, let's look at the individual localized files. In English:
du -h /Applications/Mail.app/Contents/Resources/English.lproj/ | sort
44K\t/Applications/Mail.app/Contents/Resources/English.lproj//MailHelp/shrd
..
540K\t/Applications/Mail.app/Contents/Resources/English.lproj//MailViewer.nib
544K\t/Applications/Mail.app/Contents/Resources/English.lproj//SmartMailboxCriterionView.nib
568K\t/Applications/Mail.app/Contents/Resources/English.lproj//MailHelp/gfx
576K\t/Applications/Mail.app/Contents/Resources/English.lproj//MailSorter.nib
As you can see, the largest files are nib files.
So to take an educated guess: Snow Leopard will dramatically reduce the footprint of the operating system by only installing one localization--the localization choosen by the user when they boot from the CD and choose which language to use for the installer. Other languges will be on the install disk as an Optional install. Perhaps some images will be replaced by PDF and other vector art, but bearing in mind that vector art is still much more expensive to render, and Apple has typically discouraged that route except for very simple graphics (look at the Apple Icon Guidelines), I still assert almost all the savings will come from installing fewer resources.
Or better yet, have a Framework of Localization Nibs dylib'd in when needed upon loading your application, based upon the localization settings for the User.
Or better yet, have a Framework of Localization Nibs dylib'd in when needed upon loading your application, based upon the localization settings for the User.
I was thinking about that as an option, too. There would be localizations aspects that would not be found in localization.framework, but it seems like there is a lot of redundant data from app to app.
I was thinking about that as an option, too. There would be localizations aspects that would not be found in localization.framework, but it seems like there is a lot of redundant data from app to app.
It does? You should take a look sometime. There is actually very little redundant data that is of any size. Look at the resources in Mail again and compare them to iChat. The nib files are not even close to eachother. If you think that nib files are commonly shared, you have obviously never used a nib file.
Anyway, the whole point of my post was that Apple is NOT doing anything uber-cool with LLVM and NSA-powered optimization techniques to magically make executables super-small. I was pointing out that it's just impossible if you do the math on the Resources folder(s). Without having Apple legal knock on my doors, I can say that you can piece it together by reading the posts above without having to even have a copy of Snow Leopard--R.I.P. .nib, hello .xib. As I said before, nib files are the largest space gobblers, and in SL "they are installing fewer resources", no magic Localization framework required.
So to take an educated guess: Snow Leopard will dramatically reduce the footprint of the operating system by only installing one localization--the localization choosen by the user when they boot from the CD and choose which language to use for the installer. Other languges will be on the install disk as an Optional install. Perhaps some images will be replaced by PDF and other vector art, but bearing in mind that vector art is still much more expensive to render, and Apple has typically discouraged that route except for very simple graphics (look at the Apple Icon Guidelines), I still assert almost all the savings will come from installing fewer resources..
I still don't understand why they are suddenly doing this now. Why was the default install set up to install every language under the sun? I can appreciate that one computer may be shared between users of two or maybe three languages, but all of them?
One of my wife's co-workers has a last name spelled "Taht". It was almost impossible for anyone to write him a letter in a Microsoft application without it coming through as "That".
If I knew someone named Taht, I would simply remove Taht from the auto-correct list in Word. Problem solved.
They'd also do well to add GREP search and replace to the text engine. That's add GREP's well-honed abilities to almost all text applications.
Developers can use it with predicates. Users can't use GREP. I can't see it being added. Apple typically doesn't add geek-only features.
That would be nice. I don't think it would be too hard to create a deamon that would monitor what files/folders are created by an app while it's running, that would then create a small DB of the apps that would delete the appropriate files.
Receipts already have this. Anyone who uses Apple's installer can make use of this.
It does? You should take a look sometime. There is actually very little redundant data that is of any size. Look at the resources in Mail again and compare them to iChat. The nib files are not even close to eachother. If you think that nib files are commonly shared, you have obviously never used a nib file.
Anyway, the whole point of my post was that Apple is NOT doing anything uber-cool with LLVM and NSA-powered optimization techniques to magically make executables super-small. I was pointing out that it's just impossible if you do the math on the Resources folder(s). Without having Apple legal knock on my doors, I can say that you can piece it together by reading the posts above without having to even have a copy of Snow Leopard--R.I.P. .nib, hello .xib. As I said before, nib files are the largest space gobblers, and in SL "they are installing fewer resources", no magic Localization framework required.
Individual nib files may not share much of the same data, but they share much of the same behavior and using a central RDBMS ala SQLite that has a custom interface to interact with IB and work with Localization content, xml plist files, etc., can be abstracted as can much of IB once Carbon is gone.
NeXTSTEP applications weren't abhorrent pigs and yet we did have a good dozen localization options per release.
We didn't do the all resources thrown in our bundle solution, but then NeXTSTEP didn't have Carbon to huck it up.
Developers can use it with predicates. Users can't use GREP. I can't see it being added. Apple typically doesn't add geek-only features.
Make it a preference for Developer Tools, Terminal.app and any other shell that can leverage it via Advanced Preferences.
We did such in NeXTSTEP.
Taking a page out of Redmond's handbook for once, Snow Leopard will also leverage text processing features originally conceived by Microsoft as features for Word.
That, in a nutshell, it what's wrong with virtually every word processing and text application around. Whether for Macs, Windows or Linux, they're all following Microsoft's lead, adding silly, clumsy, bothersome features simply because Microsoft put those features in Word.
There's a lot Apple could do to improve the text-handing abilities of OS X that don't require slavishly imitating Microsoft. Suggestions include:
1. Building in GREP search and replace. I use it with InDesign and it's absolutely amazing what it can do. The code is probably open source. Put it into OS X and every text application could tap the power.
2. Almost no one uses named styles in Word because it's so badly done. But done right, named styles (paragraph and character) save a lot of time. Users want it. Virtually every full-featured commercial text application supports it. Almost none of the more innovative 'shareware' applications do, because creating it from scratch requires more time and cost to implement than they can afford. Apple needs to build named styles into OS X, doing it right, and allow them to be cut and pasted between applications. When I cut and paste between Word and InDesign, I don't want the Word formatting to come along. I want the distinction between headings and body text to be maintained.
3. There's useful open source OCR software out there. OS X has speech recognition. It needs to add text recognition. Let us scan or take a picture of some text and easily convert to text as easily as OS X does text to speech.
If I knew someone named Taht, I would simply remove Taht from the auto-correct list in Word. Problem solved.
Better yet: having the auto-correct and spelling infrastructure know about your contacts, so that it automatically accepts those spellings as correct. The information is already in the system, it should leverage what you've already told it.
Newton did this, iPhone does this, no reason why Mac can't do it as well.
(a couple quibbles)
CUPS is already a part of OS X.
The alleged web tablet is anything but confirmed.
The observed smaller application footprint is definitely not from resolution independence. More likely missing localizations or ZFS's smaller minimum file size.
That, in a nutshell, it what's wrong with virtually every word processing and text application around. Whether for Macs, Windows or Linux, they're all following Microsoft's lead, adding silly, clumsy, bothersome features simply because Microsoft put those features in Word.
There's a lot Apple could do to improve the text-handing abilities of OS X that don't require slavishly imitating Microsoft. Suggestions include:
1. Building in GREP search and replace. I use it with InDesign and it's absolutely amazing what it can do. The code is probably open source. Put it into OS X and every text application could tap the power.
2. Almost no one uses named styles in Word because it's so badly done. But done right, named styles (paragraph and character) save a lot of time. Users want it. Virtually every full-featured commercial text application supports it. Almost none of the more innovative 'shareware' applications do, because creating it from scratch requires more time and cost to implement than they can afford. Apple needs to build named styles into OS X, doing it right, and allow them to be cut and pasted between applications. When I cut and paste between Word and InDesign, I don't want the Word formatting to come along. I want the distinction between headings and body text to be maintained.
3. There's useful open source OCR software out there. OS X has speech recognition. It needs to add text recognition. Let us scan or take a picture of some text and easily convert to text as easily as OS X does text to speech.
GREP is built-in to every UNIX system for the past 2 plus decades.
NeXT had a very nice implementation available for applications.
Autocorrect is an untter pain-in-the-ass.
Indeed. Like some people have said, Microsoft made this terrible feature popular. 'Popular' because people naively use it thinking it's ok for it to make occasional mistakes or 'popular' because its foisted upon the user without a clear and easy way to disable it for novice users. Either way, popular features does not automatically mean it is good. In this case it's bad.
For a tool to be considered excellent, it has to work with 100% accuracy. Imagine if a screwdriver had a 95% accuracy. You turn it clockwise and the screw would dig into a surface 95% of the time, but there's a 5% chance that it instead pulls out of the surface. Of course, this couldn't be...or wouldn't be acceptable. This is why the screwdriver is an excellent tool for the job of driving a screw into a soft surface. It works 100% of the time (barring no user error...attempts by the tool to prevent user error is simply icing on the cake. As long as the tool works 100% when no user error is made, it's an excellent tool).
A tool must work 100% of the time to be considered excellent. If it doesn't work 100% of the time...it's not the right tool for the job since there a chance that it becomes counter-productive. And that counter-productivity can cancel some or all of the productivity brought by the time that the tool actually does work.
This is why autocorrect fails as a tool. Barring no user error, the tool does *not* work 100% of the time. It has to take a guess. And I'm sure that mdriftmeyer and other people can attest that the time spent coaxing the tool to work like it should destroys any benefits that it might bring otherwise.
A tool must work 100% of the time to be considered excellent. If it doesn't work 100% of the time...it's not the right tool for the job since there a chance that it becomes counter-productive. And that counter-productivity can cancel some or all of the productivity brought by the time that the tool actually does work.
This is why autocorrect fails as a tool. Barring no user error, the tool does *not* work 100% of the time. It has to take a guess. And I'm sure that mdriftmeyer and other people can attest that the time spent coaxing the tool to work like it should destroys any benefits that it might bring otherwise.
There's an important caveat to this: autocorrect is important and desirable on the iPhone because text entry itself is heuristic. You can't touch-type.
Autocorrect has always infuriated me on machines with actual keyboards because I touch-type, so I know exactly which keys I hit, and if I hit a wrong one three characters back I've already hit delete three times and retyped the end of the word (a habit I learned using vi on terminals with la-a-a-a-a-a-a-g) before my conscious mind can weigh in.
The first thing I do when I get an upgrade to Word on my machine at work is spend 45 tedious minutes spelunking through its endless, disorganized preferences and shutting off every single "smart" thing I can find. There's no way to prevent it from meddling altogether, but it's possible to beat it into something civilized.