Re: Modifying system files
Re: Modifying system files
- Subject: Re: Modifying system files
- From: Aaron Wallis <email@hidden>
- Date: Sun, 10 Jun 2007 02:07:16 +1000
Hi all and thanks for the many words of warning :P
The app I'm building is simply a utility to allow people to change
the audio files in the core audio component in a considerably less
intrusive manner than via the terminal etc.
I found my computer illiterate partner hacking away at my laptop to
change a sound... a drag and drop interface is WWWHHHAAAAYYYY better
than a n00b learning how to use the terminal in /System/Library )
It is known now, and always will be known as a "use at your own risk"
stye application (not to mention possibly become redundant in 5 days
time :P)
Thanks again for your help and warnings.
- Az
On 10/06/2007, at 12:46 AM, Ricky Sharp wrote:
On Jun 9, 2007, at 9:26 AM, Shawn Erickson wrote:
To echo what Wain stated... DO NOT modify files under /System
unless it is required as part of an Apple approved / supported
pathway (aka install KEXTs, etc.). If you still feel you need to
do this you must fully understand the security and stability
issues involved and you must inform your customers of what you are
doing. You must take extra care in implementing you software so
that it itself or by way of what it modifies doesn't expose or
become a vulnerability. This means fully understanding how to
utilize authorization services, how to install your application
securely, how to keep it secure, and also how to ensure you keep
proper file permission, etc. on the files you modify.
Additionally you will be modify files that Apple is free to
rename, change the format of, etc. on a whim because they are not
part of the public API for Mac OS X. You expose your customers up
to all kinds of potential issues with every security update, patch
release, and major revision.. and open yourself up to a possibly
bad support situation.
Personally somethings just shouldn't be done even if you and your
customers think it would be a cool thing... I rate this type of
product as one of those.
I'll also add a couple things here (if Shawn and others have not
already convinced folks that this is a bad idea :)
(1) Tiger and Leopard work with resolution-independence. Thus,
your new artwork would need to be able to work flawlessly at
various scaling factors.
(2) More importantly, I believe there are many APIs in both Cocoa
and Carbon that return back sizes of controls. If your artwork is
not the exact same size as what Apple provides, you introduce a
high risk of those APIs returning incorrect info. For example, it
may be the case where sizes may be hard-coded as opposed to being
dynamic based upon actual image sizes.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden