5 ms·

Any reason for picking the BSD variants of usedland tooling over the GNU ones?

torstenvl 3y ago
Can't speak for everyone, but for me... familiarity, hackability, simplicity, standards compliance. GNU coreutils deviate from POSIX in a number of instances. GNU coreutils are also verbose and potentially overengineered. Compare GNU ls.c (4726 LOC) to FreeBSD ls.c (1030 LOC), for example. Even if you include the other BSD source files used in ls, the FreeBSD version is still half the size of the GNU version. GNU grep is over 3000 LOC, whereas the FreeBSD version is 724.
- burntsushi 3y ago
  What kinds of patches have you made to the BSD coreutils programs that you use?
  - torstenvl 3y ago
    https://github.com/torstenvl/betterls https://github.com/torstenvl/betterls To be fair, one of these two flags comes built in with GNU ls, but using GNU ls comes with the downside of losing support for macOS extended attributes (and GNU ls doesn't have --group-dots-extra-first).
    - Pet_Ant 3y ago
      I mean that seems like a simple patch to upstream if it’s a real deal breaker for you….
      - torstenvl 3y ago
        Or I can just continue being happy hacking on simple code bases. It is not my responsibility to upstream anything. If you feel like it should be upstreamed, my additions are open source. Go for it.
      - corbezzoli 3y ago
        You make it sound like just because you want and write something it will get merged into a project. It doesn’t work like that. Maintainers have a million reasons to say no and I have one reason to just use a different tool instead.
- jppittma 3y ago
  Who cares about posix? It's not the 2000's anymore. Solaris is dead. HP-UX is dead. Were you worried that someday you might have to port your shell script to AIX? GNU and Linux won. The only BSD environment is macOS, and if you put GNU on macOS, then the only thing I can think of that's worth a mention is alpine and busybox containers, but at that point it feels like we're just grasping at straws.
  - torstenvl 3y ago
    > Who cares about posix? ... GNU and Linux won. Well, I do :) That's why I said I was only speaking for myself. As long as we have a rich variety of free and open source software to choose from, I think we've all won.
- arp242 3y ago
  > GNU grep is over 3000 LOC, whereas the FreeBSD version is 724. Where are you getting that number from? Because I have a bit over 1,500 lines in usr.bin/grep (code only, excluding comments and blanks) vs. 3,900 for GNU grep. Also you can't compile bsdgrep with just POSIX libc (such as musl) since it relies on some extensions (specifically: REG_STARTEND). So if you're looking for POSIX_ME_HARDER then bsdgrep isn't actually the right place.
  - burntsushi 3y ago
    They probably also aren't counting the lines of whatever is in gnulib that GNU grep uses.
    - arp242 3y ago
      Please don't make this thread NSFW.
  - adrian_b 3y ago
    I suppose that only the lines of usr.bin/grep/grep.c have been counted by the previous poster. The number of lines is obviously version-dependent. Looking at the file mentioned above on a FreeBSD system to which I happen to be connected, I see 805 lines, including the comments and blanks, while all the source files total 2027 lines, also including the comments and blanks.
- globular-toast 3y ago
  Honestly picking programs based on lines of source code where fewer is better is quite silly. Better algorithms generally have more code, not less. Unless you're doing embedded work it essentially doesn't matter how "big" programs are.
  - tm-guimaraes 3y ago
    It matters if you want to hack on them
    - globular-toast 3y ago
      True, to some extent. Being "big" doesn't necessarily mean it's hard to hack on, though. Emacs is huge and probably the easiest thing to hack on.
- vocworker 3y ago
  Isn't bsd grep very slow? I remember reading "why gnu grep is fast": https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...
- sofixa 3y ago
  Isn't that because GNU grep has more features than FreeBSD grep? Had to do a complex regex capturing to rewrite recently (automatic help based on Makefile command comments in a specific format), and having to have compatibility with FreeBSD grep was the main reason I couldn't do it with grep only and had to resort to Perl. If anyone is curious, this is the resulting Perl oneliner: perl -WE 'printf ("COMMAND;DESCRIPTION;USAGE\n");while (my $line = <>) { $line =~ /^(.*):\s#\s(.*)\[Usage\s`(.\*)`]/ && printf("$1;$2;$3\n")};' Makefile | column -c "3" -s ";" -t

