Michael Hausenblas

121 points
mh9 pic
Galway, Ireland

Michael is a Developer Advocate for Kubernetes and OpenShift at Red Hat where he helps appops to build and operate apps. His background is in large-scale data processing and container orchestration and he's experienced in advocacy and standardization at W3C and IETF. Before Red Hat, Michael worked at Mesosphere, MapR and in two research institutions in Ireland and Austria. He contributes to open source software incl. Kubernetes, speaks at conferences and user groups, and shares good practices around cloud native topics via blog posts and books.

Authored Content

Authored Comments

Thanks for you comment syrrim and believe it or not, Doug McIlroy himself commented on this via email. Below the verbatim message I received from him today:

> One commenter on your "Revisiting Unix philosphy" note missed the mark on why pipes.
> I wrote the following in reply, but balked when I was asked to register. I don't hide, least
> of all behind the walls of social media. You are welcome to pass it on.
> "Unix does it this way to save memory." I've never heard that one before.
> Piping certainly avoids the aggravation of allocating memory, cluttering programs with its name,
> and freeing it. Piping may also save memory bandwidth and latency. But saving memory per se
> has rarely, if ever, been the point.
> Nevertheless, your observation, "By operating in parallel, you only have to store a single line at a time,"
> is crucial. It allows one to interact with a pipeline in real time. And it allows a pipeline to provide nonstop
> service. Neither is possible in the no-IPC intermediate-file model.