Linux and *BSD have completely changed the storage market. They are the core of so many storage products, allowing startups and established vendors alike to bring new products to the market more rapidly than previously possible.
Almost every vendor I talk to these days has built their system on top of these and then there are the number of vendors who are using Samba implementations for their NAS functionality. Sometimes they move on from Samba but almost all version 1 NAS boxen are built on top of it.
With each kernel revision, LLVM Clang gets closer to being able to build the mainline Linux kernel. There's now just a few dozen patches outstanding for LLVMLinux to be a mainline success.
Behan Webster gave his usual talk at LinuxCon in Chicago this week about the state of LLVMLinux -- building the Linux kernel with Clang rather than GCC. There's been many Phoronix articles about the topic so there isn't too much more to share beyond that many developers want to use Clang to compile the Linux kernel to lead to better code portability of the kernel, faster compilation times of Clang, potential performance differences, LLVM and Clang are more liberally licensed, and there's a host of other development extras with Clang.
While Broadwell is right around the corner and Intel's open-source Linux developers are already working on Skylake graphics support, the DragonFlyBSD crew has just managed Haswell graphics support for their DRM driver ported from FreeBSD that in turn was ported from an earlier version of the Linux kernel.
DragonFlyBSD 3.8 brought Intel DRM support but that only covered the Intel Ivy Bridge graphics hardware and was a port from the Linux 3.8 kernel era. Hitting DragonFlyBSD mainline Git for its kernel is now the Haswell support. While the i915 DRM driver's infrastructure was ported to DragonFly interfaces, adding Haswell support required extra work and still isn't fully operational.
Clang is finally co installable on Debian. 3.4, 3.5 and the current trunk (snapshot) can be installed together.
So, just like gcc, the different version can be called with clang-3.4, clang-3.5 or clang-3.6.
/usr/bin/clang, /usr/bin/clang++, /usr/bin/scan-build and /usr/bin/scan-view are now handled through the llvm-defaults package.
llvm-defaults is also now managing clang-check, clang-tblgen, c-index-test, clang-apply-replacements, clang-tidy, pp-trace and clang-query.
Changes are also available on llvm.org/apt/.
The next step will be to manage also llvm-defaults on llvm.org/apt to simplify the transition for people using these packages.
Last month in Cambridge was the 2014 GNU Tools Cauldron where GCC as a JIT compiler and other interesting topics were discussed by developers. One of the topics discussed was surrounding better collaboration between GCC and LLVM developers.
While in my earlier 2014 GNU Tools Cauldron coverage I commented on the session about GCC+LLVM collaboration, after the past Phoronix article on the event some additional information was published. The purpose of the GCC and LLVM/Clang compiler teams collaborating is to reach common defaults between compilers, avoid confusion with architecture flags and other compiler switches, and make other improvements to better the interoperability between the compilers to make a better end-user/developer experience. The focus isn't on merging GCC+LLVM, debating licensing differences, fighting over who as the faster compiler, or other such heated topics.
The Unified Extensible Firmware Interface (UEFI) provides boot- and
run-time services for x86 and other computers. For the x86 architecture
it replaces the legacy BIOS. This project will adapt the FreeBSD loader
and kernel boot process for compatibility with UEFI firmware, found on
contemporary servers, desktops, and laptops.
Ed and Nathan completed a number of integration tasks over the past
three months. Nathan added a first-stage loader, boot1.efi, to support
chain-loading the rest of the system from a UFS filesystem. This allows
the UEFI boot process to proceed in a similar fashion as with BIOS
boot. Nathan also added UEFI support to the FreeBSD installer and
release image creation script.
The EFI framebuffer requires the vt(4) system console -- a framebuffer
driver is not implemented for the legacy syscons(4) console. Ed added
automatic vt(4) selection to the UEFI boot path.
Snapshots are now built as dual-mode images, and should boot via both
BIOS and UEFI. Our plan is to merge the UEFI and vt(4) work to
stable/10 to appear in FreeBSD 10.1-RELEASE.
This project is sponsored by The FreeBSD Foundation.
After more than a half-year in development and working on tens of thousands of lines of code, Pkg 1.3.0 has been released by FreeBSD developers.
Pkg 1.3.0 introduces a new solver to automatically handle conflicts and dynamically discover them, pkg install can now install local files and resolve their dependencies via remote repositories, sandboxing of the code has happened, improved portability of the code took place, the pkg API has been simplified, improvements to the multi-repository mode, and a ton of other changes and fixes took place.
More on the pkg 1.3.0 release for improved package management on FreeBSD can be found via this mailing list post.