Les certificats dits "de confiance" sont intégrés localement dans ton ordi, en général installé avec ton navigateur (parfois certaines distributions Linux remanient la liste des autorité qu'elles considèrent de confiance). Ces certificats d'autorité ne sont donc pas récupérés "sur internet" (enfin si le jour où t'as téléchargé ton navigateur, mais pas au cas par cas quand tu visites un site). Voir par exemple la liste des certificats de CA inclus dans Firefox.
Les seules choses qui sont régulièrement vérifiées (et mises en cache, je doute que ce soit très efficace de télécharger à chaque appel) sont les listes de révocation de certificats.
Certains certificats d'autorités intermédiaires sont eux-même intégrées dans les navigateur (donc considérées de confiance au même titre que les autorités parentes qui ont signé leurs certificats), d'autres non.
En tant qu'hébergeur de site web (ou autre application utilisant ces certificats), c'est donc à toi de savoir cela et d'inclure dans ton certificat l'ensemble de la chaîne de certification jusqu'au premier certificat dont l'autorité est de confiance (car le navigateur ne pourra pas deviner qui a signé leur certificat!).
Ainsi si cette CA intermédiaire est inclus dans les navigateurs, juste fournir ton propre cert est suffisant. Sinon, inclus aussi le leur à la suite (et ainsi de suite si nécessaire).
En tant que développeur d'une application cliente qui doit vérifier des certificats, c'est à toi de décider qui est de confiance ou non (en ayant tes propres procédures, ou peut-être en choisissant de faire confiance à Mozilla ou un autre, et d'utiliser la même liste qu'eux) et d'intégrer les certificats comme données locales à côté de ton code.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En fait, je subodore que le seul moyen de s'en sortir serait que LO garde un diff des noeuds entre début et fin de session (i.e. entre ouverture du document et sauvegarde) dans sa représentation interne, et envoie ce diff au filtre OOXML (qui du coup se contenterait de ne modifier que les noeuds ad-hoc dans le document OOXML de départ).
Cette proposition me paraît un peu compliquée. Pas besoin de "diff" entre début et fin. Il suffit de travailler avec un parseur XML générique et donc de garder une représentation complète du document XML, même les nœuds ou les propriétés inconnus. On travaille alors à partir de cette représentation XML générique et pas d'une sous-représentation spécifique aux fonctionnalités de LibreOffice. Bien sûr, on ne peut afficher que les éléments connus par LibreOffice, mais ça ne veut pas dire qu'on se débarrasse du reste. Puis en fin de session, on exporte génériquement le document XML (sans chercher à le "comprendre").
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce que j'ai découvert (je le savais pas y a quelques jours avant de faire les recherches!), c'est que le Flash est virtuellement mort, en tous cas sur le web. D'ici fin 2016, presque tous les navigateurs majeurs (Mozilla Firefox, Google Chrome, Microsoft Edge, Apple Safari…) auront mis en place des mesures à l'encontre de Flash qui ne pourra plus être installé, ou bien nécessitera l'activation par clic à chaque page, etc.
C'est la fin pour Flash, au moins sur le web (sur le bureau, ils ont peut-être encore un peu plus de temps devant eux, mais je donnerais pas cher pour cette utilisation non plus).
Par contre, désolé, je peux pas beaucoup aider constructivement, je suis pas expert en développement web pour te donner les meilleurs conseils. Mais essayons.
Quel outils utiliser/IDE?
Contrairement à Flash qui était centralisé, y aura pas d'IDE principal (mais je suis sûr qu'il en existe déjà plein de bien pour HTML5. Perso j'utilise un éditeur de texte pour coder donc je ne saurais dire).
Quel API utiliser?
HTML5 de base aura déjà pas mal de ce que tu veux faire. Textes et images, bon y a déjà ça dans HTML depuis toujours. Pour l'audio, y a une balise HTML5 dédiée (et même pour la vidéo). Pour les exercices avec corrections, c'est les formulaires qui existent en HTML depuis belle lurette aussi.
Le tout saupoudré d'un peu de javascript pour rendre éventuellement l'utilisation plus fluide et "sexy", et c'est parti.
Tu n'as pas forcément besoin des APIs plus évoluées de HTML5 mais tu peux commencer à les utiliser dans un second temps pour rendre ton application sexy, par exemple avec l'appli drag&drop (certains exercices peuvent s'y prêter, j'imagine), manipuler l'audio et la vidéo dynamiquement en fonction d'évènements utilisateurs (pour une appli de langages, je peux tout à fait imaginer l'étudiant qui regarde une vidéo, et celle-ci pourrait réagir interactivement en fonction de ses réponses, bonnes ou mauvaises. En fait j'ai même déjà imaginé ce genre d'app! :p), etc.
Tiens une recherche de 10 sec dans un moteur de recherche me retourne cette page de Mozilla qui liste certaines fonctionnalités de base de HTML5. En cherchant plus, tu pourras trouver des milliers d'autres ressources (sur ce sujet, c'est pas la littérature qui manque!).
Quel sont les possibilités en termes d'inter-actions entre l'apprenant et le module d'eLearning?
Quasiment tout ce que tu es capable d'imaginer puis de développer.
Je pense qu'il ne manque aucune possibilité à HTML5 par rapport a Flash de nos jours (ce pourquoi l'ensemble des acteurs du marché mettent un frein à Flash qui est un gouffre de sécurité, ralentissements et bouffe la batterie à vitesse grand V).
Est-il possible de développer des modules "génériques" (saisie de texte, sélection de réponse, mots croisés, etc.) que l'on peut utiliser pour construire les applications finales?
Bien sûr, ça s'appelle des bibliothèques (library en anglais pour des recherches web). ;-)
Si tu es développeur, je pense que tu es familier avec le concept, tout de même.
D'ailleurs des centaines de libs javascript existent déjà pour manipuler du HTML5 (la plus connue, et donc assez générique je pense, étant incontestablement jquery, mais selon ce que tu souhaites faire, d'autres libs plus pointues peuvent être plus appropriées) et je pense que tu devrais peut-être commencer par en utiliser certaines qui font déjà probablement ce que tu veux, plutôt que de tout refaire de zéro et réinventer la roue. Avis perso. :p
Comment mettre les applications finales à disposition des apprenants?
Tu cherches à faire un site web ou une appli de bureau?
Toutes mes recommandations partent du principe que tu veux faire un site web, et dans ce cas, la réponse est simplement: donne leur l'adresse du site!
Mais cette dernière question me laisse à penser que tu souhaites faire une application de bureau. Alors c'est tout à fait possible (FirefoxOS l'a prouvé) et c'est même devenu une mode.
Ensuite perso, je ferais une application de bureau avec des technologies plus classiques (GTK+, etc.) mais je suis un peu old-school. Après c'est juste des guerres de chapelle. Si tu souhaites faire une app de bureau HTML5, tu peux.
Je sais qu'il existe plusieurs projets qui aident à packager ce type d'applications. Par contre je connais pas trop ces technologies. La seule que je peux te citer de tête (car j'y ai eu affaire y a juste quelques jours), c'est Electron. Je peux pas trop te dire ce que ça vaut par rapport à la "concurrence" par contre. À toi de chercher et de te faire ton idée.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Est-ce vraiment un bien de pouvoir installer des paquets sans droits d'administrations ?
Ben oui carrêment. C'est plutôt la question inverse qu'il faudrait poser: pourquoi aurait-on besoin de droits d'administration pour la plupart des programmes? C'est une aberration sécuritaire, en un sens. Bien sûr, ce n'est pas tout à fait vrai en remettant en contexte: à l'époque où les systèmes de paquetage classique (.rpm, .deb…) ont été créé, on pensait encore l'informatique avec l'opposition "un admin pointu qui connaît tout sur tout (ahahah)" d'un côté et des "utilisateurs idiots" de l'autre. Dans ce contexte, l'admin choisissait pour ses utilisateurs et il savait (normalement) ce qu'il faisait et aussi pouvait peser la légitimité de la source d'un programme, voire lire les dites-sources (re-ahahah).
Depuis les choses ont évolué et on se rend compte de plus en plus que le plus gros de l'utilisation, c'est: "un seul utilisateur par machine, qui est aussi l'admin". L'informatique personnelle en somme. Souvent cet utilisateur n'a pas particulièrement de connaissance, même si je pense qu'il serait bien de le rendre un peu plus responsable plutôt que totalement soumis (le rêve des GAFAM est qu'ils deviennent les administrateurs du monde et que l'ensemble des utilisateurs restent "idiots" sans chercher à comprendre).
Dans ce nouveau contexte, pouvoir installer un nouveau programme sans droits d'administration est un must.
Le fait est que les utilisateurs Linux installent depuis des années maintenant des logiciels sans droit d'administration: soit en les compilant soi-même, soit en téléchargeant une archive sur un site web (par exemple, on fait cela pour Blender, afin d'avoir une version récente), etc.
Quitte à faire cela, autant le faire de manière sécurisé et avec une intégration au bureau (je déteste avoir à aller chercher un binaire dans un dossier et double-cliquer pour devoir lancer un programme!).
En outre, tu dis plus bas:
Mais la sécurité ce n'est pas que ça. C'est aussi la sécurité des données.
Ben c'est justement là où flatpak va exceller. Un logiciel en sandbox n'a accès aux données que si ce droit lui a été donné. Ce genre de paquetage est 100 fois plus sécurisé pour les données que les systèmes à l'ancienne (lesquels n'ont tout simplement quasiment aucune sécurité, hormis l'utilisateur et le groupe, ce qui ne protège justement absolument pas les données qui auront le même utilisateur que l'exécution). Ils ont accès aux données, au réseau, l’interaction avec les autres processus, etc. Ensuite y a d'autres mécanismes, comme les capabilities POSIX, mais c'est plus complexe et très peu de logiciels "grand public" vont en faire usage. Les logiciels de tous les jours ont un peu tous les pouvoirs au final.
Avec une sandbox dont les permissions sont visibles par l'utilisateur, les choses sont déjà plus claires pour l'utilisateur et plus simple pour le développeur et packageur.
Cela ne risque-t'il pas de détruire la cohérence d'une distribution, en ayant de multiples versions de libs de provenance diverses dont il sera difficile de savoir si elles sont à jour par rapport à des failles de sécurités ?
Alors soyons clair, je préférerai de loin n'avoir besoin que des dépôts de distribution, qu'une seule version par librairie, etc. Mais la réalité a montré les limites de ce système. Au final on se retrouve régulièrement à vouloir installer une version plus récente que ce qu'il y a sur le dépôt, voire même carrément à ne pas trouver dans le dépôt un logiciel. Ça m'est encore arrivé y a 2 jours: je lis une description d'un logiciel libre qui pourrait m'être utile, je me tiens "tiens testons le", il n'était pas dans les dépôts. Et le projet upstream ne proposait qu'un binaire .deb, ainsi qu'une archive qui nécessitait une version différente d'une bibliothèque Python. Au final je n'ai pas pu tester, et j'ai abandonné (j'aurais pu insister et réussir, sans aucun doute. Mais franchement j'ai estimé l'effort comparé à mon besoin et ai décidé que ça ne valait pas le coup). Ça m'a clairement attristé.
Quant à la sécurité, même si l'usptream avait fourni un .rpm que j'aurais pu installer en un clic — avec mon mot de passe root! — quelle sécurité aurais-je eu? Niet, nada, zip! Le programme s'installerait dans mon système et une fois lancé aurait simplement accès à toutes mes données, à mon interface réseau, etc. Je dois avouer l'inavouable: je n'ai pas minutieusement inspecté le code de ce logiciel, même s'il est libre et que j'avais donc accès à tout (ceci dit, la version dans le rpm aurait pu être différente du code public! Donc même si j'avais inspecté le code, ça n'aurait pas forcément servi). Au final, il pourrait tout aussi bien contenir un gros malware qui serait passé comme une lettre à la poste (je l'ai peut-être échappé belle en échouant, qui sait!).
Si ça avait été un flatpak, j'aurais pu vérifier à quoi il avait accès: tiens pourquoi un accès réseau? Ce logiciel doit-il vraiment avoir accès à mon home complet? Etc.
Avec Wayland, j'aurais aussi pu avoir la certitude qu'il ne peut lire mon clavier ou faire un screenshot d'autres programmes (bye-bye keyloggers et assimilés), etc.
Franchement Flatpak améliore la sécurité dans ce cas de figure.
Oui on n'a plus le beau système avec chaque librairie partagée. C'est très triste et franchement cela ne me fait pas plaisir. Mais il faut aller de l'avant. J'ai envie de dire que c'est seulement le monde de l'informatique desktop, mais en fait sur le serveur, ils ont connu cela bien plus tôt, déjà avec les machines virtuelles, puis plus récemment avec docker.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui, tu peux tout à fait essayer Fedora à partir d'une clé live. En fait je ne crois même pas qu'il soit possible de démarrer l'installation directement sans passer par le bureau GNOME qui te permet de tester une install par défaut. Si ce n'est pas le cas pour toi, y a un problème. As-tu bien récupéré ta clé sur https://getfedora.org/?
Non, je ne pense pas que Fedora soit adapté pour le jeu, en tous cas pas par défaut. Les dépôts de logiciels officiels par exemple ne comprennent que des logiciels libres et sans risques légaux (brevets…). Ça veut dire que pour utiliser les pilotes propriétaires des cartes 3D, il faut en général ajouter des dépôts tiers (genre RpmFusion), voire carrêment installer par les scripts upstream pour avoir la dernière version.
Pareil si tu prévoyais d'installer Steam (RpmFusion semble le plus simple).
Donc au final, si (j'ai un peu trollé) Fedora peut marcher très bien pour du jeu. Mais clairement ce n'est pas la distribution qui va simplifier la vie de quelqu'un dont c'est l'objectif principal. Sauf si cette personne sait très bien ce qu'elle fait bien entendu.
Peut-être que la persistance sur la clé usb est possible. Je dois avouer n'avoir jamais essayé: en général, je lance uniquement pour installer, pas pour tester. Mais franchement je doute que ce soit le cas par défaut. À mon avis, faudra bidouiller pour rendre l'espace non utilisé inscriptible. Étant donné que cette clé est clairement fait pour un test vite fait et pour l'installation, je doute que tu puisses écrire sur la clé par défaut. Et encore, cela ne concernera sûrement que les données, à mon avis. Genre les programmes sont probablement installés uniquement en mémoire. Ensuite je me plante peut-être: comme dit, j'ai jamais testé!
Mais encore une fois, peut-être qu'une autre clé que celle de Fedora est plus adaptée si c'est l'usage principal que tu veux en faire. Je sais qu'il existe des clés live qui sont vraiment faites pour ce genre d'utilisation itinérantes. Mais de mémoire, je ne peux que te citer Tails. Par contre c'est vraiment pas orienté "jeu", mais essentiellement "vie privée", donc plein de données sont pas conservées exprès. Par contre, comme c'est vraiment fait pour de l'utilisation réelle sur clé, de la persistance de données est prévue (avec chiffrement des données, bien sûr, etc.).
Existe-t-il une clé pour les joueurs? Peut-être. Y a tellement de projets de distributions de partout dans le monde Linux, pour un peu tout type d'utilisation. Alors pas impossible. Mais si y a, je sais pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Genre en cliquant simplement dessus ? Et ça t'ajoute aussi le dépôt ou bien tu dois faire les mises à jour toi-même ?
Le format .flatpak, c'est juste un paquetage standalone. Par exemple GIMP-telle-version; il n'y a pas de dépôt, pas de mise à jour. Pour le dépôt, le format .flatpakrepo sera possible. Mais le format vraiment intéressant quand on gère un dépôt pour une seule application principalement sera le .flatpakref. Celui-ci référence les infos du dépôt ainsi qu'une application à installer par défaut en même temps.
On pourrait donc installer GIMP en un clic tout en ayant des mises-à-jour régulières.
Et oui l'objectif final est bien de pouvoir installer en un clic (bon avec une GUI intermédiaire, le but n'est pas d'installer des trucs à l'insu de l'utilisateur), comme pour un .rpm ou un .deb par exemple.
On pourra aussi voir les paquets flatpak installés et les désinstaller dans GNOME Software. Et surtout on pourra installer des paquets sans pouvoir d'administration (pour moi, ça c'est vraiment majeur).
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 ]
# Les certificats d'autorité sont installés dans l'OS/navigateurs
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Validation d'une chaine de confiance d'un certificat. Évalué à 4.
Salut,
Les certificats dits "de confiance" sont intégrés localement dans ton ordi, en général installé avec ton navigateur (parfois certaines distributions Linux remanient la liste des autorité qu'elles considèrent de confiance). Ces certificats d'autorité ne sont donc pas récupérés "sur internet" (enfin si le jour où t'as téléchargé ton navigateur, mais pas au cas par cas quand tu visites un site). Voir par exemple la liste des certificats de CA inclus dans Firefox.
Les seules choses qui sont régulièrement vérifiées (et mises en cache, je doute que ce soit très efficace de télécharger à chaque appel) sont les listes de révocation de certificats.
Certains certificats d'autorités intermédiaires sont eux-même intégrées dans les navigateur (donc considérées de confiance au même titre que les autorités parentes qui ont signé leurs certificats), d'autres non.
En tant qu'hébergeur de site web (ou autre application utilisant ces certificats), c'est donc à toi de savoir cela et d'inclure dans ton certificat l'ensemble de la chaîne de certification jusqu'au premier certificat dont l'autorité est de confiance (car le navigateur ne pourra pas deviner qui a signé leur certificat!).
Ainsi si cette CA intermédiaire est inclus dans les navigateurs, juste fournir ton propre cert est suffisant. Sinon, inclus aussi le leur à la suite (et ainsi de suite si nécessaire).
En tant que développeur d'une application cliente qui doit vérifier des certificats, c'est à toi de décider qui est de confiance ou non (en ayant tes propres procédures, ou peut-être en choisissant de faire confiance à Mozilla ou un autre, et d'utiliser la même liste qu'eux) et d'intégrer les certificats comme données locales à côté de ton code.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Paradoxale ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 4.
Cette proposition me paraît un peu compliquée. Pas besoin de "diff" entre début et fin. Il suffit de travailler avec un parseur XML générique et donc de garder une représentation complète du document XML, même les nœuds ou les propriétés inconnus. On travaille alors à partir de cette représentation XML générique et pas d'une sous-représentation spécifique aux fonctionnalités de LibreOffice. Bien sûr, on ne peut afficher que les éléments connus par LibreOffice, mais ça ne veut pas dire qu'on se débarrasse du reste. Puis en fin de session, on exporte génériquement le document XML (sans chercher à le "comprendre").
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Flash est en effet mort, en tous cas sur le web.
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Cherche alternative crédible à Adobe Flash. Évalué à 6.
Je suis en train d'écrire une news sur l'état de Flash, et tu peux en avoir un aperçu (en cours d'écriture) là: http://linuxfr.org/redaction/news/flash-d-adobe-agonise
Ce que j'ai découvert (je le savais pas y a quelques jours avant de faire les recherches!), c'est que le Flash est virtuellement mort, en tous cas sur le web. D'ici fin 2016, presque tous les navigateurs majeurs (Mozilla Firefox, Google Chrome, Microsoft Edge, Apple Safari…) auront mis en place des mesures à l'encontre de Flash qui ne pourra plus être installé, ou bien nécessitera l'activation par clic à chaque page, etc.
C'est la fin pour Flash, au moins sur le web (sur le bureau, ils ont peut-être encore un peu plus de temps devant eux, mais je donnerais pas cher pour cette utilisation non plus).
Par contre, désolé, je peux pas beaucoup aider constructivement, je suis pas expert en développement web pour te donner les meilleurs conseils. Mais essayons.
Contrairement à Flash qui était centralisé, y aura pas d'IDE principal (mais je suis sûr qu'il en existe déjà plein de bien pour HTML5. Perso j'utilise un éditeur de texte pour coder donc je ne saurais dire).
HTML5 de base aura déjà pas mal de ce que tu veux faire. Textes et images, bon y a déjà ça dans HTML depuis toujours. Pour l'audio, y a une balise HTML5 dédiée (et même pour la vidéo). Pour les exercices avec corrections, c'est les formulaires qui existent en HTML depuis belle lurette aussi.
Le tout saupoudré d'un peu de javascript pour rendre éventuellement l'utilisation plus fluide et "sexy", et c'est parti.
Tu n'as pas forcément besoin des APIs plus évoluées de HTML5 mais tu peux commencer à les utiliser dans un second temps pour rendre ton application sexy, par exemple avec l'appli drag&drop (certains exercices peuvent s'y prêter, j'imagine), manipuler l'audio et la vidéo dynamiquement en fonction d'évènements utilisateurs (pour une appli de langages, je peux tout à fait imaginer l'étudiant qui regarde une vidéo, et celle-ci pourrait réagir interactivement en fonction de ses réponses, bonnes ou mauvaises. En fait j'ai même déjà imaginé ce genre d'app! :p), etc.
Tiens une recherche de 10 sec dans un moteur de recherche me retourne cette page de Mozilla qui liste certaines fonctionnalités de base de HTML5. En cherchant plus, tu pourras trouver des milliers d'autres ressources (sur ce sujet, c'est pas la littérature qui manque!).
Quasiment tout ce que tu es capable d'imaginer puis de développer.
Je pense qu'il ne manque aucune possibilité à HTML5 par rapport a Flash de nos jours (ce pourquoi l'ensemble des acteurs du marché mettent un frein à Flash qui est un gouffre de sécurité, ralentissements et bouffe la batterie à vitesse grand V).
Bien sûr, ça s'appelle des bibliothèques (library en anglais pour des recherches web). ;-)
Si tu es développeur, je pense que tu es familier avec le concept, tout de même.
D'ailleurs des centaines de libs javascript existent déjà pour manipuler du HTML5 (la plus connue, et donc assez générique je pense, étant incontestablement jquery, mais selon ce que tu souhaites faire, d'autres libs plus pointues peuvent être plus appropriées) et je pense que tu devrais peut-être commencer par en utiliser certaines qui font déjà probablement ce que tu veux, plutôt que de tout refaire de zéro et réinventer la roue. Avis perso. :p
Tu cherches à faire un site web ou une appli de bureau?
Toutes mes recommandations partent du principe que tu veux faire un site web, et dans ce cas, la réponse est simplement: donne leur l'adresse du site!
Mais cette dernière question me laisse à penser que tu souhaites faire une application de bureau. Alors c'est tout à fait possible (FirefoxOS l'a prouvé) et c'est même devenu une mode.
Ensuite perso, je ferais une application de bureau avec des technologies plus classiques (GTK+, etc.) mais je suis un peu old-school. Après c'est juste des guerres de chapelle. Si tu souhaites faire une app de bureau HTML5, tu peux.
Je sais qu'il existe plusieurs projets qui aident à packager ce type d'applications. Par contre je connais pas trop ces technologies. La seule que je peux te citer de tête (car j'y ai eu affaire y a juste quelques jours), c'est Electron. Je peux pas trop te dire ce que ça vaut par rapport à la "concurrence" par contre. À toi de chercher et de te faire ton idée.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Intégration app store
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie d’Ubuntu 16.10 Yakkety Yak. Évalué à 10.
Ben oui carrêment. C'est plutôt la question inverse qu'il faudrait poser: pourquoi aurait-on besoin de droits d'administration pour la plupart des programmes? C'est une aberration sécuritaire, en un sens. Bien sûr, ce n'est pas tout à fait vrai en remettant en contexte: à l'époque où les systèmes de paquetage classique (.rpm, .deb…) ont été créé, on pensait encore l'informatique avec l'opposition "un admin pointu qui connaît tout sur tout (ahahah)" d'un côté et des "utilisateurs idiots" de l'autre. Dans ce contexte, l'admin choisissait pour ses utilisateurs et il savait (normalement) ce qu'il faisait et aussi pouvait peser la légitimité de la source d'un programme, voire lire les dites-sources (re-ahahah).
Depuis les choses ont évolué et on se rend compte de plus en plus que le plus gros de l'utilisation, c'est: "un seul utilisateur par machine, qui est aussi l'admin". L'informatique personnelle en somme. Souvent cet utilisateur n'a pas particulièrement de connaissance, même si je pense qu'il serait bien de le rendre un peu plus responsable plutôt que totalement soumis (le rêve des GAFAM est qu'ils deviennent les administrateurs du monde et que l'ensemble des utilisateurs restent "idiots" sans chercher à comprendre).
Dans ce nouveau contexte, pouvoir installer un nouveau programme sans droits d'administration est un must.
Le fait est que les utilisateurs Linux installent depuis des années maintenant des logiciels sans droit d'administration: soit en les compilant soi-même, soit en téléchargeant une archive sur un site web (par exemple, on fait cela pour Blender, afin d'avoir une version récente), etc.
Quitte à faire cela, autant le faire de manière sécurisé et avec une intégration au bureau (je déteste avoir à aller chercher un binaire dans un dossier et double-cliquer pour devoir lancer un programme!).
En outre, tu dis plus bas:
Ben c'est justement là où flatpak va exceller. Un logiciel en sandbox n'a accès aux données que si ce droit lui a été donné. Ce genre de paquetage est 100 fois plus sécurisé pour les données que les systèmes à l'ancienne (lesquels n'ont tout simplement quasiment aucune sécurité, hormis l'utilisateur et le groupe, ce qui ne protège justement absolument pas les données qui auront le même utilisateur que l'exécution). Ils ont accès aux données, au réseau, l’interaction avec les autres processus, etc. Ensuite y a d'autres mécanismes, comme les capabilities POSIX, mais c'est plus complexe et très peu de logiciels "grand public" vont en faire usage. Les logiciels de tous les jours ont un peu tous les pouvoirs au final.
Avec une sandbox dont les permissions sont visibles par l'utilisateur, les choses sont déjà plus claires pour l'utilisateur et plus simple pour le développeur et packageur.
Alors soyons clair, je préférerai de loin n'avoir besoin que des dépôts de distribution, qu'une seule version par librairie, etc. Mais la réalité a montré les limites de ce système. Au final on se retrouve régulièrement à vouloir installer une version plus récente que ce qu'il y a sur le dépôt, voire même carrément à ne pas trouver dans le dépôt un logiciel. Ça m'est encore arrivé y a 2 jours: je lis une description d'un logiciel libre qui pourrait m'être utile, je me tiens "tiens testons le", il n'était pas dans les dépôts. Et le projet upstream ne proposait qu'un binaire
.deb, ainsi qu'une archive qui nécessitait une version différente d'une bibliothèque Python. Au final je n'ai pas pu tester, et j'ai abandonné (j'aurais pu insister et réussir, sans aucun doute. Mais franchement j'ai estimé l'effort comparé à mon besoin et ai décidé que ça ne valait pas le coup). Ça m'a clairement attristé.Quant à la sécurité, même si l'usptream avait fourni un
.rpmque j'aurais pu installer en un clic — avec mon mot de passe root! — quelle sécurité aurais-je eu? Niet, nada, zip! Le programme s'installerait dans mon système et une fois lancé aurait simplement accès à toutes mes données, à mon interface réseau, etc. Je dois avouer l'inavouable: je n'ai pas minutieusement inspecté le code de ce logiciel, même s'il est libre et que j'avais donc accès à tout (ceci dit, la version dans le rpm aurait pu être différente du code public! Donc même si j'avais inspecté le code, ça n'aurait pas forcément servi). Au final, il pourrait tout aussi bien contenir un gros malware qui serait passé comme une lettre à la poste (je l'ai peut-être échappé belle en échouant, qui sait!).Si ça avait été un flatpak, j'aurais pu vérifier à quoi il avait accès: tiens pourquoi un accès réseau? Ce logiciel doit-il vraiment avoir accès à mon home complet? Etc.
Avec Wayland, j'aurais aussi pu avoir la certitude qu'il ne peut lire mon clavier ou faire un screenshot d'autres programmes (bye-bye keyloggers et assimilés), etc.
Franchement Flatpak améliore la sécurité dans ce cas de figure.
Oui on n'a plus le beau système avec chaque librairie partagée. C'est très triste et franchement cela ne me fait pas plaisir. Mais il faut aller de l'avant. J'ai envie de dire que c'est seulement le monde de l'informatique desktop, mais en fait sur le serveur, ils ont connu cela bien plus tôt, déjà avec les machines virtuelles, puis plus récemment avec docker.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Oui, non, peut-être…
Posté par Jehan (site web personnel, Mastodon) . En réponse au message essayer Fedora sur une live USB. Évalué à 2.
Oui, tu peux tout à fait essayer Fedora à partir d'une clé live. En fait je ne crois même pas qu'il soit possible de démarrer l'installation directement sans passer par le bureau GNOME qui te permet de tester une install par défaut. Si ce n'est pas le cas pour toi, y a un problème. As-tu bien récupéré ta clé sur https://getfedora.org/?
Non, je ne pense pas que Fedora soit adapté pour le jeu, en tous cas pas par défaut. Les dépôts de logiciels officiels par exemple ne comprennent que des logiciels libres et sans risques légaux (brevets…). Ça veut dire que pour utiliser les pilotes propriétaires des cartes 3D, il faut en général ajouter des dépôts tiers (genre RpmFusion), voire carrêment installer par les scripts upstream pour avoir la dernière version.
Pareil si tu prévoyais d'installer Steam (RpmFusion semble le plus simple).
Donc au final, si (j'ai un peu trollé) Fedora peut marcher très bien pour du jeu. Mais clairement ce n'est pas la distribution qui va simplifier la vie de quelqu'un dont c'est l'objectif principal. Sauf si cette personne sait très bien ce qu'elle fait bien entendu.
Peut-être que la persistance sur la clé usb est possible. Je dois avouer n'avoir jamais essayé: en général, je lance uniquement pour installer, pas pour tester. Mais franchement je doute que ce soit le cas par défaut. À mon avis, faudra bidouiller pour rendre l'espace non utilisé inscriptible. Étant donné que cette clé est clairement fait pour un test vite fait et pour l'installation, je doute que tu puisses écrire sur la clé par défaut. Et encore, cela ne concernera sûrement que les données, à mon avis. Genre les programmes sont probablement installés uniquement en mémoire. Ensuite je me plante peut-être: comme dit, j'ai jamais testé!
Mais encore une fois, peut-être qu'une autre clé que celle de Fedora est plus adaptée si c'est l'usage principal que tu veux en faire. Je sais qu'il existe des clés live qui sont vraiment faites pour ce genre d'utilisation itinérantes. Mais de mémoire, je ne peux que te citer Tails. Par contre c'est vraiment pas orienté "jeu", mais essentiellement "vie privée", donc plein de données sont pas conservées exprès. Par contre, comme c'est vraiment fait pour de l'utilisation réelle sur clé, de la persistance de données est prévue (avec chiffrement des données, bien sûr, etc.).
Existe-t-il une clé pour les joueurs? Peut-être. Y a tellement de projets de distributions de partout dans le monde Linux, pour un peu tout type d'utilisation. Alors pas impossible. Mais si y a, je sais pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Intégration app store
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie d’Ubuntu 16.10 Yakkety Yak. Évalué à 5.
Le format
.flatpak, c'est juste un paquetage standalone. Par exemple GIMP-telle-version; il n'y a pas de dépôt, pas de mise à jour. Pour le dépôt, le format.flatpakreposera possible. Mais le format vraiment intéressant quand on gère un dépôt pour une seule application principalement sera le.flatpakref. Celui-ci référence les infos du dépôt ainsi qu'une application à installer par défaut en même temps.On pourrait donc installer GIMP en un clic tout en ayant des mises-à-jour régulières.
Et oui l'objectif final est bien de pouvoir installer en un clic (bon avec une GUI intermédiaire, le but n'est pas d'installer des trucs à l'insu de l'utilisateur), comme pour un
.rpmou un.debpar exemple.On pourra aussi voir les paquets flatpak installés et les désinstaller dans GNOME Software. Et surtout on pourra installer des paquets sans pouvoir d'administration (pour moi, ça c'est vraiment majeur).
Voir ce billet de Richard Hughes pour voir l'état d'intégration de flatpak dans GNOME Software.
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 ]