You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
82 lines
3.4 KiB
82 lines
3.4 KiB
4 years ago
|
+++
|
||
|
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...
|
||
|
|