HOME > RSS > BLOGS France > Biologeek

R S S : Biologeek


PageRank : 2 %

VoteRank :
(0 - 0 vote)





tagsTags: , , , , , , , , ,


Français - French

RSS FEED READER



★ Web et technique

21 July, by David Larlet[ —]

L’évolution des objets techniques doit être comprise en ce sens comme la recherche d’un système qui est tel qu’il ne peut être autodestructif. Le système doit pouvoir se maintenir stable le plus longtemps possible. Pour le dire autrement, il s’agit au fond d’augmenter l’espérance de vie de l’objet technique — ce que rend précisément possible l’établissement de directions de convergence. Un objet technique est d’autant plus évolué qu’il n’est pas en lutte avec lui-même. Un objet technique évolué est celui dans lequel aucun effet secondaire ne nuit au fonctionnement de l’ensemble, ou aucun effet secondaire n’est laissé en dehors de ce fonctionnement. Un objet technique se caractérise par le fait de son inscription au sein d’une lignée technique qui augmente à chaque génération son espérance de vie par l’artifice d’une auto-corrélation.

Gilbert Simondon et la libération par les techniques (cache)

Difficile de ne pas faire un parallèle avec le Web ici, objet technique en lutte permanente avec lui-même. La question est de savoir s’il y a effectivement convergence et augmentation de son espérance de vie au cours du temps. J’en doute de plus en plus. Et de continuer :

Mais, précisément, est-ce bien un artifice ? L’objet technique est-il artificiel ? Ce qui est frappant, bien plutôt, note Simondon, est que l’objet technique évolué se rapproche du mode d’existence des objets naturels, en ce sens où il tend lui aussi vers la cohérence interne ou la fermeture du système des causes et des effets qui s’exercent circulairement au sein de son enceinte. On estime d’ordinaire que ce qui fait l’artificialité d’un objet ne tient pas seulement à ceci que l’objet considéré a été fabriqué (et non pas produit spontanément par la nature), mais aussi et surtout à ceci que l’intervention de l’homme est nécessaire pour maintenir cet objet dans l’existence en le protégeant contre le monde naturel, en lui donnant ainsi un statut à part d’existence. L’artificialité est ce qui est intérieur à l’action artificialisante de l’homme : est artificiel ce qui requiert le concours de l’homme non seulement pour exister, mais encore pour se maintenir dans l’existence. Or le propre d’un objet technique est justement qu’il requiert de moins en moins l’intervention de l’homme pour se maintenir dans l’existence : c’est un objet artificiel (en tant qu’objet fabriqué) qui a un mode d’existence naturel.

Ibid.

Je ne peux m’empêcher de faire le parallèle ici encore avec un Web de plus en plus artificiel de par son manque de résilience, son rythme effréné (cache) et l’usage abscons de JavaScript. Ce qui m’amène à penser à l’autonomie du code. Si vous ne touchez plus au code de votre produit Web actuel pendant 6 mois, combien de journées seront nécessaires pour le remettre à jour ? Mettre le doigt sur les causes de son artificialité permet de participer à l’évolution d’un outil technique. De faciliter son émancipation en réduisant sa dépendance aux développeurs tout en maximisant les problèmes résolus (cache).

Pour paraphraser Max Weber au sujet de l’État qui considérait que « le pouvoir politique, c’est le monopole de la violence légitime » on aurait « le pouvoir technique, c’est le monopole de la dette légitime ». Or qui introduit cette dette aujourd’hui ? Les GAFAM plus que l’État à travers des bibliothèques populaires (React, Angular) qui évoluent très rapidement. Cette dette ne s’arrête pas aux outils mais aussi à leurs usages : en utilisant gratuitement un produit on en devient implicitement redevable.

Est-ce que le logiciel libre est ce « mode d’existence naturel » ? En un sens oui, car il devient théoriquement entretenu par une communauté qui se renouvelle et le fait évoluer itérativement. En pratique malheureusement on est bien loin du compte, il y aurait probablement à piocher dans des principes éloignés du code pour parvenir non pas à la convivialité mais peut-être à la résilience :

  • Homéostasie : des boucles multiples de rétroaction pour contrer les perturbations et stabiliser le système ; l’homéostasie est la capacité que peut avoir un système quelconque à conserver son équilibre de fonctionnement en dépit des contraintes qui lui sont extérieures.
  • Omnivore : la vulnérabilité est réduite par la diversification des ressources et des moyens ; comme dans la nature l’ultra spécialisation entame les potentiels de survie.
  • Flux rapides : des mouvements des ressources rapides à travers le système assurent la mobilisation de ces ressources pour faire face aux perturbations.
  • Niveaux hiérarchiques faibles : afin de mettre en œuvre rapidement des réponses très locales non standard. Comme chez nos amis les fourmis ou les rats.
  • Capacité tampon : capacités centrales sur-dimensionnées de telle sorte que les seuils critiques soient moins susceptibles d’être franchis. C’est ce qui est à l’œuvre dans les végétaux du désert et leur capacité interne en eau.
  • Redondance : les fonctions se chevauchent, et un relais peut ainsi être assuré si certaines échouent. Les espèces d’animaux redondantes sont celles qui exercent la même fonction au sein de l’écosystème. Comme les vautours et les hyènes dont les fonctions de découpage des animaux morts sont une même fonction pour deux espèces.

Résilience et modularité (cache) — Source : PDF en anglais (cache)

Il s’agirait presque de la définition d’un réseau en pair-à-pair comme SSB. Notez qu’il n’y a pas de référence à la croissance, un écosystème ayant besoin de s’auto-équilibrer pour survivre.

Quelques pensées (techniques ?) mal agencées que je vous laisse maintenir en vie :-).


✍ Lettre à Hubert

19 July, by David Larlet[ —]

Hubert,

Merci pour ces 5548 articles qui nourrissent mes réflexions de manière asynchrone et dense. Tu es le seul journaliste que je suis avec assiduité. En fait c’est à la fois pire et mieux que ça : tu es ma définition d’un journalisme qui sait s’adapter à un contexte changeant. C’est lourd à porter, c’est quelque peu déprimant de te voir aussi esseulé mais c’est aussi enthousiasmant et inspirant de constater que c’est possible !

Alors se pose la question de l’essaimage. Comment faciliter un cadre apprenant qui permette à ces réflexions de produire des interactions transverses ? Comment répertorier les externalités positives qui suscitent l’envie de prendre part à un tel travail ? Comment diffuser sans dénaturer ?

Autant de questions qui dans un autre domaine sont irrésolues de mon côté.

David


★ Without JavaScript

18 July, by David Larlet[ —]

js;dr = JavaScript required; Didn’t Read.

Pages that are empty without JS: dead to history (archive-org), unreliable for search results (despite any search engine claims of JS support, check it yourself), and thus ignorable. No need to waste time reading or responding.

Also known as, if it’s not curlable, it’s not on the web.

js;dr = JavaScript required; Didn’t Read (cache)

Transcript of a 5 minutes ignite talk at the Montreal accessibility meetup.

There has been a lot of discussions related to JavaScript within our community. The topic is way more vast than just the accessibility question. I’m here to share with you my own (non-)usage of JavaScript. I’m not deactivating JS completely, actually I’m doing something worse: I combine both hosts configuration and uMatrix to avoid loading most of JavaScript files either from ad-related servers or from content delivery networks (CDNs).

Needless to say that my web is quite empty. My feeling is that one page out of three does not load correctly and one out of ten is left totally blank (e.g. a documentation for developers that requires JS to be loaded, WTF.). Why on earth do I inflict that to myself?!

There are many reasons actually:

  1. Ethics. I’m a Web developer and if I want to fix something I need to be aware of how wide a thing is broken. It impacts my future choices. Really. And it drives interesting discussions with my peers when we have to depend on JS and/or a CDN.
  2. Security. Wait, what?! Yes, about four pages out of ten “include at least one library with a known vulnerability” (cache). That is just crazy.
  3. Tracking. Each and every time you link to a CDN you give all your statistics to another company. Think about it. As a user, I don’t want to be tracked.
  4. Connectivity. “All your users are non-JS while they’re downloading your JS” famously quoted Jake Archibald and there are a lot more reasons for JavaScript not loading correctly (more on that later).
  5. Performances. This is just unbelievable how fast a (blank :p) page can render. Ditch your bloated JS and trillions of call to ad-servers and you will not even need AMP.
  6. Business. Are we creating a Wealthy Western Web (part1 (cache), part2 (cache)) or do we take into consideration the next billion of users/customers? Hint: they will not have an iPhone 7 with a high bandwidth connection.
  7. Empathy (some might say accessibility). Your users can be subject to bad connectivity (transportation, countryside and so on), hanging HTTP requests for sub-resources, under a corporate firewall or worse if a wifi access/provider modifying JS on-the-fly. They can even have addons/plugins altering the DOM in a way you did not anticipate.
  8. Empathy. Again. Bad usage of JS can be nauseous/disturbing for people suffering from ADHD, autism, dyslexia or visually challenged (cache).

We’re building on a web littered with too-heavy sites, on an internet that’s unevenly, unequally distributed. That’s why designing a lightweight, inexpensive digital experience is a form of kindness.

Designed lines. (cache)

When making something readable/usable is turned into “kindness” by the community, it makes me think that we broke something in our culture. Oh and it makes me cry a little as a Web developer.

The answer to all that is progressive enhancement (cache) even years later. But sometimes you do NOT even need all that. Rethink what you are doing from the ground up. Challenge your value(s). And remember that “We’re all just temporarily abled.” (cache), let’s stop shooting ourselves in the foot each and every day.

I do think modern web development has gone down a deeply unwise path. Only through exercising our personal choices can we bring it back. We have mostly stopped the web from being a hellhole of shitty punch the money adverts by blocking the living shit out of adverts. JavaScript is becoming the new conduit for awfulness. I like the web too much to have to endure any more of it when not strictly necessary.

Why I’m turning JavaScript off by default (cache)


★ Sur la route

7 July, by David Larlet[ —]

Découvrir un lieu et la micro-culture qui l’habite. Que l’on vient augmenter et réduire à la fois. Les mêmes automatismes pour la survie du groupe. Les mêmes isolements pour la sienne.

Songer au nomadisme lent sans fantasmer celui des premières nations. L’envisager avant de réaliser le nombre de peurs qui alourdissent son propre sac. Se définir par ses escales et se nourrir de ses mouvements. S’embellir de ses contradictions.

Ponctuer son chemin de déchets. Le coût du nomadisme parmi les sédentaires. Ne pas être capable de quantifier son inadaptation. Réfléchir aux tensions qu’Ellul oppose aux adaptations. Ces dernières définissant pour moi l’intelligence et pour lui le confort. La route devra être longue pour aller au bout des ces concepts. En espérant secrètement qu’il n’y en ait pas mais qu’elle soit ponctuée de quêtes d’essence. De sens. Sans interdits.

Accepter d’autres façons d’appréhender le monde. De prendre soin de son monde en tolérant d’autres mo(n)des de pensées. S’intégrer en étant constructif dans un univers en auto-destruction. Des mots ne suffiront pas à calmer ces maux. Rouler au bout de ce monde pour contempler sa fin. Refaire le monde tout en participant à l’e-monde. Rêver d’une histoire sans faim.

Faire un dernier tour de campement pour ne rien oublier. Ne plus savoir si on continue d’avancer pour se retrouver, se fuir ou s’oublier soi-même. Déconnecté, mais de qui ? Des connectés sans acquis.


★ Inclusive Python

29 May, by David Larlet[ —]

After 12 years of hacking in Python, what did I learn the hard way? From biology to the web, across startups and now French government, I realized one thing: making your code resilient requires empathy.

It is the subject of a talk (slides) I gave at the Montreal-Python meetup.

I’ve been using Python for more than a decade now. Such a ride. And still, time doesn’t really matter. It’s more the diversity of projects and interactions that made me who I am as a developer. As such, I’m more and more concerned about the life of the code than ever. The transmission of the associated knowledge is the key to success of a project and to achieve this you have to think as a team. Lone wolves are burning out with their products. And it’s a real loss of energy. And happiness. And that sucks.

But first, let’s define inclusive. Given the Wiktionary the first definition is:

Including (almost) everything within its scope.

For this article, I would like to slightly rephrase that definition:

Including (almost) everybody within its scope.

I prefer that definition because coding is a social and political act. As such, each and every line of Python you produce should be put into that context. With whom. And why.

So, how do you make everybody capable of working with you(r Python code)?

Include yourself

Yesterday I was clever, so I wanted to change the world. Today I am wise, so I am changing myself. — Jalaluddin Rumi

That might seem obvious but do yourself a favour and do not reject yourself from your own code! We all have (please confirm :p) a project with no tests, no docs and yet critical and running in production that you have to maintain. Reshaping the project is not an option because you are short on attention/budget so it became a patchwork of ugly bug fixes. At that point, even you are unable to fix something without a week of procrastination to avoid that painful task. The challenge is not technical but the amount of motivation required is tremendous.

Try to be empathetic with a older wiser self. Ease the installation process, reduce dependencies, have fixtures. Document, automate, speed up the feedback loop when you are modifying something. All basic things that I rarely saw well implemented (including my projects).

Include your colleagues

— “But if all of our programmers are pairing, won’t they write half as much code?”
— “No, hopefully they’ll write even less than that.”

Ben Rady

