HOME > RSS > BLOGS France > Biologeek

R S S : Biologeek


PageRank : 2 %

VoteRank :
(0 - 0 vote)





tagsTags: , , , , , , , , ,


Français - French

RSS FEED READER



✍ Lettre à Yohan

2 December, by David Larlet[ —]

Yohan,

C’est un plaisir de travailler avec toi depuis tant d’années, d’abord sur Libé, puis chez Mozilla et actuellement avec Etalab. J’ai l’impression de sortir grandi de nos interactions et tu as indirectement contribué à mes réflexions sur la simplicité dans le développement et au statut de dévelopeur expérimenté.

J’admire ton intégrité lorsqu’il est question d’outils avilissants (coucou Slack). J’apprécie ton humilité et ta soif de toujours explorer plus loin les possibilités que nous offre notre domaine. Il est tellement facile de se considérer comme étant brilliant (cache) dans cette profession qu’une approche impliquant peu d’égo (cache) est exceptionnellement rare. Il y a un enjeu politique dans la ré-acquisition de ses outils mais aussi social dans la (re)prise de contrôle que cela procure. On ne se fatigue plus à courir après les dernières nouveautés lorsqu’on est en train de les réinventer en se les réappropriant.

Je me demande de plus en plus si proposer les services d’une équipe (cache) qui a l’habitude de travailler ensemble ne serait pas plus pertinent qu’une somme d’égos afin de faire émerger un produit.

Nous avons encore de belles années devant nous :-).

David


✍ Lettre à Simone

1 December, by David Larlet[ —]

Simone,

Ou Peggy, je ne sais plus. Merci pour ces voyages philosophiques et notamment ces thérapies. C’est un angle auquel je suis sensible pour avoir l’impression d’évoluer à mon échelle. Prendre soin en ayant davantage conscience de ce qui blesse au quotidien.

Ce qu’il me manque en tant qu’expatrié c’est de pouvoir participer aux après-midi et échanger avec d’autres sur ces thématiques. En espérant que cela t’encourage à continuer, et pourquoi pas… à essaimer.

David


★ Bugs et complexité

27 November, by David Larlet[ —]

« Lorsque nous utilisions des systèmes électromécaniques, nous pouvions les tester de manière exhaustive », regrette Nancy Leveson, spécialiste d’astronautique, d’aéronautique et de sécurité logicielle au MIT. Les systèmes logiciels sont différents parce qu’ils peuvent être changés à moindre coût, qu’ils sont sans cesse mis à jour et bien plus complexes. Pour Leveson, « le problème est que nous essayons de construire des systèmes qui dépassent notre capacité à les gérer intellectuellement ».

Réinventer la programmation ? (cache)

La recherche d’exhaustivité dans un système complexe est une bataille perdue d’avance contre des moulins à vent. Ce qu’il faut tenter d’améliorer ce n’est pas la réduction du nombre de bugs en amont mais la réactivité pour corriger ceux détectés lorsque le système est en place. Un logiciel (non-critique !) devrait être fait pour répondre à 80% des problématiques rencontrées. Si nous sommes si loin du compte aujourd’hui — en tout cas dans le Web (cache) — cela est dû au manque d’empathie des développeurs vis-à-vis de bénéficiaires qui ne peuvent exprimer leurs voix de façon pertinente à la fois par manque de compétences et de moyens de communication. Il est quasi-impossible de savoir quel est le ressenti d’une personne utilisant un outil informatique au sens large. Autant les frustrations que les joies seraient pourtant requises pour améliorer le système, mais comment réussir à faire une synthèse de ces ressentis ?

Ma solution actuelle est de tenter de réduire les boucles de rétro-actions permettant d’améliorer le système de manière progressive et éclairée ; une fois que la problématique a été elle-même simplifiée afin d’en réduire le périmètre. La complexité qui ne peut-être débuguée est un péché d’orgueil, pas forcément celui du développeur. Je ne pense pas qu’il faille réinventer la programmation en elle-même mais plutôt les conditions de son application et surtout de son évolution. Interviewer des utilisateurs en amont d’une conception ET une fois le système mis en production est malheureusement loin d’être une pratique courante.

Les languages et les modélisations afférentes ne sont que des grammaires sans vies, l’équipe et sa connaissance d’une problématique donnée sont les composantes qu’il faut soigner. En laissant le temps à la confiance de s’installer, condition indispensable à l’ouverture qu’est cet autre : l’utilisateur. Ce partenaire d’une symbiose dont on essaye de créer l’outil sans en mesurer les appétences ni les conséquences (cache).

