liberforce a écrit 4744 commentaires

C'est sûr qu'il l'a mauvaise.

Non. Tu te prends par la main, tu codes ton appli pour utiliser les libs couramment utilisées par les plus grosses distrib’ du marché et tu livres un soft potable.

Tu te berces d'illusions là.

Les "libs couramment utilisées par les plus grosses distrib’ du marché" ça veut rien dire. Toutes les distribs n'ont pas les mêmes versions de bibliothèques, et faire des cas spécifiques par combinaison de version sans les tester ça, ça ne marche pas.

Exemple en tête: GTK+ qui a changé la gestion du CSS en cours de route sur GTK+ 3. Tu fais comment quand tu as fait le portage de ton appli pour la nouvelle version, mais que toutes les distribs ne l'ont pas ? En général tu te retrouveras avec les distribs qui ont l'ancienne version de dépendance qui diffuseront l'ancienne version de l'appli, et les les distribs qui ont la version récente qui diffuseront la nouvelle version de l'appli.

Tu noteras que l'appli est propre, mais c'est l'écosystème qui fait que la distrib contrôle les dépendances, et pas le développeur de l'appli. Flatpak lui permet de livrer exactement la version qui est connue pour fonctionner avec telle autre version de dépendance, et ça marchera sur toutes les distribs gérant flatpak. Le développeur reprend le contrôle.

Ensuite s'il sort une nouvelle version majeure, bin désolé mais si tu n'as pas une distrib rolling release, la réalité du terrain c'est que ton soft ne sera que dans la version N+1 de la distrib parce que faire un backport ce serait aussi backporter les dépendances dans leur version plus récentes. Si ces dépendances sont partagées avec d'autres applis et non parallèlement installables, la validation devient un cauchemar, donc personne ne fait le backport.

Flatkill a tout de même un avantage: montrer que le boulot n'est pas fini, car faire un package flatpak les yeux fermés en donnant toutes les autorisations à l'appli c'est une hérésie au niveau sécurité, parce que ça ouvre des failles de sécurité.

Des packageurs inconséquents peuvent donc ruiner la réputation d'une application, et ça c'est un vrai problème. J'ai déjà vu des développeurs refuser de mettre le doigt dans flatpak, et refuser les rapports de bug à ce sujet parce que l'appli a été packagée par un tiers.

Qui ici a déjà eu une application malveillante sous GNU ? Quel est du coup l’utilité du cloisonnement ?

À une époque où les gens font du wget http://www.whatever/bidule_inconnu.sh | sudo bash , se protéger contre des menaces potentielles ne me semble pas superflu. En plus, le fait que tu n'ais jamais vu d'application malveillante ne veut pas dire qu'elles n'existent pas, juste que tu n'en as pas vu. Un rootkit qui s'installe par exemple, ça le crie pas sur les toits.

Le besoin de cloisonnement vient du fait que le modèle des distributions est peu flexible, et que des softs produits pour Linux et Windows sont en général plus à jour sous Windows ! Pour Linux, il faut attendre la prochaine version de ta distrib, croiser les doigts et espérer un backport, etc. Ensuite à partir du moment où tu veux exécuter du code tel que fourni par le développeur de l'application et que tu fais sauter l'intermédiaire de sécurité qu'est la distrib, tu te retrouves exposé au bon vouloir de chaque développeur d'appli de mettre à jour les bibliothèques qu'il utilise à chaque faille de sécurité détectée. S'il ne le fait pas, tu es exposé (comme le montre bien http://flatkill.org ) , la seule solution solution est donc de cloisonner, et de bien cloisonner (i.e. réduire les permissions au minimum).

La doc de flatpack spécifie aussi qu'il faut limiter les permission d'accès au filesystem:
http://docs.flatpak.org/fr/latest/sandbox-permissions.html#filesystem-access

As a general rule, Filesystem access should be limited as much as possible. This includes using:

• Using portals as an alternative to blanket filesystem access, wherever possible.
• Using read-only access wherever possible, using the :ro option.
• If some home directory access is absolutely required, using XDG directory access only.

Les packagers ont une responsabilité s'ils ne respectent pas les bonnes pratiques.

En gros, flatpak ça fonctionne comme Android au niveau permissions. Donc le moyen le plus rapide de fournir un flatpak pour les applications était de demander un maximum de permissions pour que ça fonctionne directement. Mais ensuite les applications ont un boulot d'adaptation pour réduire les droits demandés, et utiliser des portails à la place. Et adapter une application, ça demande du temps de développement.

Le système de packages n'est pas parfait non plus:
https://mastodon.social/@federicomena/100873820279835134

En revanche, je pense que la bonne question à se poser c'est: doit-on packager des applications sur flathub en sachant que les développeurs de l'application ne soutiennent pas flatpak. Parce que si personne n'est prêt à faire le boulot d'adaptation, cela représente effectivement un risque.

Une des solutions est sans doute de mettre plus en avants les droits réclamés par une application flatpak, pour qu'on sache si ça a été packagé à l'arrache ou si l'application a réellement été adaptée pour flatpak. Une autre partie de la solution est peut être aussi de ne pas packager une application si:
- on a pas l'intention de fournir des patchs pour restreindre les droits qu'elle demande
- ou si on sait que le mainteneur de l'application refusera les patchs pour la gestion de flatpak

Ou bien on peut la packager, mais sans diffuser le paquet flatpack tant que l'application n'a pas été modifiée pour demander des droits un minimum raisonnables.

En gros, le problème est plus dans l'utilisation de flatpak par les packagers. Mais il faudrait sans doute aussi renforcer dans flatpak et gnome-software la visibilité des permissions demandées pour que l'utilisateur comprenne bien ce à quoi il s'expose.

Que veux tu que le numéro de version te suggère ? Il y a un 4ème digit qui n'a pas l'air d'être dans la numérotation upstream, plus un numéro de paquet. Je pense que si tu es capable d'aller chercher des numéros de CVE, tu dois être capable de regarder le changelog d'un paquet non ? Tu peux d'ailleurs le faire graphiquement avec le gestionnaire de paquets de Mageia. Alors ou c'est en anglais, mais franchement, je ne vois pas ce qu'ils font de si différent des autres distribs, et qui mérite de s'indigner.

Ce n'est pas tant que la version proposée soit ancienne qui me choque, c'est que la distribution diffuse une version qui n'est plus maintenue.

Plus maintenue upstream. LibreOffice maintient ses releases pendant seulement 9 mois, ils ne font pas de version LTS. Mageia fait la maintenance, il y a quoi de désinvolte là dedans ?

Moi ce qui me choque, c'est que tu sois "choqué" alors qu'ils font le job de maintenance, et plutôt bien. Tu attendais une dépêche Mageia pour dire "on maintient LibreOffice" (et tout les autres logiciels de la distrib qui ne sont plus maintenus upstream) ? Dans ce cas pourquoi LibreOffice et pas d'autres logiciels aussi en fin de vie ? Pour moi c'est implicite que le distributeur fait la maintenance, c'est ce qu'on demande à une distribution.

Pour des versions plus récentes, il y a une version Flatpak de LibreOffice :
https://www.libreoffice.org/download/flatpak/

Je n'ai pas testé cependant.

Les mainteneurs de Mageia font le backport eux-mêmes ?

Ça a l'air d'être le cas, en partie, et en partie aussi du backport de Fedora 26 :

Mon Jun 4 2018 ns80 1:5.3.7.2-3.mga6

(not released yet)
+ Revision: 1234491
- add patch for CVE-2018-10583 (mga#22579)
- synch with Fedora 26 for CVE-2018-6871, CVE-2018-10119, CVE-2018-10120 (mga#22579)


Source: http://sophie.zarb.org/rpms/1a4c8e652e881959b1c8a95c45559202/changelog

Malgré le "not released yet", ça a bien l'air d'être livré:
https://madb.mageia.org/package/show/release/6/arch/x86_64/name/libreoffice

Sinon pour le vieux Fujitsu, tu as la distribution Slitaz.

Les saveurs loram permettent de démarrer SliTaz sur des machines ayant très peu de ressources. La saveur loram a besoin de 128 MB et libère le cdrom, la version loram-cdrom peut démarrer avec 24 Mb et un peu de mémoire swap, mais ne libère pas le cdrom.

Donc la loram-cdrom peut peut être tourner (lentement). Mais tu n'y feras jamais tourner LibreOffice.

Tout d'abord un petit mot : merci d'essayer de faire un effort sur l'orthographe, et de faire des phrases avec des points. C'est assez dur de te lire, et certains n'auront sans doute pas la patience.

Ensuite, pas la peine de raconter tout le pédigré de ton pote. Juste dire qu'il a des difficultés financières ou est dans le besoin, ça résume les 3/4 de ton post.

Voilà les specification du Fujitsu Siemens Lifebook C340.

En gros, c'est un Pentium II à 233MHz, et 64 Mo de RAM. Pentium 2, pas Dual Core, hein ! C'est 233 MHz et pas 2,2 GHz, soit 10 fois moins rapide. Vu la bête, je pense que le temps passé à configurer ce truc sera plus utile à chercher une autre machine. Et tu parles à quelqu'un qui a installé un Linux sur un Pentium II à 450 MHz avec de la RAM défectueuse achetée en brocante à une époque où c'était déjà une machine obsolète.

Si vous en êtes à penser à acheter un écran, autant regarder sur le marché de l'occasion. Par exemple sur backmarket.fr, je trouve un Lenovo Thinkpad x220i à 100€. C'est un Core i3 2,5 GHz - HDD 250 Go RAM 2 Go. L'ordi le moins cher est à 80€, mais pour 20€ de moins c'est beaucoup beaucoup plus limité, ça ne vaut pas le coup. En plus les Thinkpad sont certifiés Linux, pas de soucis d'installation, et il doit pouvoir garder le Windows d'origine s'il a besoin de Powerpoint (qui n'a pas de version Linux) et ne peut pas utiliser LibreOffice.

Si vraiment ça reste trop cher, tu dois pouvoir trouver des ordis pas cher dans un emmaüs local, souvent avec une distribution Linux Emmabuntus (un Ubuntu personnalisé).

En dernier recours, tu as moyen de surveiller les poubelles avant le passage des encombrants. J'ai vu une machine l'autre jour que j'ai failli prendre, j'ai juste pris la RAM et quand je suis repassé elle était partie. C'était de la RAM DDR3, donc une machine récent. Souvent les gens jettent parce qu'ils ont racheté autre chose, ou parce que leur Windows ne fonctionne plus et qu'ils ne savent pas réparer. C'est rarement un problème matériel. Si tu sais bricoler, tu peux en réassembler un, et récupérer les pièces manquantes en brocante à pas cher (genre je récupère des barettes de RAM à 1€).

Tu as aussi les dons, sur des sites spécialisés, comme la liste de diffusion freecycle.org, donnons.org, objetgratuit.com, mais il faut être réactif car cela part vite en général. Le site de l'April en référence d'autres.

c'est un nouveau build system, il y en a déjà trop

Comme je l'ai dit plus haut, c'est un faux problème. Personne n'arrive à faire les choses parfaitement du premier coup. Il faut des essais, et des échecs (les siens ou ceux des autres), pour en tirer des leçons et faire mieux la fois suivante. Je suis d'accord avec toi pour la gestion par les IDE, mais là c'est le problème des IDE. Pas besoin d'un IDE pour tirer profit d'un outil de build. C'est une solution de confort, et si une solution prend l'ascendant, elle sera gérée, comme cela a été le cas pour CMake.

Meson importe lui même les modules du monde entier (dans sa façon de voir les choses). C'est pour ça que vous avez un module Qt, GNOME, RPM, … à mon sens ce n'est pas au build système de s'intégrer avec tous les frameworks de la terre entière.

Sauf quand les projets ont des besoins particuliers. On ne peut pas demander à chaque application de redévelopper tout ce qui était déjà fait et le réinclure. Il faut un endroit centralisé pour cela. Meson montre que comme autotools avec ses macros, il est capable de gérer les spécificités des projets. Dans le cas de GNOME, ça va être de compiler des schémas, des fichiers de ressources, de la documentation, des fichiers d'introspection. Compiler et générer, c'est le job du build system, alors pourquoi pas le centraliser là bas ? C'est un atout pour les projets souhaitant migrer.

CMake est très clairement le build system le plus avancé en matière de C et C++. Je l'utilise depuis 10 ans maintenant.

https://yourbias.is/the-sunk-cost-fallacy

J'ai des choses à lui reprocher mais pas tant que ça et lorsque je trouve des choses à améliorer j'envoie des correctifs.

Et c'est bien de contribuer. Mais de même qu'il y a de la place pour plus qu'un seul OS, je pense qu'il y a de place pour plus d'un build system.

Quand tu as déjà n projets existants qui font les choses différemment, c'est quoi la norme ? Quand tu as ./configure && make && make install et que tu ne veux pas utiliser make mais ninja, tu as déjà 50% de la commande qui change. Si tu veux abstraire l'appel à make ou équivalent, tu te retrouves à faire comme CMake: cmake --build va appeler make ou ninja selon le type de générateur configuré au départ. Sauf qu'alors tu dévies encore plus de ton ./configure && make && make install initial. Bref, il n'y a pas trop le choix.

Pour ce qui est de ninja, j'ai lu dans le manuel de cmake une rumeur comme quoi il serait aussi supporté

C'est plus qu'une rumeur, CMake gère de manière expérimentale Ninja depuis au moins CMake 3.0, et n'est plus marqué comme expérimental dans la documentation depuis CMake 3.3 (juillet 2015).

le fait de supporter un maximum de backend me semble une force, pas une faiblesse.

Mais ça augmente la complexité, et tu dois ensuite abstraire ce que peut faire un système et pas l'autre. C'est l'éternel débat entre s'adapter au plus petit dénominateur commun vs exploiter les capacités au maximum en utilisant les spécificités.

Pour les tailles de projets sur lesquels je travaille il n'y a pas de problème de temps de configuration avec CMake

Perso, j'avais fait quelques tests sous Windows + MSYS2 pour des applis GTK+ à peine plus compliquées qu'un hello world. C'était sur un Asus Transformer T100, donc pas une bête de course: Intel Atom et eMMC pour le stockage. Bin j'avais déjà un gros écart à la configuration entre CMake et Meson (de l'ordre de la centaine de ms avec Meson, et de l'ordre de la seconde avec CMake). Donc pas besoin de milliers de lignes de code pour voir un bénéfice.

Pour un hello world en C:

project('tutorial', 'c')
executable('demo', 'main.c')

Pour un projet C en GTK+:

project('tutorial', 'c')
gtkdep = dependency('gtk+-3.0')
executable('demo', 'main.c', dependencies : gtkdep)

Source: http://mesonbuild.com/Tutorial.html

Tu m'excuseras, mais l'auteur de article en question dit seulement:

Bon là je désespère. Encore un outil qui veut être le plus rapide et toujours pas d'outil qui prétend fonctionner correctement.

Je n'ai jamais utilisé Meson mais on m'a dit que c'est-nouveau-c'est-bien-tu-devrais-essayer.

Pourquoi pas, enfin moi je cherche surtout un truc qui me génère de quoi faire un build iOS, Android, OSX et Linux. Un truc qui juste marche quoi.

On est loin du propos argumenté là… La définition de "ça marche" est différente pour chacun, parce que ça dépend des besoins de chacun. Qu'est-ce qui n'a pas marché pour lui ?

Non, ça n'est pas un remplaçant, et c'est bien ça le problème.

J'ai dit "un remplaçant", pas "le remplaçant".

systemd est un remplaçant à sysVinit, mais ninja est une alternative à make.

Ah. Parce que systemd n'a pas commencé comme "un système alternatif avec l'espoir qu'il remplace à terme l'existant" ? Tu crois que les gars proclament "je suis le remplaçant de ", et les moutons suivent ? Ce qui différencie l'alternative du remplaçant, c'est juste le taux d'adoption, et ce taux varie en fonction du temps. Ou alors on m'aurait menti et Betamax est le remplaçant et VHS l'alternative ?

Créer des alternatives, c'est ce qui fait émerger des remplaçants. Tu ne peux pas te plaindre que des gens essaient de faire mieux que l'existant, et n'y arrivent pas pour des raisons multiples. Sinon autant jeter tous les OS alternatifs, il y a Windows.

Une dépendance à GNU make sur une distribution linux? C'est le genre de dépendance qu'on peut certainement assumer, non?

Ces outils sont multi-plateforme et permettent la cross-compilation aussi, et l'utilisation en contexte embarqué… Ta distrib Linux sur ton PC x64 c'est carrément pas le débat.

un Makefile minimal de trois lignes qui appelle ninja

Tu réalises que Ninja est un remplaçant à Make ? Si au lieu de remplacer une brique par une autre équivalente tu préfères rajouter un wrapper et une nouvelle dépendance, t'es pas sorti de l'auberge…

La police est peut être installée en local sur ta machine et le navigateur irait alors la chercher là ?

C'était juste un problème de cache. J'ai bloqué les polices externes, effacé le cache, rechargé la page et ça passe. En revanche il y a alors quelques caractères que je ne vois plus, comme les icônes de notes, remplacés par un rectangle avec le point de code unicode correspondant.

commentaire supprimé

Super la réactivité ;). Petite remarque:

popd permet de retourner au dernier dossier enregistré (un peu comme cd sans argument qui ramène dans le dossier de l’utilisateur).

En fait l'équivalent serait cd - qui te renvoie dans le dossier précédent.

Appelé sans argument, pushd déplace l’utilisateur dans le dossier qui se situe au sommet de la pile de dossiers, et ajoute le chemin qui était courant au moment de l’appel de la fonction au sommet de la pile. Ainsi, Appeler pushd sans arguments plusieurs fois de suite permet de basculer entre deux dossiers.

Ça je ne connaissais pas, merci !

Moi j'aime bien OpenDyslexia, ça me donne une impression de modernité, ça ressemble un peu aux lettres basques, et puis, étant légèrement dyslexique, j'ai eu envie de faire connaître cette police.

Très clairement, on a pas du tout le même ressenti. Déjà, j'ai du mal à voir la modernité. Ensuite, cette police m'indispose au plus haut point (je précise que je ne suis pas dyslexique). Un peu comme un livre mal imprimé avec une encre qui a bavé. On dirait du Comic Sans qu'on aurait fait fondre au chalumeau. Ce n'est peut être que moi, mais je ne me vois pas lire plus de quelques lignes avec cette police. J'ai bloqué les polices externes avec uBlock Origin, mais je n'arrive pas encore à avoir une police différente.

Bon, après ce n'est pas un plaidoyer que tu changes ta police, mais juste faire remarquer que ça peut déranger des gens.

P'tit soucis quand même sur le copier/coller "l'état chinois chine", et puis il manque la fin ;)

$ type pushd
pushd est une primitive du shell