steph1978 a écrit 3052 commentaires

Comme certaine commentaire, je me pose la question de la nécessité d'un serveur de rasterisation alors que d'autres applications s'en charge localement, y compris sur mobile, comme OSMAND.

Ensuite, je trouve la proposition de P2P très intéressante ; ainsi tous les utilisateurs participeraient à l'effort et de manière pérenne.

Enfin, si il est possible d'installer un miroir quelque part, je pourrais fournir un peu de CPU + Bande passante sur un serveur en France. Car je suis un grand fan d'OSM.

son propre CSPRNG

C'est peut être le P (pour Pseudo) qui gène pour une application critique…

Le périphérique peut utiliser deux sources d'entropies (voire les fondements théoriques): * l'activité des ondes radio alentours

C'est ce qu'utilise random.org. Je me suis toujours demandé si au fin fond d'un datacenter c'était une source fiable et abondante ? Vu le débit proposé par random.org, c'est une source peu abondante (1500b/s je crois).

Est-ce que cumuler des sources pas très fiables car proprio ou avec un débit faible peut garantir une source fiable ?

BlogDash !

Ça a l'air intéressant comme application. D'autant plus que j'aime bien travailler avec Flask. Je vais donc regarder ton code.

Par contre, je propose un autre titre : PictureDash.
Ton besoin était sûrement d'afficher des graphes mais au final, il affiche des images.
Et ne semble pas proposer de fonctions liées au fait que ce soient des graphes et donc que cela comporte des axes, des données, etc.

second degré, c'est ça ?

Étant donné que le système économique actuel considère que les ressources naturelles sont gratuites, la monnaie n'est pas une mesure pertinente de l'empreinte écologique.
Range tes euros !

Je me sers souvent de cet outil mais il me faut forcément la docs en ligne car il y a mille options.
J'ai souvent constaté que le site est très très lent, avec de nombreux timeout.
Victime de leur succès ou d'une mauvaise architecture de site web.

Quant à la qualité auquel je fais référence, c'est celle, comme je l'ai déjà écrit, perçue par les utilisateurs de mes logiciels et dont ils me font part au travers de leurs retours.

Quand le client d'un plombier est content, c'est parce qu'il a l'eau chaude et l'eau froide à tous les étages et pas de fuites. Et pas parce que le plombier a une belle caisse à outils et sait se servir du chalumeau.

C'est donc bien la capacité à délivrer des fonctionnalités qui ressort, et la maintenabilité. Et tu sembles avoir ces capacités.

La difficulté ici c'est que tu ne peux pas nous présenter tes réalisations et ne peux nous montrer que la caisse à outils. D'où un moindre transport de ma part…

Je vais redire un peu ce qui transparaît déjà dans les autres commentaires mais tant pis.

Je ne sais pas exactement quel est le but que tu poursuis. Mais en publiant à propos de ton projet, j'imagine que tu souhaites une certaine adhésion/contribution.

une démarche de développement d'un framework qui vise à faciliter le développement de logiciels (potentiellement libres) de qualité

Je ne sais pas ce que tu mets derrière qualité ?

1. Maintenable ? Par qui ?
2. Capable de délivrer rapidement des fonctionnalités ? Par qui ?
3. Dont tu maîtrise chaque ligne de code ?

J'ai l'impression que tu t'ai focalisé sur la dernière option.

Je ne crois pas - et c'est un avis purement personnel - au logiciel parfait.

Je suis pour une approche beaucoup plus pragmatique/agile:

• Un backlog de fonctionnalités. On implémente le plus prioritaire avec quelques outils pour aller plus vite.
• On livre. On a des retours utilisateurs (bug ou feature request)
• On incrémente, en refactorisant (par exemple en modifiant l'architecture logicielle, en incluant d'autres bibliothèques, etc.).
• à un moment, on ajoute de l'intégration continue, une site vitrine, la doc, etc.

Là tu vas mettre des années à fournir quelque chose que tes potentiels utilisateurs auront déjà trouvé (ou appris à se passer) depuis longtemps…

Ça passe par internet parce que tu utilises son instance de démo.
C'est vrai pour tous les services qu'on nous a proposé ici.
Après, si ça te plaît, tu installes en local ou où tu veux.
Tu proposes pas d'alternatives, sachant que la plupart (genre Cloud) auront cet inconvénient by design.

Du coup, ton commentaire, c'était juste histoire d'en faire un.
Pour resté au top de ta forme quoi.
Bah désolé d'avoir interféré dans ton entraînement quotidien.

C'est gentil de moinsser puis de m'inviter à.

Donc voilà, c'est fait.

# traceroute -T -p 80 services.fiveinthewood.com
traceroute to services.fiveinthewood.com (88.171.196.37), 30 hops max, 60 byte packets
 1  gre92-9-88-171-196-37.fbx.proxad.net (88.171.196.37)  0.232 ms  0.343 ms  0.375 ms
 2  gre92-9-88-171-196-37.fbx.proxad.net (88.171.196.37)  0.772 ms  0.745 ms  0.676 ms

Depuis une machine en wifi, je demande un accès à un service public hébergé sur une machine filaire, derrière la même box.

Résultat conforme à la théorie du routage IP : premier hop : la box qui fait routeur. Deuxième hop : la box qui natte vers la machine. Fin.

Je ne vois pas ce qui pouvait amener à penser le contraire et encore moins à moinsser sans avoir testé.

Un transfert de fichier entre deux machines passant par ton IP publique ne fait que passer par ta box. Ça fait pas des centaines de km…

