Slashdot Mirror

A whitelist DNS server can store data in memory &/or disk as a hash table. I bet u like hash :) lol. /etc/hosts is O(N) speed but a hashtable is O(1) speed. That means it's faster than /etc/hosts. Also, the /etc/hosts file is re-loaded and re-parsed every time u do a DNS lookup => http://svnweb.freebsd.org/base/stable/9/lib/libc/net/

Look at how FreeBSD development has been absorbed by Apple even though it was supposedly "Open Source"

Did Apple using FreeBSD cause the original code to become unavailable for download, installation and libre use? Supposedly, it's still available and still very open.

You should try PC-BSD. It's really a true FreeBSD with a great innovation called PBI (it just install packages like you do on Mac or Windows).

If you need anything else there's the famous ports, except that now FreeBSD has a binary package manager for apps , e.g., like apt-get. See also pkgng - next generation package management for FreeBSD.

(NB: binary system upgrades was made possible years ago).
PS: Right now, packages are on hold because of the recent security incident, so only ports are active (they're source files). BTW, before any Linux fanboy says anything, shall I remind them how many times Debian has been hacked?

There is always the new package manager if you don't need any special options and are fine with binaries:
http://wiki.freebsd.org/pkgng
https://mebsd.com/make-build-your-freebsd-word/pkgng-first-look-at-freebsds-new-package-manager.html

It easily rivals apt-get but I still stick with the regular ports system because I need to compile several packages (other than the dependancies) myself for the different options not available with binaries and I've never found compiling from source anywhere near as simple on linux distributions as it is on FreeBSD.

I've been using 9.1-RELEASE since SVN was tagged 2012-12-04 on both my home and work desktop. ZFS root is awesome, and userland is pretty much the latest bleeding edge upstream, I've had absolutely no issues running a full-fledged XFCE-4.10, Firefox ESR 10.x with Flash, 3D accel, everything desktop.

I've used freebsd-update to go from both 9.1-RC3 and 9.0-RELEASE to 9.1-RELEASE also switching to pkgng.
I'd recommend folks to look at the following guides if they want to use ZFS root or create a nice, full-featured desktop OS.

http://forums.freebsd.org/showthread.php?t=31662 (ZFS ROOT)
https://cooltrainer.org/2012/01/02/a-freebsd-9-desktop-how-to (good desktop guide)

Great job BSD devs, keep it up.

Maybe the Linux Foundation (or someone else, they're the first that come to mind) could do a similar thing to raise money for improving the Linux graphics and wireless stacks? How much improvement could we get for a million USD? Or perhaps there are individual developers out there who would do what Poul-Henning Kamp did? I'd be happy to contribute to such an initiative. Kickstart it?

Marshall Kirk says: "Check back on the FreeBSD Foundation web site in the last few days of the year or January of next year to see the final result." (End quote.) But to me it's like a spectator sport!

It's not a "failure" by any stretch of imagination. A lot of fundraising projects set an ambitious goal, and the year is far from over. The current tally is $304,844 - perfectly "on target"!

UPDATE: $319,614 - from 1082 donors!

Maybe the December issue of the BSD Magazine, which just came out yesterday, will remind more people to donate...

Maybe some are waiting for 9.1 release...

And maybe, as feedback for the recent security screw-up, some people have decided to donate to other projects (hopefully copyfree ones) instead...

--libman

UPDATE: $325,359 - from 1102 donors!

Please donate today!

--libman

It's not a "failure" by any stretch of imagination. A lot of fundraising projects set an ambitious goal, and the year is far from over. The current tally is $304,844 - perfectly "on target"!

UPDATE: $319,614 - from 1082 donors!

Maybe the December issue of the BSD Magazine, which just came out yesterday, will remind more people to donate...

Maybe some are waiting for 9.1 release...

And maybe, as feedback for the recent security screw-up, some people have decided to donate to other projects (hopefully copyfree ones) instead...

--libman

Alright, here's my shtick... It's a great race between two open source software ecosystems: copyLEFT and copyFREE.

The copyFREE side is a more amicable pacifist bunch, with more freedoms and more choices, and it has been gaining ground in the last decade in all software categories but one - the kernels. The copyLEFT side was founded by a bunch of militant hippies trying to destroy capitalism, and it had several years' head start, so its viral licenses were grandfathered into some of the most important pieces of open source software. The OS projects within each team like to share code, and the copyLEFT team can also mooch copyFREE code as well, but not the other way around...

This race is contested on many fronts, and one obscure comparison (that I just came up with) is: while running the race forward, to still maintain support for the 80386 platform. Only UNIX systems (sorry, sorry, sorry) that can run on a 80386 PC (sorry, sorry) with actively maintained current versions (sorry) are to be included. Let's see how the two teams compare:

THE COPYLEFT TEAM:

(1) Linux - now i486, as mentioned in this article.

THE COPYFREE TEAM:

(1) FreeBSD - i486 since 2005.

(2) OpenBSD - i486 since 2007.

(3) NetBSD - i486, "80386 support removed" in 2007.

(4) MINIX 3 - i586, 32mb RAM, 635mb HD.

So it looks like the copyLEFT camp had this little "current UNIX on 80386" advantage, and now lost it...

--libman

Alright, here's my shtick... It's a great race between two open source software ecosystems: copyLEFT and copyFREE.

The copyFREE side is a more amicable pacifist bunch, with more freedoms and more choices, and it has been gaining ground in the last decade in all software categories but one - the kernels. The copyLEFT side was founded by a bunch of militant hippies trying to destroy capitalism, and it had several years' head start, so its viral licenses were grandfathered into some of the most important pieces of open source software. The OS projects within each team like to share code, and the copyLEFT team can also mooch copyFREE code as well, but not the other way around...

This race is contested on many fronts, and one obscure comparison (that I just came up with) is: while running the race forward, to still maintain support for the 80386 platform. Only UNIX systems (sorry, sorry, sorry) that can run on a 80386 PC (sorry, sorry) with actively maintained current versions (sorry) are to be included. Let's see how the two teams compare:

THE COPYLEFT TEAM:

(1) Linux - now i486, as mentioned in this article.

THE COPYFREE TEAM:

(1) FreeBSD - i486 since 2005.

(2) OpenBSD - i486 since 2007.

(3) NetBSD - i486, "80386 support removed" in 2007.

(4) MINIX 3 - i586, 32mb RAM, 635mb HD.

So it looks like the copyLEFT camp had this little "current UNIX on 80386" advantage, and now lost it...

--libman

I thought they just threatened to sue, but didn't when the project met their demands.

Agreed. I've been using FreeBSD off and on since 2.2.2. Despite some really eye watering bugs with Ubuntu (especially their ec2 instances), FreeBSD is just more tedious and more frustrating to use. But... FreeBSD has the one killer feature for me: ZFS. It's portable in a pinch and ensure a decent amount of data integrity. Hammer, BTRFS, etc don't offer that kind of flexibility.

For the upgrade from 7.x to 8.x I used "freebsd-update". I forgot to disable the cron task, so after falling asleep the machine proceeded to lunch itself. Fine. User error. Again I tried "freebsd-update" to apply security patches. Guess what? "freebsd-update" doesn't handle new files gracefully, and again it lunched itself. Sure, there was an easy fix (download the single missing file that threw a wrench into the works), but the maintainer of "freebsd-update" knew of the problem and, as far as I can tell, just ignored it. Too much manual intervention is required to keep a FreeBSD system running compared to Linux.

I decided to tempt fate again with the upgrade from 8.x to 9.x (to see if the much promised support for Intel graphics chips was usable -- lesson learned, despite being in the release notes it's pre-alpha at best). Well, this time "freebsd-update" didn't mess anything up, the new kernel did. Turns out what FreeBSD 9.x and FreeBSD < 9.x consider BSD disk labels are two very separate things. My ZFS pools vanished. All sorts of fun ensued (there's that pesky data integrity thing). While FreeBSD 8.x would recognize the pool, 9.1 both missed and corrupted the ZFS magic bits. UGH.

Then there's the ports system. A clusterfuck if I've ever seen one. I've been using 'portupgrade' to ease some of the pain. And it works. Until it doesn't. It's definitely not particularly compatible with ruby 1.9. It's utterly confused by the versioning on the ruby 1.9 port. Upgrading (as of this week) to the latest version of the "pciids" port breaks "portupgrade" with no clean way to back these things out. When mucking about with all the updated XOrg stuff (see above about trying to get Intel graphics to work) I discovered that if you're not using "portupgrade" it's super easy to install duplicate, conflicting versions of a package with no clean way of backing this out. Compare this to Debian based distros where dpkg -i will neatly handle upgrades without lunching your system. While compiling is something of a pain, there are out of date binary packages that are sorta available. The real pain is just that the ports toolchain sucks rocks.

Oh, and watching trivial bugs languish for years got frustrating too. Ah well.

Care to give an example of conf files being placed illogically in FBSD?

the directory structure is explained here:
http://www5.us.freebsd.org/doc/handbook/dirstructure.html
and every port is required to follow that structure.

He may be referring to Apache HTTP Server 2.4.x, discussion concerning what he's referring to can be found on forums.freebsd.org - http://forums.freebsd.org/showthread.php?t=34310

... of course, at the end of the day he can always compile from source or follow blog postings which provide a considerable amount of detail to complete this simple task. We've compiled from source many of our applications so we can customize the compiled experience to a finer degree. I may have made some ports contributions along the way as well.

http://www.freebsd.org/donations/

Great start! The home page has a Donate link at the top, it takes you to a clear, simple URL.

Then it all falls apart...

95% of the page is about everything other then cash donations. The simple PayPal Donate button? No where to be found. The Network For Good Donate link? Again, AWOL. In fact there is only one small paragraph buried 2/3rds of the way down the page about cash donations...and it just tells you to visit the FreeBSD Foundation page. Even worse, it doesn't link you to the Foundation's Donation page...it links you to the home page where you again, need to dig down and find the real donations page.

Stick the PayPal Donate box (found here) on the top of the main FreeBSD.org page and I guarantee they'll easily quadruple their donations without doing anything else whatsoever.

I love, love, LOVE FreeBSD, but yah...they've never been particularly good at tooting their own horn. :-/

That's how it works - more or less - in the PC space

Exactly. If I want to run Microsoft Office on FreeBSD on the new MacBookPro, it's hassle free. Everything just works.

Actually, I believe you're trolling. The bit you quoted from was not claiming that it was "hassle free" nor that "everything just works". It was merely claiming that it is possible to do it. And given your example, I'd say it is possible to do just that:

"On FreeBSD/i386 8.0 and later Wine should work for most user applications including Microsoft Office 2007" http://wiki.freebsd.org/Wine

So let's compare the PC space to the phone/tablet space again...

Can Microsoft make Office for Mac and sell it on their own website? sure, no doubt they already do.

Can Microsoft make Office for iOS and sell it on their own website? well, they could, but no one would be able to install it.

Can Microsoft make Office for Android and sell it on their own website? sure, no problem, so long as the customer's Android build supports side-loading (which it will unless the software provider specifically disabled it).

There is no conspiracy theory in my statement. There is a hinted conspiracy theory in the OP's statement, but I do not share that sentiment in the least.

I already stated what could have been announced (to mailing lists, RSS feed, Twitter, and the forums) on the 11th that was appropriate:

"We've shut off the SVN-to-CVS gateway for an investigative matter; you won't see ports/src/etc. updates until we turn it back on. We've also shut off the portsnap master. csup/cvsup, portsnap, freebsd-update, native CVS, and GNATS are all impacted. We'll provide more detail when we have it, rest assured."

The outage duration is only a problem when nothing official was stated anywhere and the community was being kept in the dark. The fact that nothing official was stated about said services being taken down (i.e. what was going on), and what *was* stated by key FreeBSD Project members was in response to user inquiries (vs. something official, i.e. an announcement) was either flat out wrong or vague as hell, is something that needs to be addressed for the future (see very last paragraph for a mirrored opinion). I can provide references to every one of those Project members' statements if you want to review them.

Rephrased: users had no idea why commits weren't being picked up by csup/cvsup or by portsnap, and at least one user was frightened to find the freebsd-update servers were completely unreachable.

The concern items I presented are factual and based on what actually transpired. Please cease the "what if" and "predictive" straw man arguments.

There is no conspiracy theory in my statement. There is a hinted conspiracy theory in the OP's statement, but I do not share that sentiment in the least.

I already stated what could have been announced (to mailing lists, RSS feed, Twitter, and the forums) on the 11th that was appropriate:

"We've shut off the SVN-to-CVS gateway for an investigative matter; you won't see ports/src/etc. updates until we turn it back on. We've also shut off the portsnap master. csup/cvsup, portsnap, freebsd-update, native CVS, and GNATS are all impacted. We'll provide more detail when we have it, rest assured."

The outage duration is only a problem when nothing official was stated anywhere and the community was being kept in the dark. The fact that nothing official was stated about said services being taken down (i.e. what was going on), and what *was* stated by key FreeBSD Project members was in response to user inquiries (vs. something official, i.e. an announcement) was either flat out wrong or vague as hell, is something that needs to be addressed for the future (see very last paragraph for a mirrored opinion). I can provide references to every one of those Project members' statements if you want to review them.

Rephrased: users had no idea why commits weren't being picked up by csup/cvsup or by portsnap, and at least one user was frightened to find the freebsd-update servers were completely unreachable.

The concern items I presented are factual and based on what actually transpired. Please cease the "what if" and "predictive" straw man arguments.

This was already submitted two days ago.
New article link merely references the material already posted by freebsd on Nov 17th.

(or god forbid OS X)

http://www.freebsd.org/

The portion of OSX they'd want to use is free.

http://www.freebsd.org/cgi/man.cgi?query=svr4&sektion=4

Might work, experiment at your own risk. If it does work, your options have become much greater.

Aren't Juniper's OS BSD based?

Yes, Juniper runs a FreeBSD kernel, but that's about the only similarity. You certainly don't have a full-fledged computer, or a working userland you can access. You get the kernel booting-up their proprietary CLI interface, with their own configuration and command syntax. In fact Cisco's IOS was based on BSD as well, back in the day, but it's diverged substantially at this point, as Juniper's OS probably will if they survive for as many decades as Cisco has.

All BSDs, from what I understand, use PF, and so even if an OS uses something like FreeBSD or NetBSD instead of OpenBSD as its base, whatever it used for the IP filtering would be based on PF, wouldn't it? Or are there IPTables versions on BSD as well?

http://www.freebsd.org/doc/handbook/firewalls.html

The FreeBSD firewall used-to be IPFW, and I assume that's still more-or-less the default option. You can see IPTABLES is there, as is PF.

PF is an option on FreeBSD, but it tends to be either missing a few features, or otherwise just lagging behind what's available on OpenBSD, where it is developed.

Also, how is OpenBSD better than other FreeBSD based distros,

Honestly, I don't care... With OpenBSD versus Cisco ASAs / Netscreens, or Linux firewalls, or low-end ARM-based "routers", there was a huge gap between the options that I tried to explain. But comparing OpenBSD vs FreeBSD, you're really splitting hairs. And in the end, it doesn't matter, because the corporate world will continue to insist on using expensive trash like ASAs which has been severely hobbled to fit Cisco's traditional model. Some day I'm sure I'll see it come crashing down, like every other industry that lived on arbitrary restrictions. I'd be perfectly happy using PF (or even the ancient IPF) on FreeBSD or OpenBSD or even PF on Linux if it ever gets fully (sup-)ported, to avoid more hours on proprietary crippled hardware devices. But if given the choice between an ASA and a Linux system running IPTables, I'd struggle with it, and probably shoot myself at the depressing prospect of working with either one for serious work...

See style(9). Kernel code is expected to follow this format; whether the programmer likes it or not has no bearing. The same is not actively enforced for userland programs and their source, but is highly encouraged.

As an author of a 3rd-party FreeBSD program, I chose to follow this document as well, just to keep everything consistent.

Makefiles have similar requirements; see style.Makefile(5).

See style(9). Kernel code is expected to follow this format; whether the programmer likes it or not has no bearing. The same is not actively enforced for userland programs and their source, but is highly encouraged.

As an author of a 3rd-party FreeBSD program, I chose to follow this document as well, just to keep everything consistent.

Makefiles have similar requirements; see style.Makefile(5).

The most secure modern operating systems you can get are OpenBSD or FreeBSD. They are based on stable mature open source, and don't have the bloat and featureitus problems of Linux.

--libman

FreeBSD 9.0 was dedicated to Dennis Ritchie.

It looks to me like most the problems they are solving have already been solved. There are already several open source log-structured file systems. This list excludes experimental and similar software from educational institutions:
      - Yaffs - http://www.yaffs.net/ - designed from the ground up for NAND
      - JFFS2 - http://sourceware.org/jffs2/jffs2-html/jffs2-html.html - ditto.
      - NANDFS - http://wiki.freebsd.org/NAND - BSD style licence

Plus there's Ext4 - which is used in Android now - not designed for NAND, but seems to work ok.

This work by Samsung fixes the problems with their previous file system. It's good, but it's not unique. Good PR though.

There's a lot of reasons to switch distros. Everyone usually finds one that fits their way of thinking after two or three. People also find that the different distros work better at different tasks - you don't (generally) use Ubuntu for servers, for instance.

As far as what I run on "my" computer, it hasn't changed much: Slackware -> Debian unstable. I knew Slackware inside and out (back in the 3.x days) and now I know Debian very well (you have to, if you run unstable). I've hit a comfort zone, and I'm unlikely to change.

I switched from Slackware to Debian because Slackware was very, very far behind on switching from the libc5 C library to glibc (the second major change in Linux, the first being the switch to ELF executable format). A lot of software was being written that didn't work with the old libc5, and Pat (the maintainer of Slackware) was being stubborn on the point. He had his reasons, but I wanted new software, so I switched.

I tried Corel Linux back when it came out. That lasted about two days. It didn't live up to its promises, and when I found myself replacing the Corel repositories with Debian repositories, I knew it was in vain (BTW, doing apt-get update && apt-get upgrade from Corel to Debian is... interesting. It worked, after a lot of fixing, but I finally wiped and reinstalled Debian). It's just as well - there was only the one version of Corel Linux.

I've had to use Red Hat (not Enterprise, but old school Red Hat Linux) on a few occasions for work-related reasons. This was back in the RPM dependency hell days, and it turned me off of any distro that doesn't maintain a decently large package repository. I used Fedora Core 4 and found it to be just as bad. Same goes for Mandrake (before they became Mandriva - I had friends who ran that because it was "user friendly" - I did not find it so. It might be better now, of course.

I've used Gentoo for shits and giggles on a server I run. I was just curious about it. I've since replaced it with OpenBSD because a) I didn't have the time to learn to admin it properly and b) compiling every package in the system on an Intel Atom chip is painful. (I already knew how to admin OpenBSD.) I liked Gentoo and if I ever replaced Debian as my main distro, it would be to go to Gentoo. I just don't have the time to learn a new system anymore.

I've done LFS. I highly recommend it to anyone who wants to learn more about the underpinnings of Linux. It reminded me a lot of my Slackware days, back when you had to compile everything.

Ubuntu works, and I've run it on a few machines, but doesn't fit into my way of doing things. I like to customize my system a lot, and I like to log in as root when I'm doing admin stuff. You can do that with Ubuntu, but it's just easier with Debian.

Of course, there's the BSDs and Solaris as well, and these days I mostly do server stuff on OpenBSD (or FreeBSD if it's a fileserver). The BSDs make excellent servers and don't feel as "hacked together" as Linux does. I wouldn't use one as my main system, but if I had a technical job again I wouldn't mind a FreeBSD desktop.

So the rite of passage isn't to find the most obscure distro, but to find the distro that suits both you and your use case best. Experimentation never hurts, and you can learn a lot from running different distros.

Gee. Isn't life tough. As I remember from eons ago, Windows is AT LEAST as wrenching. If you're REALLY serious about stability, reliability and freedom from bloat a la systemd, udev, plymouth, la de da, and are willing to invest time up front in return for that continuing stability, allow me to suggest trying out FreeBSD or its desktop friendly derivative, PC-BSD. This would require some real dedication to learn the idiosyncracies. Just to clear one thing up, FreeBSD isn't rocket science to install a DE on. I was doing it a decade ago without much trouble. It doesn't hold your hand and automate everything like PC-BSD does, though.

If you mostly just want a linux desktop that doesn't put you through effing with big changes every year to stay supported, you could do what I did. Install Redhat Enterprise 6 or any of its free derivatives (notably CentOS, Scientific Linux, PUIAS Linux). That way you're good to stay on the same major release, fully supported, hardware-and-feature-back-ported, bug-fixed, and security-updated with good old GNOME 2.32 to at least 2017. I'm a little worried about what RHEL 7's default desktop will look like when it rolls out maybe some time during 2014, but I'm very confident you'll just be able to choose Xfce (as you can now in 6), and anyway there's really no need to make the jump from 6 to 7 until 2017.

Linux does just fine without GNOME. Does it work the other way?

Yes

Please see this for FreeBSD: http://forums.freebsd.org/showthread.php?t=25723

The only way out of this is to use an open source operating system where you can do your own code review, and where one guy doesn't have a bottle neck of control.

Yes and no. Open source doesn't guarantee security. For example, BIND had a long history of bugs (many of which involved security) due to poor design prior to version 9. You didn't need a mole or any malicious intent when the software was so full of big holes you could drive your car through them. OpenBSD had an alleged FBI back door in the news a couple years ago that had lain unnoticed for years.

Then again, there are examples of open source uncovering security issues. A quick google search uncovered this old one and this more recent one. By the way, if it sounds like I'm picking on BSD, I was searching for that FBI link. The other stuff just popped up. I know the various BSDs have a reputation for stability and security.

The only way out of this is to use an open source operating system where you can do your own code review, and where one guy doesn't have a bottle neck of control.

Yes and no. Open source doesn't guarantee security. For example, BIND had a long history of bugs (many of which involved security) due to poor design prior to version 9. You didn't need a mole or any malicious intent when the software was so full of big holes you could drive your car through them. OpenBSD had an alleged FBI back door in the news a couple years ago that had lain unnoticed for years.

Then again, there are examples of open source uncovering security issues. A quick google search uncovered this old one and this more recent one. By the way, if it sounds like I'm picking on BSD, I was searching for that FBI link. The other stuff just popped up. I know the various BSDs have a reputation for stability and security.

Mplayer is not available for BSD.

Since when?

http://www.freebsd.org/cgi/url.cgi?ports/multimedia/mplayer/pkg-descr

Clarification on the FreeBSD inclusion:

A quick review of the related FreeBSD advisory(*) reveals that FreeBSD is only vulnerable to this if one has mis-matched the install-version of the OS to the hardware. Installing either the amd64 version on AMD hardware, or the i386 version on Intel hardware is fine. The risk comes from installing the AMD version on Intel hardware.

Arguably, not a lot of people who'd install FreeBSD in the first place would go with that seemingly obvious mismatch.

(*) http://security.freebsd.org/advisories/FreeBSD-SA-12:04.sysret.asc

I found it strange that an aim in the roadmap was to support the latest GNU binutils [1].. I hope they are trying to adress that piece of GNU dependency too. There is the FreeBSD-project libelf/elftoolchain [2, 3] that could be interesting... [1] https://www.bitrig.org/index.php?title=Roadmap [2] http://wiki.freebsd.org/LibElf [3] http://sourceforge.net/apps/trac/elftoolchain/

It seems that everyone would agree with you. This is a post made to the freebsd-security mailing list today. The new default for FreeBSD is now SHA512.

Yes, according to CVS/SVN logs here FreeBSD has had support for blowfish password hashes for 11 years and 2 months. Don't you love dispelling anti-FreeBSD FUD?

"The default algorithm for storing password hashes in /etc/shadow is MD5. RHEL / CentOS / FreeBSD user can migrate to SHA-512 hashing algorithms."

FreeBSD has long (like, 10+ years) had support for Blowfish password hashes. Blowfish was a close second in the AES contest, and is quite strong. Enabling it only requires editing /etc/login.conf and afterwards updating any pre-existing passwords.

All these posts and no-one has mentioned it runs on FreeBSD?

Netflix's New Peering Appliance Uses FreeBSD

Maybe, but I'm sure there are hardcore people out there who would break even the lax license of FreeBSD. Surely someone is on their team to give the legal equivalent of "lol GTFO" when a user decides to e.g. offer it stripped of the copyright notice or try to claim a nonexistent warranty.

Try this

http://www.freebsd.org/platforms/

Itanium - ia64 is the 4th item in the list. It is, however, not available for OpenBSD or NetBSD - although in NetBSD 6, I recall seeing that a source version of the OS has been introduced, but apparently not compiled and tested.

I guess Itanium users would have to choose b/w FreeBSD and Debian

AFAIK (and I've checked http://www.freebsd.org/where.html) there is no FreeBSD itanium port.

However, FreeBSD will not actively block you from using a newer version of GCC.

Using newer version of GCC and binutils with the FreeBSD Ports Collection

zfs! Works great. Included with FreeBSD 9, amongst other OSs.

You might also enjoy John Siracusa's exhaustive review of filesystems on one of my favorite podcasts.

You can keep an eye on the status here. Oh, and you're meant to say 'I and both other BSD users...'

Putting an @reboot entry in the user's crontab would start anything you want when the machine boots, without the user even logging in.

...and would do so not only on OS X, but on many Linux distributions and FreeBSD and NetBSD and OpenBSD and....

Well, they're about to jail their entire population...

BSD is genuine UNIX. Linux isn't.

BSD is genuinely free software. Linux isn't.

If the binary code of the kernel of one of the *BSD systems showed striking similarities to the binary code of Linux, then there would most likely already have been lawsuits between one of the companies selling *BSD support and one of the companies selling Linux support.