liberforce a écrit 4744 commentaires

Le but était justement de continuer à faire vivre GNOME2, donc heureusement qu'ils ont tout gardé...

Je ne vois pas en quoi a répondait au problème. Les applis n'ont pas changé de manière trancendentale entre GNOME 2 et GNOME 3. C'est GNOME Shell la réelle modification de GNOME 3. Ça ne justifiait pas selon moi un fork massif.

Ils ont réussi à porter l'intégralité de leur environnement sur GTK3 plus rapidement que Xfce, donc visiblement ils ont les ressources.

Tant mieux pour eux.

Et au pire GTK2 ne m'aurait pas empêché de dormir.

Sans GTK+ 3, pas de Wayland.

Le problème de MATE ça a été l'approche "on forke tout", là où Cinnamon prenait l'approche "on forke que ce qui est nécessaire". MATE s'est retrouvé à dupliquer tout le boulot de migration à GTK+ 3, et je ne vois rien de glorieux à ça. Un projet libre a rarement assez de ressources, donc là maintenir toute la stack GNOME à eux seuls, en étant (je pense) moins nombreux, je trouve ça au mieux contre-productif, au pire néfaste pour l'utilisateur (tout un environnement de bureau à maintenir côté bugs de sécu, je pense que ça doit être un gros boulot).

À un moment il faut bien une limite, sinon pourquoi pas protester contre tous ces bureaux qui ne marchent pas sur des 386?

TL;DR: Le problème n'est pas de ne pas fonctionner, mais ne ne pas dire à l'utilisateur pourquoi ça ne fonctionne pas.

Certes, mais tu noteras qu'il y a souvent peu de "system requirements". Ceux de GNOME Shell ne sont pas clairement explicites. De plus, sur mon autre machine (AMD Athlon XP Barton 3000+), celle qui fait tourner GNOME, j'ai aussi eu d'autres soucis. J'ai voulu ripper des CD, et sound-juicer crashait systématiquement pendant l'encodage au format FLAC. La cause ? Bien que ces processeurs sont sortis à la même période que les Pentium 4, ils n'ont pas le jeu d'instructions SSE2, et la lib l'utilisait. En la recompilant, plus de soucis, et j'ai pu continuer à utiliser la même machine encore un peu.

Mais c'est parfois un peu difficile de savoir avec quelles options les distrib sont compilées. Tu as beau avoir du i{3,4,5,6}86 dans les noms de paquets, ce n'est plus vraiment représentatif dès que tu rentres dans la catégorie des "ordinosaures". Mageia (ça ne doit pas être les seuls) fournit des paquets i586, et cet identifiant correspond aux Pentium 1. Chez Ubuntu, c'est du i386. Cet identifiant ne sert plus à rien si ce n'est indiquer que c'est du x86 sur 32 bits. Tu finis donc par avoir des crash qui pourraient être évités: on sait quel matériel tu utilises, et on connait les flags utilisés pour compiler les applis, je pense qu'il y a bien moyen de faire un diagnostic pour dire ce qui pourrait coincer, ou au moins vérifier que ça correspond au moment de l'installation des paquets. Moi je peux sortir un débogueur et analyser le problème (et encore, j'avais pas fait gaffe au code renvoyé par le segfault), mais tous les utilisateurs finaux ne sont pas informaticiens.

Je veux bien qu'on ne jette pas le matériel qui marche, mais s'attendre à ce qu'une machine de 11ans d'âge fasse tourner le dernier bureau à la mode, c'est peut-être un peu optimiste!

Mon autre machine a le même âge, et ça marche. Je ne dis pas que je prends ça pour acquis, je sais bien que ce sont de vieilles configs. Si je les garde, c'est que tant que ça fait son job, et que mes besoins sur ce genre de machine sont remplis, alors pas besoin d'autre chose.

J'ai un jour vu un reportage sur des enfants en Asie qui brûlaient au briquet les cartes mères et les "sniffaient" pour savoir comment les trier pour les recycler. Je t'assure que ça soigne de toute envie d'avoir le dernier gadget à la mode. Ça ne m'empêche pas d'avoir d'autres machines, mobiles cette fois ci, mais dans tous les cas je les fais durer le plus longtemps possible. C'est à dire jusqu'à ce qu'elles tombent en panne et que je ne puisse pas les réparer ou bien quand elles ne remplissent plus mes besoins.

Pour en revenir à GNOME, j'espérais que ça tourne, mais si ça ne tourne pas parce que la machine est trop ancienne, ça me va aussi. Ce qui était plus frustrant toutefois c'était de ne pas avoir de message d'erreur clair au lancement qui m'en informe. Le comportement de base que j'ai eu, c'est la session qui tente de se lancer et qui crashe en boucle car relancé par systemd (mais c'est peut être un problème de l'intégration dans Mageia). Je savais qu'il y a le backend logiciel llvmpipe donc je pensais avoir au moins un truc très lent et qui se lance.

