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.
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.
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.
[^] # Re: Microsoft en rêvait
Posté par liberforce (site web personnel, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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, Mastodon) . 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.[^] # Re: Quelques questions...
Posté par liberforce (site web personnel, Mastodon) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3. Dernière modification le 09 octobre 2018 à 09:55.
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).
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.
[^] # Re: on en a déjà parlé dans la meson.
Posté par liberforce (site web personnel, Mastodon) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3.
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.
[^] # Re: hello world
Posté par liberforce (site web personnel, Mastodon) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 10. Dernière modification le 08 octobre 2018 à 14:45.
Pour un hello world en C:
Pour un projet C en GTK+:
Source: http://mesonbuild.com/Tutorial.html
[^] # Re: on en a déjà parlé dans la meson.
Posté par liberforce (site web personnel, Mastodon) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 5.
Tu m'excuseras, mais l'auteur de article en question dit seulement:
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 ?
[^] # Re: Un nouveau standard ?
Posté par liberforce (site web personnel, Mastodon) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 6.
J'ai dit "un remplaçant", pas "le remplaçant".
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.
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.