f9105467ef
Submitted by: Emily Boyd (emilyboyd at emilyboyd dot com) Sponsored by: Google Summer of Code 2005
375 lines
23 KiB
Text
375 lines
23 KiB
Text
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
|
|
<!ENTITY base CDATA "..">
|
|
<!ENTITY date "$FreeBSD: www/en/news/sou1999.sgml,v 1.6 2002/03/16 08:09:20 murray Exp $">
|
|
<!ENTITY title "FreeBSD State of the Union, 1999">
|
|
<!ENTITY % navincludes SYSTEM "../includes.navabout.sgml"> %navincludes;
|
|
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
|
]>
|
|
|
|
<html>
|
|
&header;
|
|
|
|
<p><i>From Jordan Hubbard <jkh@FreeBSD.ORG>, Sunday January 10th,
|
|
1999.</i></p>
|
|
|
|
<p>Well, it's another year behind us, folks, and probably high time for
|
|
another state of the union report!</p>
|
|
|
|
<p>Ahem... I'm never quite sure how to word these things since I'm
|
|
always reminded of a U.S. president sitting in front of fireplace,
|
|
trying to sound down-home and folksy for the corn growing states, or
|
|
perhaps England's Queen on Christmas day, giving her usual
|
|
somber-yet-hopeful address on how things went for Britannia during the
|
|
previous year and what everyone should perhaps think about for the
|
|
next. Neither one of those is really me, basically, so perhaps I'll
|
|
just cut to the chase and focus on the most pertinent lessons (and
|
|
objectives) to come out of the year 1998 for me.</p>
|
|
|
|
<p>1998 was, of course, the year that the Internet got bigger (no
|
|
surprise), various "internetpraneurs" (gag) got richer and FreeBSD's
|
|
user base, as measured by the ftp download stats grew at its usual
|
|
200-300% rate. More companies also entered the FreeBSD arena, either
|
|
offering add-ons for or solutions incorporating FreeBSD, and our PR
|
|
machine, as flimsy and low-key as it often is, managed to ratchet
|
|
things up another notch. All in all, it was a very good year for
|
|
FreeBSD and I don't think that even the most paranoid of us could
|
|
claim otherwise - Microsoft took one in the shorts, we got bigger and
|
|
just a bit better known, life was good.</p>
|
|
|
|
<p>Well, mostly. Whipping off my rosy glasses for a second, I can also
|
|
say that there were still a number of rocks in the road and unexpected
|
|
bends that left us not always in the best of control there. While
|
|
downloads have gone up, CD sales aren't quite following suit since the
|
|
whole CD market in general is suffering from increased Internet
|
|
availability and its erosion of some of the CD's fundamental
|
|
advantages. We still did quite well, considering the market's gradual
|
|
implosion, but it would be foolish to continue to rely on a single CD
|
|
product to provide the kinds of subsidies that have been steadily
|
|
oiling the project's gears (we more than doubled the size of the
|
|
FreeBSD.org computing cluster, for example, and significantly enlarged
|
|
our developer equipment grant program in 1998, all things which cost
|
|
$$$). It's fairly obvious that Walnut Creek CDROM will need to
|
|
increase the number of products it offers if it wishes to remain an
|
|
effective player in the FreeBSD game and we must continue, as a
|
|
project, to be flexible in exploring all types of relationships with
|
|
those who may now have a vested interest in FreeBSD's success. Things
|
|
are well past the point where we can do everything that needs to be
|
|
done as a serious and "grown up" solution just on good will and
|
|
volunteerism alone.</p>
|
|
|
|
<p>With that in mind, sites like the <a
|
|
href="http://www.freebsdmall.com">FreeBSD Mall</a>
|
|
have been set up to try and market a wider variety of FreeBSD-related
|
|
products and we've also begun exploring relationships with various
|
|
companies who can derive measurable value from any PR campaign that
|
|
enhances FreeBSD's reputation (translation: we want them to help pay
|
|
for it :). As many people have somewhat bitterly pointed out by now,
|
|
this business has become a 10% technology and 90% perception equation
|
|
as far as the direction in which people stampede is concerned, and
|
|
hate them for the mindless little sheep that they are, you still need
|
|
to understand people's tendencies and behavioral patterns when it
|
|
comes to dealing with anything they don't really understand. We've
|
|
done a great job on the technology, we really have (and should be
|
|
proud of that), but all too frequently we just throw up our hands over
|
|
the perception issue and tell people to think whatever the hell they
|
|
want to. Bad techies! Myopic techies! :-)</p>
|
|
|
|
<p>What can we do to change this in 1999? Well, I've also heard our
|
|
advocate corps calling for logistical support ("Backup! We need some
|
|
<em>backup</em> here!!") and I've listened to them, part of my project
|
|
for the new years being to get more digital daemon imagery made available
|
|
(which I have already commissioned), more glossies with various handy
|
|
comparison charts on them ("FreeBSD and NT", "FreeBSD and Solaris",
|
|
"FreeBSD and Linux", etc) and more newsletters for passing out to people.
|
|
We can also produce more marketing periphenalia like buttons, stickers,
|
|
new T-shirts, etc. to give people a wider array of stuff to proudly point
|
|
to in support of the "emerging FreeBSD phenomenon." If we can manage to
|
|
raise more money for PR, we can also perhaps buy some of these items in
|
|
bulk to use as give-aways in various promotional deals. Other than that,
|
|
I'm always open to suggestions. We need to do more effective PR, that
|
|
much is inarguable, it's only a question of picking our targets for
|
|
maximum effect given a limited operating budget.</p>
|
|
|
|
<h2>The core team:</h2>
|
|
|
|
<p>1998 also ended with a bit of a bang as far as FreeBSD's project
|
|
management was concerned, frustration with a mostly recumbent core
|
|
team goading a couple of bearded Danish Vikings into staging a
|
|
midnight raid on -current, ruthlessly culling the weak and the lame
|
|
from the source tree. Unfortunately, some of those weak or lame bits
|
|
of code were still in use at the time and, with no prior public
|
|
warning having been given, it did not exactly leave the various
|
|
followers of -current with the feeling that the event was going to be
|
|
the highlight of their Christmas season. Their complaints led, in
|
|
turn, to something of a constitutional crisis within core, the rival
|
|
factions each accusing one another of either impeding progress or
|
|
using cowboy tactics to achieve that progress, and each faction had
|
|
its legitimate points just as it had its wholly unreasonable ones.
|
|
Coming out of this, various suggestions were bandied about concerning
|
|
how we might put together a "better core team" to which such things
|
|
simply did not happen (or, if they did, would not be our fault since
|
|
we'd all be long gone :-) and many of these suggested cures were
|
|
eventually deemed, quite rightly, to be worse than the disease. So
|
|
what did we learn from the exercise then?</p>
|
|
|
|
<p>First off, I think everyone is now pretty much in agreement that these
|
|
sorts of drive-by shootings are just not an option for the future, no
|
|
matter what the justification. Anyone who contemplates a major
|
|
addition or removal of functionality from the source tree MUST
|
|
communicate those intentions well in advance and give the readership
|
|
of -current, -stable or -announce (the former two depending on the
|
|
branch the changes affect and the latter on the extent of the changes)
|
|
ample time to respond. If there is a conclusively negative response
|
|
to a proposed change, it just doesn't happen until and unless the
|
|
proposal somehow manages to win people over through sheer dint of
|
|
persuasive argument in its favor. If it's more a mixed bag of
|
|
reactions, or there is little reaction at all, the developer is free
|
|
to proceed at his or her discretion but still never without advance
|
|
notice.</p>
|
|
|
|
<p>Second, in reaction to the various proposals put forward to either gut
|
|
core or have core elected by popular vote, let me just say that we're
|
|
not going to do that. There are probably several people currently in
|
|
core who would gladly step aside and retire if they felt that adequate
|
|
replacements had been found and the project was in good hands, but
|
|
none of us like the scenario where anyone is overtly forced out of
|
|
core. It's just not a reasonable way of going about it when so many
|
|
less painful alternatives exist, and I, for one, would far rather
|
|
simply grow core and let the inactive members fall off when they
|
|
themselves have come to a decision that they have nothing left to
|
|
contribute at a "core level", resignation from core having not stopped
|
|
several folks from remaining as effective committers or making other
|
|
valuable contributions.</p>
|
|
|
|
<p>We're a free software project and nobody's paid to be in core, no
|
|
matter how seriously we may be tempted to take the whole core thing
|
|
sometimes, and we need to remember that all of this started as a bunch
|
|
of folks who simply wanted to work together in creating something
|
|
useful and interesting. The day we lose that kind of informal
|
|
atmosphere of productivity over politics is the day that something
|
|
pretty fundamental goes out at the center of core and also the day
|
|
that I'll retire from it myself, handing my hat to a replacement and
|
|
wishing everyone the very best of luck.</p>
|
|
|
|
<p>I can also only sound a similar cautionary note about the idea of
|
|
electing core from the user base, or with committers serving as a kind
|
|
of "electoral college", as nice and democratic an idea as that might
|
|
sound. The FreeBSD core team does not represent a democratically
|
|
selected body and was, in fact, very carefully put together in a very
|
|
non-democratic way. We picked core with the specific intention that
|
|
it represent as diverse a set of hard-core FreeBSD evangelist/developers
|
|
as we knew how to find and we've continued to add people using the
|
|
same criteria.</p>
|
|
|
|
<p>In bringing someone into core, we don't look at whether they've been
|
|
winning popularity contests lately or won the Programming Olympiad 3
|
|
times in a row, we ask ourselves: "Does this person bring a unique
|
|
talent or viewpoint to the group? Will the resulting whole be greater
|
|
than the sum of its parts?" These are our two most overriding
|
|
concerns and, in fact, are the only grounds on which we've ever felt
|
|
it necessary to actually ask for someone's resignation from core. We
|
|
can tolerate quite a bit from people but not when it impacts core's
|
|
fundamental ability to work together or seeks to undermine the very
|
|
diversity of opinion we've worked so hard to cultivate. It's good to
|
|
be an effective group of decision makers as a core team, and we do
|
|
have our moments (both ways), but sometimes it's even better to know
|
|
simply when to stay out of the way and just make sure the train stays
|
|
roughly on the tracks. We've prevented a lot more stupidity through
|
|
having such a diverse and carefully selected core team than I think
|
|
we've ever caused and I do not trust the democratic process to leave
|
|
us with the same thing after a few elections.</p>
|
|
|
|
<p>Core is also continuing to work on drafting some internal documents
|
|
which cover, in much better detail, just what our rules as committers
|
|
are, those superseding any "core member privileges", governing how
|
|
large-scale code removal and addition operations should be carried
|
|
out. We'll post something to committers just as soon as we finally
|
|
flesh it out to our mutual satisfaction but, in a nutshell, it
|
|
basically just insists that people need to be warned before such
|
|
changes happen and that the owner of a given body of code should be
|
|
given first say as to whether or not it's time to kill it in the name
|
|
of obsolescence or redundancy. Finally, we are looking at the general
|
|
issue of communication inside and outside core and the question of
|
|
whether or not to bring in some new member(s) at this time. That
|
|
discussion is ongoing and I'll do my best to keep everyone up to date
|
|
on that as things progress.</p>
|
|
|
|
<h2>Release numbering:</h2>
|
|
|
|
<p>Other decisions on the horizon concern returning to our former
|
|
practice of using "major" version numbers for branches and "minor"
|
|
numbers for releases, the revision number field only being used to
|
|
denote point-releases which were done for some reason significant
|
|
enough to merit such a special release. This means that the next
|
|
release will be 3.1, not 3.0.1, and the new branch will be 4.0-current
|
|
instead of 3.1-current. Is this just a marketing ploy? No, it's not,
|
|
though marketing has indeed been a frequent casualty of our current
|
|
numbering scheme.</p>
|
|
|
|
<p>We have frequently made fairly large changes between our "point
|
|
releases", jumps like 2.2.5->2.2.6 and 2.2.6->2.2.7 being a lot bigger
|
|
than most folks gave them credit for given that it was just one little
|
|
revision number being changed. This one simple facet of human nature
|
|
reduced the effectiveness of these releases and under-sold the work
|
|
being done by our developers to substantially improve <em>every</em>
|
|
release we do, regardless of which branch it's on.</p>
|
|
|
|
<p>This is not a trend which seems to be reversing itself and so I feel
|
|
quite safe in saying that 3.1 will be a "full release" over 3.0 in its
|
|
own right and not merely the "3.0.1" which conveys such a different
|
|
impression. It's also very important to note that since our branches
|
|
seem to typically last from 12-18 months these days, no matter what we
|
|
try in attempting to kill a branch earlier, a major version bump (4.0)
|
|
is entirely merited for something which won't see full release status
|
|
until sometime in the year 2000. This will make the marketing people
|
|
happy since they won't have such an uphill battle on number perception
|
|
and it will make the users happy since they'll get a clearer picture
|
|
of what changed in, say, 3.1 to 3.2 vs 3.1 to 3.1.1 (which might be an
|
|
important security update). It will also make this particular
|
|
developer happy since I'll have the revision number space back again
|
|
for doing point releases. It's a win and so we're going to do it.
|
|
3.0.1 is dead, long live 3.1! :)</p>
|
|
|
|
<h2>Technology:</h2>
|
|
|
|
<p>This last year also saw a successful transition to ELF from a.out
|
|
format and a new kernel loadable module scheme which allows modules to
|
|
be read in without a runtime dependency on /usr/bin/ld. We also got a
|
|
new boot loader (with a forth interpreter!) to aggregate a "kernel" at
|
|
boot time. These are both powerful new mechanisms and, coupled with
|
|
some new stuff which will be coming in 1999, should give us a far more
|
|
dynamic and extensible system than we've ever had before.</p>
|
|
|
|
<p>Not to be overlooked is also our new SCSI CAM system, giving us more
|
|
robust behavior with large drive arrays and supporting more of the
|
|
high-end SCSI controllers, or the support for multiple processors on
|
|
the x86. We made considerable progress all across the board with the
|
|
release of 3.0, finally reaching a point with the DEC Alpha
|
|
architecture port where people starting worrying more about the
|
|
packages collection than they did about working kernels or a /usr/src
|
|
which built. That represents considerable progress towards "genuine
|
|
usefulness" and I hope that 1999 will see a fully desktop capable
|
|
release of FreeBSD/axp (to say nothing of a server capable one),
|
|
various difficulties with X server technology making the Alpha desktop
|
|
a unique milestone in its own right, especially if it's on an ARC or
|
|
AlphaBIOS machine. 1999 may also see the early release of a SPARC
|
|
port, though it's still far too early to say anything more definite
|
|
than that. Join the <a
|
|
href="mailto:sparc@FreeBSD.org">sparc@FreeBSD.org</a> mailing list if
|
|
you want to follow these efforts.</p>
|
|
|
|
<p>IPv6 and IPSec were also hotly debated topics in 1998, FreeBSD's
|
|
refusal to back any specific implementation being cited by many as an
|
|
example of core's over-conservatism in action. Happily for everyone,
|
|
our wait-and-see attitude proved to be the right one when the two
|
|
major "competing" groups, KAME and INRIA, finally agreed to merge
|
|
their implementations. We have, in turn, committed to adopting this
|
|
merged implementation and have several people from the KAME/INRIA
|
|
groups on the FreeBSD development team who will be importing and
|
|
maintaining this code as it becomes available.</p>
|
|
|
|
<p>There is also substantial work underway with the VM system and the
|
|
filesystem code, much of which is either being tested quietly in small
|
|
groups (Dillon/Dyson/Greenman) or is awaiting the 4.0 branch event,
|
|
still scheduled for January 15th, 1999. In other areas, we have
|
|
Kazu's very welcome total redesign of the console driver coming into
|
|
-current along with USB support, courtesy of Nick Hibma and others.
|
|
This is just to name a few of the projects underway and I don't mean
|
|
to slight anyone by not mentioning theirs directly, these are just 3
|
|
ongoing projects right off the top of my head. We seem to be gaining
|
|
a lot of technical momentum, and that's great, just so long as we can
|
|
also keep our heads during the times where not everyone is in total
|
|
agreement about which technical direction to take.</p>
|
|
|
|
<h2>Tech support:</h2>
|
|
|
|
<p>A point which should also be obvious to everyone yet still somehow
|
|
requires frequent reinforcement is the fact that we need to maintain
|
|
participation in this project as something which is also
|
|
<em>enjoyable</em> for the developer/participants or they will just as
|
|
quickly go away again and stop giving each and every one of us the
|
|
benefit of their volunteer labor (on which a dollar value could not
|
|
even be put). This is something which each and every one of our
|
|
users needs to be aware of, at least somewhere in the back of their
|
|
minds, for those times when they're tempted to start thinking of
|
|
FreeBSD as just another shrink-wrap solution from Software,
|
|
Inc. and start treating project members like personal employees.
|
|
Those looking for actual FreeBSD employees should send mail to
|
|
<a href="mailto:jobs@FreeBSD.org">jobs@FreeBSD.org</a> and indicate how
|
|
much money they're willing to pay, otherwise don't do it.</p>
|
|
|
|
<p>I don't mean to come across so harshly here that people don't even
|
|
bother asking us for help, I'm simply saying that those users who
|
|
avail themselves of the various FreeBSD volunteer tech support
|
|
mechanisms out there (mail, news, irc, etc) should always understand
|
|
that asking another perfect stranger for help is just not much
|
|
different from asking a random person on the street for a dollar. If
|
|
you want to get free handouts, you'd better at the very least learn to
|
|
ask politely and when to take "no" for an answer! :-) I've seen a lot
|
|
of abuse of the various tech support forum volunteers this last year
|
|
and it frankly sucks. People just need to be more considerate and
|
|
stop regarding free tech support as a god-given right rather than a
|
|
very special privilege. If you want on-demand tech support, go to
|
|
www.freebsdmall.com and order yourself a tech support contract. You
|
|
get what you pay for! :)</p>
|
|
|
|
<h2>Looking forward:</h2>
|
|
|
|
<p>What do I see ahead for 1999? Well, assuming that we don't all vanish
|
|
in some pre-millennial holocaust, I see more interesting new features,
|
|
improved marketing, more commercial interest, more magazine articles
|
|
and press attention, basically more of the same if we can just try to
|
|
stay reasonably well focused on what we need to do and not get
|
|
distracted into chasing weird desktop dreams or suddenly become overly
|
|
minimalist or kitchen-sink biased in /usr/src, continuing to chart the
|
|
middle course we're more famous for. The FreeBSD core team, one year
|
|
older and hopefully a little wiser, needs to continue keeping a light
|
|
but steady hand on the tiller, relying on our developers as usual to
|
|
provide much of the actual motive force behind FreeBSD.</p>
|
|
|
|
<p>Our users also need to become more involved and I'm hoping that 1999
|
|
will be the year when a lot more local user groups and other self-help
|
|
type of organizations are formed. The Handbook and FAQ are documents
|
|
which are getting better, hopefully another trend we'll see continue
|
|
into 1999 as Nik Clayton, our fearless new Documentation Project
|
|
leader, continues at the helm. We still have to remember, however,
|
|
that for many users the handbook and FAQ docs are just not enough.</p>
|
|
|
|
<p>Linux has succeeded largely because of a large grass-roots support and
|
|
evangelism network which allows it to reach such people and
|
|
communicate the message to them. If FreeBSD's own users want to see
|
|
FreeBSD doing better against whomever they most perceive as its
|
|
competition, and 1998 was certainly a year where I heard a lot of
|
|
complaining about this, then they're going to simply have to get off
|
|
their collective duffs and put in more of this kind of work. When was
|
|
the last time a bunch of FreeBSD users got together to hand out
|
|
FreeBSD literature at a Microsoft product launch, for example, or held
|
|
an install-a-thon at a local computer show?</p>
|
|
|
|
<p>The Linux folks do things like that all the time, apparently, whereas
|
|
only a very few die-hard FreeBSD users currently do it now, so why not
|
|
help these people out? Join the <a
|
|
href="mailto:advocacy@FreeBSD.org">advocacy@FreeBSD.org</a> mailing
|
|
list and discuss your plans there so that others with more enthusiasm
|
|
than ideas can also learn from and perhaps help you with yours. Write
|
|
short articles for the new advocacy sites like <a
|
|
href="http://www.daemonnews.org/">www.daemonnews.org</a> or <a
|
|
href="http://www.freebsdrocks.com/">www.freebsdrocks.com</a> and help
|
|
promote the success of BSD evangelical publications.</p>
|
|
|
|
<p>Phrases like "this is your FreeBSD" and "it all depends on you" may
|
|
seem shop-worn and trite, but they're also unfortunately still true
|
|
when there's so few of us and so many of you. If FreeBSD is to
|
|
<em>really</em> continue to succeed in 1999, it will only be with
|
|
substantial user participation and that means you, users! Start a local
|
|
user group, donate some of your older CD releases to the local library,
|
|
try and convince a local small business or ISP to use FreeBSD, these are
|
|
just a few of the many things that can be done if you're truly
|
|
interested in putting some energy into FreeBSD and ideas for what to do
|
|
will be the least of your worries if you're truly motivated.</p>
|
|
|
|
<p>Executive Summary: 1999, rah rah rah, let's do it! :)</p>
|
|
|
|
&footer;
|
|
</body>
|
|
</html>
|