flan a écrit 1848 commentaires

À part pour certaines applications spécifiques, je ne vois pas l'intérêt d'utiliser une base binaire boiteuse (pourquoi 2¹⁰ et non 2¹¹, par exemple ?). Quel est-il ?

Le problème est donc bien fixé dans Debian :)

Personnellement, je ne comprends pas trop l'intérêt du 8.
Enfin, si, mais je trouve qu'il revient à dire qu'il faut utiliser les bons outils (et savoir les utiliser ! ).
Je trouve de la même façon que pour faire un projet web, utiliser un framework est au moins aussi important que savoir déployer son application, en test ou pas, qu'avoir documenté les différentes procédures critiques (au moins dès que c'est autre chose qu'un POC), de toujours partir du principe que la machine sera perdue demain, etc.

C'est très probablement des certificats clients.

En tout cas avec Apache, tu peux en effet rendre le certificat client optionnel… sauf que dans ce cas, le navigateur va probablement ne jamais demander au client de fournir le certificat (de mémoire, c'était le comportement quand j'avais essayé).

C'est également le cas pour pip, mais ce n'est pas toujours directement applicable au paquet Python s'il n'est pas parfait dès le début (par exemple, si le paquet Python s'appelle « toto », le nom Debian sera « python3-toto »… sauf que si le paquet Python s'appelle déjà « python-truc », on ne va pas l'appeler « python3-python-truc »…).

Mais en pratique, ça fonctionne assez bien.

Je peux difficilement essayer, faute de Windows sous la main.
As-tu essayé ? qu'est-ce que ça donne précisément ?

Tout simplement générer un mot de passe unique et le mettre sur une étiquette collée sur l'objet en question.
Aucune difficulté technique particulière, ni pour l'utilisateur.

Mais le même lien explique qu'on peut réduire sa taille.
Ça ne me choque pas qu'il y ait des dossiers à ne pas supprimer sur un OS (as-tu essayé de supprimer /boot ou /bin ?).
Que vaut la taille de ce dossier après l'utilisation des méthodes documentées ?

Même si je suis plutôt d'accord avec toi, je suis également assez d'accord avec sa conclusion :)

Mais est-ce toujours utile ? La question mérite tout de même d'être posée, et la réponse sera différente d'une personne à l'autre.

Oui, bien sûr ; je ne voulais pas parler spécifiquement de Libre Office / Office, simplement souligner qu'un logiciel, même assez cher en apparence (pour beaucoup de monde, un logiciel à 200 ou 300€ est cher), pouvait être tout à fait rentable alors même qu'on est à peine plus efficace avec (je parlais de 5%, mais avec certains logiciels on peut être facilement deux fois plus efficace par rapport à un autre).

Après, dans notre cas de figure, si on est aussi efficace, voire plus efficace, avec Libre Office, on aurait tort de se priver, évidemment.

Il faut regarder le prix global de l'investissement, et non le coût de la licence. Si ton utilisateur (qui coûte peut-être 50k€/an à l'entreprise) est à peine 5% plus efficace avec un logiciel, cela veut dire que c'est rentable de payer ce logiciel jusqu'à environ 2 000€.

Et la différence de productivité peut largement dépasser 5% d'un logiciel à l'autre…

Oui, c'est exactement ce que je dis : c'est totalement inutilisable et tu le démontres bien : il faut ouvrir un autre logiciel, créer une image déjà à la bonne taille (« Environ 620 à 625 pixels de large et 830 de haut ce qui donne, pour un export de l’image à une résolution de 150 pixels : environ 1037 pixels en largeur sur 1384 en hauteur avec, pour une couleur bleu foncé une opacité ) 25 % »), ensuite deviner tout de suite les bons paramètres, savoir où on sauvegarde l'image (et d'ailleurs, est-ce que le filigrane reste si je transmets le fichier ?), retourner au document, incorporer l'image, se rendre compte que ce n'est pas le bon texte, refaire la manip, se rendre compte que la police de caractère ne convient pas, refaire la manip… et quand on veut un filigrane différent pour 10 exemplaires, passer des heures sur le sujet.

Avec Word : aller dans le bon menu, ajouter un filigrane, cocher la case texte qui donne directement des paramètres par défaut qui sont valables (un texte pas idiot, la bonne nuance de gris, la bonne opacité, une police convenable, …).
Dans mon petit cas précis, à mettons 20-30€/heure/personne, une licence Word est vite rentabilisée rien que sur le temps perdu à faire des filigranes (et quelques autres broutilles de ce genre).

J'ai pu tester la différence, vu qu'à la base j'étais parti dans l'idée d'imposer LibreOffice. Les utilisateurs ont tous été convaincus de continuer à utiliser Word ou Excel (alors qu'à nouveau, les besoins sont très simples).

LibreOffice vaut maintenant largement MS Office.

Bof, c'est un peu rapide comme affirmation. Il y a des points positifs, mais également des points négatifs. À mon boulot, on n'a que peu de besoins en traitement de texte (avec une mise en forme assez simple, on peut faire la même chose Libre Office ou Office), mais :
1) par défaut le thème de Libre Office est moche (comparé à ceux fournis par Office),
2) on ne peut pas faire de filigrane en pratique avec Libre Office, alors que c'est une fonction qu'on utilise beaucoup et qui se fait en deux clics avec Word.
Bref, j'ai du mal à dire que Writer vaut largement Word, alors que sur les 2% des fonctions (au mieux) que j'utilise, il y a déjà un net écart.

Merci pour l'info, ça me paraît assez intéressant. Je cherche un petit sac-à-dos pour un 13" avec un cahier de notes format A4 et quelques petits trucs.

On peut même dire à peu près abandonné et obsolète (pas de Python 3, il se limite à Python 2.7)

Personnellement, je pense partir sur du salt (pour configurer des postes clients) + salt-ssh (pour configurer les serveurs).
L'intérêt est de pouvoir partager un maximum de fichiers entre les deux outils, tout en s'adaptant aux contraintes différentes sur les deux environnements.

Oui, il faut les occuper tout le temps, et c'est le grand argument pour dire qu'il ne faut prendre que des presta.
Mais en pratique, on n'aura jamais ce souci : les systèmes informatiques doivent être périodiquement refondus et une fois qu'on aura fini un projet, on peut être sûr qu'il y aura d'autres projets à faire ou à refaire.

Quant à la motivation des gens… il y a également la motivation de sa structure, qui est directement liée à son intérêt. Malheureusement, l'intérêt de la SSII est inverse de celui de l'Administration. Après, bien sûr, il faut diriger intelligemment les fonctionnaires pour les garder motivés et performants, mais ça c'est vrai quel que soit le corps de métier.

Par contre, avoir des fonctionnaires permet d'avoir une souplesse impossible à avoir via les marchés publics (tu intègres le développeur dans une équipe opérationnelle pendant un certain temps et en échange tu définis largement moins le besoin). L'agilité est par construction interdite dans les marchés publics, alors que c'est une méthode très efficace pour pas mal de projets (pas tous, évidemment). Elle serait possible avec des fonctionnaires.

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)