I’m not great about backups, I’m probably very good at backups compared to most, but not compared to the zfs experts I know. They are an outlier and shouldn't have been counted.

I am confused at why so few machines offer dual NVMe, I guess I understand laptops, but everything has space and power. If one is none then everyone should want their base storage to be a mirror.

Ideally there would be something with the power performance profile of the Mac mini, but with the ability to run the software I want without jumping through infinite hoops. Alas no, I’m stuck with the choice between poorly supported slow SBCs or expensive Intel boxes.

One day early in 2024 while searching Ali express for “dual nvme computer” as you do I found the Morefine M6.

This is a phone sized Intel N200 based SBC, it sports dual NVMe slots, 2.5G wired network, high speed wireless, usb-c for power, usb-c for data and three USB3 ports. This thing is a dream, a tiny machine with mirrorable storage that will run off nothing.

I had an idea for the M6 immediately, it can live on my desktop as a first hop backup target for my laptop. Mirror to the M6 at 2.5Gbit/s and it can then gradually upload to the cloud over the terrible VDSL (we since moved and have symmetric gigabit fiber, greatly reducing upload times, but the idea was still compelling).

The M6 came and I was immediately surprised at the weight of the device. I had thought from the pictures that it was an aluminium body, a metal that would act as a heat sink. Instead the entire case is plastic and there is a tiny fan and heat pipe arrangement to move heat away.

The second impression was the fan noise. This think is incredibly loud, the two pin fan has no way to control speed so it is always going.

The third thing was performance. The M6 arrived just as we closed on our house so I could only do a minimum of testing. I installed FreeBSD to a pair of mirrored usb sticks and started to do performance measurements of the CPU and network and the M6 continually locked up or reset. I never caught what happen, it was just dead.

Rather than debug this I bought and moved into a house a prepared for a child to arrive. Disappointed I couldn't resolve back ups before life got too hectic.

Return to the M6

Some time passes and I return to work after some wonderful parental leave.

I started porting OpenBSD's iwx WiFi driver (via haiku for complete weirdness) to FreeBSD. iwx supports Intel PCIe ax200, ax201, ax210 and ax211 chipsets, this is currently supported by the Linux compat iwlwifi driver on FreeBSD. OpenBSD decided rather than bloating iwm, to add a new driver supporting later chipsets.

I always planned to use PCIe pass through and bhyve for development if it could be possible. When I had a stub driver building I set up an OpenBSD test VM on one of my testbed machines and discovered to much surprise that the PCIe test card I had wasn't supported. I tried in iwlwifi and it also wasn't supported.

I ordered another card, but things seem to come the next day only when they aren't needed and take weeks otherwise.

While waiting I tried the M6 and low and behold I was able to use iwx on OpenBSD in a VM with PCIe pass through without any issue.

The M6 has been my main development target for the iwx port so far with FreeBSD as a hyper visor and FreeBSD as a guest (and sometimes OpenBSD when I need to compare command traces).

The M6 still locks up sometimes, but this has tampered off. I transfer kernels to the guest over Ethernet and saturate the 2.5 Gbit link between my framework laptop and the VM machine for these tiny transfers.

The M6 is limited to 6 cores, but the most strenuous thing it is doing is run iperf. Mostly it sits there sipping power ready for work (and blasting that stupid fan).

Improvements

Via Reddit I've almost found two things which offer improvements. The one I have found is 3D models to replace the back of the case where the NVMe mounts with a 3D printed metal plate to use as a heat sink.

The one I almost have is a model to completely replace the fan side with a heat sink. If the M6 hadn't become so key I wouldn't consider these, but it is also too important now to mess with a lot.

I’m on the road and it is wonderful to be able to take a tiny usb-c powered vm host with me and get useful work done. I can’t wait for more computers in stupid form factors like this.

Oh and the shenanigans I have planned for it when it is no longer my primary development target.

Pictures

As a treat and for hackers here are its insides, the NVMe side is just slots for the NVMe.

10 years after my first visit I’m returning to the Chaos Communication Congress (CCC), run by the Chaos Computer Club (CCC) for some time Chilling Chatting and Cdrinking (CCC).

It’s been a long time since I last attended a congress, it was the final one in Hamburg and a lot has changed since.

Returning to Congress I wanted to make a list of things I could do to make the event more special. I’m definitely more of a “plan to do everything and then do nothing person” when it comes to these events, but as I’m only managing two days and I’m not travelling with a group making and then following a plan might be nice.