Being part of a team is a way to duplicate the knowledge around the project. And that’s clearly not a lack of time or energy when you see the turn-over within our profession. I see three ways to do it:

  1. before: discussing strategies all together regularly, your mileage may vary on the frequency. The whole team needs to have a clear picture of what will be developed and why.
  2. during: pair-programming and/or quick sessions to discuss a particular issue mainly focused on the how.
  3. after: performing code-reviews and user-testing on each and every pull/merge-request. Check that the “why” of point 1. has been addressed and tested. Do not hesitate to trash everything at that point if it’s not relevant anymore.

Besides that, newcomers are a chance to rethink together a better process to onboard people. It only happens once per people, do not miss it and block at least half a day dedicated to that task. Observe them installing your project and trying to figure out how to make it run. Observe, do not help, do not say anything, let them find out alone. It’s not a user-testing session but a developer one. Collect everything to improve the developer experience later. Once the task is performed or worse your colleague is stuck, it’s time to discuss of the improvements. Is that a documentation issue? Or an environment one? Are you really explaining the purpose of your project? Which are the communication channels? And so on. We all have an illusion of the simplicity of our processes until they confront the diversity of others’ experiences.

The knowledge of your product is in your team, not in your code. We probably need new practices to get rid of that situation, it’s still too hard to find the right cursor between documenting and delivering value. Not only sharing how it works but why it failed and how do we addressed it at that time.

Include your (re)users

My suggestions can be expensive in time, money and energy. When you’re building something for the first time, all of this comes down to you. Focus on the documentation in the beginning. By doing that, you’ll create a welcoming place for others and then they can start helping you with the rest of it.

Lowering the barriers (cache)

This is a particular case that might be biased by my situation but when you are open-sourcing your developments and working for a government citizens you want people to be able to contribute to your work one way or another. Lowering the barriers of the contributions is still very hard.

Labelling some easy-picking issues (cache) might be worth it and your reactivity to answer to declared issues is key. Especially by people who just created an account just to submit them. Which does happen more than I expected in my case! Performing pedagogic reviews might be worth it on the long term to help contributors level up and produce better code with you.

Note: if your project only runs on top-of-the-market computers and requires to download megabytes of dependencies, you are closing the door to a lot of potential contributors.

Include maintainers

While I empathize with maintainers burning out and asking for support, trying to tackle sustainability from a maintainer centric view is a to paddle against the flow of the river. We continue to see barriers to adoption and participation fall away, enabling a new generation of contributors to be involved as long as we can view them as part of the solution rather than the problem itself.

Developers like to think they code their way out of any problem. We know how to scale servers but most of us are inexperienced with scaling people.

Maintainer vs. Community (cache)

Each and every time you contribute to an open-source project, you give your technical debt to a maintainer. Sad but true so help them with tests and documentation too! Lowering the barriers to other contributors is a way to increase the sustainability of the project which directly benefits to you.

As a maintainer, try to involve more people in the governance and maintenance of your project (I’m terrible at this…). This is somehow your escape lane because interest in projects will vanish from time to time. If you are the only one keeping the keys it will be lost forever once abandoned. At least, be a Minimally-nice Open Source Software Maintainer (cache).

Include beginners

Write code for complex logic so elegantly simple that it won’t make you look smart.

Think about it each and every time you plan to add a metaclass, a signal, a decorator or introduce the latest hyped lib to name a few. The beauty of your code is somewhat ugly to somebody having a hard time understanding these concepts. Really, nobody will blame you for writing dumb code that anyone understand at first sight. Not to mention yourself when you are stressed by a deadline or reopening this code six months later.

The best programmers write code beginners understand. It is as simple as this. You can write idiomatic Python and still be readable by a developer using another programming language. Make it a target and enjoy crossed code-reviews to identify these issues.

Document tools you use for your project (pycodestyle, isort to name a few), you can even add pre-commit hooks or automated checks via the pull/merge-request.

Include citizens

In an ever-more intricate and connected world, where software plays a larger and larger role in everyday life, it’s irresponsible to speak of coding as a lightweight activity. Software is not simply lines of code, nor is it blandly technical. In just a few years, understanding programming will be an indispensable part of active citizenship.

Coding is not ‘fun’, it’s technically and ethically complex (cache)

I’m not only talking about fixing typos in documentation here. How do you include people in the process of building the product? How do you make them aware that they can have a direct impact on what is done with their taxes? That part is yet to be experimented because it requires a shift in minds. A nation is a cooperative that scaled and as such each individual should act as part of a community.

