Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decoded: GNU Coreutils

maizure.org

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Decoded: GNU Coreutils

#21

Post by cat199 »

serhart wrote: post #8
cat199 wrote: post #6

Earlier quoted context omitted.

Did I? "This resource is for novice programmers exploring the design of command-line utilities. It is best used as an accompaniment providing useful background while reading the source code of the utility you may be interested in. " ^ "best used as an accompaniment" I posit that GNUs intentionally obfuscated code design[1]^ requires the use of such a site, whereas, reading the originals and their decedents, provides…

I'm pretty curious on how you conclude that GNU is "intentionally obfuscating code" from [1]. I read [1] as good advice to avoid inadvertently getting code into GNU that could be claimed by copyright. Focus on speed instead of memory; simplicity instead of speed. I don't see "make it different for difference sake." I also conclude the opposite from the cat implementations. I really don't see how the BSD cat is a more…

"If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can’t write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the Unix version irrelevant and dissimilar to your results. "

on it's own, not intentionally obfuscating. but when the naive implementation is straightforward and the only clear cut way, and everything else involves abstracting something, then yes.

see also the 'yes' example from the other thread:

https://github.com/coreutils/coreutils/blob/master/src/yes.c https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c

Really, my main beef is the suppression of history and misrepresentation of a broader culture as 'proprietary' to serve RMS's political aims, whereas in the actual Usenet/BSD culture, it quite simply wasn't. Unix wasn't just AT&T, it was the community around it as well, which lives on in the BSD's with a clear lineage and 'cultural context' which is also truly open source and built around software freedom, but the promotion of GNU devoid of context obscures this fact.

Re: Decoded: GNU Coreutils

#22

Post by cat199 »

serhart wrote: post #8
cat199 wrote: post #6

Earlier quoted context omitted.

Did I? "This resource is for novice programmers exploring the design of command-line utilities. It is best used as an accompaniment providing useful background while reading the source code of the utility you may be interested in. " ^ "best used as an accompaniment" I posit that GNUs intentionally obfuscated code design[1]^ requires the use of such a site, whereas, reading the originals and their decedents, provides…

I'm pretty curious on how you conclude that GNU is "intentionally obfuscating code" from [1]. I read [1] as good advice to avoid inadvertently getting code into GNU that could be claimed by copyright. Focus on speed instead of memory; simplicity instead of speed. I don't see "make it different for difference sake." I also conclude the opposite from the cat implementations. I really don't see how the BSD cat is a more…

> I find the GNU cat to have way more options and easier to read source code. My guess is that novice programmers would find the GNU version easier to grok, which also probably aligns more to the goal of GNU.

Perhaps, but, also, on a source based unix system (i argue the only real unix system, since this is what unix was from the v5 research days, and continued to be for source license holders through the dawn of PC-BSD and then in open-source BSD onwards), one can do something like this:

    $ which ls
    /bin/ls
    $ man ls > /dev/null # output hidden for example purposes
    $ ls /usr/src/bin/ls     
    CVS      cmp.c    ls.1     ls.h     obj      utf8.c
    Makefile extern.h ls.c     main.c   print.c  util.c
    $ grep include /usr/src/bin/ls/ls.c |sed -ne 2p     
    #include 
    $ ls /usr/src/sys/sys/stat.h                                              
    /usr/src/sys/sys/stat.h
    $ grep ^sys_statfs /usr/src/sys/kern/*.c    
    /usr/src/sys/kern/vfs_syscalls.c:sys_statfs(struct proc *p, void *v, register_t *retval)
    $ less /usr/src/sys/kern/vfs_syscalls.c  # oh so that's how it works in the kernel..
    $ (cd /usr/src/bin/ls && cp ls ls.c.orig && $EDITOR ls.c && make && make install && ls -Q)  # yay! my new option -Q works
    $ (cd /usr/src/bin/ls && diff -urw ls.c.orig ls.c |Mail -s 'new patch' developers@some-mailing-list.org)
whereas, for example, on a binary package based linux or proprietary UNIX, this would entail either separate download of N different tools and disparate compilation steps in the former, or not being able to do it in the latter. While there is nothing constraining a linux or proprietary unix from being made available in such a way, they quite simply arent, and the 'culture' and concept of having a single binary+source+documentation tree which is fully self hosting with a single build system managing the build combined as a single unit as 'what the unix system is' is lost..

Re: Decoded: GNU Coreutils

#24

Post by AstroJetson »

Interesting project, this would make a good teaching tool for people interested in more operating system interaction.

On the website it would be nice if you had a way to flag which ones were fully annotated. But I like the main page design. The block graphics on the flow is very helpful.

You've done some very nice work here.

Re: Decoded: GNU Coreutils

#25

Post by SamuelAdams »

AstroJetson wrote: post #24

Interesting project, this would make a good teaching tool for people interested in more operating system interaction. On the website it would be nice if you had a way to flag which ones were fully annotated. But I like the main page design. The block graphics on the flow is very helpful. You've done some very nice work here.

Agreed, this would be very beneficial to students and people learning C.

Re: Decoded: GNU Coreutils

#26

Post by Tepix »

Super interesting. I had a brief look at "head" and "df" and the flows seem to be complete.

The flow for "tr" is not completely right given that the second parameter ("string2") is optional with certain options.

The text for "yes" mentions how it fills a buffer with multiple copies of the string to achieve its very high performance. Nice!

Re: Decoded: GNU Coreutils

#27

Post by yodon »

Tepix wrote: post #26

Super interesting. I had a brief look at "head" and "df" and the flows seem to be complete. The flow for "tr" is not completely right given that the second parameter ("string2") is optional with certain options. The text for "yes" mentions how it fills a buffer with multiple copies of the string to achieve its very high performance. Nice!

Reminds me of a time at a large animation studio where I was working on performance issues with the in-house asset management system.

The asset management tool was fully commandline based, no GUI. An artist showed me what was involved in committing their scene: launch the command, type yes, hit return, wait about 30 seconds, type yes, hit return, repeat. I piped yes to stdin and it ran for 47 hours.

If you need a performance-optimized version of "yes" there are probably other aspects of your architecture you should look at first.

Re: Decoded: GNU Coreutils

#29

Post by ape4 »

Rather than a flow chart, etc. It would better to convert the utilities to simple C with no error handling or optimization. So `cat` would be about 5 lines. No mmap() or fancy stuff.

Re: Decoded: GNU Coreutils

#30

Post by masklinn »

yodon wrote: post #27
Tepix wrote: post #26

Super interesting. I had a brief look at "head" and "df" and the flows seem to be complete. The flow for "tr" is not completely right given that the second parameter ("string2") is optional with certain options. The text for "yes" mentions how it fills a buffer with multiple copies of the string to achieve its very high performance. Nice!

Reminds me of a time at a large animation studio where I was working on performance issues with the in-house asset management system. The asset management tool was fully commandline based, no GUI. An artist showed me what was involved in committing their scene: launch the command, type yes, hit return, wait about 30 seconds, type yes, hit return, repeat. I piped yes to stdin and it ran for 47 hours. If you need a per…

yes(1) takes a custom "expletive", so in the performance context it's usually used for flood filling in situations where e.g. /dev/zero or /dev/urandom are not appropriate sources for some reason.
Post reply on HN