Gentoo already forked; the coder base is split, though not sure about the user base.

ports vs. portage is a debate of utility. Its a meta-tool; how do I get the tools that I need in a better manner (* Better to be defined by the user). I sincerely doubt that the tipping point between selecting gentoo and FreeBSD is the difference in a metatool.

FreeBSD has fewer buffer overflow exploits. It's that simple. Most BSD-based solutions (NetBSD & OpenBSD included) are considered more secure for server systems. Of course, application security is still an issue....

1) I shouldn't be answering to trolls, but the whole "my free x86 based UNIX OS that runs tons of software is SOOOO much better than your free x86 based UNIX OS that runs tons of software that you must be a luser and i rock!" thing is pathetically old. See a tree. Pet a dog. get laid. Get a life outside of petty arguments about free OSes showing "heh, I said BSD sucks, on a BSD FORUM, I sooooo rule".

2) FreeBSD is not about speed really, though it is fast, and in many ways faster than Linux. FreeBSD is about a system. Not a kernel with 24 vendor specific patches (I honestly can't read the patch version on my current RH kernel, nor do I bother to look it up) with a billion RPMs each with their own vendor specific patches or apt dpkges and a few tarballs here and there, but a cohesive system. The problem that "BSD SUXXORS" dorks have with FreeBSD is that its beauty is subtle; you don't really get it until you've had the system for a while and you realize how everything just feels right. They don't switch scheduler and VMs in the middle of a "stable" branch. They don't make you change firewall code with every major kernel release. It just works, and works well. If chasing every RPM, worrying abut what vendor has what is what you like doing, cool, go for it. But BSD users (like myself) will be quite happy with what we chose, for reasons you can't seem to understand.

Thankfully, it's FreeBSD you're talking about, and not another unnamed BSD system that I am aware of:-)

Yeah, that FreeBSD that ships with two packet filters out of the box (three if you count the one that comes with the ppp daemon), and the unnamed one in the ports - of course, without the slightest hint on which to use in what situation in the docs...;-)

I don't know if you're implying that Debian is not a cohesive system by saying that FreeBSD doesn't have apt dpkges or whatever, but Debian is a cohesive system that doesn't change functionality in the middle of a stable branch. You don't have to chase packages around, they're easily downloaded and installed, and major upgrades are handled pretty seamlessly as well. It works and it works well. I'm sure there are other reasons why FreeBSD and Debian are better and worse than each other for different purposes

The one thing I personally don't like about most Linux systems is that they seem to think that they are smarter than the upstream developers. The problem with heavily patched packages and funky custom installation layouts is that all the documentation, from howtos to security advisories, must first be "translated" to your local system. The BSD packages, and I guess this is true for gentoo and some other Linux-based systems as well, is that they mostly keep stuff as it was meant to be by the authors, except

"The BSD packages, and I guess this is true for gentoo and some other Linux-based systems as well, is that they mostly keep stuff as it was meant to be by the authors, except for patches neccessary to make it run at all."

Because BSD prefers being better for upstream maintainers than for end users. Why in the hell would I want to do a whereis every time I need to find some random binary that freebsd thinks should go in/usr/local/mysql/libexec/bin/ or whatever?

um... in FreeBSD one of their major philosophies is a consistent well defined file heirarchy. This is one of *most* BSD users complaints with Linux,there doesn't seem to be any standardized file structure which lends to chaos. It is my experiance that it is much easier to find binaries in FreeBSD (granted you do have to learn the system to start with) than in Linux Distros.

Not to forget about having to chase down the dependancies, hoping they're the right version, then chasing down the dependancies' depandancies, etc., etc., etc. That's one of the major reasons I chose to stay away from the RPM-based systems and went with FreeBSD. The ports tree gets the dependancies for you (if you are in a lazy enough mood to go that route) or the pkg_add gets them as well. It's a lot less of a headache to worry about "oops, I forgot this dependancy!". I personally think that the RPM us

and if you need something that ximian doesn't have in their database you just pull it's dependency libraries from redcarpet and build it from an srpm. things definitely aren't as tough as they used to be

I have no experience with BSD, and I'm sure ports is great, but it isn't the only game in town anymore

Now having said that, I agree about FreeBSD. It does rock that it's one complete operating system. I do have to point out, however, that there's a much bigger difference between OpenBSD and FreeBSD than there is between, say, Red Hat and Slackware. At least between two Linux distributions most of the kernel is the same.;-D

Do we really need to throw out stable and robust ports entirely just because you like the USE flags? If it's so desperately wanted by you, then perhaps you could actually code it up. It's all just simple makefiles, so you don't even need to learn python.

There already are "USE" flags of a sort, but they're more specific than the general purpose flags that Gentoo uses. Adding some new flags should be a piece of cake, if you can convince the committers of their need.

To moderators: IMO, the previous comment should not be marked "Informative". It contributes no factual information towards the topic of discussion. At best, it is an opinion.

To the poster: nobody's asking anyone to "throw out stable and robust ports". Wherever did you get that idea? The whole GentooBSD project seems more to be an exploration of an alternate way to manage and maintain a BSD-based system. I don't think that the authors intend this to replace or usurp existing distributions of FreeBSD

Okay, then return the results of the inspiration to the BSD community then B-).

Anyway, though I use and enjoy Gentoo, I've never really understood the logic of writing something as integral to the system as Portage in a language that requires an interpreter to function. One would think that system code should just run by itself.

Anyway, though I use and enjoy Gentoo, I've never really understood the logic of writing something as integral to the system as Portage in a language that requires an interpreter to function. One would think that system code should just run by itself.

Well, Gentoo's all about choice. Writing the integral system (i.e. Portage) portions in Python (or any other interpreted language) would make it a lot more portable to other systems, as the interps translate the Python (or whatever language) code into the sys

1 of the things that I like about portage is the ease of use. You don't have to find dependencies. Nor do you have to find the web sites that host these packages. If you can find a place that's closer than the defaults, then you'll have the option of getting packages from there.

I think that these general advantages should be available all across the board for all OSes, unless of course there are specific needs for specific alternatives.

I'm not trying to start a flame war or anything. I'm just sharing my own likes & dislikes.

Do realize, that ports has done this for a long time. Only diff beween ports and portage are the command structure, some layout and the systems that they originated for.

The cool thing about ports in relation to freebsd, and prolyl the other bsd's.. is that they integrate with the package systems used. SO if you want, you can download the tbz (vs tgz) package or use/usr/ports.

Yeah, I just realized after I clicked Submit that Gentoo is a combination of BSD & various other distros/OSes. I feel bad. It's almost as if I didn't read the article that I submitted. On the other hand, it wasn't written in the article that I submitted, so my memory lapse may be somewhat excusable.

1 thing that I hope that they add is the abiblity to not update the entire portage tree. Otherwise, we are forced to download way too much data that we may never use, when all we want to do is update the packages that we have already.

I'm not sure that this would be useful. My experience with Gentoo Linux and its existing portage tree has taught me that many ebuilds are inter-related. As a quick example: a new version of PHP might require an updated version of Apache, a new MM library, and a new version of OpenSSL.

If a user only updated their PHP portage directory, and if the PHP ebuild were properly written to require the most current or known-good versions of all of its dependencies (as tested by the PHP ebuild maintainers), then t

Remember that updating the portage tree does not automatically update all installed software. The user must still use the emerge command wisely by seeing what ebuilds have been updated, and making a decision based on their needs. Those who run emerge -u world blindly can get into trouble.:)

Yeah, I hear you on that. I kind of learned that the hard way. I'm suprised that they don't have a command to upgrade all packages to the most recent stable ebuild. How hard can it be? I'm not skilled in understanding it

Portage already does everything you just mentioned. Portage has stable and unstable "profiles" which will automatically update all your software to either the newest stable version or the newest version overall respectively. You can change which profile you are in at any time, or you can stick to stable and emerge individual packages from the unstable profile. Usually I stick to the stable tree for libraries and things like that that contribute to overall system stability and then manually install some unst

Then I first tried gentoo I thought portage was better than ports, but that was because I hadn't read the onlamp [slashdot.org] article about portupgrade.

The differences I've noted is that portage is upgraded every now and then which gives you the small trouble of running etc-update and upgrade it's config files. It might actually be broken at some times to.

Ports on the other side is rock solid and has been used for a much longer time. You can of course set compiler flags for ports to, and atleast for freebsd the upgrade tool is as good as the gentoo one. I do however like netbsds approch most since their pkgsrc seems most intelligent with their/usr/pkg path for everything installed from it. I must admit I don't know that much about their different port handling tools thought, I've mostly used make install.

The huge advantage of gentoos portage is the USE-flags, which I really like. Don't know if it would be hard to get the same functionallity in the BSDs without using portage, or if there already are a few alternatives which works almost the same way. Feel free to reply or e-mail me information about usefull ports tools if you have any.

Don't know if it would be hard to get the same functionallity in the BSDs without using portage, or if there already are a few alternatives which works almost the same way.

There are things in FreeBSD that work almost the same way. But they tend to be much more specific than what Gentoo users are used to. They're informally called "knobs" and can be put in the global/etc/make.conf file to apply to everything, or used on a per-port basis. Adding new knobs is not that hard, but you have to go through and ma

I should have added that NetBSD has a page with documentation for their pkgsrc [netbsd.org] which sorts out most of the questions you could have for it. For example that you've got/etc/mk.conf with build configurations, audit-packages which keeps track of any security vulnerabilities in the pkg tree, pkglint which tells you if you have any outdated packages installed and that you can upgrade packages with the command make update.

Combined they make a very good package system to. Don't know if make update handles depend

The huge difference between ports and portage is that portage has replaced makefiles and instead uses a python based solution. They also got USE-flags there you can specify stuff like "X ssl gtk -kde -cups" and stuff like that, to make applications which can use X and ssl compile with those options enabled, but not compile kde and cups support.

Portage doesn't replace makefiles, at least not the ones provided to build the actual program.

The FreeBSD's ports' Makefile basically sets a load of build/package organization variables, almost the same as a portage "ebuild" does. An ebuild is a script though. I've submitted a few when I was trying out Gentoo a while ago.

Portage just happens to be written in python (good choice BTW IMHO) whereas the traditional pkg-tools for FreeBSD are C based and the portupgrade utility is written in Ruby.

Portage doesn't replace makefiles, at least not the ones provided to build the actual program.

I know that, I just wanted to tell that portage didn't used Makefiles to make it work.

Portage was inspired by NetBSD's pkgsrc which was derived from FreeBSD ports. Flags like PROVIDES are similar to USE and somewhat comparable to FreeBSD's make options for ports e.g. "NO_GUI"=true and stuff like that. I do like the USE idea though.

I actually didn't thought about that possibility, even thought I've used it som

"-gnome" would be much more useful example, since there are many apps that can be built with or without gnome support, but I am not aware of any that Qt applications that can optionally use KDE. If you don't want to build any KDE applications, then simply don't build any KDE applications. Since nothing but KDE applications depend on KDE, this is the simplest solution.

I have a cron job which does a daily cvsup and `portupgrade -aRr' (disclaimer: Doing this on a production server is a bad idea. Always check ports before deploying them. On a workstation, however, in the unlikely event that it breaks I can spend some time avoiding work while I figure out why:). The problem with this is that some ports (e.g. ghostscript and php) have curses based front-end for selecting make flags. This causes portupgrade to wait for user input (which never happens, since it is not run

The problem with this is that some ports (e.g. ghostscript and php) have curses based front-end for selecting make flags. This causes portupgrade to wait for user input

Use portupgrade -m "BATCH=yes", and no user input will be required. You can also set the variables that you want your ports to be built with in/etc/make.conf, or, more flexibly, in/usr/local/etc/pkgtools.conf, based on the ports name (including wildcards). This is a good idea anyway, because you don't have to remember all these options, t

I couldn't disagree more. I've only been using FreeBSD for a short while, but the documentation really is superb. The only problem is that there is so much of it that I haven't had a chance oto read it all yet...

Maybe they're getting redy to leave the ship if the SCO racket goes out of hands. I wouldn't mind using a different kernel (if it is as good as BSD's), but I don't really feel like learning new maintnance tools.

As usual, when this comes up, let's plug NetBSD's Packages Collection [netbsd.org]. ``pkgsrc'', as it's known, originally derived from FreeBSD's ports is available for a large number of platforms [netbsd.org] (Netbsd, of course, and then Darwin, FreeBSD, OpenBSD, Linux, Solaris and Irix), thus allowing system administrators who have to take care of more than one OS to take advantage of its strengths. So, uhm, sorry, but I'd also have to add my vote to the ``who needs portage'' camp.

Well, since there is already a thriving community of Gentoo Linux developers who maintain the portage tree, I'd say that the first part of your question has already been answered. The Gentoo portage tree will be used for both Gentoo Linux and Gentoo BSD.

I know you're probably a troll, but I feel obligated to ask the questions anyway.

Why does it matter if people "waste" their time on this? Does it hurt your ego to see people working on Gentoo BSD? Are you the sole arbiter of what *BSD-related projects are wastes of other people's time? More importantly, who asked you?

What if, by some chance, Gentoo BSD happens to provide a better package management system than the standard package management systems? What if portage meets people's needs better than

No, I'm not trolling. I don't see why anybody needs it. Ports and pkgsrc can accomplish things just as fast/faster than portage can. I don't see any advantages in portage over ports and pkgsrc. Thus, I don't see it as being an improvement. Judging by the amount of other people who posted here saying "didn't they notice that we already have ports" and other similar things, I'd say I speak for a good few people.

On a different note, I don't like Linux anyway and, unless Gentoo BSD is going to offer some kille

Not to sound like a troll here, but i really dont see the point since we have a well-oiled ports system already?

If someone can explain a good reason, ficool.. but i as of yet, really dont see a point. And it can only cause issues. One nice thing about the ports tree, is its 'the' ports tree.. no confusion involved.

So what you're saying is that the ports tree is "the" only way that people should use *BSD? That there are no reasons to improve upon a system that, admittedly, has grown old and was not designed from the ground-up as a flexible software maintenance tool? That people should not innovate or try to develop a better system that meets their needs?

The "issues" that people encounter when using a new package management system are positive forces for change. A fresh approach to software management will help de

That aside, if you had fully understood what I said. you would have realized I'm not against change. I just feel that there needs to be a valid case to consider it. I also clearly stated i did NOT know the portage system, thus looking for others to assist in the rational..

So far, you haven't given me any valid reasons, nor does the typical sounding Linux crowd's "you don't know what you are talking about so shut up" attitude that leaked thru doesn't help the case.

Why do you insist upon posting with out the facts?
According to NetCraft Surveys (yes, I come from a world where we actually like to quote our sources.) Usage of the BSD's is actually increasing.
And by most reports (including e-week, and linuxworld) *BSD's are more stable than any other system out there.
Before you decide to make another idiot comment to make yourself feel better about who you are try to get the facts straight.

1. You can not play games on it.
2. It cannot be used by my grandma.
3. It lacks a GUI of any note.
4. There is no support available for it.
5. It is an assortment of fragmented OSes.
6. It cannot be run on the x86 platform.
7. You have to compile everything and know C.
8. Support for the latest hardware is always poor.
9. It is incompatiable with GNU/Linux.
10.It is dying.
1. Of course you can play games on it.
2. Sure it can.
3. You can use any popular GUI. wm, KDE, GNOME etc.
4. Are you too stupid to f