Maybe some day, micro-payments will be available to remunerate the time spent by citizens on collective projects but — apart from the technical issue — the complexity to evaluate the value of each contribution is a real problem.

Include conclusion

An important point of maturity as a developer is realizing that writing code is a relatively insignificant part of software development.

Steven R. Baker

Embrace the diversity of others point of views, make them count. Your code is not a book, it’s a continuous discussion on a given goal. You are maybe familiar with the concept of progressive enhancement, you can push the first draft of your code/documentation as a proof of concept and then progressively enhance the inclusivity of your project too. As for Web literacy, it’s a matter of Python literacy. We have the chance to use a language that is easy to learn, let’s be worthy of it.

I had to confess that I’m not doing half of the things I described, it is mostly self-criticism here. And that’s OK, really, because inclusiveness is a journey. Just be sure to keep moving toward a direction that makes you feel good at the end of each and every day.

Include discussions

What makes a good pull-request for a developer and a good code review from a maintainer?

On the developer side, documenting clearly what is the aim of your contribution is key. It looks obvious but that’s not always the case. Adding clean code, tests and documentation is great. We use to add an entry in the changelog with every pull-request nowadays to ease the communication with our international team.

A good code review is a one that is both respectful and engaging. You can be inspired (cache) by a checklist (cache) but once again, don’t take it too dogmatically. It’s up on your team to define its own check points.

How do you handle technical debt and contributions?

We actually (and sadly) don’t have pull-requests related to technical debt clean up. We mostly initiate that kind of change during workweeks (about twice per year) when everybody is in the same room to coordinate and evaluate alternatives together.


★ Espace et temps

1 May, by David Larlet[ —]

In other words, we should not take too much comfort from the fact that the global internet first evolved thanks to cooperative capitalists, not competitive socialists: the story of the Soviet internet is a reminder that we internet users enjoy no guarantees that the private interests propping up the internet will behave any better than those greater forces whose unwillingness to cooperate not only spelled the end of Soviet electronic socialism but threatens to end the current chapter in our network age.

How the Soviets invented the internet and why it didn’t work (cache)

J’ai de plus en plus le sentiment que les cycles (d’ouverture aux autres ⟳ repli sur soi) sont intimement liés à notre rapport à la technologie. Et plus particulièrement aux effets que la technologie a sur notre relation à l’espace et au temps. Comme un mécanisme d’auto-protection, lorsque les autres se rapprochent de trop, on se renferme d’autant plus dans notre bulle : égoïsme, survivalisme, nationalisme. Il faut alors le temps de l’acceptation de ces changements et certains évènements comme la guerre favorisent probablement la prise de recul nécessaire à large échelle.

Le numérique (incluant le Web) contribue à la compression de l’espace et du temps. Il permet de prendre conscience à la fois du côté des privilégiés qu’ils le sont d’autant plus et du côté des exploités qu’ils sont nombreux. Ce ne sont pas tant les inégalités que leur visibilité qui est critique dans une société. Lorsqu’un outil accroit cette visibilité instantanément et en tout lieu, il est normal que des processus de rétro-actions se mettent en route au service d’une stabilité sociale qui s’apparente au fascisme.

Dans quelle mesure est-ce que cette cyclicité est inéluctable ? Est-ce qu’il est souhaitable de participer au contre-pouvoir ou au contraire de l’accélérer pour passer plus rapidement au prochain cycle ? Mes propres explorations dans la dualité allouée au numérique en tant que pharmakon me font douter de sa nature éducative au sens où l’entend Seymour Papert :

A few talked about the computer as a teaching machine. This book too poses the question of what will be done with personal computers, but in a very different way. I shall be talking about how computers may affect the way people think and learn. I begin to characterize my perspective by noting a distinction between two ways computers might enhance thinking and change patterns of access to knowledge.

Mindstorms, Seymour Papert

Le passage à l’échelle est trop brutal pour qu’il soit compréhensible et intégrable, l’accompagnement requérant un temps long s’il doit se faire sans violence. Notre capacité à entrevoir les possibles se trouve être masquée par nos dégoûts de l’actuel que nous n’arrivons pas à changer suffisamment rapidement alors qu’ils se trouvent être chaque jour plus visibles.

L’acceptation de ces fake news est un moyen d’auto-défense envers une réalité qui nous dépasse. De protection d’une intégrité qui pourrait voler en éclats en cas de déstabilisation trop forte. Il s’agit d’un criant besoin de repères sur un territoire nouveau qui manque de mécanismes de contrôle traditionnels, le fascisme étant avant tout un mal-être externalisé.

