Je ne suis pas professionnel du droit, donc il s'agit d'un pur exercice d'imagination. :)
Cher Maître X,
j'ai bien pris connaissance de votre soi-disant mise en demeure du 27/09/2017 portant sur une soi-disant contrefaçon d'un texte de votre mandant M. Gallaire par un participant de notre site LinuxFR. Ces deux textes de quelques paragraphes rapportent le résultat d'une même élection et vous me semblez avancer que:
- la simple mention des dates concernant la tenue de cette élection,
- la simple mention des noms des participants à cette élection,
- la simple mention de la méthode de vote retenue pour cette élection
- l'utilisation d'une formule très ordinaire de félicitations au vainqueur de cette élection
représenteraient les traits caractéristiques d'une création individuelle de votre mandant, dans laquelle s'exprimerait un génie particulier indissociable de sa personne. Si ma compréhension de votre lettre est correcte, je vous prierai bien de porter à ma connaissance les traits caractéristiques d'une création individuelle et le génie particulier qui s'y exprime dans l'emploi des expressions que vous relevez, à savoir:
- entre le 5 et le 11 mars
- du 2 au 15 avril
- la méthode de Condorcet
- Mehdi Dogguy, Chris Lamb
- bonne chance dans la mise en œuvre de ton programme !
à la fois prises individuellement puis dans leur ensemble.
etc.
Ce qui en soit est pas si différent du type de déploiement qu'on voit pour de l'embarquW IOT. Et dire qu'on peut pas mettre à jour, c'est aussi un peu trompeur.
Est-ce que l'équivalent de curl https://… | sh - serait un code valide?
Oui, c'est un problème ancien et il suffit d'une brève recherche pour se rendre compte qu'il y a une bonne dizaine de possibilités… je n'en ai jamais utilisé une mais pour le besoin de l'exemple j'en ai pioché une où il n'y a pas trop de plomberie à faire.
Si j'ai bien compris ton exemple, tu as un coût assez important à la création du paquet, mais les mises à jour sont relativement aisées.
Ma stratégie actuelle est plutôt de ne pas faire de mise à jour. Dans l'état actuel des chose écrire des paquets pour Debian (c'est probablement le cas pour beaucoup de distributions) est une compétence à cultiver, et le processus complet est largement trop complexe pour l'utilisateur occasionnel du système. Il y a trop d'outils avec lesquels il faut interagir (pour mettre à jour le fichier ChangeLog, pour tester le paquetage, pour créer le paquet proprement dit, pour l'uploader quelque part) alors qu'en fait de moins point de vue il s'agit d'une seule opération. Ce qui est particulièrement pénible est le lien entre le ChangeLog et le nom du paquet… peut-être que la bonne façon de travailler m'échappe, mais en gros il faut avoir une branche par distribution où on veut envoyer ce paquet … alors que le programme est absolument portable. Bref: on le fait une fois pour essayer et après on se souvient à quel point c'est pénible et plein de problèmes inutiles et on concentre son énergie sur autre chose.
L'approche de FreeBSD ou MacPorts est, en comparaison, bien plus simple pour le porter.
Ton dernier exemple est intéressant. Aujourd'hui j'aurais tendance à penser que la grande majorité des utilisateurs passent par les dépôts de leur distrib pour utiliser LibreOffice… Ce qui montrerait que les méthodes l'installation « à la rache » des développeurs ne sont pas vraiment plébicités par les utilisateurs, qui préfèrent le système de paquet… C'est à creuser.
Ça montre aussi que la méthode “à l'arrache” n'est pas nouvelle et que c'est toujours mieux que de ne pas faire de paquet du tout.
Dernier point : Le packaging est compliqué surtout lorsque que le logiciel est question est construit avec les pieds, ou qu'on veut respecter des normes strictes, par exemple celle de Debian, qui sont là pour de bonnes raisons !
Huuum, je ne suis pas sûr: par exemple bsdowl respecte tout ce qu'il peut respecter: il a son fichier ./configure qui comprend toutes les options --prefix etc. pour configurer les chemins d'installation… etc. La procédure d'installation est
Il est crucial de désactiver l'identification par mot de passe et de n'utiliser que des identifications par clef publique (PasswordAuthentication no et PubkeyAuthentication yes)
Il faut créer un utilisateur Unix dédié pour la procédure sauvegarde.
Il faut montrer le moins de surface possible pour la machine, donc n'ouvrir qu'un seul port (le routeur du FAI doit permettre faire du NAT pour rediriger un port du routeur (IP publique) sur le Pi.
Un aspect qui n'a pas été encore mentionnant et qui est peut-être plus inattendu est qu'il faut impérativement configurer le système de logs et le firewall de façon appropriée… Je l'ai appris à mes dépens car il y a quelques années j'avais effectivement ce genre de montage chez moi, et j'ai rapidement remarqué que le serveur SSH était en permanence sollicité… par des attaques de dictionnaire, ce qui a rempli le dossier de logs en environ un mois, et flingué la carte SD. Je n'ai vérifié les détails mais le scénario probable de l'écriture synchrone de chaque ligne de log sur la carte SD a fait beaucoup de mal au système.
Pour se prévenir de cela, il faut donc:
Utiliser des règles de firewall qui vont rejeter les tentatives infructueuses répétées. Il y a plusieurs stratégies utilisables, j'ai rapidement regardé et l'approche de Joao S Veiga semble à la fois simple et raisonnable: il paramètre iptables pour rejeter toutes les tentatives multiples sur le port 22 (SSH) suivant de moins de 15 secondes une tentative plus ancienne.
En ce qui concerne les logs il faut vérifier que syslog ou tout autre système utilisé n'écrit pas de façon synchrone sur le disque ou bien mettre les logs sur un autre système de fichiers. Par exemple un disque USB attaché au Pi (si l'alimentation est assez forte!), un disque réseau NFS, voire envoyer tous les logs sur une autre machine via syslog, ou bien utiliser un système de fichiers tmpfs et utiliser logrotate de façon très agressive pour limiter la place consommée par ceux-ci!
pour des besoins similaires mais avec un serveur web, j'utilise sslh en front, sur le port 80 ou 443.
À signaler que répartiteur HA-PROXY permet aussi de faire ce genre de choses: une analyse du contenu ou de l'origine permet de rerouter le traffic. Avec l'avantage que c'est un outil beaucoup plus général.
Autant je comprends docker dans une démarche industrielle avec des microservices d'entreprises pour la scalabilité d'un service avec une connaissance et la construction de son infra docker …
La plupart des systèmes de paquet sont assez compliqués, et même Ubuntu par exemple qui s'est donné la peine de réduire énormément la complexité a toujours un système hyper complexe De mon côté, auteur de logiciel, j'ai mon code source, typiquement dans un dépôt Git, une clef PGP pour signer mon paquet et un serveur FTP où télécharger (ici upload) mon paquet source, et pourtant je dois traficoter avec 4-5 outils qui sont souvent des empilements d'autres outils… bref, y'a rien de moins marrant que de construire ses paquets.
En regard, docker est assez simple et se prête bien aux techniques d'intégration continue Un Dockerfile est essentiellement une suite de commandes shell, qui en plus bénéficie d'un système de cache.
Les dépendances utilisées peuvent provenir de bien des sources différentes. Le gestionnaire de paquet d'une distribution n'est qu'un moyen comme un autre d'installer des logiciels – c'est souvent le plus puissant mais aussi le plus coûteux en terme de préparation, dès lors que quelque chose est à préparer. Les autres méthodes sont bien-sûr les tarball, mais aussi les système de paquets spécifiques aux langages ou à une communauté (par exemple npm, yarn, opam, quicklisp, gem, pip, composer pour les langages, Emacs a une fonction spéciale pour installer des packages elisp, et il me semble que certains gros logiciels comme sage ont leur propre système de distribution pour des extensions, mais je peux me tromper). Comme le Dockerfile est essentiellement un shell script, cela permet d'utiliser toutes les dépendances qu'on veut sans s'embêter à préparer des paquets pour les logiciels manquants pour toutes les distributions qu'on souhaite toucher.
Pour des logiciels d'une telle complexité, l'homogénéité des déploiements facilite la maintenance. Pour l'équipe qui développe, le nom de l'image utilisée contient en elle-même toutes les informations de version nécessaires pour essayer de reproduire un bug signalé, par exemple. Il y a régulièrement eu des initiatives pour distribuer les logiciels de cette manière (sur PC-BSD p.ex., il me semble que Ubuntu ou Cent-OS avait aussi introduit une forme de paquet “blob” il y a quelques années, sans que je sache ce qu'ils sont devenus, ou encore les “App bundle” de Mac OS-X, ou les applications Windows pour quitter le monde du libre).
Probablement pour à peu près les mêmes raisons, en 2001, lorsque Open Office est sorti il était distribué soit en source soit en binaires précompilés mais pas de véritables paquets. Lien Wayback Machine
Les avantages que tu cites sont les mêmes que pour n'importe quelle solution de virtualisation : c'est très intéressant, et il y en a bien d'autres.
C'est très juste, qu'on parle de virtualisation lourde par exemple via VirtualBox ou VMWare ou bien de virtualisation plus légère via des conteneurs ou des jails FreeBSD, on retrouve à peu près les mêmes avantages: c'est technologies et ces méthodes de travail n'ont, à bien y regarder, rien de très nouveau ou de très révolutionnaire: la première fois que j'ai utilisé VM Ware c'était en 2001 et les jails de FreeBSD existent depuis 2000 (FreeBSD 4.0).
Là où toutes ces possibilités se distinguent, c'est la communauté d'utilisateurs, y compris les utilisateurs industriels, et l'outillage disponible… et bien-sûr dans une certain mesure les effets de mode. En pratique c'est plus facile de travailler avec des conteneurs qu'avec des machines virtuelles, tout simplement parcequ'on a une couche en moins et que les outils s'occupent de la création du réseau etc.
Je travaille beaucoup avec docker et ce qui pêche le plus à mon avis c'est d'une part la commande docker build utilisée pour préparer les images, qui ne propose pas du tout la bonne interface: si on veut travailler efficacement il faut manier la commande docker build à travers un script qui s'occupe de plein de petits détails. Ensuite la documentation est plutôt mauvaise: très fouilli, mal organisée, la présentation est dégueu ce qui rend la lecture difficile, le rédacteur change tout le temps d'avis sur le type de document qu'il écrit (référence, matériel d'introduction, exemples)…
S'il faut tout reconfigurer à chaque mise à jour, et perdre les données, poubelle.
Bien évidemment on peut avoir des données persistant indépendamment des conteneurs. Dans le langage de docker il s'agit des volumes. Cependant, à cause des limitations de la commande docker build (limitations qui ont par ailleurs de bonne raisons d'être!) la préparation de l'image dans certains cas demande des soins particuliers.
Sauf que, en pratique, j'ai fait suffisamment de va-et-viens entre les diverses versions de Debian (avec un peu d'apt-pinning et quelques repos externes, dont 1 non-free, au passage, pour bien essayer de foutre la merde) pour savoir que les paquets Debian sont solides, très solides.
Faire des va et viens a l'inconvénient que c'est une excellente recette pour fabriquer des “serveurs flocon de neige” (les flocons de neige sont tous différents les uns des autres) alors que les solutions à la docker permettent d'implémenter facilement la méthode du serveur constant (immutable server pattern en vo), ce qui signifie qu'au lieu de faire des va et viens on jette tout et on repart sur du neuf. La méthode du serveur constant a l'intérêt qu'elle qu'elle aide à maintenir l'homogénéité d'un parc et à garantir la reproductibilité d'un environnement. Le cas “à la docker” est particulièrement intéressant pour déployer un grand nombre de copies de la même application ou bien pour faire coïncider le plus possible l'environnement de développement avec celui de la production.
Ce qui compte pour mesurer la performance d'un programme pour s'orienter dans le développement c'est d'appliquer la méthode scientifique. Le but est donc de construire un énoncé falsifiable et dans le contexte de l'optimisation de ta méthode functionToMeasure on aimerait bien construire un énoncé du type “l'implémentation A est toujours plus performante que l'implémentation B” mais ce type d'énoncé n'au aucune chance de marcher.
Dans la liste des défauts de mon énoncé il y a bien-sûr le fait qu'il faut expliquer ce que veut dire “performant” ce qui n'est pas forcément facile et en plus imaginer une expérience qui mesure cette performance dont on a précisé la teneur, et le but est d'arriver à une expérience dont le résultat est reproductible, autrement on ne peut rien conclure du tout. Mais ensuite la durée d'exécution (“performance en temps”) se comporte super mal! À preuve:
Le même programme lancé sur la même machine opérant sur la même donnée après un cold boot peut livrer des temps d'exécution très différents, sans problème du simple au double. Il y a des milliers de raisons possibles à cela, dont l'alignement mémoire qui a une influence directe sur la stratégie d'utilisation des caches.
Un programme plus long qu'un autre (par exemple bordé de NOPs ou qui fait des contrôles d'indice sur un tableau) peut parfois être rapide!
Les ordinateurs sont très complexes et il y a des tas de facteurs qui influent sur la vitesse d'exécution des programmes, même la taille d'une variable d'environnement non utilisée par le programme!
Ainsi, même si on réalise que les mesures individuelles n'ont aucun sens et qu'il faut toujours mesurer des distributions, on ne fait que s'avancer vers un problème très compliqué et si on veut mesurer sérieusement la vitesse d'exécution d'un programme on doit donc construire un protocole expérimental qui se débarrasse de tous les biais… et quand on le fait pour GCC on découvre que l'incidence de l'utilisation de -O3 par rapport à -O2 est indistiguable d'un bruit statistique.
Des problèmes particulièrement difficiles en pratique sont en outre la production de données dont la distribution ressemble à celles de l'application réelle, et pour les applications réseau la reproduction d'une charge ressemblant à celle de l'application réelle.
L'exagération outrancière du point de vue aurait pu te mettre la puce à l'oreille. :)
Pour apporter de l'eau à son moulin, j'aime bien quelques exemples:
Dans les noms propres, comme en français, l'anglais ne connaît aucune limite: tous les -cestershire (Gloucestershire, Worcestershire, etc.), Greenwich, Fowey, …
Dans les noms communs le plus rigolo est lieutenant |lɛfˈtɛnənt|
Les mots en -ough se prononcent presque tous différemment les uns des autres.
On ne prononce pas pareil desert selon que ce soit un nom ou un verbe
On ne prononce pas pareil read selon que ce soit le présent ou le prétérit
Les mots consistant d'une seule syllabe avec oo comme voyelle (foot, mood, door, blood, etc.) se rangent en quatre catégories selon comme on prononce le oo.
Pas vraiment la façon dont je la pense mais comme programmeur OCaml expérimenté je peux dire que le cycle de développement avec Common Lisp est complètement différent de ce qu'il est avec OCaml.
La raison principale est la proximité de l'évaluation du programme avec l'écriture de celui-ci. En OCaml on peut utiliser la REPL pour mettre au point une fonction mais c'est assez compliqué à mettre en place parcequ'il faut écrire un .ocamlinit spécifique au projet qui charge les modules nécessaires au module où vit notre fonction et installe les pretty-printers. Si on se rend compte qu'on a besoin du débogueur, il faut refaire toute cette configuration avec le débogueur. Enfin, une fois qu'on est content de sa fonction on peut continuer la mise au point avec une autre fonction d'un autre module et cela demande d'ajuster les fichiers de configuration pour le toplevel ou le débogueur à la main. En Common Lisp tout ce petit yoga disparaît, ce qui est du à l'association du débogueur à la REPL et à la portée dynamique des variables. Ce type de développement très interactif est semble-t-il un des points forts de Common Lisp et la norme parmi les programmeurs, c'est en tout cas une façon très agréable de travailler.
Même si les PPE de OCaml sont très puissants et relativement faciles à utiliser – moyennant compilation et installation, puis paramétrage de la REPL pour les utiliser, et je ne sais pas si le débogueur les prend en charge – il faut bien reconnaître que la fonction équivalente en Common Lisp fournie par les macros est, en comparaison, d'utilisation enfantine.
Un point sur lequel OCaml et Common Lisp se rapprochent est qu'en dépit de leur expressivité ces langages restent assez proches de la machine, ils laissent entrevoir très nettement les rouages de la machine.
Comme en OCaml, le code assembleur généré (ici par SBCL) est très lisible:
Un examen succinct montre que L1 est notre if final et le reste de la structure s'en déduit facilement. Pour une version un peu plus “bas niveau” peut être écrite en ajoutant des annotations:
L'assembleur est un peu moins facile à suivre (pour moi) mais on voit quand-même que le seul appel à une fonction (remote call) est celui fait à length pendant l'initialisation de la boucle et que dans la boucle, la seule instruction qui accède à la mémoire est celle en position F00 tout le reste ne consiste qu'en des opérations très rapides sur les registres et des sauts courts. À la fin on nettoie la pile – seule la partie après le IDIV reste pour moi très mystérieuse, mais la boucle critique est simple et claire, même avec mes connaissances rudimentaires en assembleur.
Entre dire que JavaScript est plus proche de Lisp que de Java et dire que c'est un dialecte de Lisp, il y a quand-même un petit monde que je ne franchirais pas! Au-delà de la syntaxe toute différente, les différences notables sont:
La méta-programmation, où on a du côté de JavaScript des possibilités d'introspection très développées et une fonction eval (qu'on essaie de ne pas utiliser) et de celui de Lisp un système de macros très solide, avec notamment loop et do.
Des approches assez différentes pour la programmation par objets.
La portée des variables obéit à des mécanismes différents: le variable hoisting, le mot-clef this et la seule portée lexicale des variables pour JavaScript le distinguent de Lisp.
En revanche. un gros point commun de Lisp et JavaScript, est l'accent très fort mis sur les structures de données et l'interactivité, ce qui pousse assez naturellement le programmeur à écrire des fonctions très découplées des autres, très faciles à tester.
Le livre de Crockford, auteur de l'article que tu cites, est une excellente introduction à JavaScript.
Merci pour toutes ces précisions. J'avais vu Weblocks, Panic et Parenscript
L'impression que m'a fait Weblocks est qu'il implémente l'état de l'art de la programmation web d'il y a environ 5-10 ans – ce qui est très impressionnant mais on s'en est aujourd'hui largement détourné. Est-il exact que le modèle proposé par Weblocks produit un couplage très fort entre l'UI, la logique de l'application et la base de données? Si c'est le cas c'est précisément le modèle dont on s'est radicalement éloigné ces dernières années, en faisant une UI qui communique avec des microservices via une API explicite (p.ex. en signant les requêtes, ce qui dans certains cas élimine pratiquement le besoin de maintenir une session, ce qui simplifie beaucoup la logique de l'application!), ce qui permet d'utiliser les fonctions de l'application web en RPC JSON/HTTPS et permet aux développeurs de la GUI et ceux de l'application de travailler de façon complètement découplée. (Notamment en testant les composants de la GUI avec des storybooks au lieu de devoir accéder à un environnement complet.)
Ceci dit Weblocks semble très impressionnant – et ma première impression est peut-être fausse. La documentation que tu proposes en lien ne va pas beaucoup plus loin que l'exemple minimal de la TODO liste, est-ce que tu as d'autres lectures sur Weblocks à recommander?
Un article impartial et argumenté, qui va vraiment au fond des choses. Sérieusement, à part coller deux-trois sous-entendus hasardeux à deux phrases de MAM, quel rapport avec la pensée soi-disant sexiste de cette femme? C'est d'un vide…
L’anglais et plus KISS en particulier sur la conjugaison. Il est nécessaire d’assimiler la concordance des temps (qui est propre à chaque langue) mais il n’y a pas cette difficulté que représente les terminaisons qui varient comme en français. Typiquement, en français, trois groupes de verbes (le troisième étant un gros fourre-tout…), en anglais, deux « groupes » : régulier ou non. Alors oui, en français on peut bien plus souvent connaître la personne d’un verbe conjugué en se passant du pronom/sujet, c’est vrai avec seulement quelques verbes en anglais, mais quel est l’intérêt ? Quel est l’intérêt de faire porter deux informations (le sens et la personne) au sein du même mot ?
Le fait qu'il y ait trois groupes (2 réguliers, et le groupe des irréguliers) contre deux groupes (1 régulier et le groupe des irréguliers) montre au contraire qu'il y a plus de régularités en français. :)
On compare la marque du pluriel dans les deux langues, pour rire ?
one vertex, several vertices, one foot, several feet, … :) et puis tout le sketch des dénombrables, indénombrables :)
Ce n'est pas de la grammaire mais la prononciation en anglais est encore pire qu'en français.
Après c'est un tout, mais comme non-spécialiste, je suppose que c'est particulièrement facile de sous-estimer la difficulté de la grammaire anglaise quant on en ignore tous les détails – ce qui est mon cas, je parle et écris bien, en faisant peu de fautes, mais c'est surtout parceque je lis beaucoup en anglais, et je ne connais pas la grammaire. Même si j'ai une grammaire anglaise chez moi (Berland-Delépine) qui fait quand-même quelques pages et me rappelle mon ignorance du sujet chaque fois que je l'ouvre. Alorsqu'au contraire à l'école on passe des années à apprendre la grammaire française, donc on en connaît bien plus les difficultés.
Oui tu as raison, Michèle Alliot-Marie et Christine Lagarde ont bien intégré le sexisme et le machisme et l'ont laissé guider leurs vies. C'est pour ça que l'une a été ministre de la défense et l'autre a été ministre des finances et dirige le FMI. Qu'on partage ou non leurs opinions politiques on est bien forcé de reconnaître que leur carrière est marquée par une révolte contre la place que certains veulent assigner aux femmes dans la société, et c'est précisément cette révolte qui définit le féminisme. Pour ma part j'irai jusqu'à considérer que leurs exemples sont largement plus importants pour inspirer les femmes qui voudraient se lancer dans une carrière politique que l'utilisation de tel ou tel article pour déterminer telle ou telle fonction, mais il s'agit là d'une appréciation personnelle.
C'est peut-être le cas, mais cela ne saurait épuiser tous les aspects du sujet. Michèle Alliot-Marie et Christine Lagarde par exemple veulent être appelées Madame le ministre, et une femme pharmacien m'a déjà repris alors que je la présentais comme pharmacienne, en mode “Je me suis cassé le cul à passer ce putain de diplôme alors t'as pas intérêt à laisser penser que c'est mon mari qui porte le titre.”
On peut espérer que dans quelques années des usages clairs se soient établis, mais en attendant dire “Madame le député” est tout à fait correct – en revanche si “Madame le député” préfère être appelée “Madame la députée” pourquoi pas, tant que tout le monde se comporte civilement dans l'expression de son souhait.
Qu'est-ce qui est bizarre? J'ai repris ;es mots de l'exemple de Marotte. Après il est clair que ça ne marche que si les deux noms ont des genres différents, ou si on a plein de noms d'un genre donné et un seul d'un genre différent.
# Ma réponse
Posté par Michaël (site web personnel) . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 10.
Je ne suis pas professionnel du droit, donc il s'agit d'un pur exercice d'imagination. :)
J'espère qu'on pourra bientôt lire la vraie!
[^] # Re: on vit une époque formidable
Posté par Michaël (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à 2.
Est-ce que l'équivalent de
curl https://… | sh -serait un code valide?[^] # Re: Logs
Posté par Michaël (site web personnel) . En réponse au message Backup rsync SSH. Évalué à 2.
Oui, c'est un problème ancien et il suffit d'une brève recherche pour se rendre compte qu'il y a une bonne dizaine de possibilités… je n'en ai jamais utilisé une mais pour le besoin de l'exemple j'en ai pioché une où il n'y a pas trop de plomberie à faire.
[^] # Re: Docker fourre-tout ?
Posté par Michaël (site web personnel) . En réponse à la dépêche L’application « OnlyOffice pour Nextcloud » est disponible. Évalué à 3. Dernière modification le 09 novembre 2017 à 09:58.
Ma stratégie actuelle est plutôt de ne pas faire de mise à jour. Dans l'état actuel des chose écrire des paquets pour Debian (c'est probablement le cas pour beaucoup de distributions) est une compétence à cultiver, et le processus complet est largement trop complexe pour l'utilisateur occasionnel du système. Il y a trop d'outils avec lesquels il faut interagir (pour mettre à jour le fichier ChangeLog, pour tester le paquetage, pour créer le paquet proprement dit, pour l'uploader quelque part) alors qu'en fait de moins point de vue il s'agit d'une seule opération. Ce qui est particulièrement pénible est le lien entre le ChangeLog et le nom du paquet… peut-être que la bonne façon de travailler m'échappe, mais en gros il faut avoir une branche par distribution où on veut envoyer ce paquet … alors que le programme est absolument portable. Bref: on le fait une fois pour essayer et après on se souvient à quel point c'est pénible et plein de problèmes inutiles et on concentre son énergie sur autre chose.
L'approche de FreeBSD ou MacPorts est, en comparaison, bien plus simple pour le porter.
[^] # Re: Docker fourre-tout ?
Posté par Michaël (site web personnel) . En réponse à la dépêche L’application « OnlyOffice pour Nextcloud » est disponible. Évalué à 4.
Ça montre aussi que la méthode “à l'arrache” n'est pas nouvelle et que c'est toujours mieux que de ne pas faire de paquet du tout.
Huuum, je ne suis pas sûr: par exemple bsdowl respecte tout ce qu'il peut respecter: il a son fichier
./configurequi comprend toutes les options--prefixetc. pour configurer les chemins d'installation… etc. La procédure d'installation estEt le paquetage Debian https://github.com/michipili/bsdowl/tree/debian/debian m'a coûté plusieurs heures de recherche dans plusieurs documents (apparemment la documentation officielle n'est pas à jour et tout le monde écrit sa propre documentation simplifiée…) Les courtes notes que j'en ai tiré pour mes propres besoins sont quand-même plus longues que les instructions pour MacPorts alors qu'elles sont moins générale.
# Logs
Posté par Michaël (site web personnel) . En réponse au message Backup rsync SSH. Évalué à 2. Dernière modification le 08 novembre 2017 à 21:41.
Comme les autres l'ont déjà signalé:
Il est crucial de désactiver l'identification par mot de passe et de n'utiliser que des identifications par clef publique (
PasswordAuthentication noetPubkeyAuthentication yes)Il faut créer un utilisateur Unix dédié pour la procédure sauvegarde.
Il faut montrer le moins de surface possible pour la machine, donc n'ouvrir qu'un seul port (le routeur du FAI doit permettre faire du NAT pour rediriger un port du routeur (IP publique) sur le Pi.
Un aspect qui n'a pas été encore mentionnant et qui est peut-être plus inattendu est qu'il faut impérativement configurer le système de logs et le firewall de façon appropriée… Je l'ai appris à mes dépens car il y a quelques années j'avais effectivement ce genre de montage chez moi, et j'ai rapidement remarqué que le serveur SSH était en permanence sollicité… par des attaques de dictionnaire, ce qui a rempli le dossier de logs en environ un mois, et flingué la carte SD. Je n'ai vérifié les détails mais le scénario probable de l'écriture synchrone de chaque ligne de log sur la carte SD a fait beaucoup de mal au système.
Pour se prévenir de cela, il faut donc:
Utiliser des règles de firewall qui vont rejeter les tentatives infructueuses répétées. Il y a plusieurs stratégies utilisables, j'ai rapidement regardé et l'approche de Joao S Veiga semble à la fois simple et raisonnable: il paramètre iptables pour rejeter toutes les tentatives multiples sur le port 22 (SSH) suivant de moins de 15 secondes une tentative plus ancienne.
En ce qui concerne les logs il faut vérifier que syslog ou tout autre système utilisé n'écrit pas de façon synchrone sur le disque ou bien mettre les logs sur un autre système de fichiers. Par exemple un disque USB attaché au Pi (si l'alimentation est assez forte!), un disque réseau NFS, voire envoyer tous les logs sur une autre machine via syslog, ou bien utiliser un système de fichiers tmpfs et utiliser logrotate de façon très agressive pour limiter la place consommée par ceux-ci!
[^] # Re: port ?
Posté par Michaël (site web personnel) . En réponse au message Backup rsync SSH. Évalué à 2. Dernière modification le 08 novembre 2017 à 21:20.
À signaler que répartiteur HA-PROXY permet aussi de faire ce genre de choses: une analyse du contenu ou de l'origine permet de rerouter le traffic. Avec l'avantage que c'est un outil beaucoup plus général.
[^] # Re: Docker fourre-tout ?
Posté par Michaël (site web personnel) . En réponse à la dépêche L’application « OnlyOffice pour Nextcloud » est disponible. Évalué à 7. Dernière modification le 08 novembre 2017 à 18:51.
Oui à la base c'est à ça que ça sert… cependant force est de constater que docker a un certain succès comme système de distribution ad-hoc.
J'y vois plusieurs raisons:
La plupart des systèmes de paquet sont assez compliqués, et même Ubuntu par exemple qui s'est donné la peine de réduire énormément la complexité a toujours un système hyper complexe De mon côté, auteur de logiciel, j'ai mon code source, typiquement dans un dépôt Git, une clef PGP pour signer mon paquet et un serveur FTP où télécharger (ici upload) mon paquet source, et pourtant je dois traficoter avec 4-5 outils qui sont souvent des empilements d'autres outils… bref, y'a rien de moins marrant que de construire ses paquets.
En regard, docker est assez simple et se prête bien aux techniques d'intégration continue Un Dockerfile est essentiellement une suite de commandes shell, qui en plus bénéficie d'un système de cache.
Les dépendances utilisées peuvent provenir de bien des sources différentes. Le gestionnaire de paquet d'une distribution n'est qu'un moyen comme un autre d'installer des logiciels – c'est souvent le plus puissant mais aussi le plus coûteux en terme de préparation, dès lors que quelque chose est à préparer. Les autres méthodes sont bien-sûr les tarball, mais aussi les système de paquets spécifiques aux langages ou à une communauté (par exemple npm, yarn, opam, quicklisp, gem, pip, composer pour les langages, Emacs a une fonction spéciale pour installer des packages elisp, et il me semble que certains gros logiciels comme sage ont leur propre système de distribution pour des extensions, mais je peux me tromper). Comme le Dockerfile est essentiellement un shell script, cela permet d'utiliser toutes les dépendances qu'on veut sans s'embêter à préparer des paquets pour les logiciels manquants pour toutes les distributions qu'on souhaite toucher.
Pour des logiciels d'une telle complexité, l'homogénéité des déploiements facilite la maintenance. Pour l'équipe qui développe, le nom de l'image utilisée contient en elle-même toutes les informations de version nécessaires pour essayer de reproduire un bug signalé, par exemple. Il y a régulièrement eu des initiatives pour distribuer les logiciels de cette manière (sur PC-BSD p.ex., il me semble que Ubuntu ou Cent-OS avait aussi introduit une forme de paquet “blob” il y a quelques années, sans que je sache ce qu'ils sont devenus, ou encore les “App bundle” de Mac OS-X, ou les applications Windows pour quitter le monde du libre).
Probablement pour à peu près les mêmes raisons, en 2001, lorsque Open Office est sorti il était distribué soit en source soit en binaires précompilés mais pas de véritables paquets. Lien Wayback Machine
[^] # Re: mises à jours et docker
Posté par Michaël (site web personnel) . En réponse au journal Les outils de l'IT pour un FabLab. Évalué à 3.
C'est très juste, qu'on parle de virtualisation lourde par exemple via VirtualBox ou VMWare ou bien de virtualisation plus légère via des conteneurs ou des jails FreeBSD, on retrouve à peu près les mêmes avantages: c'est technologies et ces méthodes de travail n'ont, à bien y regarder, rien de très nouveau ou de très révolutionnaire: la première fois que j'ai utilisé VM Ware c'était en 2001 et les jails de FreeBSD existent depuis 2000 (FreeBSD 4.0).
Là où toutes ces possibilités se distinguent, c'est la communauté d'utilisateurs, y compris les utilisateurs industriels, et l'outillage disponible… et bien-sûr dans une certain mesure les effets de mode. En pratique c'est plus facile de travailler avec des conteneurs qu'avec des machines virtuelles, tout simplement parcequ'on a une couche en moins et que les outils s'occupent de la création du réseau etc.
Je travaille beaucoup avec docker et ce qui pêche le plus à mon avis c'est d'une part la commande
docker buildutilisée pour préparer les images, qui ne propose pas du tout la bonne interface: si on veut travailler efficacement il faut manier la commandedocker buildà travers un script qui s'occupe de plein de petits détails. Ensuite la documentation est plutôt mauvaise: très fouilli, mal organisée, la présentation est dégueu ce qui rend la lecture difficile, le rédacteur change tout le temps d'avis sur le type de document qu'il écrit (référence, matériel d'introduction, exemples)…Bien évidemment on peut avoir des données persistant indépendamment des conteneurs. Dans le langage de docker il s'agit des volumes. Cependant, à cause des limitations de la commande
docker build(limitations qui ont par ailleurs de bonne raisons d'être!) la préparation de l'image dans certains cas demande des soins particuliers.[^] # Re: mises à jours et docker
Posté par Michaël (site web personnel) . En réponse au journal Les outils de l'IT pour un FabLab. Évalué à 7.
Faire des va et viens a l'inconvénient que c'est une excellente recette pour fabriquer des “serveurs flocon de neige” (les flocons de neige sont tous différents les uns des autres) alors que les solutions à la docker permettent d'implémenter facilement la méthode du serveur constant (immutable server pattern en vo), ce qui signifie qu'au lieu de faire des va et viens on jette tout et on repart sur du neuf. La méthode du serveur constant a l'intérêt qu'elle qu'elle aide à maintenir l'homogénéité d'un parc et à garantir la reproductibilité d'un environnement. Le cas “à la docker” est particulièrement intéressant pour déployer un grand nombre de copies de la même application ou bien pour faire coïncider le plus possible l'environnement de développement avec celui de la production.
Docker et APT, ou tout autre gestionnaire de version de paquets ont en principe des fonctionnalités presqu'orthogonales.
# Reproductibilité
Posté par Michaël (site web personnel) . En réponse au journal Optimisation, microbenchmark et compilation Just In Time : quand 1 + 1 ne font pas 2. Évalué à 8.
Ce qui compte pour mesurer la performance d'un programme pour s'orienter dans le développement c'est d'appliquer la méthode scientifique. Le but est donc de construire un énoncé falsifiable et dans le contexte de l'optimisation de ta méthode
functionToMeasureon aimerait bien construire un énoncé du type “l'implémentation A est toujours plus performante que l'implémentation B” mais ce type d'énoncé n'au aucune chance de marcher.Dans la liste des défauts de mon énoncé il y a bien-sûr le fait qu'il faut expliquer ce que veut dire “performant” ce qui n'est pas forcément facile et en plus imaginer une expérience qui mesure cette performance dont on a précisé la teneur, et le but est d'arriver à une expérience dont le résultat est reproductible, autrement on ne peut rien conclure du tout. Mais ensuite la durée d'exécution (“performance en temps”) se comporte super mal! À preuve:
Le même programme lancé sur la même machine opérant sur la même donnée après un cold boot peut livrer des temps d'exécution très différents, sans problème du simple au double. Il y a des milliers de raisons possibles à cela, dont l'alignement mémoire qui a une influence directe sur la stratégie d'utilisation des caches.
Un programme plus long qu'un autre (par exemple bordé de NOPs ou qui fait des contrôles d'indice sur un tableau) peut parfois être rapide!
Les ordinateurs sont très complexes et il y a des tas de facteurs qui influent sur la vitesse d'exécution des programmes, même la taille d'une variable d'environnement non utilisée par le programme!
Voir par exemple Producing Wrong Data Without Doing Anything Obviously Wrong!. Un autre exemple rigolo de biais est la question la plus votée de SO.
Ainsi, même si on réalise que les mesures individuelles n'ont aucun sens et qu'il faut toujours mesurer des distributions, on ne fait que s'avancer vers un problème très compliqué et si on veut mesurer sérieusement la vitesse d'exécution d'un programme on doit donc construire un protocole expérimental qui se débarrasse de tous les biais… et quand on le fait pour GCC on découvre que l'incidence de l'utilisation de -O3 par rapport à -O2 est indistiguable d'un bruit statistique.
Des problèmes particulièrement difficiles en pratique sont en outre la production de données dont la distribution ressemble à celles de l'application réelle, et pour les applications réseau la reproduction d'une charge ressemblant à celle de l'application réelle.
[^] # Re: quel desktop ?
Posté par Michaël (site web personnel) . En réponse au message Alerte batterie vide trop courte XFCE.. Évalué à 3.
Je pense qu'il s'agit de XFCE. ;)
[^] # Re: Le contraire
Posté par Michaël (site web personnel) . En réponse au journal Une Demande d’Emploi en 2017. Évalué à 8.
L'exagération outrancière du point de vue aurait pu te mettre la puce à l'oreille. :)
Pour apporter de l'eau à son moulin, j'aime bien quelques exemples:
Dans les noms propres, comme en français, l'anglais ne connaît aucune limite: tous les -cestershire (Gloucestershire, Worcestershire, etc.), Greenwich, Fowey, …
Dans les noms communs le plus rigolo est
lieutenant |lɛfˈtɛnənt|Les mots en -ough se prononcent presque tous différemment les uns des autres.
On ne prononce pas pareil desert selon que ce soit un nom ou un verbe
On ne prononce pas pareil read selon que ce soit le présent ou le prétérit
Les mots consistant d'une seule syllabe avec oo comme voyelle (foot, mood, door, blood, etc.) se rangent en quatre catégories selon comme on prononce le oo.
[^] # Re: commentaire link
Posté par Michaël (site web personnel) . En réponse au journal WPA2 est bronsonisé. Évalué à 4.
Crêpes au citron et sucre, de loin les meilleures! :P
[^] # Re: Perlissade
Posté par Michaël (site web personnel) . En réponse au journal C'est décidé, j'apprends Common Lisp!. Évalué à 4.
Pas vraiment la façon dont je la pense mais comme programmeur OCaml expérimenté je peux dire que le cycle de développement avec Common Lisp est complètement différent de ce qu'il est avec OCaml.
La raison principale est la proximité de l'évaluation du programme avec l'écriture de celui-ci. En OCaml on peut utiliser la REPL pour mettre au point une fonction mais c'est assez compliqué à mettre en place parcequ'il faut écrire un
.ocamlinitspécifique au projet qui charge les modules nécessaires au module où vit notre fonction et installe les pretty-printers. Si on se rend compte qu'on a besoin du débogueur, il faut refaire toute cette configuration avec le débogueur. Enfin, une fois qu'on est content de sa fonction on peut continuer la mise au point avec une autre fonction d'un autre module et cela demande d'ajuster les fichiers de configuration pour le toplevel ou le débogueur à la main. En Common Lisp tout ce petit yoga disparaît, ce qui est du à l'association du débogueur à la REPL et à la portée dynamique des variables. Ce type de développement très interactif est semble-t-il un des points forts de Common Lisp et la norme parmi les programmeurs, c'est en tout cas une façon très agréable de travailler.Même si les PPE de OCaml sont très puissants et relativement faciles à utiliser – moyennant compilation et installation, puis paramétrage de la REPL pour les utiliser, et je ne sais pas si le débogueur les prend en charge – il faut bien reconnaître que la fonction équivalente en Common Lisp fournie par les macros est, en comparaison, d'utilisation enfantine.
Un point sur lequel OCaml et Common Lisp se rapprochent est qu'en dépit de leur expressivité ces langages restent assez proches de la machine, ils laissent entrevoir très nettement les rouages de la machine.
Comme en OCaml, le code assembleur généré (ici par SBCL) est très lisible:
Un examen succinct montre que L1 est notre
iffinal et le reste de la structure s'en déduit facilement. Pour une version un peu plus “bas niveau” peut être écrite en ajoutant des annotations:L'assembleur est un peu moins facile à suivre (pour moi) mais on voit quand-même que le seul appel à une fonction (remote call) est celui fait à
lengthpendant l'initialisation de la boucle et que dans la boucle, la seule instruction qui accède à la mémoire est celle en positionF00tout le reste ne consiste qu'en des opérations très rapides sur les registres et des sauts courts. À la fin on nettoie la pile – seule la partie après le IDIV reste pour moi très mystérieuse, mais la boucle critique est simple et claire, même avec mes connaissances rudimentaires en assembleur.[^] # Re: Lisp + Ecma
Posté par Michaël (site web personnel) . En réponse au journal C'est décidé, j'apprends Common Lisp!. Évalué à 4. Dernière modification le 14 octobre 2017 à 16:41.
Entre dire que JavaScript est plus proche de Lisp que de Java et dire que c'est un dialecte de Lisp, il y a quand-même un petit monde que je ne franchirais pas! Au-delà de la syntaxe toute différente, les différences notables sont:
La méta-programmation, où on a du côté de JavaScript des possibilités d'introspection très développées et une fonction
eval(qu'on essaie de ne pas utiliser) et de celui de Lisp un système de macros très solide, avec notammentloopetdo.Des approches assez différentes pour la programmation par objets.
La portée des variables obéit à des mécanismes différents: le variable hoisting, le mot-clef this et la seule portée lexicale des variables pour JavaScript le distinguent de Lisp.
En revanche. un gros point commun de Lisp et JavaScript, est l'accent très fort mis sur les structures de données et l'interactivité, ce qui pousse assez naturellement le programmeur à écrire des fonctions très découplées des autres, très faciles à tester.
Le livre de Crockford, auteur de l'article que tu cites, est une excellente introduction à JavaScript.
[^] # Re: Bravo
Posté par Michaël (site web personnel) . En réponse à la dépêche Inauguration d'un « bureau ouvert » à l’Assemblée nationale française. Évalué à 3.
Ce copinage s'il était avéré serait probablement problématique, mais quel rapport avec la discussion actuelle?
[^] # Re: Oui mais non
Posté par Michaël (site web personnel) . En réponse au journal C'est décidé, j'apprends Common Lisp!. Évalué à 2.
Merci pour toutes ces précisions. J'avais vu Weblocks, Panic et Parenscript
L'impression que m'a fait Weblocks est qu'il implémente l'état de l'art de la programmation web d'il y a environ 5-10 ans – ce qui est très impressionnant mais on s'en est aujourd'hui largement détourné. Est-il exact que le modèle proposé par Weblocks produit un couplage très fort entre l'UI, la logique de l'application et la base de données? Si c'est le cas c'est précisément le modèle dont on s'est radicalement éloigné ces dernières années, en faisant une UI qui communique avec des microservices via une API explicite (p.ex. en signant les requêtes, ce qui dans certains cas élimine pratiquement le besoin de maintenir une session, ce qui simplifie beaucoup la logique de l'application!), ce qui permet d'utiliser les fonctions de l'application web en RPC JSON/HTTPS et permet aux développeurs de la GUI et ceux de l'application de travailler de façon complètement découplée. (Notamment en testant les composants de la GUI avec des storybooks au lieu de devoir accéder à un environnement complet.)
Ceci dit Weblocks semble très impressionnant – et ma première impression est peut-être fausse. La documentation que tu proposes en lien ne va pas beaucoup plus loin que l'exemple minimal de la TODO liste, est-ce que tu as d'autres lectures sur Weblocks à recommander?
[^] # Re: Bravo
Posté par Michaël (site web personnel) . En réponse à la dépêche Inauguration d'un « bureau ouvert » à l’Assemblée nationale française. Évalué à 3.
Un article impartial et argumenté, qui va vraiment au fond des choses. Sérieusement, à part coller deux-trois sous-entendus hasardeux à deux phrases de MAM, quel rapport avec la pensée soi-disant sexiste de cette femme? C'est d'un vide…
[^] # Re: Trollons
Posté par Michaël (site web personnel) . En réponse à la dépêche Le développement de « Débattons » est lancé !. Évalué à 9.
Tu dis ça parceque tu es contre la terre ronde, le port du casque à vélo, l'écriture inclusive, le gluten et les claviers qui se blo
[^] # Re: Singulier, pluriel, faut savoir !
Posté par Michaël (site web personnel) . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 6. Dernière modification le 07 octobre 2017 à 14:00.
Le fait qu'il y ait trois groupes (2 réguliers, et le groupe des irréguliers) contre deux groupes (1 régulier et le groupe des irréguliers) montre au contraire qu'il y a plus de régularités en français. :)
one vertex, several vertices, one foot, several feet, … :) et puis tout le sketch des dénombrables, indénombrables :)
Ce n'est pas de la grammaire mais la prononciation en anglais est encore pire qu'en français.
Après c'est un tout, mais comme non-spécialiste, je suppose que c'est particulièrement facile de sous-estimer la difficulté de la grammaire anglaise quant on en ignore tous les détails – ce qui est mon cas, je parle et écris bien, en faisant peu de fautes, mais c'est surtout parceque je lis beaucoup en anglais, et je ne connais pas la grammaire. Même si j'ai une grammaire anglaise chez moi (Berland-Delépine) qui fait quand-même quelques pages et me rappelle mon ignorance du sujet chaque fois que je l'ouvre. Alorsqu'au contraire à l'école on passe des années à apprendre la grammaire française, donc on en connaît bien plus les difficultés.
[^] # Re: Bravo
Posté par Michaël (site web personnel) . En réponse à la dépêche Inauguration d'un « bureau ouvert » à l’Assemblée nationale française. Évalué à 4.
Oui tu as raison, Michèle Alliot-Marie et Christine Lagarde ont bien intégré le sexisme et le machisme et l'ont laissé guider leurs vies. C'est pour ça que l'une a été ministre de la défense et l'autre a été ministre des finances et dirige le FMI. Qu'on partage ou non leurs opinions politiques on est bien forcé de reconnaître que leur carrière est marquée par une révolte contre la place que certains veulent assigner aux femmes dans la société, et c'est précisément cette révolte qui définit le féminisme. Pour ma part j'irai jusqu'à considérer que leurs exemples sont largement plus importants pour inspirer les femmes qui voudraient se lancer dans une carrière politique que l'utilisation de tel ou tel article pour déterminer telle ou telle fonction, mais il s'agit là d'une appréciation personnelle.
[^] # Re: Bravo
Posté par Michaël (site web personnel) . En réponse à la dépêche Inauguration d'un « bureau ouvert » à l’Assemblée nationale française. Évalué à 5.
C'est peut-être le cas, mais cela ne saurait épuiser tous les aspects du sujet. Michèle Alliot-Marie et Christine Lagarde par exemple veulent être appelées Madame le ministre, et une femme pharmacien m'a déjà repris alors que je la présentais comme pharmacienne, en mode “Je me suis cassé le cul à passer ce putain de diplôme alors t'as pas intérêt à laisser penser que c'est mon mari qui porte le titre.”
On peut espérer que dans quelques années des usages clairs se soient établis, mais en attendant dire “Madame le député” est tout à fait correct – en revanche si “Madame le député” préfère être appelée “Madame la députée” pourquoi pas, tant que tout le monde se comporte civilement dans l'expression de son souhait.
[^] # Re: Lisp + React
Posté par Michaël (site web personnel) . En réponse au journal C'est décidé, j'apprends Common Lisp!. Évalué à 4.
Apparemment oui, mais il ne faut pas oublier que Clojure est un dialecte de Lisp, donc la syntaxe est légèrement différente,.
[^] # Re: Singulier, pluriel, faut savoir !
Posté par Michaël (site web personnel) . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 1.
Qu'est-ce qui est bizarre? J'ai repris ;es mots de l'exemple de Marotte. Après il est clair que ça ne marche que si les deux noms ont des genres différents, ou si on a plein de noms d'un genre donné et un seul d'un genre différent.