4 ms·

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

by durin42 16y ago

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.

X-Istence 16y ago
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-860658a852d0581211825bae79440278f7df7d07 http://wiki.freebsd.org/SummerOfCode2008#head-860658a852d058...
Malus 16y ago
bc/dc have been replaced with the versions from OpenBSD: http://lists.freebsd.org/pipermail/svn-src-head/2010-January/013873.html http://lists.freebsd.org/pipermail/svn-src-head/2010-January...
cperciva 16y ago
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.
- X-Istence 16y ago
  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 http://wiki.freebsd.org/LibElf More information: http://elftoolchain.sourceforge.net/for-review/libelf-by-example-20100112.pdf http://elftoolchain.sourceforge.net/for-review/libelf-by-exa... http://wiki.freebsd.org/LibElf/ImplementationStatus http://wiki.freebsd.org/LibElf/ImplementationStatus
  - cperciva 16y ago
    That's what I meant by "there might be a replacement for binutils coming up soon". :-)
    - X-Istence 16y ago
      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.
- jrockway 16y ago
  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.
  - cperciva 16y ago
    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.
    - jrockway 16y ago
      Why write new versions rather than fix the GNU versions? More eyeballs, and all that...
      - cperciva 16y ago
        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.)
        jrockway 16y ago
        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.
        16y ago

by durin42 16y ago

X-Istence 16y ago

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-860658a852d0581211825bae79440278f7df7d07 http://wiki.freebsd.org/SummerOfCode2008#head-860658a852d058...

Malus 16y ago

bc/dc have been replaced with the versions from OpenBSD: http://lists.freebsd.org/pipermail/svn-src-head/2010-January/013873.html http://lists.freebsd.org/pipermail/svn-src-head/2010-January...

cperciva 16y ago

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.

X-Istence 16y ago
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 http://wiki.freebsd.org/LibElf More information: http://elftoolchain.sourceforge.net/for-review/libelf-by-example-20100112.pdf http://elftoolchain.sourceforge.net/for-review/libelf-by-exa... http://wiki.freebsd.org/LibElf/ImplementationStatus http://wiki.freebsd.org/LibElf/ImplementationStatus
- cperciva 16y ago
  That's what I meant by "there might be a replacement for binutils coming up soon". :-)
  - X-Istence 16y ago
    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.
jrockway 16y ago
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.
- cperciva 16y ago
  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.
  - jrockway 16y ago
    Why write new versions rather than fix the GNU versions? More eyeballs, and all that...
    - cperciva 16y ago
      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.)
      - jrockway 16y ago
        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.
        16y ago