Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Wed, 2004-02-11 at 19:19, nmeyers at javalinux.net wrote: > On Thu, Feb 12, 2004 at 12:12:21AM +0000, dsr at tao.merseine.nu wrote: > > On Wed, Feb 11, 2004 at 04:19:05PM -0500, Joshua Pollak wrote: > > > Hello, I've been running Gentoo on a personal basis for a very long > > > time, but I've never used it at work. I would like to propose its use > > > here at my company to replace our RedHat 9.0 machines. > > Why? > > I run Gentoo on my boxes, but I like living on the bleeding edge. If > your company likes support and stability, it's much better off with RH > than Gentoo. > > Nathan I've been a Gentoo user off and on since early 2002, and I'm currently running it on most of my machines, including my desktop at work. Even with this, I definitely agree it's not a good idea to use a widescale deployment of machines with Gentoo. I'm actually in the process right now of fixing some problems that a "emerge -u world" caused on my machine, and I'm not running their "unstable" branch. Joshua, if you definitely want to go with gentoo, here are some I would definitely recommend. 1) Go with binary packages. Gentoo does support binary packages (although I haven't used them). You should be able to build them exactly how you want on one machine, and distribute to the rest. No need to expend binary compile time * the number of machines. 2) Compile for lowest common denominator. It'll be hellish trying to figure out why package X doesn't work, just to find out it's only broken when using P4 optimizations and you're running a P3. The speed difference shouldn't be noticable if you're not throwing anything lower than a P3 into the mix. 3) Look into the Gentoo Enterprise initiative that was just announced in last week's gentoo news letter (http://www.gentoo.org/news/en/gwn/20040202-newsletter.xml). It's just getting started, but it has similiar goals as you're discussing, and perhaps you could help them as much as they help you. 4) If you're not going with binary packages and the enterprise edition doesn't work out, consider running your own rsync repository that you update by hand. That way you can only upload the updated packages that you've confirmed work. Note that this would only be worthwhile if you're supporting a LOT of machines. If it's just a handful, fixing the machines that end up with the occasional issue might be less of a time sink.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |