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`.