Peut être que la machine ira à la casse, ou peut-être que je trouverai une meilleure carte graphique d'occase en brocante ;).
À une époque j'avais recyclé un vieux PII 400MHz avec de la RAM défectueuse achetée en brocante. Une des forces du logiciel libre ça reste pour moi d'éviter l'obsolescence de matériels qui peuvent toujours servir quand c'est possible. Et puis si tout le monde faisait tourner des bêtes de course, plus personne ne ferait attention à la surconsommation de CPU ou de mémoire :)

Je ne vois pas pourquoi ton commentaire a été jugé inutile. GNOME 3 ne tourne pas sur cetaines vieilles configurations, notamment celles avec des cartes graphiques anciennes, c'est un fait. GNOME Shell exige certaines API de rendu 3D, ou sinon il ne démarrera pas. Et personne à ma connaissance ne teste le rendu software via llvmpipe.

Exemple concret: je n'ai pas réussi à lancer GNOME 3 sur un Dell Optiplex 320 équipé d'une ATI Radeon X300.

J'ai une autre machine avec une carte ATI qui arrive à faire tourner GNOME 3, mais avec un AMD Athlon XP 3000+ avec 1,5Go de RAM, ça commence à faire juste. Je ne dis pas que MATE tournerait mieux, mais GNOME 3 trouve ses limites.

Il y avait une conférence sur le sujet au FOSDEM:
https://fosdem.org/2018/schedule/event/mozilla_eu_copyright_reform_end_floss/

Je ne l'ai pas encore regardée, donc je vous laisse vous faire votre avis.

.

Avec des fichiers liés, il se retrouve lui même à gérer l'emplacement sur le système de fichier de ses images. S'il les déplace, les liens seront cassés. Pour redistribuer, il faut donner le fichier odg + les ressources. Pour des fichiers de 380 octets, on s'amuse pas à ça. Les fichiers liés sont utiles quand tu as des insertions d'éléments très lourds, pas dans ce cas précis (ou alors juste comme solution de contournement).

Je reproduis sur LibreOffice 4.2.8.2 sur Ubuntu 14.04. Donc c'est un vieux vieux bug. J'ai extrait l'image fautive du odg d'origine en décompressant le document avec file-roller. Si je crée un nouveau document odg, que j'insère cette image, et que je sauve, l'image est tronquée. Étrangement, eye of gnome arrive à la lire, et si j'ouvre le fichier odg qui contient cette image tronquée, elle apparaît normalement. Le vrai bug est donc ancien, mais juste mis en évidence par des versions plus récentes de LibreOffice parce que l'image corrompue est remplacée par un rectangle noir.

N'oublie pas que tu as beaucoup plus d'utilisateurs que de développeurs. Il ne faut pas sous-estimer la charge de travail que représente la reproduction de bugs. Je trouve donc normal d'essayer de déléguer un peu de la complexité, maintenir un logiciel, souvent bénévolement, n'est pas de tout repos. Mais les développeurs s'adaptent en général à l'audience, et il n'est pas nécessaire d'être développeur pour ouvrir un bug.

Sur le fond, quelqu'un qui prend du temps pour te remonter un bug ou une suggestion, ça a toujours de la valeur.

Tu ne prends pas en compte le temps passé sur chaque bug à les trier, gérer les doublons, et les tester. Tout ça c'est une charge de travail non négligeable, et les projets libres sont peu nombreux à ne pas manquer de main d'œuvre. Un bug ouvert, mais sans une bonne procédure de reproduction, ça ajoute plus de charge que de bénéfice. Le bon bug et le mauvais bug quoi...

Si tu rapportes un bug sur une vieille version, le bug n'est plus forcément valide. C'est donc mieux si le rapporteur peux reproduire lui même avec une version plus récente pour être sûr que le bug est toujours d'actualité. C'est encore plus nécessaire si le problème est difficile à reproduire ou est dépendant d'un matériel quelconque. Cependant, ce n'est pas obligatoire, et de toute façon les compétences de chacun sont variables. Mais en le faisant tu augmentes les chances que ton bug soit corrigé en faisant toi même une partie de l'investigation, et c'est à mon avis vrai pour tous les projets libres.

Dans tous les cas, si tu as un bug avec une application, tu as habituellement juste cette application à recompiler, éventuellement quelques dépendances plus récentes, mais pas tout GNOME. Le projet est cependant conscient que cela peut être difficile, c'est pour cela que les runtime de flatpak doivent permettre d'avoir la bonne configuration et avoir le moins dépendances possibles à recompiler, ce qui permet d'abaisser le niveau de connaissances exigé pour contribuer.

