Leaving the GNU Guix community

Leaving the GNU Guix community

[Leo Le Bouter]

[-- Attachment #1: Type: text/plain, Size: 5855 bytes --]

Hello! 

I feel like what has happened is really a disaster, I don't feel like
contributing to GNU Guix anymore in the future. I think that the GNU
Guix maintainers justify unacceptable behavior and have acted upon
things without understanding them, not understanding why incidents have
happened, and at the same time that I don't feel that I can explain, and
that many people have spread misinformation that other believed also. 

I don't feel like there's any way forward to this, we really do not
understand each other, I don't know how to communicate the culture in
some feminist/queer squats in France around Paris where I live, where we
really feel together on the same page when it comes to these questions
and where also we exclude people who don't understand these goals, in
which I feel so good and where really every confrontation is avoided and
has many values that building an inclusive community like GNU Guix wants
to be. 

I think that the technicality of software development must be redefined
so that the hierarchy between the experienced and the beginner
disappears, I think that to cast as a beginner or an experienced is an
attitude, many people who are experienced cast themselves as beginners
for various reasons and that some other people cast themselves as
experienced for various other reasons. I think the difference between
the beginner and the experienced is a construction, I think that such
must be worked on so that every individual contributor can feel
independent and empowered and also not have to define themselves towards
the experienced. I think that the technicality of software development
implies a special kind of relationship with knowledge and experience, I
think that also must be re-invented, and in other social environments
like the feminist/queer squats I live in knowledge and experience is a
really sensitive topic and people who have knowledge and experience are
not always welcome to say what they know or what they think unsolicited
and if they are solicited, there's also a way to say that to never imply
a domination of student-professor, that to accept that someone does not
want to hear about supposed knowledge and experience, and also needs and
wants to feel proud and independent about what they are doing without
the help of people with said knowledge or experience. I think that in a
sense, everyone must become a beginner. I think it approaches a very
fundemental topic of software development especially in Free Software
communities that is to among others end meritocracy. I think that the
world of Free Software and Open Source is tainted by that meritocratic
spirit and that if we want to bootstrap inclusive communities we must
embrace that underrepresented people also are of very varrying skill
levels and that we must empower and include everyone no matter their
skill level, and that this notion even of skill level disappears and
that all people of varrying skill levels are also not interested in
feeling submitted to a pre-existing group of people with knowledge or
experience. That we must find other ways, tools, to organize tolerance
for mistakes, collectively, that errors become not problematic at all,
or that the possibility for error is removed, to create systems that
detect errors and only accept non-errorneous input, so that as long as
the contribution is a valid input from anyone, it is a valid
contribution, that there's no room for doubting, for having failed to,
for being responsible, for being accountable, for being blamed, if the
tool fails to detect errors then we are collectively responsible for
improving the tool, not individually responsible for triggering a
validation bug. The tool also must be friendly with the way it rejects
input, it must be helpful, it must provide guidance, it must not leave
anyone no matter who they are, no matter what they know, in a situation
where they have no idea what to do to create a valid contribution. I
think that inclusive tools remove the possibility for error. I think
that good UI/UX is when you can't go wrong, and that if you do, it's
easy to undo what you just done, always. I think that GNU Guix is many
situations many things can go wrong and I think that's not inclusive, it
pushes off many people because it induces important amounts of stress to
realize things can be wrong and especially when you can't undo them. I
think that somehow the tolerance for mistakes or errors from anyone must
be absolute, so that it is never an issue they happen. I think that for
example with the design of the web where HTML parsers are tolerant to
errors, that with JavaScript there's nothing that can possibly go wrong
with code you write, ideally nothing can possibly be a security issue
(not the case with JavaScript on the web but I think that if we were
given a chance to give another go we could fix it), I think that such
error-tolerant design is one of the reasons that there's also so many
JavaScript developers of very diverse skill levels, that to me it feels
very inclusive. I think that there's ideas to take from there. I think
also when we talk about practical software freedom, that we still have
systems that can only be controlled by programmers, that the majority of
people on earth are still bound to use tools they cannot control
themselves. I think that to reach true practical software freedom
everyone must be a "programmer", that controlling your system fully
becomes so intuitive, so accessible, so inclusive also, because I think
those topics are inevitably linked, that the need for "expert
programmers" disappears. I think that software design is strongly
entangled with the need for expertise and I think that for computing in
general to become ethical as a whole the difference between a user and a
developer, the words even, must disappear, become out of use, stop
making sense. 

Léo

[-- Attachment #2: Type: text/html, Size: 6072 bytes --]

Re: Leaving the GNU Guix community

[Ryan Prior]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

On Thursday, April 29th, 2021 at 11:43 PM, Leo Le Bouter <lle-bout@zaclys.net> wrote:

> I feel like what has happened is really a disaster, I don't feel like contributing to GNU Guix anymore in the future.

Hey Léo, thank you for writing & for all your contributions. As a security professional I feel you deeply on the points you brought up and see how it would be frustrating for you to continue. Hope to catch you around & continue hacking together sometimes, it's been a pleasure!

Ryan

[-- Attachment #2: Type: text/html, Size: 910 bytes --]

Re: Leaving the GNU Guix community

[aviva]

On 4/29/21 7:43 PM, Leo Le Bouter wrote:
> I don't feel like there's any way forward to this, we really do not
> understand each other, I don't know how to communicate the culture in
> some feminist/queer squats in France around Paris where I live, where we
> really feel together on the same page when it comes to these questions
> and where also we exclude people who don't understand these goals, in
> which I feel so good and where really every confrontation is avoided and
> has many values that building an inclusive community like GNU Guix wants
> to be.



I feel you are trying to say something significant here, but it is not
understandle.

Re: Leaving the GNU Guix community

[Leo Prikler]

Hello,

Am Freitag, den 30.04.2021, 01:43 +0200 schrieb Leo Le Bouter:
> I think that the GNU Guix maintainers justify unacceptable behavior 
1. What makes you think that?
2. How do you justify your own behaviour, specifically the kind of
behaviour, that others have asked you to justify?

> [The Guix maintainers] have acted upon things without understanding
> them, not understanding why incidents have happened
Where specifically?

> [M]any people have spread misinformation that other believed also.
What kind of misinformation was spread?

> I don't feel like there's any way forward to this, we really do not
> understand each other
Mutual understanding does not spring into existence from nowhere, it
requires effort.  You have always been quick to point out when you feel
misunderstood by others, but I don't feel you try to understand them in
turn.

> I don't know how to communicate the culture in some feminist/queer
> squats in France around Paris where I live, where we really feel
> together on the same page when it comes to these questions and where
> also we exclude people who don't understand these goals, in which I
> feel so good and where really every confrontation is avoided and has
> many values that building an inclusive community like GNU Guix wants
> to be.
I agree that avoiding conflict is a good heuristic when it comes to
being inclusive, but I don't think that purges are the way towards
inclusivity.

> I think that the technicality of software development must be
> redefined so that the hierarchy between the experienced and the
> beginner disappears, I think that to cast as a beginner or an
> experienced is an attitude, many people who are experienced cast
> themselves as beginners for various reasons and that some other
> people cast themselves as experienced for various other reasons. 
The notions of "beginner" and "experienced user" are already very weak
within Guix.  Of course, those who have a longer history of
contributing have accustomed to our rituals and thus feel less
alienated by them than someone who has to set up 'git send-email' for
the first time.  Such technical hurdles certainly exist, but I don't
think they bar anyone from contribution.  I feel the opposite is the
case.  Of all the software projects I've so far contributed to, Guix
was the easiest to get into.

> I think the difference between the beginner and the experienced is a
> construction, I think that such must be worked on so that every
> individual contributor can feel independent and empowered and also
> not have to define themselves towards the experienced. 
Guix already empowers its users long before they start contributing. 
As far as contributions are concerned I know of no process better than
peer review.

> I think that the technicality of software development implies a
> special kind of relationship with knowledge and experience, I think
> that also must be re-invented, and in other social environments like
> the feminist/queer squats I live in knowledge and experience is a
> really sensitive topic and people who have knowledge and experience
> are not always welcome to say what they know or what they think
> unsolicited and if they are solicited, there's also a way to say that
> to never imply a domination of student-professor, that to accept that
> someone does not want to hear about supposed knowledge and
> experience, and also needs and wants to feel proud and independent
> about what they are doing without the help of people with said
> knowledge or experience. 
I have no idea what to make of this blurb.  Are people really waving
around their commit log saying "I've contributed so and so many
packages, I am an expert™"?

> I think that in a sense, everyone must become a beginner. 
Everyone is a beginner.  Maybe not always, but also at no point never
again.

> I think it approaches a very fundemental topic of software
> development especially in Free Software communities that is to among
> others end meritocracy. I think that the world of Free Software and
> Open Source is tainted by that meritocratic spirit and that if we
> want to bootstrap inclusive communities we must embrace that
> underrepresented people also are of very varrying skill levels and
> that we must empower and include everyone no matter their skill
> level, and that this notion even of skill level disappears and that
> all people of varrying skill levels are also not interested in
> feeling submitted to a pre-existing group of people with knowledge or
> experience. 
I don't feel that Guix is tainted in the way you imply.  People
contribute according to their skill so as to satisfy their own and
other's needs.  When I say "contribute according to their skill", I
mean they use their (pre-existing or otherwise) knowledge of Scheme/the
Guix package API in particular to hack together mostly package
definitions, but also build systems, UI, the whole backend code, etc. 
And yes, that is certainly a skill to have.  You won't get package
descriptions from 1000 monkeys trying to write Shakespeare or an AI,
that renders pretty anime avatars. 

> That we must find other ways, tools, to organize tolerance for
> mistakes, collectively, that errors become not problematic at all, or
> that the possibility for error is removed, to create systems that
> detect errors and only accept non-errorneous input, so that as long
> as the contribution is a valid input from anyone, it is a valid
> contribution, that there's no room for doubting, for having failed
> to, for being responsible, for being accountable, for being blamed,
> if the tool fails to detect errors then we are collectively
> responsible for improving the tool, not individually responsible for
> triggering a validation bug. The tool also must be friendly with the
> way it rejects input, it must be helpful, it must provide guidance,
> it must not leave anyone no matter who they are, no matter what they
> know, in a situation where they have no idea what to do to create a
> valid contribution. I think that inclusive tools remove the
> possibility for error. I think that good UI/UX is when you can't go
> wrong, and that if you do, it's easy to undo what you just done,
> always. 
I'd rather subject myself to peer review than a benevolent machine
overlord, TYVM.  Yes, there are ways in which tooling can improve a
situation.  In the particular way you have recently erred, I think
'guix lint' would have raised some warnings.  However, I feel as though
making such tools mandatory effectively creates an entry barrier rather
than doing the opposite. 

> I think that GNU Guix is many situations many things can go wrong and
> I think that's not inclusive, it pushes off many people because it
> induces important amounts of stress to realize things can be wrong
> and especially when you can't undo them. 
There are plenty of opportunities and much time to undo an error. 
That's why we have a review process after all.

> I think that somehow the tolerance for mistakes or errors from anyone
> must be absolute, so that it is never an issue they happen. I think
> that for example with the design of the web where HTML parsers are
> tolerant to errors, that with JavaScript there's nothing that can
> possibly go wrong with code you write, ideally nothing can possibly
> be a security issue (not the case with JavaScript on the web but I
> think that if we were given a chance to give another go we could fix
> it), I think that such error-tolerant design is one of the reasons
> that there's also so many JavaScript developers of very diverse skill
> levels, that to me it feels very inclusive. I think that there's
> ideas to take from there. 
You're contradicting your earlier statement.  You can't have a system
that's both extremely pedantic and "fault tolerant" in the JS sense. 
Those are opposite extremes.

> I think also when we talk about practical software freedom, that we
> still have systems that can only be controlled by programmers, that
> the majority of people on earth are still bound to use tools they
> cannot control themselves. I think that to reach true practical
> software freedom everyone must be a "programmer", that controlling
> your system fully becomes so intuitive, so accessible, so inclusive
> also, because I think those topics are inevitably linked, that the
> need for "expert programmers" disappears. I think that software
> design is strongly entangled with the need for expertise and I think
> that for computing in general to become ethical as a whole the
> difference between a user and a developer, the words even, must
> disappear, become out of use, stop making sense.
There is a nugget of truth to be found in there, but I feel you're
drawing distinctions on unclear grounds.  Certainly a committer is a
developer and someone who only ever invokes "guix pull && guix upgrade
&& sudo guix system reconfigure /etc/config.scm" is not, but where do
people, who submit patches into your image?  I personally feel Guix
encourages more users to be developers (while that distinction still
exists) than any other system.

Also, you must consider the cognitive burden, that developing software
is, particularly for those who don't have a background in computer
science.  I am personally happy to teach anyone who is willing to
learn, but I acknowledge, that some people will only ever be interested
in getting their job done (using free software, of course), and that
first teaching them a programming language would be unsolicited advice.

Regards,
Leo

Re: Leaving the GNU Guix community

[Ludovic Courtès]

Hi Léo,

I’m sad you reached the conclusion that our inability to understand each
other cannot be overcome; perhaps you’re right, though I like to believe
there’s always a way forward.  I hope we can meet each other again, in
Guix or other spaces in more favorable conditions, under less stress.

There’s a lot of food for thought in your message.  I think it’s fair to
say that maintainers and in fact most contributors have been paying
attention to welcoming people regardless of their experience level; the
manual, although technical, also strives to assume little knowledge in
the field.  We can certainly improve on both fronts, but at least this
is already a goal of the project.

You write that “the difference between the beginner and the experienced
is a construction”.  I sympathize with your rejection of the
student-professor domination.  However, I think newcomers can and should
benefit from guidance by the experienced; that’s the only way we can
truly blur the experienced/beginner distinction.  As an “experienced”
person in this project, I consider it part of my work to help others.  I
believe knowledge sharing can be achieved without it becoming a
domination relation.  That is at least what I think most people here
strive for.

Thanks again for your contributions.  I wish you the best for your
future endeavors.  We will welcome you back whenever you feel we can
work together again.

Ludo’.

Re: Leaving the GNU Guix community

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> You write that “the difference between the beginner and the experienced
> is a construction”.  I sympathize with your rejection of the
> student-professor domination.  However, I think newcomers can and should
> benefit from guidance by the experienced; that’s the only way we can
> truly blur the experienced/beginner distinction.  As an “experienced”
> person in this project, I consider it part of my work to help others.  I
> believe knowledge sharing can be achieved without it becoming a
> domination relation.  That is at least what I think most people here
> strive for.

I have been wanting to raise this issue for a while, so maybe now is the
right time! :)

On the educational level, I fully agree with Ludo.

I wonder, however, if this educational hierarchy does not transpire into
political hierarchies.

In other words, if we certainly need experienced users to teach and help
newcomers, do we need experienced users to take more executive decisions
than newcomers?

At the moment, it seems that the right to police others is reserved to a
privileged group.  Should it really be this way?  It does not seem
obvious to me that this separation benefits the community, maybe there
would be an interesting discussion to have here.

For instance, if a long-term, experienced contributor misbehaves (be it
with commits or communication), can they be policed?  The same way that
less experienced users are policed?  By whom?
Can a less experienced user police an experienced one?

There is a lot to discuss here, including transparency of communication,
class of privileges, protocols for exclusion, etc.

I don't know if these issues have been raised and addressed in the Guix
community; maybe there is room for improvement.  Anyhow, discussing more
about these things can only help organizing ourselves better and
building a stronger community! :)

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: Leaving the GNU Guix community

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]

