Slashdot Mirror

So you think a low market share device that effectively failed to achieve significant penetration on launch in 1993 is responsible for the success of an embedded low power processor that's been around since the early '80s? http://en.wikipedia.org/wiki/ARM_architecture

You're looking at the wrong Wikipedia page. I didn't say that Apple invented ARM. I said, "It launched ARM into the low-energy device market," which Apple did by founding ARM Holdings in 1990, along with Acorn and VLSI. After the Newton introduced the ARM architecture to an international audience, then DEC, etc. started licensing it. Apple reaped the rewards, by selling their ARM stock for hundreds of millions of dollars in the late-90's, when they were digging out of a crisis.

ARM was not the overwhelmingly obvious choice for a 32-bit handheld system at the time. MIPS was in several designs, and the PalmPilot used a DragonBall processor. Even making a personal CPU architecture was still an option, though not an especially viable one.

You mean like practically everyone?

Not quite like everyone, stupid.

I get you, but I use the SVN repo here and the ports search here for doing all that. Then I use either pkg or portmaster to install what I want. The other great thing is that pkgng the package manager is supported by puppet, chef, cfengine, ansible, and salt. So installing packages and keeping everything up-to-date across all the variety of servers in a datacenter is a snap.

I get you, but I use the SVN repo here and the ports search here for doing all that. Then I use either pkg or portmaster to install what I want. The other great thing is that pkgng the package manager is supported by puppet, chef, cfengine, ansible, and salt. So installing packages and keeping everything up-to-date across all the variety of servers in a datacenter is a snap.

You may want to revisit. The base tools for package management can be frustrating for someone who is learning them. Fortunately there are some newer tools that are in regular use probably after your last time using FreeBSD. The utility portmaster is most likely what you're looking for. It is able to control the ports system and package management very very very well. It has no external dependencies (it's actually just a huge shell script).

In addition to portmaster, the base system's package management has been completely rewritten in pkgng. You will find that it takes many good cues from debian apt.

All of these are command line tools. If you're a GUI type and shy away from command line, BSD's are not for you (yet).

You may want to pose that question to Netflix. They account for about 1/3 of the traffic on the internet and all that traffic is served from FreeBSD servers.

Also, Mac OS X is essentially a fork of FreeBSD.

The OS on all Juniper equipment is a modified version of FreeBSD.

The Playstation 3 and 4 OS are both modified FreeBSD.

Plus more.

You might find this interesting. It compares several versions of BSD with Linux.

Hmm? Is it really that simple? Recently I tried setting up an FreeBSD+XFCE combination and I humbly went through all the steps in the handbook regarding setting up and configuring X.org, installing and configuring the font packages and installing the ugly XDM, and finally installing XFCE.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/nutshell.html#introduction-nutshell-users You also forgot some biggies, like Netflix, oh and Apache themselves. Sampling an OS's usage numbers off of how many public facing web servers are out there will give you very biased results. I have two FreeBSD servers running OpenBGPd and OpenOSPFd, and two that are NFS servers, there is absolutely no web server on them. They are ROCKS of stability. This is just FreeBSD, a partner ISP I work with runs OpenBSD route reflectors.

Where does this myth come from

Since the late 90s there have been mumblings ("Someone I know who works at MS said they knew someone who said...") that code from BSD TCP/IP stack was in Windows but there was never any proof. Some speculated that because they were susceptible to some of the same vulnerabilities they must share common code but there were some vulnerabilities that affected the Windows TCP/IP stack not the BSD one (and vice versa) so this seems unlikely.

In 2001 the FreeBSD folks decided to search for proof but other than utilities nothing much was found. You can even see them correcting the "Windows uses the BSD TCP/IP stack" misconception years later.

Around the same time an article saying Microsoft uses open source code was published in the Wall Street Journal. Here's a quote:

Software connected with the FreeBSD open-source operating system is used in several places deep inside several versions of Microsoft's Windows software, such as in the "TCP/IP" section

This assertion is somewhat broard but it was enough to kick off a new round of speculation and rebuttals with regard to the Windows TCP/IP stack but everyone loves a good tale so the counterclaims are less well known. Perhaps this would qualify as a Snopes urban myth.

[H]ow did it end up being passed of as fact on wikipedia?

