Slashdot Mirror

• Free Software Foundation
• OpenBSD
• Apache
• NetBSD
• PostgreSQL
• SAMBA
• FreeBSD
• LinuxFund.org
• KPFK radio

Personally I don't think *BSD can be compared to a distrubution of Linux. I think of Linux as a police force and *BSD as the FBI. *BSD is more stable, more professional, more rock hard kick ass. I picture Linux to be more slick, stable, personal and cool. There are three main BSDs, FreeBSD, NetBSD, and OpenBSD. As far as I know, FreeBSD seems to be focused on stability, and being robust. OpenBSD is focused on security. NetBSD seems to be focused on being a server and running on many platforms.

Take QNX RTP/4 for example. It can stay up and functional regardless of the situation, even through hardware installations. This is an assett for many uses; Nuclear Fuel monitoring, etc... Try that with a monolithic kernel.

OK, FreeBSD is also very portable, but it is also a monolythic kernel design, like LINUX. (is FreeBSD also available on Mainframes ??) But do not assume, that Mach3 gains the protability of FreeBSD !! At last, please only count real distributions not possible hacks !!

It's NetBSD! Not FreeBSD!

On the MainFrame issue... Show me any corporation that uses Linux on a mainframe (for actual work), and I'll show you one poorly managed corporation. Anyway, to answer your question, NetBSD isn't available on a mainframe, but is Linux available (functionaly) on a VAX?

---------------------------
I may not agree with what you say, but I will defend to the death your right to say it.
--Voltaire

Due to a last-minute problem (a build error, not a bug with KDE or FreeBSD itself) which was discovered with the KDE packages on the Intel architecture ISO image for 4.2-RELEASE, I've updated the image at:

ftp:/ /ft p.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES /4.2-install.iso

I also took the opportunity to include the windowmaker package, which was mistakenly left off (and referenced by one of FreeBSD's canned Desktop profiles).

The new MD5 checksum for this image is:
MD5 (4.2-install.iso) = 7eec8a2e4bc2211fccf18b5a6fd5b55e

If you do not have any interest in installing the KDE desktop or windowmaker and you have already grabbed the previous installation ISO then you can safely ignore this announcement; nothing else was changed.

Apologies to everyone who downloaded the first ISO image and had an unsatisfactory KDE experience. Excrement occurs.

- Jordan

Actually, there are patches for zero copy sockets and NFS for FreeBSD-current. It's bleeding edge, but if you want zero-copy, it might be worth exploring, at least for future development.

--
"Don't trolls get tired?"

1. Trolling (poorly)
2. Really damned stupid
3. Uneducated

first off , freebsd releases a daily snapshot which is tested by 100's of people DAILY!

Sure there is a few bugs to work out. But if you would please tell me 1 o/s that doesnt have bugs to work out.But I gurantee you this , there is not a boot bug. there is too much testing done to release something of that poor quility.

heres the links to the daily snapshots. ftp://releng4.freebsd.org (for -STABLE) and for ftp://current.freebsd.org

first off , freebsd releases a daily snapshot which is tested by 100's of people DAILY!

Sure there is a few bugs to work out. But if you would please tell me 1 o/s that doesnt have bugs to work out.But I gurantee you this , there is not a boot bug. there is too much testing done to release something of that poor quility.

heres the links to the daily snapshots. ftp://releng4.freebsd.org (for -STABLE) and for ftp://current.freebsd.org

The Java 2 is availible in /usr/ports/java/jdk12-beta as well as ;Ta r file We've been running it with no problems for some time now

For those of you who might be curious and lazy, here's a quick link to the RELNOTE S.T XT for this release (i.e. the changelog/release notes).

--

It would be nice to have in 2.5 a kqueue/kevent interface similar to FreeBSD 4.x Maybe something like Schedular Activations

CTM does this.

Server side, the CTM server runs a script which identifies changes, compresses them, puts a sequence number on them, and emails them out. Client side, ctm.rmail decodes and applies the changes.

CTM was developed for use with FreeBSD, but could be used for any source repository.

If your web browser does not parse that address correctly, just grab release #23 from ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/

Ahem, ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/ FreeBSD-SA-00%3A23.ip-options.a sc. v1.1

If you don't believe, check this picture. Yes, my score is now 0.001. Yes, call me king.
BTW, no hardware/software cheat used, I just had a lot of luck to release the button so fast. The kind of thing that happens once in a billion times. Yet, I am the king.
If anyone gets a higher score (if there is one) and has a screenshot, send me the link!

--
Q: How does a Unix guru have sex?
A: unzip;strip;touch;finger;mount;fsck;more;yes;umoun t;sleep

Please compare this to the original advisory.

Gahhhh, what are you thinking..... I can easily get FreeBSD 3.5-Stable loaded and setup to do NAT & Firewall with about 200mb of diskspace on a 486/25.

But what's really interesting is the picoBSD project which can do all this AND fit on a single floppy. So you can keep your MFM disk to pull apart and make frisbees/rearview mirror decorations/ or whatever else fancies your imagination. And it will run on a 386...

If you're going to take the DIY approach, you should either be an experienced UNIX admin, or get yourself up to speed as fast as you can. The Aileen Frisch book Essential UNIX Administration (or Esential System Administration) is a good place to start. For running a mail server, also check out sendmail.org and Claus Assman's useful site on configuring sendmail.

I had similar paranoid security concerns, so I set up OpenBSD. It was a fairly painless install, provided you read the directions. I set up sendmail, UW-IMAP, IMP, and access it via secure http. UW-IMAP has some serious security concerns, but it's much easier to compile than Cyrus, my preferred IMAP server.

If you're new to UNIX admin though, try looking at FreeBSD. This is hands down the simplest UNIX installation I have ever done. It was almost as simple as starting the installation, walking away, and coming back when it was done. It also doesn't hurt that FreeBSD has excellent network performance.

TinyEgo

Have you looked through the FreeBSD Ports Tree lately?

Not that I'd consider tchrist's opinion definitive :-)

1. Video card.
2. Monitor (Got the shakes after about 30 minutes of being on)
3. Hard drive (bad firmware)
4. Mouse (Netrek damaged the left button :))
5. CD-ROM twice (Power died and loud operation)
6. Motherboard and memory (DOD - fried)
7. Memory again (thank you ECC)

Given this, let's compare:

Microsoft asserts its market share by bundling products that users have no (easy) way to remove, and by using proprietary technology to give their own products an edge. (hidden APIs, for example)

RedHat asserts its market share by bundling products that users have no (easy) way to remove (much easier than Microsoft, but see the first paragraph above), and by using complicated open-source technology to give their own distribution an edge. (C++ binaries that are not compiled with GCC 2.96 won't link against the C++ library supplied with RedHat due to C++ name mangling; the user must either get a statically linked version (which isn't usually provided), compile from source (which they don't know how), or stick with RedHat's products).

There's a big difference between "it can be done" and "it will be done"; it's called barrier to entry.

Mac OS X's kernel (Darwin) is not your typical monolithic BSD kernel. It's a Mach kernel with a layer of BSD-like services around that. Darwin is Nearly-Free Software under the Apple Public Source License.

From what (little) I know of UML, I'd have to give jail the nod since it's focused on security, uses less overhead per-process (?), as well as having a focused and simple design.

Besides just being a nice OS, it had just made itself even better suited as an Internet server (for most services). The recent (end of July -- part of the 4.1.1 release) addition of the socket filtering, coupled with the dataready and httpready sample filters should help ANY web-server -- they ensure, the server is not bothered (from accept(2)) until the data-packet has arrived (for dataready) or until http-headers have arrived (more specialized httpready).

The next Apache release will have the FreeBSD code to use this filters (already committed in CVS-tree, AFAIK) or you can patch any other server to use them -- including an earlier release of Apache. Here is an example -- a patch for Apache (and Apache's documentation).

Look for the SO_ACCEPTFILTER option in setsockopt(2) and the accept_filter(9) ).

According to my source, using this on busy sites (where keep-alives are already disabled) may bring down the number of Apaches needed 5-10 fold...

-mi

Besides just being a nice OS, it had just made itself even better suited as an Internet server (for most services). The recent (end of July -- part of the 4.1.1 release) addition of the socket filtering, coupled with the dataready and httpready sample filters should help ANY web-server -- they ensure, the server is not bothered (from accept(2)) until the data-packet has arrived (for dataready) or until http-headers have arrived (more specialized httpready).

The next Apache release will have the FreeBSD code to use this filters (already committed in CVS-tree, AFAIK) or you can patch any other server to use them -- including an earlier release of Apache. Here is an example -- a patch for Apache (and Apache's documentation).

Look for the SO_ACCEPTFILTER option in setsockopt(2) and the accept_filter(9) ).

According to my source, using this on busy sites (where keep-alives are already disabled) may bring down the number of Apaches needed 5-10 fold...

-mi

Besides just being a nice OS, it had just made itself even better suited as an Internet server (for most services). The recent (end of July -- part of the 4.1.1 release) addition of the socket filtering, coupled with the dataready and httpready sample filters should help ANY web-server -- they ensure, the server is not bothered (from accept(2)) until the data-packet has arrived (for dataready) or until http-headers have arrived (more specialized httpready).

The next Apache release will have the FreeBSD code to use this filters (already committed in CVS-tree, AFAIK) or you can patch any other server to use them -- including an earlier release of Apache. Here is an example -- a patch for Apache (and Apache's documentation).

Look for the SO_ACCEPTFILTER option in setsockopt(2) and the accept_filter(9) ).

According to my source, using this on busy sites (where keep-alives are already disabled) may bring down the number of Apaches needed 5-10 fold...

-mi

Besides just being a nice OS, it had just made itself even better suited as an Internet server (for most services). The recent (end of July -- part of the 4.1.1 release) addition of the socket filtering, coupled with the dataready and httpready sample filters should help ANY web-server -- they ensure, the server is not bothered (from accept(2)) until the data-packet has arrived (for dataready) or until http-headers have arrived (more specialized httpready).

The next Apache release will have the FreeBSD code to use this filters (already committed in CVS-tree, AFAIK) or you can patch any other server to use them -- including an earlier release of Apache. Here is an example -- a patch for Apache (and Apache's documentation).

Look for the SO_ACCEPTFILTER option in setsockopt(2) and the accept_filter(9) ).

According to my source, using this on busy sites (where keep-alives are already disabled) may bring down the number of Apaches needed 5-10 fold...

-mi

you could run any untrusted app in a chroot jail.

UNIX has always been designed around two levels of users: root and everybody else. While this is a simple and strong security model, it has disadvantages when it comes to delegating administrative tasks to more or less trusted persons. The FreeBSD ``Jail'' facility provides a way to compartmentalize a server in such a way that the root-privilege for one compartment can be handed over to non-trusted persons without compromising the security of the entire machine. Creating "virtual machines" this way has many uses.

John K. Hubbard himself has described FreeBSD's installer as "Evil Incarnate" (section 3.2 of the link given).

-Peter

I live in Atlanta (Virginia Highlands area), I'm not in college, and I live in what could be considered a geek house. I work for an ISP in the area, and I decided to move out of my ultra-cramped apartment. I managed to find a steal of a house... well, half a house. Its been subletted into two seperate dwellings, one upstairs, and one in the basement. The basement dwelling was available. I quickly moved into this place, put an add out on Yahoo, and found a like-minded techie working in the same field as myself. Both of us being geeks (him, an NT administrator, and myself a security engineer using Linux and BSD), we had half an army of computers between us, so we signed-up for DSL through Speakeasy, I setup FreeBSD on a spare PPro200 for a NAT-firewall, and we now have 7 PCs running various operating systems (Linux, FreeBSD, OpenBSD, WinNT, Win2k, and Win98) with all the bandwidth we really need for around $60 a month.

Just goes to show that a) you don't need to be in college to have a geekhouse, b) FreeBSD can make a damn good firewall, and c) its all possible in Atlanta. Good luck with your searching!

Well I was not able to confirm this, although there is a lot of excellent humour and information, there are only three very brief mentions of MFS in the FreeBSD FAQ and none of them say anything about it resizing itself (although it might be inferrable from the fact that there is no mention of a flag to set it's size.)

I am curious as to what purpose this serves, however. If, as was my impression, FreeBSD has the same sort of dynamic caching that Linux uses, this would only add an extra layer of overhead - and hurt, not help, performance. Any FreeBSD folks want to enlighten me? Is there actually any situation where this is useful, or is it an artifact from a time when the caching algorithm really sucked, or what? ;^)

Firstly, it's not easy to update the ports tree itself

You're going about it the wrong way there. Have a look see at the FreeBSD Handbook for CVSup for more details on this. Also, if you don't already have a copy, go pick up "The Complete FreeBSD" from Walnut Creek. It's an outstanding book, and one that I found to be a much easier read than many of the Linux specific books out there. It has a chapter covering the ports tree that I think you'd benefit from.

Mind you, ports do have their problems. All in all, I think that it's a far better approach to software distribution than anything else that I've seen. A more in depth discussion of this, which even relates to this thread, was done a few weeks back right here on Slashdot, "Unified BSD packaging system?". One of the concepts brought up in that discussion I haven't seen mentioned in this one is if there is some way to unify all the *nix world rather than just the various flavors of Linux.

It sure would be cool to see a group work out the best of the best features from the leading methods of distributing software and bring it to all the platforms. Definitely not holding my breath for anyone to actually do this, just a pleasent thought just the same.

A rich XML based syntax? Just a pet peeve of mine, but why does everything have to be XML based? It's like Microsoft saying that C++ is the first language to have the ability to have XML-based comments embedded in the code. Yep, it is. But is =head1 really any better or worse than ?

As for your requests for functionality, perhaps you should read Installation and package tools document, version 1.0 by jkh over at the FreeBSD side of the world. While I know I'll be burned at the stake for saying good things about FreeBSD on slashdot, that document has some excellent thoughts which the Linux world could also benefit from.
----------------------------

ask why a new version of a package was released?
see a list of changes between old and new versions?

Well, RPM does include a Changelog which should include why the package was released, and what changes were made. check the --changelog option.

tell the system to apply only security or high-priority fixes?

You can do this mostly by installing a distro, and then tracking a particular version of it. Redhat-6.2 has lots of updates, but all of them fall into your 'security/high-priority' category.

tell the system to automatically process all updates except those involving specified packages, which I want to approve on a case-by-case basis?

It's trivial to setup something like this where you mirror the appropriate dir on updates.redhat.com, then have a script which does an rpm -F foo.rpm on every rpm whose name isn't listed in 'no-auto-upgrade.txt'. However, given your original statement, it's not possible. You're saying that you want it to automatically everything, except it should psychically know what you want to pick and choose from. Ummm... no matter how you cut it, you'll at some point have to tell the system 'upgrade or no'.

tell the system never to upgrade packages that require upgrades of packages used by other software (eg, libraries)?

This is the default behavior of RPM. You have to use --nodeps to override it.

ask for packages that will help me convert GIF files to PNG?

You want natural language capability search built into your package manager? You've watched too much star trek. If however you did a quick search for RPMs that contained both 'GIF' and 'PNG' in their name on a site like rpmfind.net you'd find gif2png is readily available.

