+++
title = "Commented Links for 2020-07-19"
date = 2020-07-19

[taxonomies]
tags = ["links", "unix", "build", "c", "data structures", "algorithms", "zig",
"rust", "linux", "kernel", "ai", "git", "git ignore", "ci", "cd"]
+++

Building Executables Unix Way, Really Used Data Structures and Algorithms, Zig
Foundation, Rust on Linux, Bad AI, Git Ignore, What is CI and CD.

<!-- more -->

## [Traditional Unix Toolchains](https://bsdimp.blogspot.com/2020/07/traditional-unix-toolchains.html?m=1)

While the title may give some impression that it will talk about common unix
tools (and pipes, and `&&` and `||`), it actually talks about the process the
unix compilers take on converting your C code into an executable.

It is a bit succinct, but succinct in the right places. It gives a good
explanation on the whole process, the involved tools and their jobs in the
process.

## [Data Structures & Algorithms I Actually Used Working at Tech Companies](https://blog.pragmaticengineer.com/data-structures-and-algorithms-i-actually-used-day-to-day/)

When doing job interviews, we get asked about a lot of stuff. But what do we
_actually_ use? Kinda reminds of that joke about the job interview asking to
invert a binary tree and the job is just to move a button 2 pixels to the
left.

But it is good to know what is actually useful, in real life applications. And
not just some CRUD or whatever, but what goes into Skype and Uber.

## [Announcing the Zig Software Foundation](https://ziglang.org/news/announcing-zig-software-foundation.html)

Zig is a small language aimed to fix the problems with C.

What impressed me here is that the Rust community had talks about making a
foundation, so the language would be open to everyone, but still didn't manage
to make it.

So, kuds to Zig developers for creating their foundation!

## [Linux kernel in-tree Rust support](https://lkml.org/lkml/2020/7/10/1261)

Alright, so it seems the Linux developers finally opened to doors to new
languages in their tree.

What feels "wrong" here is that Linus is saying that "Rust support" should
always be up, so if something breaks, they can point that it was broken
anyway. The "wrong" part is that this, obviously, puts visibility on things
that _don't_ work instead of focusing on the things that _do_ work. What if
there are a couple of modules working fine, but only one fails? Obviously
everybody will point out that the support _doesn't_ work and people should
stick with what still works.

But Linus, you know...

## [Awful AI](https://github.com/daviddao/awful-ai)

Not every AI is good. Not every AI will help you find an open spot for that
meeting with everyone. Not every AI will tag your photos with locations and
loved one -- but they would tag any black people as "gorillas". Or maybe say
who may be gay or not (and think how those people would be affected on
countries that see homosexuality as a crime). The list goes on and on.

## [gitignore.io](https://www.toptal.com/developers/gitignore)

Create a comprehensive `.gitignore` for your project, based on your language
and tools.

## [The real difference between CI and CD](https://fire.ci/blog/the-difference-between-ci-and-cd/)

What does CI and CD do? What they are there for?

I've been thinking about doing a presentation for people starting with in
development about each of those -- 'cause, you know, there are a bunch of
people still thinking `git push` on your computer and `git pull` on the
production server is a good decision...