• [ ] Attend a workshop
• [ ] Go to a main hall talk
• [ ] Go to a second talk
• [ ] Have deep thoughts in the night club
• [ ] Dance!
• [ ] Dance at a spontaneous party
• [ ] Tee trinken in das Tee Haus
• [ ] Leak some at Whiskey leaks
• [ ] Get all the stickers
• [ ] Pick up some random electronics from a community space
• [ ] Meet old friends
• [ ] Meet new friends
• [ ] Promulgate some Scott’s lingo
• [ ] Investigate a puzzle
• [ ] Hack a thing
• [ ] Drink a tschunk
• [ ] Flora mate
• [ ] Beer…
• [ ] Coffee bike
• [ ] Attend a demo party

You would think “go to a talk/workshop” would be a no brainer and it is for everyone who comes and therefore really difficult to do. A major “no one goes there it’s too busy” situation.

I've already lined up a hardware workshop, it is too exciting to tease if it doesn't work out.

The best thing a happen an hacker events spontaneously, will foregoes planning them, if this is your first congress you should not make too many plans and instead aim to hang out in the spaces for hacker communities. Priorities community sessions, workshops and then talks.

The talks are recorded, the community session will never happen again. To actually join a workshop you’ll need to be hours early to queue, maybe that isn't the best use of the event for you.

I've already plans to see new and old friends, but if you are heading to Congress you could try and track me down (I’m only around days 0-2.5) or maybe and me an email to make things easier.

Pretty quiet week, driver changes normally come as large series and there aren't a lot this week. This week isn't an outlier.

Goings on

BSD Devroom at FOSDEM 2024

The schedule for the FOSDEM is online . The BSD Devroom is only a half day with the following sessions:

• How FreeBSD security audits have improved our security culture
• Wake up, FreeBSD! Implementing Modern Standby with S0ix
• Tracking bulk builds in pkgsrc - from Cloud to NetBSD Native
• High Performance Packet filtering in BSD. A holistic review
• A packet's journey through pf
• Making NetBSD as a fast(er) booting microvm
• Writing about FreeBSD
• FreeBSD audit source and other syslog-ng news

I will be talking about writing about FreeBSD, which means right now I am writing about talking about writing. I'm going to cover avenues in, how and where to publish stuff and the process and idea behind this series of reports.

Network Stack

Swap a tab for a space so in6_ifaddr can be grepped for.

• a6a0b8d50e87 in6_var.h: make struct in6_ifaddr declaration searchable with grep(1)

ICMP responses are rate limited, but there might be issues if an attacker could discover the rate limit so a jitter value is applied to the rate limit. This improves the description:

• eba715c544ea icmp.4: improve icmplim and add icmplim_jitter description

Netdev

More progress in cxgbe to make TLS offload available by default.

• 70693a45381b cxgbe tom: Restore support for zerocopy TCP receive for aio_read()
• 34fbc9e421e7 cxgbetool.8: Consistently use .Cm for loader tunables
• 906521882324 cxgbe: Tidy TOE tunables under hw.cxgbe
• 8b1788118a1a cxgbe tom: Enable TLS offload support by default
• 45d5b9f0324a cxgbe/t4_tom: Plug an stid leak.

Tidy up a module ordering issue that leads to a hang during module load for iwlwifi.

• 87e140a5c6f8 iwlwifi: avoid (hard) hang on loading module

API improvements in net80211.

• 30e8252353d9 net80211: HT: check for feature support in ht_recv_action_ht_txchwidth()
• 8437d7d6a4d6 net80211: HT: add missing bit descriptions for IEEE80211_AGGR_BITS
• ca389486a959 net80211 / LinuxKPI 802.11: use enum ieee80211_sta_rx_bw for ni_chw

Lot of updates to rtwn moving towards HT (80211n) and VHT (80211ac), adrian@ is talking about doing 50Mbit right now from rtwn which is great progress.

• 977679d651de rtwn: remove unused rate configuration code for management traffic.
• f6f03d156ba7 rtwn: add VHT awareness to rtwn_chan2centieee()
• b811e5a5effe rtwn: program the 1 and 2 stream VHT transmit power rates
• b4980d8a48e5 rtwn: calculate the transmit power for VHT rates
• 468cd606239e rtwn: refactor out the rtl8812/rtl8821 tx power programming
• 3d69926189f5 rtwn: expand the ridx numbers to include VHT; add accessor macros
• c3c2f0ddd818 rtwn: add missing iv_ampdu_limit
• b59017c5cad9 rtwn: add placeholder for the per-MACID rate report
• b2b6c2236b9c rtwn: enable HT40 for RTL8821/RTL8812 series NICs
• 351356090998 rtwn: use ieee80211_ht_check_tx_ht40() to transmit HT40 frames

Firewalls

