While we're on the subject of DMG's for software distribution...
-
Hi Folks,
(Not super saavy about Mac OS X here so bear with me please...)
On the subject of DMG's... I inherited a software product that
currently ships using some moldy-oldy version of the Wise installer. I
think basically all it does is put the application _folder_ into the
Applications folder. In the application folder I am referring to is
the application bundle, some PDFs (doc) and a Plugins folder with one
plugin bundle in it. I think the application expects the plugins to be
in this specific place i.e., the Plugins folder in the applications
folder.
I'd prefer to ship this as a DMG... But if I understand DMG-based
delivery correctly, the idea is that Mac users are used to this and
"know" to copy the application bundle to the Applications folder. But
I need the user to copy the application folder (not just the bundle)
into the Applications folder. otherwise the plugin won't be found and
life as we know it will cease ;)
Is DMG just a non-starter for this or is there a way with a DMG format
to someone clue in the user that the folder needs to be copied, not
just the application bundle.
Thanks in advance...
Chris -
I'm certainly no expert but...
Application bundles are just directories which some special
characteristics that makes Finder hide the fact that its a directory
to make it look like an application. Finder just looks at any
directory that ends in .app and thinks its an application. It then
looks inside for an application, but in anycase, it doesn't show the
user the directory as a directory.
If the files you need are shipped as part of the application, the
appropriate place to put them is somewhere within the application
bundle (directory).
If the files are added during runtime or after installation, then they
typically go in the user directory in ~/Library/Application
Support/programName.
Some of this is spelled out in "File System Overview",
http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/BPF
ileSystem.html
On Mon, Sep 8, 2008 at 11:31 PM, Chris Markle <cmarkle...> wrote:
> Hi Folks,
>
> (Not super saavy about Mac OS X here so bear with me please...)
>
> On the subject of DMG's... I inherited a software product that
> currently ships using some moldy-oldy version of the Wise installer. I
> think basically all it does is put the application _folder_ into the
> Applications folder. In the application folder I am referring to is
> the application bundle, some PDFs (doc) and a Plugins folder with one
> plugin bundle in it. I think the application expects the plugins to be
> in this specific place i.e., the Plugins folder in the applications
> folder.
>
> I'd prefer to ship this as a DMG... But if I understand DMG-based
> delivery correctly, the idea is that Mac users are used to this and
> "know" to copy the application bundle to the Applications folder. But
> I need the user to copy the application folder (not just the bundle)
> into the Applications folder. otherwise the plugin won't be found and
> life as we know it will cease ;)
>
> Is DMG just a non-starter for this or is there a way with a DMG format
> to someone clue in the user that the folder needs to be copied, not
> just the application bundle.
>
> Thanks in advance...
>
> Chris
>
-
Seth Willits Re: While we're on the subject of DMG's for software distribution... Sep 09 2008, 06:03On Sep 8, 2008, at 8:31 PM, Chris Markle wrote:
> I'd prefer to ship this as a DMG... But if I understand DMG-based
> delivery correctly, the idea is that Mac users are used to this and
> "know" to copy the application bundle to the Applications folder. But
> I need the user to copy the application folder (not just the bundle)
> into the Applications folder. otherwise the plugin won't be found and
> life as we know it will cease ;)
You can set the background image of the dmg to explain it, but some
users will not do what you say and manually copy it incorrectly.
Your two options to ensure correct installation would be to:
a) use a package installer
b) put the plugins and docs inside of your application's bundle.
--
Seth Willits -
At 20:31 -0700 8/9/08, Chris Markle wrote:
> In the application folder I am referring to is
> the application bundle, some PDFs (doc) and a Plugins folder with one
> plugin bundle in it. I think the application expects the plugins to be
> in this specific place i.e., the Plugins folder in the applications
> folder.
My recommendation for this would be:
1 Put the PDFs in the Resources folder in the app, and add Help menu
entries to display them.
2a Put the Plug-Ins folder in the Contents folder in the app and use
it from there; OR
2b Put the Plug-Ins folder in the Resources folder, and on launch
copy it in to ~/Library/Application Support/Your App Name/Plug-Ins
and use it there.
3 Forget about the dmg and use .zip instead. There is no real reason
to use dmg except for the pretty background, and it adds confusion to
the users who run it from within the disk image and don't understand
why it then disappears when they log out. We switcher from .dmg to
.zip and (like other developers) got zero comments about the change.
BTW, would someone please standardize on the spelling and
capitalization of "Plug-Ins"?! It is spelled
Plug-Ins
Plug-ins
PlugIns
Plugins
and probably othes.
Plug-Ins seems the most common.
Enjoy,
Peter.
--
Keyboard Maestro 3 Now Available!
Now With Status Menu triggers!
Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
<> <<A href="http://download.stairways.com/">http://download.stairways.com/> -
On Tue, Sep 9, 2008 at 1:34 AM, Peter N Lewis <peter...> wrote:
> 1 Put the PDFs in the Resources folder in the app, and add Help menu entries
> to display them.
Pro Tools does this. It's incredibly frustrating to have to launch
the app just to get at the documentation. I happen to know that you
can open the app bundle, but who is to expect that a normal user will
know?
> 2a Put the Plug-Ins folder in the Contents folder in the app and use it from
> there; OR
This makes sense, because you can then use -[NSBundle
builtInPlugInsPath] to get to them.
> 2b Put the Plug-Ins folder in the Resources folder, and on launch copy it in
> to ~/Library/Application Support/Your App Name/Plug-Ins and use it there.
This isn't helpful to the user if they want to move or copy the
application. The OS does a good job of presenting the user the
appearance of a monolithic application object. Granted, your plug-in
might rely on code that gets installed elsewhere, so this might not
matter. But, for example, I expect that when I add Dreamweaver
plugins, like the very important updated WebDAV plugin bundle, that I
can move the app around and not lose it.
Better yet, search not only in the bundle but also in a few other
sensible locations.
> 3 Forget about the dmg and use .zip instead. There is no real reason to use
> dmg except for the pretty background, and it adds confusion to the users who
> run it from within the disk image and don't understand why it then
> disappears when they log out. We switcher from .dmg to .zip and (like other
> developers) got zero comments about the change.
ZIP files don't get the special treatment Internet-enabled DMGs do.
For one, if your Internet-enabled DMG only contains your app bundle,
Safari will unwrap the executable and throw away the DMG. Also, it is
a very convenient wrapper for holding things like documentation,
uninstallers, etc. I can also very easily burn a CD from the DMG --
very important as I found out when I accidentally trashed my network's
repository of software.
> BTW, would someone please standardize on the spelling and capitalization of
> "Plug-Ins"?! It is spelled
>
> Plug-Ins
> Plug-ins
> PlugIns
> Plugins
According to the documentation
(http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingCode/Tasks
/LoadingBundles.html#//apple_ref/doc/uid/20001273-99488-BAJFBAJB),
PlugIns is correct. Plug-ins is used as a fallback.
--Kyle Sluder -
on 2008-09-08 11:31 PM, Chris Markle at <cmarkle...> wrote:
> I'd prefer to ship this as a DMG... But if I understand DMG-based
> delivery correctly, the idea is that Mac users are used to this and
> "know" to copy the application bundle to the Applications folder.
Apple currently recommends that ALL applications be delivered in the form of
an installer. See the "PackageMaker User Guide," last revised in July 2007:
"The installation packagebased mechanism is the preferred method for
delivering products in Mac OS X. This model is a change for experienced Mac
OS X developers and packagers. Before Mac OS X v10.5 (Leopard), the
preferred software delivery mechanism was the manual install, where users
drag the product from its container, a disk image, onto their file system.
However, managed installs (which are steered by the Installer application
after the user opens an installation package) on Leopard clients make
possible advanced installation-management features, such as better package
management through the Installer package database, downloadable packages,
and certificate-based signing. Leopard leverages these features to provide
users an improved install experience."
I don't have any inside information, but I assume this change is because so
many switchers from that other platform have difficulty with the concept of
drag-installing an application package.
This doesn't answer your question about DMGs, however. You can deliver an
installer in a DMG, as I do these days, or in a zip file, or whatever.
--
Bill Cheeseman - <bill...>
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.com -
Am 09.09.2008 um 12:53 schrieb Bill Cheeseman:
> on 2008-09-08 11:31 PM, Chris Markle at <cmarkle...> wrote:
>
>> I'd prefer to ship this as a DMG... But if I understand DMG-based
>> delivery correctly, the idea is that Mac users are used to this and
>> "know" to copy the application bundle to the Applications folder.
>
> Apple currently recommends that ALL applications be delivered in the
> form of
> an installer.
The quoted paragraph means "an Apple installer", not "an installer"
> Leopard leverages these features to provide users an improved
> install experience."
*LOL* Well, dreaming is legitimate...
>Regards,
Tom_E -
On Sep 9, 2008, at 5:53 AM, Bill Cheeseman wrote:
> on 2008-09-08 11:31 PM, Chris Markle at <cmarkle...> wrote:
>
>> I'd prefer to ship this as a DMG... But if I understand DMG-based
>> delivery correctly, the idea is that Mac users are used to this and
>> "know" to copy the application bundle to the Applications folder.
>
> Apple currently recommends that ALL applications be delivered in the
> form of
> an installer. See the "PackageMaker User Guide," last revised in
> July 2007:
Here's what Apple says in the Software Delivery Guide (which I'd
assume to be more authoritative about which option you should use than
the PackageMaker manual), in the section under Managed Installs:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/Software
Distribution/Managed_Installs/chapter_5_section_1.html#/
/apple_ref/doc/uid/10000145i-CH6-SW8
"As described in “Overview of Software Delivery,” managed installs
give you more control over the installation process, which, among
other things, allows you to fine-tune the user’s install experience.
However, when your product is made up of a single component that
doesn’t need to be placed at privileged locations in the file system,
such as /Applications or /Library, you should provide users with a
manual install for your product. Manual installs are faster and easier
to perform for novice and expert users alike. See “Manual Installs”
for details."
I must agree with this paragraph whole-heartedly - my single favorite
thing about OS X is the way so many applications can be installed by
dragging a simple icon somewhere, and can be uninstalled by dragging
that same icon to the Trash. No need to worry about an installer
dumping crap where you don't want it, no paranoia about trusting the
uninstaller to remove everything - just delete, and it's gone. It's a
brilliant idea, and although users coming from Windows might be used
to needing to run an installer all the time, once it's explained to
them, it's the most natural thing in the world. After all, if we're
designing solely for the benefit of doing what Windows users are used
to, they're also used to launching applications through a Start menu
in the lower-left corner. Do we need one of those too?
Charles -
David Melgar Re: While we're on the subject of DMG's for software distribution... Sep 09 2008, 22:16I agree. Being able to install applications in unprivelaged locations
is one of the best qualities of mac os x.
Sent from my iPhone
On Sep 9, 2008, at 2:18 PM, Charles Srstka <cocoadev...>
wrote:
> On Sep 9, 2008, at 5:53 AM, Bill Cheeseman wrote:
>
>> on 2008-09-08 11:31 PM, Chris Markle at <cmarkle...> wrote:
>>
>>> I'd prefer to ship this as a DMG... But if I understand DMG-based
>>> delivery correctly, the idea is that Mac users are used to this and
>>> "know" to copy the application bundle to the Applications folder.
>>
>> Apple currently recommends that ALL applications be delivered in
>> the form of
>> an installer. See the "PackageMaker User Guide," last revised in
>> July 2007:
>
> Here's what Apple says in the Software Delivery Guide (which I'd
> assume to be more authoritative about which option you should use
> than the PackageMaker manual), in the section under Managed Installs:
>
> http://developer.apple.com/documentation/DeveloperTools/Conceptual/Software
Distribution/Managed_Installs/chapter_5_section_1.html#//apple_ref/doc/uid/
10000145i-CH6-SW8
>
> "As described in ?gOverview of Software Delivery,?h managed installs g
> ive you more control over the installation process, which, among oth
> er things, allows you to fine-tune the user?fs install experience. Ho
> wever, when your product is made up of a single component that doesn
> ?ft need to be placed at privileged locations in the file system, suc
> h as /Applications or /Library, you should provide users with a manu
> al install for your product. Manual installs are faster and easier t
> o perform for novice and expert users alike. See ?gManual Installs?h f
> or details."
>
> I must agree with this paragraph whole-heartedly - my single
> favorite thing about OS X is the way so many applications can be
> installed by dragging a simple icon somewhere, and can be
> uninstalled by dragging that same icon to the Trash. No need to
> worry about an installer dumping crap where you don't want it, no
> paranoia about trusting the uninstaller to remove everything - just
> delete, and it's gone. It's a brilliant idea, and although users
> coming from Windows might be used to needing to run an installer all
> the time, once it's explained to them, it's the most natural thing
> in the world. After all, if we're designing solely for the benefit
> of doing what Windows users are used to, they're also used to
> launching applications through a Start menu in the lower-left
> corner. Do we need one of those too?
>
> Charles
-
> I must agree with this paragraph whole-heartedly - my single favorite thing
> about OS X is the way so many applications can be installed by dragging a
> simple icon somewhere, and can be uninstalled by dragging that same icon to
> the Trash. No need to worry about an installer dumping crap where you don't
> want it, no paranoia about trusting the uninstaller to remove everything -
> just delete, and it's gone. It's a brilliant idea, and although users coming
> from Windows might be used to needing to run an installer all the time, once
> it's explained to them, it's the most natural thing in the world. After all,
> if we're designing solely for the benefit of doing what Windows users are
> used to, they're also used to launching applications through a Start menu in
> the lower-left corner. Do we need one of those too?
>
Absolutely, keep it small, keep it contained, and don't go putting files all
over the place on the customers hard drive. That's for "other platforms".
--Jon -
On 2008 Sep, 09, at 11:18, Charles Srstka wrote:
> On Sep 9, 2008, at 5:53 AM, Bill Cheeseman wrote:
>
>> Apple currently recommends that ALL applications be delivered in
>> the form of
>> an installer. See the "PackageMaker User Guide," last revised in
>> July 2007:
>
> Here's what Apple says in the Software Delivery Guide (which I'd
> assume to be more authoritative about which option you should use
> than the PackageMaker manual), in the section under Managed Installs:
Charles, it may appear to have a more authoritative perspective, but
it was last revised a year earlier, in July 2006. Therefore, I put my
faith the document that Bill Cheeseman referred to instead. Manual
Installs are Out. Installers are In. -
On Sep 9, 2008, at 2:15 PM, Jerry Krinock wrote:
> Charles, it may appear to have a more authoritative perspective, but
> it was last revised a year earlier, in July 2006. Therefore, I put
> my faith the document that Bill Cheeseman referred to instead.
> Manual Installs are Out. Installers are In.
But:
- installers that require authentication are seriously uncool (unless
absolutely positively necessary)
- installers that aren't also uninstallers (that work) is akin to
mixing striped pots & polka dotted shirts
- installers that do not allow for custom installation location is
moldy fruit in a gourmet buffet
If you are going down the Installer path, do it right. Otherwise,
don't do it at all. Drag and Drop FTW.
b.bum -
on 2008-09-09 4:16 PM, David Melgar at <enki1711...> wrote (quoting an
earlier poster, I think):
>> Here's what Apple says in the Software Delivery Guide (which I'd
>> assume to be more authoritative about which option you should use
>> than the PackageMaker manual),...
The poster didn't say why he assumes the Software Delivery Guide to be more
authoritative. The only evidence I'm aware of is that the Software Delivery
Guide was last updated over two years ago, in July 2006, before Leopard was
released. The PackageMaker User Guide is a year newer, and it states that it
applies to Leopard. On that evidence, I'm more inclined to think the
PackageMaker User Guide is authoritative with respect to Leopard.
Speaking only for myself, I am less enamoured of drag-install than I was
originally, given all the stories about newcomers to the platform failing to
understand how it works. The relatively recent fad of putting an Application
folder symlink next to the application icon in the DMG window is a popular
attempt to grapple with this problem, but in my personal view it only
increases the confusion.
Apple has given vague hints that installers will bring greater benefits in
the future. I don't know what those benefits might be, but I'm guessing that
improved security might be one of them.
I discovered a year ago that an application implementing a certain
security-related feature of the system cannot use an embedded framework, for
security reasons. (Specifically, an application that uses the
AXMakeProcessTrusted function from the accessibility API, which requires
user authentication, can't use embedded frameworks. I confirmed this with
Apple engineers at the time.) Thus, such an application cannot be
drag-installed, because it is necessary to install the framework in an
external location, such as /Library/Frameworks. It is therefore necessary to
use an installer to install it correctly. Scenarios like this may be the
wave of the future.
--
Bill Cheeseman - <bill...>
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.com -
On Tue, Sep 9, 2008 at 5:15 PM, Jerry Krinock <jerry...> wrote:
>
> On 2008 Sep, 09, at 11:18, Charles Srstka wrote:
>
>> On Sep 9, 2008, at 5:53 AM, Bill Cheeseman wrote:
>>
>>> Apple currently recommends that ALL applications be delivered in the form
>>> of
>>> an installer. See the "PackageMaker User Guide," last revised in July
>>> 2007:
>>
>> Here's what Apple says in the Software Delivery Guide (which I'd assume to
>> be more authoritative about which option you should use than the
>> PackageMaker manual), in the section under Managed Installs:
>
> Charles, it may appear to have a more authoritative perspective, but it was
> last revised a year earlier, in July 2006. Therefore, I put my faith the
> document that Bill Cheeseman referred to instead. Manual Installs are Out.
> Installers are In.
Your installer is the first thing a user sees of your product, so it
should leave a good first impression.
Alas, with me, *any* form of install is an automatic loss of points.
So by shipping an installer, you ensure that my first impression of
your product is a bad one.
Not having an installer has so many benefits. Having one has almost no
benefits. I don't think that Apple's opinion on the matter should
matter one way or the other. After all, they are not the users of your
software.
Mike -
It is definitely a mixed message... It needs to be at the very least
consistent. I've raised it with someone and will attempt to pursue it.
As bbum said, the issues with Installer packages are the need for
authentication, and the inability to specify where it should be
installed if it is a simple application.
On 9-Sep-08, at 5:26 PM, Bill Cheeseman wrote:
> on 2008-09-09 4:16 PM, David Melgar at <enki1711...> wrote
> (quoting an
> earlier poster, I think):
>
>>> Here's what Apple says in the Software Delivery Guide (which I'd
>>> assume to be more authoritative about which option you should use
>>> than the PackageMaker manual),...
>
> The poster didn't say why he assumes the Software Delivery Guide to
> be more
> authoritative. The only evidence I'm aware of is that the Software
> Delivery
> Guide was last updated over two years ago, in July 2006, before
> Leopard was
> released. The PackageMaker User Guide is a year newer, and it states
> that it
> applies to Leopard. On that evidence, I'm more inclined to think the
> PackageMaker User Guide is authoritative with respect to Leopard.
-
On Sep 9, 2008, at 4:26 PM, Bill Cheeseman wrote:
> The poster didn't say why he assumes the Software Delivery Guide to
> be more
> authoritative. The only evidence I'm aware of is that the Software
> Delivery
> Guide was last updated over two years ago, in July 2006, before
> Leopard was
> released. The PackageMaker User Guide is a year newer, and it states
> that it
> applies to Leopard. On that evidence, I'm more inclined to think the
> PackageMaker User Guide is authoritative with respect to Leopard.
Well, the Software Delivery Guide is, as the name suggests, the guide
to how you should deliver software, and is not intended to be a usage
manual for any one specific method. The PackageMaker manual is a
document describing how to use one specific application for software
delivery, written by people who probably *would* like you to use their
product. To my mind, it's like the difference between getting polling
data from an independent polling site vs. getting data from Obama or
McCain's web site.
Anyway, if Mac software starts heading back down the road to
everything having an installer, the appeal of the Mac platform vs.
Windows will be severely diminished in my eyes. Drag and drop puts the
user in control - installers put the user at their mercy. Whenever I
see an installer that does nothing but put an app in /Applications, I
tend to think twice about using that app, because it's often a sign of
a poorly thought out product. Often I will send an e-mail to the
author complaining about this as well.
Charles -
probably best not to debate this particular aspect of things...
As I said, I'll about getting this clarified in the docs, and a
consistent message in it.
On 10-Sep-08, at 3:40 AM, Charles Srstka wrote:
> On Sep 9, 2008, at 4:26 PM, Bill Cheeseman wrote:
>
>> The poster didn't say why he assumes the Software Delivery Guide to
>> be more
>> authoritative. The only evidence I'm aware of is that the Software
>> Delivery
>> Guide was last updated over two years ago, in July 2006, before
>> Leopard was
>> released. The PackageMaker User Guide is a year newer, and it
>> states that it
>> applies to Leopard. On that evidence, I'm more inclined to think the
>> PackageMaker User Guide is authoritative with respect to Leopard.
>
> Well, the Software Delivery Guide is, as the name suggests, the
> guide to how you should deliver software, and is not intended to be
> a usage manual for any one specific method. The PackageMaker manual
> is a document describing how to use one specific application for
> software delivery, written by people who probably *would* like you
> to use their product. To my mind, it's like the difference between
> getting polling data from an independent polling site vs. getting
> data from Obama or McCain's web site.
>
> Anyway, if Mac software starts heading back down the road to
> everything having an installer, the appeal of the Mac platform vs.
> Windows will be severely diminished in my eyes. Drag and drop puts
> the user in control - installers put the user at their mercy.
> Whenever I see an installer that does nothing but put an app in /
> Applications, I tend to think twice about using that app, because
> it's often a sign of a poorly thought out product. Often I will send
> an e-mail to the author complaining about this as well.
-
In my mind, the installer issue is an issue of trust.
Do you trust the "installer" of an application to install the
application in the best interest of the user. Do you trust that the
installer won't install things you don't want. Do you trust that the
installer provides a way to uninstall the application completely when
its done.
The resounding answer to all of these questions is NO. This is one of
the primary reasons why the Windows platform gets a black eye.
Applications typically recklessly install themselves, overwriting
other applications data, installing additional unwanted features deep
into the operating system without the user being told resulting in
spyware, nagware or annoyware under the guise of providing the user
some wonderful feature.
I've worked on many platforms for many years, from Windows to many
varieties of Unix to mainframes.
I believe that the only way to solve this problem of trust is to not
trust the installer.
That means that the operating system provides rigid constraints on
what the installer can do without asking the operating system.
Two options work:
1. Do not allow the application to modify anything that can affect
other applications or the system overall. In my mind this is the
typical Mac OS X approach today doing a manual install. The
application is contained within one directory (bundle). The user can
place that application wherever they want. It does NOT need to be a
priviledged location.
2. If an application must modify the system beyond its own bounds,
then the installer is forced to run within a sandbox controller by the
operating system. The operating system provides an API through which
ANY system modification is done. In this way the operating system can
audit and log any activities the installer is doing. In this way the
operating system can ensure that the operations can be undone to
completely remove the application at a later time. A user could
potentially use the install log to determine if unwanted activities
have occurred.
To emphasize what others have said... if Mac OS X moves away from its
current manual install model, it risks the same installer abuses
common in the WIndows world and one of its primary advantages over
Windows will have been lost.
> From a security perspective, I deride any Mac OS X application whichrequires an installer. I have never seen one which allowed me to
install in a non privileged location.
On Wed, Sep 10, 2008 at 9:21 AM, Scott Anguish <scott...> wrote:
> probably best not to debate this particular aspect of things...
>
> As I said, I'll about getting this clarified in the docs, and a consistent
> message in it.
>
>
> On 10-Sep-08, at 3:40 AM, Charles Srstka wrote:
>
>> On Sep 9, 2008, at 4:26 PM, Bill Cheeseman wrote:
>>
>>> The poster didn't say why he assumes the Software Delivery Guide to be
>>> more
>>> authoritative. The only evidence I'm aware of is that the Software
>>> Delivery
>>> Guide was last updated over two years ago, in July 2006, before Leopard
>>> was
>>> released. The PackageMaker User Guide is a year newer, and it states that
>>> it
>>> applies to Leopard. On that evidence, I'm more inclined to think the
>>> PackageMaker User Guide is authoritative with respect to Leopard.
>>
>> Well, the Software Delivery Guide is, as the name suggests, the guide to
>> how you should deliver software, and is not intended to be a usage manual
>> for any one specific method. The PackageMaker manual is a document
>> describing how to use one specific application for software delivery,
>> written by people who probably *would* like you to use their product. To my
>> mind, it's like the difference between getting polling data from an
>> independent polling site vs. getting data from Obama or McCain's web site.
>>
>> Anyway, if Mac software starts heading back down the road to everything
>> having an installer, the appeal of the Mac platform vs. Windows will be
>> severely diminished in my eyes. Drag and drop puts the user in control -
>> installers put the user at their mercy. Whenever I see an installer that
>> does nothing but put an app in /Applications, I tend to think twice about
>> using that app, because it's often a sign of a poorly thought out product.
>> Often I will send an e-mail to the author complaining about this as well.
>
-
On Wed, Sep 10, 2008 at 3:40 AM, Charles Srstka <cocoadev...>wrote:
>
> Anyway, if Mac software starts heading back down the road to everything
> having an installer, the appeal of the Mac platform vs. Windows will be
> severely diminished in my eyes.
I agree with you to a point, but... "severely diminished"? One presumably
will be *using* a piece of software far more often than installing it, so
let's try to keep things in perspective.
> installers put the user at their mercy
Yeah, if only there were an app that would let users look inside installer
packages... It would ease their troubled minds, so perhaps it could be
called "Peaceful" or something like that... :-)
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net -
whether it is an issue of trust or not isn't really relevant to this
list. As I said, this isn't to be debated here.
I'll see about the documentation issue, but if we're not talking
about how to construct an DMG, or installer, or the docs about it, it
is _off topic_.
On 10-Sep-08, at 12:03 PM, David wrote:
> In my mind, the installer issue is an issue of trust.
>
> Do you trust the "installer" of an application to install the
> application in the best interest of the user. Do you trust that the
> installer won't install things you don't want. Do you trust that the
> installer provides a way to uninstall the application completely when
> its done.
>
> The resounding answer to all of these questions is NO. This is one of
> the primary reasons why the Windows platform gets a black eye.
> Applications typically recklessly install themselves, overwriting
> other applications data, installing additional unwanted features deep
> into the operating system without the user being told resulting in
> spyware, nagware or annoyware under the guise of providing the user
> some wonderful feature.
>
> I've worked on many platforms for many years, from Windows to many
> varieties of Unix to mainframes.
>
> I believe that the only way to solve this problem of trust is to not
> trust the installer.
>
> That means that the operating system provides rigid constraints on
> what the installer can do without asking the operating system.
>
> Two options work:
> 1. Do not allow the application to modify anything that can affect
> other applications or the system overall. In my mind this is the
> typical Mac OS X approach today doing a manual install. The
> application is contained within one directory (bundle). The user can
> place that application wherever they want. It does NOT need to be a
> priviledged location.
>
> 2. If an application must modify the system beyond its own bounds,
> then the installer is forced to run within a sandbox controller by the
> operating system. The operating system provides an API through which
> ANY system modification is done. In this way the operating system can
> audit and log any activities the installer is doing. In this way the
> operating system can ensure that the operations can be undone to
> completely remove the application at a later time. A user could
> potentially use the install log to determine if unwanted activities
> have occurred.
>
> To emphasize what others have said... if Mac OS X moves away from its
> current manual install model, it risks the same installer abuses
> common in the WIndows world and one of its primary advantages over
> Windows will have been lost.
>
>> From a security perspective, I deride any Mac OS X application which
> requires an installer. I have never seen one which allowed me to
> install in a non privileged location.
>
> On Wed, Sep 10, 2008 at 9:21 AM, Scott Anguish <scott...>
> wrote:
>> probably best not to debate this particular aspect of things...
>>
>> As I said, I'll about getting this clarified in the docs, and a
>> consistent
>> message in it.
>>
>>
>> On 10-Sep-08, at 3:40 AM, Charles Srstka wrote:
>>
>>> On Sep 9, 2008, at 4:26 PM, Bill Cheeseman wrote:
>>>
>>>> The poster didn't say why he assumes the Software Delivery Guide
>>>> to be
>>>> more
>>>> authoritative. The only evidence I'm aware of is that the Software
>>>> Delivery
>>>> Guide was last updated over two years ago, in July 2006, before
>>>> Leopard
>>>> was
>>>> released. The PackageMaker User Guide is a year newer, and it
>>>> states that
>>>> it
>>>> applies to Leopard. On that evidence, I'm more inclined to think
>>>> the
>>>> PackageMaker User Guide is authoritative with respect to Leopard.
>>>
>>> Well, the Software Delivery Guide is, as the name suggests, the
>>> guide to
>>> how you should deliver software, and is not intended to be a usage
>>> manual
>>> for any one specific method. The PackageMaker manual is a document
>>> describing how to use one specific application for software
>>> delivery,
>>> written by people who probably *would* like you to use their
>>> product. To my
>>> mind, it's like the difference between getting polling data from an
>>> independent polling site vs. getting data from Obama or McCain's
>>> web site.
>>>
>>> Anyway, if Mac software starts heading back down the road to
>>> everything
>>> having an installer, the appeal of the Mac platform vs. Windows
>>> will be
>>> severely diminished in my eyes. Drag and drop puts the user in
>>> control -
>>> installers put the user at their mercy. Whenever I see an
>>> installer that
>>> does nothing but put an app in /Applications, I tend to think
>>> twice about
>>> using that app, because it's often a sign of a poorly thought out
>>> product.
>>> Often I will send an e-mail to the author complaining about this
>>> as well.
>>
-
On Sep 10, 2008, at 11:49 AM, Sherm Pendley wrote:
> Yeah, if only there were an app that would let users look inside
> installer packages... It would ease their troubled minds, so perhaps
> it could be called "Peaceful" or something like that... :-)
Yup, and a big reason I wrote it was to get around having to run
unnecessary installer packages.
Charles
