wallstprog

The "MQ" part of the name is unfortunate, but apparently came about because of the original idea to come up with a "better" implementation of AMQP (http://zeromq.org/docs:welcome-from-amqp).

But you're right -- ZeroMQ doesn't do queueing (except in some very limited circumstances), and if you need reliable delivery you must implement that yourself "on top of" ZeroMQ. I've done that, and while it's not a simple task, it is certainly possible.

You can get reliable delivery "out of the box" with other software, that in fact does do queueing. (kafka may be one, but I don't know enough to say).

But what you give up when you do that is performance -- ZeroMQ can easily be orders of magnitude faster than those other solutions, and for some applications (e.g., real-time market data) the work to provide a custom reliability solution on top of ZeroMQ is worthwhile.

I use Markdown and find it quite useful, even with its problems (which the article does a good job of describing -- the main one being "The nice thing about standards is that there are so many to choose from".)

Apropos of GitHub pages (which I use to host my blog), are you aware that it is possible to generate HTML locally from Markdown, and then publish the generated HTML? FWIW, Octopress (http://octopress.org/docs/deploying/github/) does this (I didn't even realize at first that was what was happening), and that happily insulates you from any changes in GitHub's Markdown support -- as long as your local toolchain remains consistent, content should be rendered the same.

Obligatory link to Drepper's classics:

https://akkadia.org/drepper/no_static_linking.html

https://www.akkadia.org/drepper/dsohowto.pdf

Seems like the Plan 9 guys haven't heard of these? If done properly, dynamic linking is almost always better than static -- key word here is "properly", which doesn't always/often happen.

My two cents, fwiw: http://btorpey.github.io/blog/2014/09/23/into-the-void/

Nice article!

If you're interested in clocks on Linux, you might also find this article useful (shameless plug): http://btorpey.github.io/blog/2014/02/18/clock-sources-in-li...

One thing it seems no one has mentioned in the Linux vs. MacOS flamewar is that Linux is ugly, while MacOS, while maybe not beautiful, is inoffensive at worst and elegant at best.

I use Linux and Mac almost equally and for CLI apps I'm pretty happy with either one (although Mac is a bit better), but for GUI applications I'll go with Mac every time.

If you have to stare at something all day, the esthetics of it become important.

> No app store or repostiory on the mac does as well.

Homebrew?

On a related note: http://btorpey.github.io/blog/2017/05/10/join/

The author is correct that trying to get modern toolchains on older systems (like RH6) is a real pain. But sometimes there's no real choice -- some applications value reliability above all else, and tend to be deployed on RH where its relative stability is a feature, not a bug.

I've written about this (http://btorpey.github.io/blog/2015/01/02/building-clang/), specifically in the context of getting clang running on RH6, which required first getting a C++11-compatible gcc running on RH6. For those who are in the same boat, you may find the article helpful.

Interestingly, William Gibson includes something very much like this as a plot point at the end of "Zero History."

At the risk of being labeled a dinosaur, this is still prob. the best book I ever read on structuring code:

https://www.amazon.com/Reliable-Software-Through-Composite-D...

If you're interested in static analysis, you may find this series of articles useful: http://btorpey.github.io/blog/2016/11/12/even-mo-static/.

FWIW, I did not see a lot of false positives in the tests I did with clang. On the contrary, I would say that clang tends to be rather conservative, and doesn't report warnings unless they are almost certainly bugs.

I'd certainly be interested in what others think -- if so inclined please leave a comment on the article, or email me directly.

Thanks for pointing that out! I should have mentioned that in the article, and in fact I do much of this type of work on my MacBook.

Hmmm...that might be a good topic for another article.

In the meantime, here are a few packages you can install using HomeBrew (brew install <package>) that help bridge the gap between Mac and Linux for other tools:

bash binutils coreutils gawk gnu-sed gnuplot

Glad you liked it! Like I said in the article, I continue to be amazed at the things you can do with a simple bash prompt.

Interesting comment -- thanks for that.

It also reminds me of one of my favorite aphorisms: "Perfect is the enemy of good enough".

What some other commenters appear to have missed is the use case I'm discussing here: scraping log files to generate text files to feed to gnuplot.

And while the approach presented here may not work at Google scale, it works just fine for my situation. It takes me about 10 minutes on my MacBook to churn through around 50GB of logs to produce a few dozen charts. It took about a week to put the scripts together, and now anybody on my team with a shell prompt can do the same thing (including the QA folks).

Sometimes you need to dot all the i's and cross all the t's, but sometimes it's just about getting the job done quickly, with minimal dependencies.

Like I said above, the title is bit of a joke, and a tease.

If you read my blog, you'll see that I try to keep things light. (No cat pictures, though -- at least not yet ;-)

Having said that, the description in the header is "Data manipulation with plain text files". Maybe I'll see if I can find a way to show that on GitHub ...

Umm, the title was meant to be, like, a joke?

Agreed -- if you can't explain why "that's the way we do it here", then that's a problem.

On the contrary, that is a very good reason, and sometimes the only one that matters.

In any group of "n" developers there are likely to be "n+m" different ways to do the same thing. This increases the "cognitive load" to understand others' code (a fancy way of saying it makes the code hard to understand).

Personal preference is not a valid reason to eschew standards, even (especially) de-facto ones.

If there is a "better" way to accomplish a particular task, then the entire team should adopt it (and go back and change existing code to conform to the "better" approach). If that's not worth doing, then leave well-enough alone. (Another way of saying "If it ain't broke, don't fix it").

"Those who refuse to study history are condemned to repeat it"

People like Jim Gray, Mike Stonebraker, et al. were/are not dummies.

You'd be surprised (or maybe not ;-) how often a hiring mgr copies and pastes from some other job description he saw somewhere else.

The one tool I wouldn't want to live without is BeyondCompare (http://scootersoftware.com/)

A couple of good resources:

https://blog.codinghorror.com/coding-horror-the-book/

http://www.aristeia.com/authorAdvice.html