Hacker News Reader

Comment by mahmud | Hacker News Reader

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/

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.

View on HN

If you want minimalism, you could study the BusyBox sources as well. E.g. BusyBox coreutils:

http://git.busybox.net/busybox/tree/coreutils

Most BusyBox utilities leave out more options than FreeBSD equivalents.

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.

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

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

> 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

("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.

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...

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat....

Seven? That is at least around 85% bloat. 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)

early C source code kept its figure by foregoing any stupid bounds checking.

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?

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.

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'.

In many cases the "GNU bloat" lies not in the added features but in unnecessary cleverness and complexity. See how GNU cat does it's own complex buffering, while FreeBSD version just calls read/write in loop in simple case and uses stdio in the complex one.

Plan 9's cat is written in a mere 35 lines: http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c

As always, if you want to read C code as written by the same people who invented C, the Plan 9 source code (http://plan9.bell-labs.com/sources/plan9/sys/src/) is a great resource.

Then what? spend an eternity in heart-break hotel with LispM & BeOS fans? ;-)

Nah, come join the fun w/ the Plan 9 crew at http://golang.org!

From a quick skim of the two sources, the difference in sizes can be attributed to:

1) The GNU version has MUCH more verbose commenting 2) The GNU version reads input in blocks in cooked mode, rather than a character at a time as the BSD cat does. This is MUCH faster, but it leads to a lot more complexity, and thus more code. It also carefully calculates the optimal block size to use for this; this is also quite complex and carefully commented (see, eg, the 20 line comment at line 736). 3) The GNU version has to be portable to multiple unixes, and thus has a number of places where it has to test for multiple error codes, and/or missing features 4) The GNU version has a very verbose --help output, which consumes a good page or so of code by itself.

I don't really see any 'bloat' there. Sure, it's okay to have a simple cat, but it's not a bad idea to optimize a tool that's used so frequently. And the verbose --help output, verbose commenting, and portability are all part of the GNU coding standards. You can argue about whether you want to spend all that effort on it, but I don't think the sheer volume of code is a good measure for whether the code is good or not.

Reply on news.ycombinator.com