Gil Cot ✔ a écrit 5730 commentaires

Je suppose que tu n'as pas lu la réponse de tissac qui parle justement des personnes auditées qui sont mises au courant.
Mais ça n'enlève rien au fait que l'analogie est foireuse parce-qu'il ne s'agit pas de mettre au courant les personnes individuellement mais la hiérarchie (charge à elle de savoir vers qui redescendre l'information ou pas) et là ces prétendus chercheurs n'ont contacté aucune autorité représentative mais ont pris leur décision de sabotage unilatéralement.
Déso de remettre une couche, ce point ayant été soulevé par Zatalyz et Zenitram, mais tu sembles pas voir que tu fais un parallèle entre un kiwi et un oignon.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Dans ta liste, il y a bien
1) mise en place d'un(e) règlement (ou charte) intérieur(e) ; pas un « comité éthique » remarque
2) demande de respect de la loi, ou du règlement de l'organisme de financement ; toujours pas question d'éthique
3) l'aval d'un comité d'éthique dans certains cas ; et tu décris quelque chose qui n'a rien à voir avec le point 1) (et c'est la remarque que nous te faisons depuis le début)
4) des certifications réglementaire et non des évaluations de questions éthiques, et tu vas jusqu'à faire disparaitre l'existence d'un comité (et ce que nous disons depuis le début est justement pourquoi parler de comité s'il n'y en a pas ?)

Ce n'est pas une question que certains d'entre nous imaginent des choses, mais que tu mets le doigt sur un montage manipulatoire qui discrédite la recherche et les universités (et au passage donne raison aux complotistes et toutes personnes qui ne peuvent plus faire confiance aux chercheurs et aux publications bidons.) Tu es toi-même tellement englué dans l'enfumage que tu refuses de voir la déconnexion et refuses de te poser les questions fondamentales :

• C'est quoi l'éthique ? Indice : il y a un lien avec la morale et des valeurs, pas les points de légalité…
• C'est quoi un comité ? Indice : il y a une notion de réunion de personnes déléguées, pas une administration de tamponnage…

Par définition, un comité d'éthique n'est pas saisi à tout venant, et implique que des gens se réunissent et pas pour parler de législation… Arrêtons de fourvoyer les mots.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

À noter qu'un certain politicien Zéro utilise cette rhétorique pour assoir sa « vision transhistorique et inutilement grandiloquente » :-D Je ne connais qu'une référence : la nuit d'avant dodo, quand on nous disait des contes, et que le souvenir semble avoir toujours été ainsi …pour tous.

Pour la trivialité, la compilation du noyau fut un jeu courant, donc commun et banal pour certaines personnes. Ce n'était pas pour autant aisé (il faut s'y reprendre parfois moult fois la première fois.) Encore que je doute que tu ais refait l'opération, les yeux fermés, les autres fois.
Tiens, me rappelle le trivial poursuite où la plupart sèche pourtant sur nombre de questions supposées faciles…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Aujourd'hui, un expert en sécurité qui fait un audit d'une entreprise (sur la demande express de celle-ci) ne s'amuse pas à demander l'autorisation des employés avant de réaliser une opération de phishing ou d'ingénierie sociale. Il va juste éprouver les salariés dans le cadre de leur boulot en condition réelle.

C'est exactement la même chose qu'on essayé de faire les auteurs de l'étude. Sauf que l'un pose un problème éthique "évident" à en lire certains, l'autre pas du tout, c'est normal.

J'adore l'inversion accusatoire qui marche bien sur certaines personnes.
Dans ton exemple, tu parles d'audit …donc d'un truc cadré et fait à la demande de l'entreprise (te le précise entre parenthèses.)
Ensuite tu nous dis qu'une étude est un un audit ? Passons, tu pousses le bouchon jusqu'à faire croire que l'équipe noyau aurait fait la demande expresse à l'université (sans ça ton analogie ne tient pas : l'expert en sécurité ne décide pas unilatéralement de tester une entreprise, c'est dans ce cas un pirate puni par la loi et non un expert payé par l'entreprise.) Et pour finir les chercheurs auraient remis leur rapport d'audit au demandeur ? Trois points sur trois ne sont pas vérifiés dans ton analogie mais bien tenté.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Petite correction : Salt-stack utilise aussi YAML et Jinja
mais avec un paradigme un peu différent.

Je dirais plus qu'un peu différent. Salt utilise un langage de template (jinja, mais d'autres sont dispos) qui va générer du yaml (ou d'autres). Tu as le choix des armes, et tu peux faire tout en python par exemple.

J'oublie souvent qu'il est possible d'utiliser autre chose (certainement parce-que je suis resté à l'usage de Jinja). Mais en prenant juste ces deux composants, je notais juste les deux approches sans entrer dans les détails.

