1 |
I can only agree with Mark, I use Gentoo extensively at home, and love it. |
2 |
|
3 |
But at work (Telco environment) I wouldn't recommend it, there we go with Red |
4 |
Hat Linux (surprise surprise ;-) ) when it comes to Linux, otherwise we're |
5 |
using HP-Unix and Sun Solaris extensively. |
6 |
|
7 |
Personally I'd prefer for a server environment Debian which for a company got |
8 |
a stable and long release cyclus (even though it's nowhere as flexible as |
9 |
Gentoo....) |
10 |
|
11 |
It's basically all boils down to production stability and knowing your |
12 |
environment from a to z. |
13 |
|
14 |
--Robert |
15 |
|
16 |
On Tuesday 15 May 2007 19:13, Mark Rudholm wrote: |
17 |
> Andrew Gaffney wrote: |
18 |
> > A. Khattri wrote: |
19 |
> >> I have no problem with change as long as there is an easy way to keep |
20 |
> >> what |
21 |
> >> we have. After all, Gentoo is about having a choice and removing the |
22 |
> >> apache flag from PHP without providing some other mechanism to keep it |
23 |
> >> is simply removing choice. |
24 |
> > |
25 |
> > I see this type of argument used all the time. Some people just don't |
26 |
> > seem to get the fact that all Gentoo devs are volunteers, and we will do |
27 |
> > whatever makes it easier on *us*. If you don't like it, don't bitch |
28 |
> > about choice. You have the *choice* to learn how to maintain the stuff |
29 |
> > yourself and not complain. You don't pay for Gentoo, so you don't have |
30 |
> > the right to tell any Gentoo dev what to do with their volunteer |
31 |
> > time.</rant> |
32 |
> |
33 |
> If people are using this argument all the time, it might be |
34 |
> worth considering why they are. |
35 |
> |
36 |
> Gentoo tends to remove packages or change them in a way that |
37 |
> is not rearward-compatible more readily than other distributions. |
38 |
> I understand that the labor is all volunteer, however, other, |
39 |
> more stable/mature distributions are also all-volunteer, but yes, |
40 |
> that's the way it is. People spend their volunteer time as they |
41 |
> see fit, I understand this completely. |
42 |
> |
43 |
> The result, however, is that Gentoo becomes an inappropriate |
44 |
> choice for a production server deployment. I haven't suggested |
45 |
> Gentoo for production servers to anyone (especially my employers) |
46 |
> since somewhere around 2003 for this reason. |
47 |
> |
48 |
> At work, my team of a few dozen people support tens of thousands |
49 |
> of Linux servers. We wrote our own tools for installation, |
50 |
> distribution, and maintenance of OSes and package sets. There was |
51 |
> a time when I considered that we could use Gentoo. Our own custom |
52 |
> Portage repositories could be maintained, and the portage tools |
53 |
> would cover a lot of the things we need to do very nicely. It'd |
54 |
> be great to build on the work of other Gentoo contributors, and |
55 |
> we'd no doubt join the larger community of contributors. But I |
56 |
> simply can't recommend this. The Gentoo developers and packagers |
57 |
> in general seem more interested in the latest shiny thing rather |
58 |
> than stability, reliability, and predictability. Fine for a desktop, |
59 |
> but antithetical to the needs of people running mission-critical |
60 |
> server farms. As you point out, it's entirely the prerogative of |
61 |
> the developers and packagers to set their own priorities, and I |
62 |
> agree of course, but do be aware of the results of the choices of |
63 |
> Gentoo packagers and developers and how they collectively create |
64 |
> the personality of the distro and how that personality effects the |
65 |
> choices of other potential contributors and users of Gentoo Linux. |
66 |
> |
67 |
> -Mark (who uses Gentoo on his personal systems these days) |
68 |
-- |
69 |
gentoo-server@g.o mailing list |