On tombe alors dans les distributions pour ordinosaure… C'est du matériel avec 1,5 Go de RAM, capable de faire tourner un GNOME 3. Ça ferait certes une occasion d'essayer une SliTaz, mais c'est pas un 486 non plus…
Je me suis fait la même remarque. J'ai un Athlon XP 3000+ (barton) acheté en 2004 je crois. Je me suis rendu compte de problèmes avec SSE2 quand j'ai tenté de ripper mes CD audio avec sound-juicer (sous Mageia 6, le problème n'est pas que chez Fedora). La seule solution a pour moi été de le recompiler en désactivant la gestion SSE2. Cela peut être un peu pénible, mais c'est le seul logiciel avec lequel j'avais eu ce problème. Je n'avais pas eu le soucis avec Firefox, mais j'utilise moins cet ordi depuis cette année. Après c'est sûr que rebuilder Firefox, c'est pas ce qu'il y a de plus pratique…
En cherchant un peu je suis tombé sur ce thread: https://superuser.com/a/1254953
On y pointe cet outil en Rust, elfx86ets, permettant de détecter le jeu d'instructions utilisé par un binaire (et donc potentiellement trouver les binaires à problème selon son architecture).
Par ailleurs, il a été constaté dans la partie de la base de données dédiée à la gestion des étudiants, des commentaires tels que : diagnostiqué de plusieurs maladies graves […] ou très lourdement endetté […].
Sûrement un coup des syndicalistes :p. Sérieusement, la lecture des manquements vaut effectivement le coup d'oeil. Pour une école qui enseigne l'informatique, ça craint du boudin vu le nombre d'infractions.
La délégation a enfin été informée que les postes de travail des agents de sécurité qui ont accès au dispositif de vidéosurveillance est protégé par un mot de passe composé de 5 caractère alphanumériques.
On peut s'occuper d'un autre problème du même genre maintenant, les motards. Ils se regroupent le dimanche, boivent, font un boucan d'enfer et ce sont de vrais dangers publics sur la route. Interdisons la moto !
Je propose qu'on rajoute juste un peu plus de loups.
Je manipule de moins en moins des fichiers systèmes, alors ceci ne m'évoquait plus grand chose:
root::16431:0:99999:7:::
Il faut commencer par comparer avec la ligne existance avec sudo grep root /etc/shadow. Pour comprendre un peu mieux je rajoute un extrait de man shadow. C'est le 2ème champ vide (plutôt qu'avec un point d'exclamation, en tout cas sur ma vieille Ubuntu) qui ouvre la porte:
mot de passe chiffré
Consultez crypt(3) pour plus d'informations sur le traitement de cette chaîne.
Si le champ du mot de passe contient une chaîne qui ne peut pas être un résultat valable de crypt(3), par exemple si elle contient les caractères ! ou *, alors l'utilisateur ne pourra pas utiliser
son mot de passe UNIX pour se connecter (mais il se peut que l'utilisateur puisse se connecter au système par d'autres moyens).
Ce champ peut être vide. Dans ce cas aucun mot de passe n'est nécessaire pour s'authentifier avec l'identifiant de connexion indiqué. Cependant, certaines applications qui lisent le fichier
/etc/shadow peuvent n'autoriser aucun accès si le mot de passe est vide.
Un champ de mot de passe qui commence avec un point d'exclamation indique que le mot de passe est bloqué. Les caractères restants sur la ligne représentent le champ de mot de passe avant que le
mot de passe n'ait été bloqué.
Galaxy J5 ici, et je compte bien le faire durer aussi longtemps que possible, c'est pas comme si les réserves de terres rares étaient infinies. Je n'utilise que Firefox, donc je trouve aussi la question de savoir si Firefox continuera de tourner avec d'anciennes version d'Android pertinente…
Je t'avoue que j'avais vu l'article circuler et pas vu sa date. Mais comme toi je vois régulièrement des services qui proposent ce genre de méthode d'installation, et pas vraiment d'avertissement. Je ne sais pas s'il y a eu des modifications dans curl mais je ne vois pas ce que ça changerait: c'est le serveur web qui est malicieux, et altèrerait le contenu du ficher. Je ne vois pas trop comment wget ou curl pourraient détecter cela.
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).
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.
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.
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.
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.
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.
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 2. Dernière modification le 31 octobre 2018 à 10:54.
On tombe alors dans les distributions pour ordinosaure… C'est du matériel avec 1,5 Go de RAM, capable de faire tourner un GNOME 3. Ça ferait certes une occasion d'essayer une SliTaz, mais c'est pas un 486 non plus…
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 6.
On ne devrait pas avoir à changer de hardware pour des problèmes purement logiciels… Développement durable, tout ça…
[^] # Re: Petite précision sur les processeurs sse2
Posté par liberforce (site web personnel) . En réponse à la dépêche Fedora 29. Évalué à 4.
Je me suis fait la même remarque. J'ai un Athlon XP 3000+ (barton) acheté en 2004 je crois. Je me suis rendu compte de problèmes avec SSE2 quand j'ai tenté de ripper mes CD audio avec sound-juicer (sous Mageia 6, le problème n'est pas que chez Fedora). La seule solution a pour moi été de le recompiler en désactivant la gestion SSE2. Cela peut être un peu pénible, mais c'est le seul logiciel avec lequel j'avais eu ce problème. Je n'avais pas eu le soucis avec Firefox, mais j'utilise moins cet ordi depuis cette année. Après c'est sûr que rebuilder Firefox, c'est pas ce qu'il y a de plus pratique…
En cherchant un peu je suis tombé sur ce thread: https://superuser.com/a/1254953
On y pointe cet outil en Rust, elfx86ets, permettant de détecter le jeu d'instructions utilisé par un binaire (et donc potentiellement trouver les binaires à problème selon son architecture).
# Les pratiques
Posté par liberforce (site web personnel) . En réponse au lien Mise en demeure de l'association 42. Évalué à 6.
Sûrement un coup des syndicalistes :p. Sérieusement, la lecture des manquements vaut effectivement le coup d'oeil. Pour une école qui enseigne l'informatique, ça craint du boudin vu le nombre d'infractions.
# security FTW
Posté par liberforce (site web personnel) . En réponse au lien Mise en demeure de l'association 42. Évalué à 4.
[^] # Re: Microsoft en rêvait
Posté par liberforce (site web personnel) . En réponse au journal IBM achète Red Hat. Évalué à 10.
De l'importance de la ponctuation…
vs
[^] # Re: prochaine étape la Vuvuzela ?
Posté par liberforce (site web personnel) . En réponse au journal Enfin un maire qui a la tête sur les épaules. Évalué à 9.
Je propose qu'on rajoute juste un peu plus de loups.
[^] # Re: Magnifique !
Posté par liberforce (site web personnel) . En réponse au journal La faille grosse comme une maison. Évalué à 3.
Je manipule de moins en moins des fichiers systèmes, alors ceci ne m'évoquait plus grand chose:
root::16431:0:99999:7:::
Il faut commencer par comparer avec la ligne existance avec
sudo grep root /etc/shadow. Pour comprendre un peu mieux je rajoute un extrait deman shadow. C'est le 2ème champ vide (plutôt qu'avec un point d'exclamation, en tout cas sur ma vieille Ubuntu) qui ouvre la porte:[^] # Re: question
Posté par liberforce (site web personnel) . En réponse à la dépêche Firefox 63. Évalué à 7.
Galaxy J5 ici, et je compte bien le faire durer aussi longtemps que possible, c'est pas comme si les réserves de terres rares étaient infinies. Je n'utilise que Firefox, donc je trouve aussi la question de savoir si Firefox continuera de tourner avec d'anciennes version d'Android pertinente…
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par liberforce (site web personnel) . En réponse au lien "wget http://foo.com/command.sh | bash" considered harmful. Évalué à 5.
Je t'avoue que j'avais vu l'article circuler et pas vu sa date. Mais comme toi je vois régulièrement des services qui proposent ce genre de méthode d'installation, et pas vraiment d'avertissement. Je ne sais pas s'il y a eu des modifications dans curl mais je ne vois pas ce que ça changerait: c'est le serveur web qui est malicieux, et altèrerait le contenu du ficher. Je ne vois pas trop comment wget ou curl pourraient détecter cela.
[^] # Re: Non! Microsoft ne libère PAS 60 000 brevets!
Posté par liberforce (site web personnel) . En réponse à la dépêche Revue de presse de l’April pour la semaine 41 de l’année 2018. Évalué à 10.
La situation sur exFAT notamment est confirmée notamment par Bradley Khun de la Software Freedom Conservancy.
M'enfin le meilleur endroit pour en discuter reste le journal Vers une fin de la guerre des brevets logiciels ?
[^] # Re: C'est ce qui s'appelle
Posté par liberforce (site web personnel) . En réponse au journal Paul Allen bronsonisé. Évalué à 8.
C'est sûr qu'il l'a mauvaise.
[^] # Re: Espace disque partagé...
Posté par liberforce (site web personnel) . En réponse au journal Flatpak. Évalué à 10. Dernière modification le 12 octobre 2018 à 12:29.
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.
[^] # Re: Kill flatkill
Posté par liberforce (site web personnel) . En réponse au journal Flatpak. Évalué à 8.
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.
[^] # Re: Espace disque partagé...
Posté par liberforce (site web personnel) . En réponse au journal Flatpak. Évalué à 6. Dernière modification le 12 octobre 2018 à 11:20.
À 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).
[^] # Re: De ce que j'ai compris
Posté par liberforce (site web personnel) . En réponse au lien Flatpak - a security nightmare. Évalué à 2. Dernière modification le 11 octobre 2018 à 11:10.
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
Les packagers ont une responsabilité s'ils ne respectent pas les bonnes pratiques.
# De ce que j'ai compris
Posté par liberforce (site web personnel) . En réponse au lien Flatpak - a security nightmare. Évalué à 5.
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.
[^] # Re: LibreOffice 5.3.7, sérieux ?
Posté par liberforce (site web personnel) . En réponse à la dépêche Sortie de Mageia 6.1. Évalué à 6.
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.
[^] # Re: LibreOffice 5.3.7, sérieux ?
Posté par liberforce (site web personnel) . En réponse à la dépêche Sortie de Mageia 6.1. Évalué à 9.
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.
[^] # Re: LibreOffice 5.3.7, sérieux ?
Posté par liberforce (site web personnel) . En réponse à la dépêche Sortie de Mageia 6.1. Évalué à 3. Dernière modification le 09 octobre 2018 à 16:10.
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.
[^] # Re: LibreOffice 5.3.7, sérieux ?
Posté par liberforce (site web personnel) . En réponse à la dépêche Sortie de Mageia 6.1. Évalué à 7.
Ça a l'air d'être le cas, en partie, et en partie aussi du backport de Fedora 26 :
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
[^] # Re: j'envysage de trouver une autre machine
Posté par liberforce (site web personnel) . En réponse au message Quel distribution et quelle de pour un pc tournant de base sous windows 98. Évalué à 2. Dernière modification le 09 octobre 2018 à 11:43.
Sinon pour le vieux Fujitsu, tu as la distribution Slitaz.
Donc la loram-cdrom peut peut être tourner (lentement). Mais tu n'y feras jamais tourner LibreOffice.
[^] # Re: j'envysage de trouver une autre machine
Posté par liberforce (site web personnel) . En réponse au message Quel distribution et quelle de pour un pc tournant de base sous windows 98. Évalué à 2. Dernière modification le 09 octobre 2018 à 11:32.
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.
[^] # Re: Je n'aime pas
Posté par liberforce (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3. Dernière modification le 09 octobre 2018 à 10:37.
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.
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.
https://yourbias.is/the-sunk-cost-fallacy
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.
[^] # Re: Un nouveau standard ?
Posté par liberforce (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 2.
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 installet que tu ne veux pas utilisermakemaisninja, tu as déjà 50% de la commande qui change. Si tu veux abstraire l'appel àmakeou équivalent, tu te retrouves à faire comme CMake:cmake --buildva appelermakeouninjaselon le type de générateur configuré au départ. Sauf qu'alors tu dévies encore plus de ton./configure && make && make installinitial. Bref, il n'y a pas trop le choix.