Lorsqu’une activité outillée dépasse un seuil défini par l’échelle ad hoc, elle se retourne d’abord contre sa fin, puis menace de destruction le corps social tout entier.

Ivan Illich cité dans Rencontre improbable entre von Foerster et Snowden (cache)

Chacun essaye de (sur)vivre dans son propre processus d’individuation, composant avec les altérités des différents niveaux qui l’entourent. En embrassant la complexité du monde d’une part, en acceptant la fragilité du soi d’autre part. Comment revenir à des outils numériques proposant une échelle compréhensible par tous ? Quelle est notre limite cognitive actuelle vis-à-vis des liens facilités par la technologie ?

En relisant la définition des outils conviviaux, je ne peux m’empêcher de penser que ScuttleButt donne des pistes en matière de stockage et d’échanges mais surtout de moyens de mise en relation. Une FAQ vient d’être publiée afin de mieux comprendre les concepts sous-jacents et notamment comment les connexions sociales sont réalisées.

La où la disruption mène à la violence, la réduction favorise l’apaisement. C’est l’un de mes objectifs actuels en tant que développeur web de résister à l’un et de tendre vers l’autre.

Merci à Aurélien de m’avoir ouvert des perspectives, vous devriez travailler avec lui.


★ Spectre et autisme

28 April, by David Larlet[ —]

I like being alone. I have control over my own shit. Therefore, in order to win me over, your presence has to feel better than my solitude. You’re not competing with another person, you are competing with my comfort zones.

Horacio Jones

J’ai offert La différence invisible à Noël. Ce qui signifie que je l’ai lu car j’offre rarement un livre sans savoir ce qu’il y a dedans. Et au fil des pages, j’ai commencé à me dire qu’il y avait beaucoup de similitudes entre ce que l’héroïne ressentait et certaines de mes expériences. J’ai gardé ça dans un coin de ma tête pensant que le biais était bien trop énorme pour être pertinent. Au détour d’une nuit d’insomnie, je commence à lire des articles sur le sujet (merci Aurélien !) ainsi qu’à consulter la documentation locale. Puis me résoudre à remplir un quiz puis d’autres et toujours me retrouver à la limite sur le spectre en présentant un nombre non négligeable de traits neuro atypiques. Je ne ressens pas le besoin d’aller plus loin pour l’instant en le faisant diagnostiquer de manière sérieuse.

Les retours (cache) de découvertes (cache) tardives ont ceci de commun qu’ils sont une libération. Pour ma part, je ne sais pas si je me sens rassuré ou résigné. Ni diminué, ni augmenté, cela me conforte dans l’idée que l’adaptation est pour moi de la survie. Et qu’elle me demande énormément d’énergie selon les situations. À travers ce prisme, j’ai des pistes pour tenter de comprendre pourquoi certains bruits, certaines lumières et même certains sites me sont insupportables (cache) mais aussi pourquoi je travaille de la maison, à l’étranger en ayant ma propre entreprise (cache). Et beaucoup d’autres choses encore (confort, inclusion, résilience) qui prennent un éclairage différent à la lumière de cette éventualité.

Difficile de savoir si la prévalence de l’autisme (cache) est bien réelle ou provient d’un changement dans son interprétation, elle semble prépondérante dans l’informatique en tout cas. Il semblerait aussi que le facteur héréditaire (cache) soit non négligeable et c’est peut-être ce qui me préoccupe le plus dans mon accompagnement. Quoi qu’il en soit, cela m’a plongé dans une profonde introspection ces derniers mois qui a menée notamment à la mise en pause de mes correspondances. J’espère que la publication de ce billet permettra de relancer la machine, j’ai l’impression d’être dans la phase d’acceptation qui précède la reconstruction.

Je suis loin d’être le premier à me servir de mon blog pour partager des atypies psychologiques, Kenneth Reitz (cache), Benjamin Bayart (cache), Pep (cache) et d’autres (cache) l’ont fait avant moi et je les remercie car cela m’a aidé à écrire à mon tour. Constater au quotidien que ce monde n’est pas binaire et que les différences de chacun en font sa force est un grand pas vers l’acceptation d’autrui.

Note : il parait que les autistes ont participé à l’évolution (cache) de l’espèce humaine (cache) ce que je trouve à la fois enthousiasmant et malheureux.


★ Confiance et transparence

22 April, by David Larlet[ —]