Léo,

Leo Le Bouter 写道：
> I feel like what has happened is really a disaster,

I'm relieved that we share, at least, this.  I think everyone 
does.

> I don't feel like contributing to GNU Guix anymore in the 
> future.

That's a great pity.  I hope to welcome you back some day.  Guix 
is better off with your fixes.

Yet I'm convinced that the decision to suspend commit access was 
the right one.  It wasn't easy.  Nobody was happy about it.

I also hope that you can accept your role in the events that lead 
to it and learn from them and make adjustments.

I'm disappointed that you still deflect the brunt of the 
responsibility to others and refuse to acknowledge that this, 
itself, is a problem.  Saving face consistently took precedence 
over accepting feedback.  That's a dangerous blind spot to have.

> I think that the GNU
> Guix maintainers justify unacceptable behavior and have acted 
> upon
> things without understanding them, not understanding why 
> incidents have
> happened

We have a much better understanding of the *complete* situation 
than you imply.  It's far too common and too convenient to claim 
that people you don't agree with are (at best) uninformed.

We've certainly made mistakes over the years.  Being buggy humans 
we'll be sure to make more.

Several contributors expressed (in at least one case: severe) 
unease with your attitude long before Mark sent his own unpleasant 
message, and I think we did too little and waited too long to 
publicly address either in a coordinated manner.  Lesson 
hard-learnt.

