1 |
Mike Myers <fluffymikey <at> gmail.com> writes: |
2 |
|
3 |
|
4 |
> Hi! I know I don't post here much but I read it a lot and have been using |
5 |
Gentoo for several years now. I keep seeing users mention about how they do an |
6 |
update and then everything goes to crap. I've experienced this myself quite a |
7 |
bit too. I believe the reason this happens is the drawback one of Gentoo's |
8 |
nicest features; constantly being up to date. |
9 |
|
10 |
|
11 |
Hello MIke, |
12 |
|
13 |
Folks probably will not like my suggestions, but it works |
14 |
in lieu of a better schema, so aplogies to all I offend, in advance........ |
15 |
|
16 |
Gentoo servers (firewall, dns, mail, web ...) rarely suffer from these |
17 |
issues, in fact, I believe one of gentoo's largest unexplored niches |
18 |
should be Large Installation System Administration (via cfengine). |
19 |
|
20 |
So, in my opinion, where Gentoo is really challenged, is the workstation |
21 |
(laptop, desktop....). You know the X11 + kde/gnome software boxen. |
22 |
What I do is keep one (workstation) system |
23 |
on the bleeding edge (very frequent upgrades) so as to discern |
24 |
where breakage or unecessary updates are looming. Since I admin an ever |
25 |
expanding hoarde of gentoo based servers and workstations, development |
26 |
of some tools to compile, distribute and manage the various x86 and amd64 |
27 |
machines we have, is way past due. As soon as I have a scheme I'm |
28 |
happy with, we'll be deploying lots of embedded gentoo based systems. |
29 |
|
30 |
So I update the test workstation on fridays, use it over the weekend a |
31 |
nd then update the other systems. Granted, if the devs release something |
32 |
(broken) over the weekend, I get screwed with this scheme sometimes. |
33 |
I should update the test system daily (in the mornings) and then |
34 |
update the other systems on the same day after that. |
35 |
|
36 |
Problems with that scenario is the various methods of proxying the |
37 |
downloads and syncs are problematic in and of themselvs, not very |
38 |
often, but still bad enough to make those current schemes, less |
39 |
than desirable. Futhermore, DistCC is still a 'work in progress' |
40 |
and I've experience just enough hassle that it has been disabled |
41 |
(also due in part to so many different variants of x86). |
42 |
|
43 |
Long story short: Gentoo is the best distro for our work, as one only |
44 |
has to installed debian, suse, or redhat for a week or two, to realize |
45 |
just how spoiled you get with Gentoo. That said, I've learned to be |
46 |
cautious and patient with key software upgrades on Gentoo. However this |
47 |
approach burns lots of extra time. My hope is Gentoo will continue to |
48 |
improve and become more of a 'production' distro, as the other Linux |
49 |
distros all seem to have unacceptable flaws, for our needs. |
50 |
|
51 |
Future: |
52 |
What is really needed is a group of users, with similar needs, to define |
53 |
commonality of core applications that are essential to the needs: What |
54 |
this means is a list of software, for example openoffice, kde-meta, apache, |
55 |
java, perl, python, C, etc. that forms a core of what we all need (not what |
56 |
we want). Then set up cfengine to push binaries, via a trusted mechanisms, |
57 |
to each of the arch categories) Maybe on a weekly basis. Each |
58 |
network, business or usergroup, would use their test system for 24 hours |
59 |
as a quarrantined update, before pushing to the rest of their machines. |
60 |
Or maybe push sources that are know good, to the test server at each |
61 |
participating location. |
62 |
|
63 |
If fact what the one (initially) master server environment sets up |
64 |
uses, could be duplicated at any remote location with a group of systems. |
65 |
Individuals could feed (download binaries) from those locations, with |
66 |
the proper security mechanisms agreed to. If a group of locations |
67 |
with multiple systems use a common update semantic, then it would be |
68 |
a lot less work, as opposed to each cleaver admin, rolling their own |
69 |
solution..... If something actually worked reasonable well, talented |
70 |
admins could offer this service to commercial clients, thus generating |
71 |
excitement about gentoo, and funding for many needy geeks..... |
72 |
|
73 |
If you only have one or 2 gentoo sytems, something like this is not worth |
74 |
the effort. For those of us looking to manage dozens to hundreds of |
75 |
gentoo based systems, the need for some management scheme, is long overdue. |
76 |
JFFNMS goes a LONG way to solving the problem, but, it is not |
77 |
centric to the needs of gentoo systems. A companion project |
78 |
that addresses all of those gentoo_centric issues could compliment |
79 |
JFFNMS and simultaneously created that quintessential opportunity |
80 |
for Gentoo to really shine, compared to it's competition. |
81 |
|
82 |
|
83 |
|
84 |
James |
85 |
|
86 |
|
87 |
|
88 |
-- |
89 |
gentoo-user@g.o mailing list |