flan a écrit 1848 commentaires

Pourtant, tu n'as pas tous les droits avec un logiciel libre quelconque. Notamment pas celui d'en faire une version non-libre, pour certaines licences en tout cas.

On peut avoir au moins deux raisons bien différentes d'installer des paquets Python : pour les utiliser comme des outils classiques, ou parce qu'ils sont nécessaires dans un projet en développement.
Dans le premier cas, j'installe avec --user. Dans le second, il me semble assez impératif de créer un virtualenv (ou équivalent, en gros c'est un chroot pour Python) qui permet d'isoler ce projet du reste du système et d'y mettre les bonnes versions.

Sinon, deux sites à connaître, le premier est Sam & Max (attention, lien NSFW mais avec de bons conseils et des retours d'expérience intéressants), le second est The Hitchhiker's Guide to Python.

et encore après…

Tu peux même dire « encore maintenant », en fait :)

Sachant qu'il peut y avoir des petites manipulations.

Il y a 10 ans, j'avais assisté à une présentation de Google, qui expliquait qu'ils faisaient de temps en temps des ajustements manuels, en citant un exemple du genre une bière locale et une actrice portant le même nom mais avec une actrice devenue brutalement super connue. La bière aurait dû remonter en premier, mais la montée brutale avait été compensée manuellement.
Je me souviens plus trop des détails, mais l'idée est là :)

Je passe également sur les mises sur liste noir de Google qui a pu y avoir dans le passé…

Avec ansible, tu vas donner une série d'instructions du type « tel objet doit être dans tel état » :

• la ligne TOTO=3 doit être présente dans /etc/fichier.conf,
• le paquet tree doit être installé dans sa dernière version,
• le fichier /etc/service.conf doit être modifié,
• le service networkd doit être démarré.

De plus, tu as une notion de variables (par exemple, n'importe où dans Ansible, "{{ ansible_hostname }}" sera remplacé par le nom de la machine).
C'est à Ansible de se débrouiller pour que l'état soit mis en place (ou ne rien faire).

Avec bash, les instructions que tu donnes sont du type « faire quelque chose », et c'est à toi de vérifier si c'est déjà fait.

Du coup, les Inuits devraient se faire des journées de boulot de 6 mois… ça me parait un peu longuet !

Et on appellerait ça l’heure UTC ! Ultra pratique quand on doit se coordonner sur la Terre entière.
Par contre, comme c’est utile également d’avoir une heure qui reflète un peu la vie locale, on doublerait ça d’une heure locale.

Mmmmmmh ça me dit quelque chose, mais quoi ?!?

Globalement, les cryptomonnaies ont deux autres intérêts :
- permettre de faire des transferts d'argent illicites vu que ça permet des échanges sans passer par des banques, même s'il faut passer par des monnaies adaptées,
- interdire aux États d'avoir une politique monétaire en leur refusant le contrôle de la monnaie.

Oui, bien sûr, mais c'est une simple question d'habitude.
Cependant, tu ne pourras jamais empêcher les suppositions. Si un métier est surtout exercé par une population partageant globalement une certaine caractéristique et que tu vas découvrir une personne exerçant ce métier, tu t'attendras forcément à ce qu'elle partage cette caractéristique. Si on te présente un jockey, tu t'attends à ce qu'il soit petit, et c'est mathématique.

Je trouve que le nom du métier soit masculin ou féminin ne devrait rien induire sur la personne qui l'exerce : on pourrait tout à fait conserver infirmière et sage-femme (par exemple), quelque soit la personne concernée vu que le sexe n'a priori pas d'importance (pas plus que la plupart des autres caractéristiques humaines) pour le métier¹.

C'est en effet une erreur, mais elle est fréquemment enseignée malheureusement.

Personnellement, je suis plutôt contre : on se fout de la personne du maire (et du coup, il serait logique de dégager le « monsieur » ou « madame » qui va avec), c'est la fonction qui est importante et celle-ci n'a pas de genre spécifique.

Probablement pas : le soleil n'atteint pas son zénith en France métropolitaine. Il faut être entre le tropique du Cancer et celui du Capricorne pour voir le soleil atteindre le zénith.

Mais DNT est abandonné…

Alors que moi, même si je ne cache pas que des fois je désespère, je pense que la majorité est juste très mal informée.

Il y a certainement de ça… et aussi qu'on entend surtout parler des extrêmes, quel que soit le domaine. C'est quand même beaucoup plus vendeur de parler des deux qui croient vraiment que [la Terre est plate|les nazis sont sur la Lune|le King est encore vivant|…] que de tous ceux qui ne le croient pas.

En effet, le tutoiement systématique me fait fortement penser à la Terreur, ainsi qu'aux bonnes heures de la terreur soviétique des années 20…

Si c'est vraiment ce modèle de société qui est souhaité, ça fait peur.

À ma connaissance, il n'y a pas de solution miracle, ça dépendra de l'application d'origine.

Tu peux avoir les md5 (sha1/sha256/…) des fichiers d'origine et comparer avec ceux de la sauvegarde (mais attention : si ton fichier d'origine est corrompu, la sauvegarde le sera aussi).
Si c'est une application avec une base de données de taille raisonnable, tu peux créer une machine virtuelle avec Vagrant, installer l'application, charger la sauvegarde et regarder la date des dernières modifications.
Si ce sont des fichiers, tu peux créer un fichier "date" avant la sauvegarde et vérifier s'il est bien restauré.
Si ce sont des fichiers avec une structure particulière (XML, par exemple), tu peux vérifier si les XML sauvegardés sont toujours valides.

Je ne suis pas sûr que rallumer fréquemment des appareils augmente réellement leur durée de vie.

Et ça perd les IDE, qui ne peuvent plus t’aider.
Je préfère conserver la signature, voire ajouter le type attendu et avoir un IDE qui me prévient dès que je fais une erreur de type.

J'ai mis trop longtemps pour éditer mon message, alors je me réponds pour compléter :

Concernant le git, je ne suis donc pas concerné mais je pense que c'est illusoire de penser que la fusion fonctionnera mieux que sur du HTML sous prétexte que les balises s'écrivent **toto** et non <strong>toto</strong> .

Ah non, je ne le prends pas du tout pour du troll :)
En fait, de mon côté, les vraies contraintes étaient différentes car je voulais entre autres :

• limiter les applications métier à utiliser,
• du versioning (simple, sans chercher à pinailler par ligne),
• imposer un style très uniforme en fonction du type de document,
• personnaliser à ma manière les impressions faites,
• permettre de lier des méta-données (qui proviennent d'une application web) à ces documents et les ajouter à l'affichage ou à l'impression.

Au final :

1. Intégrer l'éditeur de texte à l'application web a été la solution de moindre coût pour permettre ces points,
2. utiliser un éditeur Markdown a été la solution à moindre coût pour permettre une mise en forme minimale (avec la possibilité de tags propriétaires et de notes de bas de page),
3. la transformation en LaTeX a été la solution à moindre coût pour imprimer les documents avec un rendu correct¹,
4. cela permet de tout faire dans une seule application web.

D'un point de vue technique, je me moque totalement des autres choix (WYSIWYG, WYGIWYM ou à balises), ce sont les utilisateurs (dont je suis également) qui choisiront, mais si je peux proposer un WYSIWYG qui remplisse tous mes critères, les utilisateurs seront les plus heureux du monde.

Dans mon cas :
- j'ai la chance d'avoir des utilisateurs obéissants et de bonne volonté à défaut d'être geek,
- ils savent qu'ils n'ont aucune chance de repasser à Word ou LibreOffice (ils ont eu une phase transitoire avec LO, et leur réaction face à Markdown a été unanime : c'est toujours mieux que LO),
- un éditeur WYSIWYG (style Word) pourrait très bien être castré pour se limiter à un sous-ensemble simple et donc obtenir un rendu homogène ( https://ckeditor.com/docs/ckeditor5/latest/examples/builds/document-editor.html ),
- il est illusoire d'utiliser git sur du Markdown et espérer avoir en permanence du texte valide lors d'une fusion (des étoiles ou des underscores sur deux lignes différentes, par exemple) — on se retrouve à égalité avec du HTML à ce niveau : de toute façon, si tu ne peux pas garantir que la transformation vers le produit final est viable, on se moque de pouvoir faire un diff.

Pour avoir mené une expérience similaire (du Markdown dans des mains de non-geek), je pense que c'est une mauvaise idée.

Pour autant, je ne rejette pas la faute sur les utilisateurs, mais plutôt sur le Markdown, qui est finalement un langage beaucoup moins simple qu'il n'y paraît quand il s'agit de faire des listes imbriquées, des listes numérotées avec plusieurs paragraphes (« mais pourquoi ça me numérote à 1. alors que j'ai mis 2. ???? »), etc. Les réponses sont toujours du type « faut sauter une ligne » ou « fallait rajouter 4 espaces au début de chaque ligne ».
D'autre part, il faut trouver un éditeur Markdown qui permette les correcteurs orthographiques, ce qui n'est pas évident, et un rendu temps réel bien synchronisé (j'ai souvent des décalages verticaux entre l'interface de saisie et l'aperçu du rendu).

De mon côté, c'est encore du Markdown mais je pense partir sur du « HTML » avec ckeditor. Je mets les guillemets car c'est un HTML très expurgé qui devrait interdire de faire n'importe quoi (je veux forcer un style très uniforme des documents) et une conversion facile vers d'autres formats.

Un processeur normal est constitué de « portes logiques » qui laissent ou non passer le courant en fonction des courants électriques en entrée (à traduire par « ça produit un 0 ou un 1 en fonction des 0 et 1 en entrée). Tu as des portes pour faire un AND, un NOT, un OR, etc. Quand tu en as quelques millions mises bout à bout, ça donne des enchaînements complexes capables de produire des additions, divisions et autres opérations dont sont capables les processeurs modernes.
Ces portes sont gravées dans le silicium et donc non modifiables. Si tu te plantes lors de la gravure de ton processeur, tu mets tout à la poubelle et tu recommences.

Un FPGA est la même chose, sauf que ce n’est pas gravé dans le marbre et que tu peux regraver les portes logiques pour adapter les opérations faisables par le processeur (en contrepartie les opérations sont faites moins vite). Pratique pour faire des prototypes ou des processeurs hyper spécialisés.

Mais en pratique, combien de sites ont vraiment besoin de perfs aussi élevées ?
Quand je vois que des sites comme Libération, Disqus, Instagram, Spotify, The Washington Post sont (ou ont été) avec du « bête » Django, je me dis que 99% des sites web devraient pouvoir tenir sans trop de souci avec des technos très classiques.
À nouveau, je ne suis pas développeur web, mais quand je compare le coût annuel du développeur avec celui d'un serveur, j'imagine que la rapidité de développement doit largement primer la performance (sauf quand on s'appelle Google ou Facebook ou qu'on fait partie du 1% ci-dessus, bien sûr)

Ce n'est pas la première fois que je me fais cette réflexion, vu que la question des perfs revient régulièrement (par exemple avec les framework C++).