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

[Rick Moen]

Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):

> 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."

OK.  In fairness, I'm not very sure how much software for OS X does
bother to use the system-registration mechanisms, since the latter's
very existence is news to me.  I was going by what seems likely, based
on what I _have_ seen.

> >> 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.

Ah, noted.  (I didn't catch that, sorry.)  

I'd be the last person to make excuses for RH (et al.)'s rather fallible
BerkeleyDB-based system, but I can swear it's at least gotten a lot
better in that area.  One of the nifty things about the Debian (and
compatibles) architecture is that there are well-tested ways to 100%
recover from a damaged or lost package database -- and also to rebuild
completely if you _do_ have the database but clobbered /usr.  Karsten
Self and I (among others) worked out those things, and you'll find them
documented at links from http://linuxmafia.com/kb/Debian/ .  To my
knowledge, there's nothing remotely similar for RPM-based systems
(though I could be wrong):  If you lose or scramble the DB files, you're
screwed.

This _can_ and should be protected again, by prudent admins of RPM
systems, by backing up /var/lib/rpm/* off-system, however.

> Other than that, like dpkg, unreliability remains
> caused almost solely by abuse, i.e. venturing outside the regime.

OK, I do think we're on the same page.  Sorry if I sounded a little
cranky:  Too many years saving MacOS users from their own lack of 
caution and foresight, and not getting paid enough for it.  ;->

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

Well, first, I wouldn't really mourn much.  ;->

But I can envision ways to extend classic freenix package regimes to
accomodate arbitrary non-OS-vendor sources.  If you don't mind using the
OS vendor as clearinghouse, the OS vendor's master signing key can be 
used to vouch for third-party VAR keys, which in turn are used to sign
packages distributed to users.  In the Mac OS X case, it'd be "My system
trusts new package Foo because Apple has the maintainer signing key in 
its keyring, and so doesn't pop up a warning message."  Otherwise, if
you don't want to have the OS vendor in that role, vendor public keys 
can be made available in other ways, e.g., you trust that the printer
driver package is really from HP because you _think_ you trust your
nameserver and routers to get stuff from the real www.hp.com host.
(That trust model is a little if-ey.)

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

Well, *I* sure don't.  ;->


> 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.

Well, yes, it's not so much a case of "required" as of "you might as
well, at that point".

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

I have many skills, and that's one of them.  ;->


> 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").

Noted.  But a basically invisible system facility, absent knowing that
you can get at it using third-party shareware, isn't really impressive.


> In Ubuntu, locally installed software, managed or not, has to at least
> respect the confines of the FHS.

Not if you compile qmail from the source tarball.  ;->

Eh, we're basically on the same page.  Noted that the OS X .app is
_supposed_ to stay self-contained -- but I keep finding pieces of 
things in odd locations anyway.  (I can't remember where, and don't have
the G3 beastie in front of me.)