Le problème de Timeshift est qu'il n'est pas synchronisé avec le gestionnaire de paquets.
Du coup, si tu pars sur un instantané, tu perds par exemple 1 journée de diff alors que c'est seulement 5 minutes que tu souhaiterais rollback.
Ça peut être vraiment contre-intuitif et rageant car tu ne sais pas exactement ce qu'il manque et certaines opérations que tu pensais finis sont à refaire.
Il manque sans doute une GUI a Nix pour proposer la gestion des snapshots :
Si c'était le cas, réviserais-tu ton discours ?
Je n'utilise pas Timeshift mais si tu casses au hasard X11 ou Wayland, c'est toujours facile ? (pour le coup, avec les snapshots au bootloader, ça me parait une avancé notable, non ?)
Là ou je trouve que son journal est également intéressant c'est qu'on c'est tous fait avoir par la permissivité de certains fichiers de conf : on se trompe dans l'édition et on se rend compte à l’exécution qu'on a tout cassé.
Avec Nix, on limite la casse en opérant des contrôles en amont.
Point curiosité : j'aimerais bien savoir ce qu'un comparatif d'espace disque consommé sur les 2 technos avec une échelle de temps et gamme de logiciels proche d'un usage courant donnerait.
Ah oui mais là tu dégages git aussi…
A titre perso, ça me dérangerais pas mais je vois difficilement des gros projets migrer.
Git, c'est devenu "la norme".
C'est un point que je reproche au fonctionnement à la github et cie : centraliser ce qui devrait être par nature décentralisé.(c'est quand même la nature de git)
j'ai peine à comprendre qu'il n'existe pas d'outil permettant de balader un gestionnaire d'anomalies d'un dépôt à un autre (par exemple un sous-module).
Je pense vraiment qu'il y a besoin que quelques projets se prennent se genre de fermetures abusives pour que ça réveille les esprits.
Pour ce qui est des tests unitaires, rien n'interdit de créer des dépôts miroirs avec des données compressés et les décompresser dans l'outil de ci. Ca sera sans doute plus dur à détecter du coup et accentuerais l'effet flamby.
Effectivement, plusieurs langages ont échoués dans cette tâche.
Là ou Rust se distingue d'autres langages c'est qu'il n'utilise que des algos éprouvés (d’où la rouille) alors que des langages plus académiques (OCAML, Haskell etc.) ont plus servi de POC.
La guideline de départ du langage était claire : remplacer C++ dans Firefox pour améliorer les soucis de mémoire et de concurrence.
Tous les développeurs C et C++ rêvent de passer à Rust : clairement, non. Ceux qui ont de la bouteille dans un langage, on foncièrement plus de difficultés à en changer. Ils ont appris à éviter les pièges et par conséquent l'intérêt est moindre.
En revanche, un jeune dev aura plus facile à s'orienter vers Rust à mon sens et des projets avec un mix senior/junior demande moins d'efforts de review des seniors car le compilateur fait plus de vérifs.
L'écosystème compte également : je trouve que pour un langage, au départ soutenu par aucune GAFAM, Rust a fait son bonhomme de chemin a ce niveau.
Pour ce qui de Javascript c'est plus lié au fait qu'il y a beaucoup de dev web et que ce langage est incontournable. (mais, c'est volatile : le vent va peut-être changer avec webassembly et/ou Typescript)
Pour ce qui est des évols de C++ : si je ne me trompe pas, rien n'est déprécié donc un projet peut très bien mélanger du C++ old school avec des concepts plus récents ?
Vu de l’extérieur (j'ai pas fait suffisamment de C++ pour avoir un avis objectif) : Le poid de l'existant est très lourd en C++ et l'on peut faire la même chose de mille et une façon.
La rétrocompatibilité à tout prix c'est un vrai soucis à plusieurs niveaux.
Dommage de ne pas avoir communiqué pourquoi au moment même : on bosse dur justement pour avoir le max de softs à jour (d'ailleurs une grande partie de ceux cités sont présents) et une expérience utilisateur la plus proche des besoins d'une classe de primaire.
Une synergie serait bien venu : je vois plein de créations de contenus pédagogiques qui auraient leur place au sein de Primtux.
Posté par mothsART .
En réponse au message Installation de Gspeech.
Évalué à 1.
Dernière modification le 28 juin 2020 à 19:35.
Je ne sais pas sur quel gestionnaire de fenêtre tu utilises sur devuan mais je pense qu'il n'y a pas de sys tray ou qu'il n'est pas détecté et que gSpeech est par conséquent présenté en mode "fenêtre".
Je vais tenter de reproduire via une VM et te tiens au courant.
Pour la latence, en effet : gSpeech va tout convertir puis lire. J'ai déjà réfléchit à améliorer ça mais ça demande un peu plus de taf.
PS : je ne connaissais pas gespeaker : c'est tjs bien de connaitre des équivalents pour comparer.
ça devrait résoudre ton soucis.
Je vais résoudre ce soucis de dépendance.
Ce qui m'a aussi étonné (mais c'est peut-être voulu car lié à tes locales) c'est que tes notifications (I'm reading the text, one moment please) sont en anglais..
J'en déduis que tu l'as installé via le ppa ?
Peux-être un soucis de dépendance oublié dans mon .deb.
Si tu lances gspeech via un terminal et que tu fais la même manip, as-tu un message d'erreur ?
Tu peux aussi le lancer en ligne de commande (il te faut alsa-utils pour lancer aplay) :
gspeech-cli -i "mon texte" -o son.wav && aplay son.wav
C'est bien connu, les devs qui utilisent des fichiers de configurations qui ne sont pas étanches, on peut dire qu'ils sont porteurs de sandhall.
Et quand ils jouent à des sports sans filets avec des fichiers de config indisponibles, on peut dire sans hésitation qu'ils sont en mode n/a dhall.
Ne me cherchez plus, ça fait longtemps que j'ai disparu (---> []), il ne reste que dhall.
Admiratif également et utilisateur régulier de Gimp : je ne pourrais plus m'en passer.
Je fais principalement du pixel art avec ces derniers temps.
Quand j'ai débuté, on m'avait conseillé Aseprite mais finalement, je n'y ai jamais trouvé mon compte : je suis plus productif (par habitude ou pour d'autres raisons, difficile de trancher) sur Gimp.
Peux-être le seul bémol serait d'avoir une config de Gimp uniquement pour ce type d'usage : y'a plein d'outils qui ne servent pas ou peu dans ce cadre.
tu as raison. Le bac à sable de nix n'est là que pour du build.
En revanche, il existe des sandbox indépendante tel que "firejail" : je ne connais que de nom et ne sais pas quel granularité ça a mais je pense que je vais tester avec nix.
Néanmoins, je trouve pas mal d'avoir 2 softs bien distincts : 1 pour le sandboxing et 1 pour le gestionnaire de paquet, non ?
Tu m'as convaincu sur le fait que Play.it a besoin d'un bac à sable.
Comme dis, Nix en a un mais j'ai plus l'impression que son but est d'isoler pour garantir les dépendances plutôt que vraiment protéger le système hôte.
En réalité, c'est ce pourquoi je l'ai utilisé mais je n'en sais pas vraiment plus.
Tout ce que je peux dire c'est qu'il n'est pas mis en avant, à la différence de Flatpak.
A juste titre ou non : difficile de trancher.
Oui, on ne parle de la même chose.
Quand je parlais de prod c'était très large.
ça peut être fournir un exe, un intranet : dans une de mes anciennes boite, on mettais à jour des apps web dans un intranet qui était dispo h24 mais le soir et week-end, c'étais leur service info interne qui assurait les astreintes.
Après, le cadre légal, c'est pas vraiment mon job…
Je pense aussi que tu me réponds comme si j'étais l'auteur du tout premier commentaire qui parle de l'allégorie de la prod qui tombe à 18h.
Effectivement, j'ai pas approfondis la question sous Nix donc je mets un point à Flatpak par ignorance.
Si je suis ta logique : c'est en gros meilleur en terme de sécu que de l'empaquetage natif : deb, rpm etc ?
Donc si on compare uniquement Nix à Flatpak en terme de remplaçant pour les 2 critères : installation en espace utilisateur et version plus à jour… c'est un peu malhonnête de l'inclure dans les apports.
Dans ce cas, ce critères rentre en jeu si on fait un comparatif gestionnaire de paquet : genre Flatpak vs Apt mais pas dans le cadre d'un complément au gestionnaire natif.
Dans ce cas, on mettre d'autres points sur le tapis : tu peux upgrade ton kernel avec Flatpak ?
Donc si j'extrapole, c'est bien pour empaqueter des binaires propriétaires par exemple.
L'intérêt est moindre si on installe à partir de flathub car les paquets présents sont validés par la communauté.
mais aussi à limiter l'impact d'une faille de sécurité ou d'un bogue dans ce logiciel.
Tu n'a peut être pas dis que c'était bien, mais tu considère que quelqu'un qui dis que si un environnement a des SLA il faut travailler en équipe et gérer des astreintes est dans sa tour d'ivoire.
Oula, tu fais des déductions rapides quand même là…
J'arrive même pas à comprendre ou tu veux en venir : en quoi tu considères que mon exemple est du travail illégal ?
Depuis quand l'âge d'une solution est un critère ?
En soit, ça peut paraître futile mais bon, y'a tellement de trucs effet de mode qui ne tienne pas sur la longueur.
Sur un soft aussi sérieux que de l'empaquetage, ça me parait pas déconnant que ça tienne sur la durée et que ça soit un minimum éprouvé : si au final, tu te rends compte que tu peux facilement empaqueter pour tel technos et pas tel autre, c'est quand même l'ascenseur émotionnel.
Ça a du sens aussi parce que depuis quelques années on parle de Flatpak comme la solution qui n'existait pas.
Or non : c'est le nième truc qui est arrivé et qui fragmente.
Pourquoi proposer encore un truc plutôt que d'améliorer/promouvoir de l'existant.
Nix en 15 ans de travail acharné empaquette quand même une quantité astronomique de softs dans des technos très hétérogène.
Le temps joue en sa faveur parce que Rome ne c'est pas construit en 1 jour.
Flatpak est dispo presque partout dans les dépôts des distributions, Nix pas vraiment
C'est un point que j'avais pas pris en compte, effectivement.
J'en prend note.
Flatpak utilise un bac à sable avec un système de permissions très puissant.
Le bac à sable (Nix peut faire aussi) est pour ma part pas forcément une qualité.
système de permissions
Jamais creusé dans ce sens donc j'ai pas d'élément de comparaison.
Ca me fait une belle jambe comme ça : à titre perso, je vois pas ce que ça m'apporte mais je veux bien des cas d'usage.
Je trouve juste dommage que dès qu'on parle d'avoir de l'install user ou un paquet plus à jour que sa distrib, la solution envisagé soit toujours Flatpak alors qu'il ne me semble pas légitime :
- ni historiquement (nix a plus de 15 ans)
- ni techniquement
Y'a qu'en matière de com, de site web (qui est bien plus sexy) qu'il y a un avantage côté Flatpak mais c'est de la poudre aux yeux à mon sens.
Pour les avantages côté dev, j'ai testé les 2 et y'a pas photo. Nix me convainc autant par sa qualité, sa doc, sa cohérence, sa communauté que Flatpak me déçois.
C'est pas parfait mais je trouve que le rapport qualité/communication est disproportionné et j'essai à mon faible niveau d'équilibrer la balance.
Je ne parlerais pas de Snap, Appimage que je connais moins mais qui semble avoir les mêmes défauts que Flatpak.
Si tu as suffisamment de test, tu n'as pas peur de la prod.
Entièrement dac. (c'est les tests, pas la capacité de rollback)
Tu peux très bien designer ta migration pour être transparente…
Je connais et applique tout ça.
Ca complexifie et l'expérience m'a montré que ça n'évite complètement les ratés.
Rien n'est parfait.
Sur des langage comme Rust, tu peux rendre l'ensemble de la base typé et amorcer des migrations ou tu peux garantir que les requètes avant et après migrations soient safe.
On en revient au point initial : un vrai truc typé de bout en bout t'évites d'envoyer de la merde en prod.
Normalement, tu as pu tester ton webservice
Normalement, un WS est versionné et tu peux passer de l'un à l'autre.
Le soucis c'est bien le "normalement" et le "bien fait". Si t'es consommateur, tu subis.
Tu peux très bien construire ton application pour pouvoir utiliser l'ancien cache et le mettre à jour petit à petit.
Dans l'absolu : oui. Mais la réalité fait que tu travailles sur du legacy ou tout n'est pas forcément possible aussi facilement.
Tu sais qu'il y a des systèmes qui font des rollback automatiquement ?
Alors, oui. Bon, j'appel pas ça du rollback : t'as plusieurs versions de ton app/fonctionnalité et t'as des triggers en fonction de.
Ça peut être un vrai serpent de mer à plusieurs têtes si tu mets ça partout.
Comme souvent : faut savoir utiliser la bonne stack en fonction des besoins, ressources etc.
Ça peut être dur de trouver le bon curseur de déclenchement. faut que les métriques ne tombent pas, qu'elles soient temps réels etc.
Bref : du cas par cas.
Je n'ai jamais parlé d'une prod qui casse un vendredi.
Non, une prod, n'implique pas nécessairement un travail en équipe, ni d'astreintes.
Comment tu peux sortir une généralité comme celle-ci ? Tout dépend du contexte.
Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça…
tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)
Je le redis : pour moi, un bon typage c'est une forme de test : si tu touches à un truc qui ne compile plus, ben tu dois le traiter avant de pousser en prod.
Sur des langages ou tout se fait au runtime, on fait de plus en plus d'analyse static en amont.
L'objectif est le même : prévenir plutôt que guérir.
Je n'arrive toujours pas à comprendre ce que tu essayes de démontrer avec le rollback.
Le rollback c'est le joker au cas ou.
Les devs n'auront pas peur de la prod pas parce qu'ils peuvent revenir en arrière 50 fois dans la journée mais parce que leurs déploiements, aussi fréquents soient-ils se passeront dans l'ensemble bien et que les soucis en prod ne seront pas inlassablement de même nature.
Pour moi, c'est un leurre de croire que tout est rollbackable (et par conséquent, c'est dangereux de trop s'appuyer dessus).
T'as plein de cas ou tu ne peux pas te permettre ce luxe.
qlqs exemples loin d'être exhaustif :
- chg en base de donnée conséquente : même si entre la liv et le rollback, il c'est passé 5min, tu as potentiellement des données à migrer et du coût le rollback ne peut pas être simple.
- tu ne maîtrises pas toute la chaîne de production : ton code dépend d'un web service externe qui a upgrade par ex.
- tu as des niveaux de cache : t'es obligé d'invalidé tes caches à chaque livraison/rollback : tu peux faire explosé ta prod en jouant à ça.
Le rollback, pour moi, c'est du travail dans l'urgence.
Tu atténues l'urgence mais y'a quand même quelqu'un qui a appuyé urgemment sur l'interrupteur.
Je n'ai jamais vu ce type de bug arriver dans une prod.
Tu m'aurais dit "rarement", je me serais dit "étonnent" mais soit.
Avec un jamais, je suis partagé entre "mauvaise foi", "déni", "ignorance".
Je te donne un cas sur lequel j'ai été confronté mille fois (et qui est proprement traité en Rust) : https://fr.wikipedia.org/wiki/Charles_Antony_Richard_Hoare#R.C3.A9flexions_sur_la_programmation
Qu'un objet (structure de données) puisse être vide par défaut et que l'on ne vérifie sa nullité qu'au runtime a énormément d'incidence.
Maintenant, tu extrapoles sur des structures complexes avec énormément d'imbrications (et qui ont tendance à changer régulièrement) et pour résoudre tous les cas potentiels de bugs, tu te rends vite compte que tu es proche de l’explosion combinatoire.
Quand il dit "bug à 1 milliard", je crois qu'il est en dessous de la réalité.
Ce qui est certain, c'est qu'à l'heure des libs/frameworks, ces soucis de typage ne nous saute pas forcément aux yeux juste en lisant la tracktrace.
C'est bien plus sournois mais ça n'empêche que le fond du problème vient de là.
Je vois aussi que beaucoup de frameworks pour des langages faiblement typés ont tendance à atténuer ces soucis parce qu'ils font le travail à notre place.
C'est un moyen détourné qui entraîne d'autres dérives (à mon sens).
Par exemple, sur la stack javascript, utiliser des frameworks obligent npm et donc une foison de dépendances (et dépendances tiers).
Cette dérive est en partie dût à la qualité déplorable du typage du langage et la monté de TypeScript et cie n'y es pas étranger.
En client/serveur toujours, on parle de plus en plus d'isomorphisme.
Ça soulève bien un soucis de typage pour moi : la capacité de partager une structure de donnée sans faux raccord.
En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.
tout le monde ne travaille pas en équipe ou si c'est le cas en inter-dépendance.
une mise en prod n’inclus pas foncièrement un déploiement complexe : à la base, on parle d'un soft en cli donc le déploiement c'est création d'un exécutable.
tous les projets ne sont pas forcément orienté "software as a service".
dans une grande structure, tu as souvent une panoplies de rôles : dba, admin sys, devops, archi etc.
certaines responsabilités porté par des devs dans certaines boites ne le sont pas dans d'autres
les devs ne choisissent que rarement la stack (ou l'intégralité), langage y compris.
un worflow tel que tu le décris (canary release, AB test) a un coût matériel et humain loin d'être négligeable.
c'est quoi un bon dev ? C'est tellement subjectif.
Un workflow bien millimétré, ça nécessite d'embaucher des gens qualifiés (ou les former) donc on peut les classer dans la case des "bons devs".
Je pense plutôt qu'il y a une constante : n'importe quel boite souhaite la meilleur qualité et donc des salariés le plus compétents possibles, agiles, volontaires etc.
et que ce facteur humain va dépendre de leur porte feuille, du processus d'embauche, d'un brin de chance etc.
Tout dépend de ce que tu produits.
Si le dev en question nécessite d'avoir des connaissances métiers très pointus (par exemple médical), le bon dev sera un mélange entre qualité technique et connaissances en rapport.
Si le dev doit interagir avec de la donnée : il faut qu'il soit pointu en SQL, elasticSearch etc sinon la qualité ne pourra pas être au rendez-vous.
Si ça nécessite des connaissances mathématiques, il aura beau savoir suivre un worflow de dingue, ça ne suffira pas.
J'ai et j'ai eu l'occasion de travailler sur des projets seul, avec des petites et des grandes équipes : worflow de malade, dev à l'arrache, langage compilé, interprété, fortement typé ou non.
Mon constat c'est que beaucoup de choses "critiques" (les fameuses 500 qui font tant plaisir) peuvent être évités en amont avec du typage, du pattern matching et de l'immutabilité.
Ca veut pas dire qu'on peut pas faire des erreurs de typage avec un langage fortement typé, (genre mettre un string là ou on attend un entier et caster comme un porc un peu partout)
mais on limite vachement les risques, c'est mathématique.
Mieux que ça : dev avec des grosses contraintes m'a mis le nez sur des soucis que je n'aurais jamais anticipé avant.
J'en conçoit, ça n'évite pas les bugs logiques, fonctionnels, métier mais c'est quand même plus valorisant de se concentrer que la dessus, non ?
Il n'est pas impossible d'avoir des erreurs au runtime en Rust (d'ailleurs, aucun langage ne les évites intégralement) mais faut déjà sacrément pousser pour y arriver alors qu'avec d'autres langages, c'est d'une facilité déconcertante.
La simplicité du rollback, c'est bien mais faut pas que ça devienne une solution de facilité.
Bien entendu qu'il est impossible de livrer en prod sans un dérapage mais ce qui me semble plus important que le rollback en lui-même c'est les mesures prisent après rollback :
pourquoi c'est arrivé et comment on évite à l'avenir.
Avec ça, on réduit leur fréquence graduellement et on peut se permettre d'éviter des dettes techniques : maj des libs régulières, refacto etc.
En plus, il y a tellement de cas ou un rollback n'est pas possible (ou que celui-ci a un coût) que de s'appuyer dessus c'est le désastre assuré.
Faut avoir un outil de rollback simple mais coder comme si il était impossible.
[quote]
C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité.
[/quote]
Bon, y'a une variété de tests qui existent, je ne t'apprend rien.
Un test pour moi, c'est une forme de doc : ça dit à un instant T ce que ton soft fait ou ne fait pas.
Tout ce qui n'est pas testé n'est pas contractuel.
Je ne vois pas en quoi faire un écrire un test par quelqu'un d'autre que le dev de la fonctionnalité change quoi que ce soit.
La review de code (si c'est possible avec une hiérarchie de reviewer), le pair programming et inclure le code des tests dans cette relecture me semble bien plus vital.
Un reviewer "senior" qui te drive en te disant qu'il manque tel test ou que ce dernier ne sert à rien, n'aura sans doute pas écrit le code mais ce sera tout comme.
Autre constat, plus tu as de doc et moins tu as de chance que ça soit lu, compris, assimilé par tous.
Comme dis, avoir la même rigueur avec un langage interprété nécessite de faire des tests de typage.
Ca prend du temps, ça n'apporte pas grand chose et ça parasite la doc.
Enfin, quand on a un soucis en prod, tu le sais aussi bien que moi, l'enjeu c'est souvent de reproduire.
Limite, c'est un autre métier.
Reproduire, c'est souvent 90% du taf et quand je fais le constat amer d'avoir passé des heures a arriver à reproduire un bug qui est lié à du typage, ça me fait rager parce que je sais qu'il pouvait être évité en amont.
Je suis bien conscient que dans 10 ans je tomberais encore sur les bugs les plus habituels : date, encodage, dépendances etc. mais je ferais tout pour que ça ne soit pas mon cœur de métier.
En toute franchise, je me considère pas comme le meilleur dev, loin de là : j'écris pas en dvorak avec du 150 MPM, je passe souvent par l'étape papier avant de sortir du syndrome de la page blanche.
Néanmoins, je pense que l'apprentissage de Rust m'a permis de m'améliorer sur plein de sujets et je recommande vivement de sortir de sa zone de confort avec ce genre de langage.
Ca m'a permis de voir certaines choses soit disant acquises avec un autre regard : par exemple la POO.
[^] # Re: à chacun sa vision de la simplicité
Posté par mothsART . En réponse au journal Les rollbacks avec NixOS, ou comment casser son système. Évalué à 3.
Le problème de Timeshift est qu'il n'est pas synchronisé avec le gestionnaire de paquets.
Du coup, si tu pars sur un instantané, tu perds par exemple 1 journée de diff alors que c'est seulement 5 minutes que tu souhaiterais rollback.
Ça peut être vraiment contre-intuitif et rageant car tu ne sais pas exactement ce qu'il manque et certaines opérations que tu pensais finis sont à refaire.
Il manque sans doute une GUI a Nix pour proposer la gestion des snapshots :
Si c'était le cas, réviserais-tu ton discours ?
Je n'utilise pas Timeshift mais si tu casses au hasard X11 ou Wayland, c'est toujours facile ? (pour le coup, avec les snapshots au bootloader, ça me parait une avancé notable, non ?)
Là ou je trouve que son journal est également intéressant c'est qu'on c'est tous fait avoir par la permissivité de certains fichiers de conf : on se trompe dans l'édition et on se rend compte à l’exécution qu'on a tout cassé.
Avec Nix, on limite la casse en opérant des contrôles en amont.
Point curiosité : j'aimerais bien savoir ce qu'un comparatif d'espace disque consommé sur les 2 technos avec une échelle de temps et gamme de logiciels proche d'un usage courant donnerait.
[^] # Re: Ce qui devait arriver…
Posté par mothsART . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 1.
Ah oui mais là tu dégages git aussi…
A titre perso, ça me dérangerais pas mais je vois difficilement des gros projets migrer.
Git, c'est devenu "la norme".
[^] # Re: Ce qui devait arriver…
Posté par mothsART . En réponse au lien Les dépôts de code, même les plus populaires, sont faciles à faire censurer sur Microsoft-Github. Évalué à 3.
C'est un point que je reproche au fonctionnement à la github et cie : centraliser ce qui devrait être par nature décentralisé.(c'est quand même la nature de git)
j'ai peine à comprendre qu'il n'existe pas d'outil permettant de balader un gestionnaire d'anomalies d'un dépôt à un autre (par exemple un sous-module).
Je pense vraiment qu'il y a besoin que quelques projets se prennent se genre de fermetures abusives pour que ça réveille les esprits.
Pour ce qui est des tests unitaires, rien n'interdit de créer des dépôts miroirs avec des données compressés et les décompresser dans l'outil de ci. Ca sera sans doute plus dur à détecter du coup et accentuerais l'effet flamby.
[^] # Re: Pffff
Posté par mothsART . En réponse à la dépêche Rust a 5 ans, rétrospective. Évalué à 7.
Effectivement, plusieurs langages ont échoués dans cette tâche.
Là ou Rust se distingue d'autres langages c'est qu'il n'utilise que des algos éprouvés (d’où la rouille) alors que des langages plus académiques (OCAML, Haskell etc.) ont plus servi de POC.
La guideline de départ du langage était claire : remplacer C++ dans Firefox pour améliorer les soucis de mémoire et de concurrence.
Tous les développeurs C et C++ rêvent de passer à Rust : clairement, non. Ceux qui ont de la bouteille dans un langage, on foncièrement plus de difficultés à en changer. Ils ont appris à éviter les pièges et par conséquent l'intérêt est moindre.
En revanche, un jeune dev aura plus facile à s'orienter vers Rust à mon sens et des projets avec un mix senior/junior demande moins d'efforts de review des seniors car le compilateur fait plus de vérifs.
L'écosystème compte également : je trouve que pour un langage, au départ soutenu par aucune GAFAM, Rust a fait son bonhomme de chemin a ce niveau.
Pour ce qui de Javascript c'est plus lié au fait qu'il y a beaucoup de dev web et que ce langage est incontournable. (mais, c'est volatile : le vent va peut-être changer avec webassembly et/ou Typescript)
Pour ce qui est des évols de C++ : si je ne me trompe pas, rien n'est déprécié donc un projet peut très bien mélanger du C++ old school avec des concepts plus récents ?
Vu de l’extérieur (j'ai pas fait suffisamment de C++ pour avoir un avis objectif) : Le poid de l'existant est très lourd en C++ et l'on peut faire la même chose de mille et une façon.
La rétrocompatibilité à tout prix c'est un vrai soucis à plusieurs niveaux.
[^] # Re: Avez-vous essayé PrimTux?
Posté par mothsART . En réponse à la dépêche Interview de Laurent, instituteur et libriste. Évalué à 7. Dernière modification le 05 août 2020 à 19:44.
Dommage de ne pas avoir communiqué pourquoi au moment même : on bosse dur justement pour avoir le max de softs à jour (d'ailleurs une grande partie de ceux cités sont présents) et une expérience utilisateur la plus proche des besoins d'une classe de primaire.
Une synergie serait bien venu : je vois plein de créations de contenus pédagogiques qui auraient leur place au sein de Primtux.
Seul on va plus vite, ensemble on va plus loin !
[^] # Re: j'ai peut être loupé un truc
Posté par mothsART . En réponse au message Installation de Gspeech. Évalué à 1. Dernière modification le 28 juin 2020 à 19:35.
Je ne sais pas sur quel gestionnaire de fenêtre tu utilises sur devuan mais je pense qu'il n'y a pas de sys tray ou qu'il n'est pas détecté et que gSpeech est par conséquent présenté en mode "fenêtre".
Je vais tenter de reproduire via une VM et te tiens au courant.
Pour la latence, en effet : gSpeech va tout convertir puis lire. J'ai déjà réfléchit à améliorer ça mais ça demande un peu plus de taf.
PS : je ne connaissais pas gespeaker : c'est tjs bien de connaitre des équivalents pour comparer.
[^] # Re: suite
Posté par mothsART . En réponse au message Installation de Gspeech. Évalué à 2.
Tu n'as pas à être désolé : les instructions d'installation sont dédié aux utilisateurs avancés qui vont installer à partir des sources.
Là, j'ai oublié (encore une fois) de gérer cette dépendance dans mon paquet debian :
Je met à jour le paquet et le ppa pour qu'ils en prennent compte.
Pour les notifications, en effet : c'est cohérent.
N'hésites pas si tu as d'autres remarques à l'usage.
[^] # Re: suite
Posté par mothsART . En réponse au message Installation de Gspeech. Évalué à 2. Dernière modification le 28 juin 2020 à 13:41.
Ce message ne me semble vraiment pas inhérent à ton soucis.
Le gtk-critical s'affiche au lancement de gSpeech ou bien à la lecture de ton texte ?
Peux-tu tester ? :
Si oui, tu peux installer manuellement :
ça devrait résoudre ton soucis.
Je vais résoudre ce soucis de dépendance.
Ce qui m'a aussi étonné (mais c'est peut-être voulu car lié à tes locales) c'est que tes notifications (I'm reading the text, one moment please) sont en anglais..
[^] # Re: Licence?
Posté par mothsART . En réponse au journal gSpeech passe en 0.10. Évalué à 1.
Vu que c'est en python, pas de soucis d'amalgame dans la compilation.
Alors, c'est pas libre mais ça reste open source : https://android.googlesource.com/platform/external/svox/
et des forks du genre : https://github.com/naggety/picotts
[^] # Re: Licence?
Posté par mothsART . En réponse au journal gSpeech passe en 0.10. Évalué à 1.
Effectivement, je pense que tu es dans le vrai.
Sur Ubuntu, c'est classé dans multiverse et sur Nix, je tombe sur la même licence https://nixos.org/nixos/packages.html?channel=nixos-20.03&query=pico
Vu que j'ai repris le projet (gSpeech) et qu'il était sous GPL 3, je ne me suis pas posé de questions outre mesure pensant que c'était déjà tranché.
Je ne sais pas trop si j'ai par conséquent un soucis de licence vu que gSpeech se retrouve a être une GUI au dessus d'un moteur TTS propriétaire.
# soucis d'installation ou d'utilisation
Posté par mothsART . En réponse au journal gSpeech passe en 0.10. Évalué à 2.
Si vous rencontrez le moindre soucis d'installation ou d'utilisation de Gspeech, j'ai créé une entrée sur le forum dédié : https://linuxfr.org/forums/linux-debian-ubuntu/posts/installation-de-gspeech
Merci d'avance
[^] # Re: Ne lis pas
Posté par mothsART . En réponse au journal gSpeech passe en 0.10. Évalué à 1.
J'en déduis que tu l'as installé via le ppa ?
Peux-être un soucis de dépendance oublié dans mon .deb.
Si tu lances gspeech via un terminal et que tu fais la même manip, as-tu un message d'erreur ?
Tu peux aussi le lancer en ligne de commande (il te faut alsa-utils pour lancer aplay) :
gspeech-cli -i "mon texte" -o son.wav && aplay son.wav
[^] # Re: Où est l'intérêt ?
Posté par mothsART . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 2.
C'est bien connu, les devs qui utilisent des fichiers de configurations qui ne sont pas étanches, on peut dire qu'ils sont porteurs de sandhall.
Et quand ils jouent à des sports sans filets avec des fichiers de config indisponibles, on peut dire sans hésitation qu'ils sont en mode n/a dhall.
Ne me cherchez plus, ça fait longtemps que j'ai disparu (---> []), il ne reste que dhall.
[^] # Re: Bravo
Posté par mothsART . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 4.
Admiratif également et utilisateur régulier de Gimp : je ne pourrais plus m'en passer.
Je fais principalement du pixel art avec ces derniers temps.
Quand j'ai débuté, on m'avait conseillé Aseprite mais finalement, je n'y ai jamais trouvé mon compte : je suis plus productif (par habitude ou pour d'autres raisons, difficile de trancher) sur Gimp.
Peux-être le seul bémol serait d'avoir une config de Gimp uniquement pour ce type d'usage : y'a plein d'outils qui ne servent pas ou peu dans ce cadre.
[^] # Re: Flatpak?
Posté par mothsART . En réponse au journal Sortie de ./play.it 2.11.4. Évalué à 2.
tu as raison. Le bac à sable de nix n'est là que pour du build.
En revanche, il existe des sandbox indépendante tel que "firejail" : je ne connais que de nom et ne sais pas quel granularité ça a mais je pense que je vais tester avec nix.
Néanmoins, je trouve pas mal d'avoir 2 softs bien distincts : 1 pour le sandboxing et 1 pour le gestionnaire de paquet, non ?
# node et deno sont dans un bateau
Posté par mothsART . En réponse à la dépêche Sortie de Deno 1.0. Évalué à 6.
Tout le monde aura remarqué que deno est le verlan de node.
[^] # Re: Flatpak?
Posté par mothsART . En réponse au journal Sortie de ./play.it 2.11.4. Évalué à 2.
Tu m'as convaincu sur le fait que Play.it a besoin d'un bac à sable.
Comme dis, Nix en a un mais j'ai plus l'impression que son but est d'isoler pour garantir les dépendances plutôt que vraiment protéger le système hôte.
En réalité, c'est ce pourquoi je l'ai utilisé mais je n'en sais pas vraiment plus.
Tout ce que je peux dire c'est qu'il n'est pas mis en avant, à la différence de Flatpak.
A juste titre ou non : difficile de trancher.
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 1. Dernière modification le 15 mai 2020 à 20:49.
Oui, on ne parle de la même chose.
Quand je parlais de prod c'était très large.
ça peut être fournir un exe, un intranet : dans une de mes anciennes boite, on mettais à jour des apps web dans un intranet qui était dispo h24 mais le soir et week-end, c'étais leur service info interne qui assurait les astreintes.
Après, le cadre légal, c'est pas vraiment mon job…
Je pense aussi que tu me réponds comme si j'étais l'auteur du tout premier commentaire qui parle de l'allégorie de la prod qui tombe à 18h.
[^] # Re: Flatpak?
Posté par mothsART . En réponse au journal Sortie de ./play.it 2.11.4. Évalué à 2.
Effectivement, j'ai pas approfondis la question sous Nix donc je mets un point à Flatpak par ignorance.
Si je suis ta logique : c'est en gros meilleur en terme de sécu que de l'empaquetage natif : deb, rpm etc ?
Donc si on compare uniquement Nix à Flatpak en terme de remplaçant pour les 2 critères : installation en espace utilisateur et version plus à jour… c'est un peu malhonnête de l'inclure dans les apports.
Dans ce cas, ce critères rentre en jeu si on fait un comparatif gestionnaire de paquet : genre Flatpak vs Apt mais pas dans le cadre d'un complément au gestionnaire natif.
Dans ce cas, on mettre d'autres points sur le tapis : tu peux upgrade ton kernel avec Flatpak ?
Donc si j'extrapole, c'est bien pour empaqueter des binaires propriétaires par exemple.
L'intérêt est moindre si on installe à partir de flathub car les paquets présents sont validés par la communauté.
Je reste plus sceptique sur ce point.
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 1.
Oula, tu fais des déductions rapides quand même là…
J'arrive même pas à comprendre ou tu veux en venir : en quoi tu considères que mon exemple est du travail illégal ?
[^] # Re: Flatpak?
Posté par mothsART . En réponse au journal Sortie de ./play.it 2.11.4. Évalué à 2.
En soit, ça peut paraître futile mais bon, y'a tellement de trucs effet de mode qui ne tienne pas sur la longueur.
Sur un soft aussi sérieux que de l'empaquetage, ça me parait pas déconnant que ça tienne sur la durée et que ça soit un minimum éprouvé : si au final, tu te rends compte que tu peux facilement empaqueter pour tel technos et pas tel autre, c'est quand même l'ascenseur émotionnel.
Ça a du sens aussi parce que depuis quelques années on parle de Flatpak comme la solution qui n'existait pas.
Or non : c'est le nième truc qui est arrivé et qui fragmente.
Pourquoi proposer encore un truc plutôt que d'améliorer/promouvoir de l'existant.
Nix en 15 ans de travail acharné empaquette quand même une quantité astronomique de softs dans des technos très hétérogène.
Le temps joue en sa faveur parce que Rome ne c'est pas construit en 1 jour.
C'est un point que j'avais pas pris en compte, effectivement.
J'en prend note.
Le bac à sable (Nix peut faire aussi) est pour ma part pas forcément une qualité.
Jamais creusé dans ce sens donc j'ai pas d'élément de comparaison.
Ca me fait une belle jambe comme ça : à titre perso, je vois pas ce que ça m'apporte mais je veux bien des cas d'usage.
[^] # Re: Flatpak?
Posté par mothsART . En réponse au journal Sortie de ./play.it 2.11.4. Évalué à 2. Dernière modification le 15 mai 2020 à 15:20.
Oui, j'avoue que c'était un peu provoc.
Je trouve juste dommage que dès qu'on parle d'avoir de l'install user ou un paquet plus à jour que sa distrib, la solution envisagé soit toujours Flatpak alors qu'il ne me semble pas légitime :
- ni historiquement (nix a plus de 15 ans)
- ni techniquement
Y'a qu'en matière de com, de site web (qui est bien plus sexy) qu'il y a un avantage côté Flatpak mais c'est de la poudre aux yeux à mon sens.
Pour les avantages techniques pour l'utilisateur, tu peux voir ici : https://doc.ubuntu-fr.org/nix
Pour les avantages côté dev, j'ai testé les 2 et y'a pas photo. Nix me convainc autant par sa qualité, sa doc, sa cohérence, sa communauté que Flatpak me déçois.
C'est pas parfait mais je trouve que le rapport qualité/communication est disproportionné et j'essai à mon faible niveau d'équilibrer la balance.
Je ne parlerais pas de Snap, Appimage que je connais moins mais qui semble avoir les mêmes défauts que Flatpak.
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 2.
Entièrement dac. (c'est les tests, pas la capacité de rollback)
Je connais et applique tout ça.
Ca complexifie et l'expérience m'a montré que ça n'évite complètement les ratés.
Rien n'est parfait.
Sur des langage comme Rust, tu peux rendre l'ensemble de la base typé et amorcer des migrations ou tu peux garantir que les requètes avant et après migrations soient safe.
On en revient au point initial : un vrai truc typé de bout en bout t'évites d'envoyer de la merde en prod.
Normalement, un WS est versionné et tu peux passer de l'un à l'autre.
Le soucis c'est bien le "normalement" et le "bien fait". Si t'es consommateur, tu subis.
Dans l'absolu : oui. Mais la réalité fait que tu travailles sur du legacy ou tout n'est pas forcément possible aussi facilement.
Alors, oui. Bon, j'appel pas ça du rollback : t'as plusieurs versions de ton app/fonctionnalité et t'as des triggers en fonction de.
Ça peut être un vrai serpent de mer à plusieurs têtes si tu mets ça partout.
Comme souvent : faut savoir utiliser la bonne stack en fonction des besoins, ressources etc.
Ça peut être dur de trouver le bon curseur de déclenchement. faut que les métriques ne tombent pas, qu'elles soient temps réels etc.
Bref : du cas par cas.
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 1. Dernière modification le 15 mai 2020 à 12:08.
Je n'ai jamais parlé d'une prod qui casse un vendredi.
Non, une prod, n'implique pas nécessairement un travail en équipe, ni d'astreintes.
Comment tu peux sortir une généralité comme celle-ci ? Tout dépend du contexte.
Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça…
tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)
Je le redis : pour moi, un bon typage c'est une forme de test : si tu touches à un truc qui ne compile plus, ben tu dois le traiter avant de pousser en prod.
Sur des langages ou tout se fait au runtime, on fait de plus en plus d'analyse static en amont.
L'objectif est le même : prévenir plutôt que guérir.
Je n'arrive toujours pas à comprendre ce que tu essayes de démontrer avec le rollback.
Le rollback c'est le joker au cas ou.
Les devs n'auront pas peur de la prod pas parce qu'ils peuvent revenir en arrière 50 fois dans la journée mais parce que leurs déploiements, aussi fréquents soient-ils se passeront dans l'ensemble bien et que les soucis en prod ne seront pas inlassablement de même nature.
Pour moi, c'est un leurre de croire que tout est rollbackable (et par conséquent, c'est dangereux de trop s'appuyer dessus).
T'as plein de cas ou tu ne peux pas te permettre ce luxe.
qlqs exemples loin d'être exhaustif :
- chg en base de donnée conséquente : même si entre la liv et le rollback, il c'est passé 5min, tu as potentiellement des données à migrer et du coût le rollback ne peut pas être simple.
- tu ne maîtrises pas toute la chaîne de production : ton code dépend d'un web service externe qui a upgrade par ex.
- tu as des niveaux de cache : t'es obligé d'invalidé tes caches à chaque livraison/rollback : tu peux faire explosé ta prod en jouant à ça.
Le rollback, pour moi, c'est du travail dans l'urgence.
Tu atténues l'urgence mais y'a quand même quelqu'un qui a appuyé urgemment sur l'interrupteur.
Tu m'aurais dit "rarement", je me serais dit "étonnent" mais soit.
Avec un jamais, je suis partagé entre "mauvaise foi", "déni", "ignorance".
Je te donne un cas sur lequel j'ai été confronté mille fois (et qui est proprement traité en Rust) : https://fr.wikipedia.org/wiki/Charles_Antony_Richard_Hoare#R.C3.A9flexions_sur_la_programmation
Qu'un objet (structure de données) puisse être vide par défaut et que l'on ne vérifie sa nullité qu'au runtime a énormément d'incidence.
Maintenant, tu extrapoles sur des structures complexes avec énormément d'imbrications (et qui ont tendance à changer régulièrement) et pour résoudre tous les cas potentiels de bugs, tu te rends vite compte que tu es proche de l’explosion combinatoire.
Quand il dit "bug à 1 milliard", je crois qu'il est en dessous de la réalité.
Ce qui est certain, c'est qu'à l'heure des libs/frameworks, ces soucis de typage ne nous saute pas forcément aux yeux juste en lisant la tracktrace.
C'est bien plus sournois mais ça n'empêche que le fond du problème vient de là.
Je vois aussi que beaucoup de frameworks pour des langages faiblement typés ont tendance à atténuer ces soucis parce qu'ils font le travail à notre place.
C'est un moyen détourné qui entraîne d'autres dérives (à mon sens).
Par exemple, sur la stack javascript, utiliser des frameworks obligent npm et donc une foison de dépendances (et dépendances tiers).
Cette dérive est en partie dût à la qualité déplorable du typage du langage et la monté de TypeScript et cie n'y es pas étranger.
En client/serveur toujours, on parle de plus en plus d'isomorphisme.
Ça soulève bien un soucis de typage pour moi : la capacité de partager une structure de donnée sans faux raccord.
Je ne fait pas que de l'antithèse.
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 6. Dernière modification le 14 mai 2020 à 13:58.
En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.
Je pense plutôt qu'il y a une constante : n'importe quel boite souhaite la meilleur qualité et donc des salariés le plus compétents possibles, agiles, volontaires etc.
et que ce facteur humain va dépendre de leur porte feuille, du processus d'embauche, d'un brin de chance etc.
Tout dépend de ce que tu produits.
Si le dev en question nécessite d'avoir des connaissances métiers très pointus (par exemple médical), le bon dev sera un mélange entre qualité technique et connaissances en rapport.
Si le dev doit interagir avec de la donnée : il faut qu'il soit pointu en SQL, elasticSearch etc sinon la qualité ne pourra pas être au rendez-vous.
Si ça nécessite des connaissances mathématiques, il aura beau savoir suivre un worflow de dingue, ça ne suffira pas.
J'ai et j'ai eu l'occasion de travailler sur des projets seul, avec des petites et des grandes équipes : worflow de malade, dev à l'arrache, langage compilé, interprété, fortement typé ou non.
Mon constat c'est que beaucoup de choses "critiques" (les fameuses 500 qui font tant plaisir) peuvent être évités en amont avec du typage, du pattern matching et de l'immutabilité.
Ca veut pas dire qu'on peut pas faire des erreurs de typage avec un langage fortement typé, (genre mettre un string là ou on attend un entier et caster comme un porc un peu partout)
mais on limite vachement les risques, c'est mathématique.
Mieux que ça : dev avec des grosses contraintes m'a mis le nez sur des soucis que je n'aurais jamais anticipé avant.
J'en conçoit, ça n'évite pas les bugs logiques, fonctionnels, métier mais c'est quand même plus valorisant de se concentrer que la dessus, non ?
Il n'est pas impossible d'avoir des erreurs au runtime en Rust (d'ailleurs, aucun langage ne les évites intégralement) mais faut déjà sacrément pousser pour y arriver alors qu'avec d'autres langages, c'est d'une facilité déconcertante.
La simplicité du rollback, c'est bien mais faut pas que ça devienne une solution de facilité.
Bien entendu qu'il est impossible de livrer en prod sans un dérapage mais ce qui me semble plus important que le rollback en lui-même c'est les mesures prisent après rollback :
pourquoi c'est arrivé et comment on évite à l'avenir.
Avec ça, on réduit leur fréquence graduellement et on peut se permettre d'éviter des dettes techniques : maj des libs régulières, refacto etc.
En plus, il y a tellement de cas ou un rollback n'est pas possible (ou que celui-ci a un coût) que de s'appuyer dessus c'est le désastre assuré.
Faut avoir un outil de rollback simple mais coder comme si il était impossible.
[quote]
C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité.
[/quote]
Bon, y'a une variété de tests qui existent, je ne t'apprend rien.
Un test pour moi, c'est une forme de doc : ça dit à un instant T ce que ton soft fait ou ne fait pas.
Tout ce qui n'est pas testé n'est pas contractuel.
Je ne vois pas en quoi faire un écrire un test par quelqu'un d'autre que le dev de la fonctionnalité change quoi que ce soit.
La review de code (si c'est possible avec une hiérarchie de reviewer), le pair programming et inclure le code des tests dans cette relecture me semble bien plus vital.
Un reviewer "senior" qui te drive en te disant qu'il manque tel test ou que ce dernier ne sert à rien, n'aura sans doute pas écrit le code mais ce sera tout comme.
Autre constat, plus tu as de doc et moins tu as de chance que ça soit lu, compris, assimilé par tous.
Comme dis, avoir la même rigueur avec un langage interprété nécessite de faire des tests de typage.
Ca prend du temps, ça n'apporte pas grand chose et ça parasite la doc.
Enfin, quand on a un soucis en prod, tu le sais aussi bien que moi, l'enjeu c'est souvent de reproduire.
Limite, c'est un autre métier.
Reproduire, c'est souvent 90% du taf et quand je fais le constat amer d'avoir passé des heures a arriver à reproduire un bug qui est lié à du typage, ça me fait rager parce que je sais qu'il pouvait être évité en amont.
Je suis bien conscient que dans 10 ans je tomberais encore sur les bugs les plus habituels : date, encodage, dépendances etc. mais je ferais tout pour que ça ne soit pas mon cœur de métier.
En toute franchise, je me considère pas comme le meilleur dev, loin de là : j'écris pas en dvorak avec du 150 MPM, je passe souvent par l'étape papier avant de sortir du syndrome de la page blanche.
Néanmoins, je pense que l'apprentissage de Rust m'a permis de m'améliorer sur plein de sujets et je recommande vivement de sortir de sa zone de confort avec ce genre de langage.
Ca m'a permis de voir certaines choses soit disant acquises avec un autre regard : par exemple la POO.