[prev] [thread] [next] [lurker] [Date index for 2006/05/22]
> > In UNIX a typical package involves having files in 10 different obscurely > > named directories, with names like "/usr/sbin" that are STILL the subject > > of active debate over whetehr something should be "sbin" or "libexec". > 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. > 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. > > 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. The server version of Mac OS X is 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. 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. > 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 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. > 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. > And the OS is very clearly built out of confusing packages like Linux. It's not built of packages I need to care about. 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. > 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. > 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. Everything else can be reinstalled. The actual configuration and my own files have to be backed up and restored. > > 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. As for rootkits, tripwire watches all the files, not just the ones the package system put into place. > 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.There's stuff above here
Generated at 14:00 on 27 May 2006 by mariachi 0.52