10 ms·

It really surprises me when people look for "small" programming projects. Boot a Unix, leave X, sit still for 20 minutes. There. Get the sources to your Unix

by mahmud 16y ago

It really surprises me when people look for "small" programming projects. Boot a Unix, leave X, sit still for 20 minutes. There. Get the sources to your Unix and just go read the code for your everyday utils. This is best done with a BSD, that isn't bloated with GNUisms. If you don't believe me about GNU bloat, just look here: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/ http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/ Get a BSD and devour the beauty that is Unix, unfuckedwith. FreeBSD also comes with all the papers & research docs you need; love how the troff formatting is readable in console with zcat. The CRT radiation kept me glowing green for many an enjoyable night.

derleth 16y ago
> bloat This word, which I see so often, is almost entirely content-free. At most, it conveys a vague sense of 'big is bad'; the association of 'bigness' is the only thing that saves it from being a purely content-free snarl word. http://rationalwiki.org/wiki/Loaded_language#Snarl_words http://rationalwiki.org/wiki/Loaded_language#Snarl_words ("When used as a snarl words, these words are essentially meaningless; most of them can be used with meaning, but rarely are.") To say what ought to be obvious, one person's bloat is another person's essential feature. And, yes, I do use that paragon of GNU software, GNU Emacs, and surely you realize the folly of trying to tell me my editor of choice is bloated.
- mahmud 16y ago
  Bloat is real, and it affects one in five American teenagers, and 100% of GNU code. Bloat can be defined as `cat` being 7 pages in BSD, and 20 in GNU. It's an aesthetic value judgment, made by someone qualified to say .. "do not want": http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/bin/cat/cat.c?rev=1.32.24.1;content-type=text%2Fplain http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/bin/cat... http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat.c http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat....
  - Someone 16y ago
    Seven? That is at least around 85% bloat. http://minnie.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/cmd/cat.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/cm... needed only one page. As the poster above said, one man's bloat is another man's essential feature. Back to the subject: reading those old sources really learns you why, back in the seventies, people found Unix so appealing. even ignoring the feature growth/creep (or whatever you want to call it), you do not have to wade through a zillion copyright header lines, option parsing that goes on for ages, locale-specific stuff, etc, before getting to the meat of the program. Disadvantage is that some code dives into assembler fairly quickly (for example, printf is mostly assembly in the system I refer to above)
    - mahmud 16y ago
      early C source code kept its figure by foregoing any stupid bounds checking.
  - danieldk 16y ago
    The immediate difference I noticed is that the GNU version contains a lot more comments describing what actually happens. Now, what do you think is more appropriate for educational purposes. Source code with plenty of comments or source code with nearly no comments at all?
    - mahmud 16y ago
      If you just wanna see how a few library functions and system calls are used? yeah, just get APUE and dig into the simplest implementations you can find, which is often BSDish. I routinely gloss over comments when reading code anyway; the most accurate documentation is found via reflection & introspection on the system itself, not comments.
  - Confusion 16y ago
    314 vs. 784 lines, not adjusted for amount of comments. Bloat or simply an increased set of features? Being used to GNU commands, I've always found BSD commands lacking features I often use. Although you can usually compose the same operation using some additional pipes and although I understand how this would be considered 'prettier', 'cleaner' or 'better', I still feel the GNU commands I am used to are just right and do not constitute 'bloat'.
barrkel 16y ago
The GNU toolset may have combobulated source, but it's a damn sight more usable and useful than bare-bones utilities.
- mahmud 16y ago
  But the metric of this thread was "small C projects", not useful, cushy coreutils.
danieldk 16y ago
If you want minimalism, you could study the BusyBox sources as well. E.g. BusyBox coreutils: http://git.busybox.net/busybox/tree/coreutils http://git.busybox.net/busybox/tree/coreutils Most BusyBox utilities leave out more options than FreeBSD equivalents.
psadauskas 16y ago
I almost always prefer the GNU utils to the BSD ones. The GNU ones usually allow arguments in nicer orders. GNU `sort -h` can sort the human-sized output of GNU `du -h`. I've noticed tons of niceties from these sorts of tools on Ubuntu are completely missing from BSD based OSX. One man's bloat is another man's convenience.

by mahmud 16y ago

derleth 16y ago

> bloat This word, which I see so often, is almost entirely content-free. At most, it conveys a vague sense of 'big is bad'; the association of 'bigness' is the only thing that saves it from being a purely content-free snarl word. http://rationalwiki.org/wiki/Loaded_language#Snarl_words http://rationalwiki.org/wiki/Loaded_language#Snarl_words ("When used as a snarl words, these words are essentially meaningless; most of them can be used with meaning, but rarely are.") To say what ought to be obvious, one person's bloat is another person's essential feature. And, yes, I do use that paragon of GNU software, GNU Emacs, and surely you realize the folly of trying to tell me my editor of choice is bloated.

mahmud 16y ago
Bloat is real, and it affects one in five American teenagers, and 100% of GNU code. Bloat can be defined as `cat` being 7 pages in BSD, and 20 in GNU. It's an aesthetic value judgment, made by someone qualified to say .. "do not want": http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/bin/cat/cat.c?rev=1.32.24.1;content-type=text%2Fplain http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/bin/cat... http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat.c http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat....
- Someone 16y ago
  Seven? That is at least around 85% bloat. http://minnie.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/cmd/cat.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/cm... needed only one page. As the poster above said, one man's bloat is another man's essential feature. Back to the subject: reading those old sources really learns you why, back in the seventies, people found Unix so appealing. even ignoring the feature growth/creep (or whatever you want to call it), you do not have to wade through a zillion copyright header lines, option parsing that goes on for ages, locale-specific stuff, etc, before getting to the meat of the program. Disadvantage is that some code dives into assembler fairly quickly (for example, printf is mostly assembly in the system I refer to above)
  - mahmud 16y ago
    early C source code kept its figure by foregoing any stupid bounds checking.
- danieldk 16y ago
  The immediate difference I noticed is that the GNU version contains a lot more comments describing what actually happens. Now, what do you think is more appropriate for educational purposes. Source code with plenty of comments or source code with nearly no comments at all?
  - mahmud 16y ago
    If you just wanna see how a few library functions and system calls are used? yeah, just get APUE and dig into the simplest implementations you can find, which is often BSDish. I routinely gloss over comments when reading code anyway; the most accurate documentation is found via reflection & introspection on the system itself, not comments.
- Confusion 16y ago
  314 vs. 784 lines, not adjusted for amount of comments. Bloat or simply an increased set of features? Being used to GNU commands, I've always found BSD commands lacking features I often use. Although you can usually compose the same operation using some additional pipes and although I understand how this would be considered 'prettier', 'cleaner' or 'better', I still feel the GNU commands I am used to are just right and do not constitute 'bloat'.

barrkel 16y ago

The GNU toolset may have combobulated source, but it's a damn sight more usable and useful than bare-bones utilities.

mahmud 16y ago
But the metric of this thread was "small C projects", not useful, cushy coreutils.

danieldk 16y ago

If you want minimalism, you could study the BusyBox sources as well. E.g. BusyBox coreutils: http://git.busybox.net/busybox/tree/coreutils http://git.busybox.net/busybox/tree/coreutils Most BusyBox utilities leave out more options than FreeBSD equivalents.

psadauskas 16y ago

I almost always prefer the GNU utils to the BSD ones. The GNU ones usually allow arguments in nicer orders. GNU `sort -h` can sort the human-sized output of GNU `du -h`. I've noticed tons of niceties from these sorts of tools on Ubuntu are completely missing from BSD based OSX. One man's bloat is another man's convenience.