Re: Installer-dev Digest, Vol 77, Issue 2
Re: Installer-dev Digest, Vol 77, Issue 2
- Subject: Re: Installer-dev Digest, Vol 77, Issue 2
- From: "Hirtle, Clif" <email@hidden>
- Date: Tue, 4 Jan 2011 16:53:00 -0500
- Acceptlanguage: en-US
- Thread-topic: Installer-dev Digest, Vol 77, Issue 2
One cannot really disagree with any of the best-practice logic presented here, but equally need to remind us of the logistics of the average Mac sys admin, often the lone ranger in amongst a cadre of Windows-centric client/server teams and pulled in 10 directions of support, development, imaging, packaging, etc at once. This all too familiar environment lends great temptation to jumping on standardized tools like PackageMaker, Iceberg, and the usual suspects one hears about in official vendor training and certifications, whilst missing out or not even being aware of more comprehensive, often free tools like this.
So at the risk of running off-topic, merely want to highlight here the intersection between a spiking Macintosh user base and uncertainty in future of both Apple server solutions and community-driven support resources (ala: MacEnterprise) which have historically offered a great deal of junior-level admins ability to get on board with the Mac platform quickly and easily. One can foresee the potential absence of these creating a real vacuum in accessible, easy to use/find solutions for new or time-constrained Mac sysadmins, whom I would predict we will see more and more of as the demand to formally admin iOS and MacOS devices continue to increase.
Clif
On Jan 4, 2011, at 3:13 PM, "Don Montalvo" <email@hidden> wrote:
> Greg Neagle <email@hidden> wrote:
>
>> On Jan 4, 2011, at 11:22 AM, Hirtle, Clif wrote:
>>
>>> Dummy Question #2:
>>> If we are all creating packages for common applications like these (and assuming no custom org-specific settings), is there not a more effective means of crowdsourcing our package efforts? I am aware of the Manifest
>>> Destiny project, but seems like there might be value in sharing/vetting the same Office 2010 installation being custom created across 500 different organizations at the same time.
>>
>> All the more reason to move your customizations into a separate package -- it removes the need to create modified vendor packages. Then you can share your customizations with others without having to worry about distributing commercial software.
>>
>> This is why repackaging commercial applications is such a terrible thing. Not only is it time-consuming and error-prone, but it's very difficult to share your work. Further, it makes vendor support more difficult, because your repackaging effort may introduce issues that don't occur when the software is installed directly from the unmodified vendor package.
>>
>> -Greg
>
> I agree with Greg, why reinvent the wheel if you don't have to?
>
> We validate *all* vendor provided pkg and mpkg installers. It's been our experience that even big companies have idiots working for them who have no clue about enterprise software distribution/delivery. Witness the Citrix installer from hell (circa 2006). Let this be a lesson to the Project (micro)Manager who insisted we push it to hundreds of computers without validating first...I think he's flipping burgers in Howard Beach nowadays. :)
>
> http://donmontalvo.com/citrix/installer-from-hell.jpg
>
> Moral...trust but validate.
>
> Don _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Installer-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden