diff --git a/en/advocacy/index.sgml b/en/advocacy/index.sgml index 0b5bdeda5d..910c1d7d3c 100644 --- a/en/advocacy/index.sgml +++ b/en/advocacy/index.sgml @@ -1,104 +1,104 @@ - + %includes; ]> &header;

Much of the success which surrounds FreeBSD is due to people advocating its use to their friends, colleagues, and employers.

This page provides links to more information to help you do this.

Mailing lists

Web resources

Sites using FreeBSD

- &footer + &footer; diff --git a/en/advocacy/letter.sgml b/en/advocacy/letter.sgml index b62e905cd0..22ba681824 100644 --- a/en/advocacy/letter.sgml +++ b/en/advocacy/letter.sgml @@ -1,262 +1,262 @@ - + %includes; ]> &header;

On October 31st 1998 (Halloween) Eric Raymond posted a leaked memo from Microsoft.

This prompted Jordan Hubbard to write the following response. This text is unchanged, except for the HTML formatting.

To: advocacy@FreeBSD.org
Subject: On advocating FreeBSD and the Halloween memo...
Date: Tue, 03 Nov 1998 08:21:56 -0800
Message-Id: <709.910110116@time.cdrom.com>

[ caution - this is a bit long. Lots of points here I've been wanting to cover for awhile and now seems as good a time as any.. ]

OK, so we've all seen this latest bit of Linux leaping about and shouting from the rooftops and some of us have even gone "agh!" and run around a bit ourselves, but now that we've all hopefully calmed down again I'd like to say a few words about this and the state of FreeBSD advocacy in general.

First off, just to cover the Halloween memo in brief, yes it appears to be genuinely from Microsoft and yes, it appears to be genuinely full of statements culled from various Linux evangelists who feel no pangs at making blatantly false pronouncements like "Linux is the only OS experiencing growth" or "Linux is the only contender for the x86 platform." These types of statements are pure hooey, of course, and FreeBSD is currently doing better than it has at any previous point in its history. Our releases are starting to finally hit their stride, it seems (and try to remember back to the days when it was more like: "My god! We did it! A release!"), and our rate of innovation and self- improvement hasn't been higher since the 2.0 days - it's very encouraging to see that we can spur ourselves to such heights of productivity *without* legal injunctions staring us in the face! :-)

Second, we have to keep sight of the fact that none of this is particularly new or even interesting. We know that Linux is the current poster child of the press and we also know about the press's irritating predilection for focusing on one and only one champion rather than looking more in depth at the situation. We can yell and scream all we like, but we're not going to change the fact that for many journalists investigating "Open Source", Linux is the first and possibly only thing they're going to look at. It simply has the right sized hype-bubble surrounding it where we do not. We also have to accept the fact that ISVs are going to target their products at the much more obvious Linux market and try to strike deals with it, going "FreeBSD? What's that?" when asked about a native port. The same goes for investment, selling shares in Red Hat, Inc., etc. Money always goes after the visible markets first.

What you have to ask yourselves, looking at the dynamics of this situation as dispassionately as possible, is whether all of this is necessarily as bad a thing as some of the gloom-n-doomers would have us believe. Looking at only the superficial indicators, it's easy to say that "Linux is winning and we're losing", pointing to the stacks of Linux books and magazines in the bookstores, the Clinton transcripts where he mentions Linux, the Goodyear blimp circling overhead with Linus's smiling face shining from it, etc etc. It's especially easy to say that when you hold Linux and FreeBSD in your mind as equivalent products, started at the same time and with the same overall development mentality.

The fact of the matter is that Linux and FreeBSD are NOT equivalent products with identical user and developer communities surrounding them, however. We've *always* been lower key about things, preferring to quietly focus on the business of steadily turning out quality products to only moderate fanfare. It's no use screaming for teams of FreeBSD fan dancers to come out and start singing the praises of FreeBSD in full 4-part hyperbole with some grinning, cigar-chomping promoter standing in the background - that's just not us. The nay-sayers will also say that "this not being us" will surely be our downfall since you gotta sing and dance now if you want to be noticed, but I'm really not so sure about that. To my way of thinking, we have our style and we have our niche and they're both respectable in their own way. Not everyone buys toilet paper because a team of singing rabbits (to paraphrase the great Rod Serling) suggested it on television, and some people DO react positively to the somewhat less superficial attributes of quality, consistency and a focus on the technology rather than on standing in front of the cameras and saying things like "open source validates the concept of a basic human sociological tropism towards cooperation and the free and open exchange of .." to some vapid blond on Technology Week.

That kind of approach might also get all the sound bites this week, but remember the old "15 minutes of fame" effect and the fact that the press is going to get bored with Linux eventually and go off in search of other things they don't understand to dissect. When that inevitably happens, it's going to be back to quality and those groups who remained true to their basic operating principles and didn't get sucked in and destroyed by excessive growth or hype. The opportunities for wandering off and getting lost in the woods in pursuit of some bright and shiny object have never been higher than they are now, and somebody's bound to panic and go off and do something stupid in an effort to differentiate themselves. I don't think we have any need to panic at all and should simply keep doing what we're doing and try to do it as best we can.

I'm not saying that there's no room for improvement, and some alliances *are* being made with various artist/marketing types whom we think can help us get the attention we deserve, but it's not the same as saying that we're going to drop everything and go play Linux's game now. That would be the wrong move and I can only point to the history of BSD itself when searching for good examples of technologies which have remained viable long after "losing" a war to a competitor. BSD "lost" to SYSV over a decade ago, but did that kill it? Quite apparently not and it appears to be doing better today than it ever did even back in its heyday, when it ran on a large collection of VAXes but hardly any of the commodity (68K) hardware at all (you had to buy an obscure 32016 based machine if you wanted to run BSD at home :-). The situation today is vastly improved by comparison and most people don't even stop to think about that.

In any case, I didn't mean this posting as a fluffy "we're fine!" sorta thing, though I do think that people sometimes lose sight of our own growth rate and notable successes when furrowing their brows over the latest Linux PR victory, I do have a summary of points I think we can and should improve:

  1. Keep pushing the magazine articles out. These seem to be easier for people than books and I've largely given up on trying to incite a FreeBSD book to happen - I guess that will just occur in its own good time. Walnut Creek CDROM is still paying a bounty for magazine articles (matching funds for your fee) and has enabled more than one person to buy a new machine for the price of one weekend's writing for a good cause. Pick a target publication and go for it, folks! I've done about 3 of these so far (maybe more, I forget :) and can say that it's not that hard. You generate a simple article outline and you submit it to the editor along with your proposal for what you're trying to accomplish with the article (just a paragraph or two of text, not a thesis). If they're interested, they'll send you back details on how long they want the article to be (generally 500-1000 words) and how much they're willing to pay. When they pay, send us a photocopy/FAX of your royalty check and we'll pay too. It's that simple, and it good for FreeBSD to appear in print like this since it reaches outside the somewhat closed audience of the mailing lists.

  2. Look at Linux as a door opener, not a threat. I mean this, folks, even you rabid Linux haters out there. Consider very carefully the fact that if customer A needs a PC to do server job B, customer A is going to do one of four things:

    1. Buy NT
    2. Buy a commercial Unix
    3. Buy Linux
    4. Buy *BSD

    Those really are about the only 4 options for building a department fileserver or gateway box with cheap, commodity hardware (we'll assume the people who don't want cheap buy Cisco gear, Suns and NetApp filers anyway) and let's look at them in turn:

    1. If they buy NT, you can pretty much write them off. By the time they realize what they've gotten themselves into, the investment (or embarrassment) is generally too great to back out of anyway and it's actually very few IS shops that seem to claw their way back from NT and install a free OS instead. Sure, you hear widely trumpeted stories whenever some large ISP does make it back from NT, but its very rareness is what makes it something to trumpet about. NT is Darth Vader here and we must fear his control of the dark side (marketing) and the fact that "everybody knows NT" when the issue of personnel comes up with most pointy-haired managers.

    2. Is a much better option since at least the customer has accepted Unix as their savior and can potentially be won over at some point by OSS, but the fact that they chose a commercial Unix probably also means that they have deep-seated needs for tech support or inter-operability with other parts of the IS shop and you'll probably have to work on them for awhile to win them over.

    3. Here now we've at least accomplished two things: We've got the customer admitting that they want Unix and that they want a free Unix. Furthermore, they've chosen a solution which we think we can beat in all the taste tests if we can just get the CD in front of their faces. All in all, this has got to be the easiest conversion of the three and a definite win if their only other options were A or B.

    4. Yay! Of course we like this one, but if it's not FreeBSD then we still have a bit of a conversion job to do and it might even require something like a SPARC port to be able to offer the same cross-platform inter-operability that the user has chosen the other *BSD for. It's something to think about, and certainly no better than the Linux scenario in some ways (again, if you're just thinking about this from the pure, mercenary "how do we get more FreeBSD users" perspective).

  3. Hold your advocacy to a higher standard, and by this I mean that if we're to weather this whole PR blitz period with our reputation for being "the calm and level-headed ones" intact, we can't stoop to the level of some Linux advocates when trying to make short-term gains against their PR blitzes. Sometimes you just have to be Gandi.

    When the press have gone away, believe me, people will remember which groups stuck to their guns and didn't compromise their identities or ideals and which went sort of nuts and participated in a few raping and pillaging sessions. I'd far rather be the group still standing there when the smoke clears going "Yup, we're still here and still doing good software without the fanfare or fancy costumes. Have a look!"

    To put it another way: If FreeBSD were a respected musical entertainer, I would want her to be the one who stuck to doing the kind of music she liked and always did it well rather than horrifying us during the disco years by suddenly putting on spandex pants and lip-syncing to formulaic, song-factory material or shrieking out heavy-metal lyrics in heavy makeup with Axel Rose 10 years later. :-) Sometimes the price of "success" is too high.

- Jordan

- &footer + &footer; diff --git a/en/advocacy/myths.sgml b/en/advocacy/myths.sgml index 24527dfaf0..dbefb97597 100644 --- a/en/advocacy/myths.sgml +++ b/en/advocacy/myths.sgml @@ -1,383 +1,383 @@ - + %includes; ]> &header;

As the BSD projects (FreeBSD, NetBSD, and OpenBSD) have grown in size, a number of persistent myths have grown up around them. Some of these are perpetuated by well meaning but misguided individuals, others by people pursuing their own agendas.

This page aims to dispel those myths while remaining as dispassionate as possible.

Note: Throughout this page, ``*BSD'' refers to all three of the BSD Projects. Where a myth or response is specific to a particular project it is indicated as such.
If you are aware of an omission or error on this page, please let the maintainer, Tom Rhodes <trhodes@FreeBSD.org> know.

Index

Myths

*BSD has a closed development model, it's more ``Cathedral'' than ``Bazaar''

Eric Raymond wrote an influential paper, ``The Cathedral and the Bazaar'' in which the Linux development model (and the model Eric used for fetchmail) is held up as an example of how to do ``open'' development. By contrast, the model employed by *BSD is often characterized as closed.

The implicit value judgment is that ``bazaar'' (open) is good, and ``cathedral'' (closed) is bad.

If anything, *BSD's development model is probably more akin to the ``bazaar'' that Eric describes than either Linux or fetchmail.

Consider the following;

Also, see this article written by Jordan Hubbard in Performance Computing, titled What is FreeBSD?

You cannot make your own distributions or derivative works of *BSD

You can. You just need to say in the documentation and source files where the code is derived from.

For example, PicoBSD is a tailored distribution of FreeBSD that fits on a floppy. It's great for turning a diskless 386 PC into a router or a network print server.

The Whistle Interjet is a ``network appliance'' that acts as a router, web server, mailhost (and other functionality), and can be configured using a web browser. The underlying operating system is FreeBSD, and Whistle have contributed many of their code enhancements back to the FreeBSD project (while keeping enough of them proprietary that they can stay in business).

The OpenBSD project started as a spinoff from the NetBSD project, and has since evolved its own distinctive approach.

*BSD makes a great server, but a poor (&unix;) desktop

*BSD makes a great server. It also makes a great desktop. Many of the requirements for a server (responsiveness under load, stability, effective use of system resources) are the same requirements as for a desktop machine.

*BSD has access to the same desktop tools (KDE, GNOME, windowmanagers) as Linux. And ``office'' applications such as WordPerfect or StarOffice work under BSD's Linux emulation layer.

The BSD codebase is old, outdated, and dying

While the BSD codebase may be more than 20 years old, it is neither outdated or dying. Many professional users like the stability that years of testing has provided FreeBSD.

Technological enhancements continue to be added to *BSD, including, but not limited to;

The *BSD projects are at war with one another, splinter groups form each week

No. While occasional advocacy may get a touch heated, the *BSD flavors continue to work with one another. FreeBSD's Alpha port was initially heavily based on the work done by the NetBSD team. Both NetBSD and OpenBSD used the FreeBSD ports collection to bootstrap their own port sets. FreeBSD and NetBSD both integrate security fixes first discovered by the OpenBSD team.

This cooperation extends to the commercial company BSDi, who graciously donated their DOS emulation layer to FreeBSD.

The FreeBSD and NetBSD projects separated more than five years ago. OpenBSD is the only new BSD project to split off in the last five years.

The *BSD projects cooperate in other areas as well. For example, the monthly publication DaemonNews is a collaborative effort by members of all three projects.

You can't cluster *BSD systems (parallel computing)

The following URLs should disprove this;

In addition to this, Tom Rhodes is currently writing an article designed to walk a user through setting up a Parallel Computing environment using FreeBSD and other utilities. Keep an eye out for this article in late 2002 early 2003.

There's no commercial support for *BSD

FreeBSD: The FreeBSD Commercial Consulting Page lists companies that offer commercial support for FreeBSD.

The FreeBSD Mall also offer commercial support, along with shirts, hats, books, software, and promotional items.

For training, one might try BSDMall.com, but they sell other items too, like shirts, hats, books and software! Definitely worth a look.

OpenBSD: The OpenBSD Commercial Consulting Page lists companies that offer commercial support for OpenBSD.

There are no applications for *BSD

The free software community started running on predominantly BSD systems(SunOS and similar). *BSD users can generally compile software written for these systems without needing to make any changes.

In addition, each *BSD project uses a ``ports'' system to make the building of ported software much easier.

FreeBSD: There are currently more than 8,000 applications ready to download and install in the FreeBSD ports collection. On both the i386 and Alpha, the Linux emulation layer will also run the vast majority of Linux applications.

NetBSD: The Linux emulation layer will run the vast majority of i386 Linux applications, and the majority of SunOS4 applications can be run on a SPARCStation.

OpenBSD: There are currently slightly more than 400 applications ready to download and install in the OpenBSD ports collection. The Linux emulation layer will also run the vast majority of i386 Linux applications, and the majority of SunOS4 applications can be run on a SPARCStation.

Both NetBSD and OpenBSD are able to use applications in FreeBSD's ports collection with minimal effort. Their lower number of ported applications reflects this.

It is true that most companies when porting to PC Unix will choose Linux first. Fortunately, *BSD's Linux emulation layer will run these programs (Acrobat, StarOffice, Mathematica, WordPerfect, Quake, Intel ICC compiler, Compaq's Alpha compiler ...) with few, if any, problems.

As a historical note, the first version of Netscape Navigator that ran on FreeBSD with Java support was the Linux version. Now you can also use a native FreeBSD version of Mozilla with a native Java plugin, all compiled conveniently from the ports!

*BSD uses the a.out executable format, which is outdated technology

FreeBSD: Quite a while ago (before 1998) FreeBSD used the a.out format by default. There were no pressing reasons to switch earlier. In particular, FreeBSD did not (and does not) have the problems building shared libraries that spurred the Linux conversion from a.out to ELF. As of FreeBSD version 3.0, FreeBSD uses the ELF executable format.

*BSD is better than (insert other system)

This is user opinion only.

(insert some other system) is better than *BSD

This is user opinion only

Contributors

Members of the FreeBSD, NetBSD, and OpenBSD projects have contributed to this page;

Nik Clayton <nik@FreeBSD.org> Jordan Hubbard <jkh@FreeBSD.org>
Ian F. Darwin <ian@DarwinSys.com>
Adrian Filipi-Martin <adrian@ubergeeks.com>
Tom Rhodes <trhodes@FreeBSD.org>
- &footer + &footer; diff --git a/en/java/advocacy.sgml b/en/java/advocacy.sgml index 23beff8b93..c391531d6c 100644 --- a/en/java/advocacy.sgml +++ b/en/java/advocacy.sgml @@ -1,25 +1,25 @@ - + %includes; ]> &header;

We would like to have FreeBSD known as the stable &java; platform.

Request for Enhancement to Sun:
We have petitioned Sun to provide an official FreeBSD port. We are currently in 2nd place in the vote count. If you are a member of the Java Develop er's Connection (it's free), you can vote for it as well http://developer.java.sun .com/developer/bugParade/bugs/4288745.html

Petition IBM for a port to FreeBSD:
In October, 1999, IBM released a new version of their IBM Developer Kit for Linux. We would like to see them release one for FreeBSD. If anyone has a point of contact in IBM that could spearhead this petition, please let Patrick Gardella know.

-&footer +&footer; diff --git a/en/security/security.sgml b/en/security/security.sgml index 637a659dbe..371ad458a9 100644 --- a/en/security/security.sgml +++ b/en/security/security.sgml @@ -1,313 +1,313 @@ - + %includes; ]> - + &header;

Introduction

This web page is designed to assist both new and experienced users in the area of FreeBSD security. FreeBSD takes security very seriously and is constantly working on making the OS as secure as possible.

Here you will find additional information, or links to information, on how to protect your system against various types of attack, on whom to contact if you find a security-related bug, and so on. There is also a section on the various ways that the systems programmer can become more security conscious so that he is less likely to introduce vulnerabilities.

Table of Contents

All FreeBSD Security issues should be reported directly to the Security Officer Team personally or otherwise to the Security Officer. All reports should at least contain:

A description of the vulnerability;
What versions of FreeBSD seem to be affected if possible;
Any plausible workaround;
And example code if possible.

After this information has been reported the Security Officer or a Security Team delegate will get back with you.

The FreeBSD Security Officer and the Security Officer Team

To better coordinate information exchange with others in the security community, FreeBSD has a focal point for security-related communications: the FreeBSD Security Officer.

If you need to contact the FreeBSD Project about a possible security issue, you should therefore send mail to the Security Officer with a description of what you have found and the type of vulnerability it represents.

In order that the FreeBSD Project may respond to vulnerability reports in a timely manner, there are four members of the Security Officer mail alias: the Security Officer, the Deputy Security Officer, and two Core Team members. Therefore, messages sent to the <security-officer@FreeBSD.org> mail alias are currently delivered to:

Jacques Vidrine <nectar@FreeBSD.org> Security Officer
Dag-Erling Smørgrav <des@FreeBSD.org> Deputy Security Officer
Robert Watson <rwatson@FreeBSD.org> FreeBSD Core Team member, Release Engineering liaison,
TrustedBSD Project liaison, system security architecture expert
Warner Losh <imp@FreeBSD.org> FreeBSD Core Team liaison, Security Officer Emeritus

The Security Officer is supported by the FreeBSD Security Team <security@FreeBSD.org>, a small group of committers vetted by the Security Officer.

Please use the Security Officer PGP key to encrypt your messages to the Security Officer when appropriate.

Information handling policies

As a general policy, the FreeBSD Security Officer favors full disclosure of vulnerability information after a reasonable delay to permit safe analysis and correction of a vulnerability, as well as appropriate testing of the correction, and appropriate coordination with other affected parties.

The Security Officer will notify one or more of the FreeBSD Cluster Admins of vulnerabilities that put the FreeBSD Project's resources under immediate danger.

The Security Officer may bring additional FreeBSD developers or outside developers into discussion of a submitted security vulnerability if their expertise is required to fully understand or correct the problem. Appropriate discretion will be exercised to minimize unnecessary distribution of information about the submitted vulnerability, and any experts brought in will act in accordance of Security Officer policies. In the past, experts have been brought in based on extensive experience with highly complex components of the operating system, including FFS, the VM system, and the network stack.

If a FreeBSD release process is underway, the FreeBSD Release Engineer may also be notified that a vulnerability exists, and its severity, so that informed decisions may be made regarding the release cycle and any serious security bugs present in software associated with an up-coming release. If requested, the Security Officer will not share information regarding the nature of the vulnerability with the Release Engineer, limiting information flow to existence and severity.

The FreeBSD Security Officer has close working relationships with a number of other organizations, including third-party vendors that share code with FreeBSD (the OpenBSD and NetBSD projects, Apple, and other vendors deriving software from FreeBSD, as well as the Linux vendor security list), as well as organizations that track vulnerabilities and security incidents, such as CERT. Frequently vulnerabilities may extend beyond the scope of the FreeBSD implementation, and (perhaps less frequently) may have broad implications for the global networking community. Under such circumstances, the Security Officer may wish to disclose vulnerability information to these other organizations: if you do not wish the Security Officer to do this, please indicate so explicitly in any submissions.

Submitters should be careful to explicitly document any special information handling requirements.

If the submitter of a vulnerability is interested in a coordinated disclosure process with the submitter and/or other vendors, this should be indicated explicitly in any submissions. In the absence of explicit requests, the FreeBSD Security Officer will select a disclosure schedule that reflects both a desire for timely disclosure and appropriate testing of any solutions. Submitters should be aware that if the vulnerability is being actively discussed in public forums (such as bugtraq), and actively exploited, the Security Officer may choose not to follow a proposed disclosure timeline in order to provide maximum protection for the user community.

Submitters should be aware that the FreeBSD Project is an open source project, and source revision control information for every change made to the FreeBSD source tree is publicly accessible. If a disclosure schedule is provided, it should take into account both the official release of advisory, patch, and update information, as well as initial inclusion of fixes in the FreeBSD source tree. There is necessarily a lag between the inclusion of fixes in the tree and the generation and releases of advisories, patches, and binary updates, as the source control system is used to generate them.

Submissions may be protected using PGP. If desired, responses will also be protected using PGP.

FreeBSD Security Advisories

The FreeBSD Security Officer provides security advisories for several branches of FreeBSD development. These are the -STABLE Branches and the Security Branches. (Advisories are not issued for the -CURRENT Branch.)

Issues affecting the FreeBSD Ports Collection are covered in the FreeBSD VuXML document.

Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or `Extended'. The designation is used as a guideline for determining the lifetime of the branch as follows.

Early adopter
Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release.
Normal
Releases which are published from the -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release.
Extended
Selected releases will be supported by the Security Officer for a minimum of 24 months after the release.

The current designation and estimated lifetimes of the currently supported branches are given below. The Estimated EoL (end-of-life) column gives the earliest date on which that branch is likely to be dropped. Please note that these dates may be extended into the future, but only extenuating circumstances would lead to a branch's support being dropped earlier than the date listed.

Branch Release Type Estimated EoL
RELENG_4 n/a n/a March 31, 2005
RELENG_4_8 4.8-RELEASE Extended March 31, 2005
RELENG_5_2 5.2.1-RELEASE Early adopter December 31, 2004
RELENG_4_9 4.9-RELEASE Normal October 31, 2004
RELENG_4_10 4.10-RELEASE Extended May 31, 2006

Older releases are not maintained and users are strongly encouraged to upgrade to one of the supported releases mentioned above.

Like all development efforts, security fixes are first brought into the FreeBSD-current branch. After a couple of days and some testing, the fix is retrofitted into the supported FreeBSD-stable branch(es) and an advisory is then sent out.

Some statistics about advisories released during 2002:

Advisories are sent to the following FreeBSD mailing lists:

Advisories are always signed using the FreeBSD Security Officer PGP key and are archived, along with their associated patches, at our FTP CERT repository. At the time of this writing, the following advisories are currently available (note that this list may be a few days out of date - for the very latest advisories please check the FTP site):

&advisories.html.inc; - &footer + &footer;