Gotta love Stewart for keeping me honest! Stewart Stremler wrote: > John H. Robinson, IV wrote: > > So it's just a matter of scale? Large collections of computers > do change the tradeoffs, but if you're running that big of a shop, > you ought to be able to afford an OS that comes with professional > 24/7 support.
For the Big Iron servers, I would agree. With the multiple desktop / lab systems, I might argue with you. > The 28-minute delay argument is a bit disingenuous. A bit, I have to agree with you. But t illustrates a point: the point being that when a vulnerability is going to patched, the vendor will alert the OS distributors ahead of time, so they can have the patched packages ready at the time the announcement is made. With portage, you are still stuck with the download / compile / install. > If you REALLY want to make sure you get your services patched as fast > as possible, you'd be downloading the source, compiling it locally, > and installing it yourself anyway. You are too used to how long it takes Sun to make patches available. > > There may be a way to build once, then install many times with Gentoo. I > > honestly don't know. If this were the case, why bother with the whole > > compile on the end user system? > > It's called rsync, yes? :) Maybe. There may be some parts of the emerge that do local things, (hopefully restricted to /etc and the like) that are not as well suited to rsyncing. The binaries should be able to be rsynced without a problem. > > Another drawback is that you are now a QA department of one. When > > something in a package beaks, why did it break? What was it compiled > > against? What options were used? What optimisations? You may very well > > have a very unique package, and the Gentoo maintainer (or whatever the > > equivalent is) could be at a complete loss. > > I must admit, this seems like a short-term gain, long-term benefit. If > the Gentoo community can influence developers, then making sure code > compiles on a wide range of systems with a wide range of compiler > versions using a wide range of compiler options would be a good thing. Do you want to know what distribution really helps vendors clean their code? Debian. Because of the *sheer number* of architectures supported. One of the Gentoo faqs included something about -O9. Okay, veering away from apt vs portage. Let me try to get back to that, instead. > Code that breaks if it isn't compiled *just* *right* is not a Good > Thing. Pressure on developers to avoid such things is actually of > benefit to all. Granted. > If there are interesting synergistic effects, there's been a failure in > modularization. If we just accept such things as commonplace, instead > of demanding that such things be rare, we're doing the same thing that > Microsoft has done with reboots/reinstalls -- training users to just > accept the crappy solution by not presenting anything better. Also granted. With a QA department of one, those rare times are still very hard to resolve. > What if you're not using _quite_ the same configuration as some > Debian testbed? "Why bother?" is a call to conformity to what is > supplied, and if you don't have the same sort of system as what is > used by the centralized system, well, tough noogies. > > (Yes, Debian broke X on SPARC, and it hasn't been fixed, and nobody > has offered any useful advice ["give me a remote root login" doesn't > count] in six months. Why? Not many people bother with Debian on > SPARC32 anymore -- whoops.) I remember you discussing this problem before. I had mixed results with Debian Sparc, myself. > > I still have not found any good argument *for* other than having > > to/getting to compile oneself. > > In theory, compiling locally lets you reconfigure the filesystem to > some other standard, which you can't do with binary-only distros, > as many programs hard-code in paths. Indeed, it seems the ELF format > uses hard-coded paths in the binary. I wonder how much one would have to muck with the build scripts to do that. I can't find a good answer. -john -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