Aujourd’hui encore, trop de développeurs regardent sur Stack Overflow, l’une des grandes plateformes de partage pour développeurs, les méthodes des autres, copient des bouts de code et de fonctions, les collent ensembles et les ajustent par itération. Ça fonctionne jusqu’à ce qu’on tombe sur un vrai problème !, souligne Newcombe.

Ibid.

Stack Overflow est l’équivalent de l’encyclopédie Wikipedia dont les entrées se font en langage naturel (par des questions) et il ne s’agit pas de copier bêtement des résultats mais d’analyser les différentes réponses pour se faire son propre avis sur une question complexe. Il ne s’agit pas uniquement d’assembler du code d’autrui mais de liens vers des documentations officielles mal indexées ou des parties de RFC (Request For Comment) pertinentes pour une problématique donnée. Je ne connais pas d’équivalent dans d’autres profession, aussi je conçois que cela soit difficile à appréhender. Le seul malheur de la plateforme est d’être détenue par des intérêts privés ce qui met notamment en question la pérennité d’un tel service. Je suis un développeur moyen qui utilise cet outil de manière quotidienne et je n’en éprouve aucune honte. Un grand merci à mes pairs qui viennent alimenter cette base de discussion continuellement mise à jour.


★ Async Python Frameworks

18 November, by David Larlet[ —]

There is a new lightweight, fast, minimalist, you-name-it framework each week within the Python community. Why? Because it’s simple! You may want to take that path too and if you do, don’t make the same mistakes as we did. Come share your own frustrations and let’s build a new one together, in 10 minutes  — How to build an async pico web framework from scratch

I gave a talk at PyConCA on that topic, feeling legitimate given that we actually did it! Here are some notes about my intervention.

Context

I’m working with the French government via State Startups. Our goal is to explore solutions for a given problem faced by citizens and/or administrations. These last 6 months, we experimented a way to localize unmanned aerial vehicles (UAVs a.k.a. drones) in real-time for the whole French territory. With a distributed team, we tried to figure out if the law was applicable and if a centralized database would make sense for all parties (citizens, industrials, police, army and so on).

There was a bunch of unknowns, especially related to performances. When you are (in)validating proof of concepts, you might think that performances are your last concern but we wanted to be able to try the service for real. Plus, you never know when a proof-of-concept finally goes into production…

We roughly estimated that we will have to be able to handle about 50k requests per second. In Python. With a unique server. Spoiler alert: for a lot of non-technical reasons, we did not stressed the API for real so we cannot guarantee that our framework can hit that peak. Nonetheless, I think the process was interesting because that is the first time in my career that I had to put my developments under such constraints.

We knew Django and Flask, we already experimented with Falcon. You cannot achieve that level of performances out of these frameworks given our resources. That is why we dug into the async side of Python 3. And it was fun! At first we thought that Sanic was the perfect candidate but soon enough we bumped into issues related to testing and the API did not click with us. So, after an intensive workweek of sleep deprivation and big waves in the ocean, we started to hack on our own framework. And it was crazy!

Coopetition

First of all, this is not a competition. It is challenging to compare concepts and implementations. We had no guilt to steal clever parts, documenting what we think is better for our needs. What we made is not a framework for anybody. Micro means specific and as such incomplete. That is why I encourage you to do the same for your own needs.

Go read the code of your current web framework, it is a gold mine of hacks to deal with inconsistent HTTP-related specifications :-). Seriously, assembling your own framework will make you learn a ton of things. From request parsing to header security, from CORS-related issues to multipart nightmare of latin-1 encoded filenames, from conflicting specifications on Cookies to crazy Accept headers.

Our philosophy was to give a decent developer experience while uncompromising performances. To achieve that we knew that we had to stay minimalists and reuse small and performant librairies.

Benchmarks

We are still working on it and for sure a benchmark is a lie. We use wrk which is kind of ab on steroids. Anyway, I think we are missing a tool in the Python community to be able to compare performances across pull/merge-requests. Like continuous integration with metrics on introduced bottlenecks, continuous performances? If I missed anything on that topic, please drop me an email.

Edit: Ronan made me discover airspeed velocity, nice!

The smallest async web response we were able to compute is the following:

class Protocol(asyncio.Protocol):

    def connection_made(self, transport):
        self.writer = transport

    def data_received(self, data: bytes):
        self.writer.write(b'HTTP/1.1 200 OK\r\n')
        self.writer.write(b'Content-Length: 25\r\n')
        self.writer.write(b'Content-Type: application/json\r\n')
        self.writer.write(b'\r\n')
        self.writer.write(b'{"message":"Hello bench"}')

