Si vous avez des dépôts mercurial chez eux, il faudra donc envisager une migration, soit vers une autre forge, soit vers git et rester chez bitbucket. Je ne crois pas qu'ils aient développé d'outils spécifique pour migrer facilement un dépôt chez eux (ce qui énerve d'autant plus quantité de développeurs, surtout ceux qui payent et qui se sentent encore plus lésés).
C'est bien ça le pire, je crois.
J'ai moi-même encore un dépôt Mercurial là-bas, après être moi-même passé à Git pour tous mes autres projets pour et mes versionings en local de mes documents, parce que c'est une collaboration de longue date avec une personne qui est encore sous Mercurial et parce que je l'utilisais aussi au moment où j'ai ouvert le dépôt. C'est même ça qui m'a conduit vers BitBucket.
Quand ils en ont annoncé la fin, j'en ai simplement pris acte à titre personnel. Comme dit plus haut, ça faisait longtemps que je ne l'utilisais plus ailleurs. Par contre, je m'attendais à avoir la même chose qu'ailleurs, à savoir un gros bouton « je migre mon dépôt vers Git », que ce soit fait en une fois et que l'on n'en parle plus.
J'ai été assez surpris de ne pas trouver immédiatement de référence vers la procédure à suivre, et assez agacé de me rendre compte, au bout de quelques pages de lecture, que leurs recommandations se résumaient en gros à « bah démerdez vous, je crois qu'il existe un truc par là pour le faire mais pas sûr… ». Du coup, s'il faut se débrouiller soi-même pour tout migrer et qu'il faut rouvrir un nouveau dépôt à la main, aucun intérêt en particulier de rester chez eux plutôt qu'ailleurs.
Seule exception à ce dernier point : la possibilité d'avoir un dépôt privé. C'est utile quand on collabore à développer des choses qui s'appuient sur des ressources non libres. Mais la politique des autres hébergeurs a évolué également depuis cette époque et même Github propose des dépôts privés gratuits jusqu'à trois collaborateurs.
J'ai déjà mal au crâne à la lecture de ton post, mais je crois que le plus insupportable sur le web aujourd'hui, ce n'est plus les titres putaclic mais :
« Le respect de votre vie privée est notre priorité. (Accepter / Refuser) ».
La personne qui a imposé ça à l'Europe entière mérite d'être condamnée à aller elle-même valider chacune des ces notifications à chaque fois qu'elles apparaissent. :-)
J'ai pris le temps de relire le fil en entier en prenant en compte toutes tes interventions et je reconnais que j'ai posté un peu vite… :-)
Certes, on ne mesure pas la performance d'un codeur à la vitesse à laquelle il livre (et ce n'est pas mon chef qui me contredira…). Ça ne se mesure pas non plus en « nombre de lignes de code » livrées. C'est comme « e=mc² » : ça tient en cinq caractères, mais ça représente huit ans de travail, un prix Nobel (bon d'accord, pas directement là dessus) et le fondement de la physique du 20ème siècle (bon, là aussi, ça représente bien plus que ces cinq caractères).
Par contre, je m'inscris farouchement contre le concept de « pisseur de code », comme on dit. Surtout quand c'est en assembleur. Je ne peux laisser personne croire qu'un codeur arrive en « fin de ligne » quand quelqu'un a pensé la chose pour lui.
La performance d'écriture d'un code en soit je ne sais pas trop qui sa passionne. Ça donne des effets pour le quidam, mais faut le mettre en balance avec la qualité qui est produite par exemple pour que ça ait du sens.
Précisément. Un codeur conçoit TOUJOURS ce qu'il fait. Je ne connais personne — même du temps des pupitreurs — qui n'ait été qu'un « traducteur passif » entre une machine et un bureau d'études. Au contraire, je ne pense pas qu'on puisse être bon architecte logiciel sans avoir pratiqué.
Pour un autre domaine que je connais bien, c'est comme si pour faire comprendre la qualité d'athlète de Teddy Riner, on énonçait le nombre de pompes qu'il peut enchainer parce qu'expliquer que gagner des championnat du monde sur une technique différente à chaque combat c'était trop compliqué.
Justement. J'ai bien compris que tu faisais référence aux différentes activités pratiquées à un moment donné, mais présenter la chose de cette façon laisse croire qu'il y a d'un côté des personnes judoka et d'autres des faiseurs de pompes.
Dans le premier cas, je pense qu'on ne peut pas faire l'un sans l'autre. Dans le second, on peut faire des pompes sans être judoka et réciproquement mais dans tous les cas, un « gros faiseur de pompe » ne peut pas ne pas être considéré comme sportif…
"quasiment tous les bug reports que j'ai fait sur le tracker Fedora sont restes sans réponses pour être fermes automatiquement par le bot de fin de vie…"
Le « bot de fin de vie » !
La meilleure métaphore qui soit depuis la Grande Faucheuse… :-)
Comme beaucoup de monde ici, je suis tombé dans l'informatique depuis la pré-adolescence (voire l'enfance). J'ai vu le minitel arriver chez moi, j'ai connu la présentation du TO7 en classe de CP, j'ai écrit mes premiers programmes aux alentours de l'âge de neuf ans, j'ai eu un MO6 à moi à onze, j'ai connu le programme informatique pour tous.
Dans les années 1990, j'ai vu l'essor du PC dans le grand public porté par l'apparition du « multimédia ». Parallèlement, c'était aussi la grande époque des démos. Avec les années 2000, j'ai vu la France entière (le monde aussi, en fait, mais bon) adopter massivement l'informatique et, paradoxalement, sembler en savoir de moins en moins sur le sujet. Avec les années 2010, on a vu la chose devenir carrément politique. Et à présent, l'enjeu à court terme pour le début de la prochaine décennie semble être « la fibre pour tous ».
Je suis toujours développeur de métier aujourd'hui et l'amer constat que j'en fais après plus de trente ans d'exercice est que : ça n'intéresse pas les filles.
Je suis toujours émerveillé de voir comment on cherche à ramener ça au sexisme ou à d'autres vicissitudes avant même de poser ouvertement la question aux principales intéressées.
Ça m'agace parce que j'entends ce son de cloche jusque sur l'antenne d'une grande station de radio nationale alors que les informaticiens sont les premiers à déplorer cet état de fait et que du temps des coding partys évoquées ci-dessus, l'entrée était souvent gratuite pour les filles, justement pour tenter de rétablir un semblant de mixité ou, à tout le moins, permettre aux copines des participants de les accompagner.
À l'inverse, il y a des métiers scientifiques notoirement très féminisés : la bio et la génétique.
Et là, ça ne date pas d'hier non plus. Je me souviens qu'étant encore à l'école primaire au début des années 1980 et lisant des publications pour les enfants de mon âge, j'avais déjà vu dans le courrier des lecteurs celui d'une jeune fille qui souhaitait devenir « généticienne ». C'était peut-être même à cette époque que j'ai découvert le mot et c'était bien avant l'explosion de la bio-informatique.
J'ai travaillé ensuite presque six ans pour un centre de recherche situé sur le/la génopôle d'Évry et le ratio ne laissait pas de place au doute. Environ 75% du personnel était féminin. Par contre, ce rapport était plus qu'inversé dans l'équipe des bio-info. On a réussi à avoir deux jeunes femmes absolument formidables à l'administration système pendant un temps significatif (quelques années). Au développement, on a eu deux contrats cours en six ans.
Bref, j'aimerais bien donner la parole aux filles dans la suite de ce fil, car je sais que LinuxFr a des lectrices même si, ici comme ailleurs, on aimerait qu'elles soient beaucoup plus représentées. Dites-nous ce qui vous attire ou vous effraie.
Il est intéressant de noter qu'une communauté Thomson existe et est encore assez active même en 2018.
L'un des événements, d'ailleurs, est la sortie sur TO8D de cette petite pépite le mois dernier, « mission : lift off ».
30 ans après la fin de la production de ces machines, il devient d'ailleurs difficile de se rendre compte de ce que cela représente de produire cela sur cet appareil. La démo que l'on voit à l'écran présente un jeu qui est en fait au niveau des consoles de la génération suivante.
Il est très difficile de donner une réponse universelle à cette question (ce qui montre au passage qu'elle est justifiée).
Il faut d'abord être précis sur ce que tu entends toi, ici, par « logiciel libre » : un logiciel peut très bien être développé et maintenu dans un cadre professionnel, tout en étant volontairement placé sous licence libre. Dans ce cas, j'ai tendance à penser que le logiciel concerné va être sensiblement de la même qualité que les autres, mais qu'il va bénéficier de fait d'un panel bien plus large de bêta-testeurs. Donc il va converger plus rapidement vers quelque chose de stable, à ressources égales. Et encore, cela n'est vrai que si le public ciblé est suffisamment large. S'il s'agit d'un logiciel libre mais ultra-spécialisé, cela dépendra donc de la valeur de l'équipe initiale.
Si, en revanche, tu entends « logiciel communautaire » vs. « logiciel commercial à code source fermé » et développé en entreprise, là, c'est beaucoup plus flou.
On pourrait gloser longuement sur l'explosion de la dette technique dans les softs soumis à deadlines strictes, sur les bienfaits ou non d'avoir un chef de projet, etc. mais globalement, ce qui est nécessaire à la qualité d'un projet est les ressources, humaines et financières, qu'on lui consacre.
Financièrement, même dans le logiciel libre, les grands projets ont souvent fait l'objet d'une levée de fonds préalable. Et en termes humains, du côté des développeurs, on peut commencer à mesurer ça en années/hommes. Combien de temps faut-il pour que la communauté puisse élever un produit au niveau de celui d'un projet ayant impliqué 500 personnes, par exemple ? Sachant que la branche master du dépôt Git du noyau Linux fait état de 18424 personnes différentes ayant chacune soumis de 1 à 6000 patches, combien faudrait-il de temps au Hurd pour rattraper le même niveau ?
La vraie réponse, à mon avis, est donc qu'un projet libre peut virtuellement s'améliorer jusqu'à atteindre la perfection, mais dans un temps qui, le plus souvent, dépasse sa propre durée de vie (voire même celle de leurs auteurs).
Oui et Vigipirate c'était juste le temps de gérer l'attentat de Saint-Michel.
Ce n'est pas tout-à-fait la même chose ou en tout cas, selon moi, c'est le mauvais exemple : à l'époque, ça aurait vraiment dû être le cas et le plan avait réellement été, progressivement et discrètement, allégé à mesure que l'on s'éloignait des événements. C'est une nouvelle série d'attentats et un contexte géopolitique de plus en plus tendu qui ont conduit à sa « perpétualisation ». Ça vaut le coup d'ailleurs de revoir un peu la chronologie des faits car c'est un vrai phénomène de société.
Mais s'il est vrai que certaines tendances politiques rêvent d'un d'état d'urgence permanent (et pas seulement en France), il est de fait que ça arrangerait tout le monde de pouvoir se passer de Vigipirate, à commencer par le gouvernement, parce que cela coûte cher. Se battre en permanence contre une menace intérieure, c'est comme passer son temps à avoir la fièvre.
Les frais d'inscription tels que décrits dans le présent journal, en revanche, ça ressemble un peu à « se payer sur la bête », comme on dit.
Posté par Obsidian .
En réponse au journal [Énigme] Foutue guerre… .
Évalué à 2.
Dernière modification le 13 juillet 2018 à 17:32.
Le camp se trouve au bout de l’un de ces chemins. A priori, il suffirait d’envoyer un soldat sur chaque sentier pour savoir où est le camp. Seulement on vous a prévenu que parmi les soldats, 1 sur 2 est parfaitement loyal et vous dira toujours la vérité, et l’autre peut à sa guise vous dire la vérité ou mentir (sans logique apparente). Evidemment, vous ne savez pas lesquels vous sont loyaux…
Comment trouver le camp avant la nuit ?
En menaçant d'exécution sommaire tous tes soldats si tu n'es pas au camp d'ici 1h30. Le seul qui osera revenir sera le bon. :)
Je pense qu'on va limiter l'indentation pour éviter d'avoir les effets de poupées russes qui nuisent à la lisibilité.
À noter que ça, ça se fait avec la CSS. Il ne faudrait pas faire l'erreur de limiter ça directement dans le code et perdre de l'information en conséquence.
Comme dit plus haut, c'est malhonnête en soi et personne ne fonctionne au chantage. En plus, dans notre métier en particulier (pourvu que ça dure) les développeurs sont quasiment en situation de plein emploi. Donc, soit le dev est incompétent (il y en a beaucoup plus que l'on croit) au moins sur une techno donnée, soit la compagnie fait déjà des pieds et des mains pour tenter de retenir ses éléments.
Avec ça, il y a un phénomène dont toutes les petites et moyennes structures ont fait l'expérience si elles ont un jour mené un projet de développement : même avec la meilleure volonté du monde, le logiciel devient de toutes façons et de lui-même, soit obsolète soit impossible à maintenir. Même si le dev est un « full stack » et connaît toutes les technologies sur le bout des doigts, il faut toujours au moins 500 jours/homme pour produire quelque chose qui soit réellement abouti sur tous les plans. Même faire de l'intégration, ou être mainteneur de packages pour une distribution, est une activité extrêmement chronophage. Et l'ennui des petites structures, c'est que pour verser un salaire au développeur, il faut vendre vite et si possible beaucoup.
Donc, le dev n'a pas le temps de produire quelque chose d'exhaustif dès le départ. Ce n'est pas du mercantilisme, c'est juste que s'il n'y a pas rapidement une première vente, il n'y aura pas de fond pour poursuivre le développement.
Du coup, les logiciels qui deviennent vraiment pérennes dans le temps sont ceux dont l'équipe a pu atteindre une masse critique, justement parce qu'elle ne dépend pas d'un seul développeur. Donc soit les logiciels de grosses entreprises, avec des équipes et des processus métier bien rodés, soit des projets de logiciel libre qui, par nature, ne sont pas liés au départ à une contrainte de temps et que les personnes intéressées peuvent rejoindre au fur et à mesure de leur avancement.
Et enfin, lorsque l'on arrive à surmonter tout cela, dans le contexte actuel, c'est généralement le développeur qui part de lui-même. Du coup, toutes les sociétés sont déjà habituées à prévoir un plan de repli ou à mettre carrément un projet en sommeil le temps de former une autre équipe.
La meilleure façon, au contraire, de pérenniser son emploi est d'être rentable. Il ne s'agit pas de devenir volontairement une vache à lait bien sûr, mais le meilleur argument pour se rendre « indispensable » est d'être capable d'exhiber ce que ton travail rapporte à la compagnie par rapport à ce que tu lui coûtes. Fort de cela, et si ça marche bien, tu peux essayer de négocier une augmentation pour récupérer ta part du gâteau tout en restant « profitable ».
Et s'il s'avère que justement, « ce n'est pas la politique de la compagnie » ou que tu travailles dans une de ces SSII où le principe est de te payer le minimum en te promettant monts et merveilles jusqu'à ce que tu décides toi-même de mettre un terme à la mascarade, alors au contraire, il faut essayer de perdre le moins de temps possible et essayer rapidement une nouvelle structure. Et pour cela, tu auras besoin à la fois de faire une transmission de compétences pour être libéré rapidement et d'un portfolio pour intégrer facilement un autre poste. Et ça, ce sont deux très bonnes raisons d'écrire le code le plus propre et le plus accessible possible.
Pour finir, sache que la personne qui devra un jour faire face à ton code réellement « obfusqué » sera probablement… toi-même. Entre 20 et 35 ans, on retient en général tout de tête. Après, ça devient difficile. Mais malgré cela, imagine qu'on te place huit mois sur une mission secondaire, puis que tu prennes trois semaines de vacances avant de reprendre ton développement initial. Tu verras alors à quel point il est difficile de se ré-immerger dans son propre travail…
Et… J'ai un compte facebook, et je m'en sers pas mal. Pourquoi ? Parce que c'est un réseau énorme, je galère beaucoup avec ma vie sociale, et ça en améliore sensiblement la qualité. Alors, pour moi, ces infos sont un prix a payé pour la socialisation. J'espère qu'un jour j'aurais une vie sociale suffisamment solide pour pouvoir m'en passer. Aujourd'hui, ce n'est pas le cas. C'est pas un problème d'estime pour ma vie privée donc, c'est un problème d'estime pour ma vie sociale.
C'est dommage, parce que ton commentaire commençait de manière très pertinente, en montrant bien que tout n'est pas blanc ou noir et que, surtout, on peut tout-à-fait faire un usage raisonné et responsable de toute ressource qui nous est accessible.
Par contre, cette dernière phrase résonne comme si Facebook était un « moindre mal » et qu'en plus, elle traduit une grande détresse sous-jacente. Et ça, généralement, c'est justement ce qui fait le côté vicieux de la chose.
Pour identifier les doublons, fdupes effectue une comparaison de taille et de signature MD5 de chaque fichier, et ensuite une comparaison octet par octet est effectuée.
C'est effectivement un cas de figure qui revient fréquemment sur le devant de la scène, UNIX propose d'ailleurs des liens durs pratiquement depuis le début (surtout à une époque où l'espace disque coûtait cher). Et il m'arrive régulièrement de faire ce genre de stats.
Du coup, il me vient idée à l'esprit : puisque les comparaisons de fichiers et le contrôle de leur somme (notamment avec Git), qui implique de les lire linéairement en une fois mais en entier, sont des choses récurrentes, serait-il envisageable d'intégrer cette fonctionnalité directement au système de fichier ? Et si oui, existe-t-il déjà des FS qui le fassent ?
Le stockage sur disque implique déjà l'usage de CRC à très bas niveau (hardware et juste au dessus). Étant donné que les fonction de hachage comme MD5, SHA1, etc. sont de taille fixe et sont faites pour être faciles à calculer, c'est quelque chose que l'on pourrait envisager d'intégrer dans les inodes et que l'on récupérerait ensuite avec stat().
# Migration
Posté par Obsidian . En réponse au journal Bitbucket abandonne les utilisateurs de Mercurial. Évalué à 8.
C'est bien ça le pire, je crois.
J'ai moi-même encore un dépôt Mercurial là-bas, après être moi-même passé à Git pour tous mes autres projets pour et mes versionings en local de mes documents, parce que c'est une collaboration de longue date avec une personne qui est encore sous Mercurial et parce que je l'utilisais aussi au moment où j'ai ouvert le dépôt. C'est même ça qui m'a conduit vers BitBucket.
Quand ils en ont annoncé la fin, j'en ai simplement pris acte à titre personnel. Comme dit plus haut, ça faisait longtemps que je ne l'utilisais plus ailleurs. Par contre, je m'attendais à avoir la même chose qu'ailleurs, à savoir un gros bouton « je migre mon dépôt vers Git », que ce soit fait en une fois et que l'on n'en parle plus.
J'ai été assez surpris de ne pas trouver immédiatement de référence vers la procédure à suivre, et assez agacé de me rendre compte, au bout de quelques pages de lecture, que leurs recommandations se résumaient en gros à « bah démerdez vous, je crois qu'il existe un truc par là pour le faire mais pas sûr… ». Du coup, s'il faut se débrouiller soi-même pour tout migrer et qu'il faut rouvrir un nouveau dépôt à la main, aucun intérêt en particulier de rester chez eux plutôt qu'ailleurs.
Seule exception à ce dernier point : la possibilité d'avoir un dépôt privé. C'est utile quand on collabore à développer des choses qui s'appuient sur des ressources non libres. Mais la politique des autres hébergeurs a évolué également depuis cette époque et même Github propose des dépôts privés gratuits jusqu'à trois collaborateurs.
[^] # Re: Addition
Posté par Obsidian . En réponse au journal Blagues Friday. Évalué à 4.
Oui, mais le logarithme népérien pour attendre…
[^] # Re: Comparer des pommes et des oranges
Posté par Obsidian . En réponse au journal [HS] Quand les français votent avec leur argent. Évalué à 6.
« Tout le monde », ça ne veut pas dire « N'importe qui ».
[^] # Re: Enfin !
Posté par Obsidian . En réponse au journal Une société privée d'investissement achète linuxfr.org et debian.org. Évalué à 10.
… et qu'on pourra s'authentifier avec Facebook ! :-)
[^] # Re: Relativisons...
Posté par Obsidian . En réponse au journal Les compagnies informatiques le détestent. Évalué à 9. Dernière modification le 02 novembre 2019 à 20:45.
J'ai déjà mal au crâne à la lecture de ton post, mais je crois que le plus insupportable sur le web aujourd'hui, ce n'est plus les titres putaclic mais :
« Le respect de votre vie privée est notre priorité. (Accepter / Refuser) ».
La personne qui a imposé ça à l'Europe entière mérite d'être condamnée à aller elle-même valider chacune des ces notifications à chaque fois qu'elles apparaissent. :-)
[^] # Re: Relativisons
Posté par Obsidian . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 2.
J'ai pris le temps de relire le fil en entier en prenant en compte toutes tes interventions et je reconnais que j'ai posté un peu vite… :-)
Certes, on ne mesure pas la performance d'un codeur à la vitesse à laquelle il livre (et ce n'est pas mon chef qui me contredira…). Ça ne se mesure pas non plus en « nombre de lignes de code » livrées. C'est comme « e=mc² » : ça tient en cinq caractères, mais ça représente huit ans de travail, un prix Nobel (bon d'accord, pas directement là dessus) et le fondement de la physique du 20ème siècle (bon, là aussi, ça représente bien plus que ces cinq caractères).
Par contre, je m'inscris farouchement contre le concept de « pisseur de code », comme on dit. Surtout quand c'est en assembleur. Je ne peux laisser personne croire qu'un codeur arrive en « fin de ligne » quand quelqu'un a pensé la chose pour lui.
Précisément. Un codeur conçoit TOUJOURS ce qu'il fait. Je ne connais personne — même du temps des pupitreurs — qui n'ait été qu'un « traducteur passif » entre une machine et un bureau d'études. Au contraire, je ne pense pas qu'on puisse être bon architecte logiciel sans avoir pratiqué.
Justement. J'ai bien compris que tu faisais référence aux différentes activités pratiquées à un moment donné, mais présenter la chose de cette façon laisse croire qu'il y a d'un côté des personnes judoka et d'autres des faiseurs de pompes.
Dans le premier cas, je pense qu'on ne peut pas faire l'un sans l'autre. Dans le second, on peut faire des pompes sans être judoka et réciproquement mais dans tous les cas, un « gros faiseur de pompe » ne peut pas ne pas être considéré comme sportif…
[^] # Re: Relativisons
Posté par Obsidian . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 3.
Tu n'es pas en train de nous dire que c'est mutuellement exclusif, quand même ?
[^] # Re: Photos cultes
Posté par Obsidian . En réponse au journal [HS][Nécrologie] L'ancien président français Jacques Chirac est bronsonnisé.. Évalué à 5.
Il ressemble presque à un James Bond sur ces photos ! Ou au moins un OSS 117… :-)
[^] # Re: Réactivité sur le bug tracker
Posté par Obsidian . En réponse à la dépêche Fedora 31 bêta peut être testé. Évalué à 3.
Le « bot de fin de vie » !
La meilleure métaphore qui soit depuis la Grande Faucheuse… :-)
[^] # Re: Tel Lazare...
Posté par Obsidian . En réponse au journal Les temps changent !! Qui l'aurait cru il y a 20 ans ?. Évalué à 4.
Tu veux probablement dire « Hurd/Xenix » ?
[^] # Re: Benchmark
Posté par Obsidian . En réponse au journal La Banque du futur. Évalué à 4.
Le crypto-cash ? /o\
(Je sors →[]).
[^] # Re: Et si on leur demandait ?
Posté par Obsidian . En réponse au journal Pourquoi les femmes ont déserté l’informatique dans les années 1980. Évalué à 6.
… alors qu'en fait, le bébé est sans doute en train de dire « oh, j'ai fait un gros caca ! » :-)
# Et si on leur demandait ?
Posté par Obsidian . En réponse au journal Pourquoi les femmes ont déserté l’informatique dans les années 1980. Évalué à 10.
Comme beaucoup de monde ici, je suis tombé dans l'informatique depuis la pré-adolescence (voire l'enfance). J'ai vu le minitel arriver chez moi, j'ai connu la présentation du TO7 en classe de CP, j'ai écrit mes premiers programmes aux alentours de l'âge de neuf ans, j'ai eu un MO6 à moi à onze, j'ai connu le programme informatique pour tous.
Dans les années 1990, j'ai vu l'essor du PC dans le grand public porté par l'apparition du « multimédia ». Parallèlement, c'était aussi la grande époque des démos. Avec les années 2000, j'ai vu la France entière (le monde aussi, en fait, mais bon) adopter massivement l'informatique et, paradoxalement, sembler en savoir de moins en moins sur le sujet. Avec les années 2010, on a vu la chose devenir carrément politique. Et à présent, l'enjeu à court terme pour le début de la prochaine décennie semble être « la fibre pour tous ».
Je suis toujours développeur de métier aujourd'hui et l'amer constat que j'en fais après plus de trente ans d'exercice est que : ça n'intéresse pas les filles.
Je suis toujours émerveillé de voir comment on cherche à ramener ça au sexisme ou à d'autres vicissitudes avant même de poser ouvertement la question aux principales intéressées.
Ça m'agace parce que j'entends ce son de cloche jusque sur l'antenne d'une grande station de radio nationale alors que les informaticiens sont les premiers à déplorer cet état de fait et que du temps des coding partys évoquées ci-dessus, l'entrée était souvent gratuite pour les filles, justement pour tenter de rétablir un semblant de mixité ou, à tout le moins, permettre aux copines des participants de les accompagner.
À l'inverse, il y a des métiers scientifiques notoirement très féminisés : la bio et la génétique.
Et là, ça ne date pas d'hier non plus. Je me souviens qu'étant encore à l'école primaire au début des années 1980 et lisant des publications pour les enfants de mon âge, j'avais déjà vu dans le courrier des lecteurs celui d'une jeune fille qui souhaitait devenir « généticienne ». C'était peut-être même à cette époque que j'ai découvert le mot et c'était bien avant l'explosion de la bio-informatique.
J'ai travaillé ensuite presque six ans pour un centre de recherche situé sur le/la génopôle d'Évry et le ratio ne laissait pas de place au doute. Environ 75% du personnel était féminin. Par contre, ce rapport était plus qu'inversé dans l'équipe des bio-info. On a réussi à avoir deux jeunes femmes absolument formidables à l'administration système pendant un temps significatif (quelques années). Au développement, on a eu deux contrats cours en six ans.
Bref, j'aimerais bien donner la parole aux filles dans la suite de ce fil, car je sais que LinuxFr a des lectrices même si, ici comme ailleurs, on aimerait qu'elles soient beaucoup plus représentées. Dites-nous ce qui vous attire ou vous effraie.
[^] # Re: VEOLIA OFFICIEL
Posté par Obsidian . En réponse au journal Un recrutement racé chez VEOLIA. Évalué à 5.
« Veolia_Officiel », aujourd'hui, ça fait un peu groupe de RnB mais merci pour le complément d'information. :-)
[^] # Re: La page en question
Posté par Obsidian . En réponse au journal Le domaine linux.org détourné. Évalué à 7. Dernière modification le 10 décembre 2018 à 01:30.
Je dirais même que ça manque d'audace ! :-)
# Ça continue !
Posté par Obsidian . En réponse au journal Comment on codait un jeu sur un ordi 8 bits dans les années 1980s. Évalué à 5.
Il est intéressant de noter qu'une communauté Thomson existe et est encore assez active même en 2018.
L'un des événements, d'ailleurs, est la sortie sur TO8D de cette petite pépite le mois dernier, « mission : lift off ».
https://www.youtube.com/watch?v=47ZuQm4XWew
30 ans après la fin de la production de ces machines, il devient d'ailleurs difficile de se rendre compte de ce que cela représente de produire cela sur cet appareil. La démo que l'on voit à l'écran présente un jeu qui est en fait au niveau des consoles de la génération suivante.
# Durée de vie
Posté par Obsidian . En réponse au journal Un logiciel libre devient-il meilleur qu'un logiciel propriétaire dans la durée ?. Évalué à 9.
Il est très difficile de donner une réponse universelle à cette question (ce qui montre au passage qu'elle est justifiée).
Il faut d'abord être précis sur ce que tu entends toi, ici, par « logiciel libre » : un logiciel peut très bien être développé et maintenu dans un cadre professionnel, tout en étant volontairement placé sous licence libre. Dans ce cas, j'ai tendance à penser que le logiciel concerné va être sensiblement de la même qualité que les autres, mais qu'il va bénéficier de fait d'un panel bien plus large de bêta-testeurs. Donc il va converger plus rapidement vers quelque chose de stable, à ressources égales. Et encore, cela n'est vrai que si le public ciblé est suffisamment large. S'il s'agit d'un logiciel libre mais ultra-spécialisé, cela dépendra donc de la valeur de l'équipe initiale.
Si, en revanche, tu entends « logiciel communautaire » vs. « logiciel commercial à code source fermé » et développé en entreprise, là, c'est beaucoup plus flou.
On pourrait gloser longuement sur l'explosion de la dette technique dans les softs soumis à deadlines strictes, sur les bienfaits ou non d'avoir un chef de projet, etc. mais globalement, ce qui est nécessaire à la qualité d'un projet est les ressources, humaines et financières, qu'on lui consacre.
Financièrement, même dans le logiciel libre, les grands projets ont souvent fait l'objet d'une levée de fonds préalable. Et en termes humains, du côté des développeurs, on peut commencer à mesurer ça en années/hommes. Combien de temps faut-il pour que la communauté puisse élever un produit au niveau de celui d'un projet ayant impliqué 500 personnes, par exemple ? Sachant que la branche master du dépôt Git du noyau Linux fait état de 18424 personnes différentes ayant chacune soumis de 1 à 6000 patches, combien faudrait-il de temps au Hurd pour rattraper le même niveau ?
La vraie réponse, à mon avis, est donc qu'un projet libre peut virtuellement s'améliorer jusqu'à atteindre la perfection, mais dans un temps qui, le plus souvent, dépasse sa propre durée de vie (voire même celle de leurs auteurs).
[^] # Re: Bon
Posté par Obsidian . En réponse au journal Écoles d'ingénieurs: les frais augmentent. Évalué à 2.
Ce n'est pas tout-à-fait la même chose ou en tout cas, selon moi, c'est le mauvais exemple : à l'époque, ça aurait vraiment dû être le cas et le plan avait réellement été, progressivement et discrètement, allégé à mesure que l'on s'éloignait des événements. C'est une nouvelle série d'attentats et un contexte géopolitique de plus en plus tendu qui ont conduit à sa « perpétualisation ». Ça vaut le coup d'ailleurs de revoir un peu la chronologie des faits car c'est un vrai phénomène de société.
Mais s'il est vrai que certaines tendances politiques rêvent d'un d'état d'urgence permanent (et pas seulement en France), il est de fait que ça arrangerait tout le monde de pouvoir se passer de Vigipirate, à commencer par le gouvernement, parce que cela coûte cher. Se battre en permanence contre une menace intérieure, c'est comme passer son temps à avoir la fièvre.
Les frais d'inscription tels que décrits dans le présent journal, en revanche, ça ressemble un peu à « se payer sur la bête », comme on dit.
[^] # Re: L’Élysée n’est pas là où vous croyez
Posté par Obsidian . En réponse au journal elysee.fr, ou la pitoyabilité de la start-up nation. Évalué à 2.
Pluto, c'est la planète Claire ?
# Facile
Posté par Obsidian . En réponse au journal [Énigme] Foutue guerre… . Évalué à 2. Dernière modification le 13 juillet 2018 à 17:32.
En menaçant d'exécution sommaire tous tes soldats si tu n'es pas au camp d'ici 1h30. Le seul qui osera revenir sera le bon. :)
[^] # Re: Le détail, toujours le détail
Posté par Obsidian . En réponse à la dépêche Refaire LinuxFr.org : résultats de l’enquête. Évalué à 2.
À noter que ça, ça se fait avec la CSS. Il ne faudrait pas faire l'erreur de limiter ça directement dans le code et perdre de l'information en conséquence.
[^] # Re: Pas forcément commercial
Posté par Obsidian . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 10.
Comme dit plus haut, c'est malhonnête en soi et personne ne fonctionne au chantage. En plus, dans notre métier en particulier (pourvu que ça dure) les développeurs sont quasiment en situation de plein emploi. Donc, soit le dev est incompétent (il y en a beaucoup plus que l'on croit) au moins sur une techno donnée, soit la compagnie fait déjà des pieds et des mains pour tenter de retenir ses éléments.
Avec ça, il y a un phénomène dont toutes les petites et moyennes structures ont fait l'expérience si elles ont un jour mené un projet de développement : même avec la meilleure volonté du monde, le logiciel devient de toutes façons et de lui-même, soit obsolète soit impossible à maintenir. Même si le dev est un « full stack » et connaît toutes les technologies sur le bout des doigts, il faut toujours au moins 500 jours/homme pour produire quelque chose qui soit réellement abouti sur tous les plans. Même faire de l'intégration, ou être mainteneur de packages pour une distribution, est une activité extrêmement chronophage. Et l'ennui des petites structures, c'est que pour verser un salaire au développeur, il faut vendre vite et si possible beaucoup.
Donc, le dev n'a pas le temps de produire quelque chose d'exhaustif dès le départ. Ce n'est pas du mercantilisme, c'est juste que s'il n'y a pas rapidement une première vente, il n'y aura pas de fond pour poursuivre le développement.
Du coup, les logiciels qui deviennent vraiment pérennes dans le temps sont ceux dont l'équipe a pu atteindre une masse critique, justement parce qu'elle ne dépend pas d'un seul développeur. Donc soit les logiciels de grosses entreprises, avec des équipes et des processus métier bien rodés, soit des projets de logiciel libre qui, par nature, ne sont pas liés au départ à une contrainte de temps et que les personnes intéressées peuvent rejoindre au fur et à mesure de leur avancement.
Et enfin, lorsque l'on arrive à surmonter tout cela, dans le contexte actuel, c'est généralement le développeur qui part de lui-même. Du coup, toutes les sociétés sont déjà habituées à prévoir un plan de repli ou à mettre carrément un projet en sommeil le temps de former une autre équipe.
La meilleure façon, au contraire, de pérenniser son emploi est d'être rentable. Il ne s'agit pas de devenir volontairement une vache à lait bien sûr, mais le meilleur argument pour se rendre « indispensable » est d'être capable d'exhiber ce que ton travail rapporte à la compagnie par rapport à ce que tu lui coûtes. Fort de cela, et si ça marche bien, tu peux essayer de négocier une augmentation pour récupérer ta part du gâteau tout en restant « profitable ».
Et s'il s'avère que justement, « ce n'est pas la politique de la compagnie » ou que tu travailles dans une de ces SSII où le principe est de te payer le minimum en te promettant monts et merveilles jusqu'à ce que tu décides toi-même de mettre un terme à la mascarade, alors au contraire, il faut essayer de perdre le moins de temps possible et essayer rapidement une nouvelle structure. Et pour cela, tu auras besoin à la fois de faire une transmission de compétences pour être libéré rapidement et d'un portfolio pour intégrer facilement un autre poste. Et ça, ce sont deux très bonnes raisons d'écrire le code le plus propre et le plus accessible possible.
Pour finir, sache que la personne qui devra un jour faire face à ton code réellement « obfusqué » sera probablement… toi-même. Entre 20 et 35 ans, on retient en général tout de tête. Après, ça devient difficile. Mais malgré cela, imagine qu'on te place huit mois sur une mission secondaire, puis que tu prennes trois semaines de vacances avant de reprendre ton développement initial. Tu verras alors à quel point il est difficile de se ré-immerger dans son propre travail…
[^] # Re: Pas forcement…
Posté par Obsidian . En réponse au journal Pourquoi Facebook ?. Évalué à 2.
C'est dommage, parce que ton commentaire commençait de manière très pertinente, en montrant bien que tout n'est pas blanc ou noir et que, surtout, on peut tout-à-fait faire un usage raisonné et responsable de toute ressource qui nous est accessible.
Par contre, cette dernière phrase résonne comme si Facebook était un « moindre mal » et qu'en plus, elle traduit une grande détresse sous-jacente. Et ça, généralement, c'est justement ce qui fait le côté vicieux de la chose.
# fdupesfs ?
Posté par Obsidian . En réponse au journal fdupes : un utilitaire pour gagner de la place sur son disque dur. Évalué à 3.
C'est effectivement un cas de figure qui revient fréquemment sur le devant de la scène, UNIX propose d'ailleurs des liens durs pratiquement depuis le début (surtout à une époque où l'espace disque coûtait cher). Et il m'arrive régulièrement de faire ce genre de stats.
Du coup, il me vient idée à l'esprit : puisque les comparaisons de fichiers et le contrôle de leur somme (notamment avec Git), qui implique de les lire linéairement en une fois mais en entier, sont des choses récurrentes, serait-il envisageable d'intégrer cette fonctionnalité directement au système de fichier ? Et si oui, existe-t-il déjà des FS qui le fassent ?
Le stockage sur disque implique déjà l'usage de CRC à très bas niveau (hardware et juste au dessus). Étant donné que les fonction de hachage comme MD5, SHA1, etc. sont de taille fixe et sont faites pour être faciles à calculer, c'est quelque chose que l'on pourrait envisager d'intégrer dans les inodes et que l'on récupérerait ensuite avec stat().
[^] # Re: le proverbe qui va bien
Posté par Obsidian . En réponse au journal [MaVie] La grosse gaffe du jour ..... Évalué à 4.
En plus, il est qualifié pour devenir BOFH, maintenant…