Interesting links for 2020-03-03.

  • The situation with Go on OpenBSD: I'm not interested in Go itself, but I've read similar things about Rust on the *BSD. It's sad that such platform is a second class citizen for newer, compiled languages.
  • Facebook's Download-Your-Data Tool Is Incomplete: Ok, first of all, delete your Facebook account (even if they still create a "dark profile" of you). Second, with GDPR laws coming in full force (like the California Privacy Law and the Brazilian version of GDPR, LGPD), it's amazing to see that companies built on collecting everything about you still fail to get in line.
  • On C and embedded platforms: Although focused on embedded devices (which the post itself claims is a lot larger and more limited than a Raspberry), it gives a long explanation about the way C source is turned into an executable (and I may need some points of this for a presentation called "The Secret Life of the Linker").
  • 42 Unique Productivity Tips: How to be more Productive with Less Effort: Weirdly enough, I think I do half of those already, but I still don't think I'm as productive as I should. Also, some points seem incomplete, like the "Biological Prime Time", which lacks information on how you figure out your BPT. On the other hand, "Create a Todon’t List" is something I never thought before!
  • Windows 93: Have some time to play with something stupid? Someone built a "remixed" version of Windows 95 with HTML+CSS+JS.
  • fork() can fail: this is important: Yes, fork() can fail and you should check for failures; also yes, malloc() can fail and you should check for failures. And this reminds me of Rust Result (which you can also use in Haskell) and the fact that the compiler does not let you get away from ignoring the errors. More languages should be built like this.
  • Production Oriented Development: 1 Ok, it's DevOps, but let's talk about this again for the people in the back. The only point that I need to point that one should be careful about is "Buy Almost Always Beats Build": Sure, buying a done product is better than a will-be product, but it may also force something akin to the use of Design Patterns: changing the (real) problem to make it fit the pattern or, in this case, changing the real problem to fit the tool.
  • Vim plugins that I use: A list of VIM plugins. I have my fair share of plugins installed, but HOLY COW, that's too much even for me.


I think I shared this on Mastodon before, but I realized there is one small point that needs some clarification.