[libre-riscv-dev] useful article on consensus

[Luke Kenneth Casson Leighton]

On Thu, Apr 25, 2019 at 7:53 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

> I found this article on consensus in Rust, and thought it might be useful
> to apply some of the principles to us as a project.
>
> http://smallcultfollowing.com/babysteps/blog/2019/04/19/aic-adventures-in-consensus/

this link i've also found extremely useful:
http://www.crnhq.org/12-Skills-Summary.aspx?rw=c

every time there is something... "wrong" (not the right word, you know
what i mean), i've found that carefully reading that document has an
identifying "speech / behaviour" snippet that matches closely with
what's "wrong" (again, definitely not the right word), and, in the
surrounding text has key insights and, crucially, has actions which,
if followed, would help correct the "error" (again, not the right
word).

it's a tool, then.

in the link you sent, jacob, a key insight caught my eye:
" I guess then that the trick is being sure that you’re trading the
right things. "

this is the major insight, to be driven by "why" - not what or even
how.  which is later emphasised with:
" then you realize that one of the design constraints you took as
inviolate isn’t, really, all that essential."

unlike "N.E.Other" project, we have some particularly tough
constraints that no commercial silicon company would ever remotely
consider inviolate, and no project that calls itself "open" (note i
said "open" not "libre") would consider, either.

i've already had people say "no thanks i don't wish to join because
the ethical focus of the charter is way too frickin scary". not in
those exact words, however they see the hatred and the "inconvenience"
that arises when you have to put your foot down and say, "no, i'm
really sorry, that's unethical", and they *don't want the
consequences*.

basically, they "just wanted to focus on the technology", and, sadly,
i have to say that that's exactly the kind of thinking that,
considering "everyone who works in technology" as a world-wide group,
has got us into the Tim Cook "we did it to ourselves" scenario [1] and
many other examples.

the ones that are particularly scary are how google employees who
stood up and organised walk-outs over unethical decisions are now
being hounded and ostracised.  one has quit, the other, their life is
now a living hell, at work.


unfortunately, what's very very difficult to grasp, here, about
setting an ethical goal is: there can *be* no compromises, period.
not a single one.  that is particularly challenging in a Western World
where people are brainwashed (not a good word, however it makes the
point) to believe that "Democracy" is a perfectly acceptable
decision-making process.

you see this in films where the bad guy says, "The means justify the
ends, son" and you know they're using that to justify blowing
something up that is going to kill 1eN people in order to "save"
1e(N^2).  hero steps in, blah blah, all ends well :)

the reason that there can be no compromises on an ethical goal is that
the means are *part of the goal*, and "ethical" is defined as "doing
good for someone whilst doing no harm TO ANYONE".  and it applies one
HUNDRED percent, NO exceptions.

therefore, if even *one* unethical decision is made, the entire
project - everything you've done up until that point - is compromised
and is a complete waste of time (it's not, you know what i mean).


i think it's important to remember here that the NLnet Foundation is
funding us because they believe in what we promised to deliver.  i've
had two conversations with michiel, now, and his enthusiasm and
delight at the opportunity to fund what we've said we would do comes
through really clearly.

so the "why", here, is multi-faceted:

* we're developing an open processor so that other people can review
it for security and hardware or software level spying.  or, if they do
not have the knowledge or expertise to do that, they can trust other
people who have.

that very very specifically does NOT include *us* as the "people to be
relied on and trusted"!

 the practical take-away from this is that it implies that the code
has to be readable, well-documented, and understandable.  for the
software, it has to actually *be* secure, which, jacob, is why i
backed you on the decision to use Rust in Kazan.

on the hardware side, the user will *not* be actually *running* the
actual programming language or the tools used to *design* the
hardware, meaning: the selection criteria and priorities (the design
constraints mentioned in the article above) are radically different.


* we want people to have a sense of amazement and wonder that makes
them enthusiastic to back the project, join the project, or just
explore it and learn from it when they have actual hardware in their
hands that uses this processor.

being able to get the *actual source code* of the *hardware* - not
just the software - the *hardware* that you own, that is so
jaw-dropping when you think about what we're doing (a quad-core SMP
system with a 3D GPU and VPU!), keeping that in mind i feel is really
important.


* i've witnessed the effects of large corporations using financial
brute-force instead of creativity, and the consequences aren't pretty.
Google Project Ara is the main one i know of, there are plenty more.

having access to money comes with a responsibility to not just go
"wha-hey! now we can let our hair down and forget some of the things
we couldn't do when we *didn't* have money", because money allows you
to be *more of yourself*.

if you want the world to be populated with unethical products, buy
products from unethical companies!  you *empower* them by giving them
money, it's really that simple.

this is i think why the NLnet sets a limit of only EUR $50,000 for
first-time projects, so that they can see that the team is acting
responsibly.

yes, they pay for an AUDIT of all projects, and receive an INDEPENDENT report.


also, i am used to making quite simple pathological and extremely
creative solutions which involve taking in multiple factors at once,
combining what, to everyone else, looks like extremely disparate and
completely incompatible tools, techniques and software.

this turns out to save vast amounts of time and effort, sometimes on
the order of *two orders of magnitude* when compared to other teams.

sadly, those teams get extremely pissed off.  "how can you come in
here, order us about, tell us what to do, and make us look bad by
achieving something in N days which we haven't been able to do in N
years???"

(yes, i have literally had one person use almost exactly those words.
they actually said, "well i haven't been able to solve this in 10
years, so i don't BELIEVE you can POSSIBLY do it", and he proceeded,
over the next few weeks, to sabotage and undermine the work that i did
which did, in fact, solve the intractable problem that he hadn't been
able to solve).

the reality is, they haven't been able to get over their egos and see
the bigger picture, that, exactly as that article points out, it's not
*about* being "right", it's about the "why".  if someone from outside
presents a solution to an intractable problem for god's sake BE
GRATEFUL! :)

say "wha-hey! thank you! that's another one off the list! we can get
on with solving the other hard problems and fulfil our mission to make
better software for our users, whoopee!"


basically what i am saying, jacob, is that if you are getting the
impression that i am "trying to be right all the time", this simply is
NOT the case.  at all.

following on from the "why", above: where i answer on some of the
ideas that you come up with, i am doing so - in detail - so that not
only *you* can see the logical reasoning, it's so that *other people
can as well*, in the future.

what i then expect you to do is to review that, carefully (which
you've done in some cases, and spotted errors, which is great, as i
then proceeded to fix them), and say whether you agree or disagree
with that logical reasoning.

not answering at all leaves me both very puzzled, it also, due to the
unanimous decision-making process, completely locks up that part of
the project *and everything that it depends on*.

that in turn means, very simply, that we won't be able to declare that
a given milestone has been completed (nor any of those that it depends
on), and we *won't get paid*!

so, in short: can i ask you, if you don't agree with something,
*please speak up*, if nothing else, just ask me the simple question,
"why?"

we'll get there, ok?

l.


[1] http://fortune.com/2016/03/17/apple-tim-cook-going-dark/