I can't disagree with you on that one.... Gentoo and other source based distros offer a lot more then the binary ones do. But more care has to be taken when you use a source based distro on a production server. If you have the time for this then all power to ya :) It will probably save you a lot of headaches too since you aren't using RPM. I don't like RPM either, which is why I haven't used Redhat on my desktop for a long time and why I've been using Gentoo. RPM is fine for the average user be it workstation or server but it absolutely sucks for the power user or for someone who wants more out of their boxes. I've always used Redhat for my production servers because I only usually have problems with RPM when it comes to things that are running on the desktop (KDE, Linux DVD, etc). But, when I get home I play on Gentoo :)
>> > I stand by the comparison. Where RH or Windows needs patches and >> fixed installed after the fact, Gentoo is current as of the date of >> install. >> >> which is why modern installers support automatically grabbing updates >> that > are >> available once the base install is done! >> >> > The time spent compiling is irrelevant. >> >> the time spent compiling is completely relevant, since you'll be doing >> it until the day you get rid of that system or stop updating it. but >> what's > more >> important is the ability to verify the integration of packages you >> build > from >> source. binaries are far, far more easy to accomplish this with... >> >> > Wasn't Aaron's advice for someone in the last 2 days to install Mdk >> 8.2 rather than 9, simply because 9 was "unfriendly" on his system? >> >> no it wasn't. i suggested trying another distro such as SuSe 8.1 ... i > didn't >> suggest going backwards, though they are free to if they wish. some of >> us aren't stuck on pushing a single distro as the One True Thing and >> have no problems with someone trying MDK9, finding it isn't "for >> them", and trying SuSe 8.1 (or whatever else)... >> > > If you check my past posts, I clearly do not think Gentoo is the only > way to go. I've recommended SUSE, I've recommended Red Hat, I've > recommended Knoppix. They each have their purposes. You clearly > understand that each distro has a particular target. > > In the last month, I've installed RH 7.3 and Gentoo for servers. One > isn't better or worse, each is suited to a particular purpose. > > >> > Gentoo is simply up to date when I install it. Period. My servers > don't >> > go into production until I'm happy with how they are working. >> (Linux, > or >> > Legacy). >> >> wow, just like all the other distros i've installed in the last 2 >> years. > > This thread started out focusing on install time. Installing an old > package with the intention of immediately replacing it is a waste of > time. Should people install KDE 3.00 then every version up to current, > or should they just install the current version? Gentoo's packaging > system assures me that I have current the first time out. > > Perhaps the ultimate would be a system where RH went to a central > repository and pulled current RPMs when it first installed. That is a > goal for Gentoo as well. But that doesn't change one aspect of the > problem. Precompiled binarys are "best fit" guesses. Samba RPMs will > not support various aspects of PDCs when installed from RPM. They NEED > to be installed manually. How many configure options are there for KDE? > Does an RPM support all of them, or none of them? > > >> no. control during install doesn't mean a lot, especially since that >> represents one or two hours of what will be a years-long experience >> with that machine. perhaps i'm just speaking from having dealt with >> lots of systems for years at a time. > > Control does mean a lot. Control during the install means that the > system when it goes into production will be running at its best. I've > also administrated systems on a global scale for years at a time. > Setting it up correctly in the first place is by far the biggest issue, > as far as I'm concerned. I've mentioned Novell before, and I'll do it > again, there simply is nothing that can simplify administration like NDS > or ZENworks. > > I'll give you an example. I just set up my Gentoo box. Getting ACL > support installed was simple. I enabled it in the kernel. Compiled, > and now I'm done. > > Alternately, I have a RH7.0 box in Ontario. I'd like to install ACL > support for it too, but I can't find a 2.4.19 Kernel for RH 7.0, and I > can't find ACL patches for anything earlier. (Could be 2.4.18,). > Meanwhile, my list-lurking co-worker is currently installing RH 8.0. > After installing RH 8, She downloaded kernel patches, and applied them. > She is now recompiling the kernel, and getting it running. > > So, > Both required a kernel compile. > Only the Binary distro required patches. > Once installed, the Binary distro didn't include tools for using EA and > ACL FS support (holy acronyms, batman) Source did. > An older install for RH doesn't allow these features at all, whereas a > same age version of source based distro would have. > Well, I can install these features on the older version of RH, but only > by making it non-Red Hat in several places. > When RH8 does finish installing, Samba RPMs will not include ACL > support, so she'll need to DL and install that as well. > > So what we found is that source-based (I won't push Gentoo, there are > others (happy?)) offers more flexibility and more features than binary > based. Further, because the Binary system now uses an un-official > kernel, with un-official FS utilities, I would always worry that up2date > will at some point screw over the whole file system's permissions. > > Overall, both systems have been a ugly to install. > Gentoo used devfs, and Compaq's driver wasn't fully compliant, in the > end, I used the onboard RAID controller for the boot device, I have not > followed up to see if the driver was fixed, frankly, I don't care. I > won't need a 64bit I/O channel to the (unmounted) /boot partition.. > The RH box has been a PITA for her to get running with ACL FS support. > When it does eventually get going, every other aspect of RH will assume > that box is a normal RH install. Since it isn't, that will mean that > for the life of this box, there will be concerns about having files > overwritten that RH thinks are OEM, but which are not. > > The Binary distro will clearly be uglier to administrate going forward. > > Kev.