ask for only packages targeted at beginners?

I have no idea what use this is. Beginner is a very broad term. Is Enlightenment aimed at beginners? How about Windowmaker? The answer for both is a resounding maybe!, depending on the configuration. How about gcc, is that for beginners? After all, most computer barely-literates don't know how to use a compiler. And bind, that's definitely an advanced package right? unless of course you install a caching-nameserver rpm that helps the beginner have their own caching nameserver, then it's beginner. Or an obvious beginner package like grip, whcih isn't beginner at all, i mean, you have to know about mp3 encoders and cd rippers.

ask for only well-integrated, well-tested packages?

Use RedHat, they'll only give you these. If you stick to basics, unless you use Mandrake, you usually won't get anything that's not well-tested and integrated.

get reviews of a package?

Ah yes, all programs expand until they read mail. Or in your case, you're asking for the package manager to read newsgroups and mailing lists, so it'd be a newsreader too. Maybe we should just integrate this package manager of yours into emacs.

find out how to get started using a package?

The RPM format allows for certain files to be flagged as documentation and generally installs them in the path /usr/doc/$rpm_name. and man files in /usr/man. you can get a list of what it installed by doing rpm -qi package_name.

begin browsing the documentation for a package before approving a full installation?

again, you're asking the package manager to do things that just don't make sense. Why not read up on the software, then install it? Or just install it, and if it's no use to you, do an 'rpm -e'.

have some help in configuration updates?

These are called man pages, and documentation files. You read them and they help you. Or hell, if reading real documentation is too much work for you, then see if there's a HOWTO that you can peruse somewhere on the net.

Personally I use FreeBSD which has it's own unique set of strengths and weaknesses, and if you don't think anybody out there is thinking about this stuff, you should read this document which is a summary of the state of these things in FreeBSD, and some ideas on how to progress.

Everyone already knows that Darwin works on x86. And everyone also knows that this has absolutely no impact on Apple's business plan, and does not mean that OS X will run x86. It's also irrelevant because there are several BSD-based systems which are much more worthy of x86 PC users' time.

Let's run through more facts that everyone should know. This has nothing to do with GNU/Linux or the GPL. It does not mean that Photoshop will work on FreeBSD. It doesn't mean that the Free Unix community will see an outpouring of money, code, or other support from Apple. All it means is that Apple decided to, for once, release a real operating system. They lack the talent to do so, as should be evident from MacOS 1 through 9. They found an excellent codebase, which, do to the wonderful BSD license, is essentially free (as in both pro bono and libre) for them to plunder however they wish. So they take twenty years of the best operating systems code ever written and, um, "embrace and extend" it with the GUI that Jobs brought with him from NeXT. Very "innovative". They then release this code, which allows Mac lusers run Photoshop without crashing, and allows them to get very rich with very little work.

Years of hard work and research from many real computer professionals associated with several projects across the country and around the world go to buy Mr. Jobs another few houses (hice?) and cars. Yay.

(And this, my friends, is flamebait. I love Fridays.)

---------///----------
All generalizations are false.

I thought I'd never see something so amazing as this.

I'm running a small server in a bit of a jeopardized environment (it runs, among other things, an anonymous remailer). It runs a software called Port Sentry by Psionic, among other stuff. I think the software is qute qood, and I'm posting it here so that you might give it a try.

Portsentry works by attaching itself to a configurable number of ports. When it detects a port scan, it simply uses firewall rules to block IP traffic to the address the scan came from. You can easily configure your firewall to drop the respective rule after some time. It detects TCP as well as UDP scans at a configurable sensitivity. If you're evil-hearted, you can configure it to put in some retaliatory action, but I wouldn't recommend that because you don't know whom you're hurting. On systems that don't run a firewall, the IP address can be dropped by assigning it a dead route.

