can anyone confirm that this works? If so... then I'm sort of disappointed about these "shrinking" apps, since you're able to get them on Leopard. How small are the apps after the NIB files are removed, the apps are monolingualized, and the apps are stripped of PPC code (or xslimmed)?
can anyone confirm that this works? If so... then I'm sort of disappointed about these "shrinking" apps, since you're able to get them on Leopard. How small are the apps after the NIB files are removed, the apps are monolingualized, and the apps are stripped of PPC code (or xslimmed)?
It works. It's a standard unix command. sudo find / -iname "designable.nib" searches your entire drive for files named "designable.nib" and the -exec rm "{}" \\; argument deletes each of those files it finds.
Whomever it was that mentioned Xslimmer, I must say THANKS !!!!!!!!!!
I downloaded it, and immediately got back close to 5 gigs. I have now started a process of going through my apps to see what I do and do not really run daily, weekly, monthly or even yearly. My Mac seems a bit snappier as well.
To those of you deleting files randomly from your computer:
When you start to do things like remove .NIB files, extraneous language files, Power PC code, etc., you are likely breaking the ability for Apple Software Update to detect and install product updates.
After deleting these files, the applications that they are attached to are not longer recognizable, and can't be patched by ASU.
I'd say don't do it, unless you're prepared to manually check for and download the full installation packages for any OS updates from Apple.
It would seem that Apple's own installer/update mechanism isn't so smart in this regard. I had used Get Info to disable (not delete) the extra language files as that was reported to speed up Safari a bit. So no hacks or 3rd party apps, just Apple's own Get Info function. However, it appears that one of the Safari updates replaced all of those disabled languages and I now have TWO copies of all of them and my Safari is 90 MB! No wonder I've been getting spinning beach ball a lot lately!
Upon looking into it, it appears that the Get Info action simply moves the disabled languages into a Resources Disabled folder inside of the Safari package. This folder is 51 MB, over half of the Safari total size!
Must be handy to have UNIX command line skills! How would you modify this to list the files, their sizes and then a total size of all files at the end? Or just total file size savings would be fine. Thanks.
For instance every Adobe product has a "legal" folder with the licence agreements for the product in it. Why something that is never read by anyone needs to be copied to your HD I don't know, but making it worse, is that it's copied *hundreds* of times. The licence agreements are printed in 30 to 40 languages and an identical folder is every folder for every product in the applications folder.
For those of us that have had to go to court to protect patents, trademarks and copyrights, you bet your butt they are needed. As the law dictates, you as a trademark or copyright holder can loose your rights by not actively keeping them current.
In addition, there is the issue of liability. For example, not declaring a products Use of Software Restrictions, Privacy Policies, Proprietary Rights, Government Restricted Rights, Export Restrictions, Compliances with Local Laws, Disclaimers, Warrantees, Liability Limitations, etc., in part or in all, just leaves developers open to potential litigation.
Your rant against Adobe is not well founded. Including necessary legal notices and warnings for a single application that effectively only affects itself and its immediate surroundings is one thing. But for a suite of products like Adobe's offers that are so intertwined with each other, as well as the significant number third-party applications and plug-ins that together only increases the liability risk, is another.
In this age of virtuality, and in particular, the growing incidence of frivolous lawsuits*, being forewarned is being forearmed has never been more necessary.
Hi, this is one of the developers working on Xslimmer. A couple of words of caution:
- As others noted above, removing localizations in Adobe products may render the updater application inoperable. This is not specific to Adobe, other apps perform self-integrity checks on their contents (usually as an anti-piracy measure, or for whatever reason), and they do not work properly after being modified.
- Removing "designable.nib" files may invalidate Leopard code signatures, which could lead to applications seemingly "forgetting" passwords or keychain-stored items, and failing to remember them again. Signed apps contain a file called "CodeResources" that lists all signature-protected resources in the application. If you take a look, for example, at /Applications/Mail.app/Contents/CodeResources you'll see many references to "designable.nib" files in the English.lproj resource directory. This means that if those files were deleted, Mail.app could not behave properly afterwords, even if those nibs are only useful during development. Note also that "designable.nib" files in other localizations are _not_ listed in CodeResources, so they may be deleted with a greater degree of confidence
Although Xslimmer deals with both issues (a blacklist with apps known to not work properly is maintained by our team; CodeResource files are correctly recognized and honored), this is not intended as an advertisement for our product. You may use Monolingual or a command-line utility to remove unused resources, but please take into account that side effects like the ones above may occur, so don't forget to backup your system before attempting those operations. You should backup even if you are planning to use Xslimmer
Finally, thanks a lot to the people that recommended Xslimmer in their comments, we feel proud and honored whenever that happens
Hi, this is one of the developers working on Xslimmer. A couple of words of caution:
- As others noted above, removing localizations in Adobe products may render the updater application inoperable. This is not specific to Adobe, other apps perform self-integrity checks on their contents (usually as an anti-piracy measure, or for whatever reason), and they do not work properly after being modified.
- Removing "designable.nib" files may invalidate Leopard code signatures, which could lead to applications seemingly "forgetting" passwords or keychain-stored items, and failing to remember them again. Signed apps contain a file called "CodeResources" that lists all signature-protected resources in the application. If you take a look, for example, at /Applications/Mail.app/Contents/CodeResources you'll see many references to "designable.nib" files in the English.lproj resource directory. This means that if those files were deleted, Mail.app could not behave properly afterwords, even if those nibs are only useful during development. Note also that "designable.nib" files in other localizations are _not_ listed in CodeResources, so they may be deleted with a greater degree of confidence
Although Xslimmer deals with both issues (a blacklist with apps known to not work properly is maintained by our team; CodeResource files are correctly recognized and honored), this is not intended as an advertisement for our product. You may use Monolingual or a command-line utility to remove unused resources, but please take into account that side effects like the ones above may occur, so don't forget to backup your system before attempting those operations. You should backup even if you are planning to use Xslimmer
Finally, thanks a lot to the people that recommended Xslimmer in their comments, we feel proud and honored whenever that happens
Dude, I went and paid for it and have recommended it already. It does a great job. Worth the money. I am glad someone else in this forum/thread recommended it.
Must be handy to have UNIX command line skills! How would you modify this to list the files, their sizes and then a total size of all files at the end? Or just total file size savings would be fine. Thanks.
Here you go
sudo find / -iname "designable.nib" -exec du -k "{}" \\; | awk '{s += $1; print $0} END {print s}'
BTW I get 790956 kB from this on my system (Note Developer has these files as well)
Snow Leopard, to me, is about the exact same speed currently as Leopard. There's about 5 gigs shaved off the total OS, but the speed isn't noticeable IMHO. Maybe that's just for the developer preview, but it better be quicker if Apple expects to squeeze $129 out of us.
For those of us that have had to go to court to protect patents, trademarks and copyrights, you bet your butt they are needed. As the law dictates, you as a trademark or copyright holder can loose your rights by not actively keeping them current.
In addition, there is the issue of liability. For example, not declaring a products Use of Software Restrictions, Privacy Policies, Proprietary Rights, Government Restricted Rights, Export Restrictions, Compliances with Local Laws, Disclaimers, Warrantees, Liability Limitations, etc., in part or in all, just leaves developers open to potential litigation.
Your rant against Adobe is not well founded. Including necessary legal notices and warnings for a single application that effectively only affects itself and its immediate surroundings is one thing. But for a suite of products like Adobe's offers that are so intertwined with each other, as well as the significant number third-party applications and plug-ins that together only increases the liability risk, is another.
In this age of virtuality, and in particular, the growing incidence of frivolous lawsuits*, being forewarned is being forearmed has never been more necessary.
It does seem like they could have one licensing location with an alias pointing to the licensing documentation rather then document copies all over the hard drive. They could even make it an html document with a link to it as a menu item in an app like 'help' or 'about', or the opening launch screen .....
I haven't owned a laptop yet that I haven't had to upgrade the hard drive to a larger one. I also seem to run out of space on my desktops. After I include a dedicated external for a cloned backup and a third hard drive now for Time Machine the Terabytes add up!
Your rant against Adobe is not well founded. Including necessary legal notices and warnings for a single application that effectively only affects itself and its immediate surroundings is one thing. But for a suite of products like Adobe's offers that are so intertwined with each other, as well as the significant number third-party applications and plug-ins that together only increases the liability risk, is another.
Can you name any other company that does it that way? I haven't.
I don't think the problem is the existence of the notice, mostly the excess of it in this case, making the complaint well founded.
Whomever it was that mentioned Xslimmer, I must say THANKS !!!!!!!!!!
I downloaded it, and immediately got back close to 5 gigs. I have now started a process of going through my apps to see what I do and do not really run daily, weekly, monthly or even yearly. My Mac seems a bit snappier as well.
Thanks again for the great tip.
I mention Xslimmed, but not Xslimmer, anyways there are other things you can do to slim down your apps.
1) Monolingual-ize your apps (remove all the extra languages you don't need) -- Do NOT monolingual-ize Adobe apps
2) Remove NIB files with this terminal code:
Quote:
Originally Posted by GMFlash
No need to download any programs. Just open up Terminal and run:
Hi, this is one of the developers working on Xslimmer. A couple of words of caution:
...
- Removing "designable.nib" files may invalidate Leopard code signatures, which could lead to applications seemingly "forgetting" passwords or keychain-stored items, and failing to remember them again. Signed apps contain a file called "CodeResources" that lists all signature-protected resources in the application. If you take a look, for example, at /Applications/Mail.app/Contents/CodeResources you'll see many references to "designable.nib" files in the English.lproj resource directory. This means that if those files were deleted, Mail.app could not behave properly afterwords, even if those nibs are only useful during development. Note also that "designable.nib" files in other localizations are _not_ listed in CodeResources, so they may be deleted with a greater degree of confidence
Although Xslimmer deals with both issues (a blacklist with apps known to not work properly is maintained by our team; CodeResource files are correctly recognized and honored), this is not intended as an advertisement for our product. You may use Monolingual or a command-line utility to remove unused resources, but please take into account that side effects like the ones above may occur, so don't forget to backup your system before attempting those operations. You should backup even if you are planning to use Xslimmer
Finally, thanks a lot to the people that recommended Xslimmer in their comments, we feel proud and honored whenever that happens
Okay, you say you're not trying to advertise your product, but you've succeeded in scaring me into not performing the command-line deletion, at least until I get more information. Your claim is filled with a lot of "mays" and "coulds"--removing designable.nib files may invalidate signatures... which could lead to bad things... Mail.app could (I assume you mean "may") not behave properly afterwards.... If you (or anyone) can provide evidence that these consequences of deleting designable.nib files have actually happened, or that they will (not "may") happen, then I won't perform the command-line deletion (and I will consider buying your product). Alternatively, if someone can provide strong evidence that the scary consequences will not occur, that would be helpful, too.
Incidentally, find's man page lists the -delete option. Why not use that instead of the more cumbersome -exec rm "{}"?
I mention Xslimmed, but not Xslimmer, anyways there are other things you can do to slim down your apps.
1) Monolingual-ize your apps (remove all the extra languages you don't need) -- Do NOT monolingual-ize Adobe apps
2) Remove NIB files with this terminal code:
Xslimmer may have done that though, I don't know for sure.
Edit:
What can Apple due to reduce the size of Snow Leopard? This is my list:
1) Remove PPC code
2) Make monolingual defualt
3) remove unncessary files (like designable.NIB)
4) Use vector images
0) Make all apps use the same resources (I mean... iTunes uses different resources then the whole OS, right? Why can't it use the same?)
what else?
Oh, and thanks. I used xSlimmer and things are rolling right along it seems. I also tend to only use my Mac for work stuff. No development, or anything "stressful". Is there a difference between the two apps? I will say that my system is much faster and snappier than before.
320 GB drives or 500GB drives are enough for the life of any system, unless you realize you want to do Audio/Video compositions, convert your entire CD and DVD collections to shared drives, in which you'll be wanting terabytes of space to do work.
Even software developers don't need terabyte drives, unless they are working with multiple operating systems, filesystems and more to test their products on.
Yes, hard drives are cheap. I'm more interested in the OS ability to manage memory, VM space and messaging to work without having the system lock up before I am about localization packages filling up a dumb device.
With most flash memory it's said that each block can be written 100,000+ times. The memory uses wear levelling so that blocks are all 'worn down' at roughly the same speed. How that actually works in real life depends very much on the application. If you were to write backups to flash every day and fill up the card, in theory you'd be able to do that 100,000+ times. You may have issues if you write a lot of small files very often - flash has to blank an entire block each time it writes, so small files are inefficient in this sense as many unused bytes are 'worn down' even though they contained no data before.
The way this is handled not terribly different from the way bad blocks get mapped out of a disk with automatic error detection. Wear levelling may be done at OS level or lower down depending on the system. There is a fair amount of research going on about how exactly to get the best performance out of flash, given that it has different optimal access patterns and this wearing out problem, as compared with disks.
Getting back to the main point, smaller overall disk contents makes it that much easier to e.g. optimize putting frequently near-simultaneously accessed content together to get the best effect from the fact that a disk is better on large accesses than multiple small accesses. If you have a lot of random garbage interspersed with the stuff that's actually used, that is just one more thing to think about when optimizing layout on disk and caching disk content in RAM.
My preference would be to have a global switch at OS install for selecting the degree of localization and all installers should default to this setting with an option to override. Most of my computer use is with machines that are only ever used with one language (if with choices sometimes required of alternative country dictionaries for spelling or alternative keyboard layout). A computer in an airport or international conference should be set up with an easy switch for different languages (guess how often I've seen that).
Comments
No need to download any programs. Just open up Terminal and run:
sudo find / -iname "designable.nib" -exec rm "{}" \\;
can anyone confirm that this works? If so... then I'm sort of disappointed about these "shrinking" apps, since you're able to get them on Leopard. How small are the apps after the NIB files are removed, the apps are monolingualized, and the apps are stripped of PPC code (or xslimmed)?
can anyone confirm that this works? If so... then I'm sort of disappointed about these "shrinking" apps, since you're able to get them on Leopard. How small are the apps after the NIB files are removed, the apps are monolingualized, and the apps are stripped of PPC code (or xslimmed)?
It works. It's a standard unix command. sudo find / -iname "designable.nib" searches your entire drive for files named "designable.nib" and the -exec rm "{}" \\; argument deletes each of those files it finds.
No need to download any programs. Just open up Terminal and run:
sudo find / -iname "designable.nib" -exec rm "{}" \\;
Unless you're a developer and you'd like to keep some of your own designable.nib!
I downloaded it, and immediately got back close to 5 gigs. I have now started a process of going through my apps to see what I do and do not really run daily, weekly, monthly or even yearly. My Mac seems a bit snappier as well.
Thanks again for the great tip.
To those of you deleting files randomly from your computer:
When you start to do things like remove .NIB files, extraneous language files, Power PC code, etc., you are likely breaking the ability for Apple Software Update to detect and install product updates.
After deleting these files, the applications that they are attached to are not longer recognizable, and can't be patched by ASU.
I'd say don't do it, unless you're prepared to manually check for and download the full installation packages for any OS updates from Apple.
It would seem that Apple's own installer/update mechanism isn't so smart in this regard. I had used Get Info to disable (not delete) the extra language files as that was reported to speed up Safari a bit. So no hacks or 3rd party apps, just Apple's own Get Info function. However, it appears that one of the Safari updates replaced all of those disabled languages and I now have TWO copies of all of them and my Safari is 90 MB! No wonder I've been getting spinning beach ball a lot lately!
Upon looking into it, it appears that the Get Info action simply moves the disabled languages into a Resources Disabled folder inside of the Safari package. This folder is 51 MB, over half of the Safari total size!
sudo find / -iname "designable.nib" -exec rm "{}" \\;
Must be handy to have UNIX command line skills! How would you modify this to list the files, their sizes and then a total size of all files at the end? Or just total file size savings would be fine. Thanks.
Yeah, Adobe sucks big-time.
For instance every Adobe product has a "legal" folder with the licence agreements for the product in it. Why something that is never read by anyone needs to be copied to your HD I don't know, but making it worse, is that it's copied *hundreds* of times. The licence agreements are printed in 30 to 40 languages and an identical folder is every folder for every product in the applications folder.
For those of us that have had to go to court to protect patents, trademarks and copyrights, you bet your butt they are needed. As the law dictates, you as a trademark or copyright holder can loose your rights by not actively keeping them current.
In addition, there is the issue of liability. For example, not declaring a products Use of Software Restrictions, Privacy Policies, Proprietary Rights, Government Restricted Rights, Export Restrictions, Compliances with Local Laws, Disclaimers, Warrantees, Liability Limitations, etc., in part or in all, just leaves developers open to potential litigation.
Your rant against Adobe is not well founded. Including necessary legal notices and warnings for a single application that effectively only affects itself and its immediate surroundings is one thing. But for a suite of products like Adobe's offers that are so intertwined with each other, as well as the significant number third-party applications and plug-ins that together only increases the liability risk, is another.
In this age of virtuality, and in particular, the growing incidence of frivolous lawsuits*, being forewarned is being forearmed has never been more necessary.
*http://www.cjac.org/legislation/bp17200/shakedown.cfm
- As others noted above, removing localizations in Adobe products may render the updater application inoperable. This is not specific to Adobe, other apps perform self-integrity checks on their contents (usually as an anti-piracy measure, or for whatever reason), and they do not work properly after being modified.
- Removing "designable.nib" files may invalidate Leopard code signatures, which could lead to applications seemingly "forgetting" passwords or keychain-stored items, and failing to remember them again. Signed apps contain a file called "CodeResources" that lists all signature-protected resources in the application. If you take a look, for example, at /Applications/Mail.app/Contents/CodeResources you'll see many references to "designable.nib" files in the English.lproj resource directory. This means that if those files were deleted, Mail.app could not behave properly afterwords, even if those nibs are only useful during development. Note also that "designable.nib" files in other localizations are _not_ listed in CodeResources, so they may be deleted with a greater degree of confidence
Although Xslimmer deals with both issues (a blacklist with apps known to not work properly is maintained by our team; CodeResource files are correctly recognized and honored), this is not intended as an advertisement for our product. You may use Monolingual or a command-line utility to remove unused resources, but please take into account that side effects like the ones above may occur, so don't forget to backup your system before attempting those operations. You should backup even if you are planning to use Xslimmer
Finally, thanks a lot to the people that recommended Xslimmer in their comments, we feel proud and honored whenever that happens
Hi, this is one of the developers working on Xslimmer. A couple of words of caution:
- As others noted above, removing localizations in Adobe products may render the updater application inoperable. This is not specific to Adobe, other apps perform self-integrity checks on their contents (usually as an anti-piracy measure, or for whatever reason), and they do not work properly after being modified.
- Removing "designable.nib" files may invalidate Leopard code signatures, which could lead to applications seemingly "forgetting" passwords or keychain-stored items, and failing to remember them again. Signed apps contain a file called "CodeResources" that lists all signature-protected resources in the application. If you take a look, for example, at /Applications/Mail.app/Contents/CodeResources you'll see many references to "designable.nib" files in the English.lproj resource directory. This means that if those files were deleted, Mail.app could not behave properly afterwords, even if those nibs are only useful during development. Note also that "designable.nib" files in other localizations are _not_ listed in CodeResources, so they may be deleted with a greater degree of confidence
Although Xslimmer deals with both issues (a blacklist with apps known to not work properly is maintained by our team; CodeResource files are correctly recognized and honored), this is not intended as an advertisement for our product. You may use Monolingual or a command-line utility to remove unused resources, but please take into account that side effects like the ones above may occur, so don't forget to backup your system before attempting those operations. You should backup even if you are planning to use Xslimmer
Finally, thanks a lot to the people that recommended Xslimmer in their comments, we feel proud and honored whenever that happens
Dude, I went and paid for it and have recommended it already. It does a great job. Worth the money. I am glad someone else in this forum/thread recommended it.
Must be handy to have UNIX command line skills! How would you modify this to list the files, their sizes and then a total size of all files at the end? Or just total file size savings would be fine. Thanks.
Here you go
sudo find / -iname "designable.nib" -exec du -k "{}" \\; | awk '{s += $1; print $0} END {print s}'
BTW I get 790956 kB from this on my system (Note Developer has these files as well)
For those of us that have had to go to court to protect patents, trademarks and copyrights, you bet your butt they are needed. As the law dictates, you as a trademark or copyright holder can loose your rights by not actively keeping them current.
In addition, there is the issue of liability. For example, not declaring a products Use of Software Restrictions, Privacy Policies, Proprietary Rights, Government Restricted Rights, Export Restrictions, Compliances with Local Laws, Disclaimers, Warrantees, Liability Limitations, etc., in part or in all, just leaves developers open to potential litigation.
Your rant against Adobe is not well founded. Including necessary legal notices and warnings for a single application that effectively only affects itself and its immediate surroundings is one thing. But for a suite of products like Adobe's offers that are so intertwined with each other, as well as the significant number third-party applications and plug-ins that together only increases the liability risk, is another.
In this age of virtuality, and in particular, the growing incidence of frivolous lawsuits*, being forewarned is being forearmed has never been more necessary.
*http://www.cjac.org/legislation/bp17200/shakedown.cfm
It does seem like they could have one licensing location with an alias pointing to the licensing documentation rather then document copies all over the hard drive. They could even make it an html document with a link to it as a menu item in an app like 'help' or 'about', or the opening launch screen .....
Your rant against Adobe is not well founded. Including necessary legal notices and warnings for a single application that effectively only affects itself and its immediate surroundings is one thing. But for a suite of products like Adobe's offers that are so intertwined with each other, as well as the significant number third-party applications and plug-ins that together only increases the liability risk, is another.
Can you name any other company that does it that way? I haven't.
I don't think the problem is the existence of the notice, mostly the excess of it in this case, making the complaint well founded.
Exactly.
A year ago I foolishly removed all the unused languages and was forced to do a complete re-install of my Adobe apps.
I think the real mistake is not doing a backup before doing a change to the system.
Whomever it was that mentioned Xslimmer, I must say THANKS !!!!!!!!!!
I downloaded it, and immediately got back close to 5 gigs. I have now started a process of going through my apps to see what I do and do not really run daily, weekly, monthly or even yearly. My Mac seems a bit snappier as well.
Thanks again for the great tip.
I mention Xslimmed, but not Xslimmer, anyways there are other things you can do to slim down your apps.
1) Monolingual-ize your apps (remove all the extra languages you don't need) -- Do NOT monolingual-ize Adobe apps
2) Remove NIB files with this terminal code:
No need to download any programs. Just open up Terminal and run:
sudo find / -iname "designable.nib" -exec rm "{}" \\;
Xslimmer may have done that though, I don't know for sure.
Edit:
What can Apple due to reduce the size of Snow Leopard? This is my list:
1) Remove PPC code
2) Make monolingual defualt
3) remove unncessary files (like designable.NIB)
4) Use vector images
0) Make all apps use the same resources (I mean... iTunes uses different resources then the whole OS, right? Why can't it use the same?)
what else?
Hi, this is one of the developers working on Xslimmer. A couple of words of caution:
...
- Removing "designable.nib" files may invalidate Leopard code signatures, which could lead to applications seemingly "forgetting" passwords or keychain-stored items, and failing to remember them again. Signed apps contain a file called "CodeResources" that lists all signature-protected resources in the application. If you take a look, for example, at /Applications/Mail.app/Contents/CodeResources you'll see many references to "designable.nib" files in the English.lproj resource directory. This means that if those files were deleted, Mail.app could not behave properly afterwords, even if those nibs are only useful during development. Note also that "designable.nib" files in other localizations are _not_ listed in CodeResources, so they may be deleted with a greater degree of confidence
Although Xslimmer deals with both issues (a blacklist with apps known to not work properly is maintained by our team; CodeResource files are correctly recognized and honored), this is not intended as an advertisement for our product. You may use Monolingual or a command-line utility to remove unused resources, but please take into account that side effects like the ones above may occur, so don't forget to backup your system before attempting those operations. You should backup even if you are planning to use Xslimmer
Finally, thanks a lot to the people that recommended Xslimmer in their comments, we feel proud and honored whenever that happens
Okay, you say you're not trying to advertise your product, but you've succeeded in scaring me into not performing the command-line deletion, at least until I get more information. Your claim is filled with a lot of "mays" and "coulds"--removing designable.nib files may invalidate signatures... which could lead to bad things... Mail.app could (I assume you mean "may") not behave properly afterwards.... If you (or anyone) can provide evidence that these consequences of deleting designable.nib files have actually happened, or that they will (not "may") happen, then I won't perform the command-line deletion (and I will consider buying your product). Alternatively, if someone can provide strong evidence that the scary consequences will not occur, that would be helpful, too.
Incidentally, find's man page lists the -delete option. Why not use that instead of the more cumbersome -exec rm "{}"?
I mention Xslimmed, but not Xslimmer, anyways there are other things you can do to slim down your apps.
1) Monolingual-ize your apps (remove all the extra languages you don't need) -- Do NOT monolingual-ize Adobe apps
2) Remove NIB files with this terminal code:
Xslimmer may have done that though, I don't know for sure.
Edit:
What can Apple due to reduce the size of Snow Leopard? This is my list:
1) Remove PPC code
2) Make monolingual defualt
3) remove unncessary files (like designable.NIB)
4) Use vector images
0) Make all apps use the same resources (I mean... iTunes uses different resources then the whole OS, right? Why can't it use the same?)
what else?
Oh, and thanks. I used xSlimmer and things are rolling right along it seems. I also tend to only use my Mac for work stuff. No development, or anything "stressful". Is there a difference between the two apps? I will say that my system is much faster and snappier than before.
Even software developers don't need terabyte drives, unless they are working with multiple operating systems, filesystems and more to test their products on.
Yes, hard drives are cheap. I'm more interested in the OS ability to manage memory, VM space and messaging to work without having the system lock up before I am about localization packages filling up a dumb device.
With most flash memory it's said that each block can be written 100,000+ times. The memory uses wear levelling so that blocks are all 'worn down' at roughly the same speed. How that actually works in real life depends very much on the application. If you were to write backups to flash every day and fill up the card, in theory you'd be able to do that 100,000+ times. You may have issues if you write a lot of small files very often - flash has to blank an entire block each time it writes, so small files are inefficient in this sense as many unused bytes are 'worn down' even though they contained no data before.
See http://en.wikipedia.org/wiki/Flash_memory#Limitations
The way this is handled not terribly different from the way bad blocks get mapped out of a disk with automatic error detection. Wear levelling may be done at OS level or lower down depending on the system. There is a fair amount of research going on about how exactly to get the best performance out of flash, given that it has different optimal access patterns and this wearing out problem, as compared with disks.
Getting back to the main point, smaller overall disk contents makes it that much easier to e.g. optimize putting frequently near-simultaneously accessed content together to get the best effect from the fact that a disk is better on large accesses than multiple small accesses. If you have a lot of random garbage interspersed with the stuff that's actually used, that is just one more thing to think about when optimizing layout on disk and caching disk content in RAM.
My preference would be to have a global switch at OS install for selecting the degree of localization and all installers should default to this setting with an option to override. Most of my computer use is with machines that are only ever used with one language (if with choices sometimes required of alternative country dictionaries for spelling or alternative keyboard layout). A computer in an airport or international conference should be set up with an easy switch for different languages (guess how often I've seen that).