En même temps au bout de quelques lignes tu vois bien que l'article est un gros troll. Oui il y a des logos moches, m'enfin le pied de GNOME, Wilber la mascotte de GIMP, et le pigeon violet de pidgin me semble des logos reconnaissables et réussis (certes, je ne suis pas graphiste). Ce n'est pas comparable à d'autres logos "moins réussis" montrés dans l'article. Je ne connais pas de projets libre avec un logo tout moche qui refuserait un joli logo soumis par un contributeur. Le problème c'est que les graphistes contributeurs, ça pousse pas sur les arbres.
Je pensais au début que NeoVim interprétait différemment certaines commandes pour les rendre asynchrones, merci de m'avoir détrompé ;). Je ne l'ai pas encore utilisé, c'était plus des souvenirs de lectures...
Ah, effectivement, si tu es sûr que le problème vient du plugin qui n'est pas asynchrone... Je prends bonne note de l'existence de ALE, en tout cas, merci :). N'hésite pas à refaire un journal pour un retour d'expérience ;).
Il me semble que NeoVim n'a plus ces problèmes de lancement synchrone, ça a été rendu asynchrone, ça vaut peut être le coup d'essayer si tu veux conserver ton plugin ?
Tu peux retourner le truc pour dire que justement c'est un outil pour remplir facilement ton temps libre, c'est moins prétentieux du coup ;).
Pour le nom en anglais, effectivement ce serait mieux, mais comme vous utilisez l'abréviation EDT qui n'est de toute façon pas en anglais, autant aller au bout et prendre un nom en français. Le logiciel est multi-langue ?
Je propose TempsLibre, ou TempsLibreEDT. Parce que c'est libre, et que ça fait gagner du temps. Les anglophones ont le problème de sens de "free" (libre/gratuit) dans leur langue, d'où leur utilisation d'Open Source. Toutefois, le français n'a pas ce problème, alors autant préférer "libre" si on donne dans le pur francophone.
81 pièces, 4 pesées et une balance. Il suffit de diviser les pièces en 3 tas, successivement.
Use pesée se fait donc ainsi:
- On divise les pièces suspectes en 3 tas du même nombre de pièces.
- On met le tas n°1 d'un côté de la balance, le tas n°2 de l'autre côté de la balance, et on ne pèse pas le tas n°3.
Comme il n'y a qu'une seule pièce piégée, un des tas est forcément plus lourd que les autres, c'est celui qui contient la pièce piégée.
Au moment de la pesée, 2 possibilités:
- soit la balance est à l'équilibre, ce qui indique que le tas le plus lourd est celui qui n'a pas été pesé
- soit la balance n'est pas à l'équilibre et indique directement le tas le plus lourd
Une pesée permet donc de diviser par 3 le nombre de pièces suspectes. Effectuer 4 pesées successives va donc les diviser par 34 =わ 3 ×ばつかける 3 ×ばつかける 3 ×ばつかける 3 =わ 81. Cela devrait donc effectivement converger:
Après la première pesée, on se retrouve avec 27 pièces suspectes, les autres n'étant pas piégées.
Après la deuxième pesée, on se retrouve avec 9 pièces suspectes, les autres n'étant pas piégées.
Après la troisième pesée, on se retrouve avec 3 pièces suspectes, les autres n'étant pas piégées.
Après la quatrième pesée, on se retrouve avec 1 pièces suspecte, c'est la pièce piégée.
Mais on peut aussi s'arrêter à la 3ème pesée vu qu'on a déjà mis de côté 97,5% du trésor. Cela donne un peu de temps pour écrire un petit mot au dos de celui d'Eingousef:
« Cher Eingousef,
je te remercie d'avoir laissé cette balance de Roberval, et cet indice sur le poids de la pièce. On fait 50/50 comme d'habitude ? En gage de bonne foi, voici les 2 premières pièces, je te laisse le reste à l'endroit convenu.
Signé: M4rotte.
»
Puis je sors avec les 3 pièces (dont la pièce piégée), les place dans le mot plié, et cache le mot dès ma sortie de la banque dans une ruelle sous les poubelles, et m'en vais tranquillement. Je laisse à Eingousef le soin d'expliquer à la police son implication pendant que je dépense une partie de mes 78 pièces pour partir siroter une pina colada sous les tropiques...
Attention! Les moteurs de recherche Google Chrome et Mozilla Firefox savent espionner en secret leurs utilisateurs, avertit un informaticien américain qui a détecté une extension enregistrant tous les sites visités.
Déjà, l'informaticien qui dit que Chrome et Firefox sont des moteurs de recherches, c'est déjà assez énorme. Je suppose que le malheureux journaliste qui a écrit ça a un peu de mal avec l'informatique. Mais le titre en lui même est vraiment trompeur:
Un informaticien US explique comment Chrome et Firefox vous espionnent en secret
On laisse entendre que ce sont Chrome et Firefox qui font l'espionnage (et donc Google et Mozilla) alors que là c'est une société tierce qui fait une extension. Vu l'autre boulette, ça n'a pas l'air d'être fait pour ternir la réputation des navigateurs, mais ça ressemble plus à de l'incompétence.
Le frigidaire ou le congélateur c'est une technique pour globalement éviter qu'un composant endommagé chauffe trop pour permettre d'avoir le temps de récupérer des données, j'ai déjà entendu ça pour des disques durs mécaniques notamment. Pour le four c'est plutôt pour une carte (carte mère, carte graphique, etc.) qui peut avoir une soudure défaillante. Faire chauffer peut faire fondre la soudure en question qui en changeant de forme peut être réparée une fois refroidie. Mais dans le cas d'une carte mémoire, ça me paraît illusoire, et me semble avoir plus de chances d'achever la carte qu'autre chose. En tout cas ce n'est à tenter que quand tout le reste a échoué. Or j'ai parlé plus haut de recoverfab qui peut potentiellement récupérer les données d'une carte du moment qu'elle n'est pas endommagée physiquement. Ce serait donc dommage de griller définitivement la carte avant d'être passé par un service qui a plus de chances de fonctionner.
Ce qui est marqué c'est que le taux de réussite est de 92%, mais que ce taux ne concerne pas les cartes microsd.
Une ligne au dessus tu as un lien vers leur video qui explique le processus de récupération pour du microsd. https://www.youtube.com/watch?v=y-jrzsaT6ls
Un ami qui fait de la récupération de données sur disques durs m'a conseillé ceci: http://recoverfab.com/
Il leur sous-traite la récupération de données sur des cartes mémoires, qui demande du matériel différent. Je n'ai aucune idée du tarif en revanche, mais si tu penses sérieusement contacter une société spécialisée, ils ont l'air de confiance, et peuvent récupérer des données même si la carte n'est plus détectée.
Je ne connais en revanche pas la situation des libs précompilées pour Android, iOS et OSX, mais un conan install jsoncpp/1.8.4@theirix/stable --build=missing sur les plateformes en question devrait te permettre de les builder. Une fois fait, c'est disponible dans ton dépôt local. Il faut toutefois que celui qui a écrit la recette ait prévu un minimum la gestion ces plateformes, si ce n'est pas le cas, tu risques d'avoir quelques bugs et de devoir patcher la recette.
Mais d'un autre côté, je n'ai pas l'impression que l'on ait à modifier le makefile bien souvent, sinon pour ajouter une dépendance, ce qui prend trois secondes.
Sauf quand on l'écrit pour la première fois. Et tu as beaucoup de chances en cherchant sur le net de tomber sur des Makefiles bogués, et donc d'avoir à modifier autre chose que juste une dépendance.
Je ne suis pas d'accord. Autotools sous Windows, ça lance tellement de process que ça rajoute un overhead énorme par rapport à ce que cela fait. Dans le lien donné plus haut sur la migration de GStreamer à Meson, le développeur explique qu'ils ont gagné énormément de temps sur le build Windows (×ばつ 10) par rapport à autotools, sans doute pour cette raison là. Bien sûr, sur des gros projets le temps de build sera largement dominé par le compilateur, mais sur des projets plus petits, la lenteur du build system peut avoir un impact non négligeable.
Ensuite autotools c'est aussi différentes versions de autobidule et autotruc à installer en parallèle parce que non compatibles. Alors oui tu peux faire de la cross-compilation de Linux vers Windows, mais dans ce cas il ne faut s'offusquer qu'on dise que c'est trop "Linux only" (par opposition à Windows, pas par rapport aux autres UNIX).
Ensuite, tu ne pourras à ma connaissance pas builder avec le compilateur de Visual Studio si tu es sous Windows. Si on te donne des bibliothèques proprios pour lesquelles on ne te donne que les binaires et que tu dois t'intégrer avec, tu fais quoi ? Idem pour les symboles de debug différents entre gcc et Visual Studio qui font que tu peux avoir envie d'utiliser un compilateur unique pour être capable de déboguer le bouzin.
Enfin, autotools ne fonctionne qu'avec Make, avec tous les reproches qu'on peut faire sur Make, là où CMake et Meson sont compatibles ninja. Ninja a pour objectif de fournir un format très simple et hautement parallélisable, parce que ce sont les besoins de notre l'époque. De son côté, GNU Make va par défaut chercher des fichiers de logiciels de version obsolètes RCS et SCCS parce qu'il a été développé à une autre époque et qu'il a forcément du "bagage". "bagage" qui n'a pas été jeté parce que la compatibilité à tout prix empêche aussi l'évolution. GNU Make est un très bon logiciel, et tout à fait honorable, mais plus forcément une solution optimale au problème.
CMake et Meson (et bien d'autres sans doute), ça produit des projets pour Visual Studio et Xcode, et ça marche aussi sous Linux. Autotools n'a à ma connaissance pas apporté de solutions à ces problèmes (mais je serais ravi qu'on me pointe des solutions qui seraient passées sous mon radar).
Pour finir, voilà deux liens de l'auteur de Meson sur les reproches qu'il a fait à autotools et CMake, ainsi que des anti patterns Meson (parce qu'aucun outil n'est parfais, les soucis sont juste différents):
Je fais du conan depuis quelques temps, c'est quand même pas mal. Il faut un peu de temps pour déchiffrer leur doc, et j'aurais aimé pouvoir me plonger dedans et faire des retours avant leur version 1.0. Aujourd'hui beaucoup de chose ne peuvent plus changer pour garder la rétro compatibilité, mais ça reste quand même une solution de packaging multi-plateforme que je trouve assez viable et aboutie. La doc parle beaucoup de CMake mais ce n'est pas lié à un unique build system et il y a plusieurs build helpers gérés. Meson est d'ailleurs plus pratique à ce niveau, car le build helper génère juste le fichier .pc utile à pkg-config, alors que les recettes conan utilisant CMake doivent patcher le CMakeLists.txt à la volée si tu veux continuer à pouvoir builder en CMake pur sans conan (chercher replace_in_file dans le "Getting Started").
Meson ce n'est pas que les performances (pour beaucoup dues à ninja):
- lisibilité du code
- disparition des problèmes de quoting de CMake
- activation des warnings par défaut (parce que les débutants ne savent pas qu'il faut les activer, et ne le font donc pas, alors que ce sont ceux qui en ont le plus besoin)
- obligation de fait du build out-of-tree, parce que les développeurs peuvent casser le out-of tree en ne testant que le in-tree
- unique backend ninja: le choix a été fait de ne pas utiliser make, mais ninja qui est plus restreint et plus spécialisé. ninja ne gère que les dépendances, quitte à faire des fichiers verbeux, mais qui ne contiennent pas de logique à évaluer (pas de scripts bash, etc.). En contrepartie, on utilise un générateur de fichier de build ninja, comme Meson ou CMake.
- génération de fichiers pour Xcode ou Visual Studio
- gestion de la cross compilation
- utilisation massive de pkg-config pour la gestion de dépendances
- gestion de sous projets, ce qui permet de télécharger et builder GTK+ et toutes ses dépendances en une passe.
- gestion des SCU ou « unity builds »
Ensuite ce n'est pas une solution magique. Il y a encore des soucis, et j'avais entendu que la gestion d'Android n'était pas son fort, donc ce n'est peut être pas adapté à ton besoin. Mais cela a été assez pour convaincre de nombreux projets de l'utiliser (en migration ou compltément de leur ancien build system):
- GStreamer
- Tracker
- GNOME
- Shotwell
- Mesa
L'auteur peut relicencier à la volée son code. Cela veut dire que s'il possède l'intégralité du droit d'auteur du logiciel (pas de contributions extérieures, ou alors contributions avec cession des droits d'auteur), potentiellement il a toujours le droit de vendre son logiciel sous une licence propriétaire commerciale, et il n'a même pas à t'en informer. C'est une des libertés de l'auteur. Donc un logiciel libre peut avec des clones avec des fonctionnalités non-libres, si tu as réussi à convaincre l'auteur de t'en fournir une version sous une licence propriétaire. Cette possibilité est juste plus mise en avant quand tu as une double licence libre/propriétaire. Elle est aussi moins propice aux contributions, parce que tout le monde n'accepte pas de contribuer en signant un Copyright Assignment.
La licence BSD ne me pose aucun problème. Le code initial a été disponible et chacun a eu l'opportunité de le modifier, et c'est le plus important.
Même si les améliorations ne sont pas diffusées, la concurrence n'est pas faussée sur la partie diffusée sous BSD. Je trouve personnellement les licences sans copyleft moins efficace pour assurer la pérennité d'un logiciel, mais c'est un choix de licence tout à fait pertinent. La liberté du concepteur est préservée sur la partie qu'il a lui même diffusé sous BSD.
Quant à mes définitions "définitives", elles se basent sur ma compréhension des positions de la Free Software Foundation et de l'Open Source Initiative, qui sont les références du genre et disent peu ou prou la même chose. Je ne les ai pas trouvées sous le sabot d'un cheval. Je ne parlais de liberté que dans le contexte logiciel (donc tu penses bien qu'en parlant de "milliers d'années", on sort de ce cadre). Et dans le cas des logiciels, ce qui est considéré comme un Logiciel Libre/Open Source est tout de même très codifié:
Pour le reste, je sais bien qu'il y a 50 nuances de liberté, j'en ai déjà parlé plus longuement il y a longtemps, je ne pense pas vraiment qu'on puisse me reprocher un manque d'ouverture à ce niveau là.
Ne pas oublier aussi que cette concurrence permet aussi aux auteurs initiaux de récupérer un projet qui ne va plus dans le sens qu'ils souhaitent: https://fosdem.org/2018/schedule/event/nextcloud/
Une licence libre protège plus le produit qu'une licence moins permissive.
[^] # Re: Au niveau binaire
Posté par liberforce (site web personnel, Mastodon) . En réponse au message POKER :determiner si une main est une couleur ou non. Évalué à 5.
Oui enfin là ce serait coder en python comme en C, l'intérêt est limité.
[^] # Re: Mouais
Posté par liberforce (site web personnel, Mastodon) . En réponse au lien De la laideur des logos et interfaces dans le libre. Évalué à 10. Dernière modification le 28 août 2018 à 14:14.
En même temps au bout de quelques lignes tu vois bien que l'article est un gros troll. Oui il y a des logos moches, m'enfin le pied de GNOME, Wilber la mascotte de GIMP, et le pigeon violet de pidgin me semble des logos reconnaissables et réussis (certes, je ne suis pas graphiste). Ce n'est pas comparable à d'autres logos "moins réussis" montrés dans l'article. Je ne connais pas de projets libre avec un logo tout moche qui refuserait un joli logo soumis par un contributeur. Le problème c'est que les graphistes contributeurs, ça pousse pas sur les arbres.
Bref, circulez, y a rien à voir.
[^] # Re: NeoVim ?
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal vim: Au revoir syntastic, bonjour ALE. Évalué à 3. Dernière modification le 24 août 2018 à 12:00.
Je pensais au début que NeoVim interprétait différemment certaines commandes pour les rendre asynchrones, merci de m'avoir détrompé ;). Je ne l'ai pas encore utilisé, c'était plus des souvenirs de lectures...
[^] # Re: NeoVim ?
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal vim: Au revoir syntastic, bonjour ALE. Évalué à 3. Dernière modification le 24 août 2018 à 11:58.
Ah, effectivement, si tu es sûr que le problème vient du plugin qui n'est pas asynchrone... Je prends bonne note de l'existence de ALE, en tout cas, merci :). N'hésite pas à refaire un journal pour un retour d'expérience ;).
# NeoVim ?
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal vim: Au revoir syntastic, bonjour ALE. Évalué à 8. Dernière modification le 24 août 2018 à 11:37.
Il me semble que NeoVim n'a plus ces problèmes de lancement synchrone, ça a été rendu asynchrone, ça vaut peut être le coup d'essayer si tu veux conserver ton plugin ?
Cf paragraphe Meet Neovim: Plugin Compatibility.
[^] # Re: inspiration
Posté par liberforce (site web personnel, Mastodon) . En réponse à la dépêche FlOpEDT : un nouveau logiciel libre de gestion des emplois du temps !. Évalué à 4. Dernière modification le 14 août 2018 à 18:55.
Tu peux retourner le truc pour dire que justement c'est un outil pour remplir facilement ton temps libre, c'est moins prétentieux du coup ;).
Pour le nom en anglais, effectivement ce serait mieux, mais comme vous utilisez l'abréviation EDT qui n'est de toute façon pas en anglais, autant aller au bout et prendre un nom en français. Le logiciel est multi-langue ?
[^] # Re: inspiration
Posté par liberforce (site web personnel, Mastodon) . En réponse à la dépêche FlOpEDT : un nouveau logiciel libre de gestion des emplois du temps !. Évalué à 10. Dernière modification le 14 août 2018 à 15:56.
Je propose TempsLibre, ou TempsLibreEDT. Parce que c'est libre, et que ça fait gagner du temps. Les anglophones ont le problème de sens de "free" (libre/gratuit) dans leur langue, d'où leur utilisation d'Open Source. Toutefois, le français n'a pas ce problème, alors autant préférer "libre" si on donne dans le pur francophone.
# Yo Joe !
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal [Énigme] Foutue guerre.... Évalué à 3.
C'était pas ma guerre mon colonel !
# Trichotomie
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal [Énigme] Coffré dans un coffre ?. Évalué à 10. Dernière modification le 13 juillet 2018 à 10:57.
81 pièces, 4 pesées et une balance. Il suffit de diviser les pièces en 3 tas, successivement.
Use pesée se fait donc ainsi:
- On divise les pièces suspectes en 3 tas du même nombre de pièces.
- On met le tas n°1 d'un côté de la balance, le tas n°2 de l'autre côté de la balance, et on ne pèse pas le tas n°3.
Comme il n'y a qu'une seule pièce piégée, un des tas est forcément plus lourd que les autres, c'est celui qui contient la pièce piégée.
Au moment de la pesée, 2 possibilités:
- soit la balance est à l'équilibre, ce qui indique que le tas le plus lourd est celui qui n'a pas été pesé
- soit la balance n'est pas à l'équilibre et indique directement le tas le plus lourd
Une pesée permet donc de diviser par 3 le nombre de pièces suspectes. Effectuer 4 pesées successives va donc les diviser par 34 =わ 3 ×ばつかける 3 ×ばつかける 3 ×ばつかける 3 =わ 81. Cela devrait donc effectivement converger:
Mais on peut aussi s'arrêter à la 3ème pesée vu qu'on a déjà mis de côté 97,5% du trésor. Cela donne un peu de temps pour écrire un petit mot au dos de celui d'Eingousef:
« Cher Eingousef,
je te remercie d'avoir laissé cette balance de Roberval, et cet indice sur le poids de la pièce. On fait 50/50 comme d'habitude ? En gage de bonne foi, voici les 2 premières pièces, je te laisse le reste à l'endroit convenu.
Signé: M4rotte.
»
Puis je sors avec les 3 pièces (dont la pièce piégée), les place dans le mot plié, et cache le mot dès ma sortie de la banque dans une ruelle sous les poubelles, et m'en vais tranquillement. Je laisse à Eingousef le soin d'expliquer à la police son implication pendant que je dépense une partie de mes 78 pièces pour partir siroter une pina colada sous les tropiques...
# Sputnik et crédibilité
Posté par liberforce (site web personnel, Mastodon) . En réponse au lien L'extension stylish pour les navigateurs web vole votre historique. Évalué à 5. Dernière modification le 06 juillet 2018 à 15:40.
https://fr.sputniknews.com/sci_tech/201807061037085316-chrome-securite-web/
Déjà, l'informaticien qui dit que Chrome et Firefox sont des moteurs de recherches, c'est déjà assez énorme. Je suppose que le malheureux journaliste qui a écrit ça a un peu de mal avec l'informatique. Mais le titre en lui même est vraiment trompeur:
On laisse entendre que ce sont Chrome et Firefox qui font l'espionnage (et donc Google et Mozilla) alors que là c'est une société tierce qui fait une extension. Vu l'autre boulette, ça n'a pas l'air d'être fait pour ternir la réputation des navigateurs, mais ça ressemble plus à de l'incompétence.
Comment ça Sputnik n'était déjà pas crédible ?
# Typo
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal LinuxFr.org : seconde quinzaine de juin 2018. Évalué à 2.
# Trainline
Posté par liberforce (site web personnel, Mastodon) . En réponse au message ouisncf et prem's pas fiable. Évalué à 5.
La prochaine fois, essaie trainline.fr (anciennement capitaine-train). L'interface est simple et c'est difficile de se tromper.
[^] # Re: En dernier recours
Posté par liberforce (site web personnel, Mastodon) . En réponse au message Récupération de données sur Lyon. Évalué à 2.
Second degré inside...
Le frigidaire ou le congélateur c'est une technique pour globalement éviter qu'un composant endommagé chauffe trop pour permettre d'avoir le temps de récupérer des données, j'ai déjà entendu ça pour des disques durs mécaniques notamment. Pour le four c'est plutôt pour une carte (carte mère, carte graphique, etc.) qui peut avoir une soudure défaillante. Faire chauffer peut faire fondre la soudure en question qui en changeant de forme peut être réparée une fois refroidie. Mais dans le cas d'une carte mémoire, ça me paraît illusoire, et me semble avoir plus de chances d'achever la carte qu'autre chose. En tout cas ce n'est à tenter que quand tout le reste a échoué. Or j'ai parlé plus haut de recoverfab qui peut potentiellement récupérer les données d'une carte du moment qu'elle n'est pas endommagée physiquement. Ce serait donc dommage de griller définitivement la carte avant d'être passé par un service qui a plus de chances de fonctionner.
https://www.youtube.com/watch?v=y-jrzsaT6ls
[^] # Re: recoverfab
Posté par liberforce (site web personnel, Mastodon) . En réponse au message Récupération de données sur Lyon. Évalué à 4.
Ce qui est marqué c'est que le taux de réussite est de 92%, mais que ce taux ne concerne pas les cartes microsd.
Une ligne au dessus tu as un lien vers leur video qui explique le processus de récupération pour du microsd.
https://www.youtube.com/watch?v=y-jrzsaT6ls
[^] # Re: En dernier recours
Posté par liberforce (site web personnel, Mastodon) . En réponse au message Récupération de données sur Lyon. Évalué à 2.
À la centrifugeuse...
# recoverfab
Posté par liberforce (site web personnel, Mastodon) . En réponse au message Récupération de données sur Lyon. Évalué à 4.
Un ami qui fait de la récupération de données sur disques durs m'a conseillé ceci:
http://recoverfab.com/
Il leur sous-traite la récupération de données sur des cartes mémoires, qui demande du matériel différent. Je n'ai aucune idée du tarif en revanche, mais si tu penses sérieusement contacter une société spécialisée, ils ont l'air de confiance, et peuvent récupérer des données même si la carte n'est plus détectée.
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 3. Dernière modification le 19 juin 2018 à 10:52.
Je ne connais en revanche pas la situation des libs précompilées pour Android, iOS et OSX, mais un
conan install jsoncpp/1.8.4@theirix/stable --build=missingsur les plateformes en question devrait te permettre de les builder. Une fois fait, c'est disponible dans ton dépôt local. Il faut toutefois que celui qui a écrit la recette ait prévu un minimum la gestion ces plateformes, si ce n'est pas le cas, tu risques d'avoir quelques bugs et de devoir patcher la recette.[^] # Re: Make mon ami
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2.
Sauf quand on l'écrit pour la première fois. Et tu as beaucoup de chances en cherchant sur le net de tomber sur des Makefiles bogués, et donc d'avoir à modifier autre chose que juste une dépendance.
[^] # Re: Une défense des autotools
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2. Dernière modification le 15 juin 2018 à 18:17.
Je ne suis pas d'accord. Autotools sous Windows, ça lance tellement de process que ça rajoute un overhead énorme par rapport à ce que cela fait. Dans le lien donné plus haut sur la migration de GStreamer à Meson, le développeur explique qu'ils ont gagné énormément de temps sur le build Windows (×ばつ 10) par rapport à autotools, sans doute pour cette raison là. Bien sûr, sur des gros projets le temps de build sera largement dominé par le compilateur, mais sur des projets plus petits, la lenteur du build system peut avoir un impact non négligeable.
Ensuite autotools c'est aussi différentes versions de autobidule et autotruc à installer en parallèle parce que non compatibles. Alors oui tu peux faire de la cross-compilation de Linux vers Windows, mais dans ce cas il ne faut s'offusquer qu'on dise que c'est trop "Linux only" (par opposition à Windows, pas par rapport aux autres UNIX).
Ensuite, tu ne pourras à ma connaissance pas builder avec le compilateur de Visual Studio si tu es sous Windows. Si on te donne des bibliothèques proprios pour lesquelles on ne te donne que les binaires et que tu dois t'intégrer avec, tu fais quoi ? Idem pour les symboles de debug différents entre gcc et Visual Studio qui font que tu peux avoir envie d'utiliser un compilateur unique pour être capable de déboguer le bouzin.
Enfin, autotools ne fonctionne qu'avec Make, avec tous les reproches qu'on peut faire sur Make, là où CMake et Meson sont compatibles ninja. Ninja a pour objectif de fournir un format très simple et hautement parallélisable, parce que ce sont les besoins de notre l'époque. De son côté, GNU Make va par défaut chercher des fichiers de logiciels de version obsolètes RCS et SCCS parce qu'il a été développé à une autre époque et qu'il a forcément du "bagage". "bagage" qui n'a pas été jeté parce que la compatibilité à tout prix empêche aussi l'évolution. GNU Make est un très bon logiciel, et tout à fait honorable, mais plus forcément une solution optimale au problème.
CMake et Meson (et bien d'autres sans doute), ça produit des projets pour Visual Studio et Xcode, et ça marche aussi sous Linux. Autotools n'a à ma connaissance pas apporté de solutions à ces problèmes (mais je serais ravi qu'on me pointe des solutions qui seraient passées sous mon radar).
Pour finir, voilà deux liens de l'auteur de Meson sur les reproches qu'il a fait à autotools et CMake, ainsi que des anti patterns Meson (parce qu'aucun outil n'est parfais, les soucis sont juste différents):
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2. Dernière modification le 15 juin 2018 à 15:04.
Je fais du conan depuis quelques temps, c'est quand même pas mal. Il faut un peu de temps pour déchiffrer leur doc, et j'aurais aimé pouvoir me plonger dedans et faire des retours avant leur version 1.0. Aujourd'hui beaucoup de chose ne peuvent plus changer pour garder la rétro compatibilité, mais ça reste quand même une solution de packaging multi-plateforme que je trouve assez viable et aboutie. La doc parle beaucoup de CMake mais ce n'est pas lié à un unique build system et il y a plusieurs build helpers gérés. Meson est d'ailleurs plus pratique à ce niveau, car le build helper génère juste le fichier .pc utile à pkg-config, alors que les recettes conan utilisant CMake doivent patcher le CMakeLists.txt à la volée si tu veux continuer à pouvoir builder en CMake pur sans conan (chercher replace_in_file dans le "Getting Started").
[^] # Re: Analyse très subjective!
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 10. Dernière modification le 15 juin 2018 à 12:19.
Je te conseille aussi de lire les objectifs de Meson et ceux de ninja.
Meson ce n'est pas que les performances (pour beaucoup dues à ninja):
- lisibilité du code
- disparition des problèmes de quoting de CMake
- activation des warnings par défaut (parce que les débutants ne savent pas qu'il faut les activer, et ne le font donc pas, alors que ce sont ceux qui en ont le plus besoin)
- obligation de fait du build out-of-tree, parce que les développeurs peuvent casser le out-of tree en ne testant que le in-tree
- unique backend ninja: le choix a été fait de ne pas utiliser make, mais ninja qui est plus restreint et plus spécialisé. ninja ne gère que les dépendances, quitte à faire des fichiers verbeux, mais qui ne contiennent pas de logique à évaluer (pas de scripts bash, etc.). En contrepartie, on utilise un générateur de fichier de build ninja, comme Meson ou CMake.
- génération de fichiers pour Xcode ou Visual Studio
- gestion de la cross compilation
- utilisation massive de pkg-config pour la gestion de dépendances
- gestion de sous projets, ce qui permet de télécharger et builder GTK+ et toutes ses dépendances en une passe.
- gestion des SCU ou « unity builds »
Ensuite ce n'est pas une solution magique. Il y a encore des soucis, et j'avais entendu que la gestion d'Android n'était pas son fort, donc ce n'est peut être pas adapté à ton besoin. Mais cela a été assez pour convaincre de nombreux projets de l'utiliser (en migration ou compltément de leur ancien build system):
- GStreamer
- Tracker
- GNOME
- Shotwell
- Mesa
Mais aussi Xorg, libinput, et d'autres...
[^] # Re: Analyse très subjective!
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Un petit tour des systèmes de build. Évalué à 3.
Les SCU sont appelées unity builds dans Meson.
[^] # Re: Process d'acceptabilité
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Retour sur la licence de NumWorks. Évalué à 2.
L'auteur peut relicencier à la volée son code. Cela veut dire que s'il possède l'intégralité du droit d'auteur du logiciel (pas de contributions extérieures, ou alors contributions avec cession des droits d'auteur), potentiellement il a toujours le droit de vendre son logiciel sous une licence propriétaire commerciale, et il n'a même pas à t'en informer. C'est une des libertés de l'auteur. Donc un logiciel libre peut avec des clones avec des fonctionnalités non-libres, si tu as réussi à convaincre l'auteur de t'en fournir une version sous une licence propriétaire. Cette possibilité est juste plus mise en avant quand tu as une double licence libre/propriétaire. Elle est aussi moins propice aux contributions, parce que tout le monde n'accepte pas de contribuer en signant un Copyright Assignment.
[^] # Re: Libre diffusion ≠ Libre
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Retour sur la licence de NumWorks. Évalué à 6.
La licence BSD ne me pose aucun problème. Le code initial a été disponible et chacun a eu l'opportunité de le modifier, et c'est le plus important.
Même si les améliorations ne sont pas diffusées, la concurrence n'est pas faussée sur la partie diffusée sous BSD. Je trouve personnellement les licences sans copyleft moins efficace pour assurer la pérennité d'un logiciel, mais c'est un choix de licence tout à fait pertinent. La liberté du concepteur est préservée sur la partie qu'il a lui même diffusé sous BSD.
Quant à mes définitions "définitives", elles se basent sur ma compréhension des positions de la Free Software Foundation et de l'Open Source Initiative, qui sont les références du genre et disent peu ou prou la même chose. Je ne les ai pas trouvées sous le sabot d'un cheval. Je ne parlais de liberté que dans le contexte logiciel (donc tu penses bien qu'en parlant de "milliers d'années", on sort de ce cadre). Et dans le cas des logiciels, ce qui est considéré comme un Logiciel Libre/Open Source est tout de même très codifié:
Logiciel_libre
Open_Source_Definition
https://perens.com/2017/09/26/on-usage-of-the-phrase-open-source/
Pour le reste, je sais bien qu'il y a 50 nuances de liberté, j'en ai déjà parlé plus longuement il y a longtemps, je ne pense pas vraiment qu'on puisse me reprocher un manque d'ouverture à ce niveau là.
[^] # Re: Libre diffusion ≠ Libre
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Retour sur la licence de NumWorks. Évalué à 10.
Ne pas oublier aussi que cette concurrence permet aussi aux auteurs initiaux de récupérer un projet qui ne va plus dans le sens qu'ils souhaitent:
https://fosdem.org/2018/schedule/event/nextcloud/
Une licence libre protège plus le produit qu'une licence moins permissive.