À contrario, Ansible utilise du yaml avec parfois des bouts de jinja dans les chaines. C'est beaucoup plus encadré.

Exactement. Chez Red Hat (c'est l'actuel propriétaire), on fait du YAML avec des bouts de Jinja2 dedans. Cela a obligé à rajouter des mécanismes d'itération pour aller au delà des limitations de YAML.

- name: "Ensure groups exist"
  group:
    name: "{{ item.key }}"
    gid: "{{ item.value.id }}"
  with_dict: users
- name: "Ensure users exist"
  user:
    name: "{{ item.key }}"
    uid: "{{ item.value.id }}"
    group: "{{ item.key }}"
    groups: "foo,bar"
    comment: "{{ item.value.fn }}"
    shell: "/bin/bash"
  with_dict: users

À l'inverse, chez VMware (c'est l'actuel propriétaire), on fait du YAML à partir de Jinja2 ; du coup pas besoin de rajouter d'équivalent des with_ par exemple.

{% for key, val in pillar['users'].items() %}
  "Ensure user {{ key }} exist":
    user.present:
      - name: "{{ key }}"
      - uid: "{{ val.id }}"
      - gid_from_name: True
      - shell: "/bin/bash"
      - groups:
        - "foo"
        - "bar"
        - fullname: "{{ val.fn }}"
{% endfor %}

C'est à dire que, pour le dictionnaire de users suivant

users:
  idi:
    id: 9050
    fn: "Irvin Dirby"
  bob:
    id: 8141
    fn: "Barb Obiwan"

Ansible va appeler les modules et les exécuter avec le dictionnaire qu'il aura préparé comme il se doit. Il a fallu rajouter des mots-clés pour passer les limitations natives du formation de description.
SaltStack va d'abord évaluer le gabarit Jinja2 pour générer le YAML mis à plat

"Ensure user idi exist":
  user.present:
    - name: "idi"
    - uid: "9050"
    - gid_from_name: True
    - shell: "/bin/bash"
    - groups:
      - "foo"
      - "bar"
      - fullname: "Irvin Dirby"
"Ensure user bob exist":
  user.present:
    - name: "bob"
    - uid: "8141"
    - gid_from_name: True
    - shell: "/bin/bash"
    - groups:
      - "foo"
      - "bar"
      - fullname: "Barb Obiwan"

Comme le Jinja2 est évalué avant le YAML, pour faire les équivalents de when il faut passer par le mini-langage de templating aussi.

{% set myvar = salt[…] %}

{% if myvar %}
#conditionned YAML here
{% endif %}

Par contre quand on dépend du résultat de la tâche d'avant, là où Ansible offre register (pour exploitation dans le when), on n'a pas d'équivalent avec SaltStack. Par contre, quand on est amené à faire de la programmation Python (ou juste du Jinja2), on apprécie mieux Salt qui n'est pas aussi contraignant que l'autre.

C'était juste une réponse illustrative pour les gens qui nous liraient en se demandant de quoi on parlait exactement au sujet de cette différence d'approche.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Oups, pas vérifié (c'était dans mes notes) et je soupçonne que ce soit pas temporaire car il y a eu des réorganisations entre temps. Voici un autre lien (vérifié cette fois) https://taktuk.gitlabpages.inria.fr/index.html

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Tout comme Fabric, y a des noms qui ne sont pas trop amicaux avec les moteurs de recherche. Voici : https://doc.bearstech.com/nuka/ (avait été déjà évoqué dans un autre commentaire.)

Tu peux regarder aussi TakTuk et Kanif : http://taktuk.gforce.inria.fr/

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Merci beaucoup pour ces précisions (moi qui m'intéresse à l'histoire de l'évolution des technos, dans un certain sillage, tu m'as plus que ravi.)

Je me souviens de Func, pour avoir joué avec rapidement à titre personnel (j'expérimente pas mal et j'avais testé beaucoup de choses avant d'arrêter mon choix sur Ansible alors en 1.8.etquelque à l'époque.)
C'est vrai que dans le fonctionnement de la commande func ça ressemble pas mal à ansible ad-hoc comme ils disent.
Tiens, le certmaster rappelle l'enrôlement avec Puppet (coucou puppet-cert) ou SaltStack (coucou salt-key) et d'autres. Remarque, on fait pareil sauf que c'est délégué (ssh-keyscan -H par exemple, ou directement ssh-copy-id etc.)

Je n'ai pas connu Taboot. Mais effectivement, leur premier exemple a l'air très familier ;-)

