I wouldn't say that gentoo is based on BSD, since it's a linux distro - but it's pretty evident where it got the "portage" idea from...
-f0dder
You don't need to say it. Gentoo did:
What is Gentoo?
Gentoo is a free operating system based on either Linux or FreeBSD that can be automatically optimized and customized for just about any application or need. Extreme configurability, performance and a top-notch user and developer community are all hallmarks of the Gentoo experience.
http://www.gentoo.org/main/en/about.xml
Btw, gentoo isn't made superfluous by advances in hardware, it's just as much about having configurability options.
Agree. But to what point? If you're looking to improve performance, it becomes somewhat pointless to spend dozens of hours researching what compilation flags to set in order to squeeze a 5% improvement in efficiency on a specific platform. You could just invest in more RAM or a faster processor.
Now I agree that it might be worth it if you were doing a
Gentoo Stage-3 install as a learning experience Or if you wanted to do it for pure technical aesthetics. That's one advantage of being a student, a hobbyist, or a tech person. You get to do things like that.
I fit into the third group, so I made it a point to do a few "Stage-3's" just to find out what Gentoo was all about. And when I was finished, I considered it a good investment of my time. But that's because I'm a "computer guy" in the tech business. I can easily justify wallowing in levels of detail the average person would consider silly because it's my job to do that.
But if you're
only looking for performance (and you value your time at more than $6/hour
) it doesn't make economic sense to do a Stage-3 installation. Especially when you realize could get a part-time job that pays better than that, and then use the money you earn to buy a more capable computer.
Where Gentoo really would (and does) shine is when you use it as the basis for an application appliance. But again, that is a specialized situation where there are pragmatic reasons for wringing every last ounce of performance out of your product - because if you don't, the competition in the marketplace will kill you. And there are two other good reasons. First, once you create a fully optimized Gentoo "gold master" you can just keep cloning it until you change your hardware configuration. And second, because you're going to be responsible for support, it also makes sense to get everything "just right" before you ship out 5000 boxed products.
Gentoo is an amazing version of Linux. But it is a niche product. And I still maintain that most of its benefits apply,
in practice (as opposed to
in theory) to only a very small subset of the Linux community. From the level of knowledge you've displayed in many of your forum posts, I suspect you (i.e f0dder) are part of that small cadre of people that has specific goals combined with the necessary technical background to pull them off. For folks like you, Gentoo makes sense.
"There's some Linux experiences money can't buy. For everything else there's Ubuntu."
With other distros, I've found that oftentimes I get a lot of features I don't need from standard packages (including dragging in a crapload of dependencies),
True. But to go back to an earlier observation I made about custom and minimalist installations, those very same dependencies you don't want installed by default may later be needed for when you want to do a source install of something else. You can't have it both ways. If you want lean - you
get lean.
but a feature I need isn't enabled - and I end up having to do those messy from-source installs after all.
I don't know of any supported 'feature' for a distro that isn't found in its repositories and installable via the preferred package manager. If you're doing source compiles for a core function, I suspect you're either hacking the kernal, or getting into something that hasn't been fully tested and approved for distribution. Nothing wrong with doing that (I'm guilty of it myself) but once again you can't have it both ways. If you want beta - you
get beta.
Dependency-hunting isn't hard, it's just a waste of time. And for some software, you get into the iffy situation where very specific versions are needed. Installing redmine, for instance, was pretty fun smiley
It is a waste of time. No argument there.
But
redmine isn't a good argument for that point. Let's get some background on that story:
Redmine's hassles were the result of a change to the SQlite-3 database table_info pragma that was made by the SQLite development team. The change was made in response to what they thought was a request from the RubyCore team. Such was not the case, and the change that got made broke
all Ruby on Rails apps that were using SQLite-3. What makes this story really tragic is the fact that the problem didn't come about through an arbitrary program change, but rather by SQLite's genuine effort to be accommodating and responsive to a request it thought was from the Ruby community.
Unfortunately, both versions of SQLite's binaries are now found in many repositories, and most Linux package managers will default to the most current version of a binary for installation purposes. This can be overridden on a package by package basis by the person doing the install as long as they know about the problem. In the case of Redmine, an older version of the binary is needed. Unfortunately, most of the people involved with Redmine didn't know about the problem until after they broke their installation.
Now from my perspective, this problem has nothing to do with any Linux distro, it's repositories, or the system of package management. It has everything to do with communications issues between the developers of Ruby and SQLite.
On a side note, I would also like to point out that Redmine is not found in most Linux repositories. Furthermore, if you go over to the Redmine website and read the installation instructions, you will see that the developers have left their userbase a lot of manual setup actions that should have been scripted instead. This is probably because Redmine is still under heavy development and not quite out (ver. 0.7.3) of beta. If the installation routine had been scripted, it would have been a simple matter to check for the correct version of SQLite prior to installation. And that would have avoided the whole problem in the first place.
On a related note, Redmine is a web-based project management application. If you go over to SourceForge you will find there are something like 1700 packages that are tagged "project management." A cursory look at a few dozen will show several that duplicate, and in some cases exceed, the functionality of Redmine. Many are also out of beta.
From what I can see, there doesn't appear to much that is unique about Redmine, other than the fact that it is being implemented in
Ruby on Rails. Now while I have the greatest respect for the Ruby community, and I admire the work of the folks that came up with Ruby on Rails, I can't help thinking "so what?" when I look at Redmine. Especially when there are equivalent applications I can install directly from my distro's repositories that will give me the same functionality without the hassles of doing a source compilation or a pile of manual configurations.
It's nice that Linux has made provisions for you to compile an application from source. But unless you have a very specific
reason for doing so (or you just plain want-to-do-it*), why bother?
* That wouldn't normally be considered a reason - but this is Linux we're talking about, right? P.S. - Sorry for writing a freekin' book. Somebody else talk, please?