Dans un univers en état d’équilibre thermique, aucun événement ne pourrait plus se produire en raison de l’absence de dénivellation. Dans un cercle en état d’équilibre d’information, il n’y a plus aucune information. Dans un groupe en état d’équilibre humain, d’homogénéité humaine, il y a entropie. Mais l’entropie, c’est exactement l’équilibre de la mort. Il nous faut être attentif, si nous acceptons les généralisations qui ont été faites par d’autres, à ce que l’adaptation parfaite des uns et des autres dans un groupe signifie en réalité la disparition de la vie de ce groupe au profit de sa mécanisation. L’unité accomplie dans le mouvement politique signifie la disparition de la vie dans un système donné. […]

Or, je peux dire que l’orientation vers une conception unitaire de la nation sous la puissance organisatrice de l’État, comme l’orientation vers l’adaptation généralisée de l’homme à son milieu sont des tendances qui accroissent l’entropie et diminuent la vie. Dans ce mouvement, l’illusion politique a son rôle fort précis à jouer, qui est de présenter un simulacre, un faux-semblant d’information, de courant vivant, de fixer les passions sur de fausses réalités, cependant que les mécanismes adaptateurs fonctionnent, et d’éviter les heurts et les refus au niveau de la réalité de la société nouvelle.

La seule voie pour maintenir l’État dans son cadre et sa fonction, pour restituer à la problématique vie privée-vie politique une réalité, pour dissiper l’illusion politique, c’est de développer et de multiplier les tensions. Cela est également vrai pour l’individu et pour le corps politique. Je pense que seuls les processus de tension et de conflits sont formateurs de la personne. Non seulement sur le plan le plus élevé mais aussi sur le plan collectif.

L’illusion politique, Jacques Ellul.

La faible réactivité de l’État est parfois nécessaire pour laisser le temps à ces tensions de s’installer. Vouloir niveler trop tôt (cache) est une occasion perdue d’une appropriation citoyenne. C’est proposer une escalator là où quelques marches et encouragements auraient suffit. Sans compter le coût de mise en place et de maintenance.

Mastodon est un réseau distribué fondé sur la confiance entre les personnes d’une même micro-culture puis à une autre échelle entre ces micro-cultures à travers les connexions entre instances. Il y a l’opacité des relations humaines dans ces différentes relations de confiance. Certaines sont rendues publiques, d’autres pas. Certaines ont une gouvernance collective, d’autres pas. Certaines sont légales dans certains pays, pas dans d’autres. Cette complexité est propre à chaque communauté et ne peut être résolue à l’échelle d’un pays ou d’une administration. Du moins de manière démocratique.

Lorsque la confiance est rompue, il reste la transparence. Je creuse depuis quelques jours les technologies et concepts autour de Secure ScuttleButt (SSB pour les intimes). À la différence de Mastodon, il ne s’agit pas de technologies web (cache) et Robin a fait un excellent article d’introduction (cache) que je vais tenter de résumer en trois points clefs :

  1. Chaque périphérique est une identité (plus spécifiquement possède une clé privée) qui va émettre un flux incrémental de messages signés.
  2. Les messages du flux s’échangent en pair à pair, je ne stocke que ceux de mes amis et de leurs propres amis pour suivre les discussions et rendre le réseau plus résilient.
  3. Le stockage est chiffré et sa représentation (interface utilisateur) est à la libre interprétation de l’implémenteur. Il existe actuellement des clients graphiques mais c’est l’API qui fait référence.

Autant dire que c’est à des années lumières d’un Twitter décentralisé :-). Ici chaque nœud comporte ses données et devient le centre de son propre réseau pouvant être connecté ou non à Internet. On touche mine de rien avec ces technologies à une certification forte de l’identité/la clé utilisée. Je pense que c’est trop intelligent pour pouvoir percer et qu’il faudra encore quelques itérations pour une prise de conscience collective de ces enjeux mais le cap est techniquement enthousiasmant.

Au niveau des inconvénients, il y a bien sûr ceux relatifs à la performance car le pair-à-pair consomme forcément davantage de ressources pour chaque nœud mais le stockage des flux des amis des amis limite les pics que j’avais pu avoir avec d’autres réseaux du même type. Qui dit chiffrement dit forcément aussi problématiques associées à la gestion des clefs, pour l’instant une clef est générée par périphérique et au passage il n’y a pas à ma connaissance d’implémentation pour téléphone intelligent(-mais-pas-trop-sinon-on-pourrait-faire-du-mesh-sans-payer-une-dîme-aux-constructeurs-et-opérateurs…).

On retrouve la dualité confiance humaine (Mastodon) vs. transparence algorithmique (SSB), observer où vont se déployer les intérêts personnels, politiques et économiques sur ce curseur est fascinant à plus d’un titre. Plus que jamais, les réseaux que l’on rejoint en disent beaucoup sur nos affinités politiques et notre conception du monde.