Once you have that hardcoded response, set uvloop as your event loop and create a task for it:

asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())
loop = asyncio.get_event_loop()
server = loop.create_server(Protocol, '127.0.0.1', 8000)
loop.create_task(server)

Here we go, for more details, check out the whole file in our benchmarks. But basically you have all important parts here. That’s great but a bit too low-level for our taste!

Enters Roll which adds routing and request/response parsing in roughly 300 lines of code. An example of the same kind of response would be:

asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())

app = Roll()

@app.route('/hello/{parameter}')
async def hello(request, response, parameter):
    response.json = {'message': f'Hello {parameter}'}

We have routing and JSON serialization under the hood with dynamic response given the passed parameter in URL. No big deal but it’s quite handy compared to the raw version. Note that we lost about 63% of the initial number of requests per seconds just doing that!

Hint: it’s still better than the “concurrence”. 

Optimizations

Python 4 is already here, and it’s called Cython. — My coworker

Me: Rust is probably Python 5 (cache)! It escalates quickly when we are trolling :p

We My crazy coworker wrote a routing system using Cython to improve performances and the jump was significative to say the least. That is part of our approach: finding small existing pieces or write our own if we think we can code a faster solution. Once you expose what you consider is the right API, it’s easy to swap a given piece from one to another without introducing breaking changes.

For instance, we are currently using the awesome httptools to parse the request and the URL but that might change if we find a better approach. We only have these two dependencies for now and that is by design. We are really careful and conservative on introducing new features, trying to keep aesthetic in mind. Each new addition is benchmarked and heavily discussed in terms of developer experience. This is always a tradeoff.

One of our core principles is to ease the plug-ability via extensions and custom subclasses of core components. We are missing a way to get benchmarks of these additions though. Maybe tools like perf will help in the future, ideally it would allow us to make a table of performances given the activated extensions. Too many benchmarks are way far from real-life requests/responses treatments.

An option we did not explore yet is the use of newly introduced annotations like did APIStar to only parse/evaluate pertinent parts of the incoming request. Not sure it will work in our particular case though.

More than code

That part is really intimate. I enjoy taking the time to carve my own tools and challenge my assumptions with experimented colleagues. I can feel the progression, both on a personal point of view and as a team. You might think that time is lost and building your own “homemade framework” is such a waste and will be painful to maintain. That is OK and I used to think that too.

With as much hindsight as I can under such short notice, I think it saved us as a team to build that core reusable component when we were targeted by politics-related issues and pressure from all parts. It was kind of a safe place where we can focus for half a day and come into that pair-flow state, knowing that we were producing an open-source common.

Take aways

Do it! It has been a hell of a rollercoaster to code our own solution but we are quite happy of the result and we know that we will reuse it for future and ancient projects so the return over investment is not null even if we did not put the actual project to production. And by the way, the technical challenges along the way were as much interesting as the end result so no regrets whatsoever. Bonus: it built confidence in our capability to overcome problems and made us a better team.

Don’t do it!!! If you are not mature enough as a team to take the time to craft a tool that will fit your needs, it is probably better to reuse existing ones. It will be more generic and there is no problem with that: 99% of the time this is the more pertinent approach!

Have fun roll-ing out your own framework!


★ Distributed teams

5 November, by David Larlet[ —]

I am not a remote worker, I am a part of a distributed team.

Remote is Dead. Long Live Distributed. (cache)

It has been ten years today that I started to work within distributed teams. I honestly don’t know how I would go back nowadays to an office with all my colleagues in the same room. It would mean that we all have the same rhythms, constraints and wishes. That equation looks just impossible for me to be effective. It doesn’t match my way of being and working.

These last six months, we assemble a team with Yohan and Vincent to accomplish quite some work (more to come about all this) and even if we were on different timezones it worked quite seamlessly. Not because of agile processes (whatever it means) but because we’re part of a culture of feedback, empathy and respect. Pairing one hour or two per day looks natural, working transparently and sharing your mood seems logical, taking the time to perform pro-active reviews and learn new things is normal. Acquiring this maturity takes time though and I’m still working on it.

What I learned these last ten years is… drum rolls… that communication is key. I’m sure you are suddenly mind-blowed by such an unexpected and profound advice. And still, so many teams are failing because of this. Or more accurately lack of. I tend to think that being distributed somehow helps on that topic with asynchronous communication and different ways of interacting. You are forced to communicate to feel part of the team. Cohesion is made by links and not anymore by presence, that is kind of a paradigm shifting.