> that many people have spread misinformation that other believed 
> also. 

I refuse to credit this vague insinuation.  My mind was made up by 
nothing but your own posts to this list and your blunt refusal to 
answer questions.

Kind regards,

T G-R

PS: I wanted to keep this short, but thank you for sharing your 
thoughts or Free software development.  I read them with interest.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Leaving the GNU Guix community

[Joshua Branson]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Léo,
>
> Leo Le Bouter 写道：
>> I feel like what has happened is really a disaster,
>
> I'm relieved that we share, at least, this.  I think everyone does.
>
>> I don't feel like contributing to GNU Guix anymore in the future.
>
> That's a great pity.  I hope to welcome you back some day.  Guix is
> better off with your fixes.
>
> Yet I'm convinced that the decision to suspend commit access was the
> right one.  It wasn't easy.  Nobody was happy about it.

May I humbly suggest, that in the future if guix
maintainers/developers/super-humans suspend someone's commit
access, this "punishment"/"education" happens privately?  Perhaps this
"education" should not be announced on guix-devel.  Instead it should
only be sent privately to the developer in question.  Perhaps that would
lessen the sting.

Thanks!

Joshua

P.S.  I'm definitely NOT a guix developer (maybe some day), but I hope
it's ok that I share my thoughts.  :)


