ghusson a écrit 169 commentaires

Ce journal montre comment se mettre vite fait à git et peut être pas de la bonne manière.
Je propose aux connaisseurs de partager ici des URLs qui expliquent comment bien utiliser git.
Merci pour tout vos retours.

Commencer par lire la doc ici : https://git-scm.com/book/fr/v2
Pour un serveur auto-hébergé, voir ici : https://about.gitlab.com/products/

J'ai vu gitlab, j'installerai ça certainement un jour. Pour rappel, j'ai passé une seule journée sur la question, et il faut que j'avance mes projets. Quand j'aurai de plus gros besoins ou une plus grosse équipe, je reverrai tout ça.
Pour l'instant je vais fonctionner en mode "quick and dirty" :)

Merci pour les suggestions, je garde ça de côté pour le moment.

Merci pour tes retours. Je vais faire un premier cycle comme ça dans un premier temps.
Quand j'aurai de plus gros besoins, je lirai la doc (merci pour le lien) et j'installerai gitlab.
Pour le moment, j'avance. Ce sera toujours mieux que pas de repo du tout.

Je trouve qu'il y a peu de lignes pour le code VHDL. Par exemple pour l'ALU (https://github.com/onchipuis/mriscvcore/tree/master/ALU) : environ 500 lignes, je m'attends à plus que ça… Un gentil lecteur compétent pourrait il éclairer ma lanterne ?

Parce que j'aime bien avoir le code produit pas ma société sur un serveur que ma société maîtrise.
Pour l'instant je n'ai pas besoin d'interface graphique, je n'ai pas beaucoup de développeurs, je fais "dans mon coin".
Et cela me satisfait pour commencer.
Tout en sachant qu'un jour je mettrai certainement des projets sur gitlab, mais je passerai plus de temps à lire la doc avant d'y passer :-) Et pour l'instant le temps me manque… donc j'essaye d'optimiser.

Pourquoi j'aurais besoin d'un rebase si je réconcilie les branches de dev avec l'arbre maitre ?
Après, je sais que c'est limité comme manière d'utiliser git. Pour une petite équipe je pense que ça suffit.
Quand j'aurai besoin de plus, je passerai plus de jours à lire la doc :-)

J'ai peut-être pas vraiment les yeux en face des trous ce matin, mais je comprend pas bien pourquoi faire ça.

Pourquoi faire ça : je ne sais pas, c'était dans la doc :-)
J'ai bien compris qu'il y avait des commandes simplifiées. Mais cela ne fait pas de mal de connaître un peu le fonctionnement interne. En l’occurrence, le paragraphe qui te choque est exécuté une seule fois à la création. Moi ça ne me pose pas de problème :-) Personnellement, j'aime bien avoir une vue (même partielle, mais des bases) de ce qu'il y a sous le capot pour réagir plus vite en cas de problème. Les notions de work dir, cache, tree sont à mon sens essentielles pour comprendre ce que l'on fait. D’où les premiers paragraphes.

Donc c'est quoi ton workflow ?

Un serveur central de référence.
Des développeurs qui synchronisent régulièrement (au moins 1 fois / jour) leur développement sur le serveur.
Quand les développeurs sont satisfaits de leur travail (code fonctionnel, testé), il faut un processus de réconciliation (merge).
La je sèche un peu… entre tag, tree et branch. Ce que j'imagine : les développeurs vont créer une branche de dev, bosser dessus, la tagger pour réconciliation quand "c'est prêt", réconcilier puis enfin supprimer la branche ?

Si tu as un dépôt git il suffira d'ajouter une nouvelle remote pour pouvoir envoyer tout le dépôt.

Tu peux détailler STP ?

Dans le processus conseillé de git (je n'arrive plus à retrouver le lien), cela me semblait compliqué (une personne chargée de centraliser, valider les patchs, appliquer + un serveur d'export éventuellement avec un repack …).
J'ai donc cherché un processus plus simple. Je n'utilise pas git, je débute :-) J'ai trouvé qui guide pour une utilisation à la SVN, ça m'a plu.

