LLVM's Clang going into FreeBSD's base system | Hacker News Reader

LLVM's Clang going into FreeBSD's base system

comments.gmane.org

72 pointsyan20 comments

If FreeBSD does replace GCC, will there be any GNU software left in the base system?

On my FreeBSD 8 machine, grep is still GNU grep. Last I knew, bsdgrep wasn't quite finished, but was close. diff is from GNU diffutils, but patch appears not to be a GNU variant. bc/dc are GNU.

Getting really close though. The compiler was the last really huge piece of the system that was GNU dependent.

GNU grep is still there because the regex implementation is not on par yet with the GNU version, once that is the case bsdgrep will become the default, especially once it is shown to at least reliably have a ports tree build work (on the build hosts).

bsddiff and bsdsort are available in the ports tree according to http://wiki.freebsd.org/SummerOfCode2008#head-860658a852d058...

bc/dc have been replaced with the versions from OpenBSD:

http://lists.freebsd.org/pipermail/svn-src-head/2010-January...

The compiler was the last really huge piece of the system that was GNU dependent.

I think you're forgetting about binutils and gdb. It sounds like there might be a replacement for binutils coming up soon, but I haven't heard anyone seriously talk about writing a new debugger. There's also texinfo (hopefully this can die in 10.0) and groff (hopefully this can be replaced by some new NetBSD code in 10.0).

But we're definitely moving in the right direction.

FreeBSD has the libelf project, along with the elftoolchain that is attempting to write replacement versions of binutils tools that are BSD licensed:

http://wiki.freebsd.org/LibElf

More information:

http://elftoolchain.sourceforge.net/for-review/libelf-by-exa...

http://wiki.freebsd.org/LibElf/ImplementationStatus

That's what I meant by "there might be a replacement for binutils coming up soon". :-)

And I just noticed you are Colin Percival ... yay for paying attention, off course you'd know about the ELF projects for FreeBSD :P.

BTW, your slideshow on the encryption stuff, very cool! Enjoyed it tremendously.

But we're definitely moving in the right direction.

Replacing functional, well-tested, and Free tools with completely new ones?

Yeah, there's a reason why I don't use *BSD.

For most of these it's a case of replacing old, poorly designed, unmaintained (and in light of the poor design, mostly unmaintainable) code with better designed and well-maintained versions.

This was definitely the case for replacing GNU tar/cpio/pax with libarchive-based versions.

Why write new versions rather than fix the GNU versions? More eyeballs, and all that...

To borrow a phrase from the rollout of DNSSEC: It's really hard to rebuild a plane while in flight. Sometimes it's easier to build a second plane, fly it up parallel to the old plane, then jump across.

For what it's worth, I've talked to some people at linux distributions who are excited about ditching gcc too. (Not going to say who they are, because I don't want to get them in trouble.)

But it's kind of like building the new airplane out of rusty metal, to replace the rusting airplane you currently have. While you're taking the effort to rebuild something, you might as well use new metal.

What I mean here is, why replace a big collection of flaky C apps with another big collection of flaky C apps? Sure, maybe your new version uses strlcpy instead of strncpy, but that doesn't really fix any fundamental implementation problems.

If you think libarchive is flaky, you have incredibly high standards.

  It's really hard to rebuild a plane while in flight

Obviously these people didn't know that http://www.youtube.com/watch?v=L2zqTYgcpfg

[Disclaimer - I used to work for them]

Has there been a concentrated effort to move FreeBSD off of GNU tools (your question seems to imply this)? If so, I'm curious, why? Licensing issues? Architectural issues? Something else?

Mixture of licensing, technical, and personality/political/religious issues, I think, depending on the person involved (not everyone has the same motivations). The three big camps are probably: 1. people who think GNU software sucks technically; 2. people who don't like the GPL; and 3. people who really dislike the FSF and/or Richard Stallman.

The first reason probably applies most to big projects like gcc, where it's alleged that the FSF's development process has led to un-modular, hard-to-maintain software. But there are some differences on smaller projects as well, where the BSDs have a tendency to prefer more use of libraries with command-line apps as front-ends to the libs, while the FSF prefers self-contained command-line utilities that interact in the traditional Unix piping style. E.g. GNU tar and GNU gzip are mostly self-contained utilities, while the BSD versions have all the real code in libarchive and zlib, with some command-line frontends.

Some of the more minor rewrites I assume are due to licensing or personality/political issues (I doubt technical reasons are what lay behind OpenBSD writing GNU bc/dc workalikes).

Number 2 is the biggest issue that is pushing this change. With the GPL 3 none of the new GCC versions could be imported into the base system for FreeBSD as such the base version for GCC has had to stay behind on the last viable GPL 2 version that was available. This has led to major compiler improvements not being available to create better binaries. It was decided that instead moving to a BSD licensed compiler stack would ultimately lead to a better solutions, easier to update, less GPL components that would taint any of the systems thereby causing less licensing issues and headaches for people who want to use BSD systems.

Number 2 is the biggest issue that is pushing this change

I disagree. Having just spent a week at BSDCan and the attached FreeBSD developer summit, I'd say that the biggest reason is code quality.

Apple very definitely supported LLVM/Clang because they wanted to avoid GPLv3. FreeBSD is very happy to have a superior compiler available, and the fact that it's BSD licensed is extra icing on the cake. But if LLVM wasn't happening, I'm 100% certain that we would end up importing a newer (GPLv3) version of gcc.

It's nice to have at least two viable implementations of any software component, so not everyone is relying on the same code with the same potential bugs. It's a lot harder to crack into a mixed Linux/BSD environment than one that's purely one or the other.

Reply on news.ycombinator.com