mothsART a écrit 181 commentaires

je fais un instantané avant chaque mise à jour de paquets

ah, oui : c'est pas vraiment comme ça que j'envisage l'informatique. Si mon instantané peut être fait automatiquement, c'est mieux.
Bon j'imagine que c'est possible de faire un alias bash ou zsh qui lance ton instantané avant de mettre à jour mais bon on rentre dans la bidouille.

Manjaro créé automatiquement une entrée dans grub pour chaque snapshot du sous-volume BTRFS…

Quand tu me parles de Timeshift, je pensais plus à rsync (usage le plus courant) que à BTRFS.

J'avoue que si tu règles ces 2 points, on obtient un léger avantage pour ta technique vu que les snapshots de BTRFS doivent être bien moins gourmand.

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.

Seul on va plus vite, ensemble on va plus loin !

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.

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.

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 ? :

gspeech-cli -i "mon texte" -o son.wav && aplay son.wav

1. Le fichier son.wav est-il bien créé ?
2. est-ce que tu entends du son cette fois ci ?

Si oui, tu peux installer manuellement :

apt-get install python3-gst-1.0

ç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..

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

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.

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

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 ?

Tout le monde aura remarqué que deno est le verlan de node.

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.

Je reste plus sceptique sur ce point.

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.

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.

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.

Je n'ai jamais remis ça en cause.

Je ne fait pas que de l'antithèse.