flan a écrit 1830 commentaires

Bien sûr, tu connais bien mieux que moi ce que j'ai pu voir :)

Je suis tout à fait d'accord avec toi.
Pour ce que j'en ai vu : des presta complètement rigides, de mauvaise foi, en plus d'être mauvais. Forcément, l'intérêt de la SSII était exactement inverse de celui de l'administration, et les contraintes du marché public étaient telles qu'il peut tout à fait se permettre d'être le plus mauvais possible.
Les bons presta existent, c'est certain. Mais les marchés publics sont tels qu'ils ne permettent pas forcément de les avoir…

Plus le temps passe, plus je suis persuadé que l'Administration ferait des économies démentielles en éjectant les presta et en constituant un nouveau corps de fonctionnaires (d'ingénieurs en informatique) pour être sa propre SSII.

Et non seulement il va lui rendre la main dans une situation difficile, mais en plus le conducteur aura une demi-seconde pour prendre conscience de la situation et reprendre la main. Pour peu qu'il n'ait pas les moins libres, ça peut être rigolo (ou pas)…

Un autre aspect qui est souvent plus difficile qu'il n'y paraît est le découpage des rôles. Comment faire pour découper la configuration de chaque machine en morceaux, afin d'avoir le maximum de fichiers en commun (et donc le moins de lignes au total), et d'avoir un minimum de conflits entre ces rôles.
Par exemple, si j'ai une machine qui fait à la fois LDAP et Apache, je peux bien sûr faire un seul rôle Ansible. Seulement, si je veux ensuite faire un LDAP tout seul, c'est bien mieux d'avoir découpé en deux rôles différents.

Si au contraire je pars d'un LDAP et d'un Apache sur deux machines différentes, c'est mieux si les rôles Ansible ne génèrent pas de conflit quand j'applique ces deux rôles sur la même machine…

Ça semble facile, mais ça peut devenir un vrai casse-tête quand on a un très grand nombre de rôles à appliquer.

Manifestement, ce n'est plus un état communiste, même s'il en a gardé pas mal de mauvais côtés. Quant à son côté stalinien, comme je ne sais pas trop ce que ça veut dire exactement, je ne me prononcerai pas.

Je pratique pas mal le Python, et l'indentation ne m'a jamais posé de problème. Rien n'empêche de décaler comme il faut juste après le coller.

Peut-être que ça nécessite d'avoir un IDE adapté, en échange.

Même si je n'ai pas de souci particulier avec YAML, je regrette qu'il n'y ait pas d'éditeur spécifique à Ansible (pour détecter automatiquement les paramètres invalides dans les templates, par exemple)

À noter qu'Ansible est maintenant compatible Python 3, même si ça ne semble pas être totalement officiel : https://docs.ansible.com/ansible/python_3_support.html

De son côté, Salt ne l'est pas encore mais le portage est bientôt fini.

