News for hackers. Stuff that matters.
Re:Shell Script Best Practices, from a decade of scripting t... by foobarian on Thursday October 27, 2022 @10:34AM (#33358087)
> while somebody comfortable is shell writes a parallelized one liner, rips through GBs of data, and delivers the answer in 15 minutes.

This also works up to a point where those GBs turn into hundreds of GBs, or even PBs, and a proper distributed setup can return results in seconds.

Re:Shell Script Best Practices, from a decade of scripting t... by ekianjo on Thursday October 27, 2022 @10:37AM (#33358141)
usually you use specific frameworks for that, not pure Python.
Re:Shell Script Best Practices, from a decade of scripting t... by foobarian on Thursday October 27, 2022 @10:40AM (#33358199)
I suppose the Python side is a strawman then - who would do that for a small dataset that fits on a machine? Or have I been using shell for too long :-)
Re:Shell Script Best Practices, from a decade of scripting t... by ekianjo on Sunday October 30, 2022 @09:01AM (#33394115)
I thought the above comment was about datasets that do not fit on ones machine?
Re:Shell Script Best Practices, from a decade of scripting t... by snidane on Thursday October 27, 2022 @11:21AM (#33358914)
That's a hardware management question. The optimized binary used in my shell script still runs orders of magnitude faster and cheaper if you orchestrate 100 machines for it than any Hadoop, Spark, Beam, Snowflake, Redshift, Bigquery or what have you.

That's not to say I'd do everything in shell. Most stuff fits well into SQl, but when it comes to optimizing processing over TB or PB scale, you won't beat shell+massive hw orchestration.

Re:Shell Script Best Practices, from a decade of scripting t... by henrydark on Thursday October 27, 2022 @01:42PM (#33361189)
I often find that downloading lots of data from s3 using `xargs aws sync`, and then xargs on some crunching pipeline, is much faster than a 100 core spark cluster