Julien Jorge a écrit 590 commentaires

Le directeur technique : « On va utiliser le framework F pour notre app, ça gère le mobile et apparemment on peut aussi générer un site web, une app native, cibler des smartouatch ou faire du WebAssembly. Avec ça on est futur prouffe ».

Le directeur artistique : « on va utiliser une version personnalisée de PoopFontPro2.ttf pour l'interface, c'est pas mal non ? »

Le dev : « Bon j'ai téléchargé leur truc et réussi à faire un POC en twiquant un peu. Ça a l'air de marcher. J'ai dû convertir la fonte mais il y avait quelques glyphes mal fichus que j'ai dû corriger. ».

Le dev senior : « Non mais quelle usine à gaz ! [insérer une référence à "réinventer la roue"] Laisse-moi une semaine et je te vire ce framework et je refais ça dans 42 octets en [insérer une obscure technologie] ».

Le product owner : « J'ai regardé un peu ce qu'il se fait et avec 45 Mo on est plutôt bien placés par rapport aux autres apps du marché. C'est combien la limite de téléchargement hors wifi dans le store ? 500 Mo ? Bon écoute, niveaux priorisation je préfère que tu intègres Firebase pour qu'on ait un peu de métriques rapidement »

Voilà, même quand tout le monde veut bien faire son travail, ça ne donne pas toujours un produit optimal à la fin :)

Il n'y a pas de souci avec l'auto-promo. L'article est dans les clous thématiquement même si le comparatif m'a l'air tout à fait biaisé.

Juste pour alimenter la discution sur la forme, xkcd a une belle représentation de grosses sommes d'argent à base de carrés :)

je me pose la question de savoir si il y a lien

Si tu veux un lien va plutôt dans la rubrique liens. Ici ce sont plutôt des journaux.

J'arrive un peu tard mais je participe quand même.

Alors, s'il vous plaît, dites moi comment vous faites pour échapper à l'enfer des dépendances.

Sur mes petits projets il y a peu de dépendances et pas de conflit de versions. Je prend donc ce qui est disponible sur le système ou alors je compile et j'installe dans ~/.local/. Pendant un moment je m'embêtais à gérer dans mes CMakeLists.txt la possibilité d'utiliser la version locale ou de télécharger la dépendance via FetchContent. C'était une très mauvaise idée, ça fait plein de cas à gérer et amène trop de questions. Du coup maintenant c'est seulement du local, beaucoup plus simple.

Au boulot on a des tonnes et des tonnes de dépendances. Du coup on fait des RPM pour chaque, et je suis bien content de ne pas m'en occuper. Parmi les trucs qui m'embêtent il y a le problème que lorsqu'on modifie une dépendance il faut refaire les RPMs pour toute la chaîne jusqu'au produit pour pouvoir enfin tester, voir qu'on a oublié un truc, re-patcher la dépendance, et recommencer. L'autre souci est que ça devient tellement gros que ça bloque tout le monde sur une distribution donnée. Du coup si t'es sous Windows, ou sous un Linux non corporate, il te faut une VM Linux, ou un Docker, avec la distrib' officielle pour pouvoir travailler. C'est un vrai frein au quotidien, tous les outils deviennent dépassés hyper vite.

Avant ça dans une autre boîte sur un projet plus petit et une petite équipe j'avais pris une approche à base de script. Pour donner une idée de l'échelle, nous étions trois développeurs au maximum et il y avait une petite quarantaine de dépendances. En gros ça ressemblait à ça :

• Du côté du produit final, on avait un fichier listant les dépendances selon la plate-forme ciblée (Android, iOS, OSX, Linux), et un script qui récupérait les dépendances pour les mettre dans un dossier .local du build. Les dépendances pouvaient être des bibliothèques ou des outils de build (par exemple le SDK Android). Les dépendances étaient récupérées au choix uniquement localement ou alors depuis un bucket S3. Il faut voir le dossier .local comme un / dans lequel les dépendances étaient cherchées par le système de build.
• Pour la construction des dépendances on avait un lot de scripts outils et d'autres scripts qui utilisaient ces outils pour faire des archives prêtes à être consommées par le produit. Certaines dépendances étaient des binaires fournis par divers services (par exemple des .framework de régies pub pour iOS), auquel cas on les rangeait juste dans un dossier pratique dans le faux /. D'autres dépendances étaient compilées, installées dans un dossier temporaire puis archivées pour être prêtes à être mises telles quelles dans le faux /.

Dans les aspects bien pratiques :

• chaque développeur pouvait compiler les dépendances nativement pour son système,
• on pouvait surcharger les dépôts des dépendances pour cibler nos dépôts locaux, et ainsi tester des modifs sur des dépendances sans reboucler par le central,
• le build était isolé, pas autant que dans un Docker ou un fakeroot mais suffisamment pour nous,
• les outils de build faisaient partie des dépendances (on avait besoin que de bash, sed, grep, tar, et un compilateur pour lancer le tout, et encore ce dernier pouvait faire partie des dépendances).

Dans les aspects pas pratiques :

• le code des scripts outils n'étaient pas très accueillants pour ceux qui ne sont pas à l'aise en Bash,
• j'aurais dû faire ça en Python pour que ça fonctionne sous Windows (mais en même temps ça demande d'avoir un Python d'installé et on revient au problème du journal ; et puis personne n'utilisait du Windows),
• on a eu quelques mauvaises surprises de link en utilisant sur un système des dépendances compilées sur un autre système,
• je suis quasi sûr que ça ne scale pas avec de plus grandes équipes ou plus de dépendances.

De mon côté je n'ai jamais utilisé Conan ou vcpkg et je me demande si ces outils auraient permis d'installer des dépendances d'outils de build telles que le SDK Android ou autres outils. Ou encore de construire les dépendances à partir de dépôts locaux. Concernant l'intégration dans les outils de build, je ne vois pas trop comment on pourrait par exemple lancer CMake en ciblant Android tout en essayant de récupérer le SDK via Conan intégré à CMake. Ça se mort la queue. Pour moi l'installation des dépendances se fait forcément en amont de la configuration du build. Donc forcément il y a un peu de scripting.

Quel type de machine faut-il pour émuler des jeux Wii U ?

À titre tout à fait personnel ça me donne envi de privilégier rust partout où c'est possible, je sais que ça irrite les développeurs C++, mais si rust c'est des perfs sans pour autant sacrifier à la fiabilité, ça conviendra plus à mes aspirations.

Pas de souci avec le Rust, c'est un super langage qui résout des problèmes du c++ et ne se traîne pas des décennies d'historique :)

Je veux bien voir un bench réaliste qui montrerais l'impact réel de ce genre de trucs.

Que je sache il n'y a pas de tel benchmark, simplement parce qu'on parle d'un coût faible qui ne ressort que lorsqu'on regarde une appli dans son ensemble. Le profiler ne pointera jamais tous les ifs éparpillés dans l'app, mais ça ne veut pas dire que leur coût est négligeable.

Pour moi il y a deux mondes : les logiciels pleins de « on ne sait jamais », « ça sera future proof », « ça coûte moins cher d'acheter une machine plus puissante » ; qui sont la raison pour laquelle on trouve que les ordis d'aujourd'hui prennent plus de temps à faire des choses simples que les ordis d'hier, et de l'autre côté un monde où on ne fait pas ce qui n'est pas essentiel, où on ne s'engage que pour certains cas d'utilisation, et qui tire fortement profit de la puissance des machines.

Du coup en release ta fonction est UB avec une collection vide ? :|

C'est l'idée oui :)

L'UB n'est pas qu'une mauvaise chose, ça veut juste dire que la fonction à un périmètre limité. Il y a plein de situations en UB et on ne met pas des verifications pour tout : le débordement d'un signed int, la comparaison d'itérateurs provenant d'instances de conteneurs différents…

L'assert est très bien pour documenter ces cas et pour servir de garde fou pendant le développement.

Moi je trouve très bien que des boîtes comme Google partagent leurs règles de codage, surtout quand les choix sont justifiés. Sur le plan éthique j'aurais des choses à redire de Google ou Facebook mais sur le plan technique ils ont plus à nous apprendre que l'inverse.

Je me suis d'ailleurs parfois appuyé sur eux (et sur Linux, Mozilla et d'autres) pour justifier certains choix pour lesquels tout le monde a un avis. Puisqu'on ne peut tomber d'accord en interne on va faire comme les autres, et celui qui n'est pas d'accord se charge d'écrire à Mozilla/Google/autre pour leur expliquer qu'ils se débrouillent mal. Ça n'a pas toujours été la solution qui m'arrangeait mais ça permet de débloquer les discussions.

Je sais bien que c'est bien confortable pour eux puisque du coup c'est le reste du monde qui s'adapte à leurs pratiques. Ça leur fait toujours ça de moins à expliquer aux nouvelles recrues. Mais ce n'est pas une bonne raison pour ne pas écouter ce qu'ils ont à dire.

Pour moi les questions à se poser concernant n'importe quelle pratique sont :

• pourquoi les pros font comme ils font ?
• qu'est-ce que ça donnerait à mon échelle ?
• qu'est-ce que ça va me coûter si je change d'échelle ?

Concernant les exceptions en particulier, j'ai vu tellement de cochonneries où elles traversaient justement plusieurs couches et qu'on ne pouvait de toute façon rien en faire, ou, pire, elles étaient lancées et rattrapées dans la même fonction, que je préfère éviter autant que possible. Ce n'est pas une question de perfs, c'est une question d'éviter le bazar et d'éviter le cas du fainéant qui va passer l'erreur à son voisin plutôt que de la gérer lui-même. En fait je me demande si les exceptions ne seraient pas le pire mécanisme de gestion d'erreur qui soit.

Je préfère largement quelqu'un qui ne veut pas mettre d'exception juste parce que Google a dit de ne pas le faire plutôt que quelqu'un qui en met systématiquement parce que son prof, qui n'a jamais écrit que du code confidentiel, lui a présenté ça comme une bonne manière de faire.

Du coup pour un max dans une collection, puisque la solution du max_element est exclue, je mets en précondition que la collection ne soit pas vide. C'est l'appelant qui doit gérer sous peine de comportement indéfini, et comme je suis cool je mets quand même un assert en debug :)

Oui la LGPL c'est une bonne licence pour pousser un peu au partage sans être très contraignant. Perso je la trouve assez fair play, « je partage un truc avec toi et en échange tu partages tes modifs sur le même truc ».

En pratique malheureusement elle m'a l'air aussi impopulaire que la GPL. Entre ceux qui ne veulent que du link statique, ceux qui ne sont pas au courant de la subtilité, ceux qui refusent de remonter leurs patchs, et les boîtes qui craignent qu'un dev embarque un peu vite du code LGPL en statique. Au final il ne reste plus grand monde.

What I don't understand is simultaneously releasing free code with no requirement that it remain free. It can now be used against you and others—if you had moral qualms about that, you could've at least made money off of it yourself.

C'est pourtant simple, il y a peu de raisons qui poussent à utiliser une BSD-like plutôt que la GPL ou du code fermé :

• je considère que le code que j'écris et le code de l'application dans lequel c'est intégré sont deux choses différentes : pas de raison de forcer l'application à suivre la même licence.
• j'ai envie de montrer le code, d'avoir des retours sur ce que je fais, et je ne suis pas particulièrement cupide : pas de raison de faire du code fermé.
• j'aimerais bien qu'il y ait plus de code libre mais je ne veux pas contraindre les gens (chacun sa vie comme on dit). Je montre l'exemple avec une licence ouverte et je ne prends pas la GPL pour éviter le rapport de force.

Par contre je ne vois pas ce que vient faire l'argent dans cette histoire. Ça changerait la légitimité de la licence d'après l'auteur ?

Using a Cuck License especially for "ethical reasons" or "because I like open source software" is beyond absurd. You're simply writing code and effectively abandoning the privileges of intellectual property while allowing any large corporation to come and close-source and monetize your software and sell it back to you without any other obligations.

