Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

A new application for Framaspace : OwnershipTransfer

Par : Framasoft
10 septembre 2024 à 06:38

Still more features on Framaspace ? Yes ! At the moment, we’re spoiling the users of this service, with the integration of quite a few features like the Forms and Tables applications, but also the ‘Intros’ app developed by Val, our summer intern. And because it’s Val, it’s festival (shameful rhyme !) : just before leaving us for a well-deserved holiday and a final year of studies, he delivered a new ‘Ownership Transfer’ application that will make life easier for administrators of Framaspace spaces.

 

 

Hi Val, we’re not going to ask you to introduce yourself, as you already did in the previous interview. We’ll just remind you that you’re doing an internship at Framasoft from the beginning of May to the end of August 2024, with the aim of developing tools to support Framaspace, and therefore Nextcloud free software.

Hi ! Check out my previous interview to find out more about me ! I introduce Intros, a Nextcloud app to help users get to grips with Framaspace.

At the end of the interview, I mentioned I was working on another Nextcloud app, OwnershipTransfer. Back then things were only getting started, but I cooked, and now it’s ready.

OK, so let’s talk about the OwnershipTransfer App. What’s it for ? Who is the target audience ?

As mentioned in the previous article, OwnershipTransfer makes it possible to transfer data from one user to another in Nextcloud. For example, when someone leaves an association that uses Nextcloud (say, on Framaspace 😏), it can be useful to move their files to another user before deleting their account. You could avoid losing important archives, invoices… The same goes for calendars or address books.

Well worry no more, OwnershipTransfer (or « OT » from now on in this article) does all that. It allows Nextcloud admins to transfer data from whoever to whoever. Initially mostly designed for files, I extended it to calendars and contacts transfer.

OT allows a transfer of all the data, but also a more fine-grained choice. One can choose the calendar, address book or folder they want to transfer, so they don’t end up with someone’s holidays pictures in their files.

Screenshot of Ownership Transfer (also available in English) Screenshot of Ownership Transfer (also available in English)

 

But… didn’t this feature already exist in Nextcloud ?

It did, but not the way we wanted it to.

Nextcloud already allows transferring your own files to another user, with a small graphical interface in the user settings section. You can only transfer your own files to another user, but not choose a source user : this isn’t suitable for an instance admin who would want to move files from one user to another.

An instance admin can also transfer files or calendars from one user to another, with an OCC command. OCC is Nexctloud’s CLI, via which admins can handle some server settings. You can only use it from the command line in a terminal, which to most human beings is… cryptical.

In short there are existing working solutions, but not with a simple graphical interface for admins. This is especially an issue in « Nextcloud farms » (an organization hosting Nextcloud instances for a lot of clients at once) like Framaspace, because admins don’t have access to the CLI in this case.

 

Technically, how does it work ?

Since it’s integrated with other Nextcloud apps, OT is heavily relying on existing Nextcloud APIs. The app also uses adapted parts of Nextcloud’s code. For example, I use the code from the existing files transfer feature, which I modified to fit with our requirements. The same goes for the calendar transfer.

However, I add to implement the contacts transfer, since it is not available in Nextcloud (not even through a cryptic CLI). It looks a lot like the calendar transfer, since both of them are based on the WebDAV protocol, so I had an example to work with.

The interface is built with Nextcloud’s Vue components, of course. They are pretty pleasant to use, and new ones are often released. It allowed me to build a complete graphical interface in no time, while staying consistent with the rest of Nextcloud’s UI.

 

Have you encountered any technical or organisational problems ?

Since Nextcloud’s documentation hasn’t miraculously grown since last time, I had to wander around in Nextcloud’s source code to find the functions needed. I could almost make a hobby out of that. Almost.

At least the features exist in Nextcloud already, so adapting them wasn’t the most difficult thing ever. I could also rely on tcit’s advice, co-director of Framasoft and Nextcloud contributor. In short : I write code, he looks at it, says « cool thing, but not scalable », and I correct it.

Scalability was the most common problem. It always works on my small test environment with 5 accounts and 7 folders, but it should also (and most importantly) work on big Nextcloud instances with lots of files. For example, the files transfer can take a lot of time and resources : it has to move all the files from the source to the destination folder, which takes more or less time depending on the amount of files to move and the underlying storage type. Because of that, it is handled in the background : instead of launching it upon receiving the request, it is placed in a jobs queue that the server periodically handles.

Calendar and contacts transfers do not have this issue : they only consist of a simple SQL query to change the right property on the right element. This operation is fast, so it can be handled in the foreground.

Besides the actual transfer, building the interface was also challenging. The app allows the admin to choose which element will be transferred, so they need an interface to choose it. For calendars and contacts, it’s fairly simple : with Nextcloud’s components, I could easily build a list of calendars or address books. But for files, things are getting complicated : we need a whole tree-style view to show the subfolders’ content.

Luckily, I’ve got back up. Romain, former fellow INSA Lyon student (in Telecom, just like me !) and former Framasoft intern, worked on Sorts a few years ago. The goal was to make an app to enhance Nextcloud’s file search, mostly with filters. And Sorts has something I was really interested in : a tree-style files view. Exactly what I needed.

