4.7 KiB
+++ title = "Commented Links for 2020-06-20" 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.
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
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
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
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
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
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
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
.