While the methods employed are quite basic, it's a very useful, more or less minimalistic tool that definitely adds to the security of the site. I'm using it under FreeBSD 4.1-STABLE, where it's in the ports collection, but it says it works for other BSDs as well as Linux and ipchains-based firewalls just as well.

I'm running a small server in a bit of a jeopardized environment (it runs, among other things, an anonymous remailer). It runs a software called Port Sentry by Psionic, among other stuff. I think the software is qute qood, and I'm posting it here so that you might give it a try.

Portsentry works by attaching itself to a configurable number of ports. When it detects a port scan, it simply uses firewall rules to block IP traffic to the address the scan came from. You can easily configure your firewall to drop the respective rule after some time. It detects TCP as well as UDP scans at a configurable sensitivity. If you're evil-hearted, you can configure it to put in some retaliatory action, but I wouldn't recommend that because you don't know whom you're hurting. On systems that don't run a firewall, the IP address can be dropped by assigning it a dead route.

While the methods employed are quite basic, it's a very useful, more or less minimalistic tool that definitely adds to the security of the site. I'm using it under FreeBSD 4.1-STABLE, where it's in the ports collection, but it says it works for other BSDs as well as Linux and ipchains-based firewalls just as well.

This constant discovery of huge holes may finally generate a push for serious operating system security. One can hope. Although neither the Linux nor Windows worlds have done anything that really solves the problem, FreeBSD's Jail(2) call has real promise. Note that unlike chroot(2), which is for root only, user processes can call Jail(2), which makes it much more useful.

So get busy, get something like Jail(2) into Linux, and reorganize Mozilla so most of it runs in jail mode. That will kill the problem, instead of just injuring it slightly.

This constant discovery of huge holes may finally generate a push for serious operating system security. One can hope. Although neither the Linux nor Windows worlds have done anything that really solves the problem, FreeBSD's Jail(2) call has real promise. Note that unlike chroot(2), which is for root only, user processes can call Jail(2), which makes it much more useful.

So get busy, get something like Jail(2) into Linux, and reorganize Mozilla so most of it runs in jail mode. That will kill the problem, instead of just injuring it slightly.

This constant discovery of huge holes may finally generate a push for serious operating system security. One can hope. Although neither the Linux nor Windows worlds have done anything that really solves the problem, FreeBSD's Jail(2) call has real promise. Note that unlike chroot(2), which is for root only, user processes can call Jail(2), which makes it much more useful.

So get busy, get something like Jail(2) into Linux, and reorganize Mozilla so most of it runs in jail mode. That will kill the problem, instead of just injuring it slightly.

This constant discovery of huge holes may finally generate a push for serious operating system security. One can hope. Although neither the Linux nor Windows worlds have done anything that really solves the problem, FreeBSD's Jail(2) call has real promise. Note that unlike chroot(2), which is for root only, user processes can call Jail(2), which makes it much more useful.

So get busy, get something like Jail(2) into Linux, and reorganize Mozilla so most of it runs in jail mode. That will kill the problem, instead of just injuring it slightly.

The point is that FreeBSD, in particular, is under public revision control. Anyone can submit a patch to the project's GNATS database either via a web front-end, or via send-pr(1).

The developers are of course free to ignore your PR, but it remains sitting there for the whole world to see until they either accept it, or tell you a good reason why they're not going to. :-)

Should your patch be accepted, the fact will also be noted for all time in the CVS repository.

(It should be pointed out that the revision control extends beyond just the FreeBSD kernel, and covers the entire OS, including ports, documentation, etc. This also has many implications for the maintenance of FreeBSD systems. Want your ports and documentation to be up-to-date daily, and schedule a weekly update of all system sources and a rebuild? No problem.)

In fact, it goes even further than this. FreeBSD's development methodology is multi-tiered, with a central core team surrounded by a rather large group of committers. Not only does this mean that most submitted PR's are treated quite promptly, but it also implies that an active contributor with a good track record has a decent chance of becoming a committer, should he/she wish.

