L'encre numérique est définie dans leur doc comme une séquence ordonnée de points (cf. doc, section "Ink Format").
Donc oui a priori, j'imagine que l'ordre est pris en compte par le système. Ce serait dommage de ne pas utiliser cette information car on sait que cela rend l'OCR bien plus performant.
En tous cas, d'un point de vue strictement "j'ai pas testé mais je me fie aux notes", la première impression n'est pas idéale: sur le Google Play, il y a quasiment autant de gens (91) qui mettent la pire des notes que de ceux (93) qui mettent la meilleure, avec des commentaires assez brutaux sur la qualité de la reconnaissance.
À côté de cela, j'ai utilisé Google Handwriting Input, qui marche vraiment très bien, et les notes vont aussi dans ce sens. Malheureusement c'est pas libre (pour autant que je sache). :-/
Quoiqu'il en soit, ce projet libéré (WritePad) reste intéressant, et je l'essaierai probablement, surtout qu'on devrait avoir une tablette avec GNOME d'ici quelques mois. Cela pourrait être intéressant d'y avoir ce type d'entrée textuelle pour remplacer les claviers sur écran.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
De mémoire, sur les dernières années, je n'ai eu qu'un seul cas de spoofing sur une adresse connue (et c'était bien visible: juste une courte phrase en anglais genre "regardez ça!" et un lien).
Ensuite on peut imaginer des choses un chouille plus élaborée, du type un message dans le webmail (ou le client lourd) qui dit "Ce message aurait été envoyé dans vos indésirables s'il ne provenait pas d'un correspondant connu. Confirmez-vous sa légimité ou est-ce un spam?" avec un petit lien pour choisir (et éventuellement rediriger l'email vers la boîte spam). Ainsi on reste vigilant.
Bien sûr cela nécessite une intégration particulière avec le webmail, voire mieux des types de flags particuliers dans les headers pour que tout client soit capable de détecter la contradiction des 2 types de détection (l'antispam et le "correspondant connu").
Pour tes mails du bugzilla, le triplet adresse + IP du serveur d'émission + forme général du message me semble plus pertinent.
C'était 1 exemple qui m'est venu parce que j'ai eu le cas y a quelques jours. Mais ce n'est pas mon seul cas. Je reçois et écris beaucoup d'emails. Je n'ai pas tant de faux-positifs en spam, mais ça doit encore m'arriver peut-être 1 ou 2 fois par mois (ce qui est beaucoup trop! Si jamais cela arrive sur un email important, cela peut même être dommageable).
Je ne veux pas avoir à créer une règle explicite avec une IP de serveur ou chose similaire à chaque fois que j'envoie un email (pour lequel j'attends probablement une réponse, ou au minimum, c'est un évènement probable). Non si j'écris à quelqu'un, alors cela devrait être automatique => liste blanche! Cela n'empêche nullement l'antispam de jeter un œil quand même et éventuellement donc mon client de me mettre en garde quand un email paraît suspect. J'aurais le "warning", donc je fais plus attention, ça me suffit.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Utilisateur de dspam depuis de nombreuses années, j'en suis assez content: il fonctionne bien globalement. C'est simple, je pourrais pas faire sans. Par contre il n'est pas parfait. Des spams passent de temps en temps. Et pire du ham peut passer en spam (ceci dit gmail a l'air d'être encore plus mauvais sur ce point et je retrouve bien trop régulièrement des mails dans le spam). Pour cette raison, je regarde toujours en diagonal les spams avant de les supprimer définitivement et c'est chiant. Surtout que mon adresse historique ayant plus de 10 ans, j'ai pas mal de spams (ça augmente d'années en années ;-().
Si rspamd peut vraiment améliorer cet état de fait, ça m'intéresse. Ceci dit, dans le test, on passe de 4 à 2 faux-positifs spam. C'est bien, mais pas parfait. C'est encore 2 de trop!
Quels sont les autres "vérifications et fonctionnalités" de rspamd? Il se contente de le dire sans donner de liste. Dans la doc, je n'arrive à repérer que les règles rspamd (Lua et regexp). Est-ce juste cela?
D'après moi, il y a une fonctionnalité qui pourrait tout changer, mais il faut pour cela que le filtre de spam compile un historique des emails de l'utilisateur destinataire, ainsi que de son carnet d'adresse: toute adresse email de laquel l'utilisateur a déjà reçu des emails (et pas mis en spam par la suite), ou mieux auquelle l'utilisateur a écrit un jour, ainsi que du carnet d'adresse devrait être en liste blanche. Un exemple: je reçois au moins une dizaine de mails du bugzilla de GNOME par semaine. Eh bien il m'arrive encore régulièrement d'en trouver dans le dossier spam (c'est l'exemple qui me vient à l'esprit car justement j'en ai trouvé un y a quelques jours).
Bien sûr, il arrive que des spammers utilisent des adresses connues (c'est même une technique très classique: un virus inspecte le carnet d'adresse d'ordis infectés et envoie ensuite des emails en utilisant les adresses trouvées, sur le principe des sphères de connaissance). Mais c'est un moindre mal.
Exemple classique: j'envoie un email important dont j'attend une réponse. Savoir avec 100% de certitude que la réponse ne sera pas mise dans les spams soulage l'attente. Qui n'a jamais attendu un email et au bout d'un moment s'est dit "peut-être que ça a été taggué spam?" puis s'est senti obligé de regarder son répertoire indésirable?
Donc la question: ce genre de fonctionnalité existe-t-il? Peut-on le faire avec rspamd, ou dspam, ou n'importe quel autre système?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Il existe des personnes (par exemple moi) qui estiment que si un serveur expédie du SPAM ou un truc mal fichu une fois, alors il n'est pas utile d'accepter quoi que ce soit venant de ce serveur dans le futur proche (par exemple à l'horizon de 2 ans).
Quand tu récupères une IP d'un réseau (OVH, Gandi…) et que son précédent "locataire" spammait (sciemment ou à cause d'une erreur technique genre relai mail ouvert), tu ne pénalises absolument pas la bonne personne/le bon serveur. Le spammeur a déjà bougé et est allé voir ailleurs. Par contre tu pénalises quelqu'un de potentiellement tout à fait fiable et compétent qui a récupéré cette IP récemment.
Aussi j'espère que tu bloques tout email venant d'une IP/adresse gmail, outlook, yahoo… enfin tous les gros serveurs quoi. Non parce qu'ils envoient tous du spam (et pas qu'une fois, mais constamment. Même avec de bonnes détections des spammeurs, les comptes bots/volés ne sont pas immédiatement repérés et ont le temps de spammer).
Sinon c'est un peu du 2 poids/2 mesures, et au final tu ne fais que pénaliser ceux qui hébergent leurs propres emails (particuliers, entreprises et autres petits groupes, genre assos, collectifs…), les petits hébergeurs, enfin un peu le web complet quoi. Ils sont pénalisés juste pour avoir l'audace d'être petits, les vilains! Alors que les gros, même s'ils spamment encore plus, ils sont whitelistés pour ne jamais être ajoutés dans les diverses blacklists. À part si tu prônes le fait qu'on devrait tous utiliser les gros hébergeurs d'email (et leur donner notre vie privée en pâture en échange de belle pubs dans nos têtes, par la même occasion), ce n'est pas mon internet idéal.
Tout serveur email, dès qu'il ouvre ses comptes à plus qu'un micro-groupe de gens proches, peut être vecteur de spam pour un temps court (typiquement un utilisateur va se faire prendre le contrôle du compte car il a mis un mot de passe trop faible ou l'a laissé fuiter, ou encore son ordi s'est fait infecter). Bloquer un serveur pour 2 ans car il a été vecteur d'un seul spam à ta destination, tu peux aussi bien couper ton serveur email tout court, ça sera plus rapide.
Attention, je ne dis pas que les blacklists sont totalement mauvaises. C'est un moindre mal qui peut être acceptable, mais seulement si elles sont bien maintenus. Et ça veut dire que non, bloquer une IP pour 2 ans même après qu'elle ait changé de propriétaire, ben ce n'est pas acceptable. On n'a pas tous la chance d'avoir des plages entières d'adresse IP bloquées pour nous, et ça veut dire que les IPs changent très régulièrement de mains.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Donc passer de l'UI de Jitsi à Vroom ou autre, ça n'aurait moins d'impact cognitif sur le pauvre utilisateur qui ne savait pas retenir un sous-domaine?
Un sous-domaine, c'est juste un domaine. Pour une personne qui ne sait pas utiliser un domaine (et y en a, faut voir mon père par exemple qui tape toujours gmail dans le moteur de recherche pour y aller!), taper jitsi.example.com ou talk.example.com, il le fera de toutes façons pas s'il a pas compris le concept de base. Pour celui qui sait par contre, c'est 100 fois plus agréable de taper talk.example.com: au moins on s'en rappelle et c'est explicite/sémantique! Si je peux éviter à avoir à me souvenir des dizaines de logiciels que j'utilise non seulement sur le bureau, mais aussi en ligne (note que je me souviens déjà d'une grande quantité notamment car j'utilise beaucoup l'émulateur de terminal, mais je veux bien éviter d'avoir à mémoriser des trucs inutiles, genre "quel logiciel est installé sur telle URL qu'un tiers a installé!"), je le fais volontiers.
Encore une fois, il n'y a aucun dédain envers les gens qui se servent du logiciel en ligne, c'est même l'inverse, c'est le respect de ne pas les faire chier avec des choses avec lesquels je voudrais pas qu'on me fasse chier aussi (genre me forcer à retenir des noms sans queue ni tête ou changer des URLs!).
Le pauvre utilisateur ne saurit pas retourner sur framasoft.org si il lui arrivait vraiment d'avoir mal au crâne? Et que son cache firefox soit effacé ainsi que ses favoris???
Personne n'a jamais dit ça. Ceci dit, pourquoi forcer les gens à retourner sur framasoft.org juste pour découvrir la nouvelle URL d'une application? Franchement quel intérêt? À part peut-être pour Framasoft, car ça leur permettrait de pousser les gens à aller voir les nouvelles sur la page d'accueil (non je rigole, si c'était tout ce qu'ils trouvaient pour que les gens s'y intéressent, y aurait un sacré problème! uhuh); mais c'est certainement pas dans l'intérêt des gens qui vont perdre leur temps alors qu'ils voulaient juste discuter avec leurs contacts (par exemple, dans le cas de l'instance de discussion). Peut-être même qu'ils étaient pressés et avaient un important RDV d'affaire et c'est ce jour qu'on choisirait pour changer l'URL!
Ensuite je ne dis pas, changer une UI a aussi un fort "impact cognitif". Les gens détestent et se plaignent souvent (toujours?) des UIs changeantes. Mais ils ont aussi montré qu'ils savent s'y habituer, et surtout même rapidement apprécier le changement, surtout quand ils se rendent compte que cela apporte quelque chose (meilleur workflow, nouvelles fonctionnalités…). Et surtout, on n'y peut rien: il faut bien évoluer, et dans le cas d'un service en ligne sans suffisamment de développeurs internes, si cela doit signifier changer de logiciel, alors il faut ce qu'il faut; alors que changer une URL pour un service, il n'y a aucune bonne raison de le faire.
Ensuite ce n'est pas une décision à prendre à la légère chaque matin (il faut vraiment une bonne raison, genre arrêt de développement du logiciel, ou direction du développement qui ne nous convient vraiment plus du tout…). Et une période transitoire où les deux UIs sont disponibles en même temps (genre avec un bandeau dans l'ancienne UI qui dit pendant 3 mois "testez la nouvelle UI qui sera par défaut à date X" avec un gros bouton) n'est pas de trop.
J'abonde sauf qu'on est pas dans le même cas. Un service qui disparait par un autre, quel intérêt de gardre le lien.
En l'occurrence ici le service est "conversation audio/vidéo", pas "Jitsi" (ça c'est le "comment", pas le "quoi"). Donc non le service n'a pas disparu. Tout ce qui importe, c'est que — bien entendu — les donnés soient bien migrées vers le nouveau logiciel (dans le cas présent, j'imagine que ce sera une liste de contact, et probablement un historique d'appels).
Avec le nombre de fois où les interfaces des gros GAFAMs ont aussi complètement changé, si à chaque fois ils avaient cassé toutes les URLs (et gardé les anciennes UIs sur les anciennes URLs, duplicant ainsi le service!), ben… ce seraient sûrement plus des GAFAMs à l'heure actuelle, mais des entreprises en faillite!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
D'un point de vue mémoriel, si tu as jitsimeet.framasoft.org ou diaspora.framasoft.org, ou mattermost.framasoft.org ou lstu.framasoft.org pour le grand public c'est plus compliqué (et je rappelle que c'est à lui …
L'argument de l'utilisateur benêt, un des écueils majeurs des promoteurs du Libre (francophones seulement?).
Alors franchement je sais pas si t'as un nom de domaine, mais moi quand j'ai un nom de domaine example.com, et que je veux y mettre un webmail pour mes adresses @example.com, je vais le mettre genre à webmail.example.com par exemple, quoi que soit le logiciel que j'ai installé (même si je sais très bien ce que j'ai installé). Ça n'a rien à voir avec l'utilisateur "benêt". Et même si t'es doué techniquement, ça veut pas dire que tu dois absolument te rappeler le nom des logiciels. Franchement des fois, il m'arrive d'avoir un trou et de me dire "c'est quoi le nom de ce logiciel que j'utilise tout le temps?" mais ça m'empêche pas de bien l'utiliser, voire même d'y contribuer du code. Ça m'empêche pas de le lancer non plus (je lance beaucoup de logiciels par leur fonction: par exemple, je tape "news" dans l'overview de GNOME pour lancer mon lecteur de flux RSS).
De même que tu pourrais être un génie en maths sans savoir même le bon nom pour les divers théorèmes (ce qui t'empêche pas de les connaître et de savoir les utiliser), ou que tu peux être bon en mécanique et réparer ta voiture sans savoir le nom des divers composants.
Connaître des noms et être "benêt" sont des notions totalement transversales.
On ne se lie pas à l'outil : framatalk, aujourd'hui c'est du jitsimeet. Si demain on veut utiliser Vroom.im, on changera le soft, mais l'URL restera. Ca sera transparent pour l'utilisateur.
Et à nouveau l'utilisateur benêt (décidement).
Euh… franchement, essayer de ne pas casser une URL, c'est prendre l'utilisateur pour un benêt?
Je pense qu'y a un bon lien pour ça: Cool URIs don't change :-)
Enfin bon, non de manière générale, abstraire une "interface" à son utilisation (et non au nom technique de ce qu'il y a derrière) est une extrêmement bonne pratique, non seulement pour l'informatique, mais pour un peu tout de manière générale (du genre, faites pas un nom de recette de cuisine avec un nom d'une marque d'un des ingrédients — bon sauf si vous travaillez pour le service marketing de cette marque bien sûr. Car le jour où vous changez l'ingrédient ou la marque du fournisseur, vous aurez l'air con!).
C'est pour cela qu'en informatique, on fait souvent des wrappers autour des bibliothèques en dépendances, ce qui permet de facilement changer de dépendance au besoin (et ainsi ne pas devoir toucher 1000 endroits du code), et surtout que les APIs doivent le moins possible faire référence aux dépendances (et une URI, c'est un peu une interface applicative!).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ben les trucs classiques: fichiers appdata, desktop, icône… Ce sont des détails, pourtant importants pour le confort d'utilisation au jour le jour.
En gros, le bureau a accès aux informations du logiciel. Ainsi:
Si le bureau a encore un menu avec des catégories, avec GIMP installé par flatpak, l'utilisateur pourra trouver GIMP dans son menu, sous la catégorie "Graphisme".
Si le bureau a un champs de recherche pour trouver les programmes (par exemple comme dans GNOME), taper "gimp" propose GIMP, mais aussi si je tape "photo", "dessin", "graphisme", "image" ou autres mots clés similaires. Éventuellement une courte description du logiciel sera aussi disponible.
L'icône officielle de GIMP sera associée au logiciel (dans menu ou par recherche…) et éventuellement à des fichiers (s'il n'y a pas une prévisualisation plus adaptée).
Les fichiers XCF (et éventuellement d'autres formats d'image) seront liés à GIMP par défaut: double-cliquer un fichier XCF ouvrira GIMP.
GIMP sera proposé comme logiciel alternatif pour d'autres formats qui sont pris en charge mais pour lesquels GIMP n'est pas forcément le meilleur défaut (par exemple, un jpeg, je préfère avoir un simple visionneur par défaut, mais clic droit > "Ouvrir avec une autre application" me proposera GIMP en tête).
Bien qu'installé par flatpak, et non par le gestionnaire de paquet habituel, je peux quand même voir GIMP dans mon gestionnaire de logiciel (avec sa description et des captures d'écran), le désinstaller et même le mettre à jour.
En gros, toutes ces différentes interactions avec le système rendent l'installation par flatpak transparente. Un système "un clic" sans aucune forme d'interaction avec le système, bien qu'attrayant au premier abords, si cela ne permet pas une utilisation intégrée au système, l'intérêt est fortement réduit pour utilisation quotidienne: je me vois pas devoir aller dans un répertoire quelconque, chercher une icône AppImage (ou autre format similaire) à double-cliquer pour lancer le logiciel à chaque fois que j'en ai besoin (alors que j'aurais pu passer par le mode de lancement habituel du bureau ou simplement double-cliquer mon image xcf).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce sont des technologies très récentes qui n'étaient pas prêtes. Encore à ce jour, elles en sont encore à un stade de développement, mais qui commence à peine à vraiment pousser les portes des distributions.
GNOME Software par exemple a maintenant des prises en charge de ces technologies, mais cela n'est encore disponible dans aucune distribution. Ça le sera dans Fedora 25, puis va se répandre au moins dans toutes les distributions avec bureau GNOME.
KDE est aussi en train de travailler avec flatpak. Donc on veut imaginer de similaires prises en charge au cœur du bureau KDE bientôt aussi.
Les gens de Flatpak travaillent aussi sur un concept de service de distributions d'application (Flathub) mais pareil, ce n'est pas encore là.
Enfin flatpak (tout comme Snap) sont conçus par design pour être parfaitement efficaces (niveau sécurité) avec Wayland (respectivement Mir pour Snap). À ce stade, les protections du système sont encore limités par X11.
De manière générale donc, ce sont des projets naissants et il faut s'attendre à leur véritable départ auprès du grand public d'ici 6 mois voire 1 an quand les distribs auront enfin des prises en charge, commenceront les passages à Wayland, et que de plus en plus de projets proposeront des paquets upstream pour ces nouveaux systèmes.
Donc un tel texte d'opinion qui compare ces projets en plein balbutiement à AppImage n'est absolument pas justifié. Le fait est que Flatpak et Snap sont construits avec de nouveaux paradigmes, en particulier sécurité et intégration au bureau (en tout cas pour Flatpak. Je ne sais pas le travail fait sur Snap pour l'intégration au bureau). Mais y a aussi les concepts de "dépôts" (qui permettent de la mise à jour automatique, ainsi que la recherche d'application). Etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui. Il pourra y avoir plusieurs versions de GTK+ installées sur un système (comme actuellement GTK+2 et GTK+3). Le pkg-config des versions 3.9x sera appelé gtk+-4.0,permettant une installation en parallèle et montrant bien que les versions x.9y sont en fait des versions de développement qui visent l'API de la version x+1.
L'idée est que les applis core GNOME sont suffisamment proche de GTK+ (donc suivent le développement de près) pour les avoir suivre la version de dév (ce qui sera en gros similaire à maintenant). Alors que les applis tierces auront le choix: elles auront le droit de suivre aussi la version de dév, qui aura les nouveautés et autres trucs hype, pour le prix d'un coup de maintenance un peu plus poussée; mais elles pourront aussi se rabattre sur la version stable qui sera assurée de ne pas casser les apps.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tout à fait. Pourquoi ça casserait? Si tu souhaites rester sur une vieille version de GTK+, tu seras juste sur une vieille version qui n'aura plus de mises-à-jour, donc pas de correction de bugs en particulier, mais c'est tout. Ça "cassera" pas, et ton application tournera toujours pareil.
Bon par contre, une distribution pourrait retirer les paquets pour une vieille version de GTK+ qui n'est plus maintenue, et si ton logiciel se base dessus, c'est problématique. Mais là encore, ce sera la même chose pour n'importe quelle autre bibliothèque en dépendance si tu souhaites absolument rester sur une vieille version.
Ta solution dans ce cas pourra être de faire un paquet indépendant qui incorpore la version adéquate, par exemple avec Flatpak.
Franchement je comprends pas ces peurs et attaques en règle de GTK+, alors que 3 ans de support par défaut (c'est à dire qu'il y aura toujours possibilité d'avoir plus pour ceux qui payent), c'est vraiment une durée très très appréciable que peu de logiciels fournissent (libres ou propriétaires d'ailleurs). Comme je l'ai dit plus bas, Qt ont la même durée pour leur version LTS par exemple.
Quand GTK+ avait un modèle de développement instable, je pouvais comprendre les critiques. Mais là ils essaient de venir sur un modèle plus stable et surtout avec une durée de maintenance très correcte. Il y a très peu de logiciels libres qui ont une maintenance aussi longue par défaut (en gros, que les autres gros). Donc franchement, je comprends plus les critiques.
Je pense que c'est au contraire à saluer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Conclusion: 3 ans minimum par défaut par version de GNOME, ça me paraît vraiment pas si mal que ça! :-)
Je voulais dire GTK+, pas GNOME, bien sûr (tout le reste de mon post parlait de GTK+). C'est une erreur par amalgame!
Pour gnome, oui. Pour gtk, c’est vachement plus discutable. Surtout comparé à Qt.
Cette remarque m'a étonné. Je me suis demandé quel était le temps de maintenance des versions de Qt. Hop, petit coup de moteur de recherche, et je trouve donc leur version "long term support" (Qt 5.6), qui est de… 3 ans garantis! Exactement comme GTK+.
Ils précisent qu'il y aura possibilité d'acheter du support additionnel… similairement à GTK+ encore une fois (dans le cas de GTK+, ils disent de les contacter pour discuter d'une politique de backport. Je pense que cela signifie que l'approche est différente en ce sens qu'ils sont probablement pas contre un support allongé pour une entreprise qui souhaite payer un employé pour s'en occuper, ce qui est similaire au modèle du noyau par exemple; alors que le modèle Qt est annoncé comme plus entrepreneurial, il semblerait).
En gros, les deux bibliothèques ont la même durée de support, et les mêmes portes ouvertes pour les entreprises qui veulent un support allongé.
Tu ne serais pas en train de mélanger avec l'ancien modèle de développement de GTK+ par hasard? Celui qu'ils sont justement en train de remplacer… :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On parle de maintenance par version, pas par logiciel (quelle idée étrange. Je crois pas qu'ils prévoient d'arrêter de développer GTK+ dans 3 ans! :P). Tu peux pas comparer l'âge d'un logiciel et la durée de maintenance d'une version. Par exemple pour GIMP, avec le nombre extraordinaire de développeurs qu'on a (ironie), je peux t'assurer que notre maintenance d'une version s'arrête dès qu'on sort la version suivante. Par exemple GIMP 2.6 a cessé d'être maintenue à la sortie de 2.8 (je pense, j'y étais pas, mais en tous cas on touche pas à la 2.6 depuis des années. Moi j'y ai jamais touché). Et 2.8 cessera d'être maintenu probablement à la sortie de 2.10, ou peu après (mais sûrement pas 3 ans).
La seule raison pour laquelle cette durée reste longue dans le cas de GIMP, c'est qu'on met trop de temps à sortir les nouvelles versions (pour la même raison de peu de développeurs). :-/
C'est un peu comme si on te demandait de faire des corrections de bug sur des versions anciennes de Newton Adventure. Tu accepteras (peut-être?) de backporter certaines corrections (si tu dois aussi les faire sur la dernière version notamment, mais des fois le bug n'apparaît que sur les vieilles versions donc c'est potentiellement des heures de travail qui n'ont même pas d'incidence sur la version en cours), mais jusqu'à un certain point, j'imagine. Ton temps est quand même limité. Enfin je sais pas exactement quel est ton modèle de développement et peut-être acceptes-tu de corriger des bugs sur des versions de plus de 3 ans (bug qui potentiellement ne touche pas ta dernière version)? :-)
Ceux qui peuvent se permettre plus sont les logiciels avec plus de développeurs, notamment payés, comme GTK+ (et 3 ans, c'est vraiment pas mal). Même le noyau linux, leurs versions long-terme de plus longue durée sont seulement de 6 ans en ce moment (la version 3.2 jusqu'à 2018 et 3.16 jusqu'à 2020). Il est d'ailleurs intéressant de voir qu'ils ont des versions prévues avec "seulement" 2 ans de maintenance et qu'ils qualifient aussi de long-terme (la 4.1 dans le lien donné).
Conclusion: 3 ans minimum par défaut par version de GNOME, ça me paraît vraiment pas si mal que ça! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Puisque tu as l'air de suivre plus en détail les changements de GTK
Je ne suis pas particulièrement GTK+. J'ai découvert pas mal de choses en lisant des posts parce que j'ai participé à la dépêche. Et aussi avec le fait d'avoir été au GUADEC.
est-ce qu'il prévoient encore de gros changements d'APIs et/ou de comportement pour la suite (GTK4, 5, 6, …) ou bien est-ce que les APIs de base vont tendre vers une stabilisation générale?
C'est pas qu'ils prévoient des changements d'APIs ou de comportements. Dit comme ça, on dirait presque que ça veut dire "yeah on va tout casser juste pour embêter les gens". ;-P
C'est simplement que les technologies évoluent, ainsi que les développeurs. Un exemple classique, c'est de faire une erreur conceptuelle. Cela ne rend pas une API forcément inutilisable pour autant, mais ça peut la rendre limitée, chiante à utiliser, voire aberrante (dans certains cas, mais pas d'autres peut-être, ce qui peut expliquer l'erreur car le dév n'a pas vu le problème immédiatement). Tout développeur est tombé sur ce type d'API un jour dans une librairie ou une autre. Ben un changement de version majeure est l'occasion pour casser ce type d'API et les rendre plus logique et utilisable.
Et puis tout simplement, faut bien suivre les technologies. Dans ce genre de librairies, les APIs sont en générale suffisamment abstraites pour qu'un changement de technologie sous-jacente (on va penser au passage de X à Wayland par exemple, mais y a aussi plein d'autres technologies qui sont des briques essentielles de GTK+) ne change pas ces dernières. Mais encore une fois, le monde n'est pas parfait, et il est possible que des points de l'interface doivent être légèrement adaptées.
En gros, vouloir une stabilité totale, ce serait un peu une lubie avec un librairie aussi étendue (c'est à dire qui touche tant de sujet, donc tant de technologies) que GTK+. Du moins si on veut vivre avec son temps et faire évoluer la librairie.
Ensuite je ne doute pas une seconde que les dévs ne vont pas s'amuser à tout changer tout le temps. Ils ne le feront que lorsque cela s'avèrera nécessaire.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
AMHA ce qui pose problème (la disparition des fichiers) c'est le coté hybride. Tout gérer par fichiers arborescents sauf dans certains endroits.
En fait je vois 2 choses qui gênent vraiment:
Le changement d'applications
Ce n'est pas problématique de savoir où sont ses photos par exemple du moment qu'un autre logiciel puisse aussi les utiliser et en plus sans perte de fonctionnalité (cad si c'était de la gestion par tags, etc. on veut retrouver ses tags dans l'autre logiciel). Dans les faits, ce n'est souvent pas le cas et on le voit bien sous Android: des photos faites dans un logiciel "caméra" ne sont pas forcément visible dans un autre logiciel "caméra". C'est pénible de devoir naviguer entre les logiciels pour retrouver une photo (je connais des gens qui utilisent plusieurs logiciels de caméra parce qu'ils proposent des filtres différents, etc.).
Ceci implique d'avoir un standard de gestion des images qui serait alors commun à tout logiciel de gestion des images et permettrait donc de passer d'une appli à l'autre sans avoir à "bouger" des données d'une application à l'autre, donc sans connaissance interne des fichiers. Mais il y a toujours des limites ici aussi, car un standard implique aussi de prendre en compte les spécificités d'un type de fichier donc il faut un standard par type de fichiers: un standard pour les images, un pour les films, un pour la musique, un pour les livres, un pour les documents comptables, un pour ceci, un pour cela… or il y a toujours un type de document trop spécifique car il existe tellement de spécialités donc de types de fichier incongru. Gérer des standards de "où et comment on range tel type de fichier" devient une liste de standards qui grandit à l'infini et avec laquelle il faut toujours se mettre à jour.
La sauvegarde/Le déplacement de fichiers
Le truc classique, on a des images sur son portable, on veut les mettre sur l'ordinateur. Par exemple en branchant un smartphone, l'ordi propose souvent l'import d'images automatique, qui est totalement dans l'esprit "disparition du concept de fichiers". Mais dans le portable, y a aussi des vidéos. Il faut donc un import des vidéos séparés. Et y a d'autres types de fichiers qu'on a pu recevoir par email ou autre. Faut donc des imports pour eux aussi.
Au final, on se retrouve avec le problème des standards, mais c'est pire car on peut pas se permettre de passer 10 heures à lancer 100 types d'import pour être sûr de tout récupérer. C'est un cas typique où on veut (au moins: je veux) pouvoir naviguer un peu plus librement dans l'arborescence car on se rappelle plus trop quel type de fichiers on a bien pu amasser. À ce moment là, comme l'arborescence a été entièrement construite par plein de logiciels, on se rend compte le bordel avec plein de répertoires aux noms incongrus car automatiquement générés, et on a du mal à retrouver les vrais données.
J'ai eu le cas encore y a quelques jours pour essayer de retrouver des vidéos dans le smartphone de quelqu'un.
En tous cas, c'est une idée intéressante et je sais bien que c'est là où on se dirige. Mais c'est assez complexe et y a vraiment plein de choses à prendre en considération avant que tout cela soit fait bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ceci dit je reste persuadé que du point de vue applications utilisatrices, 2 ans c'est trop court.
La maintenance est de 3 ans minimum, cf. la dépêche (basée sur le post officiel). Ensuite on peut faire plus long, mais il y a toujours des limites en particulier financières, car même s'il y a pas mal de contributeurs payés, ce n'est pas encore au niveau du noyau par exemple; et surtout pour qu'il puisse y avoir une version "long terme", il faut en général qu'il y ait au moins une entreprise intéressée et qui paye donc un mainteneur pour cela. Donc quand GNOME deviendra plus répandu (je trouve personnellement que c'est sur la bonne pente. De plus en plus d'entreprises basent leurs produits sur GNOME, comme RedHat ou Endless; des grosses entreprises travaillent notamment avec GNOME, comme Pixar), ce n'est pas impossible qu'il y ait des gens intéressés par des versions long terme de GTK+.
Mais pour l'instant, 3 ans ("minimum" en plus, donc ça peut être plus au cas par cas), c'est quand même pas mal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je crois que la logique actuelle est de s'éloigner des icônes partout, pour tout. C'est joli, coloré (ou pas), mais ça aide pas beaucoup à la compréhension au final, surtout avec des actions compliquées. Il y a des cas où c'est utile, pour des questions de place dans l'UI notamment, mais parfois cela porte surtout à confusion (qui ne s'est jamais demandé "à quoi peut bien servir cette icône dans un logiciel?" et être obligé de tester pour comprendre?). Le texte par contre ne porte jamais (ou plus rarement en tous cas) à confusion.
Alors quand y a déjà du texte de toutes façons (comme dans un menu), la question est aussi: l'icône apporte-t-elle quelque chose de plus? Ou bien ne fait-elle que prendre de l'espace?
Pour la même raison, les boutons qui ont du texte n'ont plus l'icône à côté par défaut (en gros, c'est soit texte, soit icône, mais les deux ensemble, ça sert pas à grand chose).
Sans compter aussi l'effet "PlaySchool" que peut donner un logiciel quand y a des icônes partout.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ok ben je ne savais pas qu'il y avait cette fonctionnalité dans X, mais donc elle est désactivée par défaut dans toutes les distributions? Je ne l'ai jamais vécue (et on utilise des tablettes, etc.) donc je suppose que c'est le cas. Or une fonction désactivée partout (et pire pas activable facilement, en tous cas, je ne crois pas avoir jamais vu une telle option dans un panneau de configuration d'un quelconque système Linux), c'est comme si cela n'existe pas malheureusement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Hmm… c'est moi qui suis coupable de ce mot là. Ensuite perso je l'utilise aussi pour des choses. D'ailleurs le Wiktionnaire a plusieurs définitions, dont une générique: "Qui est sujet à tourner, à changer."
Bon ceci dit, on peut changer. Dans tes 2 propositions, "variés" serait plus le sens. Le fait est que les tablettes ont parfois des boutons, parfois non, parfois à gauche ou à droite (en fait souvent on peut tourner la tablette ou simplement bouger les boutons, lié à un mode "ambidextre"), parfois en haut (j'ai une vieille bamboo avec boutons en haut), avec un nombre indéfini, des fonctions le plus souvent indéfinies aussi, et des formes variées (bouton simple, roue…).
Alors qu'une souris, dans 99% des cas, c'est un bouton à droite, un à gauche, et en général une roulette (voire un bouton pour de vieux modèles) au milieu. Le tout a des fonctions assez définis par l'usage commun depuis pas mal d'années maintenant. Et basta!
C'était là le sens que je donnais à "versatile".
Bon peut-être que "polyvalents" marche aussi ceci dit. Je vois que Zenitram le propose aussi plus bas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
un antivol bluetooth pour vélo ( on serre les freins si l'association est perdue )
C'est pas super dangereux ça? J'imagine bien le truc avec le portable qui tombe en rade de batterie en plein virage, ou autre situation délicate. Et même sans portable qui s'arrête, le bluetooth est pas forcément la technologie la plus fiable. Je ne miserai pas une fonctionnalité si dangereuse (gestion des freins) sur la présence d'une connexion bluetooth.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est tout à fait vrai, c'est la chose qui m'a le plus surpris cette année et ce n'est pas juste en comparant au GUADEC de 2015. Il y avait d'autres évenements plus ou moins libres cet été et bien que de renommés bah, c'était pas ça, le GUADEC 2016 était pour moi le meilleur.
Je peux pas comparer avec d'autres GUADECs, mais c'est vrai certaines autres confs où je vais (que je citerai pas, je veux pas pointer du doigt), les enregistrements sont finalement publiés genre 6 mois plus tard… et encore c'est quand ils le sont. Certains évènements, on nous promet des enregistrements qui viennent jamais (ou sont perdus, ou je-ne-sais-quoi). Souvent aussi, y a des problèmes (matériels, mais aussi beaucoup humains) pendant la conf, ce qui fait que tout ou partie d'une conf n'est pas filmée. Etc.
Ici, y a vraiment eu un sans-faute.
Comment avez-vous réussi à avoir le support/soutien du CCC?
C'est pas moi, j'y suis pour rien! :P
Plus sérieusement, faudrait demander à des gens plus proches de l'organisationnel, et je pense même que ça doit être les organisateurs locaux qui ont dû trouvé.
Ensuite le CCC fait pas mal d'autres confs (suffit de regarder le site pour voir qu'y a un peu de tout) donc à mon avis, du moment que c'est du logiciel libre, s'ils ont des gens libres à ces dates, ils seraient probablement OK. Par contre, faut bien voir que le CCC est basé en Allemagne et le C3VOC (le groupe qui fait les captations vidéos) sort quasi jamais de l'Allemagne (cf. encore le site: la dernière news annonce leur présence en Grande Bretagne, expliquant que ce sera leur première fois en dehors de la zone germanophone européenne). Je pense que ce serait surtout ça le bloqueur dans plein de cas.
ps: bon je vais passer sur Endless forking Linux, ça va m'énerver. :p
Je connais pas cette affaire mais bon… je vais pas demander parce que je veux pas t'énerver! ;-)
Ceci dit, s'ils ont une version locale qu'ils utilisent le temps que leur patchs soient intégrés upstream par exemple, ça me choquerait pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ok je me rends bien compte que c'est un peu une remarque en demi-blague, mais je marche dedans quand même: ta proposition n'a pas du tout la simplicité du "je suis dans mon FS 'cloud', je veux partager un fichier quelconque avec un tel qui est sur un autre serveur (voire avec un autre logiciel), je sélectionne puis 'partage avec un tel', et il reçoit automatiquement une notification qu'on lui partage un fichier, et s'il accepte, le dit fichier apparaît dans son FS de manière transparente".
C'est l'histoire d'un clic du côté envoyeur et un clic côté receveur. Outre la simplicité, y a aussi la permission fine des utilisateurs admis (en lecture seule ou en écriture), etc.
Le fait est que j'utilise pas ça beaucoup entre serveurs (car même si OwnCloud/NextCloud commencent à se répandre, c'est pas non plus le truc que tout le monde a) — si ce n'est jamais (la seule fois, c'était justement pour tester, entre mon compte sur le serveur LILA et celui sur le serveur GNOME) — mais dans l'idée, si un tel protocole d'échanges entre serveurs distants peut se répandre (non seulement avec OwnCloud/NextCloud mais aussi avec les autres logiciels similaires) en standard, c'est génial. Par contre j'utilise ça tout le temps entre utilisateurs du même serveur.
Enfin voilà, comparer ça à bittorrent, c'est complètement à côté de la plaque. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Surtout sait-on si les 2 implémentations prévoient de suivre un même standard (je vois qu'on parle de spéc dans l'article)? À l'heure actuelle, cela fonctionne très probablement puisque le code de base existait déjà avant le fork. Mais s'ils ne prévoient pas de suivre une spéc commune, alors cela pourrait diverger dans l'avenir.
Je pense qu'il est important de savoir que quelque soit les évolutions, le partage sera compatible. Et je parle pas seulement d'Owncloud et Nextcloud. On peut espérer un monde futur où un Nextcloud pourrait partager avec un CozyCloud par exemple. Et pourquoi pas même avec des logiciels proprio (par exemple pourquoi ne pas imaginer que Dropbox décide un jour de suivre le même standard de partage entre clouds)?
Pour moi, ça serait une révolution.
Mais sinon pour en revenir au fork Nextcloud en particulier, je serais intéressé de voir un comparatif et là où les fonctionnalités divergent. J'avoue avoir du mal à savoir qui suivre. J'utilisais OwnCloud avant le fork, et n'ai pas changé depuis car je suis vraiment dans le flou sur qui correspondra le mieux à mes attentes (maintenant ou dans le futur selon les objectifs de chaque projet).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne sais pas parler espéranto, mais ils disent que c'est un langage simple à apprendre. Le latin, c'est un langage complexe, avec du masculin, féminin et neutre (comme en français ou en allemand, c'est à dire sans forcément de logique, du moins pas évidente: pourquoi la rose est-elle féminine?), 6 cas de déclinaisons nominales et d'adjectifs, au singulier et au pluriel, et en plus avec plusieurs (5) types de noms (donc on multiplie par autant pour les terminaisons à apprendre) et 2 classes d'adjectifs, etc.
J'en ai fait (et même apprécié) suffisamment d'années pour savoir que c'est pas facile. Comme je disais, je connais pas l'espéranto et peut-être qu'ils ont tout ça aussi, mais dans ce cas, je sais pas comment ils pourraient affirmer que c'est un langage simple.
Donc je suppose que l'espéranto n'a pas toutes ces complications et alors cela répond à la question « pourquoi pas le latin? ».
Quand au critère de "langue non nationale", je suis pas sûr si le fait d'être une langue morte en fait vraiment une langue non-nationale. Perso ce n'est pas un critère primordial pour moi (j'aime bien les langues de partout avec leur côté régional, ou non, aussi), mais si ça l'est pour des gens, je doute que le latin rentre vraiment dans la catégorie non-nationale.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: dynamique ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Reconnaissance d'écriture à main levée. Évalué à 2.
L'encre numérique est définie dans leur doc comme une séquence ordonnée de points (cf. doc, section "Ink Format").
Donc oui a priori, j'imagine que l'ordre est pris en compte par le système. Ce serait dommage de ne pas utiliser cette information car on sait que cela rend l'OCR bien plus performant.
En tous cas, d'un point de vue strictement "j'ai pas testé mais je me fie aux notes", la première impression n'est pas idéale: sur le Google Play, il y a quasiment autant de gens (91) qui mettent la pire des notes que de ceux (93) qui mettent la meilleure, avec des commentaires assez brutaux sur la qualité de la reconnaissance.
À côté de cela, j'ai utilisé Google Handwriting Input, qui marche vraiment très bien, et les notes vont aussi dans ce sens. Malheureusement c'est pas libre (pour autant que je sache). :-/
Quoiqu'il en soit, ce projet libéré (WritePad) reste intéressant, et je l'essaierai probablement, surtout qu'on devrait avoir une tablette avec GNOME d'ici quelques mois. Cela pourrait être intéressant d'y avoir ce type d'entrée textuelle pour remplacer les claviers sur écran.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: "Furthermore, unlike competitors, Rspamd provides a lot of other checks and features."
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Rspamd continue son chemin. Évalué à 3.
De mémoire, sur les dernières années, je n'ai eu qu'un seul cas de spoofing sur une adresse connue (et c'était bien visible: juste une courte phrase en anglais genre "regardez ça!" et un lien).
Ensuite on peut imaginer des choses un chouille plus élaborée, du type un message dans le webmail (ou le client lourd) qui dit "Ce message aurait été envoyé dans vos indésirables s'il ne provenait pas d'un correspondant connu. Confirmez-vous sa légimité ou est-ce un spam?" avec un petit lien pour choisir (et éventuellement rediriger l'email vers la boîte spam). Ainsi on reste vigilant.
Bien sûr cela nécessite une intégration particulière avec le webmail, voire mieux des types de flags particuliers dans les headers pour que tout client soit capable de détecter la contradiction des 2 types de détection (l'antispam et le "correspondant connu").
C'était 1 exemple qui m'est venu parce que j'ai eu le cas y a quelques jours. Mais ce n'est pas mon seul cas. Je reçois et écris beaucoup d'emails. Je n'ai pas tant de faux-positifs en spam, mais ça doit encore m'arriver peut-être 1 ou 2 fois par mois (ce qui est beaucoup trop! Si jamais cela arrive sur un email important, cela peut même être dommageable).
Je ne veux pas avoir à créer une règle explicite avec une IP de serveur ou chose similaire à chaque fois que j'envoie un email (pour lequel j'attends probablement une réponse, ou au minimum, c'est un évènement probable). Non si j'écris à quelqu'un, alors cela devrait être automatique => liste blanche! Cela n'empêche nullement l'antispam de jeter un œil quand même et éventuellement donc mon client de me mettre en garde quand un email paraît suspect. J'aurais le "warning", donc je fais plus attention, ça me suffit.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# "Furthermore, unlike competitors, Rspamd provides a lot of other checks and features."
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Rspamd continue son chemin. Évalué à 4.
Utilisateur de dspam depuis de nombreuses années, j'en suis assez content: il fonctionne bien globalement. C'est simple, je pourrais pas faire sans. Par contre il n'est pas parfait. Des spams passent de temps en temps. Et pire du ham peut passer en spam (ceci dit gmail a l'air d'être encore plus mauvais sur ce point et je retrouve bien trop régulièrement des mails dans le spam). Pour cette raison, je regarde toujours en diagonal les spams avant de les supprimer définitivement et c'est chiant. Surtout que mon adresse historique ayant plus de 10 ans, j'ai pas mal de spams (ça augmente d'années en années ;-().
Si rspamd peut vraiment améliorer cet état de fait, ça m'intéresse. Ceci dit, dans le test, on passe de 4 à 2 faux-positifs spam. C'est bien, mais pas parfait. C'est encore 2 de trop!
Quels sont les autres "vérifications et fonctionnalités" de rspamd? Il se contente de le dire sans donner de liste. Dans la doc, je n'arrive à repérer que les règles rspamd (Lua et regexp). Est-ce juste cela?
D'après moi, il y a une fonctionnalité qui pourrait tout changer, mais il faut pour cela que le filtre de spam compile un historique des emails de l'utilisateur destinataire, ainsi que de son carnet d'adresse: toute adresse email de laquel l'utilisateur a déjà reçu des emails (et pas mis en spam par la suite), ou mieux auquelle l'utilisateur a écrit un jour, ainsi que du carnet d'adresse devrait être en liste blanche. Un exemple: je reçois au moins une dizaine de mails du bugzilla de GNOME par semaine. Eh bien il m'arrive encore régulièrement d'en trouver dans le dossier spam (c'est l'exemple qui me vient à l'esprit car justement j'en ai trouvé un y a quelques jours).
Bien sûr, il arrive que des spammers utilisent des adresses connues (c'est même une technique très classique: un virus inspecte le carnet d'adresse d'ordis infectés et envoie ensuite des emails en utilisant les adresses trouvées, sur le principe des sphères de connaissance). Mais c'est un moindre mal.
Exemple classique: j'envoie un email important dont j'attend une réponse. Savoir avec 100% de certitude que la réponse ne sera pas mise dans les spams soulage l'attente. Qui n'a jamais attendu un email et au bout d'un moment s'est dit "peut-être que ça a été taggué spam?" puis s'est senti obligé de regarder son répertoire indésirable?
Donc la question: ce genre de fonctionnalité existe-t-il? Peut-on le faire avec rspamd, ou dspam, ou n'importe quel autre système?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ce ne sont pas forcément les "gros" qui posent problème…
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Mails considérés comme spam par gmail : config, spf, mime, ipv4/v6 ? . Évalué à 5.
Quand tu récupères une IP d'un réseau (OVH, Gandi…) et que son précédent "locataire" spammait (sciemment ou à cause d'une erreur technique genre relai mail ouvert), tu ne pénalises absolument pas la bonne personne/le bon serveur. Le spammeur a déjà bougé et est allé voir ailleurs. Par contre tu pénalises quelqu'un de potentiellement tout à fait fiable et compétent qui a récupéré cette IP récemment.
Aussi j'espère que tu bloques tout email venant d'une IP/adresse gmail, outlook, yahoo… enfin tous les gros serveurs quoi. Non parce qu'ils envoient tous du spam (et pas qu'une fois, mais constamment. Même avec de bonnes détections des spammeurs, les comptes bots/volés ne sont pas immédiatement repérés et ont le temps de spammer).
Sinon c'est un peu du 2 poids/2 mesures, et au final tu ne fais que pénaliser ceux qui hébergent leurs propres emails (particuliers, entreprises et autres petits groupes, genre assos, collectifs…), les petits hébergeurs, enfin un peu le web complet quoi. Ils sont pénalisés juste pour avoir l'audace d'être petits, les vilains! Alors que les gros, même s'ils spamment encore plus, ils sont whitelistés pour ne jamais être ajoutés dans les diverses blacklists. À part si tu prônes le fait qu'on devrait tous utiliser les gros hébergeurs d'email (et leur donner notre vie privée en pâture en échange de belle pubs dans nos têtes, par la même occasion), ce n'est pas mon internet idéal.
Tout serveur email, dès qu'il ouvre ses comptes à plus qu'un micro-groupe de gens proches, peut être vecteur de spam pour un temps court (typiquement un utilisateur va se faire prendre le contrôle du compte car il a mis un mot de passe trop faible ou l'a laissé fuiter, ou encore son ordi s'est fait infecter). Bloquer un serveur pour 2 ans car il a été vecteur d'un seul spam à ta destination, tu peux aussi bien couper ton serveur email tout court, ça sera plus rapide.
Attention, je ne dis pas que les blacklists sont totalement mauvaises. C'est un moindre mal qui peut être acceptable, mais seulement si elles sont bien maintenus. Et ça veut dire que non, bloquer une IP pour 2 ans même après qu'elle ait changé de propriétaire, ben ce n'est pas acceptable. On n'a pas tous la chance d'avoir des plages entières d'adresse IP bloquées pour nous, et ça veut dire que les IPs changent très régulièrement de mains.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Deframatisons Internet!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Six nouveaux services chez Framasoft (30 au total). Évalué à 8.
Un sous-domaine, c'est juste un domaine. Pour une personne qui ne sait pas utiliser un domaine (et y en a, faut voir mon père par exemple qui tape toujours gmail dans le moteur de recherche pour y aller!), taper
jitsi.example.comoutalk.example.com, il le fera de toutes façons pas s'il a pas compris le concept de base. Pour celui qui sait par contre, c'est 100 fois plus agréable de tapertalk.example.com: au moins on s'en rappelle et c'est explicite/sémantique! Si je peux éviter à avoir à me souvenir des dizaines de logiciels que j'utilise non seulement sur le bureau, mais aussi en ligne (note que je me souviens déjà d'une grande quantité notamment car j'utilise beaucoup l'émulateur de terminal, mais je veux bien éviter d'avoir à mémoriser des trucs inutiles, genre "quel logiciel est installé sur telle URL qu'un tiers a installé!"), je le fais volontiers.Encore une fois, il n'y a aucun dédain envers les gens qui se servent du logiciel en ligne, c'est même l'inverse, c'est le respect de ne pas les faire chier avec des choses avec lesquels je voudrais pas qu'on me fasse chier aussi (genre me forcer à retenir des noms sans queue ni tête ou changer des URLs!).
Personne n'a jamais dit ça. Ceci dit, pourquoi forcer les gens à retourner sur framasoft.org juste pour découvrir la nouvelle URL d'une application? Franchement quel intérêt? À part peut-être pour Framasoft, car ça leur permettrait de pousser les gens à aller voir les nouvelles sur la page d'accueil (non je rigole, si c'était tout ce qu'ils trouvaient pour que les gens s'y intéressent, y aurait un sacré problème! uhuh); mais c'est certainement pas dans l'intérêt des gens qui vont perdre leur temps alors qu'ils voulaient juste discuter avec leurs contacts (par exemple, dans le cas de l'instance de discussion). Peut-être même qu'ils étaient pressés et avaient un important RDV d'affaire et c'est ce jour qu'on choisirait pour changer l'URL!
Ensuite je ne dis pas, changer une UI a aussi un fort "impact cognitif". Les gens détestent et se plaignent souvent (toujours?) des UIs changeantes. Mais ils ont aussi montré qu'ils savent s'y habituer, et surtout même rapidement apprécier le changement, surtout quand ils se rendent compte que cela apporte quelque chose (meilleur workflow, nouvelles fonctionnalités…). Et surtout, on n'y peut rien: il faut bien évoluer, et dans le cas d'un service en ligne sans suffisamment de développeurs internes, si cela doit signifier changer de logiciel, alors il faut ce qu'il faut; alors que changer une URL pour un service, il n'y a aucune bonne raison de le faire.
Ensuite ce n'est pas une décision à prendre à la légère chaque matin (il faut vraiment une bonne raison, genre arrêt de développement du logiciel, ou direction du développement qui ne nous convient vraiment plus du tout…). Et une période transitoire où les deux UIs sont disponibles en même temps (genre avec un bandeau dans l'ancienne UI qui dit pendant 3 mois "testez la nouvelle UI qui sera par défaut à date X" avec un gros bouton) n'est pas de trop.
En l'occurrence ici le service est "conversation audio/vidéo", pas "Jitsi" (ça c'est le "comment", pas le "quoi"). Donc non le service n'a pas disparu. Tout ce qui importe, c'est que — bien entendu — les donnés soient bien migrées vers le nouveau logiciel (dans le cas présent, j'imagine que ce sera une liste de contact, et probablement un historique d'appels).
Avec le nombre de fois où les interfaces des gros GAFAMs ont aussi complètement changé, si à chaque fois ils avaient cassé toutes les URLs (et gardé les anciennes UIs sur les anciennes URLs, duplicant ainsi le service!), ben… ce seraient sûrement plus des GAFAMs à l'heure actuelle, mais des entreprises en faillite!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Deframatisons Internet!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Six nouveaux services chez Framasoft (30 au total). Évalué à 10.
Alors franchement je sais pas si t'as un nom de domaine, mais moi quand j'ai un nom de domaine
example.com, et que je veux y mettre un webmail pour mes adresses @example.com, je vais le mettre genre àwebmail.example.compar exemple, quoi que soit le logiciel que j'ai installé (même si je sais très bien ce que j'ai installé). Ça n'a rien à voir avec l'utilisateur "benêt". Et même si t'es doué techniquement, ça veut pas dire que tu dois absolument te rappeler le nom des logiciels. Franchement des fois, il m'arrive d'avoir un trou et de me dire "c'est quoi le nom de ce logiciel que j'utilise tout le temps?" mais ça m'empêche pas de bien l'utiliser, voire même d'y contribuer du code. Ça m'empêche pas de le lancer non plus (je lance beaucoup de logiciels par leur fonction: par exemple, je tape "news" dans l'overview de GNOME pour lancer mon lecteur de flux RSS).De même que tu pourrais être un génie en maths sans savoir même le bon nom pour les divers théorèmes (ce qui t'empêche pas de les connaître et de savoir les utiliser), ou que tu peux être bon en mécanique et réparer ta voiture sans savoir le nom des divers composants.
Connaître des noms et être "benêt" sont des notions totalement transversales.
Euh… franchement, essayer de ne pas casser une URL, c'est prendre l'utilisateur pour un benêt?
Je pense qu'y a un bon lien pour ça: Cool URIs don't change :-)
Enfin bon, non de manière générale, abstraire une "interface" à son utilisation (et non au nom technique de ce qu'il y a derrière) est une extrêmement bonne pratique, non seulement pour l'informatique, mais pour un peu tout de manière générale (du genre, faites pas un nom de recette de cuisine avec un nom d'une marque d'un des ingrédients — bon sauf si vous travaillez pour le service marketing de cette marque bien sûr. Car le jour où vous changez l'ingrédient ou la marque du fournisseur, vous aurez l'air con!).
C'est pour cela qu'en informatique, on fait souvent des wrappers autour des bibliothèques en dépendances, ce qui permet de facilement changer de dépendance au besoin (et ainsi ne pas devoir toucher 1000 endroits du code), et surtout que les APIs doivent le moins possible faire référence aux dépendances (et une URI, c'est un peu une interface applicative!).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Appimage
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 6.
Ben les trucs classiques: fichiers appdata, desktop, icône… Ce sont des détails, pourtant importants pour le confort d'utilisation au jour le jour.
En gros, le bureau a accès aux informations du logiciel. Ainsi:
Si le bureau a encore un menu avec des catégories, avec GIMP installé par flatpak, l'utilisateur pourra trouver GIMP dans son menu, sous la catégorie "Graphisme".
Si le bureau a un champs de recherche pour trouver les programmes (par exemple comme dans GNOME), taper "gimp" propose GIMP, mais aussi si je tape "photo", "dessin", "graphisme", "image" ou autres mots clés similaires. Éventuellement une courte description du logiciel sera aussi disponible.
L'icône officielle de GIMP sera associée au logiciel (dans menu ou par recherche…) et éventuellement à des fichiers (s'il n'y a pas une prévisualisation plus adaptée).
Les fichiers XCF (et éventuellement d'autres formats d'image) seront liés à GIMP par défaut: double-cliquer un fichier XCF ouvrira GIMP.
GIMP sera proposé comme logiciel alternatif pour d'autres formats qui sont pris en charge mais pour lesquels GIMP n'est pas forcément le meilleur défaut (par exemple, un jpeg, je préfère avoir un simple visionneur par défaut, mais clic droit > "Ouvrir avec une autre application" me proposera GIMP en tête).
Bien qu'installé par flatpak, et non par le gestionnaire de paquet habituel, je peux quand même voir GIMP dans mon gestionnaire de logiciel (avec sa description et des captures d'écran), le désinstaller et même le mettre à jour.
En gros, toutes ces différentes interactions avec le système rendent l'installation par flatpak transparente. Un système "un clic" sans aucune forme d'interaction avec le système, bien qu'attrayant au premier abords, si cela ne permet pas une utilisation intégrée au système, l'intérêt est fortement réduit pour utilisation quotidienne: je me vois pas devoir aller dans un répertoire quelconque, chercher une icône AppImage (ou autre format similaire) à double-cliquer pour lancer le logiciel à chaque fois que j'en ai besoin (alors que j'aurais pu passer par le mode de lancement habituel du bureau ou simplement double-cliquer mon image xcf).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Autre témoignage
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal [digression] L'Enfer de la flibuste - le récit inédit d'un pirate français. Évalué à 6.
Enfin surtout ce ne sont pas des fautes d'orthographe mais du vieux français. Un peu comme "La vie et les avantures surprenantes de Robinson Crusoe."
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Appimage
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 8.
Ce sont des technologies très récentes qui n'étaient pas prêtes. Encore à ce jour, elles en sont encore à un stade de développement, mais qui commence à peine à vraiment pousser les portes des distributions.
GNOME Software par exemple a maintenant des prises en charge de ces technologies, mais cela n'est encore disponible dans aucune distribution. Ça le sera dans Fedora 25, puis va se répandre au moins dans toutes les distributions avec bureau GNOME.
KDE est aussi en train de travailler avec flatpak. Donc on veut imaginer de similaires prises en charge au cœur du bureau KDE bientôt aussi.
Les gens de Flatpak travaillent aussi sur un concept de service de distributions d'application (Flathub) mais pareil, ce n'est pas encore là.
Enfin flatpak (tout comme Snap) sont conçus par design pour être parfaitement efficaces (niveau sécurité) avec Wayland (respectivement Mir pour Snap). À ce stade, les protections du système sont encore limités par X11.
De manière générale donc, ce sont des projets naissants et il faut s'attendre à leur véritable départ auprès du grand public d'ici 6 mois voire 1 an quand les distribs auront enfin des prises en charge, commenceront les passages à Wayland, et que de plus en plus de projets proposeront des paquets upstream pour ces nouveaux systèmes.
Donc un tel texte d'opinion qui compare ces projets en plein balbutiement à AppImage n'est absolument pas justifié. Le fait est que Flatpak et Snap sont construits avec de nouveaux paradigmes, en particulier sécurité et intégration au bureau (en tout cas pour Flatpak. Je ne sais pas le travail fait sur Snap pour l'intégration au bureau). Mais y a aussi les concepts de "dépôts" (qui permettent de la mise à jour automatique, ainsi que la recherche d'application). Etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 4. Dernière modification le 02 octobre 2016 à 12:32.
Oui. Il pourra y avoir plusieurs versions de GTK+ installées sur un système (comme actuellement GTK+2 et GTK+3). Le pkg-config des versions 3.9x sera appelé gtk+-4.0,permettant une installation en parallèle et montrant bien que les versions x.9y sont en fait des versions de développement qui visent l'API de la version x+1.
L'idée est que les applis core GNOME sont suffisamment proche de GTK+ (donc suivent le développement de près) pour les avoir suivre la version de dév (ce qui sera en gros similaire à maintenant). Alors que les applis tierces auront le choix: elles auront le droit de suivre aussi la version de dév, qui aura les nouveautés et autres trucs hype, pour le prix d'un coup de maintenance un peu plus poussée; mais elles pourront aussi se rabattre sur la version stable qui sera assurée de ne pas casser les apps.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 5.
Tout à fait. Pourquoi ça casserait? Si tu souhaites rester sur une vieille version de GTK+, tu seras juste sur une vieille version qui n'aura plus de mises-à-jour, donc pas de correction de bugs en particulier, mais c'est tout. Ça "cassera" pas, et ton application tournera toujours pareil.
Bon par contre, une distribution pourrait retirer les paquets pour une vieille version de GTK+ qui n'est plus maintenue, et si ton logiciel se base dessus, c'est problématique. Mais là encore, ce sera la même chose pour n'importe quelle autre bibliothèque en dépendance si tu souhaites absolument rester sur une vieille version.
Ta solution dans ce cas pourra être de faire un paquet indépendant qui incorpore la version adéquate, par exemple avec Flatpak.
Franchement je comprends pas ces peurs et attaques en règle de GTK+, alors que 3 ans de support par défaut (c'est à dire qu'il y aura toujours possibilité d'avoir plus pour ceux qui payent), c'est vraiment une durée très très appréciable que peu de logiciels fournissent (libres ou propriétaires d'ailleurs). Comme je l'ai dit plus bas, Qt ont la même durée pour leur version LTS par exemple.
Quand GTK+ avait un modèle de développement instable, je pouvais comprendre les critiques. Mais là ils essaient de venir sur un modèle plus stable et surtout avec une durée de maintenance très correcte. Il y a très peu de logiciels libres qui ont une maintenance aussi longue par défaut (en gros, que les autres gros). Donc franchement, je comprends plus les critiques.
Je pense que c'est au contraire à saluer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 7.
Je voulais dire GTK+, pas GNOME, bien sûr (tout le reste de mon post parlait de GTK+). C'est une erreur par amalgame!
Cette remarque m'a étonné. Je me suis demandé quel était le temps de maintenance des versions de Qt. Hop, petit coup de moteur de recherche, et je trouve donc leur version "long term support" (Qt 5.6), qui est de… 3 ans garantis! Exactement comme GTK+.
Ils précisent qu'il y aura possibilité d'acheter du support additionnel… similairement à GTK+ encore une fois (dans le cas de GTK+, ils disent de les contacter pour discuter d'une politique de backport. Je pense que cela signifie que l'approche est différente en ce sens qu'ils sont probablement pas contre un support allongé pour une entreprise qui souhaite payer un employé pour s'en occuper, ce qui est similaire au modèle du noyau par exemple; alors que le modèle Qt est annoncé comme plus entrepreneurial, il semblerait).
En gros, les deux bibliothèques ont la même durée de support, et les mêmes portes ouvertes pour les entreprises qui veulent un support allongé.
Tu ne serais pas en train de mélanger avec l'ancien modèle de développement de GTK+ par hasard? Celui qu'ils sont justement en train de remplacer… :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 8.
On parle de maintenance par version, pas par logiciel (quelle idée étrange. Je crois pas qu'ils prévoient d'arrêter de développer GTK+ dans 3 ans! :P). Tu peux pas comparer l'âge d'un logiciel et la durée de maintenance d'une version. Par exemple pour GIMP, avec le nombre extraordinaire de développeurs qu'on a (ironie), je peux t'assurer que notre maintenance d'une version s'arrête dès qu'on sort la version suivante. Par exemple GIMP 2.6 a cessé d'être maintenue à la sortie de 2.8 (je pense, j'y étais pas, mais en tous cas on touche pas à la 2.6 depuis des années. Moi j'y ai jamais touché). Et 2.8 cessera d'être maintenu probablement à la sortie de 2.10, ou peu après (mais sûrement pas 3 ans).
La seule raison pour laquelle cette durée reste longue dans le cas de GIMP, c'est qu'on met trop de temps à sortir les nouvelles versions (pour la même raison de peu de développeurs). :-/
C'est un peu comme si on te demandait de faire des corrections de bug sur des versions anciennes de Newton Adventure. Tu accepteras (peut-être?) de backporter certaines corrections (si tu dois aussi les faire sur la dernière version notamment, mais des fois le bug n'apparaît que sur les vieilles versions donc c'est potentiellement des heures de travail qui n'ont même pas d'incidence sur la version en cours), mais jusqu'à un certain point, j'imagine. Ton temps est quand même limité. Enfin je sais pas exactement quel est ton modèle de développement et peut-être acceptes-tu de corriger des bugs sur des versions de plus de 3 ans (bug qui potentiellement ne touche pas ta dernière version)? :-)
Ceux qui peuvent se permettre plus sont les logiciels avec plus de développeurs, notamment payés, comme GTK+ (et 3 ans, c'est vraiment pas mal). Même le noyau linux, leurs versions long-terme de plus longue durée sont seulement de 6 ans en ce moment (la version 3.2 jusqu'à 2018 et 3.16 jusqu'à 2020). Il est d'ailleurs intéressant de voir qu'ils ont des versions prévues avec "seulement" 2 ans de maintenance et qu'ils qualifient aussi de long-terme (la 4.1 dans le lien donné).
Conclusion: 3 ans minimum par défaut par version de GNOME, ça me paraît vraiment pas si mal que ça! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 4.
Je ne suis pas particulièrement GTK+. J'ai découvert pas mal de choses en lisant des posts parce que j'ai participé à la dépêche. Et aussi avec le fait d'avoir été au GUADEC.
C'est pas qu'ils prévoient des changements d'APIs ou de comportements. Dit comme ça, on dirait presque que ça veut dire "yeah on va tout casser juste pour embêter les gens". ;-P
C'est simplement que les technologies évoluent, ainsi que les développeurs. Un exemple classique, c'est de faire une erreur conceptuelle. Cela ne rend pas une API forcément inutilisable pour autant, mais ça peut la rendre limitée, chiante à utiliser, voire aberrante (dans certains cas, mais pas d'autres peut-être, ce qui peut expliquer l'erreur car le dév n'a pas vu le problème immédiatement). Tout développeur est tombé sur ce type d'API un jour dans une librairie ou une autre. Ben un changement de version majeure est l'occasion pour casser ce type d'API et les rendre plus logique et utilisable.
Et puis tout simplement, faut bien suivre les technologies. Dans ce genre de librairies, les APIs sont en générale suffisamment abstraites pour qu'un changement de technologie sous-jacente (on va penser au passage de X à Wayland par exemple, mais y a aussi plein d'autres technologies qui sont des briques essentielles de GTK+) ne change pas ces dernières. Mais encore une fois, le monde n'est pas parfait, et il est possible que des points de l'interface doivent être légèrement adaptées.
En gros, vouloir une stabilité totale, ce serait un peu une lubie avec un librairie aussi étendue (c'est à dire qui touche tant de sujet, donc tant de technologies) que GTK+. Du moins si on veut vivre avec son temps et faire évoluer la librairie.
Ensuite je ne doute pas une seconde que les dévs ne vont pas s'amuser à tout changer tout le temps. Ils ne le feront que lorsque cela s'avèrera nécessaire.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: éditeur pour publication scientifique/technique avec licence libre
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Le Frido, un livre de mathématique libre pour l’agrégation. Évalué à 2.
Y a pas Oreilly aussi qui a publié régulièrement des ouvrages techniques aussi dispos sur le net sous des licences libres?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: icones
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 8.
En fait je vois 2 choses qui gênent vraiment:
Le changement d'applications
Ce n'est pas problématique de savoir où sont ses photos par exemple du moment qu'un autre logiciel puisse aussi les utiliser et en plus sans perte de fonctionnalité (cad si c'était de la gestion par tags, etc. on veut retrouver ses tags dans l'autre logiciel). Dans les faits, ce n'est souvent pas le cas et on le voit bien sous Android: des photos faites dans un logiciel "caméra" ne sont pas forcément visible dans un autre logiciel "caméra". C'est pénible de devoir naviguer entre les logiciels pour retrouver une photo (je connais des gens qui utilisent plusieurs logiciels de caméra parce qu'ils proposent des filtres différents, etc.).
Ceci implique d'avoir un standard de gestion des images qui serait alors commun à tout logiciel de gestion des images et permettrait donc de passer d'une appli à l'autre sans avoir à "bouger" des données d'une application à l'autre, donc sans connaissance interne des fichiers. Mais il y a toujours des limites ici aussi, car un standard implique aussi de prendre en compte les spécificités d'un type de fichier donc il faut un standard par type de fichiers: un standard pour les images, un pour les films, un pour la musique, un pour les livres, un pour les documents comptables, un pour ceci, un pour cela… or il y a toujours un type de document trop spécifique car il existe tellement de spécialités donc de types de fichier incongru. Gérer des standards de "où et comment on range tel type de fichier" devient une liste de standards qui grandit à l'infini et avec laquelle il faut toujours se mettre à jour.
La sauvegarde/Le déplacement de fichiers
Le truc classique, on a des images sur son portable, on veut les mettre sur l'ordinateur. Par exemple en branchant un smartphone, l'ordi propose souvent l'import d'images automatique, qui est totalement dans l'esprit "disparition du concept de fichiers". Mais dans le portable, y a aussi des vidéos. Il faut donc un import des vidéos séparés. Et y a d'autres types de fichiers qu'on a pu recevoir par email ou autre. Faut donc des imports pour eux aussi.
Au final, on se retrouve avec le problème des standards, mais c'est pire car on peut pas se permettre de passer 10 heures à lancer 100 types d'import pour être sûr de tout récupérer. C'est un cas typique où on veut (au moins: je veux) pouvoir naviguer un peu plus librement dans l'arborescence car on se rappelle plus trop quel type de fichiers on a bien pu amasser. À ce moment là, comme l'arborescence a été entièrement construite par plein de logiciels, on se rend compte le bordel avec plein de répertoires aux noms incongrus car automatiquement générés, et on a du mal à retrouver les vrais données.
J'ai eu le cas encore y a quelques jours pour essayer de retrouver des vidéos dans le smartphone de quelqu'un.
En tous cas, c'est une idée intéressante et je sais bien que c'est là où on se dirige. Mais c'est assez complexe et y a vraiment plein de choses à prendre en considération avant que tout cela soit fait bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 7.
La maintenance est de 3 ans minimum, cf. la dépêche (basée sur le post officiel). Ensuite on peut faire plus long, mais il y a toujours des limites en particulier financières, car même s'il y a pas mal de contributeurs payés, ce n'est pas encore au niveau du noyau par exemple; et surtout pour qu'il puisse y avoir une version "long terme", il faut en général qu'il y ait au moins une entreprise intéressée et qui paye donc un mainteneur pour cela. Donc quand GNOME deviendra plus répandu (je trouve personnellement que c'est sur la bonne pente. De plus en plus d'entreprises basent leurs produits sur GNOME, comme RedHat ou Endless; des grosses entreprises travaillent notamment avec GNOME, comme Pixar), ce n'est pas impossible qu'il y ait des gens intéressés par des versions long terme de GTK+.
Mais pour l'instant, 3 ans ("minimum" en plus, donc ça peut être plus au cas par cas), c'est quand même pas mal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: icones
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 3.
Ça fait déjà un bout de temps que les icônes dans les menus ont été dépréciés.
Tu peux trouver une méthode ici pour les récupérer si tu veux absolument des icônes partout. En espérant pour toi que cette méthode marche toujours (le lien date de 2013):
https://ask.fedoraproject.org/en/question/23116/how-to-fix-missing-icons-in-program-menus-and-context-menus/
Je crois que la logique actuelle est de s'éloigner des icônes partout, pour tout. C'est joli, coloré (ou pas), mais ça aide pas beaucoup à la compréhension au final, surtout avec des actions compliquées. Il y a des cas où c'est utile, pour des questions de place dans l'UI notamment, mais parfois cela porte surtout à confusion (qui ne s'est jamais demandé "à quoi peut bien servir cette icône dans un logiciel?" et être obligé de tester pour comprendre?). Le texte par contre ne porte jamais (ou plus rarement en tous cas) à confusion.
Alors quand y a déjà du texte de toutes façons (comme dans un menu), la question est aussi: l'icône apporte-t-elle quelque chose de plus? Ou bien ne fait-elle que prendre de l'espace?
Pour la même raison, les boutons qui ont du texte n'ont plus l'icône à côté par défaut (en gros, c'est soit texte, soit icône, mais les deux ensemble, ça sert pas à grand chose).
Sans compter aussi l'effet "PlaySchool" que peut donner un logiciel quand y a des icônes partout.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pointeurs multiples
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 5.
Salut,
Ok ben je ne savais pas qu'il y avait cette fonctionnalité dans X, mais donc elle est désactivée par défaut dans toutes les distributions? Je ne l'ai jamais vécue (et on utilise des tablettes, etc.) donc je suppose que c'est le cas. Or une fonction désactivée partout (et pire pas activable facilement, en tous cas, je ne crois pas avoir jamais vu une telle option dans un panneau de configuration d'un quelconque système Linux), c'est comme si cela n'existe pas malheureusement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Proposition de correction
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 2. Dernière modification le 29 septembre 2016 à 12:33.
Hmm… c'est moi qui suis coupable de ce mot là. Ensuite perso je l'utilise aussi pour des choses. D'ailleurs le Wiktionnaire a plusieurs définitions, dont une générique: "Qui est sujet à tourner, à changer."
Bon ceci dit, on peut changer. Dans tes 2 propositions, "variés" serait plus le sens. Le fait est que les tablettes ont parfois des boutons, parfois non, parfois à gauche ou à droite (en fait souvent on peut tourner la tablette ou simplement bouger les boutons, lié à un mode "ambidextre"), parfois en haut (j'ai une vieille bamboo avec boutons en haut), avec un nombre indéfini, des fonctions le plus souvent indéfinies aussi, et des formes variées (bouton simple, roue…).
Alors qu'une souris, dans 99% des cas, c'est un bouton à droite, un à gauche, et en général une roulette (voire un bouton pour de vieux modèles) au milieu. Le tout a des fonctions assez définis par l'usage commun depuis pas mal d'années maintenant. Et basta!
C'était là le sens que je donnais à "versatile".
Bon peut-être que "polyvalents" marche aussi ceci dit. Je vois que Zenitram le propose aussi plus bas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: mes projets des années précedentes
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à 6.
C'est pas super dangereux ça? J'imagine bien le truc avec le portable qui tombe en rade de batterie en plein virage, ou autre situation délicate. Et même sans portable qui s'arrête, le bluetooth est pas forcément la technologie la plus fiable. Je ne miserai pas une fonctionnalité si dangereuse (gestion des freins) sur la présence d'une connexion bluetooth.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: C'est vrai!
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Compte rendu de GUADEC 2016. Évalué à 3.
Je peux pas comparer avec d'autres GUADECs, mais c'est vrai certaines autres confs où je vais (que je citerai pas, je veux pas pointer du doigt), les enregistrements sont finalement publiés genre 6 mois plus tard… et encore c'est quand ils le sont. Certains évènements, on nous promet des enregistrements qui viennent jamais (ou sont perdus, ou je-ne-sais-quoi). Souvent aussi, y a des problèmes (matériels, mais aussi beaucoup humains) pendant la conf, ce qui fait que tout ou partie d'une conf n'est pas filmée. Etc.
Ici, y a vraiment eu un sans-faute.
C'est pas moi, j'y suis pour rien! :P
Plus sérieusement, faudrait demander à des gens plus proches de l'organisationnel, et je pense même que ça doit être les organisateurs locaux qui ont dû trouvé.
Ensuite le CCC fait pas mal d'autres confs (suffit de regarder le site pour voir qu'y a un peu de tout) donc à mon avis, du moment que c'est du logiciel libre, s'ils ont des gens libres à ces dates, ils seraient probablement OK. Par contre, faut bien voir que le CCC est basé en Allemagne et le C3VOC (le groupe qui fait les captations vidéos) sort quasi jamais de l'Allemagne (cf. encore le site: la dernière news annonce leur présence en Grande Bretagne, expliquant que ce sera leur première fois en dehors de la zone germanophone européenne). Je pense que ce serait surtout ça le bloqueur dans plein de cas.
Je connais pas cette affaire mais bon… je vais pas demander parce que je veux pas t'énerver! ;-)
Ceci dit, s'ils ont une version locale qu'ils utilisent le temps que leur patchs soient intégrés upstream par exemple, ça me choquerait pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et nextcloud ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Owncloud 9 termine sa fédération. Évalué à 4.
Ok je me rends bien compte que c'est un peu une remarque en demi-blague, mais je marche dedans quand même: ta proposition n'a pas du tout la simplicité du "je suis dans mon FS 'cloud', je veux partager un fichier quelconque avec un tel qui est sur un autre serveur (voire avec un autre logiciel), je sélectionne puis 'partage avec un tel', et il reçoit automatiquement une notification qu'on lui partage un fichier, et s'il accepte, le dit fichier apparaît dans son FS de manière transparente".
C'est l'histoire d'un clic du côté envoyeur et un clic côté receveur. Outre la simplicité, y a aussi la permission fine des utilisateurs admis (en lecture seule ou en écriture), etc.
Le fait est que j'utilise pas ça beaucoup entre serveurs (car même si OwnCloud/NextCloud commencent à se répandre, c'est pas non plus le truc que tout le monde a) — si ce n'est jamais (la seule fois, c'était justement pour tester, entre mon compte sur le serveur LILA et celui sur le serveur GNOME) — mais dans l'idée, si un tel protocole d'échanges entre serveurs distants peut se répandre (non seulement avec OwnCloud/NextCloud mais aussi avec les autres logiciels similaires) en standard, c'est génial. Par contre j'utilise ça tout le temps entre utilisateurs du même serveur.
Enfin voilà, comparer ça à bittorrent, c'est complètement à côté de la plaque. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et nextcloud ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Owncloud 9 termine sa fédération. Évalué à 7.
Surtout sait-on si les 2 implémentations prévoient de suivre un même standard (je vois qu'on parle de spéc dans l'article)? À l'heure actuelle, cela fonctionne très probablement puisque le code de base existait déjà avant le fork. Mais s'ils ne prévoient pas de suivre une spéc commune, alors cela pourrait diverger dans l'avenir.
Je pense qu'il est important de savoir que quelque soit les évolutions, le partage sera compatible. Et je parle pas seulement d'Owncloud et Nextcloud. On peut espérer un monde futur où un Nextcloud pourrait partager avec un CozyCloud par exemple. Et pourquoi pas même avec des logiciels proprio (par exemple pourquoi ne pas imaginer que Dropbox décide un jour de suivre le même standard de partage entre clouds)?
Pour moi, ça serait une révolution.
Mais sinon pour en revenir au fork Nextcloud en particulier, je serais intéressé de voir un comparatif et là où les fonctionnalités divergent. J'avoue avoir du mal à savoir qui suivre. J'utilisais OwnCloud avant le fork, et n'ai pas changé depuis car je suis vraiment dans le flou sur qui correspondra le mieux à mes attentes (maintenant ou dans le futur selon les objectifs de chaque projet).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: un beau combat... d'un autre siècle
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche État de l’espéranto sous GNU/Linux. Évalué à 7.
Je ne sais pas parler espéranto, mais ils disent que c'est un langage simple à apprendre. Le latin, c'est un langage complexe, avec du masculin, féminin et neutre (comme en français ou en allemand, c'est à dire sans forcément de logique, du moins pas évidente: pourquoi la rose est-elle féminine?), 6 cas de déclinaisons nominales et d'adjectifs, au singulier et au pluriel, et en plus avec plusieurs (5) types de noms (donc on multiplie par autant pour les terminaisons à apprendre) et 2 classes d'adjectifs, etc.
J'en ai fait (et même apprécié) suffisamment d'années pour savoir que c'est pas facile. Comme je disais, je connais pas l'espéranto et peut-être qu'ils ont tout ça aussi, mais dans ce cas, je sais pas comment ils pourraient affirmer que c'est un langage simple.
Donc je suppose que l'espéranto n'a pas toutes ces complications et alors cela répond à la question « pourquoi pas le latin? ».
Quand au critère de "langue non nationale", je suis pas sûr si le fait d'être une langue morte en fait vraiment une langue non-nationale. Perso ce n'est pas un critère primordial pour moi (j'aime bien les langues de partout avec leur côté régional, ou non, aussi), mais si ça l'est pour des gens, je doute que le latin rentre vraiment dans la catégorie non-nationale.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]