Add a new flag to pfctl to only reset counters for table entries which items logged against them. This preserves the zeroed timestamp on entires with nothing logged.

• 5b59b0c61e29 pfctl: add -T reset to touch pfras_tzero only for non-zero entries

Catch a state tracking issue after the TCP_AE introductions in the last few weeks in ipfw.

• 9ea8d692f4cb ipfw: use only needed TCP flags for state tracking

Tidying in netlink.

• 33c670c373c0 netlink.h: Align macro declarations with tabs
• 5143d8c4434c netlink: Use __align_up() instead of homegrown roundup2 macro
• 9df901c8f8c8 netlink: Pop NLMSG_ALIGNTO and NLMSG_ALIGN out of the #ifndef _KERNEL block
• c7919fb92d20 netlink: Do not cast to int in NLMSG_HDRLEN and _NLMSG_LEN

User Tooling

Add option to allow setting of mount port number for nfs.

• 0e8a36a2ab12 mount_nfs.c: Add an NFS mount option to set a port# for Mount

Other stuff

• 35623ccc3758 release: Standardize on *-${FS}.* VM image naming
• 6dafe8c1e46e Clean pkg cache in release media

Please Send Feedback

This is the 12th Network status report and the final one for 2024.I have enjoyed writing these and plan to pick them up again in the New Year.

I would love to know if this summary was any help, if it was, or if you think I should cover other thing please let me know (thj@freebsd.org).

If you find a typo or have a correct let me know and I'll thank you at the end here.

You can see all prior posts here. ( rss )

My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .

Goings on

BSD Devroom at FOSDEM 2024

The CFP for the BSD Devroom at FOSDEM closed over the weekend, submitters have been told to expect responses on the 15th of December. I'll provide a run down of upcomming talks in the first status update of 2025.

FreeBSD 14.2 was released

Congratulations to everyone involved and a big thanks to the RE team for getting FreeBSD 14.2 out. The release notes are here

CFT for rtwn, ath and iwn

hi!

I've been working on some net80211 clean-ups and rtwn bugfixes in
preparation for getting the 11ac support for rtwn landed into the tree.

If you're using rtwn, ath or iwn then the latest stuff I've done in -HEAD
may affect you. Please update to the latest -HEAD and let me know if
anything has regressed! (or if it still works fine, that'd be nice to know
too!)

thanks,

-adrian

adrian@ posted a cft for users of rtwn, ath and iwn after recent CURRENT changes

Network Stack

Lots of tidying in netlink.

• 29f6150256c2 netlink: use nitems() and roundup(2) from param.h
• fe048349c63c netlink: use proper argument types in genl_register_family()
• 6380058fe5b5 netlink: use correct uint16_t type for attribute type & length
• f1c6edba885f netlink: use size_t through the allocation KPI
• 0601c0f989f2 netlink: check buffer length fits into u_int
• a034c0aeccd8 netlink: refactor writer initialization KPI
• edf5608bfef3 netlink: use bitset(9)
• ac84ce05c121 netlink: consistently use uint16_t for family id

Tidying in in6_pcbbind . This is a very difficult part of the network stack to work in and tidying here makes things much easier.

• 01f8ce83242d inpcb: Factor out parts of in6_pcbbind() and in_pcbbind_setup()
• ffb3d384fc1d inpcb: Fix the GENERIC-NODEBUG build

Transport

Tidy ups in tcp_hpts .

• b2bde8a6d391 tcp_hpts: consistenly use macros to lock & unlock
• 5cb73dbe4820 tcp_hpts: use booleans for tcp_hptsi() local variables
• 63446fd35421 tcp_hpts: use boolean to tell is it callout or userret context

Netdev

Tie receive packet headers to the correct NUMA domain, this sort of change can help a lot in systems with multiple NUMA domains to reduce cross domain traffic. This happening in iflib makes it 'free' for all iflib drivers.

• 3d642b0f71c5 iflib: Set the NUMA domain in receive packet headers

Add a big list of skus to igc

• 850f78d5a191 igc.4: Add I226 and other additions to supported list

adrian@ landed some macros that help with handling ht rates, this makes drivers cleaner:

• c6b44f64c330 net80211: add helper functions for determining HT transmit parameters
• 6749f059a586 rtwn: use ieee80211_ht_check_tx_shortgi_20() and ieee80211_ht_check_tx_shortgi_40()
• e1eff81ea99c rtwn: use ieee80211_ht_check_tx_shortgi_20() and ieee80211_ht_check_tx_shortgi_40()
• 057db5b227d0 iwn: use ieee80211_ht_check_tx_ht()
• 2014462da5b3 amrr: remove duplicate logic, use ieee80211_ht_check_tx_ht()
• 3f62f8ef5e40 iwn: use ieee80211_ht_check_tx_shortgi_20() and ieee80211_ht_check_tx_shortgi_40()
• 3d54d9e364f8 ath: use the new net80211 methods for AMPDU density/limit, short-GI

