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