- hosts:
    - 'java0*.web.qa.*'
    - 'someotherhost'
  concurrency: 2
  tasks:
    - yum.Update:
        packages:
          - some-rpm-package-name
    - service.Restart
        service: httpd

Cela devient aujourd'hui (en restant au plus proche)

- hosts:
    - 'java0*.web.qa.*'
    - 'someotherhost'
  serial: 2
  tasks:
    - yum:
        name:
          - some-rpm-package-name
        state: latest #update
    - service
        name: httpd
        state: restarted #restart

Par contre, ils font l'erreur de parler de YAMLscript, ce qui devait déjà amener des gens à vouloir « programmer » avec…
Et sinon, je vois qu'effectivement il était prévu de l'utiliser avec Puppet et Nagios, qui sont des citoyens de premier ordre comme Yum et AJP.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Mais en vrai, du Python avec de forts degrés d'indentations et sans découpage du code, c'est insupportable aussi. En fait n'importe quel langage.

Je préfère déjà :-D Ce n'est plus Y est râté et P est mieux alors qu'ils font la même.

Et pour le coup une syntaxe ouvrante/fermante est plus lisible (même si parfois marginalement).

Qu'entends-tu par « syntaxe ouvrante/fermante » ? Les formatages à la C par oppositions aux formatages par indentation ?

Sauf que, pour des états, des structures de données, la complexité peut être normale, alors que dans du code source, la normalité est de faire des fonctions, de la factorisation, pour garder des ensembles cohérent de code assez petits, et sans trop de niveaux d'imbrication.