Can't speak for everyone, but for me... familiarity, hackability, simplicity, standards compliance. GNU coreutils deviate from POSIX in a number of instances. GNU coreutils are also verbose and potentially overengineered. Compare GNU ls.c (4726 LOC) to FreeBSD ls.c (1030 LOC), for example. Even if you include the other BSD source files used in ls, the FreeBSD version is still half the size of the GNU version. GNU grep is over 3000 LOC, whereas the FreeBSD version is 724.

burntsushi 3y ago
What kinds of patches have you made to the BSD coreutils programs that you use?
- torstenvl 3y ago
  https://github.com/torstenvl/betterls https://github.com/torstenvl/betterls To be fair, one of these two flags comes built in with GNU ls, but using GNU ls comes with the downside of losing support for macOS extended attributes (and GNU ls doesn't have --group-dots-extra-first).
  - Pet_Ant 3y ago
    I mean that seems like a simple patch to upstream if it’s a real deal breaker for you….
    - torstenvl 3y ago
      Or I can just continue being happy hacking on simple code bases. It is not my responsibility to upstream anything. If you feel like it should be upstreamed, my additions are open source. Go for it.
    - corbezzoli 3y ago
      You make it sound like just because you want and write something it will get merged into a project. It doesn’t work like that. Maintainers have a million reasons to say no and I have one reason to just use a different tool instead.
jppittma 3y ago
Who cares about posix? It's not the 2000's anymore. Solaris is dead. HP-UX is dead. Were you worried that someday you might have to port your shell script to AIX? GNU and Linux won. The only BSD environment is macOS, and if you put GNU on macOS, then the only thing I can think of that's worth a mention is alpine and busybox containers, but at that point it feels like we're just grasping at straws.
- torstenvl 3y ago
  > Who cares about posix? ... GNU and Linux won. Well, I do :) That's why I said I was only speaking for myself. As long as we have a rich variety of free and open source software to choose from, I think we've all won.
arp242 3y ago
> GNU grep is over 3000 LOC, whereas the FreeBSD version is 724. Where are you getting that number from? Because I have a bit over 1,500 lines in usr.bin/grep (code only, excluding comments and blanks) vs. 3,900 for GNU grep. Also you can't compile bsdgrep with just POSIX libc (such as musl) since it relies on some extensions (specifically: REG_STARTEND). So if you're looking for POSIX_ME_HARDER then bsdgrep isn't actually the right place.
- burntsushi 3y ago
  They probably also aren't counting the lines of whatever is in gnulib that GNU grep uses.
  - arp242 3y ago
    Please don't make this thread NSFW.
- adrian_b 3y ago
  I suppose that only the lines of usr.bin/grep/grep.c have been counted by the previous poster. The number of lines is obviously version-dependent. Looking at the file mentioned above on a FreeBSD system to which I happen to be connected, I see 805 lines, including the comments and blanks, while all the source files total 2027 lines, also including the comments and blanks.
globular-toast 3y ago
Honestly picking programs based on lines of source code where fewer is better is quite silly. Better algorithms generally have more code, not less. Unless you're doing embedded work it essentially doesn't matter how "big" programs are.
- tm-guimaraes 3y ago
  It matters if you want to hack on them
  - globular-toast 3y ago
    True, to some extent. Being "big" doesn't necessarily mean it's hard to hack on, though. Emacs is huge and probably the easiest thing to hack on.
vocworker 3y ago
Isn't bsd grep very slow? I remember reading "why gnu grep is fast": https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...
sofixa 3y ago
Isn't that because GNU grep has more features than FreeBSD grep? Had to do a complex regex capturing to rewrite recently (automatic help based on Makefile command comments in a specific format), and having to have compatibility with FreeBSD grep was the main reason I couldn't do it with grep only and had to resort to Perl. If anyone is curious, this is the resulting Perl oneliner: perl -WE 'printf ("COMMAND;DESCRIPTION;USAGE\n");while (my $line = <>) { $line =~ /^(.*):\s#\s(.*)\[Usage\s`(.\*)`]/ && printf("$1;$2;$3\n")};' Makefile | column -c "3" -s ";" -t