Interface de Sorts avec l'arborescence de fichiers Interface adaptée à OT pour choisir le dossier à transférer

After a few tweaks here and there in Sorts’ code, which wasn’t necessarily easy, its tree-style view perfectly integrated with OwnershipTransfer. It helped a lot and saved a lot of dev time, and I could even improve it a bit with some lines to better view the current folder and some sharing icons.

 

Now that your internship is coming to an end, and you’ve been « eating » some Nextcloud for the past 6 months, what are your potential takes on this software ?

It’s rant time !

Anyways, besides the rant and all the things I could blame on Nextcloud (like its lightweight documentation, its occasional slowness or its imperfect UI), its a very functional software, and it’s all that matters for pretty much everyone. It could be better (and it’s already happening !), but I find it to be working just fine for most typical usages. I’ve been using it for 2 years on a Raspberry PI to backup my files and photos, and I’ve never had any major issues with it.

However, its collaborative features can definitely get better (things like multiple people writing on the same text or calc document at the same time), especially since they are very popular among the people who use Nextcloud. These features exist, but they are typically hard to use, especially the first time, and poorly optimized. So when I see Nextcloud bragging about how they now have AI integrated (which I think most people don’t find that useful anyway), while opening a shared file sometimes still causes a mess… I think they could focus on more important things. But I guess you do need something to make it look shiny.

 

We’ve been very very pleased and satisfied to work with you over the last few months ! Any final words ?

I was delighted to work at Framasoft ! I’ve learned a lot through this internship, and I want to thank the association again for its welcoming and comfortable working conditions.

Right now it’s time to relax, for me at least (before going to « class » again, but don’t mention it), and then to go back to work on my final internship at the beginning of next year ! I’m just saying, of course ;)

 


Main links for Ownership Transfer :

Une nouvelle application pour Framaspace : OwnershipTransfer

Par : Framasoft
10 septembre 2024 à 06:37

Encore des nouveautés sur Framaspace ? Et oui ! En ce moment, on gâte les utilisateur⋅ices de ce service, avec l’intégration de pas mal de fonctionnalités comme les applications Forms et Tables, mais aussi l’app « Intros » qu’a développée Val, notre stagiaire estival (rime riche !). Et comme c’est Val, c’est festival (rime honteuse !) : juste avant de nous quitter pour des vacances bien méritées et une dernière année d’études, il nous a livré une nouvelle application « Ownership Transfer » qui facilitera la vie des administrateur⋅ices d’espaces Framaspace.

An English version of this interview is available at : https://framablog.org/2024/09/10/a-new-application-for-framaspace-ownershiptransfer

 

Bonjour Val, on ne va pas te proposer de te présenter, car tu l’as déjà fait dans la précédente interview. On rappellera juste que tu es en stage à Framasoft de début mai à fin août 2024, avec pour objectif de développer des outils d’accompagnement à Framaspace, et donc au logiciel libre Nextcloud.

Salut ! N’hésitez pas à aller lire ma précédente interview pour en savoir plus sur moi ! J’y parle d’Intros, une application pour faciliter la prise en main de Framaspace.

A la fin de l’interview, je parle d’une autre application Nextcloud sur laquelle je travaillais, OwnershipTransfer. À l’époque c’était encore en cours de préparation, mais depuis j’ai cuisiné, et maintenant c’est prêt.

 

OK, donc, parlons de l’App Ownership Transfer. À quoi sert-elle ? Quel est le public visé ?

Comme indiqué dans l’article précédent, OwnershipTransfer sert à transférer des données d’un⋅e utilisateurice à l’autre dans Nextcloud. Par exemple, lorsqu’une personne quitte une association qui utilise du Nextcloud (sur Framaspace, au hasard 😏), il peut être bien pratique de transférer ses fichiers avant de supprimer son compte. Cela permet d’éviter de perdre des archives importantes, des factures,… De même pour ses agendas, ou même ses carnets d’adresses.

Ça tombe bien, OwnershipTransfer (qu’on abrégera par la suite « OT ») fait tout ça. Elle permet aux administrateur⋅ices d’un espace Nextcloud de transférer les données de n’importe qui vers n’importe qui. À l’origine surtout destinée au transfert de fichiers, j’ai pu étendre l’application au transfert d’agendas et de contacts.

OT permet de transférer toutes les données d’une application, mais aussi de choisir plus finement ce qui devra être transféré. On peut ainsi choisir l’agenda, le carnet d’adresse ou un dossier à transférer, pour éviter de se retrouver avec les photos de vacances de quelqu’un d’autre dans ses fichiers.

Capture écran d'Ownership Transfer Capture écran d'Ownership Transfer

 

Mais… cette possibilité n’existait pas déjà dans Nextcloud ?

Si, mais pas exactement comme on le voulait.

Nextcloud permet déjà de transférer ses propres fichiers à une autre personne, via une petite interface graphique dans les paramètres utilisateurs. On peut là uniquement transférer ses propres fichiers vers un autre utilisateur, mais pas choisir l’utilisateur source : ce n’est pas une solution pour les admins d’espace qui voudraient transférer des fichiers d’une personne à une autre.

