3 ms·

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 int

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 "pure" or straight forward implementation. 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. Or I just like to read obfuscated code.

ggm 7y ago
I really don't see how the BSD cat is a more "pure" or straight forward implementation. I find the GNU cat to have way more options Way more options is "cat -v considered harmful" not thought any more?
- serhart 7y ago
  If you aren't trying to be Unix I would imagine you aren't thinking that. GNU probably doesn't subscribe to that notion.
cat199 7y ago
"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/coreutils/coreutils/blob/master/src/yes.c https://github.com/openbsd/src/blob/master/usr.bin/yes/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.
cat199 7y ago
> 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 <sys/stat.h> $ 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..

ggm 7y ago

I really don't see how the BSD cat is a more "pure" or straight forward implementation. I find the GNU cat to have way more options Way more options is "cat -v considered harmful" not thought any more?

serhart 7y ago
If you aren't trying to be Unix I would imagine you aren't thinking that. GNU probably doesn't subscribe to that notion.

cat199 7y ago

"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/coreutils/coreutils/blob/master/src/yes.c https://github.com/openbsd/src/blob/master/usr.bin/yes/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.

cat199 7y ago

> 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 <sys/stat.h> $ 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..