and he landed a bunch of improvements to rtwn from debugging. Chat in the wifi irc channel suggest that rtwn might get a lot faster soon. If you use rtwn you should test HEAD now to help catch any regressions.

• fcb5e8d0c19a rtwn: don't do 64 bit TSF extension by default
• 81aef988acc7 rtwn: remove the conditional compilation around the sc_ht40 option.
• 05c3851b20e0 rtwn: enable receiving AMSDU in AMPDU
• d76247e801de rtwn: enable FCS in the recive config to work around truncated frames
• 4fa68495f04f rtwn: fix rtl8812/rtl8821 vht definitions, add VHT calibration/rate control
• 77e64f45c478 rtwn: use ieee80211_ht_get_node_ampdu_density(), fix programming MAX_AGG

bz@ has landed HT and VHT improvements for the Linux KPI.

• a0e45db6f6eb contrib/wpa: pass IFM_IEEE80211_VHT5G if vht_enabled on the channel
• 243f6925bf81 net80211: 11ac: add options to manage VHT STBC
• 116102101a56 net80211: name IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_{NONE -> NO160}
• 4294f1cac153 net80211: add missing reference for struct ieee80211_vht_mcs_info
• 943a19c666d6 LinuxKPI: 802.11: make HT compile again
• 30d2f84ef2cb LinuxKPI: firmware: change order filenames trying to load firmware

Firewalls

Following up on the pf EIM NAT support Damjan Jovanovic has implemented support for EIM NAT for libalias users. If you use ipfw, ppp or netgraph you can now experiment with a more transparent NAT mapping.

• 61bf830cbb26 libalias: Add support for EIM NAT
• f132be9bac5f netgraph: Enable support for EIM NAT
• cb21fa3d0d26 ppp: Enable support for EIM NAT
• ef18594985c0 natd: Enable support for EIM NAT
• b6c90b909905 ipfw : Enable support for EIM NAT

Some stability fixes in pf and potential panic fixes.

• ad6562ec858f pf: Don't pfsync states with unrecoverable routing information
• f966ef3a6770 pf: fold if (s != NULL) and if (s) into one block
• c22c98798456 pf: fix potential NULL dereference in SCTP multihome handling
• c49c9da239ca pf: Move route-to information to rule actions
• 0dab21248bc9 pfkey: Fix some checks in kdebug_sadb()

Other stuff

First up, documentation of a wonderful hack from phk@ to show network traffic in bits per second by running with an 8 second interval. This had a few confused follow ups, it is so simple so people thought it couldn't possibly work.

• b5a8abe9502e How to show interface traffic in bits per second

Following on from the excellent Fall Summit talk by Ian from Metify on rural broadband, do a better job of documenting the cellular hardware we support.

• 53484f516ac4 u3g.4: Fall cleaning

I like the commit message on this one:

• 4d12c7b9df66 cu.1: describe better + tag spdx

  cu.1: describe better + tag spdx Preserve over 40 years of "call UNIX" BSD heritage while answering "one line about what it does" e.g.

  "how do I get a serial console?" "% apropos serial"

Make things easier for users to understand, but also preserve the past.

Please Send Feedback

That is all for this week. Next week will be the last report of the year, I'll be travelling (please say hi if you are at 38c3) and I think a report break might be nice.

The first report will probably be on the 10th of January, look for it where you found this one.

I would love to know if this summary was any help, if it was, or if you think I should cover other thing please let me know (thj@freebsd.org).

If you find a typo or have a correct let me know and I'll thank you at the end here.

You can see all prior posts here. ( rss )

My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .

Building on my earlier blog post on setting up PCIe pass through with bhyve , I've found a little time to move things around in my test bed and try something stupid.

Bitcoin is certainly a terrible thing, but it has made some useful components super cheap (though they are getting rare again). One feature of bitcoin mining is that it is super low usage on the PCIe bus, you feed your GPU something to do, it does it, and if you find a result you send a couple of hundred bytes back. That leaves a lot of bandwidth left over.

Miners knew what to do with this took advantage of PCIe topology and added switches, expanders and risers to get as many GPUs per motherboard as they could.

We can apply their tools for other things like driver development.

The idea is this, get a bunch of devices onto a VM host through the use of cheap downstream PCIe switches, have the host ignore them and make them available to guests on the host.

This makes it possible to do a lot of concentrated testing. You can for example stick 4 different revisions of a card on host and simultaneously test them all on the latest current, or stick 3 versions of the same card on the bus and test them on CURRENT, STABLE and STABLE-1 at the same time to unsure there aren't regressions.

For porting you could run guests for FreeBSD, Linux and OpenBSD and compare functionality and commands to the card for debugging.

Proof of Concept

I had this idea early this year and managed to get a POC together in a short 12 months of forgetting about it and an afternoon of moving machines around in the attic.

I picked up two types of PCIe expander, PCIe x1 -> x16 risers (which aren't used right now) and an ASMedia ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'. Later I got a cheap 12 GPU frame, adding a final piece of structure needed to make the set up practical.

The PCIe expander uses a USB3-A cable to carry the PCIe bus out an adapter card connected to the motherboard out to the switch board. The switch board has 4 PCIe x1 slots for cards.

I mounted all this on the frame with 2 Intel AX210 WiFi cards for a POC. Pulling the card to check functionality the switch appears in pciconf -lf like so:

pcib6@pci0:5:0:0:       class=0x060400 rev=0x00 hdr=0x01 vendor=0x1b21 device=0x1184 subvendor=0x1b21 subdevice=0x118f
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib7@pci0:6:1:0:       class=0x060400 rev=0x00 hdr=0x01 vendor=0x1b21 device=0x1184 subvendor=0x1b21 subdevice=0x118f
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib8@pci0:6:3:0:       class=0x060400 rev=0x00 hdr=0x01 vendor=0x1b21 device=0x1184 subvendor=0x1b21 subdevice=0x118f
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib9@pci0:6:5:0:       class=0x060400 rev=0x00 hdr=0x01 vendor=0x1b21 device=0x1184 subvendor=0x1b21 subdevice=0x118f
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib10@pci0:6:7:0:      class=0x060400 rev=0x00 hdr=0x01 vendor=0x1b21 device=0x1184 subvendor=0x1b21 subdevice=0x118f
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI

With the switch there I added the two PCIe WiFi cards and rebooted:

pcib6@pci0:5:0:0:       class=0x060400 rev=0x00 hdr=0x01 vendor=0x1b21 device=0x1184 subvendor=0x1b21 subdevice=0x118f
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib7@pci0:6:1:0:       class=0x060400 rev=0x00 hdr=0x01 vendor=0x1b21 device=0x1184 subvendor=0x1b21 subdevice=0x118f
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib8@pci0:6:3:0:       class=0x060400 rev=0x00 hdr=0x01 vendor=0x1b21 device=0x1184 subvendor=0x1b21 subdevice=0x118f
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib9@pci0:6:5:0:       class=0x060400 rev=0x00 hdr=0x01 vendor=0x1b21 device=0x1184 subvendor=0x1b21 subdevice=0x118f
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
pcib10@pci0:6:7:0:      class=0x060400 rev=0x00 hdr=0x01 vendor=0x1b21 device=0x1184 subvendor=0x1b21 subdevice=0x118f
    vendor     = 'ASMedia Technology Inc.'
    device     = 'ASM1184e 4-Port PCIe x1 Gen2 Packet Switch'
    class      = bridge
    subclass   = PCI-PCI
iwlwifi0@pci0:7:0:0:    class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2725 subvendor=0x8086 subdevice=0x0024
    vendor     = 'Intel Corporation'
    device     = 'Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak]'
    class      = network
iwlwifi1@pci0:10:0:0:   class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2725 subvendor=0x8086 subdevice=0x0024
    vendor     = 'Intel Corporation'
    device     = 'Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak]'
    class      = network

Each card can be used on the host simultaneously. I took the cards from the host and enabled PCIe pass through for AMD in /boot/loader.conf :

pptdevs="7/0/0 10/0/0"          # intel ax210 wifi
hw.vmm.amdvi.enable=1

Finally I used the script from the previous post to run two FreeBSD CURRENT VMs, giving each one of the cards and the successfully came up and could do the wireless.

The cards can scan from here, harder workloads are a future problem. I want to install 2 more expanders on this machine and more cards to see how things work when heavily loaded. This 12 GPU bracket has 35 holes so I could add a lot of stuff.

There are PCIe bus overheads here, I'm reducing down a PCIe4 bus to PCIe2 for the Wifi cards, but they aren't exactly high performance devices in PCIe terms. I might also hit power limits, I didn't really want to ask about doing this POC, I figured I wouldn't get good answers based on similar questions on the FreeBSD mailing lists in the last year.

This seems to work, scaling is to be seen.

My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .