louiz’ a écrit 302 commentaires

Ben non, y’a toujours pas de rapport.

de grosses non-désirées

héhéhéhé ;-))))))

Non, c’est effectivement ça, c’est un « while (i-- > 100) » écrit d’une façon amusante qui fait ressembler à une flèche.

Ce n’est pas un opérateur spécial. D’ailleurs ça ne veut effectivement dire « aller jusqu’à » que si c’est dans un while, et que l’on y va en décrémentant la variable.

Cette attitude sexiste se manifeste par plusieurs choses:
- des vannes graveleuse au coeur du code (c'est meme pas un commentaire, c'est la valeur de la constante…)

Et en quoi c’est sexiste ? J’ai toujours pas compris ce qui fait fuir plus les femmes que les hommes, dans les vannes graveleuses.

Si tu trouves que c’est une ambiance puerile, pas pro etc, ok. Mais j’ai pas compris ce qui est sexiste et qui fait fuir les femmes en particulier.

• une discrimination des femmes

Ça ok.

• probablement une myriade d'autres choses

Probablement…

Les hommes sont deranges, certes (et encore, pas tous, visiblement), mains ne sont pas discrimine. C'est comme si tu me disais que la segregation était pas un problème parce que certains blanc sont aussi derange par ce genre de lois, et donc tout le monde part avec le meme désavantage.

Sauf que là, dans la discussion qui nous intéresse, y’a rien qui concerne en particulier les hommes ou les femmes. Et y’a rien dans cette blague qui les sépare ou quoi que ce soit.

Donc oui, y’a du sexisme, mais ça n’a donc aucun rapport avec la blague sur les nichons qu’on trouve dans le code de Linux… Ce qui était un peu la question.

• Qui a dit que les hommes n'étaient pas dérangés par ce genre d'humour?

Ben les gens qui disent que c’est sexiste et que ça donne un désavantage aux femmes. Si les hommes sont également dérangés par ce genre d’humour, alors tout le monde est sur un pied d’égalité et c’est pas une raison pour que les femmes s’intégrent moins facilement à l’équipe de dev.

• L'humour noir est un art difficile, une vanne pareil dans ce contexte est garantie de tomber à plat pour une grande partie de "l'audience". Une fois ta vanne à plat, il reste plus que ce moment gênant ou le lecteur se dit "heuuu, ouais?".

Ouais mais la critique initiale c’était « olala c’est sexiste » ou « olala ça fait fuir les femmes ». Et non pas « olala c’est pas rigolo ». Parce que ouais, c’est pas rigolo, mais c’est pas le sujet.

C’est pas un peu sexiste de considérer que les femmes n’aiment pas l’humour potache, graveleux, ou à caractère sexuel, tandis que les hommes ne sont pas dérangés ?

Une femme va partir avec un gros handicap de respect et va devoir batailler beaucoup plus pour atteindre le même niveau de respect, justement à cause de cette ambiance de gros lourd qui pèse dans la communauté.

À cause du sexisme de certains, qui leur fait penser que les femmes sont moins compétentes, ou que c’est pas fait pour elles, ou qu’elles devraient faire autre chose, ou que « quand même, je vais pas recevoir d’ordre d’une femme ». Ouais.

Par contre une femme va partir avec un gros handicap à cause des… “big boobs” qu’on peut voir dans certains logiciels… ?

Et de toute façon que ça soit sexiste ou pas… si on est contre tou·te·s les deux contre alors c’est bon?

Non, je suis pas spécialement contre. Je trouve que ça craint, voire parfois ça peut m’agacer personnellement. Mais j’ai pas envie d’interdire aux gens de mettre « lol nichons » dans leur code.

Ben c’est une tendance, et une grande majorité des cas.

Mais ouais, y’a des endroits où c’est pas le cas, bien vu.

Le milieu du dev en général, il t'emmerde de ma part.

Oui, effectivement, y’a certains aspects du milieu qui m’emmerdent (notamment le côté « lol alcool, viens j’t’offre une bièèèèère~ »). Mais j’en fais pas une histoire de discrimination contre moi. C’est juste des trucs qui font chier et que j’évite, du coup.