--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: Leaving the GNU Guix community

[Léo Le Bouter]

Hello Tobias,

On Sat, 2021-05-01 at 04:34 +0200, Tobias Geerinckx-Rice wrote:
> Léo,
> 
> Leo Le Bouter 写道：
> > I feel like what has happened is really a disaster,
> 
> I'm relieved that we share, at least, this.  I think everyone 
> does.
> 
> > I don't feel like contributing to GNU Guix anymore in the 
> > future.
> 
> That's a great pity.  I hope to welcome you back some day.  Guix 
> is better off with your fixes.
> 
> Yet I'm convinced that the decision to suspend commit access was 
> the right one.  It wasn't easy.  Nobody was happy about it.
> 
> I also hope that you can accept your role in the events that lead 
> to it and learn from them and make adjustments.
> 
> I'm disappointed that you still deflect the brunt of the 
> responsibility to others and refuse to acknowledge that this, 
> itself, is a problem.  Saving face consistently took precedence 
> over accepting feedback.  That's a dangerous blind spot to have.
> 

I do not think that is true, I think that I do not feel welcome to
acknowledge criticism when it is not written in a friendly manner
(because it generates confrontation), and also I can disagree with
criticism. I think I have acknowledged lots of criticism over the
course of contributing to GNU Guix and this is not taken into account
AT ALL, and that you think that this decision was right I think further
re-inforces that I will not be contributing to GNU Guix in the future.
You failed to recognize the effect of the tone in the messages, and how
deeply it affects me and my ability to feel happy and also to be
constructive (which includes responding in a useful way to criticism).
I don't feel that I can change that. I can only survive in environments
where discussion is exceptionally caring and friendly for this very
reason. I feel deeply affected by everything that's said by people,
even through Internet messages.

I think it is a disaster that you (maintainers) choose to blame someone
publicly for feeling so bad after having received messages of
exceptional aggressivity. I think it is not fair and not justified.
That you insist for me to reply to some aggressive message, I think
that is a disaster. I think it is an horrible thing to ask to someone.

> > I think that the GNU
> > Guix maintainers justify unacceptable behavior and have acted 
> > upon
> > things without understanding them, not understanding why 
> > incidents have
> > happened
> 
> We have a much better understanding of the *complete* situation 
> than you imply.  It's far too common and too convenient to claim 
> that people you don't agree with are (at best) uninformed.

I don't think I am doing any of that and it's hurtful you say I am. I
am not. I really do think that we do not understand each other, on an
emotional level.

> 
> We've certainly made mistakes over the years.  Being buggy humans 
> we'll be sure to make more.
> 
> Several contributors expressed (in at least one case: severe) 
> unease with your attitude long before Mark sent his own unpleasant 
> message, and I think we did too little and waited too long to 
> publicly address either in a coordinated manner.  Lesson 
> hard-learnt.

I think that there's been disagreements and that it's been difficult to
handle for both me and other people. I think people must acknowledge
that I can have my own way of contributing to GNU Guix that can really
make sense and that I am not bound to listen to anyone's criticism if
it doesnt make sense to me and that I cannot or am not willing to do
the work to adapt my contributions to said criticism. If you are
talking about the Zimoun case, as unfortunate as it is that they went
away, I don't think it can be blamed solely on me. They also wanted to
go. What I expressed earlier about their postings remains true for me.
I felt harassed by their postings and that's the reason it also went
off the rails. I think that there's a difference in treatment between
people that contribute to GNU Guix, that not all contributors to GNU
Guix are considered equal, that I have been the subject of criticism
but that some other contributors to GNU Guix will not be the subject of
criticism for various other reasons. I feel like I should be treated
like a person with their own opinions and preferences when it comes to
contributing and that the way I choose to do the contributions as long
as I am the one making them should be respected and that if there's
criticism it is welcome but that if I do not agree with such criticism
that my disagreement be respected. As comparison, I rarely go and
criticize other's work, I trust people to do the best. I know everyone
goes and checks if their own contributions work great from time to
time, but for that to happen you must give the authors that time. I am
able to and I know everyone is able to self-criticize their work and
adapt also. You just have to give trust. I have not heard many people
criticize code quality or anything else when it is maintainers like
Mathieu or Ludovic that broke stuff. I think it is normal to break
stuff. In general, I am not interested to fit in or become someone else
because of people's criticism, I am interested to be accepted as the
person that I already am and want to be. Some times criticism crosses
that border in that it expects me to contribute like the person who
criticizes wants, and some times I purposefully do not want to
contribute like that. I think it's also the reason I come to GNU Guix
and not some employer, I am not interested in responding to someone
else's interests if they do not make sense to me.