Who says Wikipedia only consists of facts? :-) Nothing saves you from having to use critical analysis on sources, especially since anyone can edit Wikipedia but I will note there is a citation needed link further down on that page.

All the above sources were found via a Google Windows/BSD stack query so with these starter links and a quick search you're now well armed to correct Wikipedia and anyone else who repeats this rumour. Welcome to the club!

why did he not say "Linux, BSD, and Other OSes

Maybe because the default setting in BSD is
          PasswordAuthentication = no
and
          PermitRootLogin = no

Could that be why he didn't mention the botnet logging into to lots of BSD boxes with password authentication?

I know it was mentioned in the FreeBSD 10 release, but looks like several other ZFS features for 10 made it into 9.2.

https://wiki.freebsd.org/WhatsNew/FreeBSD10 Can anyone smarter than me make sense of the SNV page to see if it's in 9.2 too?

http://svnweb.freebsd.org/base?view=revision&revision=243524

Thank you in advance.

I know it was mentioned in the FreeBSD 10 release, but looks like several other ZFS features for 10 made it into 9.2.

https://wiki.freebsd.org/WhatsNew/FreeBSD10 Can anyone smarter than me make sense of the SNV page to see if it's in 9.2 too?

http://svnweb.freebsd.org/base?view=revision&revision=243524

Thank you in advance.

things tend to go slow. Real slow. If you want things now, now, now, pay the man/men. It is free, as in someone-else-will-do-it, so you get what you, that's right, didn't pay for.

Fortunately, eventually people found this hobby project worth paying for, although I think it proved its worth before the big money started pouring in.

There are, of course, some other hobby projects that also manage to support a little more hardware than the Hurd does without huge amounts of money poured into them.

I made no such quoting error--that was direct from the New BSD text on the Wikipedia page--and I can't make any sense of whatever it is you're claiming. The 3rd clause of the New BSD license is "Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission". That puts no restrictions on the code, only on the identity of the contributor. It just says that if I contribute code, the project can't use my name and write "Greg says our project is awesome" simply because I contributed--not without my written permission. That's what endorsement/promotion means here. The BSD licenses have always had "endorse or promote" restriction text of this form in them, because the University of California @ Berkeley didn't want people to think a BSD license says they approve of a program.

If you're reading any sort of profit or sale restriction out of that clause, you're very confused about what these licenses mean. I'd recommend Why you should use a BSD style license as a good piece comparing these licenses. Modified BSD License is more terse description of the same area, with a particularly easy to follow description of New BSD->GPL moves work.

MariaDB picked New BSD as the alternate license because it's "GPL compatible". That means they can just slurp up any contributions under those terms without worrying about the copyright trail on that code at all. All they have to do is include the New BSD license in their source and binary distributions for those parts, not mention their contributors by name so they're not seen as endorsing that commercial version, and they're done. New BSD code gets assimilated trivially, GPL code comes in with copyright assignment, and therefore at all times MariaDB is uniquely able to sell derived products or the company itself with full ownership of any new code added--again.

...right, and that's exactly how Bugzilla, abrt and many other bug reporting addons for Linux distro's work. Hell, many of them even send in a core dump, up until recently in Fedora's case not even warning that the information contained within could be "sensitive." Try as I might, I can't remember you complaining about that on Slashdot. Selective memory, perhaps?

If you actually knew as much about security as you purport, then you'd have shut your face right around speaking aloud the laugh-inducing, "one [BREACH] away from having all your information spilled to them." Oh, but I'm sure you'll say something along the lines of real security being like an "onion," with multiple layers that one has to "peel away" before they can get at what they really want. What you don't seem to understand is to the professional hacker, your onion skins are about as thin and as fragile as the real ones. EVERYONE is "one [BREACH] away" from a serious security problem because every system out there can, and will, eventually be compromised, through a so-called "zero-day exploit," through sabotage via backdoors, the list goes on.

By the way, you really ought not use the same nickname everywhere you go. For more insight into the psyche of this Slashdot troll, I suggest using a search engine and taking a look at the following:

http://forums.freebsd.org/showthread.php?t=9612

Same gross spelling mistakes, same Linux bashing, no change whatsoever. Looks like when you're acting stupid you're neither anonymous nor private...and it gets preserved for future generations, no less. Leave a trail of stupidity all over the internet and it'll eventually lead back to your doorstep.

