Evan Klitzke writes about Linux internals and systems programming, including dd, linkers, stdout buffering, and uninterruptible sleep.
HN links it for explanatory systems posts like "The cult of dd" and "PATH_MAX Is Tricky", and lists it among favorite personal blogs.
And I find your comment to be a super-annoying combination of pedantic and mostly wrong. I'm not going to go through every example but just pick a few:
> > For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED).
> You can do that in Java (with byte arrays) or in Common Lisp, so what is the point here? It is not practice in Java, Lisp nor in C and C++.
C is a really old language with ancient libraries that are still widely used even though they are simply bad by modern standards. For that reason, I roll my eyes when people say something is not practice in C or talk about "sane" C libraries. A big part of working with C is dealing with ancient insanity.
You can make much stronger statements about what is idiomatic in Rust (and to some extent Java) simply because it's newer and more cohesive.
> > It's convenient to have fixed-size buffers for variable-size data (e.g. PATH_MAX) to avoid (re)allocation of growing buffers
> This is because OS/Kernel/filesystem guarantee path max size.
I think you've got that backwards. There's an advertised max path size because people wanted to stick paths in fixed-size buffers rather than deal with dynamic allocation. PATH_MAX is fairly arbitrary considering that there are certainly ways of creating and opening files which have paths exceeding that limit. I found this doc talking about this: https://eklitzke.org/path-max-is-tricky
> printf is not shipped…
I believe that when a file is mmap'd a page table is created for it in the . As you perform read/write on the file a fault loads the actual entries into that page table. As pages can be mapped they so too can be unmapped under pressure, without that falling back to swap (since it is already a file backed map, you wouldn't swap a file backed map to a different file after all).
There are a few relevant bits to this. You can MAP_POPULATE the file to prepopulate the entries and you can MAP_LOCKED to MAP_POPULATE + lock the pages in (unreliably). As mentioned in the man page for mmap MAP_LOCKED has some failure modes that you don't get with mlock.
https://www.man7.org/linux/man-pages/man2/mmap.2.html
I also found this page:
https://eklitzke.org/mlock-and-mlockall
Oh, and this: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/reference_guide/using_mlock_to_avoid_page_io
Julia Evans' blog is one of my favorites! It was a big inspiration for starting my own blog (https://andythemoron.com). I also love High Scalability and Dan Luu's blog which have been mentioned in other comments.
I "follow" several which are mostly defunct, but in terms of blogs that still feature active updates:
Evan Klitze's blog: lots of topics around Linux, C++, etc. https://eklitzke.org/
Sutter's Mill: lots of "state of the world" for C++, but also context, history, etc. https://herbsutter.com/
IT Hare: C++, game programming http://ithare.com/
The Erlangelist: Erlang/Elixir http://theerlangelist.com/
null program: lots of miscellaneous topics http://nullprogram.com/
Fluent C++: the name speaks for itself http://www.fluentcpp.com/
Another Programmer's Blog: Linux, C, C++, C#, MSSQL https://www.stev.org/
Gah, another one of those promotional posts about Rust.
More seriously, the large enough Noto Sans font with a hint of extra weight renders so gorgeous in Firefox (it's even bearable in Chrome!). I wish all webpages were as readable.
As for the content, well, going back to: https://eklitzke.org/c++-java-go-and-rust I think the problem of the author is that he doesn't realize it's possible to do much better than C++. Claiming Rusts' ownership and borrow checking is exactly equivalent to std::unique_ptr or that Rusts' concurrency support is comparable to std::thread betrays very deep nativity, misunderstanding or just a mindset that can't see beyond what C++ offers.
This is actually an incredibly frustrating thing -- when doing disk i/o, the process goes into an uninterruptible sleep state[0].
So if your shell is doing some tab completion that goes into an uninterruptible sleep, there's no escape sequence you can send it to cancel that operation.
Where I've seen this be the most vexing is in AWS if an EBS volume dies (surprisingly more frequent of an occurrence than you'd think!). It effectively prevents the machine from cleanly shutting down, and you wind up having to wait for the instance to be forcefully terminated.
[0] https://eklitzke.org/uninterruptible-sleep
Good addition! Here are some more:
https://ferd.ca
https://blog.filippo.io
https://lethain.com
http://movingpackets.net
https://www.integralist.co.uk
https://peter.bourgon.org/blog
https://engineering.linkedin.com/blog
https://begriffs.com
https://mijailovic.net
http://tatiyants.com
http://blog.pentestbegins.com (seems down right now?)
https://kalzumeus.com/archive
http://blog.stephenwolfram.com
https://paragonie.com/blog
https://www.filfre.net
https://brandur.org/articles
http://archagon.net
https://eklitzke.org
I guess I could go on forever…