Un⋅e administrateurice d’espace peut aussi transférer des fichiers ou des agendas d’un⋅e utilisateur⋅ice à un⋅e autre, via une commande « OCC ». OCC est la CLI de Nextcloud, via laquelle les admins peuvent lancer diverses opérations de maintenance ou de management. On y accède donc en ligne de commande via le terminal uniquement, ce qui a de quoi repousser la plupart des êtres vivants sur cette planète.

En bref cette solution fonctionne, mais ne propose pas d’interface graphique simple aux admins. Cela pose problème dans le cas de « fermes à Nextcloud » (une organisation qui héberge des instances Nextcloud pour beaucoup de clients d’un coup) comme Framaspace, dans lesquelles les administrateur⋅ices d’un espace n’ont pas accès à la ligne de commande.

 

Techniquement, comment ça marche ?

Comme elle s’intègre avec d’autres applications, OT se base essentiellement sur des APIs existantes de Nextcloud. L’application réutilise aussi des parties du code de Nextcloud que j’ai adaptées aux besoins de l’application. Par exemple, je réutilise le code de transfert de ses propres fichiers, en l’adaptant pour pouvoir choisir à la fois l’utilisateur⋅ice source et destinataire. De même pour le transfert d’agendas.

J’ai par contre dû implémenter le transfert de contacts, non disponible dans Nextcloud par défaut. Il est cependant très similaire au transfert d’agendas, dont je me suis inspiré, puisque les deux se basent sur le protocole WebDAV.

Pour l’affichage, j’utilise bien sûr les composants Vue proposés par Nextcloud. Leurs composants sont assez complets et agréables à utiliser, et ils en sortent de nouveaux régulièrement. Cela m’a permis de réaliser une interface graphique complète en peu de temps, et cohérente avec le reste du logiciel.

 

Tu as rencontré des soucis, qu’ils soient techniques, organisationnels, etc ?

La documentation de Nextcloud n’ayant pas miraculeusement centuplé en taille depuis la dernière fois, j’ai encore dû fouiller dans le code source de Nextcloud pour aller trouver les fonctions à utiliser. Ça commencerait presque à me plaire. Presque.

Mème d'un Val (avec quelques années de plus) face la (non) doc de Nextcloud.

Mème d’un Val (avec quelques années de plus) face à la (non) doc de Nextcloud.

 

Au moins, comme les fonctionnalités existaient déjà en partie dans Nextcloud, les adapter n’a pas été d’une difficulté monstre. Surtout que j’ai pu beaucoup compter sur les conseils de Tcit, codirecteur de Framasoft et contributeur bénévole de Nextcloud. En gros : j’écris du code, il le regarde, il se dit « Cool, mais ça passe pas à l’échelle ton truc », et puis je corrige.

C’était le problème la plupart du temps, le passage à l’échelle. C’est bien beau quand ça fonctionne sur mon petit environnement de test à 5 comptes et 7 dossiers, mais dans l’idéal il faut aussi que ça fonctionne sur les grosses instances Nextcloud avec beaucoup de fichiers. Par exemple, le transfert de fichiers peut prendre beaucoup de temps et de ressources : il faut déplacer tous les fichiers du dossier source vers la destination, ce qui peut être plus ou moins long en fonction de la quantité de fichiers et du type de stockage. Celui-ci est donc géré en fond : au lieu de l’exécuter au premier plan dès la réception de la requête, il est placé dans une file de « jobs » que le serveur effectue périodiquement.

Les transferts de contacts et d’agendas n’ont pas le même problème : il s’agit dans leur cas d’une simple requête SQL qui vient modifier la propriété de l’élément en question. Cette opération est rapide, et peut donc être exécutée au premier plan.

Outre le transfert en soi, réaliser l’interface a aussi été un vrai défi. L’application doit permettre à l’administrateurice de choisir quel élément doit être transféré, et doit donc lui proposer une interface pour faire son choix. Pour les agendas et les contacts, c’est plutôt simple : avec les composants de Nextcloud, j’ai pu facilement faire une liste d’agendas ou de carnets d’adresses. Pour les fichiers, ça se complexifie : il faut récréer une arborescence complète de fichiers, capable d’afficher des sous-dossiers.

Heureusement, un « insalien » n’est jamais seul. Romain, ancien étudiant INSA Lyon (du département Télécom, comme moi !) et ancien stagiaire à Framasoft, a travaillé il y a quelques années sur l’application Sorts. Le but de Sorts est d’améliorer la recherche de fichiers de Nextcloud, en proposant une recherche avec des filtres notamment. Mais Sorts a surtout quelque chose qui m’intéressait : une arborescence de fichiers en arbre. Pile ce qu’il me fallait.

Sorts interface with tree directory Sorts Interface adapted to OT for choosing the file to be transferred

Après avoir récupéré et adapté le code de Sorts, ce qui n’était pas forcément de tout repos, son arborescence s’intégrait parfaitement à OwnershipTransfer. Cela m’a permis de gagner beaucoup de temps de développement, et j’ai même pu apporter des améliorations, comme les lignes qui mettent mieux en évidence l’arborescence, ou les icônes de partage. Pas mal non ? C’est insalien 😎

Mème « Pas mal non ? C'est insalien »

Mème « Pas mal non ? C’est insalien »

 