> 
> > that many people have spread misinformation that other believed 
> > also. 
> 
> I refuse to credit this vague insinuation.  My mind was made up by 
> nothing but your own posts to this list and your blunt refusal to 
> answer questions.

I think we still do not understand each other, and that I cannot
possibly explain it or express it through text messages, I think it is
even more of a disaster that you again insist I should be replying to
anyone who's being aggressive. 

> 
> Kind regards,
> 
> T G-R
> 
> PS: I wanted to keep this short, but thank you for sharing your 
> thoughts or Free software development.  I read them with interest.

With a lot of disappointment and pain,
Léo

Re: Leaving the GNU Guix community

[raingloom]

On Sat, 01 May 2021 19:47:40 +0200
Léo Le Bouter <lle-bout@zaclys.net> wrote:

> I think it is a disaster that you (maintainers) choose to blame
> someone publicly for feeling so bad after having received messages of
> exceptional aggressivity.

Disclaimer: I only saw some of the relevant discussion, so, please don't
shout at me or assume I'm saying this to hurt anyone.

For what it's worth, blame-free security culture is possible. I was
reading Google's Site Reliability Engineering stuff a few months ago,
which - among other things - talked about exactly this. People need to
feel like they can make mistakes without being attacked for them,
otherwise they won't be open when they inevitably do mess something up.
But I should add that if someone does mess up, it should not be
controversial - to them or their team - to put more oversight on them.

Anyways, I hope you'll stay, and that everyone will strive to make this
an actually inclusive community.

Re: Leaving the GNU Guix community

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2925 bytes --]

Hi Léo,

I'm sorry to hear that you feel that you need to leave the community.  I
can understand why you feel that way, but I hope you'll remember that
(to my knowledge) nobody has said that they don't want you here.

I realize that in this moment, it must sting terribly to have your
commit rights temporarily revoked.  However, even before you gained
commit access, you contributed great things to Guix: patches, ideas,
computing resources, your energy and enthusiasm, and so on.  I
personally know that we would not have ported Guix successfully to
POWER9 without your help!  I guess what I'm trying to say is that even
without commit access, it's possible to be a contributor and a community
member.  And in any case, the maintainers have made it clear that the
commit access suspension does not need to be permanent:

https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00489.html

They said:

"I'm sorry to say your commit privileges have been temporarily
suspended.  After one month, you are invited to get in touch with the
maintainers collective and discuss next steps."

They have explicitly left the door open.

