Posts Tagged FreeBSD

FreeBSD 8.0 Release

Posted by on Friday, 27 November, 2009

From :

The highlights in the 8.0-RELEASE are the following:

  • A new virtualization container named “vimage” has been implemented. This is a jail with a virtualized instance of the FreeBSD network stack and can be created by using jail(8) command.
  • The FreeBSD netisr framework has been reimplemented for parallel threading support. This is a kernel network dispatch interface which allows device drivers (and other packet sources) to direct packets to protocols for directly dispatched or deferred processing. The new implementation supports up to one netisr thread per CPU, and several benchmarks on SMP machines show substantial performance improvement over the old one.
  • The FreeBSD newbus subsystem is now MPSAFE.
  • The FreeBSD TTY layer has been replaced with a new one which has better support for SMP and robust resource handling. A tty now has own mutex and it is expected to improve scalability when compared to the old implementation based on Giant lock.
  • [amd64, i386] The FreeBSD Linux emulation layer has been updated to version 2.6.16 and the default Linux infrastructure port is now emulators/linux_base-f10 (Fedora 10).
  • The FreeBSD GENERIC kernel now includes Trusted BSD MAC (Mandatory Access Control) support. No MAC policy module is loaded by default.
  • The FreeBSD USB subsystem has been reimplemented to support modern devices and better SMP scalability. The new implementation includes Giant-lock-free device drivers, Linux compatibility layer, usbconfig(8) utility, full support for split transaction and isochronous transaction, and so on.
  • The FreeBSD CAM SCSI subsystem ( cam(4)) now includes experimental support for ATA/SATA/AHCI-compliant devices.
  • The shared vnode locking for pathname lookups in the VFS(9) subsystem has been improved.
  • The ZFS file system has been updated to version 13. The changes include ZFS operations by a regular user, L2ARC, ZFS Intent Log on separated disks (slog), sparse volumes, and so on.
  • The FreeBSD NFS subsystem now supports RPCSEC_GSS authentication on both the client and server.
  • The FreeBSD NFS subsystem now includes a new, experimental implementation with support for NFSv2, NFSv3, and NFSv4.
  • The wireless network support layer (net80211) now supports multiple BSS instances on the supported network devices.
  • The FreeBSD L2 address translation table has been reimplemented to reduce lock contention on parallel processing and simplify the routing logic.
  • The IGMPv3 and SSM (Source-Specific Multicast) including IPv6 SSM and MLDv2 have been added.
  • The ipsec(4) subsystem now supports NAT-Traversal (RFC 3948).
  • The GCC stack protection (also known as ProPolice) has been enabled in the FreeBSD base system.
  • The supported version of the GNOME desktop environment (x11/gnome2) has been updated to 2.26.3.
  • The supported version of the KDE desktop environment (x11/kde4) has been updated to 4.3.1.

For more details, please see the Detailed Release Notes.

A list of all platforms currently under development can be found on the Supported Platforms page.

Debian GNU/kFreeBSD

Posted by on Saturday, 11 April, 2009

Found at

Here are the reasons why we think Debian GNU/kFreeBSD could be preferred to other systems such as FreeBSD and Debian GNU/Linux.

They’re not absolute truths, nor do we expect everyone to agree with them. So please don’t engage in an endless discussion trying to convince someone that Debian GNU/kFreeBSD is the best. That kind of things do us more harm than good.

Why would you prefer Debian GNU/kFreeBSD to Debian GNU/Linux?

  • Cleaner or more standard kernel interfaces:
    • Single /dev implementation via devfs, instead of the 3 discordant ways of handling /dev that Linux provides.
    • OSS as the default sound system (i.e. the standard interface supported by almost every Unix-like system around).
    • OpenBSD Packet Filter (pf).
  • Other nice security features, like jails.

  • Support for NDIS drivers in the mainline kernel. On Linux, NdisWrapper is unlikely to make it into the mainline kernel.

  • Possible support for ZFS in the mainline kernel. Due to license and patent issues, ZFS is unlikely to appear on Linux.
  • kFreeBSD offers an alternative in case Linux is branded illegal by the SCO case or other threats. In legal terms, Linux sources are like a minefield. kFreeBSD is much less vulnerable to such attacks because of its less bazaar-like development model.
  • kFreeBSD developers often have more interest in merging new features rather than spawning forks all along (the port to Xbox is a very good example. See the responses from Linus Torvalds and kFreeBSD developers).

  • Some people say that kFreeBSD has better performance and/or stability (especially in disk/filesystem areas).
  • The FreeBSD kernel might support some hardware which Linux does not support and/or the FreeBSD kernel support might be better (less bugs).

Why would you prefer Debian GNU/kFreeBSD to FreeBSD?

  • If you like the Debian package system (or its package set) more than FreeBSD ports (just a matter of preference).
  • If you like GNU userland more than BSDish one (again, just a matter of preference).
  • If you don’t have anything against GPL or other copylefted free software licenses, you’ll appreciate that useful kernel modules like ext2fs driver, the upcoming reiserfs and xfs, or the upcoming ethernet driver for Xbox are (or will be) compiled in on the default kernel.
  • If you’re concerned about running a 100% free system, our commitment to the Debian Free Software Guidelines (DFSG) guarantees that Debian GNU/kFreeBSD doesn’t contain any non-free software. In fact, we have removed some non-free binary-only drivers that are contained in the upstream FreeBSD tree, like the ath driver.

Now I found this very interesing myself as I have used both systems and liked them both. I found debian to be better in respects for configureability via apt, and FreeBSD was equally good with its ports, though time consuming compiling somewhat. FBSD generally i found handled higher loads on production servers better, though to be fair that would be a HUGE serverload and for the most part Linux would do fine.

So if this happens, I would definately be one counted in having a nosey and giving it a go. However I do wonder if it would take off enough, and have enough support behind it to keep it going (and anyone whos in sysadmin hates trying to upgrade something no longer supported!)