Maintenant que ton stage s’achève, et après avoir « mangé » du Nextcloud pendant près de 6 mois, quels sont tes potentiels positionnements sur ce logiciel ?

Ah, c’est le moment où je râle !

Non blague à part, malgré toutes les critiques que je pourrais faire sur Nextcloud (notamment sa documentation légère, sa lenteur occasionnelle ou son interface qui laisse parfois à désirer), le logiciel est fonctionnel, et franchement c’est tout ce qui compte pour la plupart des gens. Des améliorations sont possibles (et sont en cours !), mais je le trouve déjà assez opérationnel pour la plupart des besoins que peuvent avoir ses utilisateur⋅ices. Je l’utilise personnellement depuis 2 ans sur ma Raspberry PI pour stocker mes fichiers, et je n’ai jamais eu de problème majeur avec.

Le logiciel peut par contre s’améliorer sur ses aspects collaboratifs, qui sont très demandés par les utilisateur⋅ices (écrire à plusieurs sur un fichier texte ou calc par exemple). Ces fonctionnalités existent, mais sont souvent encore difficiles à prendre en main et peu optimisées. Du coup, quand je les vois se vanter d’intégrer de l’IA au logiciel (alors que franchement, je pense que pour beaucoup ça n’a que très peu d’utilité) alors même que quand on ouvre un fichier texte en collaboratif c’est parfois encore le bordel… je me dis qu’ils pourraient mieux diriger leurs efforts. Mais bon, faut bien des annonces pour faire vendre.

 

Nous avons été très heureux⋅ses et satisfait⋅es de travailler avec toi pendant ces quelques mois ! Un dernier mot pour la fin ?

J’ai été très heureux de travailler à Framasoft ! Ce stage a été très enrichissant pour moi, et je remercie encore l’association pour son accueil et ses conditions de travail au top. Si les sujets que j’aborde dans cet article vous intéressent et que vous cherchez un stage dégooglisé, je vous encourage à venir à Framasoft (promis le dev Nextcloud c’est pas si terrible en vrai). Sinon, vous pouvez toujours faire un don !

Maintenant c’est l’heure des vacances pour moi (puis des « cours », mais ne le dites pas trop fort), puis de mon stage de fin d’études en début d’année prochaine. Je glisse ça là, au cas où ;)

Merci et bonne continuation, Val !


Pour information, si vous êtes étudiant⋅e, que vous aimez Nextcloud, et que ce genre de sujet de stage vous intéresse (de préférence à Lyon pour faciliter l’encadrement, mais télétravail possible), n’hésitez pas à nous envoyer rapidement une candidature spontanée sur stages @ framasoft.org !

Une « édition » minable de Pepper & Carrot sur Amazon

Par : Framalang
10 avril 2023 à 05:42

Depuis quelques années, Framasoft bénéficie des illustrations très appréciées de David Revoy, un artiste qui séduit autant par son talent et son imaginaire que par le choix de publier en licence libre (CC-BY), ce qui est plutôt exceptionnel dans le monde de la bande dessinée. La licence qu’il a choisie autorise à :

  • Partager — copier, distribuer et communiquer le matériel par tous moyens et sous tous formats
  • Adapter — remixer, transformer et créer à partir du matériel, y compris pour un usage commercial.

La seule condition impérative est l’Attribution

Attribution — Vous devez créditer l’Œuvre, intégrer un lien vers la licence et indiquer si des modifications ont été effectuées à l’œuvre. Vous devez indiquer ces informations par tous les moyens raisonnables, sans toutefois suggérer que l’Offrant vous soutient ou soutient la façon dont vous avez utilisé son Œuvre.

assortie d’une interdiction :

Pas de restrictions complémentaires — Vous n’êtes pas autorisé à appliquer des conditions légales ou des mesures techniques qui restreindraient légalement autrui à utiliser l’œuvre dans les conditions décrites par la licence.

Comme on peut le lire plus haut et comme le précise David lui-même dans sa F.A.Q, ce n’est pas parce que la licence est libre que l’on peut se servir sans scrupules des œuvres et du nom de l’auteur :

Ce n’est pas parce que vous pouvez réutiliser mes œuvres que je suis d’accord avec ce que vous faites, ou que je peux être considéré comme un auteur actif de votre projet, surtout si mon nom est écrit comme une signature de votre dérivation ou si vous réutilisez mon nom pour dire à votre public que je suis « d’accord » avec votre projet. Cela ne fonctionne pas comme ça. Restez simple : communiquez la vérité,

C’est justement ces précautions et ce respect élémentaires que n’ont pas pris les éditeurs (méritent-ils ce nom ?) d’une publication dérivée de Pepper & Carrot (déjà 37 épisodes traduits en 63 langues !) et qui est en vente sur Amazon, plateforme bien connue pour ses pratiques commerciales éthiques (non)…

Alors David, d’ordinaire si aimable, se fâche tout rouge et relève toutes les pratiques complètement hors-pistes de Fa Comics, dans l’article ci-dessous publié sur son blog et traduit pour vous par Framalang…


Article original de David Revoy sur son blog : Fa Bd Comics books on SCAMazon : don’t buy them

Traduction Framalang : GPSqueek, Sysy, Poca, goofy, macrico

