Posté par freem .
En réponse à la dépêche E.T. téléphone Meson.
Évalué à 3.
Dernière modification le 19 octobre 2018 à 17:42.
Les builds reproductibles, ça me semble super, mais justement, même Debian (qui semble être plus ou moins à l'origine du mouvement, du moins c'est l'impression que j'ai eue la première fois ou j'en ai entendu parler) n'y parviens pas.
Et de ce que j'ai cru comprendre en survolant le sujet (de haut le survol, hein… ça m'intéresse, mais je n'ai pas eu le temps de creuser vraiment… mais cette piqûre va me faire re-survoler tout ça au minimum) j'ai cru comprendre que le but c'est justement de pouvoir avoir le même binaire en compilant avec les mêmes sources et la même configuration depuis un environnement différent, histoire de garantir que l'environnement n'introduit pas de problèmes, justement.
Du coup, je ne vois pas le rapport entre les build reproductibles et Yocto qui rebuild au moindre changement de source?
Je ne vois pas trop comment wget ou curl pourraient détecter cela.
Une solution serait de détecter quand la sortie standard est redirigée, comme le font grep ou ls, et dans ce cas de ne rien faire.
Ça casserait tous ces comportements sales, mais ça forcerait les usages légaux à évoluer aussi.
Posté par freem .
En réponse au journal demain soir on finit tard.
Évalué à 2.
Dernière modification le 17 octobre 2018 à 09:31.
Le lien vers la CVE semble impliquer que cette faille ne concerne «que»
A flaw was found in python-cryptography versions between >=1.9.0 and <2.3.
Par contre, ce que je ne comprend pas (mais ce n'est pas la première fois que j'ai du mal à comprendre les numéro de version de paquets Debian… faudra que je creuse un jour), dans Debian les versions que j'ai (en stable + backports) sont potentiellement "0.7.3" et "0.8.1", ça semble loin de 1.9.0? D'ailleurs il n'y a pas de MàJ de sécu dispo à l'heure ou j'écrit ces lignes… J'aurai tendance à en déduire que Debian n'est pas affectée?
Je pense que la raison c'est d'éviter les collisions avec d'autres bibliothèques C, mais dans ce cas le mieux aurait été de mettre un vrai préfixe, d'autant que'accessoirement, ça casse sans vraie raison la compatibilité avec C++. Je trouve ça dommage (un peu comme freetype et leurs foutues macros qui commencent par des '_': ça compile, mais ça génère un bruit de malade sous la forme de warnings, et comme je transforme les warnings en erreurs… :/ mais freetype à au moins l'histoire et un «quasi-monopole» dans leur domaine, ça excuse.).
Le builder est un outil du développeurs, pas un système de packaging.
Ah? Et pourquoi ça?
La compilation et la création de paquets c'est quand même vachement proche:
quand je compile, je prend des sources pour générer un ou plusieurs binaires et j'établis d'éventuelles relations entre eux;
quand je fais un paquet, je prend des sources pour générer… ah, ben, la même chose en fait?
Si on part de Make, dans son usage traditionnel avec le C ou le C++, son backend est un compilateur et un éditeur de liens, mais qu'est-ce qui empêcherait d'avoir dpkg-deb à la place?
Au final, pourquoi a création d'un paquet, ça ne serait pas juste une cible de compilation, de la même manière qu'on peut ne recompiler qu'un seul des éléments d'un projet?
D'ailleurs, CMake justement permets de générer des paquets Debian ainsi que des installateurs windows si ma mémoire ne me trompe pas. Et je ne serais pas surpris que ça puisse générer des rpm.
Si on regarde ici meson Vs Cmake j'ai quand même l'impression que ça respecte les promesses, c'est quand même bien plus lisible non?
À ce que je vois:
la version de CMake effectue une analyse statique du code, pas celle de Meson;
la version de CMake ne sépare pas les heaers et les divers éléments de source, mais ce n'est pas à cause de CMake;
la version de Meson gère plus proprement les dépendances avec fallback, vrai que ça peut servir;
la version de CMake utilise GLOB_RECURSE, mais n'utilise pas les masques (qui, je sais, sont considérés comme une mauvaise pratique), du coup, pourquoi utiliser GLOB_RECURSE?
la version de CMake inclue du code zombie;
la version de CMake semble mentionner la possibilité de faire de l'édition de lien statique, pas celle de Meson;
Conclusion:
Oui, c'est vrai, la version de Meson semble plus lisible, mais elle semble faire moins de choses, d'une part, et ne pas avoir vieilli. Je suis quasiment sûr à la lecture des deux que la version Meson est une réécriture en se basant sur celle de CMake, et que du coup il n'y à pas les antécédents. Forcément, ça aide à faire plus lisible, mais c'est une comparaison injuste.
Si demain un projet qui utilise Meson depuis plusieurs versions décide d'implémenter le support de CMake, les chances ne sont pas minces pour que le même phénomène se produise, pour moi: c'est facile de faire plus propre quand on à un exemple qui fonctionne (c'est une des raisons pour lesquelles je commence par écrire des PoC de mes codes avant de les reprendre. Le code qui en résulte n'est pas forcément propre, mais il n'est pas dégueulasse comme l'est souvent celui du PoC).
freem je suis désolé la partie plus technique de ton message ma parue incompréhensible, pour être franc je ne sais pas comment un DE est fait ni le kernel non plus.
Je m'en doutait bien, et je ne suis pas trop rentré dans les détails.
Mais juste histoire de régler un point: un DE (environnement de bureau, pour Desktop Environment), ce ne sont que quelques logiciels configurés pour fonctionner ensemble. Généralement, un gestionnaire de fenêtre, un émulateur de terminal, un éditeur de texte en forment la base, sur laquelle on ajoute un nombre variable d'applications en fonction du besoin.
Le problème est que ça implique une certaine recherche pour trouver les logiciels que l'on veut, et du temps pour qu'ils fonctionnent ensemble plus ou moins harmonieusement.
FYI: Le problème n'est pas la vitesse, mais l'occupation mémoire. Ce sont 2 choses très différentes, et justement, utiliser plus de RAM pour avoir de plus gros caches peut permettre d'accélérer un logiciel.
Dans l'ensemble, je suis d'accord avec toi, une distro plus vieille fera mieux l'affaire en terme de performances matérielles, mais ça aura 2 gros inconvénients, surtout qu'on parle de matériel qui est légalement majeur ici:
les failles de sécurités ne sont pas bouchées. Donc, mieux vaut ne surtout pas aller sur le net voire même ne pas connecter! Ça me semble impossible pour un utilisateur normal.
la compatibilité avec les formats récents sera juste catastrophique.
Pour le SSE2, oui, j'avais remonté le problème aussi, je me souvenais juste plus de la cause exacte. Mais soyons sérieux: avec 64… allez, 150Mo de ram, c'est impossible de faire tourner un navigateur web type firefox ou chromium de toute façon. Il ne reste donc que les alternatives légères, plus ou moins difficiles à utiliser et plus ou moins capable de faire le rendu des sites modernes: uzbl, netsurf, dillo, lynx… et bien d'autres (je note d'ailleurs la suppression des dépôts debian de midori).
Pour la bureautique, sur une machine aussi peu performance, pas le choix, il faut utiliser des alternatives. J'ai cité 2 qui sont plus légères que LO de mémoire en restant accessibles à un utilisateur normal, mais il y en a d'autres plus… «barbues». J'ai essayé de garder l'utilisateur final à l'esprit dans mon message initial :=)
Dans un genre différent, il y a Otter Browser, pas encore fini et qui se base sur webkit (enfin, son fork je crois… m'y perds) je sais, mais utilisable.
Me semble que netsurf va aussi bientôt intégrer le support de JS, à voir? Je ne sais pas si uzbl est encore maintenu dans la catégorie poids légers (léger, mais avec un gros moteur de rendu… sigh)
Je pense qu'il fait ici référence au fait d'interdire sans contournement possible les extensions non approuvées (je ne sais pas si c'est encore d'actualité, je ne suis pas un utilisateur d'extensions et j'utilise de toute façon très peu Firefox (et bientôt plus du tout, en fait).
Peut-être fait-il également référence au fait que si l'on consulte une page HTTPS qui inclue des objets qui ne sont pas S, ceux-ci ne s'affichent pas, ce qui implique de devoir passer par la version HTTP de la page. Sur ce point, je trouve le comportement pertinent, cela dit.
Comme l'ont dit les autres, il y a un problème dans ta description. Probablement même 2, en fait. Un dual core à 2.2GHz accompagné de 64Mbits de ram, c'est… franchement peu probable.
Déjà, parce que d'aussi longtemps que je me souviennes, la RAM à toujours été exprimée en ordre de grandeur d'octets, pas de bits, et de plus, parce que je me souviens assez bien du 1er PC que j'ai eu en ma possession (pas le 1er que j'ai eu chez moi, hein, le 1er qui m'ait vraiment appartenu), vers 2002, et sans être une bête de course à l'époque, il avait plutôt dans les 512Mo de RAM, pour un CPU du même type, plus ou moins. Je n'utilisais qu'un seul slot de RAM, et j'avais un port AGP pour y coller une carte graphique et donc éviter de partager la RAM.
Avec ce genre de machines, on peut encore avoir un peu de confort.
Avec 64Mo, par contre, c'est plus compliqué, mais faisable:
J'ai un ordinonaure à la maison, quand je l'ai acquis, il ne disposait que de 64Mo de RAM et d'un CPU cadencé à 700MHz, probablement i486 (donc, chromium maintenant ne peux plus du tout être lancé. Cela dis, vue la RAM… xD) et une Debian minimaliste fonctionnait dessus, je pouvais même jouer à wesnoth.
Depuis, j'ai réussi à retrouver une barrette de RAM, et je dépasse les 150 Mo de RAM, c'est un peu plus confortable. Ça fonctionne, oui, mais il ne faut pas rêver, ça va pas vite, et je suis restreint au niveau des logiciels. Si je pouvais mettre la main sur une carte graphique je pense que ça irait mieux quand même (oui, la RAM est partagée du coup).
Au niveau des contraintes, concrètement, prévoir 1G de swap, ça pourra pas faire de mal. Firefox ou autre navigateur moderne? C'est mort, il faut passer sur dillo ou netsurf (voire lynx si vraiment…). La conséquence, c'est que la plupart des sites web «modernes» seront inaccessibles, et les autres (ceux qui n'abusent pas de JavaScript&HTLM5) n'auront pas un rendu de folie, mais enfin, ça marche.
En bureau, je ne vois que la possibilité d'utiliser LXDE, tous les autres seront trop gros, trop lourds. Ou alors faire le sien, mais c'est un truc d'utilisateur avancé ça.
Il vaut mieux remplacer le traditionnel agetty dans /etc/inittab par fgetty, qui n'occupe que 4Kio de «mémoire permanente» (je ne connais plus le terme exact) par instance, et vu que c'est ultra pénible à faire avec systemd, et peut-être impossible à faire proprement sous Debian, ben, je suis d'avis d'installer sysv-init et de dégager systemD, même si ça plaira pas à certains ici. Si la busybox de debian fournissait encore un init, j'aurais même préconisé d'utiliser ce dernier, mais bon…
Pour la bureautique, éviter LibreOffice, gnumerics et abiword sont moins gourmands en RAM de mémoire, et pour les présentations, je conseille d'utiliser tout bêtement des PDF. Pour les générer, je dirais bien d'utiliser LaTeX, vu le système, mais ça nécessite un peu d'apprentissage (avec par contre l'avantage d'avoir un truc qu'il n'y a pas besoin de réapprendre tous les 2 ans, versionnable (mais je pense qu'il s'en fout?), utilisable sur n'importe quel système sans en chier).
En bonus, en lecteur de musique, je conseille mpd + ario (graphique) ou ncmpcpp (dans un terminal, semi-graphique).
Pour conclure, c'est faisable, mais ça nécessite des sacrifices.
Une alternative plus raisonnable à mon avis serait d'acheter un SoS (System on Chip) du genre Raspberry PI ou Beaglebone Black.
Posté par freem .
En réponse à la dépêche E.T. téléphone Meson.
Évalué à 7.
Dernière modification le 08 octobre 2018 à 15:14.
Perso, quand j'essaies d'utiliser CMake (et j'y arrive, tant bien que mal, l'air de rien), je crois que les 2 trucs qui me cassent le plus les pieds c'est:
l'intégration du (D)VCS. Il y a quantité de littérature sur comment extraire le dernier tag+le dernier hash court et l'intégrer dans le CMake, mais jusqu'ici, je n'ai rien trouvé de vraiment clair. En l'occurrence, je parle de git, le plus utilisé du moment selon mon pifomètre, mais je ne doute pas que le problème se retrouve avec les autres. Si je dois migrer à un nouveau BS (Build System, pas Bull Shit… quoique…) il va au moins falloir que ça, ce soit simple.
le triste "la compilation (ou est-ce le linkage? Je sais jamais) à échoué, vous pouvez avoir plus d'informations en passant -v". Sous-entendu: passer -v au compilo, pas à make, bien sûr. Bref, comment que ça se passe avec Meson?
Autre point qui m'a fait tiquer dans la dépêche:
Et au lieu d'imprimer les sorties les unes au-dessous des autres, la sortie précédente est effacée, permettant d'éviter les scrolls trop longs et de se concentrer sur le dernier élément. En outre, le compteur d'étape est agréable pour savoir où on en est dans la compilation (particulièrement pour les très gros projets aux longues compilations).
Euh, vous êtes sérieux la? Non, parce que si j'oublie un ";" après la "}" d'une classe ou structure en C++, l'erreur ne sera pas immédiate, mais arrivera bien après. Donc, c'est la 1ère erreur qui est importante, pas la dernière.
Ce n'est qu'un seul exemple, mais bien souvent dans mon cas les erreurs de compilations se corrigent en cascade, et pas comme un saumon qui remonte sa rivière…
Pour le reste, c'est à voir, si en effet il gère aisément les dépendances externes, ça peut être sympa, parce qu'avec CMake, quand on inclue une dépendance, on sait jamais si c'est LIBRARY, LIBRARIES, le nom n'est jamais trop sûr non plus et aller lire les fichiers qui l'indiquent (qui sont multiples) est bien lourd.
Sauf que, en fait, à bien y réfléchir, ça se fait pas trop mal avec cmake, si on utilise pkg-config, et non leur système intégré (parce que de toute façon, je me suis aperçu avec le temps que je finis toujours par utiliser des libs qui n'exposent pas de fichier cmake au système, alors que les fichiers pour pkg-config c'est la norme sous *nux).
Bon, je reconnaît que l'inconvénient du coup, c'est Windows. Pas comme si Windows n'avait jamais été une plaie dans la gestion des dépendances de build, non plus.
Conclusion pour ce paragraphe: et chez vous, pour exporter une lib, ça marche comment?
Pour ce qui est de ninja, j'ai lu dans le manuel de cmake une rumeur comme quoi il serait aussi supporté. Du coup, vu que la vitesse de meson semble l'argument de «vente» le plus mis en avant, et qu'il est avoué que c'est dû au fait d'utiliser uniquement ninja, ça donne quoi, une comparaison de vitesse à la loyale?
Parce qu'à moi, le fait de supporter un maximum de backend me semble une force, pas une faiblesse. J'avais lu il y a quelques années (dans le contexte de pondre une API de plugins) un papier des gens de chez google qui argumentaient sur le fait que, pour avoir une API à peu près stable et robuste, il fallait au moins 3 outils qui l'implémentent, et que plus il y en a, mieux c'est. Je n'arrive pas à le retrouver, mais ma mémoire m'indique que l'argumentaire était plutôt robuste et convainquant.
UnknownHorizons: je ne connaissais pas du tout, il faut que je teste!
La dernières fois que j'ai testé, y'a 1 an à peu près, il s'agissait plus d'une démo jouable (pour les gens qui avaient moins de 20 ans en 2000 ;) ) que d'un jeu complet, mais le potentiel est élevé pour être un jeu intéressant (bon, un clone d'un jeu intéressant, certes).
Widelands: j'y ai joué un moment en nostalgie de settlers, je l'aimais bien, mais encore une fois, devant les bugs et les fonctionnalités limités et le dev qui avait l'air au point mort, je me suis lassé. Faudrait peut-être que je retest voir si il a évolué.
Alors, je ne sais pas quand tu as joué à widelands pour la dernière fois, mais depuis que je connais ce jeu (quelques années, plus de 5) son développement bien que lent (public limité, après tout, alors contributions encore pire, c'est plus un jeu de gestion que de stratégie, reste à définir la limite) il a toujours été développé, genre, 1 release par an. Ces dernières années ont vu, notamment, l'arrivée de la colonisation maritime.
Et, dernier point, je lui préfère settlers 1, je trouve le gameplay du 2 dont il est inspiré trop simple.
De toute façon, ce n'est pas un clone, rien que le fait d'avoir 3 (et bientôt 4) civilisations différentes le différencie. Et ça, ça date pas d'hier.
Ah, pour info, il semble que la future release va avoir 1 nouvelle mission de campagne.
0 A.D: déjà cité
Ah, celui-là, j'aimerai pouvoir y jouer avec une machine normale sans que l'écran d'acceuil ne fasse saturer mon système. Et si, en plus, il pouvait y avoir un tutoriel, histoire qu'on comprenne ou l'on va, alors, je pourrait estimer qu'il a dépassé le statut d'alpha.
Mais non, ça rajoute des civilisations à tout va, des graphismes toujours plus beaux, etc, et l'écran d'accueil rame. Pour afficher un simple menu qui permettrait éventuellement de baisser les graphismes au minimum.
Dune Legacy: j'ai joué un peu au vrai dune quand j’étais petit mais ça m'attire pas spécialement
C'est pour les collectionneurs, en même temps, je pense. On parle de l'ancêtre des RTS la quand même.
Et qui est packagé dans toute la bonne distribution (ouai, la flemme de regarder pour les autres bonne distros). Ce qui implique que l'effort à faire, pour peu qu'on utilise cette distro ou une de ses rares filles, est mineur.
À noter que je n'ai jamais fini la campagne, telllleeeeement longue, qu'en général je perds mes sauvegardes entre 2 périodes de jeu. Ce problème à été résolu en permettant aux joueurs de commencer directement n'importe quelle campagne sans avoir fini les précédentes, ce qui risque bien de me remotiver dès que j'aurais à nouveau une tour :) (je vais p'tet attaquer directement la 3eme, dont je n'ai joué aucun scénario encore)
openssh devrait faire l'affaire, avec un tunnel.
Et si jamais tu dois, comme moi au taf, te connecter depuis un réseau GPRS dont tu n'as pas la maîtrise, rien n'empêche d'utiliser openssh-client pour faire un tunnel inversé.
Vu que, au taf, j'ai un nombre indéfini et grossissant de systèmes qui se connectent en GPRS, j'ai même pris le parti d'établir un tunnel entre le système distant et un socket sur un serveur. Pour accéder au système distant depuis un autre système distant il faut donc établir un tunnel vers ce socket, en étant connu du serveur, et connaître le nom du fichier qui est, du coup, un peu plus parlant qu'un numéro de port.
C'est vrai que l'on parle trop peu de l'atmosphère sonore des jeux libres. Wesnoth est l'un des rares jeux, de manière générale (et pas juste jeux libres), pour lesquels je joue avec la musique du jeu.
Va falloir que je jette une oreille sur ça, du coup, même si j'espère que le thème principal est encore la quand même, vu que pour moi il est un peu emblématique, et quand j'entend les 1ères notes je sais ce que je fais sans avoir besoin de regarder l'écran :D
Ouai, bon, je sais, c'est pas un lieu pour envoyer un message "privé", mais, de manière générale, je me demande si tu as une présence virtuelle "instantanée" en dehors des heures de bureaux heure française? J'aimerai bien discuter avec toi, meme s'il est évident à mes yeux que je n'ai pas grand chose a t'apprendre.
J'ai cru comprendre, au fur et a mesure des échanges (depuis quelques années, certes, mais me faut du temps) que tu vis de toi-même en produisant du logiciel libre, et je serais curieux d'avoir une discussion a ce sujet, si tu le permets.
Ce ne sont pas les moyens qui manque, mais il faut en décider d'un, si tu acceptes.
note : je comprend tout à fait les gens faisant du logiciel libre mais pas de l'oeuvre libre pour des raisons sentimentales ou économiques
Ah, bah, c'est donc ça la raison pour laquelle j'ai tendance a te rejoindre.
Sauf que, moi, en pratique, je suis un hypocrite.
Enfin, je file des patchs de temps a autres, mais je ne les suit pas nécessairement, ce sont juste des patchs, qui m'ont pris quelques (dizaines d') heures, mais qui peut potentiellement coûter bien plus a intégrer avec la vision future. J'essaie bien de suivre les règles de codage, mais elles sont rarement explicites, et j'ai tendance a tapper dans l'archi, ce qui est controversé (à raison)
j'essaye, je suis retombé dans le piège LinuxFr
Hum. Je suis persuadé que tu sais que ton opinion intéresse des gens ici. Et puis, si t'es un peu malin, tu sais que la plupart des gens qui réagissent sont les raleurs, non?
Je colles toujours des //TODO whatever dans les coins de code qui ne devraient en théorie jamais arriver, mais que je sais que je devrais gérer… je rêve du jour ou je pourrais lire ou écrire un "soft de maître", sans aucun TODO a me repprocher… (en sachant que mes TODO ne représentent pas la totalité des bugs présents, hein)
Je me permets de pertinenter pour le fait que tu apportes des explications rationnelles au problème. On a trop tendance a oublier qu'on ne sait pas grand chose, y compris dans notre petite communauté d'amoureux (je pense) de la technique.
Je te remercie donc humblement de ce rappel en puissance (je savais déjà que je suis loin de maîtriser mon domaine d'expertise, mais, ironiquement, j'avais oublié à quel point mon ignorance en dehors était vaste)
, on imagine en général que les gens meurent vieux, après avoir profité des retombées commerciales d'œuvres à succès pendant des dizaines d'années.
Oh, foutage de gueule ici… ou… allez, non, c'est moi qui exagère, mais, pour m'en convaincre, il te faudra citer plus d'auteurs morts riches, que moi d'auteurs morts dans la misère.
Normalement, vue ma faible culture artistique, je devrais perdre très vite.
[^] # Re: Un nouveau standard ?
Posté par freem . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3. Dernière modification le 19 octobre 2018 à 17:42.
Les builds reproductibles, ça me semble super, mais justement, même Debian (qui semble être plus ou moins à l'origine du mouvement, du moins c'est l'impression que j'ai eue la première fois ou j'en ai entendu parler) n'y parviens pas.
Et de ce que j'ai cru comprendre en survolant le sujet (de haut le survol, hein… ça m'intéresse, mais je n'ai pas eu le temps de creuser vraiment… mais cette piqûre va me faire re-survoler tout ça au minimum) j'ai cru comprendre que le but c'est justement de pouvoir avoir le même binaire en compilant avec les mêmes sources et la même configuration depuis un environnement différent, histoire de garantir que l'environnement n'introduit pas de problèmes, justement.
Du coup, je ne vois pas le rapport entre les build reproductibles et Yocto qui rebuild au moindre changement de source?
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par freem . En réponse au lien "wget http://foo.com/command.sh | bash" considered harmful. Évalué à 2.
Une solution serait de détecter quand la sortie standard est redirigée, comme le font grep ou ls, et dans ce cas de ne rien faire.
Ça casserait tous ces comportements sales, mais ça forcerait les usages légaux à évoluer aussi.
[^] # Re: Un nouveau standard ?
Posté par freem . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3.
Un lien ou une explication rapide seraient appréciés.
# Lien vers le CVE
Posté par freem . En réponse au journal demain soir on finit tard. Évalué à 2. Dernière modification le 17 octobre 2018 à 09:31.
Le lien vers la CVE semble impliquer que cette faille ne concerne «que»
Par contre, ce que je ne comprend pas (mais ce n'est pas la première fois que j'ai du mal à comprendre les numéro de version de paquets Debian… faudra que je creuse un jour), dans Debian les versions que j'ai (en stable + backports) sont potentiellement "0.7.3" et "0.8.1", ça semble loin de 1.9.0? D'ailleurs il n'y a pas de MàJ de sécu dispo à l'heure ou j'écrit ces lignes… J'aurai tendance à en déduire que Debian n'est pas affectée?
[^] # Re: Conventions
Posté par freem . En réponse au journal Des nouvelles d'Ulfius, framework web en C. Évalué à 5. Dernière modification le 10 octobre 2018 à 09:10.
Je pense que la raison c'est d'éviter les collisions avec d'autres bibliothèques C, mais dans ce cas le mieux aurait été de mettre un vrai préfixe, d'autant que'accessoirement, ça casse sans vraie raison la compatibilité avec C++. Je trouve ça dommage (un peu comme freetype et leurs foutues macros qui commencent par des '_': ça compile, mais ça génère un bruit de malade sous la forme de warnings, et comme je transforme les warnings en erreurs… :/ mais freetype à au moins l'histoire et un «quasi-monopole» dans leur domaine, ça excuse.).
[^] # Re: Un nouveau standard ?
Posté par freem . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3.
Ah? Et pourquoi ça?
La compilation et la création de paquets c'est quand même vachement proche:
Si on part de Make, dans son usage traditionnel avec le C ou le C++, son backend est un compilateur et un éditeur de liens, mais qu'est-ce qui empêcherait d'avoir dpkg-deb à la place?
Au final, pourquoi a création d'un paquet, ça ne serait pas juste une cible de compilation, de la même manière qu'on peut ne recompiler qu'un seul des éléments d'un projet?
D'ailleurs, CMake justement permets de générer des paquets Debian ainsi que des installateurs windows si ma mémoire ne me trompe pas. Et je ne serais pas surpris que ça puisse générer des rpm.
[^] # Re: Je n'aime pas
Posté par freem . En réponse à la dépêche E.T. téléphone Meson. Évalué à 5.
À ce que je vois:
Conclusion:
Oui, c'est vrai, la version de Meson semble plus lisible, mais elle semble faire moins de choses, d'une part, et ne pas avoir vieilli. Je suis quasiment sûr à la lecture des deux que la version Meson est une réécriture en se basant sur celle de CMake, et que du coup il n'y à pas les antécédents. Forcément, ça aide à faire plus lisible, mais c'est une comparaison injuste.
Si demain un projet qui utilise Meson depuis plusieurs versions décide d'implémenter le support de CMake, les chances ne sont pas minces pour que le même phénomène se produise, pour moi: c'est facile de faire plus propre quand on à un exemple qui fonctionne (c'est une des raisons pour lesquelles je commence par écrire des PoC de mes codes avant de les reprendre. Le code qui en résulte n'est pas forcément propre, mais il n'est pas dégueulasse comme l'est souvent celui du PoC).
[^] # Re: Merci Pour votre aide
Posté par freem . En réponse au message Quel distribution et quelle de pour un pc tournant de base sous windows 98. Évalué à 3.
Je m'en doutait bien, et je ne suis pas trop rentré dans les détails.
Mais juste histoire de régler un point: un DE (environnement de bureau, pour Desktop Environment), ce ne sont que quelques logiciels configurés pour fonctionner ensemble. Généralement, un gestionnaire de fenêtre, un émulateur de terminal, un éditeur de texte en forment la base, sur laquelle on ajoute un nombre variable d'applications en fonction du besoin.
Le problème est que ça implique une certaine recherche pour trouver les logiciels que l'on veut, et du temps pour qu'ils fonctionnent ensemble plus ou moins harmonieusement.
[^] # Re: Merci Pour votre aide
Posté par freem . En réponse au message Quel distribution et quelle de pour un pc tournant de base sous windows 98. Évalué à 3.
FYI: Le problème n'est pas la vitesse, mais l'occupation mémoire. Ce sont 2 choses très différentes, et justement, utiliser plus de RAM pour avoir de plus gros caches peut permettre d'accélérer un logiciel.
[^] # Re: Une Debian minimaliste peut tourner, avec certaines contraintes.
Posté par freem . En réponse au message Quel distribution et quelle de pour un pc tournant de base sous windows 98. Évalué à 3.
Dans l'ensemble, je suis d'accord avec toi, une distro plus vieille fera mieux l'affaire en terme de performances matérielles, mais ça aura 2 gros inconvénients, surtout qu'on parle de matériel qui est légalement majeur ici:
Pour le SSE2, oui, j'avais remonté le problème aussi, je me souvenais juste plus de la cause exacte. Mais soyons sérieux: avec 64… allez, 150Mo de ram, c'est impossible de faire tourner un navigateur web type firefox ou chromium de toute façon. Il ne reste donc que les alternatives légères, plus ou moins difficiles à utiliser et plus ou moins capable de faire le rendu des sites modernes: uzbl, netsurf, dillo, lynx… et bien d'autres (je note d'ailleurs la suppression des dépôts debian de midori).
Pour la bureautique, sur une machine aussi peu performance, pas le choix, il faut utiliser des alternatives. J'ai cité 2 qui sont plus légères que LO de mémoire en restant accessibles à un utilisateur normal, mais il y en a d'autres plus… «barbues». J'ai essayé de garder l'utilisateur final à l'esprit dans mon message initial :=)
[^] # Re: Activement à la recherche d'un remplaçant
Posté par freem . En réponse à la dépêche Firefox 61 & 62. Évalué à 3.
Dans un genre différent, il y a Otter Browser, pas encore fini et qui se base sur webkit (enfin, son fork je crois… m'y perds) je sais, mais utilisable.
Me semble que netsurf va aussi bientôt intégrer le support de JS, à voir? Je ne sais pas si uzbl est encore maintenu dans la catégorie poids légers (léger, mais avec un gros moteur de rendu… sigh)
[^] # Re: Activement à la recherche d'un remplaçant
Posté par freem . En réponse à la dépêche Firefox 61 & 62. Évalué à 3.
Je pense qu'il fait ici référence au fait d'interdire sans contournement possible les extensions non approuvées (je ne sais pas si c'est encore d'actualité, je ne suis pas un utilisateur d'extensions et j'utilise de toute façon très peu Firefox (et bientôt plus du tout, en fait).
Peut-être fait-il également référence au fait que si l'on consulte une page HTTPS qui inclue des objets qui ne sont pas S, ceux-ci ne s'affichent pas, ce qui implique de devoir passer par la version HTTP de la page. Sur ce point, je trouve le comportement pertinent, cela dit.
# Une Debian minimaliste peut tourner, avec certaines contraintes.
Posté par freem . En réponse au message Quel distribution et quelle de pour un pc tournant de base sous windows 98. Évalué à 3.
Salut.
Comme l'ont dit les autres, il y a un problème dans ta description. Probablement même 2, en fait. Un dual core à 2.2GHz accompagné de 64Mbits de ram, c'est… franchement peu probable.
Déjà, parce que d'aussi longtemps que je me souviennes, la RAM à toujours été exprimée en ordre de grandeur d'octets, pas de bits, et de plus, parce que je me souviens assez bien du 1er PC que j'ai eu en ma possession (pas le 1er que j'ai eu chez moi, hein, le 1er qui m'ait vraiment appartenu), vers 2002, et sans être une bête de course à l'époque, il avait plutôt dans les 512Mo de RAM, pour un CPU du même type, plus ou moins. Je n'utilisais qu'un seul slot de RAM, et j'avais un port AGP pour y coller une carte graphique et donc éviter de partager la RAM.
Avec ce genre de machines, on peut encore avoir un peu de confort.
Avec 64Mo, par contre, c'est plus compliqué, mais faisable:
J'ai un ordinonaure à la maison, quand je l'ai acquis, il ne disposait que de 64Mo de RAM et d'un CPU cadencé à 700MHz, probablement i486 (donc, chromium maintenant ne peux plus du tout être lancé. Cela dis, vue la RAM… xD) et une Debian minimaliste fonctionnait dessus, je pouvais même jouer à wesnoth.
Depuis, j'ai réussi à retrouver une barrette de RAM, et je dépasse les 150 Mo de RAM, c'est un peu plus confortable. Ça fonctionne, oui, mais il ne faut pas rêver, ça va pas vite, et je suis restreint au niveau des logiciels. Si je pouvais mettre la main sur une carte graphique je pense que ça irait mieux quand même (oui, la RAM est partagée du coup).
Au niveau des contraintes, concrètement, prévoir 1G de swap, ça pourra pas faire de mal. Firefox ou autre navigateur moderne? C'est mort, il faut passer sur dillo ou netsurf (voire lynx si vraiment…). La conséquence, c'est que la plupart des sites web «modernes» seront inaccessibles, et les autres (ceux qui n'abusent pas de JavaScript&HTLM5) n'auront pas un rendu de folie, mais enfin, ça marche.
En bureau, je ne vois que la possibilité d'utiliser LXDE, tous les autres seront trop gros, trop lourds. Ou alors faire le sien, mais c'est un truc d'utilisateur avancé ça.
Il vaut mieux remplacer le traditionnel agetty dans /etc/inittab par fgetty, qui n'occupe que 4Kio de «mémoire permanente» (je ne connais plus le terme exact) par instance, et vu que c'est ultra pénible à faire avec systemd, et peut-être impossible à faire proprement sous Debian, ben, je suis d'avis d'installer sysv-init et de dégager systemD, même si ça plaira pas à certains ici. Si la busybox de debian fournissait encore un init, j'aurais même préconisé d'utiliser ce dernier, mais bon…
Pour la bureautique, éviter LibreOffice, gnumerics et abiword sont moins gourmands en RAM de mémoire, et pour les présentations, je conseille d'utiliser tout bêtement des PDF. Pour les générer, je dirais bien d'utiliser LaTeX, vu le système, mais ça nécessite un peu d'apprentissage (avec par contre l'avantage d'avoir un truc qu'il n'y a pas besoin de réapprendre tous les 2 ans, versionnable (mais je pense qu'il s'en fout?), utilisable sur n'importe quel système sans en chier).
En bonus, en lecteur de musique, je conseille mpd + ario (graphique) ou ncmpcpp (dans un terminal, semi-graphique).
Pour conclure, c'est faisable, mais ça nécessite des sacrifices.
Une alternative plus raisonnable à mon avis serait d'acheter un SoS (System on Chip) du genre Raspberry PI ou Beaglebone Black.
[^] # Re: Un nouveau standard ?
Posté par freem . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3.
Hum… un lointain souvenir CSV, vraiment?
# Quelques questions...
Posté par freem . En réponse à la dépêche E.T. téléphone Meson. Évalué à 7. Dernière modification le 08 octobre 2018 à 15:14.
Perso, quand j'essaies d'utiliser CMake (et j'y arrive, tant bien que mal, l'air de rien), je crois que les 2 trucs qui me cassent le plus les pieds c'est:
Autre point qui m'a fait tiquer dans la dépêche:
Euh, vous êtes sérieux la? Non, parce que si j'oublie un ";" après la "}" d'une classe ou structure en C++, l'erreur ne sera pas immédiate, mais arrivera bien après. Donc, c'est la 1ère erreur qui est importante, pas la dernière.
Ce n'est qu'un seul exemple, mais bien souvent dans mon cas les erreurs de compilations se corrigent en cascade, et pas comme un saumon qui remonte sa rivière…
Pour le reste, c'est à voir, si en effet il gère aisément les dépendances externes, ça peut être sympa, parce qu'avec CMake, quand on inclue une dépendance, on sait jamais si c'est LIBRARY, LIBRARIES, le nom n'est jamais trop sûr non plus et aller lire les fichiers qui l'indiquent (qui sont multiples) est bien lourd.
Sauf que, en fait, à bien y réfléchir, ça se fait pas trop mal avec cmake, si on utilise pkg-config, et non leur système intégré (parce que de toute façon, je me suis aperçu avec le temps que je finis toujours par utiliser des libs qui n'exposent pas de fichier cmake au système, alors que les fichiers pour pkg-config c'est la norme sous *nux).
Bon, je reconnaît que l'inconvénient du coup, c'est Windows. Pas comme si Windows n'avait jamais été une plaie dans la gestion des dépendances de build, non plus.
Conclusion pour ce paragraphe: et chez vous, pour exporter une lib, ça marche comment?
Pour ce qui est de ninja, j'ai lu dans le manuel de cmake une rumeur comme quoi il serait aussi supporté. Du coup, vu que la vitesse de meson semble l'argument de «vente» le plus mis en avant, et qu'il est avoué que c'est dû au fait d'utiliser uniquement ninja, ça donne quoi, une comparaison de vitesse à la loyale?
Parce qu'à moi, le fait de supporter un maximum de backend me semble une force, pas une faiblesse. J'avais lu il y a quelques années (dans le contexte de pondre une API de plugins) un papier des gens de chez google qui argumentaient sur le fait que, pour avoir une API à peu près stable et robuste, il fallait au moins 3 outils qui l'implémentent, et que plus il y en a, mieux c'est. Je n'arrive pas à le retrouver, mais ma mémoire m'indique que l'argumentaire était plutôt robuste et convainquant.
[^] # Re: Ahem...
Posté par freem . En réponse à la dépêche Zero-K, un jeu de stratégie temps réel. Évalué à 5.
La dernières fois que j'ai testé, y'a 1 an à peu près, il s'agissait plus d'une démo jouable (pour les gens qui avaient moins de 20 ans en 2000 ;) ) que d'un jeu complet, mais le potentiel est élevé pour être un jeu intéressant (bon, un clone d'un jeu intéressant, certes).
Alors, je ne sais pas quand tu as joué à widelands pour la dernière fois, mais depuis que je connais ce jeu (quelques années, plus de 5) son développement bien que lent (public limité, après tout, alors contributions encore pire, c'est plus un jeu de gestion que de stratégie, reste à définir la limite) il a toujours été développé, genre, 1 release par an. Ces dernières années ont vu, notamment, l'arrivée de la colonisation maritime.
Et, dernier point, je lui préfère settlers 1, je trouve le gameplay du 2 dont il est inspiré trop simple.
De toute façon, ce n'est pas un clone, rien que le fait d'avoir 3 (et bientôt 4) civilisations différentes le différencie. Et ça, ça date pas d'hier.
Ah, pour info, il semble que la future release va avoir 1 nouvelle mission de campagne.
Ah, celui-là, j'aimerai pouvoir y jouer avec une machine normale sans que l'écran d'acceuil ne fasse saturer mon système. Et si, en plus, il pouvait y avoir un tutoriel, histoire qu'on comprenne ou l'on va, alors, je pourrait estimer qu'il a dépassé le statut d'alpha.
Mais non, ça rajoute des civilisations à tout va, des graphismes toujours plus beaux, etc, et l'écran d'accueil rame. Pour afficher un simple menu qui permettrait éventuellement de baisser les graphismes au minimum.
C'est pour les collectionneurs, en même temps, je pense. On parle de l'ancêtre des RTS la quand même.
[^] # Re: RTS libre
Posté par freem . En réponse à la dépêche Zero-K, un jeu de stratégie temps réel. Évalué à 4. Dernière modification le 29 septembre 2018 à 02:56.
Et qui est packagé dans toute la bonne distribution (ouai, la flemme de regarder pour les autres bonne distros). Ce qui implique que l'effort à faire, pour peu qu'on utilise cette distro ou une de ses rares filles, est mineur.
À noter que je n'ai jamais fini la campagne, telllleeeeement longue, qu'en général je perds mes sauvegardes entre 2 périodes de jeu. Ce problème à été résolu en permettant aux joueurs de commencer directement n'importe quelle campagne sans avoir fini les précédentes, ce qui risque bien de me remotiver dès que j'aurais à nouveau une tour :) (je vais p'tet attaquer directement la 3eme, dont je n'ai joué aucun scénario encore)
# openssh?
Posté par freem . En réponse au message tunneleur TLS sortant. Évalué à 3.
openssh devrait faire l'affaire, avec un tunnel.
Et si jamais tu dois, comme moi au taf, te connecter depuis un réseau GPRS dont tu n'as pas la maîtrise, rien n'empêche d'utiliser openssh-client pour faire un tunnel inversé.
Vu que, au taf, j'ai un nombre indéfini et grossissant de systèmes qui se connectent en GPRS, j'ai même pris le parti d'établir un tunnel entre le système distant et un socket sur un serveur. Pour accéder au système distant depuis un autre système distant il faut donc établir un tunnel vers ce socket, en étant connu du serveur, et connaître le nom du fichier qui est, du coup, un peu plus parlant qu'un numéro de port.
[^] # Re: Musiques
Posté par freem . En réponse à la dépêche Sortie de « La bataille pour Wesnoth » 1.14. Évalué à 3.
C'est vrai que l'on parle trop peu de l'atmosphère sonore des jeux libres. Wesnoth est l'un des rares jeux, de manière générale (et pas juste jeux libres), pour lesquels je joue avec la musique du jeu.
Va falloir que je jette une oreille sur ça, du coup, même si j'espère que le thème principal est encore la quand même, vu que pour moi il est un peu emblématique, et quand j'entend les 1ères notes je sais ce que je fais sans avoir besoin de regarder l'écran :D
# zenitram
Posté par freem . En réponse au journal La FSF n-a-t-elle rien compris au libre ?. Évalué à 5.
Ouai, bon, je sais, c'est pas un lieu pour envoyer un message "privé", mais, de manière générale, je me demande si tu as une présence virtuelle "instantanée" en dehors des heures de bureaux heure française? J'aimerai bien discuter avec toi, meme s'il est évident à mes yeux que je n'ai pas grand chose a t'apprendre.
J'ai cru comprendre, au fur et a mesure des échanges (depuis quelques années, certes, mais me faut du temps) que tu vis de toi-même en produisant du logiciel libre, et je serais curieux d'avoir une discussion a ce sujet, si tu le permets.
Ce ne sont pas les moyens qui manque, mais il faut en décider d'un, si tu acceptes.
[^] # Re: La FSF défend le logiciel libre, pas le libre
Posté par freem . En réponse au journal La FSF n-a-t-elle rien compris au libre ?. Évalué à 5.
Ah, bah, c'est donc ça la raison pour laquelle j'ai tendance a te rejoindre.
Sauf que, moi, en pratique, je suis un hypocrite.
Enfin, je file des patchs de temps a autres, mais je ne les suit pas nécessairement, ce sont juste des patchs, qui m'ont pris quelques (dizaines d') heures, mais qui peut potentiellement coûter bien plus a intégrer avec la vision future. J'essaie bien de suivre les règles de codage, mais elles sont rarement explicites, et j'ai tendance a tapper dans l'archi, ce qui est controversé (à raison)
Hum. Je suis persuadé que tu sais que ton opinion intéresse des gens ici. Et puis, si t'es un peu malin, tu sais que la plupart des gens qui réagissent sont les raleurs, non?
[^] # Re: La FSF défend le logiciel libre, pas le libre
Posté par freem . En réponse au journal La FSF n-a-t-elle rien compris au libre ?. Évalué à 3.
Je colles toujours des
//TODO whatever
dans les coins de code qui ne devraient en théorie jamais arriver, mais que je sais que je devrais gérer… je rêve du jour ou je pourrais lire ou écrire un "soft de maître", sans aucun TODO a me repprocher… (en sachant que mes TODO ne représentent pas la totalité des bugs présents, hein)[^] # Re: La FSF défend le logiciel libre, pas le libre
Posté par freem . En réponse au journal La FSF n-a-t-elle rien compris au libre ?. Évalué à 3.
Je me permets de pertinenter pour le fait que tu apportes des explications rationnelles au problème. On a trop tendance a oublier qu'on ne sait pas grand chose, y compris dans notre petite communauté d'amoureux (je pense) de la technique.
Je te remercie donc humblement de ce rappel en puissance (je savais déjà que je suis loin de maîtriser mon domaine d'expertise, mais, ironiquement, j'avais oublié à quel point mon ignorance en dehors était vaste)
[^] # Re: La FSF défend le logiciel libre, pas le libre
Posté par freem . En réponse au journal La FSF n-a-t-elle rien compris au libre ?. Évalué à 3.
Hum, quid du théâtre?
[^] # Re: La FSF défend le logiciel libre, pas le libre
Posté par freem . En réponse au journal La FSF n-a-t-elle rien compris au libre ?. Évalué à 1.
Oh, foutage de gueule ici… ou… allez, non, c'est moi qui exagère, mais, pour m'en convaincre, il te faudra citer plus d'auteurs morts riches, que moi d'auteurs morts dans la misère.
Normalement, vue ma faible culture artistique, je devrais perdre très vite.