To read all comments associated with this story, please click here.
You need to understand how Mac apps work. Everything is in the one file. It's not like Windows where one app has parts in Program Files, DLLs in System 32, and then stuff in the Registry, and in other cases yet more in Common Files...
If you had continued reading - you would have noticed that the very next line says that iTunes is 129 MB.
Remember that this size includes all the translations -- something you don't get with many Windows apps, if at all -- as well as all of the open source libraries (like GStreamer) that have to be bundled because Songbird is not a native OS X app, using the native APIs.
I think you're doing yourself a disfavour by taking the file size into account, especially given that either a) you don't use a Mac AND/OR b) you never compared the file size to any of the other apps on the Mac.
Everything is not in one file! It may look like a file to you but it is a directory, a special one, but a directory none the less.
And which, with the exception of a maximum of one translation, are completely worthless and a waste of time and space.
Linux users used to have to sit through endless rounds watching:
blah_blah_enGB
blah_blah_enUS
blah_blah_sp
blah blah_de
blah_blah_tw
blah_blah_se
...
scroll by endlessly on installations and updates. Thank the deities that be that Linux distros finally got a clue.
Mac apps really do this?
"The Mac download expands into a 117 MB"
Mac applications generally carry all the static libraries in one single file. There is a different philosophy of setup in Mac: There's no setup of anything. Just drag and run. I don't think it's the best philosophy when it comes down for shared libraries and take advantage of what's already in memory. But Mac does have a resource fork (meaning that it should be much more than 117 totally static).
Mac applications generally carry all the static libraries in one single file. There is a different philosophy of setup in Mac: There's no setup of anything. Just drag and run. I don't think it's the best philosophy when it comes down for shared libraries and take advantage of what's already in memory. But Mac does have a resource fork (meaning that it should be much more than 117 totally static).
That's not true. Mac apps generally have dynamic libraries/frameworks, which can be embedded in the application bundle or located in a shared location such as ~/Library/Frameworks or /Library/Frameworks.
Drag-install apps usually use the embedded method, but apps that use installers are free to locate frameworks in either of the shared locations.





Member since:
2005-09-21
"The Mac download expands into a 117 MB"
I pretty much lost interest after that. For me, a music player should be something to play music in the background and use minimal resources doing so. I don't need some behemoth running in the background all the time, integrating every single online source of information into the app itself on the off-chance that I might want to look that stuff up.
By all means, allow me to get to the wikipedia/lyrics/pictures page for an artist/song, but why people think embedding this info into a music player is a good idea is beyond me. Those things exist on the web, and the correct tool for viewing them is a web browser. Instead of embedding a browser engine in your app, launch the browser with the correct link so I can view it properly and maintain the separation of responsibilities between apps.