N’achetez pas les BD des éditions Fa Bd sur SCAMazon

par David Revoy

On atteint un record : avec la communauté de Pepper & Carrot, nous avons trouvé Fa Bd, l’éditeur du pire dérivé de Pepper & Carrot à ce jour.

Malheureusement, les produits sont publiés sous mon nom et aussi sous le nom d’artistes qui ont réalisé des fan-arts de Pepper & Carrot… Voilà pourquoi j’écris cet article, histoire de décrire un peu cette arnaque et ce carnage de la publication assistée par ordinateur qui se perpétue actuellement sur Amazon, et aussi pour dissuader le public de Pepper & Carrot de les acheter.

Accrochez-vous, car nous entrons dans le territoire du zéro absolu de la qualité, des horreurs du graphisme, des cauchemars de la colorimétrie et de l’affreuse mise en page.

Les trois albums

Un grand merci à Craig Maloney qui a acheté les trois albums pour que nous puissions évaluer leur qualité. Il a également réalisé toutes les photos que vous trouverez ici et a écrit des commentaires sur Amazon sous les albums afin d’avertir d’autres clients potentiels de leur piètre qualité.

1. Héritage

Lien vers Amazon : https://www.amazon.com/Heritage-David-Revoy/dp/B0BS1ZHM9T/

Il s’agit d’une version imprimable datant de décembre 2022 de mon webcomic (épisode unique) L’héritage en couleur publié en mai 2012 sous la licence Creative Commons Attribution 4.0 International.

 

Mes observations :

(1) bien que la couverture soit correcte, l’impression gâche totalement l’histoire elle-même : le concept de cette bande dessinée est la représentation en couleurs des sentiments du personnage principal, pourtant l’éditeur a décidé d’imprimer l’histoire complète en noir et blanc. Cela rend le tout le récit illisible et dénué de sens. Essayez de lire l’original et demandez-vous ce que vaut la bande dessinée en noir et blanc. Apparemment, c’est assez bon pour être publié de cette façon par les éditions FA Bd Comics…

(2) L’attribution est là mais l’éditeur FA BD comics n’indique pas son rôle. Et attendez, une adresse courriel Caramail ? Je croyais qu’ils avaient disparu il y a 20 ans 1. Je n’aime pas la façon dont mon crédit et mon nom sur la couverture et la page produit donnent l’impression que j’ai approuvé cette publication et que j’y ai collaboré. Il ne s’agit pas d’une « violation d’approbation » explicite, mais j’ai honte de voir mon nom figurer sur ces pages.

(3) L’éditeur a oublié une page dans l’histoire : l’avant-dernière… ce qui fait que ça casse encore plus l’histoire. Et pour remplir la fin du livre, des parties aléatoires du making of ont été téléchargées et déversées comme ça sans aucun avertissement, juste après la fin de l’histoire.

Davantage de photos ici.

2. Les histoires de Pepper & Carrot

Lien vers Amazon : https://www.amazon.com/Pepper-Carrot-Novels-David-Revoy/dp/B09ZZVJLDT/

Description : Il s’agit d’une compilation imprimable datant de mai 2022 d’un mélange de Fan-art de Pepper&Carrot contenant des bulles de texte et de BD Fan-art de Pepper & Carrot.

Mes observations :

(1) Mon nom figure en haut de la couverture, alors qu’aucune illustration de moi ne figure sur cet album. C’est très problématique, car même si j’apprécie beaucoup le fan-art d’étude de Pepper envoyé par Coyau en 2015 parce que c’était parmi les premiers fan-arts que j’ai reçus sur Pepper & Carrot, je ne pense pas que Coyau s’attendait à ce qu’il soit utilisé comme œuvre d’art/visuel/illustration pour la couverture.

(2) Même si tous les fan-arts sont correctement attribués à leur auteur, l’éditeur a mal lu une information importante sur Pepper & Carrot : l’auteur du fan-art peut mettre son œuvre sous la licence qu’il souhaite. Et sauf mention explicite, ils sont tous protégés par le droit d’auteur. C’est écrit clairement dans la case « Licence » de chaque fan-art sur le site. « Cette image est un fan-art réalisé par <nom de l’auteur>. Elle est affichée sur la galerie de fan-arts de Pepper & Carrot avec sa permission. Ne réutilisez pas cette image pour votre projet sans l’autorisation de l’auteur ». L’éditeur, sur les crédits de son album, assume « basé sur le même personnage avec la même licence ». C’est faux et abusif. Notez également que l’email de l’éditeur change sur ces crédits, et que la ligne « œuvre de fiction » de Héritage est également présente… Boulot de copier-coller vite fait et négligent détecté !

(3) Les fan-arts sont imprimés en noir et blanc. Il n’y a pas d’indication permettant de savoir qui, parmi la liste des auteurs, a dessiné quelle page, et il n’y a pas de mise en page. Les dessins sont simplement collés sur la page avec de grands espaces vides, même lorsque la police est trop petite. Notez que le contraste est également faible. Ce n’est pas du tout respectueux des créations artistiques.

Davantage de photos ici.

3. Pepper & Carrot Mini

