blog/content/links/20200601.md

+++
title = "Links for 2020-06-01"
date = 2020-06-01

[taxonomies]
tags = ["links", "distributed", "c", "rust", "protection", "no code",
"android", "research", "blog", "contact tracing", "privacy"]
+++

Distributed Systems, C in Rust, Protecting Projects, No Code, Android,
Research Blog, Contact Tracing and Privacy (again).

<!-- more -->

## [Notes on Distributed Systems for Young Bloods](https://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/)

A bunch of "things you need to remember when working on distributed systems",
not only for "young bloods", but also for those who are doing this for
sometime, just as a reminder.

## [writing c library in rust](https://www.ultrasaurus.com/2020/01/writing-c-library-in-rust/)

One of the cool things about Rust is that you can combine Rust applications
with any other C library. But not only that, it is also possible to write code
in Rust and export it as a C interface -- and, with that, combine with any
other language that can bind with C, which are basically every language around.

## [Self-Protecting Projects](https://amihaiemil.com/2020/01/17/self-protecting-projects.html)

Projects without a CI/CD pipeline are doomed to fail.

That's basically the gist of the post and I'm all for it too. There are a few
missing bits, like you can have a CI/CD pipeline and not having a policy for
writing tests; but, at the same time, I reckon there is no easy way to measure
if the proper things are being tested (and no, "every single function" is not
a measure).

Also, the idea of making the application open tickets every time the
application crashes is cool and all, but that only works for applications that
run on your own environment -- an embedded application would have a hard time
making this.

## [Why I Keep a Research Blog](http://gregorygundersen.com/blog/2020/01/12/why-research-blog/)

I've been thinking about this for some time: I have a list of "Things I Don't
Know", which I keep on [Joplin](https://joplinapp.org/). The idea is that,
when I have some time, or when I see some information related to the topic, I
can add to the note, till I finally feel confident enough to say "Ok, now I
understand this".

But for some time I've been writing this kind of post (the
"[Links](https://blog.juliobiason.me/tags/links/)" ones) as a way to keep a
list of things that I feel I may need in the future. So, if I keep a list of
"maybe in the future" links, why don't I put the research topics also in this
blog? Surely, right now, it will have only the topics and no content (sorry!)
but making it available may also help someone else.

There is one point that one could make: If I share links, why not share links
related to those topics, and let the blog engine worry about grouping them?
The point is actually to write whatever I learnt in my own words, 'cause those
are easier to recall in the future.

I'm still wrangling with the idea, though. No promises.

## [Minnesota is now using contact tracing to track protestors, as demonstrations escalate](https://bgr.com/2020/05/30/minnesota-protest-contact-tracing-used-to-track-demonstrators/)

You may recall that I've been, for a while, mentioning that contact tracing
applications may sound good to find someone that had contact with another
someone with COVID-19 (so we could alert and/or take that person to a
hospital, before it was too late for treatment), but there were serious
privacy problems with it? Well, there we go.

A black person was brutally killed by the police in the USA, and the community
rioted to the point that a police department was set afire -- I'm not saying
it was right or wrong, but you have to think the type of indignation that make
people set a _police department_ on fire.

And those people who worried that they may get in contact with someone that
got infected with COVID-19 and installed any contact tracing application are
now being tracked by their association with other demonstrators.

And _that's_ what I was talking about. There is no policy that says "this
tracing information may be _only_ used for diseases and nothing else".

## [The 'No Code' Delusion](https://www.alexhudson.com/2020/01/13/the-no-code-delusion/)

Ignoring the fact that the post talks about a movement for "creating
business rules without the need of a developer", what I found interesting is
the visual comparison of the business rule (in a diagram) and the code (a
piece of Python code). Why? Because that's exactly the way applications should
be written: There is logic and it is described in a combination of functions,
which content doesn't make part of the rule itself and there are no rules
"hidden" inside the function of a rule. There is nothing of "let me put a
regexp here to validate the email". That's not what the business rule says, so
that's not in the code. If the business rule said "You should test this,
convert to that and send this to there", that's exactly what the function
should have.

On the other hand, I didn't realized that diagrams require some previous
knowledge: Which symbol represents a test? Which symbol represents "white in
the screen"? And so on.

What I need to mention, though, is that COBOL was created for non-programmers
so they could describe business rules and run them; SQL was desgiedn so
non-programmers could describe how to retrieve and process data; BDD has
always been described as a way for non-programmers to describe how a system
should be validated.

## [Google pushed to take action against Android bloatware by 50+ organizations](https://9to5google.com/2020/01/11/android-bloatware-privacy-open-letter/#adnrb=900000)

A post from earlier this year, but there is one point that I need to bring:

Android is "open source", right? If it is, why doesn't those 50+ organizations
just fork it and make their own Android? Surely, in a 50+ organization group,
there should be a few developers and making them all work on that could solve
the problem, right?

Well, thing is, Google controls Android. You can't simply fork and hope that
you can run on your device. You can't simply make a pull request and hope it
will, one day, be part of the system.

"Android is opensource" is a farce. It is "source available", not "open
source" by any stretch of imagination.

---

This post was built with the help of

* [HN Tooter](https://mastodon.social/@hntooter)
* [Read Rust](https://botsin.space/@readrust)