D'un point de vue mémoriel, si tu as jitsimeet.framasoft.org ou diaspora.framasoft.org, ou mattermost.framasoft.org ou lstu.framasoft.org pour le grand public c'est plus compliqué (et je rappelle que c'est à lui …
L'argument de l'utilisateur benêt, un des écueils majeurs des promoteurs du Libre (francophones seulement?).
Alors franchement je sais pas si t'as un nom de domaine, mais moi quand j'ai un nom de domaine example.com, et que je veux y mettre un webmail pour mes adresses @example.com, je vais le mettre genre à webmail.example.com par exemple, quoi que soit le logiciel que j'ai installé (même si je sais très bien ce que j'ai installé). Ça n'a rien à voir avec l'utilisateur "benêt". Et même si t'es doué techniquement, ça veut pas dire que tu dois absolument te rappeler le nom des logiciels. Franchement des fois, il m'arrive d'avoir un trou et de me dire "c'est quoi le nom de ce logiciel que j'utilise tout le temps?" mais ça m'empêche pas de bien l'utiliser, voire même d'y contribuer du code. Ça m'empêche pas de le lancer non plus (je lance beaucoup de logiciels par leur fonction: par exemple, je tape "news" dans l'overview de GNOME pour lancer mon lecteur de flux RSS).
De même que tu pourrais être un génie en maths sans savoir même le bon nom pour les divers théorèmes (ce qui t'empêche pas de les connaître et de savoir les utiliser), ou que tu peux être bon en mécanique et réparer ta voiture sans savoir le nom des divers composants.
Connaître des noms et être "benêt" sont des notions totalement transversales.
On ne se lie pas à l'outil : framatalk, aujourd'hui c'est du jitsimeet. Si demain on veut utiliser Vroom.im, on changera le soft, mais l'URL restera. Ca sera transparent pour l'utilisateur.
Et à nouveau l'utilisateur benêt (décidement).
Euh… franchement, essayer de ne pas casser une URL, c'est prendre l'utilisateur pour un benêt?
Je pense qu'y a un bon lien pour ça: Cool URIs don't change :-)
Enfin bon, non de manière générale, abstraire une "interface" à son utilisation (et non au nom technique de ce qu'il y a derrière) est une extrêmement bonne pratique, non seulement pour l'informatique, mais pour un peu tout de manière générale (du genre, faites pas un nom de recette de cuisine avec un nom d'une marque d'un des ingrédients — bon sauf si vous travaillez pour le service marketing de cette marque bien sûr. Car le jour où vous changez l'ingrédient ou la marque du fournisseur, vous aurez l'air con!).
C'est pour cela qu'en informatique, on fait souvent des wrappers autour des bibliothèques en dépendances, ce qui permet de facilement changer de dépendance au besoin (et ainsi ne pas devoir toucher 1000 endroits du code), et surtout que les APIs doivent le moins possible faire référence aux dépendances (et une URI, c'est un peu une interface applicative!).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ben les trucs classiques: fichiers appdata, desktop, icône… Ce sont des détails, pourtant importants pour le confort d'utilisation au jour le jour.
En gros, le bureau a accès aux informations du logiciel. Ainsi:
Si le bureau a encore un menu avec des catégories, avec GIMP installé par flatpak, l'utilisateur pourra trouver GIMP dans son menu, sous la catégorie "Graphisme".
Si le bureau a un champs de recherche pour trouver les programmes (par exemple comme dans GNOME), taper "gimp" propose GIMP, mais aussi si je tape "photo", "dessin", "graphisme", "image" ou autres mots clés similaires. Éventuellement une courte description du logiciel sera aussi disponible.
L'icône officielle de GIMP sera associée au logiciel (dans menu ou par recherche…) et éventuellement à des fichiers (s'il n'y a pas une prévisualisation plus adaptée).
Les fichiers XCF (et éventuellement d'autres formats d'image) seront liés à GIMP par défaut: double-cliquer un fichier XCF ouvrira GIMP.
GIMP sera proposé comme logiciel alternatif pour d'autres formats qui sont pris en charge mais pour lesquels GIMP n'est pas forcément le meilleur défaut (par exemple, un jpeg, je préfère avoir un simple visionneur par défaut, mais clic droit > "Ouvrir avec une autre application" me proposera GIMP en tête).
Bien qu'installé par flatpak, et non par le gestionnaire de paquet habituel, je peux quand même voir GIMP dans mon gestionnaire de logiciel (avec sa description et des captures d'écran), le désinstaller et même le mettre à jour.
En gros, toutes ces différentes interactions avec le système rendent l'installation par flatpak transparente. Un système "un clic" sans aucune forme d'interaction avec le système, bien qu'attrayant au premier abords, si cela ne permet pas une utilisation intégrée au système, l'intérêt est fortement réduit pour utilisation quotidienne: je me vois pas devoir aller dans un répertoire quelconque, chercher une icône AppImage (ou autre format similaire) à double-cliquer pour lancer le logiciel à chaque fois que j'en ai besoin (alors que j'aurais pu passer par le mode de lancement habituel du bureau ou simplement double-cliquer mon image xcf).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce sont des technologies très récentes qui n'étaient pas prêtes. Encore à ce jour, elles en sont encore à un stade de développement, mais qui commence à peine à vraiment pousser les portes des distributions.
GNOME Software par exemple a maintenant des prises en charge de ces technologies, mais cela n'est encore disponible dans aucune distribution. Ça le sera dans Fedora 25, puis va se répandre au moins dans toutes les distributions avec bureau GNOME.
KDE est aussi en train de travailler avec flatpak. Donc on veut imaginer de similaires prises en charge au cœur du bureau KDE bientôt aussi.
Les gens de Flatpak travaillent aussi sur un concept de service de distributions d'application (Flathub) mais pareil, ce n'est pas encore là.
Enfin flatpak (tout comme Snap) sont conçus par design pour être parfaitement efficaces (niveau sécurité) avec Wayland (respectivement Mir pour Snap). À ce stade, les protections du système sont encore limités par X11.
De manière générale donc, ce sont des projets naissants et il faut s'attendre à leur véritable départ auprès du grand public d'ici 6 mois voire 1 an quand les distribs auront enfin des prises en charge, commenceront les passages à Wayland, et que de plus en plus de projets proposeront des paquets upstream pour ces nouveaux systèmes.
Donc un tel texte d'opinion qui compare ces projets en plein balbutiement à AppImage n'est absolument pas justifié. Le fait est que Flatpak et Snap sont construits avec de nouveaux paradigmes, en particulier sécurité et intégration au bureau (en tout cas pour Flatpak. Je ne sais pas le travail fait sur Snap pour l'intégration au bureau). Mais y a aussi les concepts de "dépôts" (qui permettent de la mise à jour automatique, ainsi que la recherche d'application). Etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui. Il pourra y avoir plusieurs versions de GTK+ installées sur un système (comme actuellement GTK+2 et GTK+3). Le pkg-config des versions 3.9x sera appelé gtk+-4.0,permettant une installation en parallèle et montrant bien que les versions x.9y sont en fait des versions de développement qui visent l'API de la version x+1.
L'idée est que les applis core GNOME sont suffisamment proche de GTK+ (donc suivent le développement de près) pour les avoir suivre la version de dév (ce qui sera en gros similaire à maintenant). Alors que les applis tierces auront le choix: elles auront le droit de suivre aussi la version de dév, qui aura les nouveautés et autres trucs hype, pour le prix d'un coup de maintenance un peu plus poussée; mais elles pourront aussi se rabattre sur la version stable qui sera assurée de ne pas casser les apps.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tout à fait. Pourquoi ça casserait? Si tu souhaites rester sur une vieille version de GTK+, tu seras juste sur une vieille version qui n'aura plus de mises-à-jour, donc pas de correction de bugs en particulier, mais c'est tout. Ça "cassera" pas, et ton application tournera toujours pareil.
Bon par contre, une distribution pourrait retirer les paquets pour une vieille version de GTK+ qui n'est plus maintenue, et si ton logiciel se base dessus, c'est problématique. Mais là encore, ce sera la même chose pour n'importe quelle autre bibliothèque en dépendance si tu souhaites absolument rester sur une vieille version.
Ta solution dans ce cas pourra être de faire un paquet indépendant qui incorpore la version adéquate, par exemple avec Flatpak.
Franchement je comprends pas ces peurs et attaques en règle de GTK+, alors que 3 ans de support par défaut (c'est à dire qu'il y aura toujours possibilité d'avoir plus pour ceux qui payent), c'est vraiment une durée très très appréciable que peu de logiciels fournissent (libres ou propriétaires d'ailleurs). Comme je l'ai dit plus bas, Qt ont la même durée pour leur version LTS par exemple.
Quand GTK+ avait un modèle de développement instable, je pouvais comprendre les critiques. Mais là ils essaient de venir sur un modèle plus stable et surtout avec une durée de maintenance très correcte. Il y a très peu de logiciels libres qui ont une maintenance aussi longue par défaut (en gros, que les autres gros). Donc franchement, je comprends plus les critiques.
Je pense que c'est au contraire à saluer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Conclusion: 3 ans minimum par défaut par version de GNOME, ça me paraît vraiment pas si mal que ça! :-)
Je voulais dire GTK+, pas GNOME, bien sûr (tout le reste de mon post parlait de GTK+). C'est une erreur par amalgame!
Pour gnome, oui. Pour gtk, c’est vachement plus discutable. Surtout comparé à Qt.
Cette remarque m'a étonné. Je me suis demandé quel était le temps de maintenance des versions de Qt. Hop, petit coup de moteur de recherche, et je trouve donc leur version "long term support" (Qt 5.6), qui est de… 3 ans garantis! Exactement comme GTK+.
Ils précisent qu'il y aura possibilité d'acheter du support additionnel… similairement à GTK+ encore une fois (dans le cas de GTK+, ils disent de les contacter pour discuter d'une politique de backport. Je pense que cela signifie que l'approche est différente en ce sens qu'ils sont probablement pas contre un support allongé pour une entreprise qui souhaite payer un employé pour s'en occuper, ce qui est similaire au modèle du noyau par exemple; alors que le modèle Qt est annoncé comme plus entrepreneurial, il semblerait).
En gros, les deux bibliothèques ont la même durée de support, et les mêmes portes ouvertes pour les entreprises qui veulent un support allongé.
Tu ne serais pas en train de mélanger avec l'ancien modèle de développement de GTK+ par hasard? Celui qu'ils sont justement en train de remplacer… :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
On parle de maintenance par version, pas par logiciel (quelle idée étrange. Je crois pas qu'ils prévoient d'arrêter de développer GTK+ dans 3 ans! :P). Tu peux pas comparer l'âge d'un logiciel et la durée de maintenance d'une version. Par exemple pour GIMP, avec le nombre extraordinaire de développeurs qu'on a (ironie), je peux t'assurer que notre maintenance d'une version s'arrête dès qu'on sort la version suivante. Par exemple GIMP 2.6 a cessé d'être maintenue à la sortie de 2.8 (je pense, j'y étais pas, mais en tous cas on touche pas à la 2.6 depuis des années. Moi j'y ai jamais touché). Et 2.8 cessera d'être maintenu probablement à la sortie de 2.10, ou peu après (mais sûrement pas 3 ans).
La seule raison pour laquelle cette durée reste longue dans le cas de GIMP, c'est qu'on met trop de temps à sortir les nouvelles versions (pour la même raison de peu de développeurs). :-/
C'est un peu comme si on te demandait de faire des corrections de bug sur des versions anciennes de Newton Adventure. Tu accepteras (peut-être?) de backporter certaines corrections (si tu dois aussi les faire sur la dernière version notamment, mais des fois le bug n'apparaît que sur les vieilles versions donc c'est potentiellement des heures de travail qui n'ont même pas d'incidence sur la version en cours), mais jusqu'à un certain point, j'imagine. Ton temps est quand même limité. Enfin je sais pas exactement quel est ton modèle de développement et peut-être acceptes-tu de corriger des bugs sur des versions de plus de 3 ans (bug qui potentiellement ne touche pas ta dernière version)? :-)
Ceux qui peuvent se permettre plus sont les logiciels avec plus de développeurs, notamment payés, comme GTK+ (et 3 ans, c'est vraiment pas mal). Même le noyau linux, leurs versions long-terme de plus longue durée sont seulement de 6 ans en ce moment (la version 3.2 jusqu'à 2018 et 3.16 jusqu'à 2020). Il est d'ailleurs intéressant de voir qu'ils ont des versions prévues avec "seulement" 2 ans de maintenance et qu'ils qualifient aussi de long-terme (la 4.1 dans le lien donné).
Conclusion: 3 ans minimum par défaut par version de GNOME, ça me paraît vraiment pas si mal que ça! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Puisque tu as l'air de suivre plus en détail les changements de GTK
Je ne suis pas particulièrement GTK+. J'ai découvert pas mal de choses en lisant des posts parce que j'ai participé à la dépêche. Et aussi avec le fait d'avoir été au GUADEC.
est-ce qu'il prévoient encore de gros changements d'APIs et/ou de comportement pour la suite (GTK4, 5, 6, …) ou bien est-ce que les APIs de base vont tendre vers une stabilisation générale?
C'est pas qu'ils prévoient des changements d'APIs ou de comportements. Dit comme ça, on dirait presque que ça veut dire "yeah on va tout casser juste pour embêter les gens". ;-P
C'est simplement que les technologies évoluent, ainsi que les développeurs. Un exemple classique, c'est de faire une erreur conceptuelle. Cela ne rend pas une API forcément inutilisable pour autant, mais ça peut la rendre limitée, chiante à utiliser, voire aberrante (dans certains cas, mais pas d'autres peut-être, ce qui peut expliquer l'erreur car le dév n'a pas vu le problème immédiatement). Tout développeur est tombé sur ce type d'API un jour dans une librairie ou une autre. Ben un changement de version majeure est l'occasion pour casser ce type d'API et les rendre plus logique et utilisable.
Et puis tout simplement, faut bien suivre les technologies. Dans ce genre de librairies, les APIs sont en générale suffisamment abstraites pour qu'un changement de technologie sous-jacente (on va penser au passage de X à Wayland par exemple, mais y a aussi plein d'autres technologies qui sont des briques essentielles de GTK+) ne change pas ces dernières. Mais encore une fois, le monde n'est pas parfait, et il est possible que des points de l'interface doivent être légèrement adaptées.
En gros, vouloir une stabilité totale, ce serait un peu une lubie avec un librairie aussi étendue (c'est à dire qui touche tant de sujet, donc tant de technologies) que GTK+. Du moins si on veut vivre avec son temps et faire évoluer la librairie.
Ensuite je ne doute pas une seconde que les dévs ne vont pas s'amuser à tout changer tout le temps. Ils ne le feront que lorsque cela s'avèrera nécessaire.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
AMHA ce qui pose problème (la disparition des fichiers) c'est le coté hybride. Tout gérer par fichiers arborescents sauf dans certains endroits.
En fait je vois 2 choses qui gênent vraiment:
Le changement d'applications
Ce n'est pas problématique de savoir où sont ses photos par exemple du moment qu'un autre logiciel puisse aussi les utiliser et en plus sans perte de fonctionnalité (cad si c'était de la gestion par tags, etc. on veut retrouver ses tags dans l'autre logiciel). Dans les faits, ce n'est souvent pas le cas et on le voit bien sous Android: des photos faites dans un logiciel "caméra" ne sont pas forcément visible dans un autre logiciel "caméra". C'est pénible de devoir naviguer entre les logiciels pour retrouver une photo (je connais des gens qui utilisent plusieurs logiciels de caméra parce qu'ils proposent des filtres différents, etc.).
Ceci implique d'avoir un standard de gestion des images qui serait alors commun à tout logiciel de gestion des images et permettrait donc de passer d'une appli à l'autre sans avoir à "bouger" des données d'une application à l'autre, donc sans connaissance interne des fichiers. Mais il y a toujours des limites ici aussi, car un standard implique aussi de prendre en compte les spécificités d'un type de fichier donc il faut un standard par type de fichiers: un standard pour les images, un pour les films, un pour la musique, un pour les livres, un pour les documents comptables, un pour ceci, un pour cela… or il y a toujours un type de document trop spécifique car il existe tellement de spécialités donc de types de fichier incongru. Gérer des standards de "où et comment on range tel type de fichier" devient une liste de standards qui grandit à l'infini et avec laquelle il faut toujours se mettre à jour.
La sauvegarde/Le déplacement de fichiers
Le truc classique, on a des images sur son portable, on veut les mettre sur l'ordinateur. Par exemple en branchant un smartphone, l'ordi propose souvent l'import d'images automatique, qui est totalement dans l'esprit "disparition du concept de fichiers". Mais dans le portable, y a aussi des vidéos. Il faut donc un import des vidéos séparés. Et y a d'autres types de fichiers qu'on a pu recevoir par email ou autre. Faut donc des imports pour eux aussi.
Au final, on se retrouve avec le problème des standards, mais c'est pire car on peut pas se permettre de passer 10 heures à lancer 100 types d'import pour être sûr de tout récupérer. C'est un cas typique où on veut (au moins: je veux) pouvoir naviguer un peu plus librement dans l'arborescence car on se rappelle plus trop quel type de fichiers on a bien pu amasser. À ce moment là, comme l'arborescence a été entièrement construite par plein de logiciels, on se rend compte le bordel avec plein de répertoires aux noms incongrus car automatiquement générés, et on a du mal à retrouver les vrais données.
J'ai eu le cas encore y a quelques jours pour essayer de retrouver des vidéos dans le smartphone de quelqu'un.
En tous cas, c'est une idée intéressante et je sais bien que c'est là où on se dirige. Mais c'est assez complexe et y a vraiment plein de choses à prendre en considération avant que tout cela soit fait bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ceci dit je reste persuadé que du point de vue applications utilisatrices, 2 ans c'est trop court.
La maintenance est de 3 ans minimum, cf. la dépêche (basée sur le post officiel). Ensuite on peut faire plus long, mais il y a toujours des limites en particulier financières, car même s'il y a pas mal de contributeurs payés, ce n'est pas encore au niveau du noyau par exemple; et surtout pour qu'il puisse y avoir une version "long terme", il faut en général qu'il y ait au moins une entreprise intéressée et qui paye donc un mainteneur pour cela. Donc quand GNOME deviendra plus répandu (je trouve personnellement que c'est sur la bonne pente. De plus en plus d'entreprises basent leurs produits sur GNOME, comme RedHat ou Endless; des grosses entreprises travaillent notamment avec GNOME, comme Pixar), ce n'est pas impossible qu'il y ait des gens intéressés par des versions long terme de GTK+.
Mais pour l'instant, 3 ans ("minimum" en plus, donc ça peut être plus au cas par cas), c'est quand même pas mal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je crois que la logique actuelle est de s'éloigner des icônes partout, pour tout. C'est joli, coloré (ou pas), mais ça aide pas beaucoup à la compréhension au final, surtout avec des actions compliquées. Il y a des cas où c'est utile, pour des questions de place dans l'UI notamment, mais parfois cela porte surtout à confusion (qui ne s'est jamais demandé "à quoi peut bien servir cette icône dans un logiciel?" et être obligé de tester pour comprendre?). Le texte par contre ne porte jamais (ou plus rarement en tous cas) à confusion.
Alors quand y a déjà du texte de toutes façons (comme dans un menu), la question est aussi: l'icône apporte-t-elle quelque chose de plus? Ou bien ne fait-elle que prendre de l'espace?
Pour la même raison, les boutons qui ont du texte n'ont plus l'icône à côté par défaut (en gros, c'est soit texte, soit icône, mais les deux ensemble, ça sert pas à grand chose).
Sans compter aussi l'effet "PlaySchool" que peut donner un logiciel quand y a des icônes partout.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ok ben je ne savais pas qu'il y avait cette fonctionnalité dans X, mais donc elle est désactivée par défaut dans toutes les distributions? Je ne l'ai jamais vécue (et on utilise des tablettes, etc.) donc je suppose que c'est le cas. Or une fonction désactivée partout (et pire pas activable facilement, en tous cas, je ne crois pas avoir jamais vu une telle option dans un panneau de configuration d'un quelconque système Linux), c'est comme si cela n'existe pas malheureusement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Hmm… c'est moi qui suis coupable de ce mot là. Ensuite perso je l'utilise aussi pour des choses. D'ailleurs le Wiktionnaire a plusieurs définitions, dont une générique: "Qui est sujet à tourner, à changer."
Bon ceci dit, on peut changer. Dans tes 2 propositions, "variés" serait plus le sens. Le fait est que les tablettes ont parfois des boutons, parfois non, parfois à gauche ou à droite (en fait souvent on peut tourner la tablette ou simplement bouger les boutons, lié à un mode "ambidextre"), parfois en haut (j'ai une vieille bamboo avec boutons en haut), avec un nombre indéfini, des fonctions le plus souvent indéfinies aussi, et des formes variées (bouton simple, roue…).
Alors qu'une souris, dans 99% des cas, c'est un bouton à droite, un à gauche, et en général une roulette (voire un bouton pour de vieux modèles) au milieu. Le tout a des fonctions assez définis par l'usage commun depuis pas mal d'années maintenant. Et basta!
C'était là le sens que je donnais à "versatile".
Bon peut-être que "polyvalents" marche aussi ceci dit. Je vois que Zenitram le propose aussi plus bas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
un antivol bluetooth pour vélo ( on serre les freins si l'association est perdue )
C'est pas super dangereux ça? J'imagine bien le truc avec le portable qui tombe en rade de batterie en plein virage, ou autre situation délicate. Et même sans portable qui s'arrête, le bluetooth est pas forcément la technologie la plus fiable. Je ne miserai pas une fonctionnalité si dangereuse (gestion des freins) sur la présence d'une connexion bluetooth.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est tout à fait vrai, c'est la chose qui m'a le plus surpris cette année et ce n'est pas juste en comparant au GUADEC de 2015. Il y avait d'autres évenements plus ou moins libres cet été et bien que de renommés bah, c'était pas ça, le GUADEC 2016 était pour moi le meilleur.
Je peux pas comparer avec d'autres GUADECs, mais c'est vrai certaines autres confs où je vais (que je citerai pas, je veux pas pointer du doigt), les enregistrements sont finalement publiés genre 6 mois plus tard… et encore c'est quand ils le sont. Certains évènements, on nous promet des enregistrements qui viennent jamais (ou sont perdus, ou je-ne-sais-quoi). Souvent aussi, y a des problèmes (matériels, mais aussi beaucoup humains) pendant la conf, ce qui fait que tout ou partie d'une conf n'est pas filmée. Etc.
Ici, y a vraiment eu un sans-faute.
Comment avez-vous réussi à avoir le support/soutien du CCC?
C'est pas moi, j'y suis pour rien! :P
Plus sérieusement, faudrait demander à des gens plus proches de l'organisationnel, et je pense même que ça doit être les organisateurs locaux qui ont dû trouvé.
Ensuite le CCC fait pas mal d'autres confs (suffit de regarder le site pour voir qu'y a un peu de tout) donc à mon avis, du moment que c'est du logiciel libre, s'ils ont des gens libres à ces dates, ils seraient probablement OK. Par contre, faut bien voir que le CCC est basé en Allemagne et le C3VOC (le groupe qui fait les captations vidéos) sort quasi jamais de l'Allemagne (cf. encore le site: la dernière news annonce leur présence en Grande Bretagne, expliquant que ce sera leur première fois en dehors de la zone germanophone européenne). Je pense que ce serait surtout ça le bloqueur dans plein de cas.
ps: bon je vais passer sur Endless forking Linux, ça va m'énerver. :p
Je connais pas cette affaire mais bon… je vais pas demander parce que je veux pas t'énerver! ;-)
Ceci dit, s'ils ont une version locale qu'ils utilisent le temps que leur patchs soient intégrés upstream par exemple, ça me choquerait pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ok je me rends bien compte que c'est un peu une remarque en demi-blague, mais je marche dedans quand même: ta proposition n'a pas du tout la simplicité du "je suis dans mon FS 'cloud', je veux partager un fichier quelconque avec un tel qui est sur un autre serveur (voire avec un autre logiciel), je sélectionne puis 'partage avec un tel', et il reçoit automatiquement une notification qu'on lui partage un fichier, et s'il accepte, le dit fichier apparaît dans son FS de manière transparente".
C'est l'histoire d'un clic du côté envoyeur et un clic côté receveur. Outre la simplicité, y a aussi la permission fine des utilisateurs admis (en lecture seule ou en écriture), etc.
Le fait est que j'utilise pas ça beaucoup entre serveurs (car même si OwnCloud/NextCloud commencent à se répandre, c'est pas non plus le truc que tout le monde a) — si ce n'est jamais (la seule fois, c'était justement pour tester, entre mon compte sur le serveur LILA et celui sur le serveur GNOME) — mais dans l'idée, si un tel protocole d'échanges entre serveurs distants peut se répandre (non seulement avec OwnCloud/NextCloud mais aussi avec les autres logiciels similaires) en standard, c'est génial. Par contre j'utilise ça tout le temps entre utilisateurs du même serveur.
Enfin voilà, comparer ça à bittorrent, c'est complètement à côté de la plaque. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Surtout sait-on si les 2 implémentations prévoient de suivre un même standard (je vois qu'on parle de spéc dans l'article)? À l'heure actuelle, cela fonctionne très probablement puisque le code de base existait déjà avant le fork. Mais s'ils ne prévoient pas de suivre une spéc commune, alors cela pourrait diverger dans l'avenir.
Je pense qu'il est important de savoir que quelque soit les évolutions, le partage sera compatible. Et je parle pas seulement d'Owncloud et Nextcloud. On peut espérer un monde futur où un Nextcloud pourrait partager avec un CozyCloud par exemple. Et pourquoi pas même avec des logiciels proprio (par exemple pourquoi ne pas imaginer que Dropbox décide un jour de suivre le même standard de partage entre clouds)?
Pour moi, ça serait une révolution.
Mais sinon pour en revenir au fork Nextcloud en particulier, je serais intéressé de voir un comparatif et là où les fonctionnalités divergent. J'avoue avoir du mal à savoir qui suivre. J'utilisais OwnCloud avant le fork, et n'ai pas changé depuis car je suis vraiment dans le flou sur qui correspondra le mieux à mes attentes (maintenant ou dans le futur selon les objectifs de chaque projet).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne sais pas parler espéranto, mais ils disent que c'est un langage simple à apprendre. Le latin, c'est un langage complexe, avec du masculin, féminin et neutre (comme en français ou en allemand, c'est à dire sans forcément de logique, du moins pas évidente: pourquoi la rose est-elle féminine?), 6 cas de déclinaisons nominales et d'adjectifs, au singulier et au pluriel, et en plus avec plusieurs (5) types de noms (donc on multiplie par autant pour les terminaisons à apprendre) et 2 classes d'adjectifs, etc.
J'en ai fait (et même apprécié) suffisamment d'années pour savoir que c'est pas facile. Comme je disais, je connais pas l'espéranto et peut-être qu'ils ont tout ça aussi, mais dans ce cas, je sais pas comment ils pourraient affirmer que c'est un langage simple.
Donc je suppose que l'espéranto n'a pas toutes ces complications et alors cela répond à la question « pourquoi pas le latin? ».
Quand au critère de "langue non nationale", je suis pas sûr si le fait d'être une langue morte en fait vraiment une langue non-nationale. Perso ce n'est pas un critère primordial pour moi (j'aime bien les langues de partout avec leur côté régional, ou non, aussi), mais si ça l'est pour des gens, je doute que le latin rentre vraiment dans la catégorie non-nationale.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
P.S.: mon but n'était pas de m'énerver donc désolé. La conclusion est simplement: parlons aimablement entre humains consentants sans formules dedaigneuses sur celui en face. J'espère qu' on peut se mettre d'accord sur cette conclusion. :)
Merci!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
le montage vidéo ça n'a jamais été simple que ce soit sous linux ou même sous windows, j'ai tâté également à Première Pro, c'est également très complexe et ça rien d'intuitif et de convivial. Ca demande un certain apprentissage pour acquérir le vocabulaire et comprendre les grands principes, bref ça demande un peu d'effort au début qui peut rebuter. Comme on est dans la génération de l'immédiat et que tout doit marcher tout de suite sans effort, beaucoup préfèrent critiquer le logiciel plutôt que de se remettre en cause.
Tu réponds sérieusement cela à mon commentaire sur notre expérience avec l'édition vidéo sous Linux? Tu te rends compte de notre expérience avec la vidéo (cf. notre film en cours), en particulier celle de notre artiste en résidence, Aryeom, qui de par son âge n'a évidemment pas 30 ans d'expérience dans le domaine, mais a tout de même suivi une formation universitaire avec ce type de cursus, a manipulé pendant des années After Effects, Premiere et d'autres logiciels?
Je pense pas qu'on soit totalement à la ramasse (cf. quelques exemples, sans compter les nombreuses vidéos propriétaires qu'Aryeom a aussi faites et pour lesquelles on ne peut donc pas faire de liens).
Au final, on a choisi Blender, qui n'est pas — à mon avis — le plus intuitif des logiciels parmi ceux cités et pour lesquels on en bave aussi régulièrement. Donc pour la "génération de l'immédiat", merci de pas nous sortir ce type de poncif. Franchement question remise en cause, je sais pas qui de nous ou de toi a le plus de boulot (dans ton cas, pas à propos d'utilisation de logiciels, mais de la façon dont tu considères des gens que tu ne connais même pas).
Ces logiciels dont on parle, je les ai testés. Les crashs (ou problèmes de fonctionnalités) que j'ai eu, je les ai pas inventés. Soit, c'est peut-être un mauvais paquetage. Mais il n'empêche pas que mon expérience est réelle, et qu'elle soit du fait du développement ou du paquetage, comment pouvais-je le savoir? Faut-il me cracher dessus pour autant? Tu noteras que je n'ai moi-même jamais craché sur personne, et surtout pas les développeurs avec qui j'entretiens toujours des bonnes relations (voire pourrais en devenir un très souvent, comme j'expliquais dans mon autre commentaire). Les logiciels se sont en plus probablement améliorés dernièrement comme d'autres le notent. Et donc comme je l'ai déjà dit dans mon commentaire, je souhaite tester à nouveau.
Enfin on peut parler entre nous sans être condescendant tout de même, non? Tu remarqueras que dans mon commentaire, je n'ai craché sur personne. Je continue à donner sa chance à chaque logiciel et quand quelqu'un me dit qu'un logiciel s'est amélioré, je vais prendre le temps de vérifier (même si je peux pas le faire tous les jours évidemment, y a des limites). Je rencontre très régulièrement des dévs de logiciels libres (Pitivi en particulier puisque ces derniers temps, j'ai plutôt navigué dans la communauté GNOME. Je ne crois pas avoir jamais rencontré les dévs Kdenlive mais le ferais avec plaisir si l'occasion s'en présentait) et je leur dis mes critiques en face (mais de manière saine, constructive et polie, pas en leur sortant un poncif sur leur génération ou sur la façon dont je suppose qu'ils pensent ou qu'ils devraient se remettre en cause), on en parle calmement et on s'aime bien (moi je les aime bien en tous cas). Pas d'animosité et pas de condescendance. Tout le monde fait ce qu'il peut, et eux aussi.
Ce serait bien que tu en fasses autant envers nous quand on discute sur un site web et qu'en plus, on se connaît pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
La mauvaise image des logiciels de montage vidéo vient trop souvent de package mal ficelé, mal compilé et instable, packagé par des personnes qui ne font pas de montage vidéo et qui sont incapables de les tester. J'ai toujours recompilé toutes les bibliothèques et softs de montage vidéo, et je n'ai aucun problème de plantage ou de fonctionnalités qui ne marchent pas.
C'est possible. Mais il est difficile de dire cela à n'importe qui: "quoi tu compiles pas tes logiciels? Mais c'est pour ça que ça marche pas!"
Je suis capable de compiler des logiciels, J'ai plus d'une trentaine de dépôts de source sur mon ordi (c'est à dire dont j'ai au moins vérifié le code une fois suite à un problème, voire auquel j'ai fini par contribuer + une dizaine de logiciel "stables" (pas des dépôts, mais des versions) que j'ai compilés puis installés pour une raison ou une autre. Mais ça ne veut absolument pas dire que je considère cela comme "tout va bien, c'est ainsi que doivent être les choses". Non dans l'idéal, j'ai pas à me faire chier, j'installe un super prog en double cliquant et j'en suis super content. Et si quelqu'un se plaint d'un programme, je vais sûrement pas lui conseiller de le compiler lui-même comme "la chose à faire".
En plus quand tu parles de vidéo "familiale", j'aimerais bien voir la famille de non-développeurs à qui tu dis: mais si le montage sous Linux, c'est nickel, faut juste compiler! Le gars qui vous dit que la route est longue dit n'importe quoi!
Les deux logiciels que tu cites sont en plus problématiques à compiler, kdenlive car il a plein de dépendances (que tu n'as pas forcément quand tu n'es pas sous KDE), donc faut aussi compiler à la main toutes les dépendances? Quant à Cinerella, je l'avais compilé à une époque, mais j'en avais chié. D'ailleurs celui-ci, y a vraiment pas le choix, car il n'est plus dispo en paquet sur la plupart des distributions depuis des années.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Comme j'expliquais lors de notre conf au GUADEC au sujet de ZeMarmot, l'édition vidéo est clairement le gros chaînon manquant dans la création multimédia sous Linux. Je ne trouve en effet rien de bien ni pour l'édition pro (besoin de fonctionnalité avancée et d'une UI performante) ni pour l'édition de loisir (un logiciel simple pour faire des choses simples: vidéos de vacances, comme tu dis).
Nous utilisons Blender VSE (qui rentre dans la catégorie pro car il est vraiment très puissant et plutôt stable, par contre ça pêche par l'UI et les détails). Sinon on m'a dit — il y a peu — que Kdenlive s'est beaucoup amélioré. C'était déjà (de mémoire) le plus stable des 3 gros (Pitivi, Openshot et Kdenlive), mais il avait des problèmes fonctionnels qui le rendaient inutilisable pour notre cas d'usage. J'ai pu constaté il y a quelques jours (par un court test de quelques minutes) que cela s'était en effet amélioré (sur au moins un point qui posait problème). J'y rejetterai donc un œil à nouveau, plus en détail, pour sûr.
Mais dans tous les cas, clairement c'est loin d'être rose.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En fait j'ai acheté sur ebay mais le vendeur était en effet une boutique chinoise et j'ai pu ainsi recycler un écran de portable pour une trentaine de dollars que je peux utiliser aussi bien en HDMI qu'en DVI ou VGA (y a tous les ports).
Alors je sais que ça ne répond pas à ta demande car tu cherches justement une alternative mais c'est histoire de dire que j'en suis assez content et je le referai si j'ai à nouveau un portable qui me lâche dont je veux récupérer l'écran. Je préfèrerais aussi que ce soit tout en OpenHardware et que je puisse aller me bricoler moi-même une entrée dans un hackerpace local. Mais j'ai pas le savoir suffisant en électronique ni les manuels/plans électroniques des composants des portables que j'achète.
Pour info, c'est ce que j'ai acheté. Au cas où c'est pas clair, j'ai aucun lien avec le vendeur et je n'ai eu qu'un unique achat avec ce dernier, mais ça s'est bien passé. En gros, la procédure, c'est de lui dire de quel écran il s'agit avant d'acheter (la référence exacte est sur l'écran lui-même, visible après avoir démonté l'ordi portable), et s'il confirme qu'il peut faire (étape qui peut être évitée si l'écran est dans la liste sur le site), alors tu payes, tu reçois ta carte, et y a plus qu'à la monter en quelques secondes. Je l'avais même contacté après coup quand j'étais pas sûr de comment la monter et il m'a aimablement répondu. Tout s'est bien passé.
Maintenant j'ai un écran décroché que je peux mettre dans un sac à dos et balade dans des évènements et salons quand je veux montrer des choses (en général avec un raspberry pi). Et c'est presque chiant car beaucoup de geeks sont plus intéressés par cet étonnant montage que par ce qui est montré dans l'écran. :-D
En tous cas, si tu trouves l'alternative DIY (pour les non-électroniciens, donc ça doit être sous une forme de plan tout fait par exemple), je suis aussi preneur! En attendant c'est ce que j'ai trouvé de mieux pour recycler un écran de portable.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Deframatisons Internet!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Six nouveaux services chez Framasoft (30 au total). Évalué à 10.
Alors franchement je sais pas si t'as un nom de domaine, mais moi quand j'ai un nom de domaine
example.com, et que je veux y mettre un webmail pour mes adresses @example.com, je vais le mettre genre àwebmail.example.compar exemple, quoi que soit le logiciel que j'ai installé (même si je sais très bien ce que j'ai installé). Ça n'a rien à voir avec l'utilisateur "benêt". Et même si t'es doué techniquement, ça veut pas dire que tu dois absolument te rappeler le nom des logiciels. Franchement des fois, il m'arrive d'avoir un trou et de me dire "c'est quoi le nom de ce logiciel que j'utilise tout le temps?" mais ça m'empêche pas de bien l'utiliser, voire même d'y contribuer du code. Ça m'empêche pas de le lancer non plus (je lance beaucoup de logiciels par leur fonction: par exemple, je tape "news" dans l'overview de GNOME pour lancer mon lecteur de flux RSS).De même que tu pourrais être un génie en maths sans savoir même le bon nom pour les divers théorèmes (ce qui t'empêche pas de les connaître et de savoir les utiliser), ou que tu peux être bon en mécanique et réparer ta voiture sans savoir le nom des divers composants.
Connaître des noms et être "benêt" sont des notions totalement transversales.
Euh… franchement, essayer de ne pas casser une URL, c'est prendre l'utilisateur pour un benêt?
Je pense qu'y a un bon lien pour ça: Cool URIs don't change :-)
Enfin bon, non de manière générale, abstraire une "interface" à son utilisation (et non au nom technique de ce qu'il y a derrière) est une extrêmement bonne pratique, non seulement pour l'informatique, mais pour un peu tout de manière générale (du genre, faites pas un nom de recette de cuisine avec un nom d'une marque d'un des ingrédients — bon sauf si vous travaillez pour le service marketing de cette marque bien sûr. Car le jour où vous changez l'ingrédient ou la marque du fournisseur, vous aurez l'air con!).
C'est pour cela qu'en informatique, on fait souvent des wrappers autour des bibliothèques en dépendances, ce qui permet de facilement changer de dépendance au besoin (et ainsi ne pas devoir toucher 1000 endroits du code), et surtout que les APIs doivent le moins possible faire référence aux dépendances (et une URI, c'est un peu une interface applicative!).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Appimage
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 6.
Ben les trucs classiques: fichiers appdata, desktop, icône… Ce sont des détails, pourtant importants pour le confort d'utilisation au jour le jour.
En gros, le bureau a accès aux informations du logiciel. Ainsi:
Si le bureau a encore un menu avec des catégories, avec GIMP installé par flatpak, l'utilisateur pourra trouver GIMP dans son menu, sous la catégorie "Graphisme".
Si le bureau a un champs de recherche pour trouver les programmes (par exemple comme dans GNOME), taper "gimp" propose GIMP, mais aussi si je tape "photo", "dessin", "graphisme", "image" ou autres mots clés similaires. Éventuellement une courte description du logiciel sera aussi disponible.
L'icône officielle de GIMP sera associée au logiciel (dans menu ou par recherche…) et éventuellement à des fichiers (s'il n'y a pas une prévisualisation plus adaptée).
Les fichiers XCF (et éventuellement d'autres formats d'image) seront liés à GIMP par défaut: double-cliquer un fichier XCF ouvrira GIMP.
GIMP sera proposé comme logiciel alternatif pour d'autres formats qui sont pris en charge mais pour lesquels GIMP n'est pas forcément le meilleur défaut (par exemple, un jpeg, je préfère avoir un simple visionneur par défaut, mais clic droit > "Ouvrir avec une autre application" me proposera GIMP en tête).
Bien qu'installé par flatpak, et non par le gestionnaire de paquet habituel, je peux quand même voir GIMP dans mon gestionnaire de logiciel (avec sa description et des captures d'écran), le désinstaller et même le mettre à jour.
En gros, toutes ces différentes interactions avec le système rendent l'installation par flatpak transparente. Un système "un clic" sans aucune forme d'interaction avec le système, bien qu'attrayant au premier abords, si cela ne permet pas une utilisation intégrée au système, l'intérêt est fortement réduit pour utilisation quotidienne: je me vois pas devoir aller dans un répertoire quelconque, chercher une icône AppImage (ou autre format similaire) à double-cliquer pour lancer le logiciel à chaque fois que j'en ai besoin (alors que j'aurais pu passer par le mode de lancement habituel du bureau ou simplement double-cliquer mon image xcf).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Autre témoignage
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal [digression] L'Enfer de la flibuste - le récit inédit d'un pirate français. Évalué à 6.
Enfin surtout ce ne sont pas des fautes d'orthographe mais du vieux français. Un peu comme "La vie et les avantures surprenantes de Robinson Crusoe."
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Appimage
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 8.
Ce sont des technologies très récentes qui n'étaient pas prêtes. Encore à ce jour, elles en sont encore à un stade de développement, mais qui commence à peine à vraiment pousser les portes des distributions.
GNOME Software par exemple a maintenant des prises en charge de ces technologies, mais cela n'est encore disponible dans aucune distribution. Ça le sera dans Fedora 25, puis va se répandre au moins dans toutes les distributions avec bureau GNOME.
KDE est aussi en train de travailler avec flatpak. Donc on veut imaginer de similaires prises en charge au cœur du bureau KDE bientôt aussi.
Les gens de Flatpak travaillent aussi sur un concept de service de distributions d'application (Flathub) mais pareil, ce n'est pas encore là.
Enfin flatpak (tout comme Snap) sont conçus par design pour être parfaitement efficaces (niveau sécurité) avec Wayland (respectivement Mir pour Snap). À ce stade, les protections du système sont encore limités par X11.
De manière générale donc, ce sont des projets naissants et il faut s'attendre à leur véritable départ auprès du grand public d'ici 6 mois voire 1 an quand les distribs auront enfin des prises en charge, commenceront les passages à Wayland, et que de plus en plus de projets proposeront des paquets upstream pour ces nouveaux systèmes.
Donc un tel texte d'opinion qui compare ces projets en plein balbutiement à AppImage n'est absolument pas justifié. Le fait est que Flatpak et Snap sont construits avec de nouveaux paradigmes, en particulier sécurité et intégration au bureau (en tout cas pour Flatpak. Je ne sais pas le travail fait sur Snap pour l'intégration au bureau). Mais y a aussi les concepts de "dépôts" (qui permettent de la mise à jour automatique, ainsi que la recherche d'application). Etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 4. Dernière modification le 02 octobre 2016 à 12:32.
Oui. Il pourra y avoir plusieurs versions de GTK+ installées sur un système (comme actuellement GTK+2 et GTK+3). Le pkg-config des versions 3.9x sera appelé gtk+-4.0,permettant une installation en parallèle et montrant bien que les versions x.9y sont en fait des versions de développement qui visent l'API de la version x+1.
L'idée est que les applis core GNOME sont suffisamment proche de GTK+ (donc suivent le développement de près) pour les avoir suivre la version de dév (ce qui sera en gros similaire à maintenant). Alors que les applis tierces auront le choix: elles auront le droit de suivre aussi la version de dév, qui aura les nouveautés et autres trucs hype, pour le prix d'un coup de maintenance un peu plus poussée; mais elles pourront aussi se rabattre sur la version stable qui sera assurée de ne pas casser les apps.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 5.
Tout à fait. Pourquoi ça casserait? Si tu souhaites rester sur une vieille version de GTK+, tu seras juste sur une vieille version qui n'aura plus de mises-à-jour, donc pas de correction de bugs en particulier, mais c'est tout. Ça "cassera" pas, et ton application tournera toujours pareil.
Bon par contre, une distribution pourrait retirer les paquets pour une vieille version de GTK+ qui n'est plus maintenue, et si ton logiciel se base dessus, c'est problématique. Mais là encore, ce sera la même chose pour n'importe quelle autre bibliothèque en dépendance si tu souhaites absolument rester sur une vieille version.
Ta solution dans ce cas pourra être de faire un paquet indépendant qui incorpore la version adéquate, par exemple avec Flatpak.
Franchement je comprends pas ces peurs et attaques en règle de GTK+, alors que 3 ans de support par défaut (c'est à dire qu'il y aura toujours possibilité d'avoir plus pour ceux qui payent), c'est vraiment une durée très très appréciable que peu de logiciels fournissent (libres ou propriétaires d'ailleurs). Comme je l'ai dit plus bas, Qt ont la même durée pour leur version LTS par exemple.
Quand GTK+ avait un modèle de développement instable, je pouvais comprendre les critiques. Mais là ils essaient de venir sur un modèle plus stable et surtout avec une durée de maintenance très correcte. Il y a très peu de logiciels libres qui ont une maintenance aussi longue par défaut (en gros, que les autres gros). Donc franchement, je comprends plus les critiques.
Je pense que c'est au contraire à saluer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 7.
Je voulais dire GTK+, pas GNOME, bien sûr (tout le reste de mon post parlait de GTK+). C'est une erreur par amalgame!
Cette remarque m'a étonné. Je me suis demandé quel était le temps de maintenance des versions de Qt. Hop, petit coup de moteur de recherche, et je trouve donc leur version "long term support" (Qt 5.6), qui est de… 3 ans garantis! Exactement comme GTK+.
Ils précisent qu'il y aura possibilité d'acheter du support additionnel… similairement à GTK+ encore une fois (dans le cas de GTK+, ils disent de les contacter pour discuter d'une politique de backport. Je pense que cela signifie que l'approche est différente en ce sens qu'ils sont probablement pas contre un support allongé pour une entreprise qui souhaite payer un employé pour s'en occuper, ce qui est similaire au modèle du noyau par exemple; alors que le modèle Qt est annoncé comme plus entrepreneurial, il semblerait).
En gros, les deux bibliothèques ont la même durée de support, et les mêmes portes ouvertes pour les entreprises qui veulent un support allongé.
Tu ne serais pas en train de mélanger avec l'ancien modèle de développement de GTK+ par hasard? Celui qu'ils sont justement en train de remplacer… :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 8.
On parle de maintenance par version, pas par logiciel (quelle idée étrange. Je crois pas qu'ils prévoient d'arrêter de développer GTK+ dans 3 ans! :P). Tu peux pas comparer l'âge d'un logiciel et la durée de maintenance d'une version. Par exemple pour GIMP, avec le nombre extraordinaire de développeurs qu'on a (ironie), je peux t'assurer que notre maintenance d'une version s'arrête dès qu'on sort la version suivante. Par exemple GIMP 2.6 a cessé d'être maintenue à la sortie de 2.8 (je pense, j'y étais pas, mais en tous cas on touche pas à la 2.6 depuis des années. Moi j'y ai jamais touché). Et 2.8 cessera d'être maintenu probablement à la sortie de 2.10, ou peu après (mais sûrement pas 3 ans).
La seule raison pour laquelle cette durée reste longue dans le cas de GIMP, c'est qu'on met trop de temps à sortir les nouvelles versions (pour la même raison de peu de développeurs). :-/
C'est un peu comme si on te demandait de faire des corrections de bug sur des versions anciennes de Newton Adventure. Tu accepteras (peut-être?) de backporter certaines corrections (si tu dois aussi les faire sur la dernière version notamment, mais des fois le bug n'apparaît que sur les vieilles versions donc c'est potentiellement des heures de travail qui n'ont même pas d'incidence sur la version en cours), mais jusqu'à un certain point, j'imagine. Ton temps est quand même limité. Enfin je sais pas exactement quel est ton modèle de développement et peut-être acceptes-tu de corriger des bugs sur des versions de plus de 3 ans (bug qui potentiellement ne touche pas ta dernière version)? :-)
Ceux qui peuvent se permettre plus sont les logiciels avec plus de développeurs, notamment payés, comme GTK+ (et 3 ans, c'est vraiment pas mal). Même le noyau linux, leurs versions long-terme de plus longue durée sont seulement de 6 ans en ce moment (la version 3.2 jusqu'à 2018 et 3.16 jusqu'à 2020). Il est d'ailleurs intéressant de voir qu'ils ont des versions prévues avec "seulement" 2 ans de maintenance et qu'ils qualifient aussi de long-terme (la 4.1 dans le lien donné).
Conclusion: 3 ans minimum par défaut par version de GNOME, ça me paraît vraiment pas si mal que ça! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 4.
Je ne suis pas particulièrement GTK+. J'ai découvert pas mal de choses en lisant des posts parce que j'ai participé à la dépêche. Et aussi avec le fait d'avoir été au GUADEC.
C'est pas qu'ils prévoient des changements d'APIs ou de comportements. Dit comme ça, on dirait presque que ça veut dire "yeah on va tout casser juste pour embêter les gens". ;-P
C'est simplement que les technologies évoluent, ainsi que les développeurs. Un exemple classique, c'est de faire une erreur conceptuelle. Cela ne rend pas une API forcément inutilisable pour autant, mais ça peut la rendre limitée, chiante à utiliser, voire aberrante (dans certains cas, mais pas d'autres peut-être, ce qui peut expliquer l'erreur car le dév n'a pas vu le problème immédiatement). Tout développeur est tombé sur ce type d'API un jour dans une librairie ou une autre. Ben un changement de version majeure est l'occasion pour casser ce type d'API et les rendre plus logique et utilisable.
Et puis tout simplement, faut bien suivre les technologies. Dans ce genre de librairies, les APIs sont en générale suffisamment abstraites pour qu'un changement de technologie sous-jacente (on va penser au passage de X à Wayland par exemple, mais y a aussi plein d'autres technologies qui sont des briques essentielles de GTK+) ne change pas ces dernières. Mais encore une fois, le monde n'est pas parfait, et il est possible que des points de l'interface doivent être légèrement adaptées.
En gros, vouloir une stabilité totale, ce serait un peu une lubie avec un librairie aussi étendue (c'est à dire qui touche tant de sujet, donc tant de technologies) que GTK+. Du moins si on veut vivre avec son temps et faire évoluer la librairie.
Ensuite je ne doute pas une seconde que les dévs ne vont pas s'amuser à tout changer tout le temps. Ils ne le feront que lorsque cela s'avèrera nécessaire.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: éditeur pour publication scientifique/technique avec licence libre
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Le Frido, un livre de mathématique libre pour l’agrégation. Évalué à 2.
Y a pas Oreilly aussi qui a publié régulièrement des ouvrages techniques aussi dispos sur le net sous des licences libres?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: icones
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 8.
En fait je vois 2 choses qui gênent vraiment:
Le changement d'applications
Ce n'est pas problématique de savoir où sont ses photos par exemple du moment qu'un autre logiciel puisse aussi les utiliser et en plus sans perte de fonctionnalité (cad si c'était de la gestion par tags, etc. on veut retrouver ses tags dans l'autre logiciel). Dans les faits, ce n'est souvent pas le cas et on le voit bien sous Android: des photos faites dans un logiciel "caméra" ne sont pas forcément visible dans un autre logiciel "caméra". C'est pénible de devoir naviguer entre les logiciels pour retrouver une photo (je connais des gens qui utilisent plusieurs logiciels de caméra parce qu'ils proposent des filtres différents, etc.).
Ceci implique d'avoir un standard de gestion des images qui serait alors commun à tout logiciel de gestion des images et permettrait donc de passer d'une appli à l'autre sans avoir à "bouger" des données d'une application à l'autre, donc sans connaissance interne des fichiers. Mais il y a toujours des limites ici aussi, car un standard implique aussi de prendre en compte les spécificités d'un type de fichier donc il faut un standard par type de fichiers: un standard pour les images, un pour les films, un pour la musique, un pour les livres, un pour les documents comptables, un pour ceci, un pour cela… or il y a toujours un type de document trop spécifique car il existe tellement de spécialités donc de types de fichier incongru. Gérer des standards de "où et comment on range tel type de fichier" devient une liste de standards qui grandit à l'infini et avec laquelle il faut toujours se mettre à jour.
La sauvegarde/Le déplacement de fichiers
Le truc classique, on a des images sur son portable, on veut les mettre sur l'ordinateur. Par exemple en branchant un smartphone, l'ordi propose souvent l'import d'images automatique, qui est totalement dans l'esprit "disparition du concept de fichiers". Mais dans le portable, y a aussi des vidéos. Il faut donc un import des vidéos séparés. Et y a d'autres types de fichiers qu'on a pu recevoir par email ou autre. Faut donc des imports pour eux aussi.
Au final, on se retrouve avec le problème des standards, mais c'est pire car on peut pas se permettre de passer 10 heures à lancer 100 types d'import pour être sûr de tout récupérer. C'est un cas typique où on veut (au moins: je veux) pouvoir naviguer un peu plus librement dans l'arborescence car on se rappelle plus trop quel type de fichiers on a bien pu amasser. À ce moment là, comme l'arborescence a été entièrement construite par plein de logiciels, on se rend compte le bordel avec plein de répertoires aux noms incongrus car automatiquement générés, et on a du mal à retrouver les vrais données.
J'ai eu le cas encore y a quelques jours pour essayer de retrouver des vidéos dans le smartphone de quelqu'un.
En tous cas, c'est une idée intéressante et je sais bien que c'est là où on se dirige. Mais c'est assez complexe et y a vraiment plein de choses à prendre en considération avant que tout cela soit fait bien.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK+4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 7.
La maintenance est de 3 ans minimum, cf. la dépêche (basée sur le post officiel). Ensuite on peut faire plus long, mais il y a toujours des limites en particulier financières, car même s'il y a pas mal de contributeurs payés, ce n'est pas encore au niveau du noyau par exemple; et surtout pour qu'il puisse y avoir une version "long terme", il faut en général qu'il y ait au moins une entreprise intéressée et qui paye donc un mainteneur pour cela. Donc quand GNOME deviendra plus répandu (je trouve personnellement que c'est sur la bonne pente. De plus en plus d'entreprises basent leurs produits sur GNOME, comme RedHat ou Endless; des grosses entreprises travaillent notamment avec GNOME, comme Pixar), ce n'est pas impossible qu'il y ait des gens intéressés par des versions long terme de GTK+.
Mais pour l'instant, 3 ans ("minimum" en plus, donc ça peut être plus au cas par cas), c'est quand même pas mal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: icones
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 3.
Ça fait déjà un bout de temps que les icônes dans les menus ont été dépréciés.
Tu peux trouver une méthode ici pour les récupérer si tu veux absolument des icônes partout. En espérant pour toi que cette méthode marche toujours (le lien date de 2013):
https://ask.fedoraproject.org/en/question/23116/how-to-fix-missing-icons-in-program-menus-and-context-menus/
Je crois que la logique actuelle est de s'éloigner des icônes partout, pour tout. C'est joli, coloré (ou pas), mais ça aide pas beaucoup à la compréhension au final, surtout avec des actions compliquées. Il y a des cas où c'est utile, pour des questions de place dans l'UI notamment, mais parfois cela porte surtout à confusion (qui ne s'est jamais demandé "à quoi peut bien servir cette icône dans un logiciel?" et être obligé de tester pour comprendre?). Le texte par contre ne porte jamais (ou plus rarement en tous cas) à confusion.
Alors quand y a déjà du texte de toutes façons (comme dans un menu), la question est aussi: l'icône apporte-t-elle quelque chose de plus? Ou bien ne fait-elle que prendre de l'espace?
Pour la même raison, les boutons qui ont du texte n'ont plus l'icône à côté par défaut (en gros, c'est soit texte, soit icône, mais les deux ensemble, ça sert pas à grand chose).
Sans compter aussi l'effet "PlaySchool" que peut donner un logiciel quand y a des icônes partout.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pointeurs multiples
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 5.
Salut,
Ok ben je ne savais pas qu'il y avait cette fonctionnalité dans X, mais donc elle est désactivée par défaut dans toutes les distributions? Je ne l'ai jamais vécue (et on utilise des tablettes, etc.) donc je suppose que c'est le cas. Or une fonction désactivée partout (et pire pas activable facilement, en tous cas, je ne crois pas avoir jamais vu une telle option dans un panneau de configuration d'un quelconque système Linux), c'est comme si cela n'existe pas malheureusement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Proposition de correction
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GNOME 3.22 Karlsruhe : A Land Far, Far Away. Évalué à 2. Dernière modification le 29 septembre 2016 à 12:33.
Hmm… c'est moi qui suis coupable de ce mot là. Ensuite perso je l'utilise aussi pour des choses. D'ailleurs le Wiktionnaire a plusieurs définitions, dont une générique: "Qui est sujet à tourner, à changer."
Bon ceci dit, on peut changer. Dans tes 2 propositions, "variés" serait plus le sens. Le fait est que les tablettes ont parfois des boutons, parfois non, parfois à gauche ou à droite (en fait souvent on peut tourner la tablette ou simplement bouger les boutons, lié à un mode "ambidextre"), parfois en haut (j'ai une vieille bamboo avec boutons en haut), avec un nombre indéfini, des fonctions le plus souvent indéfinies aussi, et des formes variées (bouton simple, roue…).
Alors qu'une souris, dans 99% des cas, c'est un bouton à droite, un à gauche, et en général une roulette (voire un bouton pour de vieux modèles) au milieu. Le tout a des fonctions assez définis par l'usage commun depuis pas mal d'années maintenant. Et basta!
C'était là le sens que je donnais à "versatile".
Bon peut-être que "polyvalents" marche aussi ceci dit. Je vois que Zenitram le propose aussi plus bas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: mes projets des années précedentes
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à 6.
C'est pas super dangereux ça? J'imagine bien le truc avec le portable qui tombe en rade de batterie en plein virage, ou autre situation délicate. Et même sans portable qui s'arrête, le bluetooth est pas forcément la technologie la plus fiable. Je ne miserai pas une fonctionnalité si dangereuse (gestion des freins) sur la présence d'une connexion bluetooth.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: C'est vrai!
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Compte rendu de GUADEC 2016. Évalué à 3.
Je peux pas comparer avec d'autres GUADECs, mais c'est vrai certaines autres confs où je vais (que je citerai pas, je veux pas pointer du doigt), les enregistrements sont finalement publiés genre 6 mois plus tard… et encore c'est quand ils le sont. Certains évènements, on nous promet des enregistrements qui viennent jamais (ou sont perdus, ou je-ne-sais-quoi). Souvent aussi, y a des problèmes (matériels, mais aussi beaucoup humains) pendant la conf, ce qui fait que tout ou partie d'une conf n'est pas filmée. Etc.
Ici, y a vraiment eu un sans-faute.
C'est pas moi, j'y suis pour rien! :P
Plus sérieusement, faudrait demander à des gens plus proches de l'organisationnel, et je pense même que ça doit être les organisateurs locaux qui ont dû trouvé.
Ensuite le CCC fait pas mal d'autres confs (suffit de regarder le site pour voir qu'y a un peu de tout) donc à mon avis, du moment que c'est du logiciel libre, s'ils ont des gens libres à ces dates, ils seraient probablement OK. Par contre, faut bien voir que le CCC est basé en Allemagne et le C3VOC (le groupe qui fait les captations vidéos) sort quasi jamais de l'Allemagne (cf. encore le site: la dernière news annonce leur présence en Grande Bretagne, expliquant que ce sera leur première fois en dehors de la zone germanophone européenne). Je pense que ce serait surtout ça le bloqueur dans plein de cas.
Je connais pas cette affaire mais bon… je vais pas demander parce que je veux pas t'énerver! ;-)
Ceci dit, s'ils ont une version locale qu'ils utilisent le temps que leur patchs soient intégrés upstream par exemple, ça me choquerait pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et nextcloud ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Owncloud 9 termine sa fédération. Évalué à 4.
Ok je me rends bien compte que c'est un peu une remarque en demi-blague, mais je marche dedans quand même: ta proposition n'a pas du tout la simplicité du "je suis dans mon FS 'cloud', je veux partager un fichier quelconque avec un tel qui est sur un autre serveur (voire avec un autre logiciel), je sélectionne puis 'partage avec un tel', et il reçoit automatiquement une notification qu'on lui partage un fichier, et s'il accepte, le dit fichier apparaît dans son FS de manière transparente".
C'est l'histoire d'un clic du côté envoyeur et un clic côté receveur. Outre la simplicité, y a aussi la permission fine des utilisateurs admis (en lecture seule ou en écriture), etc.
Le fait est que j'utilise pas ça beaucoup entre serveurs (car même si OwnCloud/NextCloud commencent à se répandre, c'est pas non plus le truc que tout le monde a) — si ce n'est jamais (la seule fois, c'était justement pour tester, entre mon compte sur le serveur LILA et celui sur le serveur GNOME) — mais dans l'idée, si un tel protocole d'échanges entre serveurs distants peut se répandre (non seulement avec OwnCloud/NextCloud mais aussi avec les autres logiciels similaires) en standard, c'est génial. Par contre j'utilise ça tout le temps entre utilisateurs du même serveur.
Enfin voilà, comparer ça à bittorrent, c'est complètement à côté de la plaque. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et nextcloud ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Owncloud 9 termine sa fédération. Évalué à 7.
Surtout sait-on si les 2 implémentations prévoient de suivre un même standard (je vois qu'on parle de spéc dans l'article)? À l'heure actuelle, cela fonctionne très probablement puisque le code de base existait déjà avant le fork. Mais s'ils ne prévoient pas de suivre une spéc commune, alors cela pourrait diverger dans l'avenir.
Je pense qu'il est important de savoir que quelque soit les évolutions, le partage sera compatible. Et je parle pas seulement d'Owncloud et Nextcloud. On peut espérer un monde futur où un Nextcloud pourrait partager avec un CozyCloud par exemple. Et pourquoi pas même avec des logiciels proprio (par exemple pourquoi ne pas imaginer que Dropbox décide un jour de suivre le même standard de partage entre clouds)?
Pour moi, ça serait une révolution.
Mais sinon pour en revenir au fork Nextcloud en particulier, je serais intéressé de voir un comparatif et là où les fonctionnalités divergent. J'avoue avoir du mal à savoir qui suivre. J'utilisais OwnCloud avant le fork, et n'ai pas changé depuis car je suis vraiment dans le flou sur qui correspondra le mieux à mes attentes (maintenant ou dans le futur selon les objectifs de chaque projet).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: un beau combat... d'un autre siècle
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche État de l’espéranto sous GNU/Linux. Évalué à 7.
Je ne sais pas parler espéranto, mais ils disent que c'est un langage simple à apprendre. Le latin, c'est un langage complexe, avec du masculin, féminin et neutre (comme en français ou en allemand, c'est à dire sans forcément de logique, du moins pas évidente: pourquoi la rose est-elle féminine?), 6 cas de déclinaisons nominales et d'adjectifs, au singulier et au pluriel, et en plus avec plusieurs (5) types de noms (donc on multiplie par autant pour les terminaisons à apprendre) et 2 classes d'adjectifs, etc.
J'en ai fait (et même apprécié) suffisamment d'années pour savoir que c'est pas facile. Comme je disais, je connais pas l'espéranto et peut-être qu'ils ont tout ça aussi, mais dans ce cas, je sais pas comment ils pourraient affirmer que c'est un langage simple.
Donc je suppose que l'espéranto n'a pas toutes ces complications et alors cela répond à la question « pourquoi pas le latin? ».
Quand au critère de "langue non nationale", je suis pas sûr si le fait d'être une langue morte en fait vraiment une langue non-nationale. Perso ce n'est pas un critère primordial pour moi (j'aime bien les langues de partout avec leur côté régional, ou non, aussi), mais si ça l'est pour des gens, je doute que le latin rentre vraiment dans la catégorie non-nationale.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Le chaînon manquant
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Putain que la route est longue ! ! !. Évalué à 8.
P.S.: mon but n'était pas de m'énerver donc désolé. La conclusion est simplement: parlons aimablement entre humains consentants sans formules dedaigneuses sur celui en face. J'espère qu' on peut se mettre d'accord sur cette conclusion. :)
Merci!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Le chaînon manquant
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Putain que la route est longue ! ! !. Évalué à 10. Dernière modification le 29 août 2016 à 13:34.
Tu réponds sérieusement cela à mon commentaire sur notre expérience avec l'édition vidéo sous Linux? Tu te rends compte de notre expérience avec la vidéo (cf. notre film en cours), en particulier celle de notre artiste en résidence, Aryeom, qui de par son âge n'a évidemment pas 30 ans d'expérience dans le domaine, mais a tout de même suivi une formation universitaire avec ce type de cursus, a manipulé pendant des années After Effects, Premiere et d'autres logiciels?
Je pense pas qu'on soit totalement à la ramasse (cf. quelques exemples, sans compter les nombreuses vidéos propriétaires qu'Aryeom a aussi faites et pour lesquelles on ne peut donc pas faire de liens).
Au final, on a choisi Blender, qui n'est pas — à mon avis — le plus intuitif des logiciels parmi ceux cités et pour lesquels on en bave aussi régulièrement. Donc pour la "génération de l'immédiat", merci de pas nous sortir ce type de poncif. Franchement question remise en cause, je sais pas qui de nous ou de toi a le plus de boulot (dans ton cas, pas à propos d'utilisation de logiciels, mais de la façon dont tu considères des gens que tu ne connais même pas).
Ces logiciels dont on parle, je les ai testés. Les crashs (ou problèmes de fonctionnalités) que j'ai eu, je les ai pas inventés. Soit, c'est peut-être un mauvais paquetage. Mais il n'empêche pas que mon expérience est réelle, et qu'elle soit du fait du développement ou du paquetage, comment pouvais-je le savoir? Faut-il me cracher dessus pour autant? Tu noteras que je n'ai moi-même jamais craché sur personne, et surtout pas les développeurs avec qui j'entretiens toujours des bonnes relations (voire pourrais en devenir un très souvent, comme j'expliquais dans mon autre commentaire). Les logiciels se sont en plus probablement améliorés dernièrement comme d'autres le notent. Et donc comme je l'ai déjà dit dans mon commentaire, je souhaite tester à nouveau.
Enfin on peut parler entre nous sans être condescendant tout de même, non? Tu remarqueras que dans mon commentaire, je n'ai craché sur personne. Je continue à donner sa chance à chaque logiciel et quand quelqu'un me dit qu'un logiciel s'est amélioré, je vais prendre le temps de vérifier (même si je peux pas le faire tous les jours évidemment, y a des limites). Je rencontre très régulièrement des dévs de logiciels libres (Pitivi en particulier puisque ces derniers temps, j'ai plutôt navigué dans la communauté GNOME. Je ne crois pas avoir jamais rencontré les dévs Kdenlive mais le ferais avec plaisir si l'occasion s'en présentait) et je leur dis mes critiques en face (mais de manière saine, constructive et polie, pas en leur sortant un poncif sur leur génération ou sur la façon dont je suppose qu'ils pensent ou qu'ils devraient se remettre en cause), on en parle calmement et on s'aime bien (moi je les aime bien en tous cas). Pas d'animosité et pas de condescendance. Tout le monde fait ce qu'il peut, et eux aussi.
Ce serait bien que tu en fasses autant envers nous quand on discute sur un site web et qu'en plus, on se connaît pas.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Le chaînon manquant
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Putain que la route est longue ! ! !. Évalué à 7.
C'est possible. Mais il est difficile de dire cela à n'importe qui: "quoi tu compiles pas tes logiciels? Mais c'est pour ça que ça marche pas!"
Je suis capable de compiler des logiciels, J'ai plus d'une trentaine de dépôts de source sur mon ordi (c'est à dire dont j'ai au moins vérifié le code une fois suite à un problème, voire auquel j'ai fini par contribuer + une dizaine de logiciel "stables" (pas des dépôts, mais des versions) que j'ai compilés puis installés pour une raison ou une autre. Mais ça ne veut absolument pas dire que je considère cela comme "tout va bien, c'est ainsi que doivent être les choses". Non dans l'idéal, j'ai pas à me faire chier, j'installe un super prog en double cliquant et j'en suis super content. Et si quelqu'un se plaint d'un programme, je vais sûrement pas lui conseiller de le compiler lui-même comme "la chose à faire".
En plus quand tu parles de vidéo "familiale", j'aimerais bien voir la famille de non-développeurs à qui tu dis: mais si le montage sous Linux, c'est nickel, faut juste compiler! Le gars qui vous dit que la route est longue dit n'importe quoi!
Les deux logiciels que tu cites sont en plus problématiques à compiler, kdenlive car il a plein de dépendances (que tu n'as pas forcément quand tu n'es pas sous KDE), donc faut aussi compiler à la main toutes les dépendances? Quant à Cinerella, je l'avais compilé à une époque, mais j'en avais chié. D'ailleurs celui-ci, y a vraiment pas le choix, car il n'est plus dispo en paquet sur la plupart des distributions depuis des années.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Le chaînon manquant
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Putain que la route est longue ! ! !. Évalué à 10.
Comme j'expliquais lors de notre conf au GUADEC au sujet de ZeMarmot, l'édition vidéo est clairement le gros chaînon manquant dans la création multimédia sous Linux. Je ne trouve en effet rien de bien ni pour l'édition pro (besoin de fonctionnalité avancée et d'une UI performante) ni pour l'édition de loisir (un logiciel simple pour faire des choses simples: vidéos de vacances, comme tu dis).
Nous utilisons Blender VSE (qui rentre dans la catégorie pro car il est vraiment très puissant et plutôt stable, par contre ça pêche par l'UI et les détails). Sinon on m'a dit — il y a peu — que Kdenlive s'est beaucoup amélioré. C'était déjà (de mémoire) le plus stable des 3 gros (Pitivi, Openshot et Kdenlive), mais il avait des problèmes fonctionnels qui le rendaient inutilisable pour notre cas d'usage. J'ai pu constaté il y a quelques jours (par un court test de quelques minutes) que cela s'était en effet amélioré (sur au moins un point qui posait problème). J'y rejetterai donc un œil à nouveau, plus en détail, pour sûr.
Mais dans tous les cas, clairement c'est loin d'être rose.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# J'ai acheté sur "les sites chinois".
Posté par Jehan (site web personnel, Mastodon) . En réponse au message Open Hardware / standard LVDS / écran. Évalué à 4.
En fait j'ai acheté sur ebay mais le vendeur était en effet une boutique chinoise et j'ai pu ainsi recycler un écran de portable pour une trentaine de dollars que je peux utiliser aussi bien en HDMI qu'en DVI ou VGA (y a tous les ports).
Alors je sais que ça ne répond pas à ta demande car tu cherches justement une alternative mais c'est histoire de dire que j'en suis assez content et je le referai si j'ai à nouveau un portable qui me lâche dont je veux récupérer l'écran. Je préfèrerais aussi que ce soit tout en OpenHardware et que je puisse aller me bricoler moi-même une entrée dans un hackerpace local. Mais j'ai pas le savoir suffisant en électronique ni les manuels/plans électroniques des composants des portables que j'achète.
Pour info, c'est ce que j'ai acheté. Au cas où c'est pas clair, j'ai aucun lien avec le vendeur et je n'ai eu qu'un unique achat avec ce dernier, mais ça s'est bien passé. En gros, la procédure, c'est de lui dire de quel écran il s'agit avant d'acheter (la référence exacte est sur l'écran lui-même, visible après avoir démonté l'ordi portable), et s'il confirme qu'il peut faire (étape qui peut être évitée si l'écran est dans la liste sur le site), alors tu payes, tu reçois ta carte, et y a plus qu'à la monter en quelques secondes. Je l'avais même contacté après coup quand j'étais pas sûr de comment la monter et il m'a aimablement répondu. Tout s'est bien passé.
Maintenant j'ai un écran décroché que je peux mettre dans un sac à dos et balade dans des évènements et salons quand je veux montrer des choses (en général avec un raspberry pi). Et c'est presque chiant car beaucoup de geeks sont plus intéressés par cet étonnant montage que par ce qui est montré dans l'écran. :-D
En tous cas, si tu trouves l'alternative DIY (pour les non-électroniciens, donc ça doit être sous une forme de plan tout fait par exemple), je suis aussi preneur! En attendant c'est ce que j'ai trouvé de mieux pour recycler un écran de portable.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]