En pratique, tu peux tout définir dans un fichier quelconque. Personnellement, si je fais un projet avec Ansible, j'ai un dossier avec mes playbooks, mais aussi un dossier avec un fichier de conf' par plate-forme ciblée : absolument hors de question de modifier un fichier global (au système ou à l'utilisateur).

Tu peux préciser qu'il faut se connecter avec un utilisateur et faire un sudo après.

Dans XML l'ordre est important, tu ne peux pas inverser deux balises. Heureusement, sinon un texte en XHTMLrisquerait de perdre un peu de son sens…

Et qu'est-ce que ça apporte de mieux pour l'utilisateur lambda qu'une bête appli type what's app ? Les fonctionnalités de base sont absentes, et en échange on a … bah on ne sait pas trop en fait. Du coup, je comprends tout à fait la réaction des personnes à qui tu as proposé ça.

On dit qu'une application mobile est plus performante (réactive, riche en fonctionnalité) qu'une page web. C'est faux selon moi.

Peux-tu en dire plus ? Selon moi, c'est tout à fait vrai au contraire ^{^^}

Quel est l'intérêt d'une page web pour envoyer des SMS si tu ne peux pas lire la réponse de la personne ? J'exclue bien sûr les SMS de service qui n'appellent pas de réponse.

Et sinon, autoriser les connexions directes ?
Le F2F me semble être franchement la pire des solutions, avec une très bonne probabilité de ne pas fonctionner…

J'ai lu que les portables étaient trop légers pour que ça soit vraiment efficaces : un aimant suffisamment puissant est nécessaire pour l'alimentation, mais du coup le portable s'envole quand même car trop léger.

Mais ça dépend beaucoup du domaine.

Quand tu es un domaine spécialisé, c'est tout à fait faisable (le client a besoin d'une fonction particulière qui n'existe pas encore, il devra de toute façon payer pour la voir codée).
Quand il y a besoin de support (coucou RH), c'est également faisable, c'est à peu près le même cas que précédemment : la seule façon de faire, c'est de payer.

Maintenant, si tu prends l'exemple des jeux…bah c'est tout de suite plus dur à déterminer ce qui est vendable. Du support ? Un joli site pour télécharger ? À la rigueur quand il y a une infrastructure côté serveur nécessaire (ça limite beaucoup les jeux concernés), en espérant qu'il n'y ait pas des émulateurs de serveurs qui apparaissent.

Merci pour cette réponse bien franche :)

J'allais soulever la question d'Huggin : comment se comparent les deux solutions ?
Je préfère Django, mais Huggin me semble plus connu.

Je ne vois pas le rapport avec mon message.

Ce n'est pas Clinton qui ne sait pas sécuriser ses e-mails.
C'est Clinton qui viole la loi en utilisant un serveur mail pour ses mails pro, qui viole à nouveau la loi en ne versant pas ses mails pros aux archives nationales (ce qui pose problème lors d'une enquête pour la mort d'un ambassadeur en Libye) — le tout en le sachant très bien car elle rappelle aux autres ambassadeurs de ne surtout pas le faire —, qui détruit des preuves dans une enquête fédérale, qui fait des compromissions du secret défense (en France, c'est passible de 5 ans de prison et 75k€ d'amende, de mémoire) et qui ment en disant que rien de tout cela n'est arrivé (et le mensonge est très mal accepté aux États-Unis). Et par-dessus, la justice va dire que comme c'était uniquement pour se simplifier la vie, ça n'est pas grave.

Bien sûr, tu peux réduire tout ça à « Clinton ne sait pas sécuriser ses e-mails ».

Pourtant, on ne peut pas dire que les médias ont épargné leurs efforts pour faire gagner Clinton. À quel moment ont-ils voulu favoriser Trump ?

À ma connaissance (limitée), MS n'a pas réécrit totalement leur moteur, mais a surtout retiré tout le code servant à garder la compatibilité (Trident pouvait adopter le comportement de plusieurs versions obsolète d'IE).

Malheureusement, fabric2 ne bouge pas beaucoup (du tout ?). Ils ont lancé le projet depuis quelques années, et il n'est toujours pas utilisable.
De plus, fabric et ansible sont sur le même créneau (code Python lancé depuis le poste d'admin et connexion SSH vers les machines administrées), je ne suis pas sûr qu'il y ait de la place pour les deux outils (sachant qu'Ansible a plus ou moins raflé le marché).

Bref, je trouve que parier sur fabric est plus risqué que parier sur Ansible comme techno pérenne.

Note : ce jugement ne porte absolument pas sur les qualités et défauts des deux outils, uniquement sur un des questions les plus importantes pour moi : est-ce que mon investissement sera toujours d'actualité dans 5 ans ? Je pense que fabric sera oublié, contrairement à Ansible.

Auparavant, tu pouvais te faire rembourser OS X. Maintenant, dans la mesure où macOS est gratuit, ça risque d'être plus compliqué.

Très souvent, il y a pas mal de petits trucs pénibles et inintéressants à faire pour finaliser le projet (le packaging, renvoyer à l'utilisateur des messages utiles et compréhensibles, etc.).

Techniquement, rien n'empêche de connecter le script à l'agenda (vive CalDAV !) pour ajouter automatiquement les rappels.