Comme il s'agit d'un incident logiciel (rm) et non matériel (crick crik crik clack clack), ils ne feront rien de plus que testdisk. Enfin si, ils présenteront une jolie facture.
Unetbootin permet de conserver une clé usb fonctionnelle comme conteneur de fichiers (FS FAT) tout en permettant de démarrer dessus (loader dans le MBR).
Par exemple avoir une distribution live qui prend 1GB sur une clé de 4GB et pouvoir encore stocker 3GB de fichiers.
Ça rend un service un peu différent de dd.
Certes on a rencontré pendant longtemps quelques […] mini-PC bas de gamme avec des Atom en 32 bits, mais bon c'est rare maintenant surtout qu'ils ne feraient même pas tourner une distribution actuelle
Mon eeepc tourne encore très bien en Debian 8.3.
Et je suis triste de voir que certain produit ne sont plus distribué en 32bit (par exemple Docker, alors que LXC existe).
For example, imagine a malicious "secure randomness" USB device that's actually spying on all your other randomness sources through various side channels
ça suppose que la mauvaise source peut espionner les autres sources.
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.
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 ?
Ç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.
É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é ?
Maintenable ? Par qui ?
Capable de délivrer rapidement des fonctionnalités ? Par qui ?
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.
# 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é.
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.
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.
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.
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.
[^] # Re: Importance des données
Posté par steph1978 . En réponse au message Récupérations de dossier effacé par erreur ?. Évalué à 3.
Comme il s'agit d'un incident logiciel (rm) et non matériel (crick crik crik clack clack), ils ne feront rien de plus que testdisk. Enfin si, ils présenteront une jolie facture.
[^] # Re: Clé usb d'install
Posté par steph1978 . En réponse au journal Retour d'expérience Achat PC portable LDLC SK1-I3-4-S1. Évalué à 3.
Unetbootin permet de conserver une clé usb fonctionnelle comme conteneur de fichiers (FS FAT) tout en permettant de démarrer dessus (loader dans le MBR).
Par exemple avoir une distribution live qui prend 1GB sur une clé de 4GB et pouvoir encore stocker 3GB de fichiers.
Ça rend un service un peu différent de dd.
[^] # Re: Modération?
Posté par steph1978 . En réponse à la dépêche Unixcorn, trois mois plus tard : évolutions, remises en questions et stabilisation. Évalué à 2.
Ça va j'en ai compté que… 16, ah ouai quand même !
[^] # Re: Comparaison
Posté par steph1978 . En réponse au journal Gnew 2016.2. Évalué à 4. Dernière modification le 08 août 2016 à 10:30.
Sur cmsmatrix
Sur wikipedia
Avec 1200 projets recensés, c'est sûr que le travail est énorme. Cependant, je suis étonné qu'un major comme wordpress ne soit pas à jour.
Je vais poser la question différemment de ComputingFroggy.
Qu'est ce qui t'as fait toi développer ton propre outil de CMS ?
[^] # Re: Se tenir au courant ?
Posté par steph1978 . En réponse au journal x86 ou x86_64 ?. Évalué à 5.
Mon eeepc tourne encore très bien en Debian 8.3.
Et je suis triste de voir que certain produit ne sont plus distribué en 32bit (par exemple Docker, alors que LXC existe).
[^] # Re: Source = Web
Posté par steph1978 . En réponse au journal OneRNG: générateur de nombres aléatoires open hardware/source. Évalué à 2.
ça suppose que la mauvaise source peut espionner les autres sources.
# miroir
Posté par steph1978 . En réponse à la dépêche Une grosse tuile pour GNOME Maps. Évalué à 4.
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.
[^] # Re: L’entropie est à consommer avec modération
Posté par steph1978 . En réponse au journal OneRNG: générateur de nombres aléatoires open hardware/source. Évalué à 1.
C'est peut être le P (pour Pseudo) qui gène pour une application critique…
# sources
Posté par steph1978 . En réponse au journal OneRNG: générateur de nombres aléatoires open hardware/source. Évalué à 2.
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 ?
[^] # Re: PictureDash
Posté par steph1978 . En réponse à la dépêche GraphDash, ou comment construire une interface web simple pour vos graphes. Évalué à 2.
BlogDash !
# PictureDash
Posté par steph1978 . En réponse à la dépêche GraphDash, ou comment construire une interface web simple pour vos graphes. Évalué à 4.
Ç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.
# proprement !
Posté par steph1978 . En réponse au journal Financer le web proprement grâce à la pub et une paire de modules Firefox. Évalué à 3.
second degré, c'est ça ?
[^] # Re: Écologie
Posté par steph1978 . En réponse au journal Financer le web proprement grâce à la pub et une paire de modules Firefox. Évalué à 2.
É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 !
# ça répond
Posté par steph1978 . En réponse au message Graphviz, y'a plus ?. Évalué à 3.
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.
[^] # Re: anti-pattern NIH
Posté par steph1978 . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 6.
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…
# anti-pattern NIH
Posté par steph1978 . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 4.
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.
Je ne sais pas ce que tu mets derrière qualité ?
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:
Là tu vas mettre des années à fournir quelque chose que tes potentiels utilisateurs auront déjà trouvé (ou appris à se passer) depuis longtemps…
[^] # Re: On n'arrête pas le progrès
Posté par steph1978 . En réponse au journal dl.center : partage de fichier entre périphérique. Évalué à 2.
Ç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.
[^] # Re: On n'arrête pas le progrès
Posté par steph1978 . En réponse au journal dl.center : partage de fichier entre périphérique. Évalué à 0.
C'est gentil de moinsser puis de m'inviter à.
Donc voilà, c'est fait.
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é.
[^] # Re: On n'arrête pas le progrès
Posté par steph1978 . En réponse au journal dl.center : partage de fichier entre périphérique. Évalué à -3.
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…
[^] # Re: générateur de page
Posté par steph1978 . En réponse au journal FsPages : un publicateur de pages statiques pour Gitlab. Évalué à 3.
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.
[^] # Re: générateur de page
Posté par steph1978 . En réponse au journal FsPages : un publicateur de pages statiques pour Gitlab. Évalué à 2.
Le journal commence comme ça:
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.
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.
[^] # Re: générateur de page
Posté par steph1978 . En réponse au journal FsPages : un publicateur de pages statiques pour Gitlab. Évalué à 4.
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.
[^] # Re: la langue de bois !!!
Posté par steph1978 . En réponse à la dépêche Jerry Do-It-Together assembler un ordinateur dans un bidon de 20 litres. Évalué à 2.
Quel rapport entre la langue de bois et les anglicismes ?
[^] # Re: générateur de page
Posté par steph1978 . En réponse au journal FsPages : un publicateur de pages statiques pour Gitlab. Évalué à 1. Dernière modification le 22 juin 2016 à 00:11.
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.
[^] # Re: générateur de page
Posté par steph1978 . En réponse au journal FsPages : un publicateur de pages statiques pour Gitlab. Évalué à 2.
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.