Ansible est allé dans ce sens avec les roles et différentes include…
Mais intrinsèquement, les structures de données sont complexes et les host_vars/group_vars permettent un certain découpage (et pourtant je continue à en voir qui foutent tout dans un fichier d'inventaire ini qui contient déjà une ou deux centaines de machines)

[…] Et là parfois tu te demandes bien pourquoi tu n'es pas en train de coder directement en Python.
[…] Est moins évidente, mais permettrait d'éviter la « programmation en Jinja2 ».

C'est souvent que le problème est mal posé ou son approche l'est. (Parfois j'ai l'impression que les gens pratiquent le « pourquoi faire simple quand on peut faire compliqué ? » et c'est encore plus vrai quand on se met martèle en tête que Ansible est un langage de programmation …sauf que là c'est le début du masochisme)
Mais il y a des cas effectivement pas simples qui indique qu'on a atteint les limites d'Ansible de base : il faut soit créer ses propres modules ou y aller directement dans le langage qu'on maîtrise, sinon on fait des playbooks difficiles à maintenir et qui en plus vont rapidement vous péter au visage.

Dans ton exemple, il n'y a pas de Jinja2. Et l'alternative que tu préconises, indique que tu as plutôt besoin de Fabric ou Nuka ou similaire.

Je suis bien d'accord avec ce qui suit :

Mais bref, je trouve que c'est une dérive qu'on retrouve un peu trop dans Ansible, un peu sur le principe de quand on a un marteau, tous les problèmes ressemblent à des clous, si on a déjà une infra Ansible en place, on a envie de tout faire en Ansible.

C'est d'autant plus dommage que l'utilisation d'Ansible ne t'enferme pas, et que l'esprit unixien veut qu'on utilise l'outil qui va bien dans l pléthore qu'on a à disposition. C'est toujours une erreur de faire une fixette sur un outil spécifique.

Ansible doit-il se contenter d'être un outil de description d'état désiré, ou doit-il évoluer vers un outil de programmation distante comme on peut le voir de plus en plus ?

Il y a un besoin qu'il rempli bien et il n'y a pas de raison de changer cela. Pourquoi vouloir que ça fasse le boulot d'autres outils ? On doit arrêter avec les fixettes windowsienne ; la seule évolution que j'attends perso de ces diverses solutions est qu'elles puissent (mieux) communiquer entre elles de sorte à pouvoir être complémentaires.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Un linter qui va avec ça.

Je l'ai mentionné dans un autre commentaire :

pip install yamllint
# c'est générique et servira pour tout YAML qu'on trouve ci et là
# par défaut c'est assez strict et je ne pense pas que l'exemple passe
pip install ansible-lint
# c'est très laxiste sur le YAML, comparativement à l'autre
# ça vérifie les bonnes pratiques émises au fil du temps

Je mets ça en place aussi dans mes CI/CD.

Bref quand on superpose des syntaxes existantes, on obtiens pas le meilleur de chaque monde, mais le pire. On crée un nouveau format qui n'est que partiellement pris en charge un peu partout et cette prise en charge partielle et par effet goodenought ralenti fortement l'émergence d'outils agréables à utiliser.

Je dis justement que ça ne ralenti par certaines personnes (comme moi qui ne recherche pas de syntaxe particulière) mais sinon c'est bien une nouvelle syntaxe…
On peut faire le même parallèle pour DocBook et d'autres comparé à XML au sens générique. J'ai des collègues qui ont du mal parce-que n'ayant pas de syntaxe spécifique alors que moi non.
On peut faire le même parallèle pour tous les DSL (aussi bien celui de Puppet que celui de Structurizr avec lequel je travaille actuellement.)

Et non la solution n'est pas de tripatouiller les fichiers de syntaxes de ton éditeur, tu va avoir un truc qui marchote plus ou moins. La solution c'est d'utiliser le LSP proposé par le projet, mais voila son développement n'a commencé que l'an dernier pour un projet qui a 10 ans.

Ça revient au même pour moi. Si tu utilises lsp, bah il faut créer les fichiers de syntaxe lsp (ou attendre que quelqu'un fasse le tripatouillage pour toi.)
Ensuite j'ai donné des exemples pour Vim qui ont cinq à sept ans d'existence.

En tout cas si je regarde les playbook les mieux notés d'ansible galaxy, ils appliquent tous la règles "on ne quotes que les chaines pour les quel c'est nécessaire". Bon est pour aller plus loin encore c'est aussi la règle qui est utilisée dans le dépôt de playbooks servant à illustrer les bonnes pratiques pointées par la doc d'ansible comme quoi.

La « bonne habitude » est de « juste mettre les quotes pour les chaînes de caractères. » Beaucoup d'erreurs auxquels j'ai répondu sur le forum étaient juste liées à ça : on a pris le raccourci autorisé par YAML et on n'a pas compris ce qui a merdé. Que de temps perdu en n'ayant pas fait les choses correctement dès le départ ?

Quel est le problème avec l'indentation ?

Seconde et troisième lignes (« become: yes et tasks: ») ; ça m'a piqué les yeux …et ça rend l'interprétation ambigüe (est-ce bien au même niveau que hosts: webservers ou au niveau de l'élément de liste - hosts: webservers ? certains diront qu'il y a une espace, mais comme pour Python il est mieux d'avoir un nombre paire d'espaces et surtout le même partout hors on en est à 2 sous tasks…)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Comme tu dis les noms sont trompeurs et ma remarque est qu'on devrait fuir tous ces flous artistiques/politiques (donc bannir toutes les universités américaines si c'est leur cas). Pourquoi ne pas juste appeler un chat un chat et donc parler de legal comity ? Utiliser le mot éthique là où il n'y en a point (que du juridique et de l'image marketing) c'est du même acabit que le green washing et ces manipulations ne devraient pas avoir leur place en sciences…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

De plus, POSIX demande un compilateur C99, aujourd'hui on est bientôt à C23, ce serait dommage de rester sur des anciennes versions juste pour être 100% POSIX compliant.