Another sort of cliché advice is that documentation matters, be it a one-page vision at high level, a 6-page memo (cache) at middle level, a couple of architecture decision records (cache) to document architecture decisions and/or technical RFCs (cache) as management tools, writing down why you did it that way, how you are currently experimenting and what you will do soon is clearly underrated.

Note that I would love to state that working full-time remotely is possible. But it’s definitely not. You have to meet your colleagues in-person at some point. It can be once a week, a month or a year depending on how mature you are to deal with tensions and frustrations. Even companies like Mozilla or LincolnLoop have to setup workweeks on a regular basis.

Last and not least, your behaviour will last. I was very upset 2 or 3 times this decade and it was always extremely bad for me on the long run to ruminate these situations for so long, not feeling happy with my confrontations. My take away is that integrity is better than money and sometimes taking distance is necessary and clearly better than fighting back immediately with anger. Once again, nothing new nor disrupting here, be easy to work with (cache) and anticipate delicate situations as much as possible is my professional motto.

What the next ten years will be alike? Hard to say, I always wonder what would be even better to me and I think I reached some peak where I feel valuable to a team/product without being too stressed. And that’s finally all that matters.


★ Into the Wild

26 October, by David Larlet[ —]

For the many tribes that once inhabited the forest, the threat of fire destroying their homes was a serious one, but they lived in such a way that they were able to move quickly away from danger. This was their home, though, and to think of it as a wilderness — as we do today — is incorrect. They adapted a way of life that was completely natural to them, and the abundance of the forest met all of their needs. It was home to them, every bits as much as a farm would be to a rural dweller today. Both live off the land and create comforts that make a place a home. Indeed, there is no First Nation word for wilderness — it’s not just alien to them as it become to us. Interestingly, too, they have no word for ‘outdoors’, because there is no delineation between being out of doors and in. That’s the kind of thing that really interest me — the knowledge, the skills that I acquired, which make me feel completely at home, at one, with a wild place like this.

Northern Wilderness, Ray Mears

I spent three days in the wilderness. Alone. When I say that to somebody, the first reaction is often to ask if that was a survival trip and if I had to confront myself to the elements. It makes me a bit sad because my goal was just to be within the nature and enjoy the moment as being part of it. Nature is not an hostile place per se, nature just is. As such, my plan was not to fight against something but just be. Time to learn new skills, time to meditate, time to observe and listen to the music of life. To acquire enough confidence to go with a 4-years old child.

Nature looks so distant to us these days that we consider it as an enemy. I rather tried to embrace it. The easy way. Sort of.

Earn or learn

As a record for future explorations:

  • earn: dealing with food hanging was a bit cumbersome but easier than expected, required for bears and raccoons.
  • learn: going without a tent, a mattress and a duvet was a bit too much when not acclimated, a blanket and a tarp are not enough when it is literally freezing at night.
  • earn: filtering water worked as expected, note that it makes you pee more, especially combined with tea (definitely not cool during cold nights :p).
  • learn: listening at packs of wolves howling at night back and forth is great, excepted when one is responding OMFG-too-close and you have to start up a new fire for the whole night!
  • earn: lightning up a fire and maintaining it without burning the whole forest, conditions were good except for how soaked everything was after three days of heavy rain.
  • learn: relying on fishing for better meals is hard because of the constraints (having a fire ready, good timing, proximity of the appropriated place, risks of attracting bears and so on).
  • (l)earn: practicing bushcraft skills, a bit frustrated by the lack of time I had to setup a proper camp with at least an elevated bed to isolate myself from ambiant humidity and maybe a fire reflector to warm it up by night.
  • earn: not so many bugs at this season compared to the spring, it can drive you crazy very quickly if you do not have appropriated equipment day and night.
  • learn: my backpack was as heavy as my fears (and I had so many!), I knew it and I knew also that I had to experience it before opting for lighter options, that process requires confidence.

Next time

Well, winter is coming© so I have to bring back my dedicated equipment from France prior to go camping by minus thirty Celsius degrees. At least, there will not be bears. But hungry wolves. Can’t wait :-).


★ Le bruit et l’odeur

29 September, by David Larlet[ —]

vieux
on ne veut plus de bruit
qui fasse mal
jamais plus
moins à cause du mal
que de la mauvaise qualité
du bruit
le mal n’est plus alors l’apanage
du corps, c’est désormais
le cœur qui assume
le cœur qui récole
le cœur qui subit
et il lui arrive qu’on hurle :
« suffit ! »