Lien vers Amazon : https://www.amazon.com/Pepper-Carrot-Mini-Nicolas-Artance/dp/B0BHMPMM14/

Il s’agit d’une publication papier d’octobre 2010 de la série Pepper & Carrot Mini par Nicolas Artance. Nicolas Artance est l’un des principaux contributeurs et modérateurs de la communauté Pepper & Carrot, et joue un rôle important dans la version française de la série principale. Il publie sa série sous Creative Commons Attribution 4.0 International et partage également les sources complètes.

Mes observations :

(1) La couverture ne provient pas de Pepper & Carrot Mini, elle n’a pas été réalisée par Nicolas Artance ni par moi-même, mais c’est un fan-art de Tessou. Il y a donc un problème de copyright puisque le dessin de Tessou n’est pas publié sous la licence de Pepper & Carrot. La couverture contient également trois noms et il est difficile de savoir qui fait quoi ou qui soutient quoi. Sur le produit Amazon, nous sommes co-auteur avec Nicolas… Quel bazar !

(2) Même mensonge que pour l’album précédent à propos de la licence du fan-art, et une grosse faute de frappe dans le nom de Nicolas (Nocolas). Apparemment, cet éditeur n’a aucun correcteur et s’en moque.

(3) La qualité, la mise en page… Tout est imprimé en noir et blanc et en faible contraste. Les planches en paysage sont « adaptées à la largeur » de la page. Certaines polices sont à peine lisibles.

Davantage de photos ici.

Et maintenant ?

Tout d’abord, vous pouvez aider : si vous avez un compte Amazon [NdT : il faut un compte sur Amazon.com, ça ne marchera pas depuis un compte Amazon.fr], vous pouvez simplement cliquer sur le bouton « Utile » sur les commentaires de Craig sur chaque livre 1, 2 et 3. Ce n’est pas grand-chose, mais cela aidera probablement les acheteurs potentiels à passer leur chemin en voyant l’avis 1 étoile.

Je n’ai clairement pas la charité de penser que cet éditeur souffre juste d’incompétence flagrante et qu’il essaie simplement d’aider l’impression d’œuvres culturelles libres. Ils ne m’ont jamais contacté, ils n’ont jamais contribué à l’écosystème Pepper&Carrot pour autant que je sache, et ils ont juste fait un produit de la plus basse qualité avec peu d’efforts sur une place de marché où il n’y a aucun contrôle sur la qualité.

C’est hors de prix et le fait de voir ce niveau d’irrespect pour mon art et pour l’industrie du livre est clairement ce qui affecte mon humeur. Je ne pense pas que ce produit dérivé soit d’un grand secours. S’il vous plaît, FA Bd Comic ou Amazon : si vous lisez ceci, retirez ces produits dès que possible.

De mon côté, je vais essayer de les contacter tous les deux pour qu’ils retirent les albums. Ils ont tous trop de problèmes pour être en ligne, y compris des problèmes de copyright. J’écrirai toute mise à jour ultérieure sous cette rubrique. En attendant, ne les achetez pas !

 

Mises à jour

A. 2023-03-28, 01:20am : J’ai pris le temps de faire un rapport officiel pour violation de copyright sur Amazon. Je vous informerai de l’issue de ce rapport.

B. 2023-03-28, 01:00pm : J’ai reçu ma réponse : « Nous n’avons pas été en mesure de vérifier que vous êtes le propriétaire des droits ou son agent ». (réponse automatique complète). Ok, j’abandonne…

 

Informations complémentaires sur la licence : le texte de cet article est publié sous Creative Commons Attribution 4.0. Cependant, les images de cet article sont protégées : ne les réutilisez pas : elles contiennent du fan-art, des copyrights et des marques déposées.

Google et son robot pipoteur(*), selon Doctorow

Par : Framalang
3 mars 2023 à 03:35

Source de commentaires alarmants ou sarcastiques, les robots conversationnels qui reposent sur l’apprentissage automatique ne provoquent pas seulement l’intérêt du grand public, mais font l’objet d’une course de vitesse chez les GAFAM.

Tout récemment, peut-être pour ne pas être à la traîne derrière Microsoft qui veut adjoindre un chatbot à son moteur de recherche Bing, voilà que Google annonce sa ferme résolution d’en faire autant. Dans l’article traduit pour vous par framalang, Cory Doctorow met en perspective cette décision qui lui semble absurde en rappelant les échecs de Google qui a rarement réussi à créer quoi que ce soit…

(*) Merci à Clochix dont nous adoptons dans notre titre la suggestion.

Article original : Google’s chatbot panic

Traduction Framalang : Fabrice, goofy, jums, Henri-Paul, Sysy, wisi_eu,

L’assistant conversationnel de Google en panique

par Cory Doctorow

 

Photo Jonathan Worth CC-BY-SA

 

 

Il n’y a rien d’étonnant à ce que Microsoft décide que l’avenir de la recherche en ligne ne soit plus fondé sur les liens dans une page web, mais de là à la remplacer par des longs paragraphes fleuris écrits dans un chatbot qui se trouve être souvent mensonger… — et en plus Google est d’accord avec ce concept.

