liberforce a écrit 4730 commentaires

À la centrifugeuse…

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.

$ conan search jsoncpp -r all
Existing package recipes:

Remote 'conan-center':
jsoncpp/1.0.0@theirix/stable
jsoncpp/1.8.4@theirix/stable
jsoncpp/1.8.4@theirix/testing

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.

Sauf que autotools est beaucoup trop Linux only.

Alors là c’est n’importe quoi.

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):

• http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
• http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/
• http://nibblestew.blogspot.com/2017/05/a-list-of-common-meson-antipatterns.html

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").

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…

Les SCU sont appelées unity builds dans Meson.

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é:

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à.

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.

Tu peux dire tout ce que tu veux, mais les clauses ND (pas de travail dérivé) et NC (pas d’utilisation commerciale) ne sont pas libres. Ça reste plus libre que du code propriétaire, mais ce n'est pas libre. Le logiciel libre permet la libre concurrence. Tous les acteurs, y compris le concepteur d'origine sont sur un pied d'égalité pour améliorer le logiciel, et ne peuvent pas utiliser le droit d'auteur pour avoir un avantage compétitif sur les concurrents. En gros, le principal avantage de l'éditeur, c'est qu'il connait bien le logiciel puisque c'est lui qui l'a écrit, et que donc c'est souvent le plus à même de comprendre sa base de code. Un autre avantage est la confiance en lui qu'il démontre: il pense être suffisamment bon pour pouvoir gérer la concurrence. Il ne cherchera pas à te rendre captif de son logiciel, et t'empêcher volontairement de migrer à une autre solution, il est donc normal que l'utilisateur donne un bonus de confiance à ceux qui jouent le jeu du Libre. C'est un peu comme une relation de couple : il y a des gens qui essaient d'empêcher l'autre de partir, et il y a ceux qui préfèrent donner à l'autre des raisons de rester.

Ensuite, justifier la non-ouverture par les frais de R&D, etc., à ce compte là on peut utiliser les mêmes justifications pour faire du code propriétaire.
https://ploum.net/je-nai-faire-de-votre-business-model/

Bon, tout d'abord les scripts sont fournis dans un fichier compressé .7z, mais le mot de passe n'est pas donné, donc impossible de les lire. Ensuite, si l'extrait fourni est correct c'est juste un pauvre script shell codé avec les pieds qui fait un:

echo password
Oui, même pas un

echo $password
Je pense que Jean-Kévin a encore du boulot avant hacker l'internet…

un playboy Ansible de post-installation de mon OS

Un playboy Ansible c'est un playbook avec les pages qui collent ?

Il y a eu un maximum local en l'an 2000.

Juste parce que je suis en train de lire "Practical vim" :p

    qa09f;wvi":s/\./,/<cr>q
    u
    :%normal @a

Pour les explications:

• on crée une macro enregistrée dans le registre a qui:
  • va en début de ligne (0)
  • cherche ensuite le 9ème point virgule sur la ligne, pour atteindre la 10ème colonne (9f;)
  • sélectionne visuellement le champ correspondant à cette dixième colonne (wvi")
  • remplace le point par une virgule dans la sélection (:s/\./,/\<cr\> — il faut appuyer sur entrée là où il y a écrit <cr>)
  • le dernier q indique que la macro est terminée
• ensuite on annule la modification qu'on vient de faire (u)
• on applique la macro du registre a (@a) à toutes (%) les lignes du fichier en mode normal (:normal)

Profit !

https://www.voidlinux.eu/news/2018/05/irc-back.html

La limite sur la longueur du chemin complet (MAX_PATH) a sauté sous Windows (même si ce n'est pas le cas par défaut):
https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

Ça se fait via la "Group Policy", ou via la base de registre en activant la clé HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled

Ma machine principale est en général Donald, et j'ai déjà eu Gontran, Picsou…

Perso j'ai fait une école d'ingénieur par alternance après un DUT GEII (Génie électrique et informatique industrielle, option électronique).

Si tu travaille déjà, c'est aussi possible de faire de la formation continue en école d'ingénieur. En gros en formation par apprentissage on venait de l'école et on commençait à travailler, et en formation continue tu avais ceux qui travaillaient et voulaient un diplôme pour pouvoir progresser dans leur carrière.

Ensuite, tout dépend de la motivation que tu as à reprendre des études après avoir commencé à travailler, si tu veux reprendre des formations courtes (BTS/DUT) ou plus longues. Mais concrètement en informatique, je te conseille d'aller à BAC+5, parce qu'on demande souvent un profil ingénieur même pour faire le travail d'un technicien.

Je suspecte que du matériel de récup'/ancien va être moins efficace que du matériel neuf/moderne et donc consommer et chauffer plus pour faire la même chose.

Tu ne comptes pas l'énergie, l'eau, les matières premières nécessaires à la production du nouveau matériel, et le recyclage de l'ancien (l'énergie grise). Utiliser du vieux matériel peut être plus écologique que d'utiliser du matériel récent moins consommateur en Watts.

Mouton bouffi de karma !

Bien joué :)

Pour info, cette antisèche a été réalisée par Max Cantor, lors d'une campagne Kickstarter en 2012. C'est lui qu'on voit dans le lien de la présentation "How to Do 90% of What Plugins Do (With Just Vim)" que j'ai mentionné.

Comme dit plus haut, tu as des distributions comme Debian, Ubuntu, Mageia, qui te permettent d'avoir plusieurs versions de vim installées en parallèle. Il y a peut être une version qui gère le presse papier dans slackware, pour que tu ne sois pas obligée d'utiliser gvim si tu ne le souhaites pas, mais je ne sais pas quel paquet tu devrais installer.

En revanche en cherchant un peu, il semble possible de lancer gvim sans le mode visuel, pour avoir un vim dans ton terminal comme tu en as l'habitude. Pour essayer, lance gvim -v dans ton terminal. Si tu as un vim qui se lance sans l'interface déportée de gvim, alors ça marche ;). Il ne te rester plus qu'à rajouter un alias: alias vim='gvim -v'

Si dans ton ~/.bashrc tu as quelque chose comme ça:

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

alors rajoute l'alias à la fin de ton ~/.bash_aliases. Dans le cas contraire, rajoute le à la fin de ton ~/.bashrc. Ferme ensuite ton terminal, rouvre le, et si tu tapes vim, tu devrais te retrouver dans un vim en mode texte géré par gvim (et qui donc gère le presse papier). Pour le vérifier, tape la commande suivante dans vim:

:echo has('clipboard')

Elle devrait t'afficher 1 tout en bas de l'écran, indiquant que la fonctionnalité est activée.