(Et oui, je sais bien que c’est pas ça que t’as voulu dire, mais comme je vois pas pourquoi tu me dis ça, j’ai choisi de répondre de cette manière)

Ça fait partie de la culture geek et tech de prendre voir les femmes — ou une partie — comme des objets. Cet article illustre bien le problème.

C’est marrant, les nichons ça concerne donc que les femmes ? Attention, je vais bientôt te traiter de transphobe.

Parfois c’est « oui mais non, le genre c’est pas une question de biologie ou d’apparence physique » et parfois c’est « quand on admire les nichons et qu’on en parle publiquement c’est qu’on méprise les femmes ». Faut faire un choix.

comme quand Linus compare les logiciels et les femmes («Software is like sex: it’s better when it’s free»)?

Tu vois où la mention de femme ici ?

Et au final, ça fait partie des petits trucs qui donnent l’impression que le noyau Linux est club de mecs et aide pas à se sentir à l’aise là-bas.

Ah oui, ben là par contre c’est vrai. Le noyau linux (et le milieu du dev en général) est un club de mecs, et ça aide pas à se sentir à l’aise là-bas quand on n’aime pas la « culture de mec ». Mais on peut très bien être une femme et aimer tout pareil que les mecs, et se comporter tout pareil, non ? Ou alors j’ai encore mal compris certains trucs :(

Et le noyau linux (et le milieu du dev en général) est un club d’anglophones, pas facile de s’intégrer quand on ne parle pas anglais.

Et le noyau linux (et le milieu du dev en général) est un club de personnes qui aiment l’alcool et se retrouver autour de bières, faire des blagues sur la bière, remercier les gens avec des bières, se bourrer la gueule après les conventions, etc. Pas facile de s’intégrer quand on déteste l’alcool et la bière en particulier.

Et le noyau linux (et le milieu du dev en général) est un club de personnes qui aiment star trek et star wars. Pas facile de s’intégrer quand on n’aime pas ça.

Alors oui, y’a une « culture » particulière dans le milieu, certains aspects sont très chiants et peuvent repousser les gens qui n’aiment pas ces aspects. Oui ça fait chier, mais c’est pas du sexisme.

D’autre part, tolérer des petites choses sexistes mène à perpétuer cette état de fait et à tolérer des gros trucs sexistes. cf. ceci et ceci par exemple.

Oui, le sexisme c’est mal et faut le punir, en parler, le dénoncer et essayer de changer les choses. Mais là c’est pas du sexisme c’est juste une culture à la con (non, ça me fait pas spécialement marrer de lire « lol nichons » dans du code source) qui ne plait apparemment pas à une majorité de femmes.

Trop drôle l’humour sexiste

C’est pas de l’humour sexiste. De l’humour vulgaire, à caractère sexuel, pueril à la rigueur, si tu veux.

vous voyez pas un problème à écrire «gros seins» dans le code source?

Non. Et je t’invite à écrire « 0xP3T1T3_B1T3 » dans le code source de tes logiciels, tout le monde s’en fout, et c’est pas sexiste. C’est graveleux, sexuel, sale, ce que tu veux, mais c’est pas sexiste.

C’est pas comme si des développeuses arrêtaient de contribuer à Linux à cause du sexisme. Ah, si.

« Lassée des injures », « Une contributrice du Kernel Linux a rendu son tablier en raison de l’ambiance jugée malsaine au sein de la communauté. Elle dénonce les propos, brutaux, injurieux et sexistes des responsables au premier rang desquels Linus Torvalds. »

Du coup elle est partie parce qu’elle était lassée des injures et des propos sexistes et brutaux. Pas des références au corps humain dans le code source.

Faire un sous-entendu qui dit « les gonzesses ça soûle, ça sait pas coder en plus elles ont leurs règles beurk et elles sont émotives », ça c’est sexiste. Dire « lol perso j’aime les nibards, pas vrai ?? », c’est pas sexiste. C’est relou à la limite. Mais rien à voir avec le sujet actuel.

pourquoi systématiquement construire le féminin en prenant le masculin et lui ajoutant un suffixe diminutif? Perso je dis simplement «une nerd».

Ok.

Sauf que là, y’a une différence entre savoir qu’en italien on dit « pizze » au pluriels, et dire « je vais commander des pizze ».

Le premier, c’est être cultivé. Le second c’est être un gros relou.

Non, c’est pourri. Au même titre que de dire « une pizza, des pizze » ou « un scenario, des scenarii » ou « des spaghetti, un spaghetto ».

les instances multiples d'un même démon

Tu as un lien vers la doc là dessus ? Ça m’intéresse.

Tu parles des « instanced services units (celles avec un @ dans le nom) » ou rien à voir ?

Ok si tu veux, je vois pas bien le rapport avec ce que je disais, mais oui. Tant que tu as activer les exceptions.

Tant que tu n’as pas désactivé les exceptions.

Ben… non, si t’es admin tu décides quel process est prioritaire et lequel ne l’est pas.

Une façon particulièrement simple d’implémenter cette approche est… de ne rien faire, c’est-à-dire de ne pas vérifier le pointeur renvoyé par les fonctions d’allocation. On laissera simplement le programme segfaulter tout seul lors du déréférencement d’un pointeur nul. J’appellerai ça la méthode « YOLO ».

Le problème c’est que ça va pas forcément crasher, ça peut faire des tas d’autres choses. Perso j’évite d’avoir des UB dans mon code, je préfère largement appeler abort() ou exit() dans un xmalloc.

c’est la possibilité de se passer de bouncer

J'avais cru comprendre que ce n'était pas encore au point (#3116)

Biboumi pose toujours problème si tu essayes de l’utiliser derrière un bouncer.

Mais actuellement, tu peux l’utiliser quasiment comme un bouncer directement, tant que tu laisses au moins un client connecté en permanence au chan (dans le cas de mathieui, je pense qu’il laisse poezio connecté en permanence, et quand il lance son Conversations et qu’il rejoint un chan, biboumi lui balance tous les logs qu’il a ratés).

Dans la 4.0 (qui sort dans peu de temps), biboumi devrait se comporter convenablement derrière un bouncer (en envoyant des invitations à rejoindre le chan, dans le can d’un forced-join venant du bouncer, par exemple).

Dans la 5.0 il pourra rester idle dans un chan même si tous tes clients XMPP sont déconnectés, afin d’agir véritablement comme un bouncer.

l'aide d'un packager debian te permettra de compléter ce qui pourrait manquer

Évidemment. J’attends ce messie avec impatience. :P

Pourquoi tu as 2 numéros de version alors ? Ils représentent quoi ?

Une convention qui a du sens si le paquet est dans des dépôts quelque part (genre ceux de fedora).
Mais dans mon cas, le numéro du paquet ne sert à rien, à part suivre la convention, et faire que ça build (je pourrais laisser -1)

Le changelog non-plus ne sert à rien. Il est là parce que sinon ça ne build pas.

Non j’ai pas de cycle de vie différent. Je tag les releases du logiciel et c’est marre. Le .spec qui marche avec la 3.0, c’est celui qui est présent dans le dépôt git au tag 3.0. Si y’a un bug dans le .spec je le corrige et voilà, si c’est assez dramatique pour nécessiter une nouvelle release, je fais une 3.1 (ce qui ne sera jamais le cas). J’ai pas besoin de faire des tags spéciaux juste parce que y’a des « numéros » dans le fichier .spec.

Tu peut les mettre dans des branches séparées de ton dépôt. Ça apporte pas mal de choses, comme le fait de pouvoir faire vivre les packagings de manière indépendante. Par exemple si tu rencontre un bug dans ton paquet gentoo, tu peux le modifier et le taguer sans toucher au reste.

Au contraire, je vois pas du tout ce que ça apporte.

Le packaging suit de près le code du logiciel, ils ne sont pas indépendants. Par exemple si je rajoute une page de man, je vais mettre à jour le .spec du même coup. Si je rencontre un bug dans mon paquet, ben je peux le modifier sans toucher au reste : il suffit que j’édite le fichier du paquet et pas le reste…
Et si je release une nouvelle version, il faut de toute façon que je mette à jour ce numéro dans le .spec.

Ça se voit bien chez debian justement, qui met 2 numéros de version à chacun de ses paquets (celui du logiciel et celui du paquet).

Oui, chez fedora aussi. Et je fais ça : le numéro du logiciel est dans le CMakeLists.txt, et le numéro du paquet est dans le .spec.

Ok.

Perso, je build automatiquement les paquets à chaque push sur mon dépôt git (j’utilise le ci de gitlab pour ça), par exemple les RPM pour fedora, dans mon projet biboumi
.

Ça me sert à plusieurs choses :

• je sais que mon logiciel est packageable. Je sais par exemple que le make install installe bien la doc, ou ce genre de choses.
• Si un utilisateur veut un rpm de la dernière version, ben il est là. Alors oui, ça marche que pour fedora, parce que c’est ce que je sais faire (et oui, un utilisateur m’a déjà « réclamé » un package, parce qu’il avait la flemme de faire « cmake . » et d’installer les dépendances lui-même)
• Quand je voudrai soumettre le paquet, officiellement, à fedora, ben ça sera déjà fait, et je saurai quand un de mes commits casse mon paquet.

Aussi, si tu n'as pas sous la main toutes les distributions que tu maintiens dans ton application, tu ne peux pas tester tes fichiers de construction de paquets et garantir leur bon fonctionnement.

J’utilise gitlab-ci, et je build mon truc sur fedora et debian (et bientôt sur openBSD, quand j’aurai le temps d’installer mes outils dans la VM). Si la méthode pour générer un .deb n’était pas hyper chiante, j’aurais fait le même process pour génerer un .deb à chaque push automatiquement. Ça aurait servi à vérifier que mon logiciel est également packageable correctement sous debian, et ça aurait pu aider un potentiel packageur debian à se lancer (en voyant que le travail est fait à 95%, ça peut motiver).

Less is more, comme dit. Tu imagines si tu maintiens 50 distributions dans ton dépôt ? J'ose pas imaginer le bordel.

Oui, c’est du travail. J’ai passé du temps à automatiser mes trucs, et j’ai passé du temps à essayer de build des .deb (et un jour je vais peut-être réussir). Mais c’est peut-être plus pratique d’avoir la partie « installation, au sein d’un paquet » dans mon processus d’integration continue, plutôt que de fournir mon code sans jamais tester de le packager, et me taper des bug report d’un packager archlinux qui viendrait me dire « ton makefile est pété, ça n’installe pas la doc ». Ou pire, de jamais être packagé dans aucune distro parce que mon “make install” est juste complètement pété décident d’abandonner mon logiciel parce qu’il serait trop chiant à packager dans leur distro.

Donc non, les .spec et l’eventuel dossier debian/ que je fournis dans mon repository git, ça ne sert pas à me prétendre maintainer de paquets dans les distros associées, ça sert à vérifier que mon logiciel est correct, et motiver un éventuel vrai packageur.

Alors qu'au départ, si tu délègues complètement cette tâche, tu n'as aucun souci.

Ah oui, alors ça, si quelqu’un veut bien me faire un machin debian/ qui fonctionne, le builder lui-même à chaque fois que je push sur git (en étant réactif, si possible) et venir m’annoncer quand j’ai cassé un truc dans mon makefile, ça m’intéresse beaucoup. J’aimerais bien déléguer ça. Sinon j’peux aussi le déléguer à gitlab CI.

Ne pollue pas ton application avec des fichiers de construction pour chaque distribution. Je déteste voir un répertoire debian, des fichiers .spec et autres trucs dans un code source. En plus, qui dit que ton .spec sera compatible fedora, suse, openmandriva ?

C’est quoi que tu détestes ? Avoir un dossier « packaging » qui ne te sert à rien, quand tu fais un git clone… ? C’est si génant que ça ?

(Oui, je demande parce que c’est ce que je fais)