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
    >
  • On 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 package­based 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
  • I 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 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 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
previous month september 2008 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
Go to today