By the way, speaking of contributions, I think your latest email here
raises some very good points.  I don't have good solutions to suggest
for any of them, I'm afraid, but I can say that I share many of your
concerns.  The "user experience" can definitely be better in many ways.
I also agree that the line between "user" and "developer" can and should
be blurred (programs like Emacs or LibreOffice or RenPy come to mind).
The more the line can be blurred successfully, the more it can empower
the user/developer, but it is tricky to do.  I mean, how many
non-programmers do you know who really use Emacs (or Vim)?  Personally,
I know none.  I know a lot of people who use Excel, though, or programs
like RenPy which are easy to "script" - i.e., program.  There are ways.

I also think it is more difficult than necessary to get started
contributing to Guix.  I wish it were easier, but I don't have any good
suggestions for that right now, either.  I think a lot of people who
have played with Guix code and participated in the Guix community also
experience these same difficulties, but I guess maybe people don't talk
about it too much because it's truly hard to come up with better
solutions than what we have.  There is also the issue of lack of time;
for those contributors (like myself, currently) who work on the project
only as volunteers in their spare time, it can sometimes be difficult to
find the time.  People tend to contribute in areas they are interested
in, which is fair, and there is always far more work to do than any
single person can finish on their own.

I wish you the very best in whatever you do, and I hope you'll return to
the Guix community when you feel that we can collaborate together again.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Making technology more inclusive Was: Leaving the GNU Guix community

[Denis 'GNUtoo' Carikli]