C'est pas une lecture un peu biaisée ? Et justifiée par la course à la nouvelle ? :-)
POSIX n'impose pas de version/marque/éditeur de compilateur, et ne peut pas demander d'utiliser qu'un compilo C99. Tu peux utiliser C23 ou plus ; c'est juste que tu dois pouvoir compiler avec tout compatible C99 (cela inclus ta nouvelle version de compilateur si elle n'a pas cassé la compatibilité) pour être 100% POSIX.

Une bonne partie des développeurs sensés activent tôt ou tard les warnings (options -W de gcc/clang) qui n'est évidemment pas couvert par POSIX et donc ton utilisation non portable.

Tu sous-entends que, pour toi, les avertissements du compilateur sont incompatibles avec POSIX ? Le but n'était pourtant pas d'avoir une liste figée d'options mais d'avoir un minimum syndical qui fonctionne de manière identique (bien sûr, quand on veut faire portable on se retient d'utiliser des choses qui ne le sont pas, mais de là à conclure que la norme dit que ça ne doit pas exister ça me laisse sans voix.) :-)

POSIX stipule l'option -o de disponible donc quiconque voulait un nom de fichier prédictif devrait l'utiliser de toute manière.

L'un n'empêche pas l'autre et il y a (malheureusement) un nom par défaut stipulé. Il faudrait appeler à une évolution dans la prochaine évolution de POSIX au lieu de juste dire que aux gens qui suivent les règles que ce n'est pas recevable.
Ceci dit, on devrait effectivement/explicitement faire -o a.out (je me méfie toujours des choses implicites car elles peuvent casser et faire perdre du temps) ; sauf que ça n'empêche pas la problématique actuelle de demeurer. :-)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

La doc d'introduction met l'accent sur la facilité de prise en main …ce qui peut être au détriment des bonnes pratiques :-S Probablement le prix à payer pour la bonne affiche (j'allais dire « pour être vendeur » avant de me rappeler que ce n'est pas vendu), en tout cas on ne cherche pas à décourager par certaines considérations.

Ainsi, je ne trouve pas très propre le YAML qui devrait ressembler plutôt à

- hosts: "webservers"
  become: yes
  tasks:
    - name: "install Apache server"
      yum:
        name: "httpd"
        state: latest

On va dire que je chipote, mais :

• Avoir une indentation correcte et cohérente est, comme avec Python, plus facile à lire et limite les erreurs.
• Il faut, systématiquement mettre les chaînes entre « quotes » pour ne pas donner l'impression comme on l'a vu que tantôt il en faut parfois par magie ou sans raison.
• Je ne fais exception que pour différencier les mots clés de l'outil : "latest", "directory", etc. Par contre, dans tous les cas, en ne quotant pas "yes" je différencie bien le booléen de la chaîne de caractères (et certains linters veulent même qu'on utilise carrément "true" et rien d'autre)
• Utiliser "latest" montre bien que l'outil n'impose rien et qu'on peut l'utiliser pour mettre à jour aussi sans trop de prise de tête, mais cette option va à l'encontre des bonnes pratiques si on veut être idempotent…

Maintenant, venons au cas de Jinja2, où encore on a marché sur les bonnes pratiques au profit de la facilité… car l'utilisation de "content" dans le module copy est vraiment à réserver au dernier recours. Et dans cet exemple précisément, on était dans un cas où il aurait fallut faire appel au module template… Tout cela illustre mon propos (l'outil est permissif, ce qui permet de le prendre en main facilement mais avec le revers de pouvoir faire aussi des choses pas proprettes…) Le « FAST » dans le titre indique que les petites violations des bonnes pratiques sont assumées et ça me va : vite fait ne peut être toujours 100% bien fait…

Je reviens au point qui préoccupe. Comme les éditeurs font de la coloration syntaxique pour du YAML c'est donc du YAML pur qui est vu et mis en évidence. Pour répondre à ton/ta besoin/demande, il faudrait rajouter une déclinaison qui serait la prise en compte du DSL… Pour faire une analogie, quand tu ouvres un document XHTML dans un éditeur qui le voit comme du XML, ça va certes reconnaitre qu'il y a des balises et des attributs et pouvoir indiquer les imbrications etc. Mais contrairement à un éditeur HTML pur, ça ne reconnait pas la sémantique qui lui permettrait de distinguer les balises valides des balises farfelues, et reconnaître proprement JS et CSS dedans. C'est exactement ce qu'il manque avec la prise en compte de Jinja2 dans du YAML (et c'est valable aussi si on utilise quelque autre mécanisme : j'ai perso déjà eu à faire des modèles YAML avec des variables shell mais les éditeurs ne savaient pas mettre ces intrus en évidence.)
Je pense/espère que l'éditeur que tu utilises te permets de définir assez facilement ton fichier de coloration syntaxique. Auquel cas, il te faudra partir de celui du YAML et adapter jusqu'à obtenir ton bonheur. Perso, j'utilise essentiellement Vim mais n'ayant pas eu le besoin, je n'ai pas spécialement creusé la question. Je trouve cependant pearofducks/ansible-vim et chase/vim-ansible-yaml (ou erikzaadi/vim-ansible-yaml entre autres) qui mettent en évidence des éléments du DSL. Je n'ai pas testé car je reste plus avec le fonctionnement de base et quelques réglages. Il y a divers approches avec cet éditeur (on parle par exemple de rocannon/vim-assimilate/vim-polyglot par exemple.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Mais le lectorat ici aurait râlé et se serait senti trompé si on avait parlé de PF ; pas simple la vie.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ce que tu décris indique que c'est une université et des gens à bannir de partout …parce-que le comité d'éthique est plutôt un commité juridique, et que quand bien même on teste un human workflow on se cache derrière le fait de faire de la technique.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Je te confirme que tu as bonne mémoire pour AIM d'AOL, je ne sais plus pour ICQ de Mirabilis.
Je confirme aussi que Google a été moteur (probablement ce qui a motivé d'autres à faire des expérimentations ?) et a contribué Jingle (si j'ai bonne mémoire) puis s'est effectivement suicidé. Bizarrement, les autres ne veulent pas en tirer les bonnes leçons…

Pour le dernier point (sur les specs des autres services) tu soulèves un point crucial que je n'avais pas anticipé. En tout cas, pour la partie technique, XMPP permet déjà d'être concrètement et réellement interopérable et le reste n'est qu'excuses…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

On est d'accord si tu ne le demandes pas toi-même. :-)
Maintenant que tu découvres sshpass, tu vois qu'il n'y a pas de raison de ne prendre que la moitié de la lib (enfin c'est caricatural mais tu vois ce que je veux dire.) ;-) Faut juste bien insister que l'outil ne gère pas le prompt et doit fonctionner sans cette interruption.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Tout à fait ça. Et c'est d'autant plus pervers que nombre d'usagers, si j'en crois les commentaires sur HN, finissent par claquer la porte pour ces concurrents justement. Ici, on a des projets qui ont plein d'usagers/comptes pour seulement une poignet d'actifs et du fait de la politique de facturation de Gitlab sont en train de songer à passer à Github… Beaucoup qui avaient franchi le pas lors du rachat par µ$ sont en train de le regretter et de vouloir faire demi-tour.
Ton commentaire me fait dire qu'on sait ce qu'il faut faire mais qu'on préfère la vision à court terme…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ce n'est pas faux. Je pointais surtout du doigt le fait qu'au lieu d'aller dans le sens de la standardisation, la tendance était plutôt de s'enfermer et de rompre l'interopérabilité de trucs ouverts (puis de crier que ça marche pas…)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Si il y a besoin de réduire quand la boite grandit, ça va donner quoi quand la croissance va retomber.

Comme là ?
Faut toujours se gaver avant que ça tombe …comme Mandriva une fois côté.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Feux Facebook Messenger (je présume vu que l'entreprise tente plutôt de pousser Whatsapp mais peut-être que ça survivra) et Google Talk (qui a fait place à Hangout qui est en train de virer à autre chose) par exemple (et il y en a plein d'autres comme ça) ont bien utilisé XMPP à un moment, preuve que ça marche ou peut marcher… Mais une fois qu'ils estiment avoir assez de poids (de compte dans leur réseau, chez eux) ça commence à saboter l'interopérabilité puis par la supprimer. Assurément le problème n'est pas technique (au pire il leur suffirait d'ouvrir les specs de leur proto qui est si bien et mieux pour que d'autres puissent se joindre à eux pour un monde meilleur.) Il faut arrêter de gober ou servir l'excuse technique alors qu'il s'agit purement de choix idéologiques et financiers.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

[troll]
On y vient tout doucement, depuis le temps que j'attends que la discussion semi philosophique dérive façon scientologie quantique
[/troll]

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est le contraire :
il ne faut pas voter, même par hasard, pour des assoiffé(e)s de pouvoir (et qui donc s'avèrent toujours aptes à la dictature) ;
il faut rechercher la personne qui fera le boulot (c'est vrai qu'en France on en est loin vu que le vote est pour une tête et non un programme, et qu'en prime on vote plutôt contre quelqu'un depuis des décennies.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Il y a toujours des candidats… Juste la façon de découvrir et choisir les candidats qui change : ici, la candidature n'est associé au volontariat mais à la recherche d'adéquation entre le poste et son occupant(e), mais en prime on se refuse par tout volontariat motivé par l'appât du pouvoir (ou du gain dans une entreprise.) En somme, comme dans certains pays plus au nord, les élu(e)s sont des fonctionnaires et non des psychopathes qui ont un agenda personnel qui ne cadre pas avec le bien commun. (les mêmes, en effet, qui mettent en place l'arsenal pour se faire rembourser une campagne de mensonges qui ne devrait pas avoir lieu d'être.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est le coup de la mère qui ressemble à la fille ça.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume