lasher a écrit 2732 commentaires

Oui bon, dans le dernier exemple, je suis allé un peu trop vite (comme quoi le copier-coller c'est mal), et évidemment, la bonne tête de la fonction devrait être :

/* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p2.*/
int intcmp0(const void* p1, const void* p2) 
{
    return *(int*)p1 - *(int*)p2;
}

Cela dit, toutes mes erreurs sont attrapées par le compilateur, du coup je me sens pas trop trop merdeux. :-P
(J'ai même corrigé le commentaire, t'as vu).

La concision dans n'importe quel langage peut se révéler illisible. Je ne connais pas zsh (je ne le pratique pas du tout), donc en effet la ligne que tu fournis m'est hermétique. Pourtant, avant de me dire que franchement, quel est l'idiot qui a écrit la ligne ainsi, je me poserais la question de ce que la ligne fait, et oui, je passerais le temps à essayer de comprendre avant d'émettre une opinion.

Évidemment, en Perl je peux me passer d'utiliser use warnings; use strict;, de même qu'en C je peux écrire un truc du genre

/* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/
int intcmp(const void* p1, const void* p2) 
{
    return *(int*)p1 < *(int*)p2 ? -1 : 
           *(int*)p1 > *(int*)p2 ?  1 :
           0;
}

… qui, malgré l'alignement, est franchement difficile à lire. Ou bien, je peux écrire la même fonction ainsi :

/* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/
int intcmp(const void* p1, const void* p2) 
{
    int i1 = *(int*)p1,
        i2 = *(int*)p2;
    return i1 < i2 ? -1 : 
           i1 > i2 ?  1 :
           0;
}

… Qui est déjà plus lisible.

Bien entendu, pour faire encore plus lisible, il serait sans doute mieux d'écrire ceci :

/* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/
int intcmp(const void* p1, const void* p2) 
{
    int i1     = *(int*)p1,
        i2     = *(int*)p2,
        retval;

    if      (i1 < i2) retval = -1;
    else if (i1 > i2) retval =  1;
    else              retval =  0;
}

Mais au final, la version qui pour moi est la plus lisible et efficace est celle-ci :

/* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/
int intcmp(const void* p1, const void* p2) 
{
    return *(int*)i1 - *(*int*)i2;
}

… Et ça vient, entre autres, de la concision de l'écriture (moins de choses à lire = moins de choses à comprendre).

Évidemment je suis d'accord avec toi pour dire que la concision juste pour la concision est une mauvaise chose¹. Je n'ai aucun problème avec la critique d'un langage (il y a plein de choses à critiquer en Perl, en C, en bash, sans doute en zsh etc.). Mais ta phrase impliquait une généralité sur Perl (et zsh, mais je n'ai pas répondu car je ne connais pas ce shell), ce qui m'a effectivement fait réagir.

[1] et le code que j'ai écris en C comme en Perl dans mon message précédent n'a pas été écrit pour faire « plus joli » ou pour forcer le trait que Perl est lisible : je code à peu près comme ça en Perl.

Es-tu d'accord que des employés de n'importe quelle boite pourraient décider d'aller bosser ailleurs parce qu'ils estiment que leur chef direct est un gros beauf sexiste ? Si oui, il faut considérer les choses comme ceci : un grand nombre d'employés de Mozilla ont fait comprendre qu'il était hors de question pour eux de bosser pour un mec dont les idées allaient « éclabousser » l'image de leur employeur, mais qui en plus ont une différence d'opinion fondamentale sur certains sujets. Et du coup, ils le font savoir : c'est eux, ou lui. S'il était resté, je pense qu'une partie de ces gens auraient dégagé vers d'autres horizons.

Dans les deux cas, il s'agit de liberté : d'opinion, puis d'action.

[maclag] Donc Intel a fait de mauvais processeurs avec des grosses fréquences uniquement pour vendre une supériorité mesurée en GHz.

Pour un académique peut-être. Maintenant, regardons objectivement les choses : même "mauvaise", l'architecture netburst a duré un bon bout de temps, a gentiment augmenté en performances jusqu'à fournir, c'est vrai de petits hauts fourneaux miniature. Maintenant, chez AMD, ils n'ont jamais réussi à avoir un truc qui soit significativement mieux niveau perf. Ca a fait le job, comme on dit.

Ça c'est faux. Au contraire, pour un « académique », le P4 était super bon pour ce qui fait bander les fans d'optimisation de code réguliers : les instructions SSE du P4, et le pipeline allant jusqu'à 33 étages étaient du pain béni pour les applications extrêmement régulières en termes d'accès aux données et avec peu de branchements.

Par contre, pour l'informatique grand public / de gestion, les Athlon XP étaient beaucoup moins chers, et en plus offraient des performances comparables, voire meilleures qu'un P4 de fréquence « équivalente ». Il n'est pas très compliqué de comprendre pourquoi : si le P4 se trompe sur la prédiction de branchement, il doit flusher le pipeline, ce qui implique une pénalité allant jusqu'à 33 cycles. Sur un pipeline plus court (comme ceux d'AMD, qui avaient 12 ou 13 étages), tu as mécaniquement une pénalité moindre. D'ailleurs, la première chose qu'a faite Intel lorsqu'ils ont commencé à travailler sur la micro-architecture du Intel Core, ça a été de ressortir la micro-architecture du Pentium III, et de repartir de là.

Je vois pas ce que ca a de choquant tant qu'il le fait pas au nom de la boite. Il a quand même le droit de voter pour qui il veut ce brave homme non ?

Il ne s'agit pas d'un vote (qui dans des élections serait bien entendu anonyme), mais d'un don fait non seulement avec son nom, mais (comme je l'ai expliqué ailleurs) aussi en apposant le nom de son employeur (comme requis par la loi californienne).

[Concernant l'image de marque] C'est la politique de la boite, pas la sienne. Son boulot a lui comme a tous les salariés, c'est de gérer au mieux la boite.

La fonction de CEO/PDG c'est d'être la « face » de la boite dont tu es à la tête. Ensuite, tu oublies que les employés de Mozilla qui se sont rebellés l'ont fait car une partie est homosexuelle et craint (à juste titre) une possibilité de discrimination contre eux, justement parce qu'il a clairement annoncé ses opinions sur le sujet. Ensuite, il ne faut pas oublier que beaucoup d'employés de Mozilla vivent aux USA, le pays qui vient de passer une loi au Mississipi (et qui a presque réussi à passer la même en Arizona) sur la « liberté de religion » qui autorise les employeurs à refuser que l'assurance maladie qu'ils paient pour leurs employés lorsqu'il s'agit de pilule, car ça va à l'encontre de leurs convictions religieuses.

Donc en plus des problèmes posés par les convictions personnelles mais affichées publiquement par le PDG d'une boite pour l'image de marque d'icelle, il faut à cela rajouter les problèmes potentiels de discrimination qui pourraient survenir pour les employés.

En Californie, la loi impose que tu indiques qui est ton employeur lorsque tu fais un don. Du coup, la fondation a été (indirectement) impliquée, malgré elle. Et donc, lorsque le mec devient PDG de celle-ci, il traîne ses opinions et convictions publiques avec lui, et qu'il le veuille ou non, les associe à celles de son employeur.

Et moi je te dis que c'est idiomatique. Et citer Perl n'est pas forcément une bonne façon de donner du crédit à ton opinion : les gens que j'ai vus critiquer ce langage font partie (la plupart du temps) de ceux qui voudraient que Perl s'écrive comme du C, sans tenir compte — tadaaaa ! — des idiomes propres au langage. Si j'écris

#!/usr/bin/perl
use strict;
use warnings;
use Carp qw/croak/;

croak "USAGE: $0 <filename>" unless (@ARGV);

open (my $fh, '<', $filename) or die "Couldn't open $filename: $!";
my $file_content;
{
    local $/;
    $file_content = <$fh>;
}

do_something_with($file_content);

… Oui, j'estime que $/ et $! font partie des variables de Perl à connaître. De même qu'en C, si j'écris :

#define fatal(...) do {            \
    fprintf(stderr,__VA_ARGS__);   \
    if (errno != 0) perror(errno); \
    exit(errno);                   \
} while(0)

static inline void do_something_with(char* string, off_t sz) {
    string[sz-1] = '\0';
    puts(string);
}

int 
main(int argc, char ** argv)
{
    if (argc != 2) 
        fatal("USAGE: %s <filename>",argv[0]);

    char *filename = argv[1];

    int fd = open(filename,O_RDONLY);
    if (fd == -1) 
        fatal("Couldn't open %s",filename);

    struct stat file_info;
    fstat(fd,&file_info);
    off_t sz = file_info.st_size;

    char *file_content = malloc(sz);
    if (file_content == NULL)
        fatal("Couldn't allocate string of size %lu",sz);

    int nbytes = 0;
    do {
        nbytes = read(fd, file_content, sz);
    } while (nbytes == -1 && errno == EINTR);
    if (nbytes == -1)
        fatal("Couldn't read %lu bytes from %s\n", sz, filename);

    do_something_with(file_content,sz);

    free(file_content);

    return 0;
}

J'estime que le lecteur doit savoir ce que malloc signifie, qu'il sait faire un man fstat s'il n'a jamais rencontré la fonction en question (de même que pour un programme Perl on appellerait perldoc -f *fonction* ou perldoc -q *expression*), etc. Si je voyais ce code pour la première fois, je me demanderais sans doute pourquoi le programmeur s'est fait chier à écrire le read dans un block do-while aussi bizarre¹. Bref, il s'agit de connaître le langage qu'on utilise (pour lire ou écrire).

Donc, histoire d'enfoncer le clou sur cette histoire de décider que Perl est illisible/write-only/bla par définition, je maintiens que quelqu'un qui n'a (par exemple) jamais programmé en C ou en Perl, mais a de l'expérience en Common LISP par exemple, aura sans doute autant de mal à piger un programme que l'autre.

[1] Note que je ne dis pas que cette manière d'écrire soit top-moumoute. C'est juste un exemple à la con qu'on peut trouver (même si généralement des fonctions d'adaptations du genre xmalloc ou xread sont créées pour masquer ce genre de mécanique).

Question stupide : comment on s'en sort si EXIT_FAILURE est 0 et EXIT_SUCCESS 1?

Je cite le bloc de texte complet de la norme concernant exit et EXIT_FAILURE-EXIT_SUCCESS:

Finally, control is returned to the host environment. If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned. If the value of status is EXIT_FAILURE, an implementation-defined form of the status unsuccessful termination is returned. Otherwise the status returned is implementation-defined.

Donc la vraie valeur renvoyée au système par exit n'est pas nécessairement la valeur que tu lui fournis : un 0 peut être transformé en une valeur différente compréhensible par le système hôte.

Pour la question spécifique à EXIT_SUCCESS == 1; EXIT_FAILURE == 0, je n'ai rien vu dans la norme qui l'interdise, SAUF le fait qu'il est explicitement dit que EXIT_SUCCESS ou 0 en entrée signifie « succès », et que EXIT_FAILURE signifie « échec ». Donc si tu files 0 en entrée à exit, tu lui indiques « succès ». Bref, même si la norme n'indique pas explicitement que EXIT_FAILURE ne peut pas valoir 0, je pense que la formulation indique implicitement que ça entrerait en conflit avec la notion de valeur de succès. Une fois que exit a reçu sa valeur par contre, si en « interne » l'OS hôte a décidé que « succès » = 1, et « échec » = 0, c'est justement le boulot de exit de convertir les valeurs pour qu'elles soient correctement transmises au système (je ne sais pas si je suis clair).

D'après le standard de C99 (7.1.4.3—7.1.4.4) et le standard de C11 (7.22.4.5—7.22.4.6) :

Finally, control is returned to the host environment. If the value of status is zero or EXIT_SUCCESS , an implementation-defined form of the status successful termination is returned.

(l'emphase est de moi)

EXIT_FAILURE n'a pas de valeur attitrée, et donc il faut probablement toujours l'utiliser en cas d'erreur dont on n'a pas spécifié de codes spécifiques. Je citais un commentaire sur stackoverflow, mais principalement parce que j'étais d'accord avec le monsieur qui disait en substance « si tu n'utilises jamais EXIT_FAILURE, autant utiliser 0. Mais ne serait-ce que par symétrie, si tu utilises EXIT_FAILURE, autant utiliser EXIT_SUCCESS. »

Donc si, 0 est toujours une valeur correcte pour marquer une sortie sans erreur pour exit.

… Sauf que EXIT_SUCCESS est, aux dernières nouvelles, toujours égal à 0, et pas juste pour POSIX. Pour EXIT_FAILURE, je me range à l'avis de ce monsieur.

Il n'y a aucun argument technique qui pousse à utiliser la version octale, donc faire au plus lisible (quitte à se créer des constantes pour raccourcir)

C'est ce que j'essaie d'expliquer ici : en tant que développeur, je trouve que l'utilisation des valeurs octales est plus claire que l'utilisation des flags. Elle est plus concise, j'y suis habitué depuis avant d'avoir appris à programmer, et en un coup d'œil je peux lire et comprendre la valeur — 0644, 0744, 0700, etc., sont des valeurs que j'ai très vite appris à reconnaître. Pour moi, dans le contexte d'un soft qui ne vise que UNIX (et pire encore, Linux), l'utilisation de la notation octale est idiomatique.

C'est parce que ce sont des gens qui ne savent pas forcément très bien comment fonctionne un compilateur. Autant mon métier m'a appris que la phrase « le compilateur va optimiser pour nous » est relativement fausse dans pas mal de cas, autant j'ai aussi appris dans quels cas le compilo est bien plus intelligent que moi, et qu'il vaut mieux écrire du code « bête », mais qui sera correctement identifié par le compilateur, que faire des trucs bizarres qui vont rendre la lecture difficile à la longue.

Oui oui je sais, tout le monde m'est tombé dessus parce qu'ils n'ont pas compris ce que je voulais dire.

Mais non, on a bien compris que t'aimes pas les valeurs numériques juste parce qu'elles sont numé…

[…] on peut imaginer qu'un jour, on puisse vouloir changer les permissions attribuées au fichier, et ce jour là, il faudra que le patch modifie des trucs partout dans le programme, avec de grosses possibilités de bugs ou de modifs non nécessaires […]

Ah. Je euh. Oui. Effectivement, tu aurais dû commencer par là, parce que je fais partie de ceux qui n'avaient pas compris ton raisonnement. :-) Maintenant, je ne connais pas le code autour, mais je me dis que ce genre de trucs doit être sans doute « isolé » niveau fonctionnalité, et qu'il y a de fortes chances que ce soit le seul endroit où tu aies à changer les valeurs.

En même temps, que ce soit sous ViM ou Emacs, tu as les {c|e}tags. Sous ViM, un coup de C-] pour mater la définition, puis C-t pour revenir à ton bout de code, et c'est plié…

#define PI 3 // Ça va quoi, c'est bien suffisant pour 99% de nos problèmes ! 

[à propos des chemins en dur] Et le jour ou ca change, ils vont faire quoi? grepper sur /run/machin.

Franchement c'est très moyen. Surtout pour un soft dont le code évolue aussi vite, il serait clairement plus prudent d'avoir une constante au moins pour le préfixe. Et comme on parle de (as)printf, tu peux faire des trucs sioux du genre

printf(PATH_PREFIX "/le/reste/de/mon/chemin", ...);

… pour éviter des appels inutiles à str*cat/str*cpy pour des chaînes constantes.

Entre grepper surtout TOUS les fichiers (parce que tu ne sais pas forcément exactement quel fichier source utilise ce préfixe), ou aller changer le préfixe du chemin dans un seul fichier bien identifié (et sans doute documenté), tu penses vraiment que les méthodes sont équivalentes en termes de sûreté et d'efficacité ?

Bon, autant je suis d'accord pour dire qu'il y a plein de trucs qu'on pourrait arranger dans le bout de code cité, autant je fais partie de ceux à qui ont a appris en tant qu'utilisateurs de systèmes UNIX à utiliser chmod 644 monfichier avant de nous dire « ah oui y'a aussi des mnémoniques, comme chmod u+wr,go+r monfichier. D'ailleurs, autant j'utilise volontiers chmod +x toto ou chmod o+r titi, autant il a fallu que je cherche 2 minutes pour connaître la syntaxe de chmod pour attribuer des droits différents pour tous les utilisateurs en une seule fois.

L'utilisation de valeurs octales sous UNIX, dans le contexte de programmation système ne me choque vraiment pas. Dans le contexte d'une application de plus haut niveau, oui, j'utiliserais plutôt les flags qui vont bien.

Oui, tout objet est alloué sur le tas, mais ça ne veut pas dire que lors de l'instanciation d'un objet « pur données », le compilateur n'est pas capable d'en déterminer sa taille et d'allouer juste ce qu'il faut. En d'autres termes, si j'étais en C++, je pourrais faire un truc du genre (pas du tout efficace, mais pour montrer l'idée) :

// Allocation de tous les membres d'une structure sur le tas.
size_t   total_size = sizeof(int) + MAX*sizeof(wchar_t) + sizeof(Titi);
void*    memory     = operator new (total_size);
wchar_t* str        = new((char*)memory+sizeof(int)) wchar_t[MAX];
Titi*    t          = new((char*)memory+sizeof(int)+sizeof(wchar_t)*MAX) Titi;

// ...

*reinterpret_cast<int*>(memory) = 1;
*reinterpret_cast<wchar_t*>((char*)memory+sizeof(int))[0] = 'a';
*reinterpret_cast<Titi*>((char*)memory+sizeof(int)+MAX*sizeof(wchar_t)).someField = ...;

En Java je ne sais pas, mais au niveau système, Linux a tendance à recycler la mémoire allouée par brk (donc des données qui tiennent dans moins d'une page) plutôt que passer par l'allocation depuis une nouvelle page (pour des raisons de perfs évidentes). En fait, tout un tas « d'allocateurs de petits objets » ont été proposés par le passé pour plusieurs plates-formes, comme par exemple dans Modern C++ Design, où Alexandrescu décrit un allocateur de ce genre qui exploite les capacité du « placement new ».

Oui, le fait que tout soit référence est embêtant de ce côté (d'ailleurs, tout habitué que je suis à C++, j'avais oublié de faire new au début, oubliant la référence nulle de départ), et effectivement la copie est ce qui pose problème.

Pour reprendre mon exemple :

public class Toto {
    public int a;
    public char [] str = new char[MAX];
    public Titi t = new Titi();
}

Dans ce cas précis, tout est connu à la compilation, et donc le compilateur pourrait allouer sur le tas un sizeof(int)+sizeof(char)*MAX+sizeof(Titi). Par contre, si j'instancie une "struct" toto, puis que je la passe en paramètre, ou que je l'utilise pour initialiser l'attribut d'un objet, etc., je me retrouve à passer sa référence. Donc il faut explicitement fournir une méthode/une fonction de clonage.

En ce qui concerne le ==, je ne vois pas trop le problème en Java. On n'utilise plus .equals de nos jours ?

Comme j'ai pas fait de Java depuis un bail, j'avais du mal à piger où se situait le problème. De ce que j'ai pu comprendre, le problème d'une « struct » Java serait le suivant :

public class Toto {
    public int a;
    public char [] str = new char[MAX];
    public Titi t = new Titi();
}

Alors qu'en C on écrirait tout bêtement :

struct toto_s {
    int a;
    char str[MAX];
    struct titi t;
};

Du coup j'en déduis que lorsqu'on parle des « structs à la C », on veut parler de la façon d'allouer de façon contiguë la mémoire (et ce, de façon garantie). J'ai bon ? Si oui, j'ai du coup j'ai une question subsidiaire : il me semble relativement trivial pour un compilateur d'estimer l'espace pris par un objet uniquement composé de données. Même "Titi.class" pourrait être annoté directement par le compilateur pour indiquer qu'il n'y a pas de méthodes définies.

Du coup, a-t-on réellement besoin d'un « type » qui soit explicitement des structs « à la C » ?

Et là, tout un tas de profs qui enseignent le lambda calcul saignent des yeux… :-)

Lorsqu'on est célibataire sans enfant, être ingénieur aux US est effectivement une excellent opportunité. Il faut cependant rappeler quelques trucs :

1. La plupart des ingénieurs ne touchent pas 200K$/an, mais plutôt entre 100 et 150K$.
2. Suivant l'état où on bosse, gagner 120K$ peut se révéler beaucoup moins intéressant financièrement que gagner 90K$ dans un autre état (je donne des exemples plus bas).

Oui enfin, il faut compter ~20 à 30K$ par enfant qui va à la fac par an quand même. En supposant que les enfants bossent à côté pour payer le loyer etc. (ce qui est courant aux US). Certes, tu as le temps d'économiser pendant ~18 ans pour ça, mais si tu as déjà 2 gosses, disons avec 3 ans d'écart, il faut quand même économiser pas mal chaque année pour accumuler ~80—120K$ par enfant en vue de leurs études, soit l'équivalent d'une année entière de salaire si on a deux enfants et qu'on gagne environ 200K$/an.

Ensuite, en supposant que tu cherches à vivre dans un coin un peu sympa qui t'évite de prendre trop la voiture, qui soit bien situé niveau commerces, voisinage, etc., tu vas facilement payer ~1500-1800$/mois de loyer (en étant gentil) pour un ~40 à 60m² en fonction de là où tu vis. Évidemment, tu peux aller en coloc, tu peux aussi prendre moins grand, mais quand même, il faut compter 1000$ minimum dans ces coins-là. Donc tu peux soustraire ~10% de ton salaire annuel.

Pour en revenir à ce que je disais sur le salaire annuel vs. la qualité de vie/le pouvoir d'achat : un de mes potes était parti de son poste dans l'état du Delaware, où il touchait ~90K$, pour aller bosser à New-York City, où son salaire était de 120K$. Comme il habitait Manhattan (ce qui, bien sûr est un choix, et il aurait pu décider d'habiter plus loin et passer ~1h dans les transports tous les jours), il payait ~2000$/mois en loyer pour un 30m². Les restaurants étaient relativement moins chers que là où il bossait dans le Delaware, mais pour tout le reste, c'était plus cher : le Delaware n'a pas de TVA.

Enfin, du point de vue de la santé : oui, quand on est ingé dans une boite qui a les sous, on est généralement bien couvert. Ça n'est pas suffisant cependant. On est bien couvert jusqu'à un certain point. Le gamin d'un couple vivant dans l'état du Washington et bossant pour un gros labo national (l'équivalent du CEA) s'est cassé le nez. Entre la chirurgie, les visites chez le médecin (et aux urgences avant cela), etc., ils ont plus ou moins grillé les sous « alloués » par leur police d'assurance pour cette année. On était en Janvier quand ça s'est passé.

Un autre pote, français, vivant aussi dans l'état de Washington était employé en tant qu'ingé dans une grosse boite. Il a contracté une leucémie. Là, deux choses l'ont « sauvé » : d'une part, comme il était employé par une grosse boite qui le payait bien, il avait aussi une super assurance maladie. D'autre part, sa femme est médecin dans un des hôpitaux les plus réputés pour traiter son type de cancer. Au bout d'un an (peut-être un peu plus), sa boite l'a licencié, ce qui est la procédure standard, lorsqu'un employé ne revient pas après cette durée. Du coup, heureusement que sa femme pouvait le couvrir avec son assurance.

À côté de ça, un de mes collègues, postdoc dans mon université, touche un peu moins de la moitié de ce que touche un ingé avec un peu d'expérience (~40K$) dans le Delaware, avec une femme et un gamin. La femme ne bosse pas (elle était ingénieur info en Chine, mais son niveau en Anglais est un peu court pour faire des entretiens pour les US), et comme elle a accouché aux US (pour permettre à leur fils d'avoir la nationalité US), ils ont dû payer des sommes importantes (et continuent de payer), avec un système de santé débile basé sur des « réseaux » (une assurance donnée ne fonctionne que pour un certain nombre d'établissements), ce qui a fait que lorsque le médecin traitant a changé de réseau, il leur a fallu négocier avec le médecin et l'assurance pour continuer à être remboursés. Ah oui, aussi, à moins de payer ~350$/mois, la plupart des assurances ne remboursent pas du tout la même chose que la sécu+mutuelle en France. De plus, il y a toujours une franchise à payer (très souvent autour de ~100$) pour les actes médicaux, et donc lorsqu'on va voir un médecin pour une visite de routine, il faut mettre la main à la poche (et un jour je vous parlerai d'à quoi ressemble un cabinet de médecine aux US).

Maintenant, pour être parfaitement honnête, si la femme de mon collègue arrive à trouver du boulot, elle va sans doute toucher dans les ~50K$/an, ce qui devrait être suffisant pour régler les frais médicaux divers et variés… enfin si son niveau d'Anglais s'améliore.

Ce qui m'amène à ma dernière réflexion, celle qui révèle le socialiss' en moi : certes, à titre individuel, être ingénieur aux USA est (globalement) avantageux. Mais c'est oublier comment le système fonctionne en France : les gens gens qui ont une situation plus aisée que la moyenne aident, grâce aux prélèvements sur salaires, les couches les moins aisées de la population. Aux États-Unis, ce n'est que très peu le cas (sauf à être très pauvre). Je trouve donc qu'aller aux US parce qu'on y est mieux payé, est quelque part un peu hypocrite, car on peut toujours revenir en France et se faire soigner (même si on ne cotise plus à la sécu, même s'il faudra mettre un peu la main à la poche). Mais c'est légal, donc je ne grogne pas trop.

Ce qui m'a personnellement donné envie d'aller aux US n'était pas le fric — un postdoc aux États-Unis gagne mieux qu'un postdoc français la plupart du temps, mais franchement pas grand chose par rapport à un ingé. C'était surtout la possibilité de bosser sur des technologies difficilement atteignables en France. Et oui, si d'aventure je décidais d'aller en Californie et bosser là-bas, je pourrais sans doute prétendre à un salaire >120K$/an, mais ce ne serait honnêtement pas la raison première (même si, il faut bien l'avouer, ça ne gâcherait rien).

Mais il n'est pas cité en tant que contributeur au libre (même en étant cité « depuis » le rapport).

C'est pas une histoire d'Anglais. Par exemple, le champ "Documentation" est juste la a titre informatif? Ou bien est-il possible d'effectuer une action en utilisant un truc du genre "systemd-doc " et ça va appeler la commande man kivabien ?

C'est pour ça que je dis que je comprends l'intention (et oui c'est relativement clair), mais qu'expliquer en détails ce que ça fait, c'est une autre chose.