Ah apparemment c'est effectivement principalement une histoire d'argent.

If you want praise for some contribution, put it in the license. If you don't want your software used for proprietary software, use the GPLv3.

Ah bah voilà, là on est d'accord :)

With Cuck Licenses, you get the worst of two worlds: You get no credit for your work, nor money for licensing fees like other proprietary software and your software will be used to violate your and other users' privacy when it is used in closed-source environments.

… et ça n'aura pas duré longtemps. […] your software will be used to violate your and other users' privacy […] Comme si une licence virale pouvait empêcher la malfaisance. Et puis ce serait plutôt could be used.

If Tanenbaum had released MINIX under the GPL, we wouldn't be at the mercy of Intel's business decision. They would've had to release the source code for the microprocessor, keeping user privacy ensured and irradicating the permanent spyware liability all computers have nowadays.

If they wouldn't want to do that, they'd have to just write an operating system themselves. […] It would've been a lot more respectable to not use a permissive license and instead license it proprietarily if he has no moral issues with proprietary software: he could've at least gotten Intel to pay him to use his operating system. Heck, if he had used the GPL and if they took it anyway, he could become an insta-millionaire by suing them right now.

Bon là j'ai un peu de mal. C'est acceptable qu'Intel installe un logiciel espion s'ils ont payé pour le code ? Devenir riche en faisant un procès à une boîte qui a silencieusement utilisé du code GPL pour faire quelque chose de mal serait une bonne chose ?

Bof bof, beaucoup de colère dans ce post pour pas grand chose. De mon point de vue le choix d'une licence est simple : si tu veux que ça ne soit utilisé que par des logiciels en GPL, utilise la GPL. Si tu veux des retours sur ton code et que ça puisse être utile à tout le monde, utilise une BSD, MIT ou Apache. Si tu veux des retours sur ton code mais ne rien donner, fait de l'open source avec un bon vieux copyright classique. Sinon fait du code fermé.

Même souci ici, et même solution. J'ai du mal à voir l'intérêt de Snap si ce n'est pour participer à la hype Flatpak, AppImage, etc. Ça met une éternité à se lancer, ça consomme des gigas sur le disque, et en plus le sandboxing empêche l'intégration avec d'autres apps (de souvenir c'était galère d'accéder au scanner avec le Flatpak de GIMP).

On nous promet que demain ça sera mieux, qu'on pourra avoir des apps super sécurisées en mode sandboxing avec des permissions (whoaaa !), et pour l'espace disque ben il n'y a qu'à acheter des disques, c'est pas cher ! C'est plus que zéro mais quand même moins cher que… euh… que ce que ça a été il y a 30 ans ?

Et à côté de ça on a une solution qui juste marche : les PPA. À quoi bon s'embêter avec Snap ?

Ce commentaire est sponsorisé par l'AVIRÉPCÉMAV, l'Association des VIeux RÉacs qui Pensent que C'Était Mieux À Vent.

Quid de struct tm, résultat de gmtime() ? Il n'y a pas moyen de changer les champs là dedans sans casser l'ABI. Il faut que le code client et la lib soient d'accord sur la composition de la donnée.

Si je peux changer ma représentation interne d'une classe, ne pas recompiler ceux qui utilisent cette classe et tout de même linker avec c'est qu'il n'y a pas de problème d'abi ?

Ça ne suffit même pas :) Regardez par exemple cette belle lib que l'on va générer en deux versions :

// lib.hpp
#pragma once

struct something
{
  void print() const;
  int a;
};

// lib.cpp
#include <lib.hpp>

#include <cstdio>

void something::print() const
{
  printf("v1 %d, sizeof(*this)=%lu\n", a, sizeof(*this));
}

On compile cela et on envoie le .so au client :

$ g++ -shared -fPIC -I. lib.cpp -o liblib.so

De son côté le client écrit ce programme :

// client.cpp
#include <lib.hpp>

#include <cstdio>

int main()
{
  int a = 32;
  something s{64};
  int b = 128;

  s.print();
  printf("sizeof(s)=%lu\n", sizeof(s));

  return 0;
}