In case anyone here cares, Hyper-V support has been imported in HEAD - see http://svnweb.freebsd.org/base?view=revision&revision=255524 . I managed earlier today to build a kernel with it and do a number of performance tests - it looks good.
This is not present in the 10-Alpha CD yet by default, you have to get the latest source with svn, add ''driver hyperv" to the GENERIC and build it; I'd switch to labelled fstab entries before installing and rebooting it, though. Swap the 'de' with 'hn' network adapter etc.

Just for reference to those who aren't aware of who the post above is from

tlambert is:

http://people.freebsd.org/~terry/
http://www.linkedin.com/pub/terry-lambert/2/70a/770

I.E. He knows his shit and has the references to back it up. His resume is pretty much a list of industry leading companies for the last 25 years.

Given that Freebsd never released a good audit report after that hack I can only be worried more.

http://www.freebsd.org/news/2012-compromise.html

Get a clue troll. Why are you referencing some random website written 2 days after the incident was noticed rather than the vendor, who did a full write up on what happened?

Add to that, we now that we know the NSA had access to the certs from diginotar and might had done or paid for the diginotar hack I think one might as well use windows

What the fuck does that have to do with FreeBSD or Windows? You want to use Windows because it has Diginotar/Comodo certs included by default? You know FreeBSD itself doesn't trust ANYONE's certs by default, right?

And if you read the page you're linking to ... it was clear, even on that shitty page, that it effected pre-built ports. Specifically stating the OS itself had absolutely no risk of intrusion, since the keys in question had no access to write anything other than 3rd party packages.

You're just a ignorant troll, a shitty one at that.

Apparently you missed http://www.freebsd.org/handbook

In well written english, with screenshots and everything.

Exactly. The handbook is awesome. (I didn't even need to use it to get up and running because bsdinstall (the installer) is pretty self explanitory to anyone
who has been around any nix systems for a while.) You will want a copy of the manual somewhere handy

I haven't touched FreeBSD in years, but recently wanted to play with it again. It was awesomely well documented, both with a manual and several guides, not to mention a zillion Google Hits. I didn't need to bug anyone about any thing, because all the answers were at my finger tips. It was actually a very easy install.
I added XFCE4 just to see how well that worked, and it was quite nice.

If someone gets turfed from the mailing list, its because they joined the WRONG mailing list. Start asking for beginner help on the Linux Kernel Mailing List list and see how warmly you are received.

But installing version 9 was very easy. There is no reason to avoid FreeBSD if you like messing around with different OSs. Learning is not detrimental to your health.

Docker is based in LXC (linux containers), so not available in freebsd. But can be done a port or a similar project based on FreeBSD Jails. It also uses aufs and cgrups, but i think freebsd have similar tools too.

FreeBSD hosts interesting work with respect to TCP congestion control. An earlier version (I think FreeBSD 8.0) introduced modular congestion control algorithms, and this version introduces CAIA Delay-Gradient (CDG) congestion control algorithm. The check in is here: http://svnweb.freebsd.org/base?view=revision&revision=252504, and an interesting (if slightly esoteric) slide deck is here: http://www.ietf.org/proceedings/84/slides/slides-84-iccrg-2.pdf.

FreeBSD supports it too..just FYI:

http://svnweb.freebsd.org/base?view=revision&revision=240135

Redundant, keep reading the whole "What's New" page and the conspiracy klaxon attached to your tin-foil hat will go into hyper-overdrive...

"
Support for the RDRAND random number generator

Status:
Committed to -CURRENT, MFC-ed to 9-stable
Author:
Konstantin Belousov
Web:
http://svn.freebsd.org/changeset/base/240135
RDRAND is the new Intel's CPU instruction for accessing its hardware random number generator, also known as the code-name Bull Mountain. It is present in Ivy Bridge and newer CPUs.
" ...although it would seem more likely that Konstantin Belousov would be working for the FSB rather than the NSA really. ;^)

Try this one: https://wiki.freebsd.org/WhatsNew/FreeBSD10

I have to say, this is shaping up to be a very interesting release. Bhyve, in particular, sounds very promising...

It should be this easy on ALL linux distros. Here's a screencap of me installing the latest NVidia drivers on Lubuntu the other day:
http://youtu.be/49iq5A8d0e4

Yeah. That was like super-easy and I'm sure many Windows or OS X users would be impressed..

Also what's up with the lack of usage of the tab key, the multiple clears and I guess it would had helped if you had made sure the commands actually gave the results you where after in the first place + the warning at the beginning about a distribution specific pre-installation script failing.

As for FreeBSD:
http://www.freebsd.org/doc/en/articles/compiz-fusion/nvidia-setup.html

Or openSUSE:
https://en.opensuse.org/SDB:NVIDIA_drivers#Easy_way_to_get_NVIDIA_drivers

Ubuntu:
https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia

Fedora don't seem to be all that user friendly in this regard:
http://www.if-not-true-then-false.com/2013/fedora-18-nvidia-guide/
http://rpmfusion.org/Howto/nVidia#GeForce_8_and_newer

Archlinux guide is a little longer.. But also cover much more:
https://wiki.archlinux.org/index.php/NVIDIA
Like I remember a recent thread on Slashdot where this likely would had been helpful:
https://wiki.archlinux.org/index.php/NVIDIA#Base_mosaic

That does not appear to be the problem, that is, a new compiler version: http://lists.freebsd.org/pipermail/freebsd-current/2013-June/042598.html Note the report to freebsd-current was submitted Sat Jun 22 13:09:04 UTC 2013. /usr/src/sys/fs/nfsclient/nfs_clstate.c:5160:33: error: format specifies type 'long long' but the argument has type 'uint64_t' (aka 'unsigned long')

Building current FreeBSD appears to have been broken since last night on amd64, as of the tinderbox build at 2013-06-22 13:32 UTC http://tinderbox.freebsd.org/ This frequent and lengthy build breakage appears to be both a technical and a social problem. It is a technical problem because FreeBSD appears to lack suitable incremental build tools so that developers can quickly test patches before committing them. It is a social problem because even using plain CVS, OpenBSD's developers seem to have almost zero problem keeping their current source at least buildable.

I recall frequent kernel panics while booting that were related to the Intel Ethernet chipset on a SuperMicro H8SGL-F board (not exactly the least common hardware) in a released version (I think it was 8.2 or 8.3), which was probably this. Rather annoying.

There have been other problems, too (off the top of my head), like

• the mediocre PAE support,
• and the in my eyes rather ungracefully handled transition to Xorg 7.2 in the 6.x releases, which for me didn't work at all like the documentation said, although this was not a problem of the base system, but the ports collection.
• Then there's stuff like some guys arbitrarily deciding to reimplement the system installer and on top of that, to remove the old one in the time window between 9.0 RC 3 and 9.0-RELEASE, see (along with some elitist Linux bashing going on:) here and here
• or the transition to Clang at a time when it wasn't even ready for the non-x86 architectures!

So sometimes I ask myself whether this OS is really ready for prime time

But enough of the rant. I've been sticking to it since 2000 and for most of the time it just runs and does its job. It's got some nice coherent documentation too.

I recall frequent kernel panics while booting that were related to the Intel Ethernet chipset on a SuperMicro H8SGL-F board (not exactly the least common hardware) in a released version (I think it was 8.2 or 8.3), which was probably this. Rather annoying.

There have been other problems, too (off the top of my head), like

• the mediocre PAE support,
• and the in my eyes rather ungracefully handled transition to Xorg 7.2 in the 6.x releases, which for me didn't work at all like the documentation said, although this was not a problem of the base system, but the ports collection.
• Then there's stuff like some guys arbitrarily deciding to reimplement the system installer and on top of that, to remove the old one in the time window between 9.0 RC 3 and 9.0-RELEASE, see (along with some elitist Linux bashing going on:) here and here
• or the transition to Clang at a time when it wasn't even ready for the non-x86 architectures!

So sometimes I ask myself whether this OS is really ready for prime time

But enough of the rant. I've been sticking to it since 2000 and for most of the time it just runs and does its job. It's got some nice coherent documentation too.

There's new infrastructure that has been developed from FreeBSD, pkgng. It holds the promise of much better binary package management. There's just one problem: https://wiki.freebsd.org/pkgng "As a consequence of the security incident on 11th November 2012, for the time being pre-compiled packages for pkgng are not available from any official FreeBSD repository." The security incident happened in NOVEMBER 2012. Yet as of at least June 5, 2013, "Target dates for when service may be resumed have not been released."

I've never heard the name Olson before in relation to timezone updates. Thanks for the enlightenment but yes, this article was at least a little bit necessary, if not as earth shattering as an approaching asteroid.

cheers...ank

OTOH, the original poster clearly had, so why he didn't google for it and find those sources is an interesting question. Or why he hasn't considered alternative approaches (using a 3rd party JRE; using OpenJDK and following the update process described here, etc. Unless, of course, he's one of the many anti-Java nuts we seem to attract around here.

as root you can just chattr -i the file. Pity lunix doesn't have a feature like FreeBSD's securelevel.

The 8.4-RELEASE Errata notes are here:

http://www.freebsd.org/releases/8.4R/errata.html

It's of the utmost importance that all those considering upgrading (or installing) to 8.4-RELEASE read this document, particularly sections (3) and (4).

The issue with Intel NICs driven by fxp(4) is/was a very hot (heated) topic on the mailing lists (note: long thread, but very informative), and the issue described there may impact other NIC drivers as well. There is no workaround at this time other than avoiding DHCP (assigning static IPs in /etc/rc.conf).

The 8.4-RELEASE Errata notes are here:

http://www.freebsd.org/releases/8.4R/errata.html

It's of the utmost importance that all those considering upgrading (or installing) to 8.4-RELEASE read this document, particularly sections (3) and (4).

The issue with Intel NICs driven by fxp(4) is/was a very hot (heated) topic on the mailing lists (note: long thread, but very informative), and the issue described there may impact other NIC drivers as well. There is no workaround at this time other than avoiding DHCP (assigning static IPs in /etc/rc.conf).

The ports tree has Bash 4.2.45, i'm not sure how up-to-date this is compared to linux.

As for a list of shells, the Ports tree reports 49 different shells, although some of them are just tools: http://www.freebsd.org/ports/shells.html

As for your question, FreeBSD does has KSH and ZSH.

They typically keep putting out point releases in a series for about five years after the initial .0 release, so at any given time the current and previous one or two series are supported. But they eventually get phased out, e.g. the last 7.x release was 7.4, which came out in early 2011 and stopped being security-managed in early 2013. Wikipedia has a timeline showing the release/support history.

One of the reasons for maintaining the legacy branches for a few years is that, within each series, FreeBSD commits to maintaining binary compatibility. So, upgrades are simple & quick and won't break any third-party software you've built yourself from source. There's a bit more description of the difference in section 25.2.3 here.

[Wine] takes an existing binary compiled for a particular operating system/platform

"Platform" is nebulous enough to allow this. Qt and GTK+ are themselves "platforms" in a sense.

and runs it on a different one from that for which the binary was targeted. That makes it either a virtual machine or an emulator.

"Virtual machine" is closer because an application that uses Wine executes as a user mode process directly on the CPU without an interpretive or dynamic-recompilation step. Perhaps paravirtualization is even closer, as Wine could be considered a clone of Windows designed to run as a guest within a UNIX or UNIX-clone operating system. Is support for Linux applications in FreeBSD an emulator?

The regular package management for BSDs, the ports collection, is not like .rpm or .deb at all...Everything there is compiled from source based on some pretty beefy makefiles.

Binary packages are also available for many ports, this is not a new thing for the ports collection or pkgsrc which is what DragonFly BSD uses. In addition to the various formats software may be obtained from the ports collection there are various branches one may follow: unstable, stable, and release. With regards to staying up to date, FreeBSD uses a rolling release for their ports so staying on top of things can become involved if one is using a release machine in a desktop role, ya know with lots of client side libraries for Gnome/KDE/etc. If you're updating multiple machines a build server is one way to go, here is an interesting discussion addressing updating FreeBSD.

While I like FreeBSD keeping it up to date requires more effort, than say Debian, this will become apparent when there are multiple machines to tend to.

The regular package management for BSDs, the ports collection, is not like .rpm or .deb at all...Everything there is compiled from source based on some pretty beefy makefiles.

Binary packages are also available for many ports, this is not a new thing for the ports collection or pkgsrc which is what DragonFly BSD uses. In addition to the various formats software may be obtained from the ports collection there are various branches one may follow: unstable, stable, and release. With regards to staying up to date, FreeBSD uses a rolling release for their ports so staying on top of things can become involved if one is using a release machine in a desktop role, ya know with lots of client side libraries for Gnome/KDE/etc. If you're updating multiple machines a build server is one way to go, here is an interesting discussion addressing updating FreeBSD.

While I like FreeBSD keeping it up to date requires more effort, than say Debian, this will become apparent when there are multiple machines to tend to.

The regular package management for BSDs, the ports collection

The regular package management for BSDs is the pkg utilities, the ports collection is a source control tree of available software that you compile yourself.

The regular package management for BSDs, the ports collection

The regular package management for BSDs is the pkg utilities, the ports collection is a source control tree of available software that you compile yourself.

Wikipedia has a rather well written article on FreeBSD's ports system (and being that FreeBSD has the largest user base of the *BSDs, it is often thought of as "the BSD system"). http://en.wikipedia.org/wiki/FreeBSD_Ports

Additionally, it may be worth noting that FreeBSD is transitioning over to a new binary package system called "pkgng", (to replace pkg_add, not ports). I don't personally know much about it, but the trusty old FreeBSD handbook has a section on it: http://www.freebsd.org/doc/en/books/handbook/pkgng-intro.html

Quoting the ZFS Guide:

To use ZFS, at least 1 GB of memory is recommended (for all architectures) but more is helpful as ZFS needs *lots* of memory. Depending on your workload, it may be possible to use ZFS on systems with less memory, but it requires careful tuning to avoid panics from memory exhaustion in the kernel.

Yeah... 1GB memory just to run it. I'll pass. Somehow ext4 or btrfs have no problems running efficiently on a phone.

Interesting, thanks for that info.

An aspect of the file change log capability already exists in ZFS ("zfs diff"), which displays the file/dir changes between two snapshots or a snapshot/filesystem. It would be nice to determine what has changed on the filesystem since an arbitrary point, like btrfs can do. However, this isn't a capability that is intrinsically precluded from ZFS—the filesystem uses transaction IDs—it's more like no one has extended the zfs diff functionality yet.

As for the extents, that term seems to be overloaded in btrfs: extent block groups, extent trees, btree extent backrefs, etc. Were you referring to the extent block group administrative control, the allocation strategy, or something else?

Does btrfs allow you to add cache or log accelerator devices to a storage pool? I couldn't find any equivalent of that feature, based on my googling. Hm, "How ZFS continues to be better than btrfs" seems to indicate that log acceleration isn't available.

Oh, and who could forget RAID-Z[2,3]?

Having more choice is better, and perhaps a bit of competition from btrfs will prompt the ZFS devs to add additional features (eg. like the file change search capability).

stable and installer supported ZFS boot support for the / volume.

It's definitely stable (running 9.1-RELEASE here in a few places) but not in the installer until later.
Setting up a ZFS / install now isn't too difficult but does require using a livecd.
There is a great thread covering it from many angles here, including HD encryption.

http://forums.freebsd.org/showthread.php?t=31662

One thing I did here was go upwards of 50-60G for root, I find the 10g or 20g in the
examples isn't sufficient for keeping full /usr/src and /usr/ports populated + port builds.

so perhaps the vertical mode is the intended format and the horizontal mode is for backwards compatibility with a previous `cal` tool?

And the answer is in the most obvious of places. From the cal manpage:

The cal utility displays a simple calendar in traditional format and ncal offers an alternative layout, more options and the date of Easter. The new format is a little cramped but it makes a year fit on a 25x80 terminal.

and

HISTORY: A cal command appeared in Version 5 AT&T UNIX. The ncal command appeared in FreeBSD 2.2.6. The output of the cal command is supposed to be bit for bit compatible to the original Unix cal command, because its output is processed by other programs like CGI scripts, that should not be broken.

Naturally I went and found FreeBSD's archived copy of cal (which does indeed print in horizontal format, and was replaced with ncal in 1998) before I thought to look at my own system's manpage.

oops... that's crap. This is how it's done.
NETBOOT!

If you're patient, consider using FreeBSD, and wait for them to support Xen/Dom0 for full virtualization capabilities. They're not there yet, but there's work being done right now.

Take a look at this one: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/128587

One byte, two years.

By the way, how can one say FreeBSD a state-of-the-art system, they used *this* installer for twenty years.
- Hey, we've got a new mirror, let's recompile!