[-- Attachment #1: Type: text/plain, Size: 5272 bytes --]

On Fri, 30 Apr 2021 01:43:37 +0200
Leo Le Bouter <lle-bout@zaclys.net> wrote:

> I think that the technicality of software development must be
> redefined so that the hierarchy between the experienced and the
> beginner disappears [...]
I've been thinking a lot about these topics, and there are radical
solutions that can work today, but the scope is quite limited.

Sadly, technology in general is way too complex to enable any individual
to be able to practically exercise the freedom to modify how it works
at every level: For instance, computer hardware is way too complex, not
everyone is able to modify how the RAM initialization is done in
Libreboot. And that's just for the software side that is visible to
users. There is also a big interest in modifying how the hardware
works, for instance by making custom CPUs on FPGAs, which again
requires domain specific knowledge.

Despite that, several indigenous communities run their own GSM
networks[1] and while doing that at least some of them seem to have
managed to do what you are talking about (remove power relationships
between the people with specific knowledge and the people without that
specific knowledge):
- The people running the network have to obey what the village assembly
  decided. So everybody decide together with the people running the
  networks.
- They also managed to have the protocol modified for them at a deeper
  level[2] to make their GSM network behave more like peer to peer
  networks between villages instead of the way GSM networks are
  typically deployed.

Note that in this example above many of the communities that run their
own GSM networks didn't chose (yet?) to have Internet access for
instance so the scope is quite limited.

Things get more complicated when trying to bring this amount of control
down to every single individual for every aspect of every digital
technologies. And many people have personal computers this also looks
important to reflect on.

The approach taken by lisp machines was interesting: it enabled users to
practically modify all the source code (most or all of it wasn't free
software if I understood right). They used CPUs made specifically to
run lisp code to do that but as I understand the downside was that,
even if most of the code was in lisp, there was probably still some
code in assembly or other languages as the lisp interpreter was
probably not written in lisp.

Another approach that I find interesting is the one taken by operating
systems like OpenBSD (which is not FSDG compliant) where the design is
much more simple. The downside is that it lacks many functionalities
that some users might miss.

Hyperbola (which is FSDG compliant) is working on a new operating
system which will reuse the OpenBSD kernel, so it might be interesting.

Here the bar is probably higher as it requires to be able to write C to
modify the kernel, but at least some part of it looks a lot more simple
than Linux. For instance if we compare OpenBSD's pledge system call and
Linux's secomp, pledge is only one driver in the kernel whereas secomp
also requires a compiler and so on. And more importantly, software is
being written to take advantage of secomp, so I guess that at least in
some cases some people depend on secomp because of that.

One approach which seems to also have been taken by Guix is to work to
make it more simple to modify how things works. Since lisp is parsable
it might even be possible to write graphical user interfaces (in lisp
for instance) to enable users to modify how the system is configured,
how it works, etc.

But the downside is that it still depends on complex code in the
software it packages (like linux-libre, gcc, etc).

With learning, there are also interesting approaches used for learning
concepts used in digital technology (like the concepts used by git,
etc)[3] which could potentially enable more people to be able to modify
the way technology works, but it also requires time.

And for hardware, we start to have ISAs like RISCV or PPC64LE that can
at least be implemented with designs under free licenses. So it could
potentially open the door for more simple hardware, but that hardware
also needs to be fast and not too expensive or complex to produce, so
it could also not work out because of that.

So I'm really wondering where we could go with all that, could it all
become step by step, incrementally more accessible when combining
several of these things together (like better teaching + more simple
software and hardware)? Or do we really need to re-do it from scratch
to make technology accessible? Or change the way we live and interact
with technology to make it fit people instead of having people be
required to fit technology?

Unfortunately I don't really have a deep enough vision on this topic to
know which step to take in advance so I've mostly resorted to the
incremental improvements, hoping to advance things in the right
direction up to the point where it could work well enough or show us
its limit and push us to find another path.

References:
-----------
[1]https://www.tic-ac.org/
[2]https://osmocom.org/news/120
[3]https://techlearningcollective.com/

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Making technology more inclusive Was: Leaving the GNU Guix community

[raingloom]

On Sun, 2 May 2021 02:15:31 +0200
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:

> On Fri, 30 Apr 2021 01:43:37 +0200
> Leo Le Bouter <lle-bout@zaclys.net> wrote:
> 
> > I think that the technicality of software development must be
> > redefined so that the hierarchy between the experienced and the
> > beginner disappears [...]  
> I've been thinking a lot about these topics, and there are radical
> solutions that can work today, but the scope is quite limited.
> 
> Sadly, technology in general is way too complex to enable any
> individual to be able to practically exercise the freedom to modify
> how it works at every level

A lot of complexity is essential complexity. Just as an example: type
systems are more complex than dynamic typing, but they would make it
easier to safely customize code without breaking crucial invariants.
Also s-expressions being "parsable" does not make them much better,
because often you have no way of knowing what type some piece of code
expects. They are better than sed, but they only enable intelligent
refactoring, they don't provide them automatically.

I am often more productive in Haskell than in Scheme, because I don't
waste time tracking down trivial errors that can be caught by a type
system, and because it has (and pervasively uses) typeclasses (aka.:
"interfaces"), so I can just use fmap instead of map, vector-map,
bytevector-map, and so on.
Of course you can add type systems to otherwise dynamic languages too,
so this isn't a dichotomy.

Simplicity also shouldn't come at the cost of efficiency. A compiler is
more complex than an interpreter, but it lets you target a wider array
of hardware.

There is a lot to be improved in programming languages and libraries,
but there there is a complexity bedrock you can't dig under.

Re: Symbolics. Look at a Symbolics demo if you want to see some frankly
embarrassing performance. Genera had interesting ideas but no one who
values making the most of their hardware is going to be using it. And
remember, it was even slower on Symbolics hardware, because they
couldn't iterate their CPU designs quickly enough, whereas general
purpose CPUs just kept getting faster and cheaper. Also Lisp compilers
became better at targeting generic ISAs.

But there are interesting ISA designs that actually do improve
performance. My favorites:
* Mill https://millcomputing.com/
* Reduceron https://github.com/tommythorn/Reduceron
* CHERI https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

As for languages, I want to see more types, generics/typeclasses,
effect systems, and more AOT or multi-stage compiled implementations.


Anyways, complexity probably won't entirely go away. It's very difficult
to make an already complex system simpler, building a new simpler one is
easier, which is sad, because I don't think we can afford not being
compatible with existing software and especially existing hardware.

But having a VM based system could help with both. See the classic
talk: The Life and Death of Javascript.

Oh and we should heed Chris Webber's advice and work on OCAP security.
Because yeah, simplicity also mustn't come at the expense of security,
but OCAP would make things both simpler and more secure.

So, yeah, a lot of this complexity is going to stay, but we can at
least try to not make it worse.

Oh, and social issues won't be solved by technology alone. There will
always be complex technological issues and the distribution of the
knowledge to tackle them is a social issue. We have to make our
communities inclusive for vulnerable people if we want to actually
meaningfully help them. Also sometimes you just have to work on featues
that other people want, not just features you want.

ps.: on that note, go ask some blind people about the state
of accessibility on Linux. It's not pretty.
And stop writing curses TUIs. And in general just go learn about
accessible design and test software with actual humans.

Okay, I'll stop here because this is a complex topic (quite fittingly)
and this mail is already (too) long enough.