flan a écrit 1830 commentaires

mais ça arrive vraiment ce genre de cas ? je tiens mes ordis à jour, je n'utilise quasiment que la ligne de commande, et pourtant je n'ai pas souvenir avoir dû récupérer un OS si souvent que ça. Je n'ai jamais essayé avec Linux, mais sous macOS (et Windows, me semble-t-il mais je connais beaucoup moins), c'est assez trivial de réinstaller tout l'OS sans écraser les données utilisateur (au point de se retrouver après la réinstallation avec les derniers documents ouverts d'avant la réinstallation). Je suis surpris qu'on ne puisse pas faire la même chose avec Linux (au moins les grandes distribs).
Mais bon, comme je l'ai dit, je ne prends aucune mesure pour protéger mon /home lors d'une réinstallation vu qu'une reconfiguration ne me coûte presque rien.

Est-ce nouveau ? Mon portable (Apple, avec la dernière version de macOS) permet de l'éteindre complètement (même si c'est rarissime, je n'ai aucune raison de le faire).

Sinon, je ne comprends pas l'intérêt de partitionner les disques. De toute façon, il vaut mieux partir du principe que le disque peut être perdu (disque mort, ordi perdu ou volé par exemple) et être capable de réinstaller l'ensemble. Si ce n'est pas le cas, c'est qu'il y a un risque peu acceptable de mon point de vue.

Il faut surtout voir jusqu'à quelle date il a été vendu… S'il a été vendu jusqu'en 2016, ça n'a rien d'extraordinaire de fournir des mises à jour pour un téléphone qui a un an.

Il y a une énorme différence entre affirmer comme tu le fais qu'il y a des backdoor (action volontaire de Google) et ce qui est dit dans tes sources, c'est-à-dire qu'il y a des failles (qui sont involontaires).

Normal : c'est compilé sur la machine.

Les distribs doivent compiler la version avec et la version sans PA à partir d'un seul paquet source. Avec Arch, tu refais ce boulot de la distrib et tu ne compiles que la version choisie.

Oui, je sais tout ça… et alors ? En quoi, pour l'humain, est-ce plus facile de manipuler des Ko de 1024 octets ?

Parler de disquettes de 1,44 Mo ne me semble pas franchement plus facile que de parler de disquettes de 1,47Mo (voire 1,5 Mo si on arrondit, parce que dans 99,9% — valeur particulièrement précise, évidemment — des cas on se moque d'avoir la valeur précise).
Pour la RAM, quand on a 512 Mo de RAM, est-ce réellement plus simple que d'avoir 536 Mo de RAM ? Ou encore, plus simplement, 0,5 Go de RAM ? Je suis prêt à parier qu'un processeur à 3 GHz ne fonctionne pas à 3 000 000 000 Hz très exactement, et pourtant cet arrondi ne fait de mal à personne (bien sûr, je ne parle pas des variations permanentes de fréquences des processeurs actuels).

Un Byte n'est pas toujours égal à un octet.
Un octet vaut 8 bits, alors qu'un byte est la plus petite unité adressable (souvent 8 bits, mais pas toujours). On peut avoir des bytes de 10 bits, par exemple.

À 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.