Il compile ça et teste :

$ g++ -I. client.cpp -o client -Wl,-rpath,'$$ORIGIN' -L. -llib
$ ./client
v1 64, sizeof(*this)=4
sizeof(s)=4

Tout va pour le mieux.

Le vendeur de lib fournit maintenant une nouvelle version de sa lib, la version 2, avec deux fois plus de champs dans something.

// lib.hpp
#pragma once

struct something
{
  void print() const;
  int a;
  int b;
};

// lib.cpp
#include <lib.hpp>

#include <cstdio>

void something::print() const
{
  printf("v2 %d, %d, sizeof(*this)=%lu\n", a, b, sizeof(*this));
}

Compilé de la même façon, il envoie le .so au client qui remplace directement l'ancien fichier et relance son programme :

$ ./client
v2 64, 32, sizeof(*this)=8
sizeof(s)=4

Et voilà, le programme se lance bien, il affiche n'importe quoi (la lib voit dans something::b la valeur 32 qui est dans la pile côté client) et on voit que le client et la lib ne sont pas d'accord sur la taille de something.

La mise à jour de la lib n'est pas ABI compatible avec la version précédente et pourtant ça link bien. Sur cet exemple c'est bénin mais en pratique ça cause de sacrés problèmes. Et il ne suffit pas d'ajouter ou supprimer des champs pour causer des soucis, rien que changer l'ordre pose problème.

Le comité subit une sorte de pression pour mettre tout un tas de trucs dans la lib standard parce que tel autre langage a telle possibilité ou parce que tel truc est tendance. Du coup ils ont des propositions pour mettre du networking, une api de dessin 2D (abandonnée), des bases de données (abandonnée aussi il me semble), des ranges (i.e. de la composition d'algos) et 2000 autres trucs parce que Java/Python/Autre langage le fait. Ça devient très, très, très complexe.

À côté de cela on leur demande de livrer un nouveau standard tous les 3 ans parce qu'on a attendu c++0x trop longtemps et qu'on ne veut par subir ça à nouveau. Et puis on aimerait bien être moderne, comme tel autre langage jeune, beau, et tellement cool.

Du coup ils se retrouvent coincés entre livrer un truc bien pensé ou livrer pour qu'on leur lâche la jambe. Le résultat n'est pas toujours heureux.

À cela s'ajoute le fait qu'il s'agit de logiciel et donc fatalement toute décision est une mauvaise décision après un laps de temps suffisamment long.

Personnellement je pense que la lib standard doit être good enough comme on dit, justement parce qu'il n'y aura jamais une implémentation qui satisfait tout le monde. Si on veut aller dans le détail on a toujours la possibilité de prendre une lib à part.

Après pour ce qui est de l'ABI, est-ce vraiment une mauvaise chose que de vouloir éviter de casser l'existant ? Je n'ai pas trop d'avis là dessus.

L'auteur m'a l'air bien agressif pour pas grand chose. Voici les deux paragraphes qui portent l'information :

A few weeks ago, Microsoft quietly updated its Microsoft [app] Store Policies, adding new policies (which go into effect next week), that include this text:

all pricing … must … [n]ot attempt to profit from open-source or other software that is otherwise generally available for free [meaning, in price, not freedom].

Microsoft [argues] that this is about curating content for customers and/or limiting FOSS selling to the (mythical) “One True Developer”. But, even a redrafted policy (that Giorgio Sardo (General Manager of Apps at Microsoft) hinted at publicly early today) will mandate only toxic business models for FOSS (such as demo-ware, less-featureful versions available as FOSS, while the full-featured proprietary version is available for a charge).

Ce que je comprends c'est qu'il y a une nouvelle règle pour ne pas abuser du travail fait par les développeurs de logiciels libres.

Perso je ne vois pas trop la gêne, je suis sûrement influencé par l'opinion d'un grand logiciel libre sur cet excellent site il y a quelques jours :

D'ailleurs en parlant d'utiliser le nom, il y a aussi la problématique de se faire des sous faciles en induisant en erreur les acheteurs. Beaucoup croyaient aider le développement du projet GIMP en payant sur la boutique en ligne. Ce n'était pas forcément une usurpation d'identité claire […], mais beaucoup laissaient simplement un flou suffisant en n'annonçant pas explicitement être un empaqueteur tiers tout en mettant un prix […]. Ce n'était pas agréable que des gens aient ainsi la sensation de se faire arnaquer en utilisant la réputation de notre logiciel.
[…]
Malheureusement force est de constater que des empaqueteurs se contentaient de reprendre notre travail et de le faire payer en gardant le flou sur la provenance. Certes pas illégal, mais un business bien tristounet.

C'est corrigé :) Merci po,ur le journals.

Je connais pas la raison de l'impossibilité d'éditer son journal mais j'ai quand même corrigé le lien :)

Le journal suggère quand même que la cause de l'arrêt d'Atom est le rachat par Microsoft, et que l'arrêt est fait dans le but de favoriser VS Code. Alors certes ce n'est pas « méchant Microsoft » mais ce n'est ni neutre, ni « gentil microsoft » :)

Avec les écrans qu'on a aujourd'hui il n'y a pas de raison de se limiter à 400 lignes. Moi avec mon 50 pouces installé en portrait, je mets une police 6 et je peux afficher 73269 lignes sans problème.

Je comprends ta souffrance et pourtant ça ne me semble pas évident. Quand je repars sur des trucs simples, j'en reviens toujours à ressentir les mêmes effets :

• trop de lignes dans le fichier : « c'est le bordel, ce fichier fait trop de trucs »
• trop de trucs enfouis dans le bazar : « pas moyen d'écrire un test unitaire pour cette fonction déclarée statique au fond d'un fichier avec dépendances à des variables globales » (ça marche aussi avec trop d'encapsulation)
• au bout d'un moment j'en ai marre et je range : « et vas-y qu'il faut que je déplace tout le bazar, et vas-y qu'il y a des dépendances implicites et des raccourcis moisis ».

Alors avec le temps je préfère encore une arborescence plutôt vide qu'un petit tas de trucs empilés en vrac :) La simplicité, je la cherche ailleurs : calmos sur l'OOP, calmos sur la metaprog, calmos sur les dépendances third party (outillage ou libs).

Pour le multi-dépôts je n'ai pas encore tranché. J'aime que ce soit séparé et isolé, mais d'un autre côté le mono-repo est bien confortable pour les refactos et pour retrouver tout le projet dans un état donné.

Au boulot on utilise la stratégie que tu décris. Nous avons environ 30 000 lignes d'assembleur (en utilisant des intrinsèques, ce qui est quand même plus pratique que l'assembleur brut) et la principale motivation est d'avoir ces fonctions aussi optimisées que possible. Le meilleur moyen d'y arriver est de les écrire avec les instructions que nous voulons voir dans le binaire. Le cadre est assez fixe cela dit puisque nous visons un seul couple architecture/compilateur.

Nous avons aussi une version C pour chaque fonction optimisée, à la fois comme fallback mais aussi comme référence pour la version assembleur.

En pratique on remarque que certains compilateurs arrivent à émettre de l'assembleur équivalent à celui écrit à la main depuis fonctions C. Ce n'était pas le cas avec de plus anciennes versions.

Perso je trouve qu'il nous manque quelque chose pour mesurer le gain apporté par les fonctions optimisées, pour voir si elles sont toujours pertinentes. Nous avons des mesures globales, qui englobent toutes les optims, mais rien individuellement. J'ai bien entamé un truc à base de Google Benchmark mais ce n'est pas évident d'avoir un test représentatif des cas d'utilisation réels.

Je l'utilise le plus souvent pour confirmer que le compilateur va bien effectuer certaines optims (genre éviter d'appeler systématiquement une fonction dans une boucle quand son résultat ne dépend pas de l'itération).

Le deuxième cas d'utilisation que j'ai est de comparer les sorties de différents compilateurs.

Et de temps en temps c'est aussi juste pour être impressionné par les transformations d'optimisation.

C'est corrigé, merci :)