The original question pretty much summed up one of the primary reasons I'm currently spending a lot more time on FreeBSD than Linux. Over and above any technical or other merits, the development methodology of (specifically) the FreeBSD project is such that it is one of the easiest and most profitable open source projects to become personally involved in.

The point is that FreeBSD, in particular, is under public revision control. Anyone can submit a patch to the project's GNATS database either via a web front-end, or via send-pr(1).

The developers are of course free to ignore your PR, but it remains sitting there for the whole world to see until they either accept it, or tell you a good reason why they're not going to. :-)

Should your patch be accepted, the fact will also be noted for all time in the CVS repository.

(It should be pointed out that the revision control extends beyond just the FreeBSD kernel, and covers the entire OS, including ports, documentation, etc. This also has many implications for the maintenance of FreeBSD systems. Want your ports and documentation to be up-to-date daily, and schedule a weekly update of all system sources and a rebuild? No problem.)

In fact, it goes even further than this. FreeBSD's development methodology is multi-tiered, with a central core team surrounded by a rather large group of committers. Not only does this mean that most submitted PR's are treated quite promptly, but it also implies that an active contributor with a good track record has a decent chance of becoming a committer, should he/she wish.

The original question pretty much summed up one of the primary reasons I'm currently spending a lot more time on FreeBSD than Linux. Over and above any technical or other merits, the development methodology of (specifically) the FreeBSD project is such that it is one of the easiest and most profitable open source projects to become personally involved in.

The point is that FreeBSD, in particular, is under public revision control. Anyone can submit a patch to the project's GNATS database either via a web front-end, or via send-pr(1).

The developers are of course free to ignore your PR, but it remains sitting there for the whole world to see until they either accept it, or tell you a good reason why they're not going to. :-)

Should your patch be accepted, the fact will also be noted for all time in the CVS repository.

(It should be pointed out that the revision control extends beyond just the FreeBSD kernel, and covers the entire OS, including ports, documentation, etc. This also has many implications for the maintenance of FreeBSD systems. Want your ports and documentation to be up-to-date daily, and schedule a weekly update of all system sources and a rebuild? No problem.)

In fact, it goes even further than this. FreeBSD's development methodology is multi-tiered, with a central core team surrounded by a rather large group of committers. Not only does this mean that most submitted PR's are treated quite promptly, but it also implies that an active contributor with a good track record has a decent chance of becoming a committer, should he/she wish.

The original question pretty much summed up one of the primary reasons I'm currently spending a lot more time on FreeBSD than Linux. Over and above any technical or other merits, the development methodology of (specifically) the FreeBSD project is such that it is one of the easiest and most profitable open source projects to become personally involved in.

Almost, except for the credit clause in older BSD licenses... Don't they have to give credit, or is this only if they claim they're using the BSD code?

Code licensed under any BSD-style license (even the BSDL 2.0 without the advertising clause) requires the original software's copyright notice (© Regents of UC Berkeley or something like that) to be inserted in the documentation. More BSD copyright information can be found at FreeBSD.org.

In FreeBSD, this is the difference between a port and a package-- packages are what ports build. From the FreeBSD Ports page:

For most ports, a precompiled package also exists, saving the user the work of having to compile anything at all. Each port contains a link to its corresponding package and you may either simply download that file and then run the pkg_add command on it or you can simply grab the link location and hand it straight to pkg_add since it's capable of accepting FTP URLs as well as filenames.

In FreeBSD, this is the difference between a port and a package-- packages are what ports build. From the FreeBSD Ports page:

For most ports, a precompiled package also exists, saving the user the work of having to compile anything at all. Each port contains a link to its corresponding package and you may either simply download that file and then run the pkg_add command on it or you can simply grab the link location and hand it straight to pkg_add since it's capable of accepting FTP URLs as well as filenames.