Microsoft n’a rien à perdre. Il a dépensé des milliards pour Bing, un moteur de recherche que personne n’utilise volontairement. Alors, sait-on jamais, essayer quelque chose d’aussi stupide pourrait marcher. Mais pourquoi Google, qui monopolise plus de 90 % des parts des moteurs de recherche dans le monde, saute-t-il dans le même bateau que Microsoft ?

le long d'un mur de brique rouge sur lequel est suspendu un personnage ovoïde au visage très inquiet (Humpty-Dumpty le gros œuf), deux silhouettes jumelles (Tweedle-dee et Tweedle-dum les personnages de De l'autre côté du_miroir de Lewis Carroll) représentent avec leur logo sur le ventre Bing et google, chacun d'eaux a une tête qui évoque le robot Hal de 2001, à savoir une lueur rouge sur fond noir qui fait penser à un œil.

Il y a un délicieux fil à dérouler sur Mastodon, écrit par Dan Hon, qui compare les interfaces de recherche merdiques de Bing et Google à Tweedledee et Tweedledum :

https://mamot.fr/@danhon@dan.mastohon.com/109832788458972865

Devant la maison, Alice tomba sur deux étranges personnages, tous deux étaient des moteurs de recherche.
— moi, c’est Google-E, se présenta celui qui était entièrement recouvert de publicités
— et moi, c’est Bingle-Dum, fit l’autre, le plus petit des deux, et il fit la grimace comme s’il avait moins de visiteurs et moins d’occasions de mener des conversations que l’autre.
— je vous connais, répondit Alice, vous allez me soumettre une énigme ? Peut-être que l’un de vous dit la vérité et que l’autre ment ?
— Oh non, fit Bingle-Dum
— Nous mentons tous les deux, ajouta Google-E

Mais voilà le meilleur :

— Cette situation est vraiment intolérable, si vous mentez tous les deux.

— mais nous mentons de façon très convaincante, précisa Bingle-Dum

— D’accord, merci bien. Dans ce cas, comment puis-je vous faire jamais confiance ni / confiance à l’un ni/ou à l’autre ? Dans ce cas, comment puis-je faire confiance à l’un d’entre vous ?

Google-E et Bingle-Dum se tournèrent l’un vers l’autre et haussèrent les épaules.

La recherche par chatbot est une très mauvaise idée, surtout à un moment où le Web est prompt à se remplir de vastes montagnes de conneries générées via l’intelligence artificielle, comme des jacassements statiques de perroquets aléatoires :

La stratégie du chatbot de Google ne devrait pas consister à ajouter plus de délires à Internet, mais plutôt à essayer de trouver comment exclure (ou, au moins, vérifier) les absurdités des spammeurs et des escrocs du référencement.

Et pourtant, Google est à fond dans les chatbots, son PDG a ordonné à tout le monde de déployer des assistants conversationnels dans chaque recoin de l’univers Google. Pourquoi diable est-ce que l’entreprise court après Microsoft pour savoir qui sera le premier à décevoir des espérances démesurées ?

J’ai publié une théorie dans The Atlantic, sous le titre « Comment Google a épuisé toutes ses idées », dans lequel j’étudie la théorie de la compétition pour expliquer l’insécurité croissante de Google, un complexe d’anxiété qui touche l’entreprise quasiment depuis sa création :

L’idée de base : il y a 25 ans, les fondateurs de Google ont eu une idée extraordinaire — un meilleur moyen de faire des recherches. Les marchés financiers ont inondé l’entreprise en liquidités, et elle a engagé les meilleurs, les personnes les plus brillantes et les plus créatives qu’elle pouvait trouver, mais cela a créé une culture d’entreprise qui était incapable de capitaliser sur leurs idées.

Tous les produits que Google a créés en interne, à part son clone de Hotmail, sont morts. Certains de ces produits étaient bons, certains horribles, mais cela n’avait aucune importance. Google, une entreprise qui promouvait la culture du baby-foot et la fantaisie de l’usine Willy Wonka [NdT: dans Charlie et la chocolaterie, de Roald Dahl], était totalement incapable d’innover.

Toutes les réussites de Google, hormis son moteur de recherche et gmail, viennent d’une acquisition : mobile, technologie publicitaire, vidéos, infogérance de serveurs, docs, agenda, cartes, tout ce que vous voulez. L’entreprise souhaite plus que tout être une société qui « fabrique des choses », mais en réalité elle « achète des choses ». Bien sûr, ils sont très bons pour rendre ces produits opérationnels et à les faire « passer à l’échelle », mais ce sont les enjeux de n’importe quel monopole :

La dissonance cognitive d’un « génie créatif » autoproclamé, dont le véritable génie est de dépenser l’argent des autres pour acheter les produits des autres, et de s’en attribuer le mérite, pousse les gens à faire des choses vraiment stupides (comme tout utilisateur de Twitter peut en témoigner).
Google a longtemps montré cette pathologie. Au milieu des années 2000 – après que Google a chassé Yahoo en Chine et qu’il a commencé à censurer ses résultats de recherche, puis collaboré à la surveillance d’État — nous avions l’habitude de dire que le moyen d’amener Google à faire quelque chose de stupide et d’autodestructeur était d’amener Yahoo à le faire en premier lieu.

