Zenitram a écrit 29449 commentaires

  • [^] # Re: MPEG-TS

    Posté par  (site web personnel) . En réponse au journal Edition simple de fichiers TS sous Linux. Évalué à 9.

    je vais lâchement profiter d'un fin connaisseur de ces sujets,

    Vite fait alors, j'essaye de me sevrer.

    pourquoi la Freebox me crée

    La Freebox ne créé rien, elle copie simplement le flux reçu, à ma connaissance.

    Pour une durée d'une heure, je dois avoir un fichier de plus d'1 Giga,

    Soit 2.4 Mbps, soit pas grand chose, rien de choquant, au contraire c'est plutôt peu pour de la HD.

    alors que la qualité n'est pas fantastique.

    Comparé à?
    C'est sûr que si tu compares à de l'optimisé par x264 en 2 passes avec autorisation de balancer du 10 Mbps en pointe et avoir un distance de 10 secondes entre les images de références, tu dois être déçu : les contraintes techniques (fiabilité de la diffusion, compression temps réel) font que tu diffuses avec une compression en 1 passe (le 20h de TF1 est en direct et n'attend pas que tu scannes toute la durée), débit maxi bref constant de 2.5 Mbps (pour ton cas, j'imagine) sans autoriser de pointe (ben oui, la diffusion temps réel n'aime pas les pointes, ton tuyau est à taille fixe) et un distance entre les images de référence de 0.5 seconde (vaut mieux vu les pertes sur le tuyau).

    Le mieux est de choper à la source (je te rassure, ils stockent en très bonne qualité, pour le futur, ou pour d'autres canaux moins radins) mais les diffuseurs sont assez avares, dommage :).

  • [^] # Re: MPEG-TS

    Posté par  (site web personnel) . En réponse au journal Edition simple de fichiers TS sous Linux. Évalué à 7.

    Il n'y a pas des paquets de 200 et quelques octets aussi ?

    188 pour les fichiers TS (le classique)
    4+188=192 pour les fichiers M2TS (Bluray)
    188+16=204 pour les fichiers TSP (certaines captures satellite)

  • [^] # Re: Est-ce vraiment un programme de "production" ?

    Posté par  (site web personnel) . En réponse à la dépêche systemd version 216. Évalué à 4.

    Une page de bug-report avec plus d'entrées qu'un forum Usenet.

    Il y a 2 type de logiciels : ceux avec une page de bug-report avec plus d'entrées qu'un forum Usenet, et ceux non utilisés. tu n'aimes simplement pas les trucs qui qont assez utiles pour êtres utilisés, tu préfères les logiciels peu utiles.

    Une nouvelle version tous les mois.

    Bon, ça, je n'ai pas trouvé d'autres idées que les autres montrer la stupidité de l'argumentation.
    Ah peut-être : release early, release often, c'est pas un truc du libre? Tu n'aimes pas le libre?

  • [^] # Re: Not a big deal

    Posté par  (site web personnel) . En réponse au journal Libreoffice 4.3 : Bug 81633 du tri : "It's not a bug, it's a feature !". Évalué à -7.

    Dixit celui qui juge la compétence de son interlocuteur…

    Pas mal le fait de ne pas savoir faire la différence entre la critique de ce que tu es et la critique de ce que tu fais. Ca en dit long…

  • [^] # Re: Not a big deal

    Posté par  (site web personnel) . En réponse au journal Libreoffice 4.3 : Bug 81633 du tri : "It's not a bug, it's a feature !". Évalué à -7.

    Un jour (peut être) tu travaillera en entreprise et tu pourras en parler.

    attaque personnelle, tu fais comme si tu connaissais mon parcours… Dommage pour toi, le "un jour" est arrivé il y a bien longtemps, j'ai déjà fait du déploiement à grande échelle (avec ses petits bonheurs), et pas qu'un peu (avec ses belles merdes, et je ne dirai pas que je suis parfait, ça m'est arrivé de bien planter des choses).

    Faire l'inventaire de l'utilisation des logiciels dans une entreprise un minimum conséquente est très très compliqué

    On parle de "ça pète toute notre chaîne de travail" la…

    Bref sous tes grands airs droit dans tes botes "si tu fais une erreur, j'te vire"

    Tu n'as pas compris une chose : on ne parles pas d'erreur pour quelques personnes (ça arrive, moi en premier, de louper des cas), mais de "ça pète toute notre chaîne de travail après qu'on ai déployé tout".
    si tu penses que tu ne peux pas tester ça, tu peux être licencié pour incompétance, car c'est la base du travail d'un chef de projet (savoir ce qu'est ta chaine de travail, ne pas déployer sur 2000 postes d'un coup puis regarder si ça se passe bien etc, pas pour rien qu'on a des phases pilotes que tu n'as pas l'air de connaitre).

    tu ne semble pas comprendre de quoi tu parle.

    Puisque tu es dans le personnel (au passage, souvent signe d'un manque d'argumentation), je te retourne le compliment.

    PS : sans doute que comme d'hab, en pratique "ça pete toute la chaine de travail" est la réaction de quelques perdus à qui ça pete leur chaine de travail dont ils n'ont pas parlé car ce n'est pas leur rôle de définir la chaine de travail. pas de pitité donc (et c'est complètement différent : la chaine de travail de l'entreprise va bien, le chef de projet déploiement s'en est assuré). Bref, on n'est justement pas dans des cas du petit gars dans son coin, on a 2 cas, un cas où le déploiement est très mal fait et il faut filer des baffes, et un cas où un utilisateurs ne suit pas la chaine de travail qui lui est définie et il faut filer des baffes (pas à la même personne). Je penche perso sur le gars qui est dans son coin mais qui considère que c'est "la chaine de travail" qu'on doit ne pas oublier (même si il l'a caché car sinon il aurait pris des baffes bien avant)

  • [^] # Re: Not a big deal

    Posté par  (site web personnel) . En réponse au journal Libreoffice 4.3 : Bug 81633 du tri : "It's not a bug, it's a feature !". Évalué à -1.

    On vient de migrer 2000 postes PC vers Excel 2014, et ça pète toute notre chaîne de travail.

    Je te vire, pour incompétence, c'est tout. La faute revient à toi, qui n'a pas validé ta chaine de travail avec la nouvelle version avant de déployer (ou à l'inverse : si ça n'a pas été mis dans les tests, c'est que ce ne casse pas ta chaine de travail en réalité).

    Ca n'a rien à voir avec le libre ou pas libre (le coût de la licence n'est q'uun élément parmi plein d'autre du coût), je ne vois pas où tu veux en venir.

  • [^] # Re: Not a big deal

    Posté par  (site web personnel) . En réponse au journal Libreoffice 4.3 : Bug 81633 du tri : "It's not a bug, it's a feature !". Évalué à 5.

    C'est rien du moment où tu as une solution de secours, et la tu en as une grosse de solution (utiliser la version précédente, celle qui te plaisait).
    Rien de "magique".

  • [^] # Re: Questions diverses et variées

    Posté par  (site web personnel) . En réponse au journal SUSE Linux Enterprise 12 disponible !. Évalué à 0. Dernière modification le 28 octobre 2014 à 09:18.

    Je ne vois pas le rapport avec des difficultés financières : ce n'est pas parce que tu gagnes de l'argent à un moment qu'il faut le dépenser n'importe comment, c'est plutôt signe d'une mauvaise gestion, pas viable à long terme (cette remarque marche uatant pour une entreprise que pour… un particulier ;-) ).

    La question est plutôt : KDE serait-il si peu demandé que ça ne vaut pas le coup de l'inclure même en option?

  • [^] # Re: kGraft

    Posté par  (site web personnel) . En réponse au journal SUSE Linux Enterprise 12 disponible !. Évalué à 3. Dernière modification le 28 octobre 2014 à 08:06.

    Mais que les admins SLES sachent qu'ils n'ont pas trop intérêt à investir lourdement dans kGraft parce qu'il se pourrait que ça n'existe que dans cette SLES 12 et plus du tout par la suite.
    Un peu comme Upstart dans RHEL quoi :-)

    Pour rester dans le sujet, j'aurai dit : un peu comme kpatch quoi (qui est sorti "que" dans RHEL7, si kGraft vit qu'une version, kpatch ne vivra aussi qu'une version).

  • [^] # Re: Questions diverses et variées

    Posté par  (site web personnel) . En réponse au journal SUSE Linux Enterprise 12 disponible !. Évalué à -10. Dernière modification le 27 octobre 2014 à 21:21.

    Je suis déçu, pour une fois qu'il y a une vraie bonne grosse actu sur Suse,

    Suse, ça pue c'est pas libre, et en plus ça a moins la côte que RH, du coup pas foule de motivé, dommage.
    Après, c'est ausi dommage que Suse n'ai pas appris de la bétise de RH à ne pas proposer une solution libre et on a eu CentOS et comme personne ne s'y est collé pour Suse (OpenSuse étant plus du genre Fedora), ben ils n'aident pas à se faire aimer de la communauté libre, dommage (RH a appris, lui).

    Je ne suis pas l'actu de Suse de près, mais quelle est la raison derrière ce changement ?

    Je suis bien aussi curieux, car je trouvais pas mal d'avoir l'interface léchée qui va bien (qui ne prend pas les utilisateurs pour des gamins) avec openSuse. KDE se meurt?

  • [^] # Re: Une précision

    Posté par  (site web personnel) . En réponse au journal Ubuntu is dying. Évalué à 2. Dernière modification le 25 octobre 2014 à 23:32.

    D’après l’ADEME, l'énergie économisée en 2003 sur le poste de la consommation électrique en éclairage aurait été de 1 300 GWh, soit 0,28 % de la consommation intérieure d’électricité et 4 % de la consommation d’éclairage totale19.
    Source

    Wow, je suis trop impressionné par le gain de 0.28%, par rapport aux désagréments de la chose. Très utile en effet de parler de valeur absolue pour cacher la valeur relative qu'on ne veut pas voir, balancer un nombre en espérant que ça parait assez gros pour que les gens croient que ça vaut un truc quand ils ont la flemme de se reseigenr (j'espère que tu as toi été curieux, et savait que ça représentait rien et savait que tu bluffais, sinon bon, ben la conclusion…)

    Avec 0.28%, tu m'as convaincu! (ou le contraire).

    PS : bizarrement tu as "oublié" ça : "La généralisation des lampes fluorescentes et l’adaptation de l’éclairage public à la luminosité ambiante participent également à l’amélioration de l’efficacité énergétique et réduisent les bénéfices attribués au changement d’heure, même si ces derniers restent d’actualité jusqu’en 2030, selon un rapport de l’ADEME de 201020."

    Même les plus à fond dessus ne le seront bientôt plus (et d'ailleurs, de plus en plus de pays l'abandonnent, mais bon, ce sont des idiots qui ne pensent pas aux gains énérgétiques hein…), dur dur la vie des pro-heure d'été…

  • [^] # Re: Idée

    Posté par  (site web personnel) . En réponse au journal Ubuntu is dying. Évalué à -5.

    Pour étaler, on peut faire bosser le dimanche et le soir aussi, mais il y a comme des rétincences par ci par la (à coup de procès même), pas gagné d'étaler même d'une heure (on va encore te sortir le droit de vivre ensemble à la maison, les horaire écoles tout ça…)

  • [^] # Re: Une précision

    Posté par  (site web personnel) . En réponse au journal Ubuntu is dying. Évalué à -3. Dernière modification le 25 octobre 2014 à 17:15.

    Le changement d'heure a été fait en pleine crise pétrolière, époque ou pas mal de changement politique ont été pris

    Depuis quand une décision politique est un argument pour dire que c'est cohérent?
    on peut aussi en déduire que ça a été fait pour faire croire qu'on faisait quelque chose politiquement.
    Tiens, Hadopi est super, d'après toi du moins, car il suffit de dire que ça a été fait en pleine crise des ayant droits.

    peu de personne profite du jour dès 5h…

    Rien ne t'empèche de te lever. C'est notre choix de vivre comme ça, alors que midi et minuit ont une certaine signification technique.

  • [^] # Re: A defaut de GNU, il y a Linux

    Posté par  (site web personnel) . En réponse au journal CPP Con sur Youtube. Évalué à 0.

    Typiquement, quand il faut faire une IHM avec, par exemple, Qt, je n'utilise pas les QString ailleurs que dans les classes liées à l'IHM

    QString ne fait pas partie de QtGui, mais de QtCore qui est dédié aux bases d'un programme (donc les libs, pa graphiques).
    Ta lib qui utilises QString ne dépendra donc pas d'une lib graphique, mais d'une lib de base ("Core").
    Qt != QtGui, on l'oublies assez souvent certes.

    et même là, je préfère éviter, mais c'est un exemple. Peut-être pas le meilleur

    En effet ;-).

  • [^] # Re: A defaut de GNU, il y a Linux

    Posté par  (site web personnel) . En réponse au journal CPP Con sur Youtube. Évalué à -9. Dernière modification le 23 octobre 2014 à 16:10.

    pour l'ASM, dans pas mal de projets, on peut voir des "#if" qui se balade justment pour ça : fallback sur du C standard si pas supporté par le compilo (ou que l'ASM n'a pas été fiat pour tel CPU). ASM compris donc (d'ailleurs, ça m'étonnerai qu'il y a du code ASM non optionnel dans Linux, vu toutes les machines à supporter…)

    Bref, c'est surtout une question de volonté (note : je comprend que les développeurs s'en foutent de faire du standard, pas leur priorité, je m'amuse juste sur les incohérences des gens qui demandent du standard chez les autres quand ils en ont besoin mais pas pour leur poulain quand ils n'ont pas besoin, ici Visual C++ devrait être capable de compiler out of the box si le code était standard, car Visual C++ compile pas mal de C standard quand même. Quand on dit que d'avoir plein de trucs différents c'est bien, on "oublie" que Linux ne compile que sur un seul compilo).

  • [^] # Re: A defaut de GNU, il y a Linux

    Posté par  (site web personnel) . En réponse au journal CPP Con sur Youtube. Évalué à 0.

    Linux n'est pas en C standard, ça utilise plein d'extensions GCC, bref c'est rigolo pour des gens râlant sur Microsoft et ses extensions non standards de faire en fait exactement pareil.

    Bref, pas la faute de Microsoft, mais des codeurs Linux qui s'amusent à faire du non standard. Les standards, c'est que quand l'autre ne fait pas comme on veut, sinon on s'en fout ;-).

  • [^] # Re: C++

    Posté par  (site web personnel) . En réponse au journal CPP Con sur Youtube. Évalué à 0. Dernière modification le 22 octobre 2014 à 18:10.

    Le moment où tu fais un transtypage explicite, c'est le moment où tu dis au compilateur « ta gueule, je sais ce que je fais »

    Ha ha…
    Ca peut être aussi "le client veut 0 warning dans sa config du compilo, ben on va lui faire plaisir".
    Bon, certes, ce n'est pas complètement contre ton "ta gueule, je sais ce que je fais", mais ça veut dire plutôt "ce que je fais est faire plaisir au client" que "ce que je fais, je connais son impact sur le code" qui est plutôt sous-entendu, me trompe-je?

    On te donne une corde, tu peux t'en servir pour t'empêcher de tomber du haut de la falaise, mais si tu te sers de ton cou pour t'accrocher, forcément tu vas avoir des surprises.

    Tu peux aussi t'en servir pour faire croire que tu va empécher la personne de tomber de haut de la falaise pour lui faire plaisir et qu'il se lance, mais vaut mieux pas qu'il en ai besoin, on est pas sûr que la corde ne soit qu'une ficelle. Pas aussi binaire que tu le penses, et ne pas savoir arrive plus souvent que tu le penses.
    Oui, on peut faire n'importe quoi avec un cast, et c'est bien le problème : n'importe qui peut, alors que tu minimises ("si tu te sers de ton cou pour t'accrocher, forcément tu vas avoir des surprises", tout de suite…)


    Bref, tout ça pour dire que les gens (moi compris) savaient tout le temps ce qu'ils font quand ils castent à coup de "(type)var", c'est plus ton rêve que la réalité, et que c'est pour ça que certains préfèrent l'interdire complètement dans leur politique de code.

  • [^] # Re: L'esprit de Mailden

    Posté par  (site web personnel) . En réponse au journal Que penses-tu du service mail Mailden ?. Évalué à 5. Dernière modification le 22 octobre 2014 à 15:07.

    L’idée qui anime notre projet est de rehausser le niveau de sécurité des emails, POUR TOUS, c’est-à-dire pour le boulanger, l’employée du bureau, la dessinatrice de mode, mon grand-père, mes enfants, les profs… Nous pensons que tout le monde a le droit d’avoir une zone de confidentialité, en particulier sur Internet.

    Le problème est de savoir faire la différence entre une zone de confidentialité, et une fausse zone de confidentialité.
    Si la technique pose problème, il vaut mieux dire "on peux pas" que de faire croire qu'on peut.

    En plus d’avoir mis au point une solution technique qui sécurise grandement les emails stockés sur les serveurs

    J'attends toujours une démonstration que c'est plus sécurisé que chez OVH (par exemple) : par exemple si OVH met mon mot de passé en PBKDF2 sur un serveur bien à part, c'est plus sécurisé qu'un serveur qui ne stocke pas (il traite) mais qui permet à n'importe quel pirate en herbe de mettre un hook dans le code pour récupérer le mot de passe en clair.

    La question est de savoir en quoi vous permettez plus de confidentialité (contre qui?) que les concurrents. Vous ne stockez pas le pass? OK, mais ça ne change pas que vous pouvez l'avoir quand vous en avez envie (le seul délai est jusqu'à ma prochaine connexion)! Donc ça me protège contre qui? (pas de vous, pas de l'Etat puisqu'il peut vous obliger à dumper mon pass… Donc de qui?)

    Bref, j'ai du mal à voir autre chose que la vente d'un faux sentiment de sécurité, en surfant sur la vague de la peur mais en n'ayant pas de solution technique pour remplir ce qui est dit.

    Ce type d’offre manquait cruellement en France…

    Le problème n'est pas franco-français (ça vaut aussi pour le code en français, si j'embauche une personne pour auditer, elle ne sera pas forcément francophone), ce qui fait donc penser à une opération marketing de se limiter à un pays.

  • [^] # Re: Avec code mais sans limite…

    Posté par  (site web personnel) . En réponse au journal Identification versus authentification : l'embrouille de Zwipe et Mastercard.. Évalué à -2.

    Je ne suis pas d'accord que cela se fasse automatiquement. (…)

    Tu aimes les complications, libre à toi ("OK"? Mais j'ai rien à dire d'autre que "OK", je paye la prestation).
    J'ai un peu de sous en plus sur le compte, rien de mortel, pour n'importe qui (on parle pas de gros montants, et non être limite n'est pas une question de revenu, il y a des "pauvres" pas limites et des "riches" dans le rouges à la fin du mois, qu'on me sorte pas "mais t'es riche", ça n'a rien à voir), c'est quand même bien plus simple.

    Bref, sans doute une façon de voir, quand on aime les demandes de confirmation inutiles.

    Et si ça ne passera pas, je trouverai un autre moyen de payer.

    Je serai mauvais vendeur, car je dirai "pas envie de me prendre la tête avec un autre moyen, disons nous au revoir et je laisse les autres dépenser de l'argent à gérer les râleurs pour le plaisir, moi j'aime bien les gens qui préfèrent le simple et moins cher pour tout le monde".

  • [^] # Re: Forkons Fedora !

    Posté par  (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à -6. Dernière modification le 21 octobre 2014 à 08:32.

    Oui, factuellement c'est trop propre, le but n'est pas de faire déduire que systemd est moins bien, non, pas du tout, "qui sont donc facile à aménager comme on veut" est écrit gratuitement, sans sous-entendre "l'autre c'est moins bien", pas du tout.

    Mais bien sûr…

    mais cela reste des scripts shells, qui sont donc écrit par des humains. Voila, j'ai mis une autre phrase, aussi peu utile. On peut remplir avec plein de trucs inutile, ou ne pas mettre, si il n'y a aucun sous-entendu.

    Dit-moi donc pourquoi tu as écrit "qui sont donc facile à aménager comme on veut".

    PS : pour info, je trouve "facile à aménager comme on veut" comme un inconvénient, car ce n'est pas à cet endroit que le processus metier devrait permettre des hacks. Il faut cloisonner pour pouvoir industrialiser, gérer proprement. Merci pour l'aide à flinguer ce principe.

  • [^] # Re: Forkons Fedora !

    Posté par  (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à -5. Dernière modification le 21 octobre 2014 à 08:12.

    mais cela reste des scripts shells, qui sont donc facile à aménager comme on veut.

    Je vais te révéler un secret : avec systemd, tu peux lancer un… Script shell, qui sont donc facile à aménager comme on veut.

    (ça ne doit pas être la première fois que tu lis cette information, surtout que la personne à laquelle tu réponds te l'a déjà dit mais pas assez directement il faut croire, qu'en conclure sur la personne qui ressort une n-ième fois cet "inconvénient" de systemd?)

  • [^] # Re: Forkons Fedora !

    Posté par  (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à -2.

    C'est à dire que systemd va mutualiser et industrialiser le processus métier.

    Tout à fait.
    J'ai l'impression que le clash arrive car d'un côté des gens veulent travailler (être productif) avec Linux, et de l'autre des gens veulent être payés pour jouer avec Linux, et pour ces derniers la fête est finie (les entreprises n'avaient pas le choix avant, elles devaient payer ceux qui voulaient jouer car c'était les seuls) mais maintenant elle a le choix et donc elle choisit l'industrialisation du processus métier.

    Comme à chaque fois, on voit surtout le mécanisme de rente : ceux qui ont la rente (ici, leur connaissance des bizaretés du shell pour un init) ne veulent pas la perdre, alors que les nouveaux souhaitent avancer.

  • [^] # Re: Forkons Fedora !

    Posté par  (site web personnel) . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à -2.

    mais par où je commence pour ajouter une option perso (un smart-reload ou je ne sais quoi)?

    Perso, je ne sais pas, autant pour systemd que pour SysV.
    Tu démontres le problème principal des "vétérans" : ils ne veulent pas faire l'éffort d'apprendre ce qu'ils ont déjà appris, parce qu'ils savent faire avec le vieux bousin, grâce à l'expérience, et qui trouvent chiant de se retrouver avec un nouveau système où il faut apprendre alors qu'on veut même pas essayer de voir les avantages qu'il va ensuite procurer une fois les premiers pas passés.

    Pas de chance, les nouveaux arrivent, et font plus simple, donc celui qui doit apprendre aujourd'hui va apprendre la version la plus simple (non, pas SysV, j'en suis 100% sûr même si je ne connais ce cas précis) et les vétérans experts en vieillerie iront pointer au chômage (ce qui est normal, quand on ne veut pas apprendre la nouvelle syntaxe parce qu'on connait l'ancienne).

    Dur dur d'apprendre de nouveau et de se retrouver non plus avec son argument d'autorité (je suis vétéran, je sait un peu plus car j'ai appris par coeur les commandes du vieux bousin à force) mais à se battre contre les jeunes avec ses compétences plutôt ;-).

  • [^] # Re: C'est le moment de revenir sur le projet caliop ?

    Posté par  (site web personnel) . En réponse au journal Que penses-tu du service mail Mailden ?. Évalué à 4. Dernière modification le 20 octobre 2014 à 10:12.

    le projet est finalement passé en stade de béta-test. (…) quelqu'un à testé ?

    Je viens de tester : j'ai ouvert la page principale, pas vraiment compris ce qu'il en était du concept, cliqué sur quelques pages, tombé sur "Try prototype", cliqué un peu partout, et ai fermé l'onglet.

    béta, vraiment?
    Concept, vraiment? (voir le premier commentaire de la dépèche LinuxFr)

    Je crois qu'il ne vaut mieux pas en faire trop la publicité pour le moment…

  • [^] # Re: Qualité des alternatives?

    Posté par  (site web personnel) . En réponse à la dépêche Framasoft veut dégoogliser Internet !. Évalué à 0.

    les outils à la con

    Tu as essayé leur équivalent Doodle? Tu crois sérieusement qu'à part quelques geeks perdus ça interesserait du monde un truc aussi difficile à utiliser?

    caliopen

    Pas compris, et le "Fork me on GitHub" bien visible me fait peur, ça doit pas être pour un utilisateur qui veut utiliser. Et rien d'autre (je suis utilisateur de base, si je trouve pas je ne cherche pas plus, je passe).

    GitLab

    Celui-la, OK, bien que ça soit pas aussi sexy que GitHub quand on arrive dessus (les utilisateurs de GitHub ne doivent pas être la cible)

    Mais ce qu’il faut reconnaitre à Framasoft, c’est qu’elle se remue pour être visible.

    Ben oui, tiens, c'est bien le soucis qu'on doive noter qu'elle se remue pour être visible, c'est 50% du taf à faire quand on fait que copier le voisin avec pour argument "on n'a pas NSA".