diff --git a/content/links/20200620.md b/content/links/20200620.md
new file mode 100644
index 0000000..e16bc68
--- /dev/null
+++ b/content/links/20200620.md
@@ -0,0 +1,100 @@
++++
+title = "Commented Links for 2020-06-19"
+date = 2020-06-20
+
+[taxonomies]
+tags = ["links", "sigsegv", "segmentation fault", "activitypub", "conference",
+"git", "names", "branches", "rust", "ecosystem", "cli", "design", "scp"]
++++
+
+SIGSEGV, ActivityPub Conf, Git Branch Names, Rust Ecosystem, Learning Rust
+with CLI, Design Problems, SCP.
+
+<!-- more -->
+
+## [Why is there a "V" in SIGSEGV Segmentation Fault?](https://blog.cloudflare.com/why-is-there-a-v-in-sigsegv-segmentation-fault/)
+
+A little bit of UNIX/POSIX based-operating systemas -- and something that
+never actually made me wonder what it meant, specially considering the names
+of the other interruptions and some internal commands (`creat`, for example).
+
+## [ActivityPub Conference 2020](https://conf.activitypub.rocks/#home)
+
+Ok, it is a bit early for this -- the CFP just opened -- but as a fan of what
+ActivityPub proposes to solve, I must share this: A conference related to the
+discussion of the protocol and its tools (well, I _guess_ that the topic,
+anyway).
+
+Stay tuned for the selected talks in the future.
+
+## [On Git branch naming](http://meta.ath0.com/2020/06/git-branch-naming/)
+
+The change of Git main branch name to something that is not "master" generated
+some discussion online, even with the major Git services (Github, for example)
+already announced that new repositories will get new names.
+
+There is a problem with the meaning of the name and what it represents to a
+significant part of the world population, but what the post shows is that even
+if you ignore that, the name "master" makes no sense in the Git architecture;
+it is based on the name used by BitKeeper, which had the master/slave
+architecture, which Git _does not_ have.
+
+And yes, I do agree with all the answers there. And: If it is a simple change,
+won't break anything, and oppressed groups (in the past or present) don't get
+offended, why not?
+
+There is another point thought: Git is distributed, right? This means it has
+not a central server; every installation is the central of itself. The same
+goes for its branches, though: Every branch is a copy in itself and you don't
+_have_ to put them all in the same basket at some point, e.g., merging back to
+the main branch, because there is no _main_ branch. It is just a name and
+doesn't hold any special functionality compared to other branches.
+
+## [Understanding the Rust Ecosystem](https://joeprevite.com/rust-lang-ecosystem)
+
+I tend to mention that "languages do not exist in a vacuum", and by that I
+mean that you must not look only at some programming language or just a small
+piece of it, but the whole; how is the ecosystem for this thing?
+
+And, for Rust, it felt always a vibrant system, with all its weirdness and
+coolness. And this post goes one step further showing most of the things going
+around, from platforms, to forums, to meetups, to companies using the
+language, to famous tools.
+
+## [Diving into Rust with a CLI](https://kbknapp.dev/rust-cli/)
+
+Speaking of Rust, Kevin K wrote this post about a command line tool to
+download the XKCD comics. But instead of building the most simple solution for
+it, he used the most known libraries for specific points (explaining why he
+picked some) and showing a complete final solution.
+
+I'm writing some other command line tool in Rust to explore more the language, and the current result is not even near the niceness of what is shown here.
+
+## [Stop Blaming People: It’s a Design Problem](https://quinnkeast.com/writing/stop-blaming-people-its-a-design-problem/)
+
+Developers are famous for not being able to design a button in the right way
+or making it too damn hard to use the damn button -- or, in worse cases,
+building an interface so cluttered with options that it is basically
+impossible to use the application.
+
+But it is not just the software world that suffers from that: the fire in the
+Notre Dame Cathedral could be prevented if the interface didn't use some
+indirect information; the ballistic missile warning in Hawaii wouldn't have
+happened if the interface for the alarm wasn't so simplistic. And so on.
+
+Sometimes it is necessary to think a bit more about how the service will be
+used instead of making things complex (or too simplistic).
+
+## [SCP - Familiar, Simple, Insecure, and Slow](https://gravitational.com/blog/scp-familiar-simple-insecure-slow/)
+
+I already knew SCp was slow, but I wasn't sure how slow. What impressed me
+most in the post is this line here:
+
+```
+tar cf - /tmp/big_folder | ssh server 'tar xC /tmp/ -f -'
+```
+
+Basically, using `tar` to get the content of several files and turn it in a
+single sequence of bytes, send it through stdout to ssh and, there, run `tar`
+to undo the sequence (making them back into files). Curious, and potentially
+4x faster than copying files directly through `scp`.
diff --git a/content/links/20200620.pt.md b/content/links/20200620.pt.md
new file mode 100644
index 0000000..3d90be5
--- /dev/null
+++ b/content/links/20200620.pt.md
@@ -0,0 +1,109 @@
++++
+title = "Links Comentados de 2020-06-19"
+date = 2020-06-20
+
+[taxonomies]
+tags = ["links", "sigsegv", "segmentation fault", "activitypub",
+"conferência", "git", "branches", "nomes", "rust", "eco-sistema", 
+"linha de comando", "design", "scp"]
++++
+
+SIGSEGV, Conferência de ActivityPub, Nomes de Branches no Git, O Eco-Sistema
+do Rust, Apredendo Rust com Linha de Comando, Problemas de Design, SCP.
+
+<!-- more -->
+
+## [Why is there a "V" in SIGSEGV Segmentation Fault?](https://blog.cloudflare.com/why-is-there-a-v-in-sigsegv-segmentation-fault/)
+
+Um pouco de história dos sistemas operacionais baseados em UNIX/POSIX -- e
+algo que eu nunca me preocupei realmente, principalmente considerando os nomes
+das outras interrupções e alguns comandos do sistema (`creat`, por exemplo).
+
+## [ActivityPub Conference 2020](https://conf.activitypub.rocks/#home)
+
+Eu sei que ainda é cedo para conversar sobre isso -- o "call for papers"
+acabou de abrir -- mas como fã do que o ActivityPub se propõe a solucionar, eu
+tenho que compartilhar: Uma conferência baseada na discussão do protocolo e as
+ferramentas (bom, eu _acho_ que é sobre isso, de qualquer forma).
+
+Fiquem ligados para a lista de talks no futuro.
+
+## [On Git branch naming](http://meta.ath0.com/2020/06/git-branch-naming/)
+
+A troca do nome do branch principal do Git para algo que não seja "master" tem
+dado alguma discussão por aí, mesmo com grandes representantes de Git (Github,
+por exemplo) já terem anunciado que o nome vai mudar em novos repositórios.
+
+Existe sim uma questão sobre o significado do nome e o que ele representa para
+um grupo significativo da população do mundo, mas o que o post mostra é que
+mesmo ignorando isso, o nome "master" faz sentido na arquitetura do Git; 
+ele é baseado no nome utilizado pelo BitKeeper, que tinha uma arquitetura
+mestre/servidor, que o Git _não_ copiou.
+
+E sim, eu concordo com todas as repostas apresentadas. E mais: Se é uma
+mudança simples, não vai quebrar nada, e vai fazer com que grupos oprimidos
+(no passado ou presente) não se sintam ofendidos, por que não?
+
+Mas tem mais um ponto: Git é distribuído, certo? Com isso, eu quero dizer que
+não existe um servidor principal; toda instalação do Git é o principal de si
+mesmo. O mesmo acontece com os branches: Todo branch é uma cópia auto contida
+e você _não precisa_ colocar todas elas no mesmo balaio em algum ponto, por
+exemplo, fazendo merge para o branch principal, porque _não existe_ um branch
+principal. É só um nome e ele não tem nenhuma funcionalidade especial
+comparado com outros branches.
+
+## [Understanding the Rust Ecosystem](https://joeprevite.com/rust-lang-ecosystem)
+
+Eu tenho falado que "linguagens não existem em um vácuo", e com isso eu quero
+dizer que você não pode focar somente na linguagem ou numa parte relacionada a
+ela, mas no todo; como é o eco-sistema dessa coisa?
+
+E Rust sempre me pareceu um sistema vibrante, com todas as suas esquisitices e
+legalzices. E esse post mostra boa parte do que existe no sistema, de
+plataformas, passando por forums, meetups, empresas que usam a linguagem e
+indo até as ferramentas mais famosas.
+
+## [Diving into Rust with a CLI](https://kbknapp.dev/rust-cli/)
+
+Falando em Rust, Kevin K escreveu esse post sobre criar uma ferramenta de
+linha de comando para baixar as tirinhas do XKCD. Mas ao invés de fazer isso
+da forma mais simples possível para mostrar a linguagem, ele usou as
+bibliotecas mais conhecidas para pontos específicos (explicando porque usou as
+mesmas) e mostrando uma aplicação final completa.
+
+Eu estou escrevendo uma outra ferramenta de linha de comando para aprender
+mais sobre Rust e não chega nem de perto com o resultado apresentado aqui.
+
+## [Stop Blaming People: It’s a Design Problem](https://quinnkeast.com/writing/stop-blaming-people-its-a-design-problem/)
+
+Programadores são famosos por não conseguir desenhar um botão de forma correta
+ou fazer com que seja extremamente complicado usar o maldito botão -- ou, em
+piores casos, construindo uma interface com tantas opções que é praticamente
+impossível usar a aplicação.
+
+Mas não é só no mundo do software que essas coisas acontecem: O incêndio da
+Catedral de Notre Dame poderia ter sido evitado se a interface não tivesse um
+design indireto; o alarme de míssil balístico no Havaí não teria acontecido se
+a interface para o alarme não fosse simplório. E assim por diante.
+
+Algumas vezes é preciso pensar um pouco mais sobre como o serviço vai ser
+usado ao invés de deixar as coisas complexas (ou muito simplórias).
+
+## [SCP - Familiar, Simple, Insecure, and Slow](https://gravitational.com/blog/scp-familiar-simple-insecure-slow/)
+
+Que o SCP era lento eu já sabia, mas não sabia o quanto. O que me impressionou
+do post foi essa linha aqui:
+
+```
+tar cf - /tmp/big_folder | ssh server 'tar xC /tmp/ -f -'
+```
+
+Basicamente, usando o `tar` para pegar o conteúdo de vários arquivos e
+transformar numa sequência de bytes, enviar pelo stdout para o ssh e, de lá,
+rodar o `tar` para desfazer a sequencia de bytes (transformando de volta em
+arquivos separados). Curioso, e potencialmente 4x mais rápido que copiar os
+arquivos diretamente por `scp`.
+
+<!-- 
+vim:spelllang=pt:
+-->