Is Gentoo in crisis? 199
TheCoop1984 writes "A recent article on distrowatch, and an extended thread on the gentoo forums, have pointed out that gentoo is not what it used to be. Daniel Robbins came back and went again after only a few days, developer turnover is as high as ever, personal attacks on the mailing lists are common, and people are generally not happy about the current state of affairs. Is gentoo rotting from the inside, and can anything be done about it?"
Re:A More Pertinent Question (Score:3, Informative)
Re:Hope it doesn't pass away (Score:3, Informative)
Re:What's the big idea? (Score:2, Informative)
I've been a Gentoo user for about 4 years and that's never been the goal, that's the means through which it achieves its goal.
Gentoo is a system designed to allow a user to easily put together their own personalised system aimed at doing whatever they like on whatever they like (hence the big pile of supported architectures). It's about providing as much choice as possible.
With source packages you can compile binaries to be as stable as possible (leave out GCCs optimisations) as fast as possible (turn them all the optimisations on) or even to compile small binaries (for better performance on systems with hardly any cache). See? Choice.
Easy to keep clean (Score:1, Informative)
I run Gentoo on five different systems, including a laptop and an Alpha. For me one of the big advantages is that it doesn't fill up with dozens of unwanted libraries. Let me explain: In an RPM based distribution (I have used Mandrake and SuSE) when one installs an application, it will often bring in a host of other dependent RPMs. That's just fine, and Gentoo does something similar, but what happens when you decide that you don't want the application any longer? I often install something to try it out and then decide that it doesn't do what I want. You can remove the application itself, but what about all those libxxxxx.rpm packages which it depended on. I can remove them if I can remember which ones they were, but otherwise they just hang around getting in the way.
"Disks are cheap you Bozo!" Yes, I know, but I keep my systems up to date and unwanted libraries mean unwanted security updates. With Gentoo, this problem is entirely solved with the 'emerge --depclean' command. When I emerge an application its name is added to the world file (/var/lib/portage/world) but not the names of it's dependencies. So, emerge --depclean simply looks for packages which which are not in world (or the base system list) and aren't depended on by any installed packages.
Related points: The wonder of USE flags means that many libraries never get installed at all because I can tell the application that I am not interested in that functionality. My general point also applies to cases where one upgrades an application and the new version no longer depends on a particular library.
If there are RPM (or apt) based distributions which have a similar scheme then I would love to know about it. Mandrake has (or at least used to have) a script called something like 'urpmi_rpm-find-leaves' which gave a list of RPMs which were not depended upon. By filtering the output through 'grep lib' one could get part of the way there, but it would still leave quite a few RPMs to locate by hand.
Re:Yes (Score:1, Informative)
Main problem is portage (Score:4, Informative)
A good solution would be to put portage into a
This is the kind of real, fundamental problem that gentoo should be solving. Gentoo should be the lightest distro, not a huge sprawling mess.
Re:A More Pertinent Question (Score:2, Informative)
No? Ok, then please take your ubuntu superiority myths (I don't believe for a second that you're running vanilla debian) and stuff'em where the sun don't shine. Why the heck were you doing updating a production server just to get a new version on day three after deployment anyway?
Re:A More Pertinent Question (Score:1, Informative)
Ever heard of glsa-check,
I've heard of glsa-check, even used it a time or two. All it does is tell you which pkgs you have installed which have disclosed sec. vulnerabilities. BFD.
Did you ever consider that with gentoo you can roll your own updates from upstream and test them without fear of major breakage
Oh, you mean like what debian/ubuntu pkg maintainers do for you? You know, following the debian guidelines thing?
waiting for a distro-supplied
What the hell are you on? You have to do the same thing. Wait for new versions in portage. What if the vuln is in v2 of the app and the sec. vuln. pushed the upstream to just release v3 which addresses the issue? Then you have all sorts of things to account for. New pkg version, probably different behaviour, etc. Configs? All changed. Binaries? Changed. Layout? Changed. What does debian do? Backports the fix to YOUR version. No config changes, no behaviour changes, just "fixed".
Do you claim that distro-provided defaults are sufficient configuration for your servers or that somehow debian automagically removes the need to edit config files when changes in their format/content appear once in a while and you have (gasp) new options to consider?
No, it doesn't remove the need. But you only need to do it once, unlike gentoo where you have a different version than you did 2 weeks ago, which means things have *changed*. *Changed* things require time, maintenance, testing and downtime. Config files normally (99.9% of the time) don't change in a stable release. Go ahead, read the debian policy.
No? Ok, then please take your ubuntu superiority myths (I don't believe for a second that you're running vanilla debian) and stuff'em where the sun don't shine.
Of course you don't agree, you couldn't possibly see someone running debian, right? I mean, those hundreds of thousands of installs of debian are just made up right? No one runs debian. It's not like sarge or even woody could possibly serve the function of say, a mail server, samba server, ldap server, web server, db server, etc.
Why the heck were you doing updating a production server just to get a new version on day three after deployment anyway?
Um, well, see, updating production servers is something system administrators do. It's part of their job. I don't expect you to understand, because you've clearly demonstrated that you're nothing more than someone who read a book on system administration once.
Re:Hope it doesn't pass away (Score:3, Informative)
Re:Yes (Score:3, Informative)
When Daniel was around, Gentoo also only had about 80 developers and less than 30,000 files in the tree. The package count was less than 1/4 what it is now. The bugs were still less than 25,000. There were horrible cliques within the distribution... tons of infighting. Daniel stopped doing Gentoo development long before he actually left the distribution. People seem to have this starry-eyed memory of when Daniel was around. Trust me, It wasn't a cake walk by any stretch of the imagination. While admittedly things have gotten worse of late, Daniel's presence had little to do with it. I think we would be in a similar situation had he not left. Remember that one of the reasons for his leaving was he got burnt out due to his inability to continue to manage the ever-growing distribution by himself. When he left the first time, it had already been a good year or so without much input from Daniel on anything regarding the direction of the distribution. Daniel's leaving the project didn't coincide with his reduced contributions, at all.
The biggest problem with the distribution is we are going through massive growing pains. Until recently, the leaders of the distribution were afraid to do much, for fear of upsetting developers. We've now started to realize that it's OK to upset a developer or two every now and then and that we need to work towards making the distribution better as a whole. We have been throwing around some ideas for some time and are working towards implementing them. These things take some time. Until then, we'll probably see a bit more of this sort of drivel being posted by all sorts of people. We need to get back to doing what we do best, making a kick ass distribution of Linux.