vieux
on ne désire
que le silence
des anciens conifères
le silence vertical
le silence des épines gelées
et des fruits secs
si pleins de promesses d’alcool

vieux
on ne sourit plus
qu’aux bruits minuscules

Mon bruit, Normand de Bellefeuille

La référence est terrible et il m’a fallu du temps pour apprécier la pertinence d’une telle communication. Les années passant, je comprends de mieux en mieux l’importance de faire appel à des sens qui s’exacerbent et rendent de plus en plus intolérant. J’ai maintenant du mal à accepter une mauvaise qualité de son. C’est peut-être pire pour une odeur trop forte. Je ne sais pas comment interpréter ces nouvelles sensibilités.

Puisque l’on en est à ce genre de confidences, je m’interroge de plus en plus sur le chaos qui vient et sa théorisation. Quelle place avoir dans cet avenir ? Quels savoirs acquérir en préparation ? Comment transmettre une partie de nos échecs aux générations futures ? De plus en plus tenté d’aller passer du temps en forêt pour méditer là-dessus.

Sentir, entendre, voir ne sont pas des facultés politiquement indifférentes, ni équitablement réparties parmi les contemporains. Et le spectre de ce que perçoivent les uns et les autres est variable. Il est au reste de rigueur, dans les rapports sociaux actuels, de rester à la surface, de crainte qu’un convive ne soit pris de vertige en abîmant son regard en soi-même. Si tout le cirque social dure encore, c’est parce que chacun s’échine à garder la tête hors de l’eau quand il faudrait plutôt accepter de se laisser tomber jusqu’à toucher quelque chose de solide.

Pour la suite du monde - comité invisible (cache)

Et peut-être en revenir encore plus sauvage. En ayant transformé du savoir en connaissance. Pour être ensuite en mesure de convertir des savoir-faire en pouvoir-faire (cache). Toujours ce besoin d’être en capacité.

Ou plutôt de ne pas être en incapacité ?


★ Besoin et expérience

29 August, by David Larlet[ —]

Mais à notre grande surprise, la plupart des personnes qu’on a interviewé se satisfont pleinement de ce que propose Sud Web aujourd’hui et n’aspirent pas au changement. Étonnant ? Pas étonnant ? Moi je trouve ça vraiment étonnant, voir même paradoxal… De ce que j’avais pu entre-apercevoir de la communauté, je m’attendais à de multiples réflexions, de remises en question, l’expression d’un positionnement fort sur les valeurs. Je me disais, à la vue du fort sentiment d’appartenance des participants à la communauté, que tout le monde aurait l’élan de contribuer à l’amélioration du truc.

En fait pas du tout ! La communauté a une confiance énorme en l’équipe et en les personnes qui participent et elle n’aspire pas naturellement à réinterroger les fonctionnements.

Ratatiner les croyances pour sublimer les valeurs (cache)

En préambule, je suis très heureux de voir que les énergies et les questionnements continuent d’être au centre de l’organisation de SudWeb. Et d’autant plus lorsque cela donne lieu à un partage sur le retour d’expérience. J’espère ne pas trop faire mon vieil aigri dans ce qui va suivre.

Cela fait presque une semaine que je m’interroge sur cet article et ses conclusions. Je pense avoir mis le doigt sur ce qui me gratte à ce sujet : l’application de LEAN à une expérience et non à un besoin. Peut-on appliquer les interviews de Running LEAN à un support pour relations sociales ? Je pense être assez mal placé pour m’avancer là-dessus. Néanmoins, il me semble que l’on peut difficilement prendre le recul nécessaire pour savoir si la modification d’un environnement va avoir un impact positif ou non sur ces relations avant de l’avoir vécu. Et c’est là où la méthode prédictive basée sur un échantillon atteint un peu ses limites.

Avoir plusieurs années d’expérience donne d’autant plus de légitimité pour expérimenter et d’assurance pour se relever en cas d’échec (encore faudrait-il définir cette éventualité). Un événement récurrent donne la chance de pouvoir considérer chaque itération comme une page blanche, les « acquis » ne se font pas sur les formats mais sur le réseau (ou micro-culture) qui se recrée à chaque fois. Renforcer des liens pour le sentiment d’appartenance d’un côté, en relâcher d’autres pour être inclusif par ailleurs. Une communauté vieillissante aspirera toujours à plus de sécurité et de confort. Et est-ce une raison valable pour les lui accorder ? :-)


★ 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


0 | 10










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