C’était toute une époque. Yahoo était désespéré et échouait, devenant un cimetière d’acquisitions prometteuses qui étaient dépecées et qu’on laissait se vider de leur sang, laissées à l’abandon sur l’Internet public, alors que les princes duellistes de la haute direction de Yahoo se donnaient des coups de poignard dans le dos comme dans un jeu de rôle genre les Médicis, pour savoir lequel saboterait le mieux l’autre. Aller en Chine fut un acte de désespoir après l’humiliation pour l’entreprise que fut le moteur de recherche largement supérieur de Google. Regarder Google copier les manœuvres idiotes de Yahoo était stupéfiant.

C’était déconcertant, à l’époque. Mais à mesure que le temps passait, Google copiait servilement d’autres rivaux et révélait ainsi une certaine pathologie d’insécurité. L’entreprise échouait de manière récurrente à créer son réseau « social », et comme Facebook prenait toujours plus de parts de marché dans la publicité, Google faisait tout pour le concurrencer. L’entreprise fit de l’intégration de Google Plus un « indictateur1 de performance » dans chaque division, et le résultat était une agrégation étrange de fonctionnalités « sociales » défaillantes dans chaque produit Google — produits sur lesquels des milliards d’utilisateurs se reposaient pour des opérations sensibles, qui devenaient tout à coup polluées avec des boutons sociaux qui n’avaient aucun sens.

La débâcle de G+ fut à peine croyable : certaines fonctionnalités et leur intégration étaient excellentes, et donc logiquement utilisées, mais elles subissaient l’ombrage des incohérences insistantes de la hiérarchie de Google pour en faire une entreprise orientée réseaux sociaux. Quand G+ est mort, il a totalement implosé, et les parties utiles de G+ sur lesquelles les gens se reposaient ont disparu avec les parties aberrantes.

Pour toutes celles et ceux qui ont vécu la tragi-comédie de G+, le virage de Google vers Bard, l’interface chatbot pour les résultats du moteur de recherche, semble tristement familier. C’est vraiment le moment « Mourir en héros ou vivre assez longtemps pour devenir un méchant ». Microsoft, le monopole qui n’a pas pu tuer la jeune pousse Google à cause de son expérience traumatisante des lois antitrust, est passé d’une entreprise qui créait et développait des produits à une entreprise d’acquisitions et d’opérations, et Google est juste derrière elle.

Pour la seule année dernière, Google a viré 12 000 personnes pour satisfaire un « investisseur activiste » privé. La même année, l’entreprise a racheté 70 milliards de dollars en actions, ce qui lui permet de dégager suffisamment de capitaux pour payer les salaires de ses 12 000 « Googleurs » pendant les 27 prochaines années. Google est une société financière avec une activité secondaire dans la publicité en ligne. C’est une nécessité : lorsque votre seul moyen de croissance passe par l’accès aux marchés financiers pour financer des acquisitions anticoncurrentielles, vous ne pouvez pas vous permettre d’énerver les dieux de l’argent, même si vous avez une structure à « double pouvoir » qui permet aux fondateurs de l’emporter au vote contre tous les autres actionnaires :

https://abc.xyz/investor/founders-letters/2004-ipo-letter/

ChatGPT et ses clones cochent toutes les cases d’une mode technologique, et sont les dignes héritiers de la dernière saison du Web3 et des pics des cryptomonnaies. Une des critiques les plus claires et les plus inspirantes des chatbots vient de l’écrivain de science-fiction Ted Chiang, dont la critique déjà culte est intitulée « ChatGPT est un une image JPEG floue du Web » :

https://www.newyorker.com/tech/annals-of-technology/chatgpt-is-a-blurry-jpeg-of-the-web

Chiang souligne une différence essentielle entre les résultats de ChatGPT et ceux des humains : le premier jet d’un auteur humain est souvent une idée originale, mal exprimée, alors que le mieux que ChatGPT puisse espérer est une idée non originale, exprimée avec compétence. ChatGPT est parfaitement positionné pour améliorer la soupe de référencement que des légions de travailleurs mal payés produisent dans le but de grimper dans les résultats de recherche de Google.

En mentionnant l’article de Chiang dans l’épisode du podcast « This Machine Kills », Jathan Sadowski perce de manière experte la bulle de la hype ChatGPT4, qui soutient que la prochaine version du chatbot sera si étonnante que toute critique de la technologie actuelle en deviendra obsolète.

Sadowski note que les ingénieurs d’OpenAI font tout leur possible pour s’assurer que la prochaine version ne sera pas entraînée sur les résultats de ChatGPT3. Cela en dit long : si un grand modèle de langage peut produire du matériel aussi bon qu’un texte produit par un humain, alors pourquoi les résultats issus de ChatGPT3 ne peuvent-ils pas être utilisés pour créer ChatGPT4 ?

Sadowski utilise une expression géniale pour décrire le problème :  « une IA des Habsbourg ». De même que la consanguinité royale a produit une génération de prétendus surhommes incapables de se reproduire, l’alimentation d’un nouveau modèle par le flux de sortie du modèle précédent produira une spirale infernale toujours pire d’absurdités qui finira par disparaître dans son propre trou du cul.

 

Crédit image (modifiée) : Cryteria, CC BY 3.0

❌
❌