Entre la Pachysphère et le Scuttleverse, je ne saurais trancher. D’un côté la communauté francophone qui redécouvre les avantages et les inconvénients d’être en comité restreint, de l’autre des personnes qui expérimentent sur des concepts qui me tiennent à cœur. Après tout les deux ne sont pas antithétiques, mais mon attention est limitée :-).


★ Micro-cultures and governance

7 April, by David Larlet[ —]

A new system of governance or collaboration that does not follow a competitive hierarchical model will need to employ stigmergy in most of its action based systems. It is neither reasonable nor desirable for individual thought and action to be subjugated to group consensus in matters which do not affect the group, and it is frankly impossible to accomplish complex tasks if every decision must be presented for approval; that is the biggest weakness of the hierarchical model.

Stigmergy (cache)

The recent hype within the French community about Mastodon is fascinating and raises some questions about decentralisation. At first, everybody jumps on main instances for the sake of simplicity and that’s normal. Consider it as freemium, you have 15 days (followers?) to evaluate the product and invest some time to choose and/or install the instance that fits you. The next step is to stick to traditional model and join an instance you trust (like being employed by a company) or to be tech-savy/confident enough to install and maintain your own instance (like acting as a freelance). And then come cooperatives-alike instances, the ones requiring to care about values and ethics.

Why is that important? Each Mastodon instance creates a micro-culture and links between these micro-cultures are done by humans. One line of “code” added, thousands of new connections made possible. Another one is removed and a lot of relations are broken without even being noticeable for users. Having that responsibility should be daunting for each instance administrator. That’s why I decided to co-create a cooperative after years of freelancing. It was both too easy and too difficult to deal with moral questions alone. Efficiency versus exploration. How do we decide collectively which instances we would like to be linked to? How much time can we dedicate to that task?

There are already initiatives to finance and share the responsibility of instances and that’s great. I’m more inclined to host an instance at scopyleft.fr than at larlet.fr for the same reasons. And invite peers to join the governance, discussing and sharing together before doing and working together.

The more I think about all that, the more I realise that federating identities into a unique one is an old model we may want to avoid with real decentralisation. Even with strong self-integrity you do not (re)act the same way given the group you’re in, multiple identities may allow to generate multiple circles of trust (hello G+). Either inter-connected or not. How these relations will evolve at scale based on governance and self-interest is still to be observed. Oh, and acted. Wait, tooted.

Note: disconnected instances will probably hurt Slack too, maybe more that Twitter actually.


✍ Lettre à Éric

5 April, by David Larlet[ —]

Éric,

Je comprends tes réticences (cache) vis-à-vis de Mastodon, j’ai eu les mêmes assez rapidement mais je continue de creuser en me posant des questions sur la fédération d’identités ou l’expérience utilisateur. C’est la beauté d’un réseau naissant avec les tâtonnements de chacun. Proposer une solution compliquée et découvrir qu’il en existe une plus simple. La communauté itère dans un voyage initiatique qui est nécessaire pour atteindre les limites de la décentralisation. Celui-ci doit se faire ensemble sans brûler les étapes au risque d’en perdre en chemin et de créer un réseau plus élitiste que ce qu’il n’est déjà.

Je suis ravi que l’instance la plus populaire n’arrive pas à tenir la charge, ne surtout pas l’optimiser et laisser d’autres prendre le relais pour atteindre un réseau réellement décentralisé. Je ne pense pas que tu aies eu tout de suite ton nom de domaine et ton hébergeur de confiance pour tes courriels, il en est de même pour ton identifiant Mastodon. Il évoluera au cours du temps, des données seront perdues mais tu auras probablement sauvegardé ton graphe de relations en attendant mieux (le CSV d’export est une liste des différents identifiants).

Quelle chance de pouvoir faire une expérience de cette échelle qui implique de la décentralisation et de la liberté. Il n’y a pas de stratégie, de gros acteurs ou quoi que ce soit, juste un joyeux bordel qui apporte du fun. Et ça fait du bien.

David


0 | 10 | 20










mirPod.com is the best way to tune in to the Web.

Search, discover, enjoy, news, english podcast, radios, webtv, videos. You can find content from the World & USA & UK. Make your own content and share it with your friends.


HOME add podcastADD PODCAST FORUM By Jordi Mir & mirPod since April 2005....
ABOUT US SUPPORT MIRPOD TERMS OF USE BLOG OnlyFamousPeople MIRTWITTER