Slashdot Mirror

and maybe after it is ported to linux/*bsd and ten years have gone by [...]

Code is available for FreeBSD, and you can even download an ISO installer with all the patches applied. There's also Xcode 3.0 that will have it.

For the foreseeable future, if you want to have this type of debugging on your server then the server has to run Solaris

checkout http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/1 02765. it is a patched version of the pvr250 cards for pvr150/500 cards. i am running mythtv 0.18-fixes on FreeBSD 4.11 using two pvr500 cards in one box ( 4 tuners ). i have clients on freebsd and on xebian/xbox

One of the LCD-screen iMacs is definitely a good idea. Ideally some extra RAM and a copy of Tiger (Mac OS X 10.4) put on it make for great computing. Otherwise, throw an open source OS such as FreeBSD or Linux on there.

Gnome drags an absurd number of dependencies into the distributions I use. It seems like you can't load Gnome without also loading several development libraries, a panoply of sound and video support (for hardware you don't physically have and software you have no desire to use) and various other fooferaw. I realize some of this is because of inept packaging on the part of certain distributions, but even when you take that into account Gnome's still a dependency nightmare reminiscient of Windows "DLL hell".

When the number of dependencies required to run Gnome on mainstream distributions DECREASES, that'll impress me. Until then I am unlikely to care what new eye-candy it's sporting.

The kernel's VM paging algorithms are tuned to perform best when there is at least 2x swap versus main memory. Configuring too little swap can lead to inefficiencies in the VM page scanning code as well as create issues later on if you add more memory to your machine.

Disk is always far cheaper and more plentiful than memory. If you have four gigs of memory, what's wrong with carving eight gigs of swap out of your terrabyte RAID? If you have that much memory in the first place, then you're probably running large apps. Do you and them a favor and give them a little breathing room.

I've been using these personal firewalls for years without a single occurance of malware or rooting. See for yourself, they run on a variety of architecture. They can be found here and here.

A couple of others that are nearly as good (in my personal experience) are here and here. .

Give them a try. You'll be impressed with the increased security.

Can you help someone out by pointing me towards a link to a good site that show's how to set something like that up? I've got a bit of experience with linux and solaris, but mostly use windows. I don't have any experience using BSD ...

I'll offer a suggestion. Install FreeBSD on any old computer with two NICs. You'll find the installation as easy as any Linux system, the routine maintenance probably easier, and the documentation far superiour.

Sit down to read the pf FAQ on OpenBSD's site. It's well written and comprehensive so read from the first page to the last page. Make some coffee and then read it again.

# cd /usr/ports/shells/bash && make install
# echo 'pf_enable="YES"' >> /etc/rc.conf
# echo 'pf_rules="/etc/pf.conf"' >> etc/rc.conf

Edit /etc/pf.conf using the home user scenario provided at the end of the 'pf FAQ'. Reboot and you're good to go.

You'll find pf far less verbose than iptables, ipfw, etc., and easier to learn and to use for that reason among others. There's also lots of additional tools available for pf that will help as well.

$ cd /usr/ports && make search name=pf | less

Google for all the rest.

A final comment. Using this approach gives you a secure firewall with all the unixy goodness you'd expect, not to mention logging, SSH, NTP synchronisation, etc that you may want to use as well. And earning the right to sneer at everyone using those plastic Linksys NAT boxes doesn't hurt.

It took 10 days for FreeBSD hacker to port ZFS to FBSD. The result is available here.

Conceptually, I agree that LaunchD is a really slick idea and I really hope Linux and the BSDs take a good hard look at this code and the possibility of adopting it.

It looks like somebody is working on it for FreeBSD.

Done't know about this PC-BSD flavor of FreeBSD, but FreeBSD+Oracle has been done at version 5.x and before with Oracle 9i and before; http://ezine.daemonnews.org/200402/oracle.html http://www.scc.nl/~marcel/howto-oracle.html http://www.freebsd.org/cgi/getmsg.cgi?fetch=2143+6 531+/usr/local/www/db/text/2003/freebsd-database/2 0030309.freebsd-database I'd like to hear about Oracle 10g on FreeBSD or PC-BSD, any versions of the OS

My Linksys WRT54G (not GS) is a transparent Squid proxy already. I don't see why this ASUS machine can't do the same.

It points to a secondary FreeBSD machine for that, because I have a 5GiB cache on the Squid side. Everything is anonymized through Privoxy + Tor, with no configuration changes on the client side.

Users don't even know (or care) that their traffic is being proxied or anonymized at all.

For user data stored on the FreeBSD machine, I also use rsnapshot to do backups of another disk slice that is GELI encrypted as well, which works out very nicely for the overall solution.

Everything that goes out port 80 (or comes back in on the response) through the Linksys is redirected through the Squid server on the FreeBSD machine. iptables(1) on the Linksys does all the magic for me, as follows:

iptables -t nat -A PREROUTING -i br0 -s ! 10.0.1.6 -p tcp --dport 80 -j DNAT --to 10.0.1.6:3128
iptables -t nat -A POSTROUTING -o br0 -s 10.0.1.0/24 -d 10.0.1.6 -j SNAT --to 10.0.1.2
iptables -A FORWARD -s 10.0.1.0/24 -d 10.0.1.6 -i br0 -o br0 -p tcp --dport 3128 -j ACCEPT

There's more to it, but that should get you started. Its really easy to implement, and I'd trust my FreeBSD machine to process those packets faster than the processor on the Linksys ever could (not even considering the storage requirements for such a caching mechanism).

The Squid cache on the FreeBSD side resides on a partition that is GELI encrypted. Do I have anything to hide? No, but I do have a right to protect the identity of my users, their browsing habits and their data.

Everyone else should do the same (or similar).

My Linksys WRT54G (not GS) is a transparent Squid proxy already. I don't see why this ASUS machine can't do the same.

It points to a secondary FreeBSD machine for that, because I have a 5GiB cache on the Squid side. Everything is anonymized through Privoxy + Tor, with no configuration changes on the client side.

Users don't even know (or care) that their traffic is being proxied or anonymized at all.

For user data stored on the FreeBSD machine, I also use rsnapshot to do backups of another disk slice that is GELI encrypted as well, which works out very nicely for the overall solution.

Everything that goes out port 80 (or comes back in on the response) through the Linksys is redirected through the Squid server on the FreeBSD machine. iptables(1) on the Linksys does all the magic for me, as follows:

iptables -t nat -A PREROUTING -i br0 -s ! 10.0.1.6 -p tcp --dport 80 -j DNAT --to 10.0.1.6:3128
iptables -t nat -A POSTROUTING -o br0 -s 10.0.1.0/24 -d 10.0.1.6 -j SNAT --to 10.0.1.2
iptables -A FORWARD -s 10.0.1.0/24 -d 10.0.1.6 -i br0 -o br0 -p tcp --dport 3128 -j ACCEPT

There's more to it, but that should get you started. Its really easy to implement, and I'd trust my FreeBSD machine to process those packets faster than the processor on the Linksys ever could (not even considering the storage requirements for such a caching mechanism).

The Squid cache on the FreeBSD side resides on a partition that is GELI encrypted. Do I have anything to hide? No, but I do have a right to protect the identity of my users, their browsing habits and their data.

Everyone else should do the same (or similar).

My Linksys WRT54G (not GS) is a transparent Squid proxy already. I don't see why this ASUS machine can't do the same.

It points to a secondary FreeBSD machine for that, because I have a 5GiB cache on the Squid side. Everything is anonymized through Privoxy + Tor, with no configuration changes on the client side.

Users don't even know (or care) that their traffic is being proxied or anonymized at all.

For user data stored on the FreeBSD machine, I also use rsnapshot to do backups of another disk slice that is GELI encrypted as well, which works out very nicely for the overall solution.

Everything that goes out port 80 (or comes back in on the response) through the Linksys is redirected through the Squid server on the FreeBSD machine. iptables(1) on the Linksys does all the magic for me, as follows:

iptables -t nat -A PREROUTING -i br0 -s ! 10.0.1.6 -p tcp --dport 80 -j DNAT --to 10.0.1.6:3128
iptables -t nat -A POSTROUTING -o br0 -s 10.0.1.0/24 -d 10.0.1.6 -j SNAT --to 10.0.1.2
iptables -A FORWARD -s 10.0.1.0/24 -d 10.0.1.6 -i br0 -o br0 -p tcp --dport 3128 -j ACCEPT

There's more to it, but that should get you started. Its really easy to implement, and I'd trust my FreeBSD machine to process those packets faster than the processor on the Linksys ever could (not even considering the storage requirements for such a caching mechanism).

The Squid cache on the FreeBSD side resides on a partition that is GELI encrypted. Do I have anything to hide? No, but I do have a right to protect the identity of my users, their browsing habits and their data.

Everyone else should do the same (or similar).

My Linksys WRT54G (not GS) is a transparent Squid proxy already. I don't see why this ASUS machine can't do the same.

It points to a secondary FreeBSD machine for that, because I have a 5GiB cache on the Squid side. Everything is anonymized through Privoxy + Tor, with no configuration changes on the client side.

Users don't even know (or care) that their traffic is being proxied or anonymized at all.

For user data stored on the FreeBSD machine, I also use rsnapshot to do backups of another disk slice that is GELI encrypted as well, which works out very nicely for the overall solution.

Everything that goes out port 80 (or comes back in on the response) through the Linksys is redirected through the Squid server on the FreeBSD machine. iptables(1) on the Linksys does all the magic for me, as follows:

iptables -t nat -A PREROUTING -i br0 -s ! 10.0.1.6 -p tcp --dport 80 -j DNAT --to 10.0.1.6:3128
iptables -t nat -A POSTROUTING -o br0 -s 10.0.1.0/24 -d 10.0.1.6 -j SNAT --to 10.0.1.2
iptables -A FORWARD -s 10.0.1.0/24 -d 10.0.1.6 -i br0 -o br0 -p tcp --dport 3128 -j ACCEPT

There's more to it, but that should get you started. Its really easy to implement, and I'd trust my FreeBSD machine to process those packets faster than the processor on the Linksys ever could (not even considering the storage requirements for such a caching mechanism).

The Squid cache on the FreeBSD side resides on a partition that is GELI encrypted. Do I have anything to hide? No, but I do have a right to protect the identity of my users, their browsing habits and their data.

Everyone else should do the same (or similar).

My Linksys WRT54G (not GS) is a transparent Squid proxy already. I don't see why this ASUS machine can't do the same.

It points to a secondary FreeBSD machine for that, because I have a 5GiB cache on the Squid side. Everything is anonymized through Privoxy + Tor, with no configuration changes on the client side.

Users don't even know (or care) that their traffic is being proxied or anonymized at all.

For user data stored on the FreeBSD machine, I also use rsnapshot to do backups of another disk slice that is GELI encrypted as well, which works out very nicely for the overall solution.

Everything that goes out port 80 (or comes back in on the response) through the Linksys is redirected through the Squid server on the FreeBSD machine. iptables(1) on the Linksys does all the magic for me, as follows:

iptables -t nat -A PREROUTING -i br0 -s ! 10.0.1.6 -p tcp --dport 80 -j DNAT --to 10.0.1.6:3128
iptables -t nat -A POSTROUTING -o br0 -s 10.0.1.0/24 -d 10.0.1.6 -j SNAT --to 10.0.1.2
iptables -A FORWARD -s 10.0.1.0/24 -d 10.0.1.6 -i br0 -o br0 -p tcp --dport 3128 -j ACCEPT

There's more to it, but that should get you started. Its really easy to implement, and I'd trust my FreeBSD machine to process those packets faster than the processor on the Linksys ever could (not even considering the storage requirements for such a caching mechanism).

The Squid cache on the FreeBSD side resides on a partition that is GELI encrypted. Do I have anything to hide? No, but I do have a right to protect the identity of my users, their browsing habits and their data.

Everyone else should do the same (or similar).

"A good example is network configuration. On OpenBSD, everything to do with configuring network interfaces is done through ifconfig. On Linux (and, sadly, FreeBSD) you have a separate utility to control WiFi settings."

Uh... last time I checked, you could configure all of your wireless setting in FreeBSD through ifconfig. That includes scanning for aps, setting up encryption, authentication, etc. Correct me if I'm wrong

http://www.freebsd.org/cgi/man.cgi?query=ifconfig& sektion=8

Whatever happened to just mashing your fists on the keyboard?

FreeBSD still does this (at least it lets you). In fact, it gives you an opportunity on first boot to hammer away to kick-start the entropy before it generates RSA key pairs.

There are some amazing compression programs out there, trouble is they tend to take a while and consume lots of memory. PAQ gives some impressive results, but the latest benchmark figures are regularly improving. Let's not forget that compression is not good unless it is integrated into a usable tool. 7-zip seems to be the new archiver on the block at the moment. A closely related, but different, set of tools are the archivers, of which there are lots with many older formats still not supported by open source tools

Amigo, I was using 5.2 Release, 5.3 Release, and 5.4 Release. Is that what you call "early adoption"?

In part, yes. 5.2-RELEASE was cut from the development branch (as were 5.0, 5.1 and 5.2.1). The release announcement mentions that it is "a 'New Technology' release and might not be suitable for all users", and includes a link to the Early Adopter's Guide.

FreeBSD 5 only became "mainstream" with 5.3-RELEASE - and still had some rough edges. For anyone who's only experience has been with FreeBSD 5.X releases then I can sympathise if they have come away with a less than rosy view. The amount of development and change that went on between 4.X and 5.X is now widely accepted to have been a bad idea. If you give 6.2 a spin when it comes out then you might be pleasently suprised. A lot of the disruptive changes introduced during 5-CURRENT development have finally settled down and are paying dividends.

Yes, there is. http://ezine.daemonnews.org/200302/fbsdscratch.htm l

First and foremost, read the handbook. This cannot be overstated. http://www1.uk.freebsd.org/doc/en_US.ISO8859-1/boo ks/handbook/

Bear in mind that, for a Linux user, FreeBSD will appear to behave most like Gentoo, particularly when building applications from ports. The actual inheritance was the other way around, but that hardly matters to this discussion.

The kernel config file is flat text, with the various options described in detail in the ${SRC}/sys/conf/NOTES and ${SRC}/sys/${ARCH}/NOTES files. Once you get used to it, nothing ever comes close to the ease of compiling new kernels IMHO. Just watch what depends on what, especially the COMPAT_??? options. Also, try not to use "custom" compiler flags like -ffast-math and -funroll-loops as you can end up with hard to diagnose problems when building from source.

Oh, and for anyone reading this thread who is saying "I only have one dsp device that gets locked and nothing else can use it," there is a sysctl knob which needs setting: hw.snd.pcm?.vchans which I usually set to 4 in /etc/sysctl.conf.

There's a lot of help to be had on the Usenet group comp.unix.bsd.freebsd.misc, too.

My last word on the subject is this: If you have an amd64 machine, for now I would use the i386 port (CPUTYPE=athlon64 in /etc/make.conf which will compile everything with -march=athlon-mp), especially if you use Firefox or you may end up rather frustrated. OpenOffice now works perfectly on amd64, as does JDK15 (albeit without the browser plugin) but native Firefox still has "issues" (startup hangs on a machine with an NFS mounted /home, hard locks, crashes to name but a few problems I have encountered) and plugins are rather flaky. I tend to use the 32bit Linux version on amd64, but the native i386 version has the most plugins available for it (win32codecs, Flash - you need a patch to make Flash7 work with the linuxpluginwrapper and native Firefox, see the message displayed when you install the port - et al). Also, there are no proprietary nVidia drivers for amd64 yet, which is not true for i386. This is being addressed in -CURRENT as nVidia have intimated that a key function they require is not present in the amd64 port and the devs are working on it, so the situation is set to change in the near future.

By the way, ports count at present is ~15500. That's 15.5 thousand services, applications, libraries and utilities available for the cost of typing "make install clean".

Yes, because Linux == KHTML. That's all Linux is. And KDE doesn't run on any other platform but Linux. Those stupid Mac users, how can they hate Linux when the rendering engine of one of the browsers for their OS is Linux!

(Here's a small sampling of platforms that KDE either runs on or is being ported to.)

Simple, stay away from micro$hit. Download a true operating system here or here rather than an purchasing and using and inoperable system such as winblow$.

Solaris containers are slightly upgraded BSD jails, which are essentially a extension to chroot.

BSD has had them for a long time. I know that some linux distributions can do jails as well. For example, SLES 9 does jails. Sun's containers are essentially BSD jails plus some additional namespace splitting and a really great marketing push. I used to use a hosting company that used BSD jails to separate their virtual servers on shared systems back in 2000 or so.

More about jails:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/a rch-handbook/jail.html

At first I was just thinking to myself that: "I'm glad this guy is just a pundit and in no position to do anything about implementing such a cruel device of torture."

But, then he had to mention 'the monopoly' and suddenly things seemed plausible. Not a nice thought.

The thought has passed in that I need not concern myself with such matters since I have both FreeBSD and GNU/Linux experience (with Solaris 10 soon to follow).

No known significant bugs exist at this time, but there are no guarantees of usability

The tar file format, like most unix things has undergone several revisions and branches. In POSIX.1, a new format, called the Pax Interchange Format, was created as a backwards compatible extention of the tar format, that allowed for storing of arbitrary metadata. How this metadata is used is naturally left up to the system's implementation of tar and pax. I don't know how widely these extentions are used. I know that in Mac OS 10.4, metadata including resource forks are supported, but I think they implemented them using thier normal flat-file hacks (._myfile holds metadata for myfile), and not the pax extentions. This man file has a little more information.

I do find ATIs lack of Linux support to be disappointing now however, because those of us interested on running Linux on an intel mac...

Hmmm...doesn't OS X run the FreeBSD userland? I wonder if it is not so different that you might be able to get FreeBSD's Linux Compatibility working. I suppose it is kernel based, but if OS X's kernel can run a FreeBSD userland, then why not Linux Compatibility too? At the very least, the idea should carry across. Maybe there is some project out there which ported it to or does the same thing on the Mac? I'm sure a lot of people would be interested in such a thing...

Not necessarily the same thing, but I found a program called Q emulator which may do what you want...it also emulates the 80x86 processor though, so it may be slow.

On what operating system? With FreeBSD'sSMPng project, they've made most of the network stack (from my understanding) SMP safe, and the kernel now supports pushing multiple threads across multiple CPUs (like Solaris, Xnu, and Linux)

it's easy for threads to eat monstrous amounts of resource

Don't you mean forked processes? The advantage of threads is that they're lightweight and use shared memory (dead locks hoorah!), forked processes are heavy because they need their own memory, etc.

A new icon! Seriously, it's just a big, red zero, er.. "O".

If FreeBSD can get a new spiffy logo, so can Opera. ;)

Here's a better article on removing WGA. :)

(I actually prefer this article on removing WGA, or this one, but I freely admit that they're not for newbies.) ;)

> Can you imagine what the software landscape would look like today without the GPL

sure :

http://www.freebsd.org/

You should encrypt it before sending it out to the service provider. This way you don't care, what method THEY are using. In fact, you'd rather they used none at all.

Personally, I am happy with CCrypt, which is a secure replacement for the simple-minded Unix crypt(1) utility. The FreeBSD port makes installing a breeze, as usual.

Ok, this might be a different bug; but FreeBSD fixed a remote kernel code execution bug which affected systems scanning for existing 802.11 wireless networks. The bug was discovered and reported to the FreeBSD Security Team by Karl Janmar.

Security researchers have found a way to seize control of a laptop computer by manipulating buggy code in the system's wireless device driver

Whether this is a new bug or not, it's certainly not a new type of bug.

Have you tried it on a laptop recently? That article is fairly old (only covering up to FreeBSD 5.1). I would suggest you review the changelogs for recent versions, as support has increased with every version...

I've always found support for hardware in FreeBSD to be far more painless than in Linux, and has supported almost everything I've thrown at it, including laptops, except cutting-edge consumer-grade hardware (i.e. maybe the sound on a brand-new Dell Dimension might not work).

Have you tried it on a laptop recently? That article is fairly old (only covering up to FreeBSD 5.1). I would suggest you review the changelogs for recent versions, as support has increased with every version...

I've always found support for hardware in FreeBSD to be far more painless than in Linux, and has supported almost everything I've thrown at it, including laptops, except cutting-edge consumer-grade hardware (i.e. maybe the sound on a brand-new Dell Dimension might not work).

Have you tried it on a laptop recently? That article is fairly old (only covering up to FreeBSD 5.1). I would suggest you review the changelogs for recent versions, as support has increased with every version...

I've always found support for hardware in FreeBSD to be far more painless than in Linux, and has supported almost everything I've thrown at it, including laptops, except cutting-edge consumer-grade hardware (i.e. maybe the sound on a brand-new Dell Dimension might not work).

Have you tried it on a laptop recently? That article is fairly old (only covering up to FreeBSD 5.1). I would suggest you review the changelogs for recent versions, as support has increased with every version...

I've always found support for hardware in FreeBSD to be far more painless than in Linux, and has supported almost everything I've thrown at it, including laptops, except cutting-edge consumer-grade hardware (i.e. maybe the sound on a brand-new Dell Dimension might not work).

Hello, I don't want to start a flamewar, I think FreeBSD is splendid, but for example it's not well supported on laptops :

from the FreeBSD documentation

4 Power management
Unfortunately, this is not very reliably supported under FreeBSD. If you are lucky, some functions may work reliably; or they may not work at all.

To make things a little more complex, there are two existing standards for power management: APM and ACPI, the latter superseding the former and including more features, but also introducing more problems.

why isn't there a better language than C for creating OSs in? A real macro system and overloading would probably be nice for kernel dev.s everywhere.

Uh, just so you know: code in OpenBSD is frequently ported to other operating systems (including Linux), or is at least used as a reference when creating new driver implementations. It wouldn't surprise me if NetBSD's HiFN were a ported version of the OpenBSD driver (hmm, looks like it). Same for FreeBSD (check here).

I don't know if Linux's HiFN support is based on OpenBSD's code (hell, it's hard to tell if Linux even supports the HiFN chip from here-- are the Crypto API homepages at SourceForge? Kerneli.org? Is the Crypto API even where to look? Bah! Forget about it!). But I'd say it's better than 50-50 that the developers were at least referencing the OpenBSD (as is their right; the OpenBSD code is public and free).

Point is, OpenBSD's driver is being used in at least three operating systems (and has almost certainly been used as a reference for others). FreeBSD, OpenBSD, and NetBSD users-- especially professional users-- constitute quite a chunk of HiFN's target market.

In the Unix System Administration Handbook, Evi Nemeth has this to say about daemons:

        "Many people equate the word ``daemon'' with the word ``demon,'' implying some kind of Satanic connection between UNIX and the underworld. This is an egregious misunderstanding. ``Daemon'' is actually a much older form of ``demon''; daemons have no particular bias towards good or evil, but rather serve to help define a person's character or personality. The ancient Greeks' concept of a ``personal daemon'' was similar to the modern concept of a ``guardian angel'' --- ``eudaemonia'' is the state of being helped or protected by a kindly spirit. As a rule, UNIX systems seem to be infested with both daemons and demons." (p403)

Religious society endorsing devil

Here is a major part of it

http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/network-wireless.html

Like this ?
http://www.freebsd.org/donations/donors.html

Are this kind of girls coming too?

Use FreeBSD and GELI: Disk Encrypting and Swap Encrypting using GELI.

Buy a crypto card from Soekris, like the vpn1401. FreeBSD's crypt framework will autodetect the card and use it. Note that this isn't a controller, and I don't believe it can be used with a RAID setup.

There are a lot of issues to deal with. If your swap isn't encrypted, then you'd might as well not bother if you're messing with a huge document. Also, you should find a way to encrypt your home directory as data could get dropped into temporary files. Encrypt the /tmp directory as well. The /tmp and swap keys can be one-time, but you'll want to use different passphrases for different drives. The problem you'll have is with key management. The theoretical crypto chain these days is sound (dunno about GELI specifically, as it's not been analyzed), but there's always a chance for an implementation error. Even so, you are the weakest link in your crypto chain.

Also remember that you can be compelled to give over your keys by law enforcement (legally). The crypto is so good though that if they want your keys, they'll likely install a key logger instead of bothering with asking you.

Use FreeBSD and GELI: Disk Encrypting and Swap Encrypting using GELI.

Buy a crypto card from Soekris, like the vpn1401. FreeBSD's crypt framework will autodetect the card and use it. Note that this isn't a controller, and I don't believe it can be used with a RAID setup.

There are a lot of issues to deal with. If your swap isn't encrypted, then you'd might as well not bother if you're messing with a huge document. Also, you should find a way to encrypt your home directory as data could get dropped into temporary files. Encrypt the /tmp directory as well. The /tmp and swap keys can be one-time, but you'll want to use different passphrases for different drives. The problem you'll have is with key management. The theoretical crypto chain these days is sound (dunno about GELI specifically, as it's not been analyzed), but there's always a chance for an implementation error. Even so, you are the weakest link in your crypto chain.

Also remember that you can be compelled to give over your keys by law enforcement (legally). The crypto is so good though that if they want your keys, they'll likely install a key logger instead of bothering with asking you.

Use FreeBSD and GELI: Disk Encrypting and Swap Encrypting using GELI.

Buy a crypto card from Soekris, like the vpn1401. FreeBSD's crypt framework will autodetect the card and use it. Note that this isn't a controller, and I don't believe it can be used with a RAID setup.

There are a lot of issues to deal with. If your swap isn't encrypted, then you'd might as well not bother if you're messing with a huge document. Also, you should find a way to encrypt your home directory as data could get dropped into temporary files. Encrypt the /tmp directory as well. The /tmp and swap keys can be one-time, but you'll want to use different passphrases for different drives. The problem you'll have is with key management. The theoretical crypto chain these days is sound (dunno about GELI specifically, as it's not been analyzed), but there's always a chance for an implementation error. Even so, you are the weakest link in your crypto chain.

Also remember that you can be compelled to give over your keys by law enforcement (legally). The crypto is so good though that if they want your keys, they'll likely install a key logger instead of bothering with asking you.

As someone has vaguely mentioned, it is possible to replace Sendmail completely with Postfix or [insert any MTA here]. I've replaced Sendmail with Postfix. Replaced mbox with Maildir+courier-imap, and it all works perfectly!
Read the FreeBSD Handbook. http://www.freebsd.org/doc/en_US.ISO8859-1/books/h andbook/mail-changingmta.html