[conspire] Ehhh... Linux image problem, ya think?

[Daniel Gimpelevich]

On Tue, 23 May 2006 13:56:44 -0700, Rick Moen wrote:

> Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):
> 
>> This is not really true as long as the software package uses Apple's
>> installer mechanism, which puts the information needed for
>> uninstallation
>> into /Library/Receipts for some unknown purpose. 
> 
> One would have little confidence that the software does that, and
> very long Mac OS experience suggests that it's probably very much a Wild 
> West situation, unfortunately.  Moreover:

I don't deny that, but the stuff that's there is there.

>> The canonical way to remove a software package has become a piece 
>> of software called Pacifist,
> 
> o  third-party shareware
> o  I see nothing on the Web about Pacifist being useful for UNinstalling
>    packages, though it's useful for repairing installed software.
>    Info page:  http://www.versiontracker.com/dyn/moreinfo/macosx/12743

Nevertheless, and this is not a fact that I like, it is definitely the
de facto standard UNinstallation tool for installed .pkg packages.

>> but I find that DesInstaller works just fine if you're careful.
> 
> o  third-party gratis-proprietary program
> o  said to be really dangerous
>    Info page:  http://www.versiontracker.com/dyn/moreinfo/macosx/13955

Again, "if you're careful."

>> The package management system is there, and is just as vulnerable to 
>> abuse by a clueless sysadmin as RPM or dpkg. 
> 
> I think the descriptions of your two cited downloadable add-ons suffice
> to show that the package management system, if "there", is very poorly 
> developed and unreliable in practice.

Oh, it is most definitely very poorly developed. As for being "unreliable
in practice," that can describe RPM as well, and if you include package
systems abused by clueless sysadmins, dpkg too.

>> The difference is that not all the functionality you'd expect is
>> included in the shipping product. The reasons for this are partly
>> historical, reminiscent of when there were no little pieces all over
>> the place, but only in one place.
> 
> Exactly my point.  No coherent management system.

The lack of coherence is an attribute not of the package management
system, but of the larger filesystem hierarchy design that the system is
built around, which compromises between the coherence of a Unix filesystem
hierarchy and the lack of coherence in Mac OS.

>> You mention a "full system rebuild" above, but that's
>> something unique to the Windows world.
> 
> No it's not.  Daniel, don't forget, I've been using MacOS versions all
> the way back to the 128K Mac with MFS filesystems.   In the 1980s, in
> the days of System 6.0.x and 7.x, I was the MIS Department for an entire
> software firm full of Macs, and every other week, some yoyo from the
> Sales Department would haul in his Quadra (I rated only a IIci) for
> rebuild because it had gotten so screwed up.

I have not forgotten that, nor have I forgotten how mind-bogglingly
non-trivial it was to accomplish a full system rebuild of 6.0.x or 7.x
(or even worse, a 6.0.x/7.x dual boot system, which was not uncommon for a
while). Any place that had a concentration of people even slightly
experienced in such system rebuilds saw a disproportionately large number
of people needing help with such. Everybody else just made do with their
screwed-up systems.

>> Typically, a Mac's HD never gets reformatted during the entire life of
>> the HD in that machine, and the OS never gets reinstalled.
> 
> Actually, what is _most_ typical is that the Mac OS user suddenly
> realises he's completely out of disk space, and has absolutely no clue
> about what to do about it, having absolutely no conception of overall
> system management.  These people used to bring their Quadras to my desk,
> too: The inevitable solution was to deploy a bigger hard drive for the
> user, and copy the whole huge mess of his/her volume over.

Correct, and this further illustrates and supports my above claim.

>> The need for package management is a reflection of the complexity of
>> the filesystem hierarchy imposed on the user, because its function is
>> the automation of compliance with that hierarchy.
> 
> Actually, the need for package management exists irrespective of that.

Not sure how that follows from what I said here...

>> Traditionally, the Mac made absolutely zero imposition of filesystem
>> hierarchy on anyone, so the existence of package management would have
>> addressed a need nobody had.
> 
> This is just plain wrong.  Nope.  I can't tell you how much easier real
> package management would have made my life as a Mac OS network admin and
> MIS guy.

Below, I said "Of course, that doesn't mean that using package management
on OS X can't be superior to not doing so," specifically to address this
point of view. When I say that it was traditionally a need nobody had, I'm
referring to early traditions from before networking entered the fray in
any real way, which carried over into the networked world you describe
despite changing needs. Unless you're disagreeing with my assertion that
there was zero imposition of filesystem hierarchy...

>> People coming over from Windows keep asking how it's possible to run a
>> system without anti-virus and anti-spyware software, and that's no
>> different from you asking how it's possible to run a system without
>> package management. 
> 
> Actually, those are very fundamentally different topics.  I haven't made
> a specific study of the subject (it not being within my areas of
> interest), but I'd guess that OS X's main protections against malware
> are (1) relatively careful design of userspace apps that handle public
> data (the ex-NeXTMail app, Safari, various media players, (2) Software
> Update, and (3) use of privilege separation / sudo.

The pieces of software themselves are very fundamentally different topics,
yes. The ways people think about them are not.

> It's possible to run a system without package management because, well,
> it's _always_ been possible.  It merely sucks.  It's always sucked before,
> it does now, and it will in the future.

Comparing Mac OS's disdain for package management to the way Slackware
used to treat the same is apples and oranges. And Slackware is just an
example here.

>> Of course, that doesn't mean that using package management on OS X
>> can't be superior to not doing so, but that is left up to the user as
>> a stark contrast to the ill-advisedness of software installations
>> outside the confines of the package management system in use on a
>> Linux distribution.
> 
> How is having unmanaged, locally-installed software any _more_
> ill-advised on, say, Ubuntu than it is on OS X?  (I pick Ubuntu because
> it has a roughly similar privilege-separation model, though OS X's 
> default ownership/rights are rather dangerously loose.)  I agree that
> it's a bad idea -- but equally so on both.

That depends on exactly how you choose to define "locally-installed
software" and on the exact manner of installation. There would be many
degrees of undesirability, but there would be more installation processes
that would be less desirable on Ubuntu overall, and the reasons for this
go back to maintaining the consistency of the filesystem hierarchy, which
is something that on Ubuntu lends itself more to automated processes, and
on OS X lends itself more to manually sticking things wherever.