Point déjà débattu précédemment. J'ai fait un choix. Supporter un autre matériel si besoin ne posera pas de problème grâce à l'industrialisation des déploiements et des configurations des logiciels.

C'est vrai que le Raspberry PI n'est pas parfait au niveau libre. Mais franchement, je préfère une communauté active et un fournisseur qui suit les montées en version d'OS plutôt que d'avoir les typons et un support de 2/3 ans.

Merci BAud pour ton commentaire. J'en profite…
Ce qui est prévu : les graphes seront publiquement disponibles. Pour les données, je ne sais pas ce qui est prévu. Cela paraîtrait logique l'open data à terme. Merci pour ta suggestion de license.
Pour les documents, pourquoi ne pas les placer également en EUPL ? Il y a une raison particulière ?
La documentation du système, de l'architecture, de l'intégration… je ne sais pas encore quoi faire. Pour le moment j'ai un peu "peur" de livrer tout le "savoir faire". Mais si le projet décolle bien, pourquoi pas…

Je suis d'accord avec la remarque du SPAM. Voir mon commentaire du 29/10/16 à 21:25 pour comprendre le pourquoi c'est resté "comme ça" dans la dépêche :-)

J'ai posté cette dépêche en copier/coller d'un article que j'ai rédigé à destination de la presse et du blog du fablab dans lequel je loue mes bureaux. Je l'ai collé ici pour ne pas faire un journal "bookmark" vers la page de mon entreprise. J'ai fait ce journal pour donner des nouvelles du projet car certains lecteurs me l'ont demandé sur la dépêche précédente concernant le choix de licences.
Alors, oui ça fait un peu "ovni" ici par rapport aux publications habituelles, mais je préfère faire un copier/coller et donner des nouvelles plutôt que ne pas prendre le temps de rédiger un article dédié à linuxfr.org. Et c'est en anticipant les remarques qui me sont faites que je n'ai pas fait une dépêche mais un journal… Mea culpa mais j'assume :-)
Je tâcherai de faire mieux pour annoncer la sortie du projet. En attendant, je donne des nouvelles comme je peux… A priori ça intéresse des lecteurs, même dans ce style rédactionnel, car le score de la dépêche est de 21 actuellement ?

Bonjour et merci pour le commentaire. Quand le projet sera prêt et/ou livré je livrerai tous les détails techniques. Pour le moment je fais un peu de rétention d'information afin d'avoir un temps d'avance technologique (pure stratégie pour l'intérêt de ma société). Le lien montre au moins des captures d'écran et donnes quelques petits détails. Je comprends cependant que l'on puisse rester sur sa faim :-)

Pour faire suite à https://linuxfr.org/users/ghusson/journaux/liberasys-visualisation-des-consommations-electriques-pour-lorient#comment-1679662 :
Je confirme qu'il y a de très grandes chances pour que le résultat soit placé en open source. Je vais conseiller l'EUPL car le projet a des chances de s'ouvrir au niveau européen pour les administrations et structures publiques.

J'ai rédigé cet article de manière journalistique. J'espère que cela vous donnera "quand même" envie d'aller voir le lien vers le site de mon entreprise pour en savoir plus ? :-) Promis, il y a plus de détails techniques en suivant le lien…

Pour info le MQTT prends beaucoup d'ampleur en ce moment. C'est ce que j'ai choisi personnellement (simple, puissant, sécurisable, librairies portées un peu partout). Sinon ça fait 6 mois que j'ai testé HA avec assez de satisfaction pour me dire que je vais partir là dessus… quand j'aurais du temps :-) Et ma prise sonoff il faut que je m'en occupe aussi… Un petit tuyau en passant : http://www.esp8266.nu/index.php/ESPEasy --> du bonheur mais pas assez documenté, voir le forum. Mais c'est plutôt bien fait, et en tout cas très fonctionnel ! Mes résultats de tests préliminaires ici : https://fil.crepp.org/groups/profile/197/esp-easy. Et pour ceux qui ne connaissent pas (encore), un bon fournisseur de DIY : http://www.banggood.com (utiliser la recherche sur google, leur moteur est très mauvais). Bonne domotique à vous :-)

Je n'ai absolument pas le niveau de connaissance juridique pour apprécier cela, mais j'ai trouvé : https://www.legifrance.gouv.fr/affichTexteArticle.do;jsessionid=496651A7C8DDD67CC38996A243559590.tpdila18v_1?cidTexte=JORFTEXT000032004939&idArticle=LEGIARTI000032006591&dateTexte=20160212

(version du code civil à venir au 1er octobre 2016)
"Ordonnance n° 2016-131 du 10 février 2016 portant réforme du droit des contrats, du régime général et de la preuve des obligations - Article 2 "
voir : Sous-section 4 : Dispositions propres au contrat conclu par voie électronique

Franchement je ne comprends pas le texte…
Entre l'envoi des contrats, des éléments intermédiaires et l'exécution du contrat, on ne parle pas de signature.
Il y a deux cas identifiés (cas des articles 1125 et 1126, et les autres cas) et je ne sais pas dans lequel placer la "signature" (ie accord contractuel prouvé)… de plus, des conditions sont fixées par décret en Conseil d'Etat : quelqu'un a connaissance de ces décrets ?

Merci pour la leçon mais ce n'est pas la peine d'être condescendant pour autant…
SHA1 j'étais au courant. MD5 j'en avais entendu parler mais je ne m’étais pas intéressé de près au sujet.
Sois heureux si tu as le temps de tout apprendre et de faire ta veille sur tous les sujets. Ce n'est plus mon cas malheureusement.
Pour information MD5 est encore utilisé par défaut dans postfixadmin par exemple. Cela n'a pas de gravité tant que la BDD ne sort pas du serveur. Un changement implique que tous les utilisateurs redonnent leur mot de passe… imagine pour un système avec plusieurs milliers d'utilisateurs. Mais c'est à faire.
Idem pour les connexions POP/IMAP avec le CRAM/MD5 et DIGEST/MD5… alors ok on passe sur du SCRAM (https://tools.ietf.org/html/rfc6331). Dovecot : SCRAM-SHA-1 \o/ ! Dans mon cas je passe par du TLS donc c'est moins grave mais bon…
Bref, merci d'avoir confirmé :-)

Cela confirme ce que je pensait. Tu peux confirmer que c'est également embêtant pour l'enregistrement des hachages des mots de passe (génération de collision) ? Auquel cas c'est également embêtant pour les systèmes actuels (services, apps - ex : enregistrement du MD5 du mot de passe en base de données pour faire l'authentification, si la base se fait récupérer par un attaquant, il peut générer des collisions).
Je viens de regarder, le fichier shadow utilise par défaut du SHA-512 sous debien 8, cela me rassure.
Sur le sujet, pour la pratique orientée WEB, voir : https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016

Merci pour ton commentaire au second degré :-)

La question de la vérification à posteriori est vraiment compliquée… c'est vrai que seul un équivalent du SYN SYN/ACK ACK permet de le faire de manière fiable et autonome… l'autre solution est la plate-forme tierce, certifiée, avec du contenu en read only, qui fait la vérification à l'entrée (demandé dans certains codes pour les procédures dématérialisées d'après les commentaires).

Oui mais quand même, une autorité de vérification d'identité, via chaîne de certification, a quand même une certaine valeur pour prouver ton identité. Je sais que ce type de procédure est utilisée pour la remise des réponses à appel d'offre dématérialisées (ex : plate-forme megalis https://marches.megalisbretagne.org).
Mais bon, on revient au même problème, chaque code définit ses critères en matière de signature numérique…

RQ : tu as tout à fait raison sur journaux != forum, j'aurais dû poster ça dans le forum. Désolé.