Mais en attendant, les yakafokon, ça me fatigue.

Bon bah j'arrête de te prendre la tête alors.
Je ferai à ma sauce et les autres aussi.
Si ce que tu as mis en place satisfait des utilisateurs, c'est l'essentiel.

Le journal commence comme ça:

Github propose depuis un bout de temps les pages github

Si le but, tout à fait louable, est d'attirer les gens vers Framagit, il est préférable de proposer des fonctionnalités au moins au même niveau.

Soit tu proposes quelque chose

Je propose aux développeurs, de prendre un hébergement web et un nom de domaine et d'uploader en FTP le résultat de la génération de page dessus. Quitte à faire le travail de génération, autant avoir son domaine.

Je propose à l'auteur d'envisager de mettre à disposition au moins un générateur. Ils sont tous plus ou moins équivalents en terme de fonctionnalités et de fonctionnement (markdown + front matter + templating). Hugo est un binaire statiquement compilé. L'exécuté dans un container devrait protéger la plateforme.

architecture compliquée

Si, comme tu le mentionne, ça s'installe sur un pc de bureau, ça doit pas être si compliqué que ça…

Je vois deux problèmes de ne pas avoir le générateur sur la plateforme.

D'abord, le générateur doit être installé sur toutes les machines qui peuvent créer du contenu. Sur un pc de développeur, pas trop de problème, il saura le faire. ça devient un peu plus difficile pour qqun qui ne ferai que de la rédaction de contenu ; et c'est impossible sur une tablette par exemple.

En admettant que la cible ne soient que les développeurs, reste un souci. Le repository git va contenir des fichiers générés alors que son rôle est de contenir des sources. C'est un peu comme si on y stockait les .o ou les .class.

Si la plateforme ne peut pas fournir le générateur, elle devrait simplement proposer un ftp. Les fichiers générés sur la machine du développeur seraient uploadé sur le FTP plutôt que pushées dans un git.

Quel rapport entre la langue de bois et les anglicismes ?

Tu pousses du contenu à mettre en page sur le git.
Il faut bien qu'un générateur de site tourne quelque part.
Puis qu'il ne tourne pas sur framagit, il faut qu'il tourne ailleurs.
Donc un serveur quelque part : un VM, une lambda fonction AWS, un bout de truc avec un CPU quoi.

Si il faut mettre en place un générateur soi même ; et donc avoir un serveur qui tourne, autant trouver un hébergement web avec un domaine en propre et faire un push ftp.

J'avais d'abord intégré l'utilisation de générateurs de sites statiques (Pelican, Hugo, Lektor et Jekyll), mais j'ai laissé tombé devant la complexité de la sécurisation du processus (plugins, évolution des générateurs à surveiller, etc).

Je veux bien que cela ne soit pas simple mais je pense pourtant que c'est un incontournable.

Peut être se limiter à un générateur, sans modules…

Pour le recyclage, je crois que les deux vont à la consigne.

Alors là je ne suis pas du tout en phase. Une flak ça se conserve précieusement, surtout si c'est un kado. Un bottle, ça se met au recyclage /.

La valeur de linkedin n'est pas dans le code mais dans la base utilisateurs.
Je vois pas comment M$ aurait pu mieux investir 26M$ pour les acquérir…

Pareil.

Gain en utilisabilité, sûr.
On pourra faire des scripts shell qui liront ou écriront sur les fichiers.
C'est donc une très bonne nouvelle.

Mais pourquoi gain en performance ?

J'ai un peu joué avec Angel-PS1, c'est vraiment bien !
J'aime bien l'approche pipe+démon tendant à minimiser la prise de ressources et donc maximiser les perf.
J'aime bien aussi le packaging en un seul fichier.
Petit bémol sur la doc. J'ai du dépiauter le code du gros fichier perl pour voir un peu ce qui pouvait être fait avec l'outil. Les exemples ne sont pas super parlants voire contre productifs quant à la gestion des couleurs.

Mon prompt :

(
    LoadAvgPercent, "*",
    Time, "*",
    Yellow,
    $ENV{USER},
    Blue,
    "@",
    \'\h',
    ' ',
    White,
    [ AngelPS1::Shell->WorkingDir_Tilde ],
    ' ',
    sub { my $err = $_[0]->{'?'}; $err == 0 ? () : (Red, [ $err ], ' ') },
    AngelPS1::Shell->UserPrivSymbol,
    ' ',
)

A ce sujet une petite anecdote perso :
J'ai commandé sur internet un bidule auprès d'un vendeur au canada.

Je n'ai pas lu Canada ? j'en suis pourtant sûr.

Quand tu achètes un produit d'import en France (=produit venant d'un pays hors UE), il arrive avec un prix hors taxe (dont le transport fait partie) et quand tu vas dans ton magasin, tu payes donc prix_de_base*(1+frais_de_douane)*(1+TVA).
En commandant directement à l'étranger, tu as une forte chance de ne payer que prix_de_base et une faible chance de payer la totalité. Et comme je le disais, il n'y a pas de pénalité car les douanes ne considèrent pas qu'il y a fraude. C'est une tolérance pour les particuliers parce qu'il n'y a pas vraiment moyen de déclarer sa marchandise avant qu'elle ne soit contrôler. Un pro qui ne déclare pas sa marchandise lui risque bien plus.

Tu payes des droits de douane sur les trucs que tu achètes en France ou dans l'union européenne toi ?

Si c'est un produit importé d'un pays hors UE, oui, bien sûr. Il est juste pas détaillé sur l'étiquette en magasin.