GNU Parallel Cheat Sheet [pdf] • Hacker News Board

Re: GNU Parallel Cheat Sheet [pdf]

#61

Post by mechanical_jane » Sat, Mar 09, 2019, 12:16 PM UTC

jwilk wrote: post #55

rurban wrote: post #32

Earlier quoted context omitted.

It was already forked in its early perl days, and thus it's very hard to use it properly as build tool, as the non-GNU version has an entirely different argument syntax. eg on macOS or BSD. You really have to probe for the GNU version (the more popular and newer one, with this awkward citation and begging), but for longer tasks it speeds up processing immensely. There's no need for Hadoop when you can use parallel. I…

Where can I read about this fork? Googling for "bsd parallel command" doesn't seem to show anything relevant.

If you are just looking for an alternative, GNU Parallel publishes a list of alternatives: https://www.gnu.org/software/parallel/parallel_alternatives....

Re: GNU Parallel Cheat Sheet [pdf]

#62

Post by rurban » Sat, Mar 09, 2019, 6:58 PM UTC

jwilk wrote: post #58

rurban wrote: post #57

Earlier quoted context omitted.

Mixed it up. It was from moreutils, not bsd. My configure.ac recipe for the proper parallel is this, setting logs_all to the GNU parallel version. dnl GNU parallel, skip the old non-perl version from moreutils so far AC_CHECK_PROGS([PARALLEL], [parallel]) logs_all=logs-all-serial.sh.in if test -n "$PARALLEL"; then AC_MSG_CHECKING([PARALLEL version]) parallel_version=`$PARALLEL --version 2>&1 | head -n1 | cut -c14-` c…

For the avoidance of doubt, moreutils' parallel is not a fork of GNU parallel. They are independent implementations.

Not really independent. Ole Tange tried to get his 2nd parallel into findutils (to replace xargs and allow parallel processing) in 2005. Because it was written in Perl, findutils refused to add it. So Ole Tange contacted moreutils in 2009, but they never answered, but later one guy of them, Tollef Fog Heen, rewrote parallel in C, with just minor API discrepancies. They say it predates GNU parallel, because the 2005-2007 package was not a GNU project then. It was added to savannah as individual GNU project in 2010, Ole gave up inclusion into findutils then.

moreutils parallel was written 2008, and added to moreutils 2009, just when Ole asked them. https://git.joeyh.name/index.cgi/moreutils.git/commit/?id=0f...

https://www.gnu.org/software/parallel/history.html

Hence I called it a "fork". Independent, yes, but when you know about the project, steal its name and put it into wide distribution under that same name, because you think your name has a better chance of being adopted, this is called a fork. Like a pitchfork. Poking into the original authors eyes with a sharp instrument.

Re: GNU Parallel Cheat Sheet [pdf]

#63

Post by musicale » Thu, Mar 21, 2019, 11:37 PM UTC

jwilk wrote: post #56

musicale wrote: post #46

Earlier quoted context omitted.

Beyond being supremely irritating, nagware is simply not scalable. Imagine if every utility, library, or driver in a typical Linux distribution took this approach. :( I encourage Debian et al. to adopt a "no nagware" policy.

There's something similar in Debian Policy §2.3 ( https://www.debian.org/doc/debian-policy/ch-archive.html#cop... ): > Programs whose authors encourage the user to make donations are fine for the main distribution, provided that the authors do not claim that not donating is immoral, unethical, illegal or something similar; in such a case they must go in non-free. BTW, the nagware code has been removed in Debian unsta…

It's about time! In addition to my "it's annoying and simply not scalable" comment, the bug discussion brings up some additional compelling points:

1. It included a click-wrap agreement in violation of the Debian Free Software Guidelines.

2. Fishing for inappropriate citations should not be encouraged, as it compromises the integrity of scholarship.

Re: GNU Parallel Cheat Sheet [pdf]

#64

Post by musicale » Fri, Mar 22, 2019, 12:02 AM UTC

mechanical_jane wrote: post #49

musicale wrote: post #46

Earlier quoted context omitted.

Beyond being supremely irritating, nagware is simply not scalable. Imagine if every utility, library, or driver in a typical Linux distribution took this approach. :( I encourage Debian et al. to adopt a "no nagware" policy.

I am trying to understand your take. Do you also call Firefox nagware, when it pops up with a dialog box where you can click "Don't show this again"? To me the dialog box is actually worse, because the program often blocks until you close the dialog box (not 100% sure if that is the case with Firefox). With GNU Parallel you run 'parallel --citation' once, and you are done. We are talking an effort of 15 seconds or le…

Nagware is irritating and simply not scalable.

At least with web browsers they are user-facing and you only have a few of them to deal with.

I never choose parallel intentionally, but I still encounter the nagware messages in the output of scripts that other people wrote. And disabling the nagware message on my laptop doesn't disable it in a container, in the cloud, etc.. It's very annoying.

Wasting 15 seconds of human time certainly isn't scalable over dozens or hundreds of utilities. And applying the Steve Jobs computation[1], 15 seconds * 1 million users = nearly six months of wasted human lifetime.

Fortunately Debian-unstable seems to have fixed the issue by removing the nag message (which violates the DFSG). With luck this will propagate into mainline and into all of the downstream distributions like Ubuntu.

[1] https://www.folklore.org/StoryView.py?story=Saving_Lives.txt