[prev] [thread] [next] [lurker] [Date index for 2006/05/22]
On Sun, 21 May 2006, Peter da Silva wrote:
> > That's just semantics, and I don't really care. Pick something, record it
> > in your package manifest, and do it consistently; that's all I care about.
>
> I like not having to record it anywhere because it's obvious what it does
> from what it's called and where it is. Having to grovel through what-
> package-system-does-THIS-box-use-again is hateful.
Really? What is /usr/include/ltdl.h for? I certainly couldn't guess from
what it's called or where it's located.
> > For instance, in the process of getting DarwinPorts set up yesterday, I had
> > to install the X11/Intrinsic.h header. You probably have that header on
> > your computer. You could certainly use find or whatever to find it, if so.
> > Upon finding it, could you tell me what package installed it? That's the
> > "why" I'm talking about.
>
> It was installed by Apple X11 or the Apple dev kit, and since I'm never going
> to NOT install them both with all the packages included... I don't care.
>
> It's an OS package. It's not optional. It's part of the core.
It *is* optional. In fact, the X11 SDK is one of about 12 optional SDKs,
along with a GB of optional developer documentation. Considering that my
machine has only a couple of GB free, it's important to conserve where I
can.
This is one of the things that sucks about OS X -- "I don't know what you
need, just install all 25GB and be done". Yeah, thanks.
> > > In OS X a typical package involves having one directory tree sitting
> > > in any convenient folder.
>
> > I'm not convinced. None of the OS packages are that way.
>
> Why would I ever *not* install any of the OS packages on a desktop OS that's
> chewing up tens of gigabytes no matter what I do? This isn't a server OS, and
> it's never going to be lean and mean enough to make it worthwhile trying to
> make it one.
I'm already almost out of space -- I was down to 65 MB yesterday. Good
enough reason? Thanks.
> The server version of Mac OS X is FreeBSD.
God forbid I ever pay to run FreeBSD.
> > I have maybe installed 10 packages on this machine, which means that my box
> > shipped with ~90 packages installed.
>
> So? Those 90 packages are always installed, why should you care? They're the
> core system.
The point is that those 90 packages break your whole definition of how OS
X's packaging system is so simple. Sure, the apps are easy, but the OS is
not. That may be fine for you and your one machine; I can tell you from
experience that those with tens, hundreds, or thousands of macs do not find
it so trivial or ignorable.
> Linux doesn't have a "core system", so you have to know what's there. The
> upside to that is you can control what's in your system a lot more precisely.
> The downside is you have to know what's in your system a lot more accurately.
BS. Debian has a core, Red Hat has a core, Gentoo has a core, Solaris has a
core. Yes, these are customizable. Isn't that a feature.
> > Eh, I don't agree. I've managed packages that way on Unix, linking things
> > back to /usr/local or whatever, and it's not much easier.
>
> Not the same thing at all.
>
> You don't have to link them back to /usr/local-or-whatever on Mac OS X.
I can still rm -rf /path/to/my/path, and the app goes away. So some
automated tool has to clean up the dead links; so? What do I care?
> > I can whip up a
> > script in four languages to uninstall a package by hand for any of multiple
> > decent package formats -- rpm, dpkg, emerge, whatever -- as long as I can
> > ask the packaging system, "what files are associated with this package?"
>
> For Mac OS X, for any package you're normally going to have a reason to
> uninstall, you do it with "rm -r /what-you-use/Applications/Packagename.app".
>
> Except for the idiot programs that do their own installer thing.
I don't care about uninstall; I care about upgrading, and whether there's an
upgrade available, and I care whether a given package's install has drifted
in any way.
> > With dpkg, I just say, dpkg -L <package name>. I don't care where the files
> > are; they could each be in a directory named for the file's checksum for all
> > I care, as long as the package works correctly and I can use tools to do all
> > the necessary work.
>
> I see having to have that tool as a problem. I increasingly hate the whole
> UNIX /usr/ hierarchy. I was already tendin that way when I got into Mac OS X
> and it's become so finely focussed by the experience of a system that doesn't
> work that way.
I can't believe you don't want some sort of ability to discern the meaning
behind a file. Wow.
> > And the OS is very clearly built out of confusing packages like Linux.
>
> It's not built of packages I need to care about.
Then I'm not complaining for you, I'm complaining for those who need to
actually manage their systems, not just ride them.
> I can't not care about Linux packages, because there's no core system (whether
> that's a common set of packages, or a common tree and some contrib packages,
> or whatever) that's always the same. Even with the same distro and version
> two linux systems set up by different people are unlikely to have the same
> core.
That's silly. I certainly hope you've tried this with Debian, to make such
a sweeping statement about "linux", which, again, doesn't exist as an
operating system. Certainly the kernel has no core, just like Mach has no
core.
> > You're glossing over that and just talking about the applications, many of
> > which aren't nearly as pretty as you make out.
>
> There are hateful applications that don't do packaging right, yes, and they
> are worthy of hate. Because they don't do it right.
Or because their needs are such that they can't do it "right", because the
packaging system is too primitive.
> > Files can't get corrupted? Permissions can't go wrong? Ownership can't get
> > messed up? Software can't get rooted? Ever? How do you know?
>
> I don't, and I don't know that on your Debian system either. Except for the
> ones put in there by the package system, which are hardly ever the ones I
> care about... the ones I care about are the ones in $HOME, and the
> configuration files... the ones that aren't the same as in the package
> system.
I kind of agree with that -- I agree we need a mechanism to care about those
files, which is one of the reasons I've developed Puppet.
> Everything else can be reinstalled. The actual configuration and my own files
> have to be backed up and restored.
How do you know if you have to reinstall? Just wait for all hell to break
loose?
> > > Erm... what? I know it can answer the question "what packages do you have
> > > installed", but that's a long way from "are you configured correctly".
>
> > Any package management system worth its salt can exhaustively tell you
> > whether every single managed file has the right mode, ownership, and
> > checksum. It might take an hour, but it'll tell you.
>
> That doesn't tell me if ANY of those packages are correctly configured.
Sorry; I used the wrong word originally. It should have been "still
installed". Are they still installed correctly, or has there been drift?
Can I ask the computer any meaningful questions about itself? Shouldn't I
be able to?
> As for rootkits, tripwire watches all the files, not just the ones the package
> system put into place.
Yeah, but it's entirely without meaning -- say file X changed; do you know
why? Was it intentional? Was it accidental? Can I recover?
Tripwire is a crappy band-aid on a problem the OS should care about.
> > Apache's log files all need to
> > exist and be owned by the apache user or it won't start; are they? How do
> > you know?
>
> I have NEVER creates any of apache's log files, and I have NEVER had apache
> fail to come up as a result. They're all there in /var/log/httpd.
Well, then apache has write access to all of your log directories. It
doesn't have write access to mine. Mine way's easier to automate, easier
to manage, and easier to segment. Your way requires less ability to
interact with the computer.
--
Be wary of the man who urges an action in which he himself incurs no risk.
-- Joaquin Setanti
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
There's stuff above here
Generated at 14:00 on 27 May 2006 by mariachi 0.52