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

[Daniel Gimpelevich]

On Tue, 23 May 2006 16:29:36 -0700, Rick Moen wrote:

> Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):
> 
>> Nevertheless, and this is not a fact that I like, it is definitely the
>> de facto standard UNinstallation tool for installed .pkg packages.
> 
> Again, quite a lot of software isn't installed from .pkg files --
> because there is no enforcement, either by conformance testing or by
> cultural expectation.

I believe I said that later in the message: "Some OS X software is still
like that, which is why it will lack any sort of installer other than the
sysadmin's act of copying a folder over."

>> 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.
> 
> No, there's quite a huge difference.  The RPM/dpkg regimes of distros
> based on those are a prominent, nearly pre-eminent feature that the new 
> admin is pointed to forcefully -- and routine software installations are
> expected to be compliant by custom and culture.  Going outside those
> regimes for installation and maintenance (even only by fetching packages
> from out-of-the-way sources) requires a very definite act of will that,
> by design, should leave admins with the nagging feeling that they're
> doing something questionable that might be risky.  

My stab at RPM here was a reference to the recurring hell of package
database corruption. Other than that, like dpkg, unreliability remains
caused almost solely by abuse, i.e. venturing outside the regime.

> If the admin heeds that nagging feeling and doesn't venture outside the
> regime without very compelling reasons, then he/she will find it _very_
> reliable in practice.  In the alternative, after the admin does
> otherwise and shoots a hole in his/her pedal extremities, whole
> communities will gladly point out that fact and suggest how not to do
> that again.
> 
> None of that is true on OS X.

You're tying package sources into package management systems. That would
spell immediate death for a proprietary OS.

>> 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.
> 
> No, that's really quite irrelevant, in the most literal sense of the term:  
> A proper package-management regime knows where all of a package's
> compenents went, irrespective of hierarchy design.  You can have a
> strict hierarchy, a loose hierarchy, or complete anarchy, and the 
> regime still works equally well.

In contrast, on OS X, the sysadmin knows where all the components went,
ideally.

>> 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.
> 
> The point, which I said explicitly, is that a system so badly screwed up 
> as to need a full system rebuild is hardly "something unique to the
> Windows world".

There is a difference between needing a full system rebuild and getting
one. I initially pointed out the lack of the latter, not the former.

>> Correct, and this further illustrates and supports my above claim.
> 
> No, it was a _digression_ from that discussion.  
> 
> Although exhausted storage was, as mentioned "the _most_ typical" MacOS
> user's hard disk problem, I fairly frequently had to reinitialise 
> HFS volumes on account of virus problems (not so far a significant
> problem on OS X, by contrast) or other causes of systemic damage to 
> critical system files/folders.  

In my experience, that kind of damage almost never required a reformat,
although reformats would always make the repairs less challenging, if you
catch my drift.

> Now, you might say that, typically a Mac _OS X_ HD never gets
> reformatted during the entire life of the HD in that machine, and that 
> the installed _OS X_ never gets reinstalled.  (In that sense, it's 
> a pretty typical *ix.)  However, that's not what you said.

Was also true of OS 9. 7 is another, far less summarizable, matter...

>> > Actually, the need for package management exists irrespective of that.
>> 
>> Not sure how that follows from what I said here...
> 
> See above:  Whether there is a specific filesystem hierarchy or not, 
> a proper package system remains desirable regardless.

By "proper" I read " != the sysadmin"

>> 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.
> 
> OK, noted.  I know the mindset well.  I just never found it to be a
> reasonable viewpoint.

It's more a phenomenon than a viewpoint...

>> The pieces of software themselves are very fundamentally different topics,
>> yes. The ways people think about them are not.
> 
> I'm trying to follow your point, here, and thus far not getting it.
> Honestly, probably my fault.

Another example of the fact that I suck at explaining things...

>> 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.
> 
> Huh?
> 
> I hope you don't think I'm much of an admirer of Slackware's installpkg
> / *.tgz regime, where there's sort-of a package database, but no record of 
> dependencies (unless one uses Swaret).  Still, at least there was that
> much.

You were hinting that both are equally bad in the same ways, and I'm
saying that's a hasty generalization.

> On OS X, you're talking about a situation where a
> behind-the-scenes system facility exists that installed software can
> talk to but often doesn't, and no local-admin access to or even
> knowledge of that information without fetching and installing
> third-party proprietary tools.
> 
> Again, I'm really not following your point.  Sorry.

The third-party proprietary tools are but largely front-ends to included
command-line based tools, which in turn overlay tar/cpio through pax
(hence the name "Pacifist").

>> That depends on exactly how you choose to define "locally-installed
>> software" and on the exact manner of installation.
> 
> I saild "_unmanaged_, locally-installed software", i.e., software
> installed outside the system package regime.
> 
> So, if you're saying that's a worse idea on Ubuntu than on OS X, I am
> absolutely not seeing it.  Seems like the same problem -- except that,
> for practical purposes, _all_ software installed on OS X is unmanaged
> (since there's effectively no real use of the regime you pointed to
> and effectively no admin access to it within reason).

In Ubuntu, locally installed software, managed or not, has to at least
respect the confines of the FHS. In OS X, it's all outside the FHS anyway,
but it's at least supposed to be self-contained, so the .app _is_ the
package, and treating it as a whole _is_ staying within the regime, while
manipulating individual files inside the .app is venturing outside the
regime. Are you still thinking so inside the box that you still can't see
the unmanaged installation of software on OS X as being a package
management system in itself? The only way Ubuntu can even come close to
such a system is with Klik.