Je me souviens d'une copine il y a 15 ans qui m'avait donné un .doc énorme. En fait elle avait collé une image bitmap non compressée dans le document, et Word avait conservé l'image telle quelle. Compresser au mieux les images de manière automatique évite ce genre de cas de figure, et contribue au fait d'avoir un document le plus petit possible. Bon, après faut pas se louper et altérer les images :p

Bien vu.

if (rBmpEx.IsTransparent())
{
 ...
}
else
{
 mpAccess = Bitmap::ScopedReadAccess(aBmp); // palette + RGB without alphachannel
 if (mpAccess)
 {
 if (ImplWriteHeader())
 {
 ImplWritepHYs(rBmpEx);
 if (mpAccess->HasPalette())
 ImplWritePalette();
 ImplWriteIDAT();
 }
 mpAccess.reset();
 }
 else
 {
 mbStatus = false;
 }
}
if (mbStatus)
{
 ImplOpenChunk(PNGCHUNK_IEND); // create an IEND chunk
}

mbStatus est initialisé à true, donc pour passer à false c'est que vraisemblablement mpAccess = Bitmap::ScopedReadAccess(aBmp); // palette + RGB without alphachannel renvoie NULL. Est-ce le RGB qui pose problème sachant qu'on est à 1 bit par pixel ?

Alors ça veut dire quoi, que tous les sites en "free-quelque chose" risquent un procès maintenant ? Bin je suis dans la merde avec freeside.fr... En gros si je créais ma boîte avec ce nom, je risque un procès ?

J'abonde dans le sens de F-Droid. J'utilise le Google Play store pour sa diversité mais je privilégie dès que je le peux les logiciels de F-Droid pour les raisons indiquées plus haut (logiciels libres, problèmes éthiques en rouge).

Pour en revenir au besoin:

Je compte faire des sauvegardes régulières des photographies et vidéos, je ne sais pas si les conversations peuvent être sauvegardées, je sauvegarderai aussi les contacts.

Pour la synchro de contacts j'ai un compte sur framadrive.org qui me fournit une instance nextcloud et 2 Go de stockage sur le Cloud. Ils n'ouvrent plus de comptes, mais tu peux sans doute trouver un autre fournisseur. Ensuite j'utilise davdroid disponible sur F-Droid pour la syncho de contacts et de tâches. L'appli Nextcloud, aussi dspo sur F-Droid pourrait te faire la synchro de photos et vidéos. En revanche, même si elle est sur F-Droid, il semble qu'elle contienne tout de même des trackers, cf https://reports.exodus-privacy.eu.org/reports/405/

Merci pour elle.

Je ne pense pas, dans les commentaires du post de 0patch, ils parlent du fournisseur, Design Science, qui est toujours en activité.

C'est possible ça ? Le soft a été buildé pour la dernière fois le 09/11/2000, il devaient bien déjà à cette époque avoir une politique de maintenance, pour les correctifs de bugs et de sécurité. S'ils n'avaient pas le le code, ils prévoyaient sans doute de faire appel à leur fournisseur pour cela... Tu penses que la facture aurait été trop lourde et ils préfèrent patcher eux-même ? Ou le fournisseur lui même aurait perdu le code d'une appli buildée il y a 17 ans ?

Effectivement:

$ git grep -A 2 ads_service
src/generic/google-services.json: "ads_service": {
src/generic/google-services.json- "status": 1
src/generic/google-services.json- }
--
src/gplay/google-services.json: "ads_service": {
src/gplay/google-services.json- "status": 1
src/gplay/google-services.json- }
--
src/modified/google-services.json: "ads_service": {
src/modified/google-services.json- "status": 1
src/modified/google-services.json- }
--
src/versionDev/google-services.json: "ads_service": {
src/versionDev/google-services.json- "status": 1
src/versionDev/google-services.json- }

Merci pour Exodus, je ne connaissais pas.

Je vois qu'ils ont des rapport pour pas mal d'applications. Du coup je suis surpris de trouver 2 trackers dans le client officiel nextcloud...
https://reports.exodus-privacy.eu.org/reports/search/com.nextcloud.client

Pourtant c'est GPLv2, et dispo aussi sur f-droid.
https://f-droid.org/packages/com.nextcloud.client/

Exodus est encore jeune, ce serait un faux positif ?

Je me réponds:
https://github.com/gorhill/uBlock/wiki/Blocking-mode

Petite question: quels filtres uBlock Origin utilises tu ? Comment les as-tu choisis ?

Ou une contrefaçon, comme on te l'a déjà signalé. Donc te prends pas la tête à attendre des heures des copies alors que tu ne sais pas si la clé est opérationnelle. Si tu as un doute sur le harware de ton PC, teste sur un autre PC pour voir la taille détectée.

Il peut aussi essayer gnome-multi-witer-probe:
https://blogs.gnome.org/hughsie/2015/01/28/detecting-fake-flash/

Et si tu mets un fichier dessus à partir de Windows ? Tu l'as achetée où cette clé ?