Je trouve personnellement un peu triste qu'un avis personnel, surtout venant d'une des personnes qui aident a encadrer le site, alimente avec autant d’opiniâtreté une polémique sur une exclusion qu'elle est la seule à détecter, sur plusieurs pages, en réponse à un article appelant, justement, à réduire ce genre choses.
Et ce, pour la raison simple: l'idée du article me semble être d'appeler à l'auto-modération de sorte a diminuer le travail… de l'équipe de modération. Ironique, non?
Aussi, les gens qui ont des rôles de modération ou d'administration ont implicitement le rôle associé à leur pseudonyme. C'est naturel et loin d'être limité à la modération d'un site. En fait, c'est le lot de toute "personne publique": maires, préfets, ministres, sénateurs, directeurs d'entreprises, et bien d'autres.
L'avantage d'internet, c'est que le pseudonymat est plus que possible. Donc, pour réduire le problème, il suffirait donc de créer une identité dédiée à ce rôle.
Typiquement, quand je joue sur des serveurs dont je suis admin (et qui ne sont pas les miens), j'ai tendance a changer de pseudonyme justement pour ce type de raison (pour pouvoir jouer sans avoir à discuter ou expliquer certains points, en bref, être un lambda parmi les lambda, même si on peut reconnaître un joueur via d'autres méthodes).
Évidemment, les règles de ce site interdisent à une même personne d'avoir plusieurs comptes. Mais bon, d'une part je me suis toujours posé la question du pourquoi, d'autre part je ne vois pas comment ça serait techniquement faisable, ensuite, je pense que cette règle ne devrais pas concerner les personnes qui ont des rôles officiels, et pour finir, les règles du site ne sont de toute façon pas si appliquées que ça (typiquement, nombre de liens sont hors-sujet. Je laisse aux lecteurs le soin d'apprécier si c'est, ou non, une bonne chose, je n'ai plus d'avis sur le sujet depuis que je ne fréquente quasi plus linuxfr).
Au pire, les règles, ça se change quand le besoin se fait sentir.
Je prouve juste sur un projet réel que les chiffres sont largement moins utilisés que les autres caractères utiles en prog (et plus précisément C++ ici, d'autres langages ont peut-être un ratio différent en faveur des chiffres, mais j'attend une preuve). C'est tout.
Me dire que dans les commits et les tickets on utilise des chiffres, ça c'est hors contexte, parce que les gestionnaires de tickets et de version sont loin d'être exclusifs à la programmation (cf PLM).
Qui plus est, la gestion des tickets et des commits, bien que très utile quand fait correctement, ne prend pas vraiment une part importante des frappes clavier quand on écrit du code… le déboguage et l'écriture, par contre si.
Je rappelle que le message d'origine de ce thread dit ceci (le gras est de moi):
Je reste assez dubitatif en regardant la disposition, notamment pour la programmation
Clang, et surtout C++11. En fait, je pense que clang a simplement adopté les erreurs améliorées avant qu'elles ne soient dans le standard officiel, même si c'était dans le draft de C++0x.
Ça et la performance du compilateur sont les 2 raisons qui m'ont fait adopter clang pour mes builds itératifs. Pour les builds de release, je me contente d'utiliser g++ sans trop réfléchir, parce qu'il paraît que les binaires générés sont mieux optimisés. Mais je n'ai jamais vérifié ça moi même.
Il arrive évidemment que le consentement s'affaisse si le citoyen (ou le sujet dans le temps) n'y trouve pas son compte, et là l'état peut être tenté d'abuser de la force pour obtenir des sous
Beaucoup plus récemment (temps que les moins de 20 ans connaissent), on peut rappeler la taxe carbone, et d'autres.
Oui, un impôt peut être considéré comme du racket, et des impôts ont créé des évènements violents à de nombreuses reprises, l'état n'hésite pas si souvent a "user de la force".
J'ai aussi moins de 40 ans, mais je me souviens très bien des PC de mon enfance.
Je n'ai jamais dis que les formations n'ont pas évolué, par exemple je n'ai pas appris l'assembleur en terminale électronique, mais le C, alors que mon père, qui a fait la même classe 15 ans plus tôt, avait de l'assembleur motorola.
Je doute aussi qu'UML existait il y a 40 ans, par contre merise oui. J'ai découvert UML en BTS, et merise dans une formation plus tard (et j'ai plus utilisé merise à des fins réellement utiles dans ma vie qu'UML… amusant constat).
Je n'ai pas dis que l'informatique ne s'est jamais complexifié, j'ai dis que sur les 15 ans que je peux vérifier (qui sont du vécu et pas de l'ordre de l'imagination) je n'ai pas l'impression que ça se soit sensiblement complexifié.
Je pensais que l'on parlais du métier, pas des formations. Je n'avais pas compris la limite sur les 15 ans, non plus.
Donc, mes excuses. Problème de compréhension de ma part.
même pas trop basse, hein, les erreurs de g++ il y a 15 ans et maintenant c'est le jour et la nuit),
Ah ça c'est clair, je me souviens très bien de l'horreur qu'était comprendre une erreur dans un template!
Je me contentais de répondre a la partie qui suggère que les chiffres sont plus usités en programmation que les caractères "autres", rien de plus.
La gestion des tickets (et de l'historique du code) n'est techniquement pas de la programmation, ce genre de choses sont utilisées dans d'autres domaines, après tout. Et malgré tout, je serais curieux de voir le ration de chiffres vs autres dans un descriptif de commit. Si le descriptif se contente d'un numéro de ticket sans autre information, alors franchement c'est moche, ça casse le workflow de devoir aller chercher un autre outil pour avoir une info complète.
Mais je suppose qu'en effet, les caractères de la barre des chiffres en azerty n'y ont que peu d'intérêt. Malgré tout, l'écriture des textes de commit est une tâche mineure. On pourrais aussi arguer (avec une bonne dose de mauvaise foi, ça devrais passer…) que des IDs ne sont pas des nombres, et qu'un autre logiciel utilisera à la place un autre système (non, je n'en connais pas :)). Sur le papier, ça tiens.
Moins de 5% des caractères sont des chiffres, contre plus de 18% qui sont des caractères accessibles sans modificateurs d'aucune sorte
Je me suis mal exprimé ici, mais je pense que tu as bien compris que par "caractères accessibles sans modificateurs d'aucune sorte" j'entendais en azerty, d'une part, et d'autre part que je parlais des caractères dans la regex, qui sont une partie de ceux disponibles. En programmation, les autres ne me servent à rien, vu que je programme exclusivement en anglais (j'y arrive pas en français, aucune idée de pourquoi)
Trouvé via cette recherche, 1er lien, pour les curieux de la méthode. ENfin, j'ai trouvé le domaine comme ça, et ajouté /386 à la fin, parce que je suis un geek qui trouve ça naturel, je suppose.
En même temps, je ne serais pas surpris si steam lui-même n'était maintenu que par des stagiaires… ce truc est quand même vachement lent et buggué, pour un soft d'une boîte qui est censée être capable de développer des jeux vidéo performants.
J'aimerai vraiment connaître leur excuse pour le 32bits, franchement, parce que selon wikipedia: «Première version 12 septembre 2003», «2003
AMD introduces its Opteron and Athlon 64 processor lines», «2004
Intel, reacting to the market success of AMD, admits it has been developing a clone of the AMD64 extensions named IA-32e», «2006
Sony, IBM, and Toshiba begin manufacturing the 64-bit Cell processor for use in the PlayStation 3» donc ce n'est pas comme si leur logiciel était tellement plus vieux que les archi 64.
Au vu de la lourdeur et des bugs du bouzin, en plus, c'est très probablement juste une application étronJS de nos jours, donc il a probablement eu réécriture vu que «Première version 15 juillet 2013» et donc c'est plutôt assez dur a pardonner pour moi, sauf, bien sûr, si le truc n'est maintenu que par des stagiaires (et des stagiaires de BTS, maximum, hein) depuis 20 ans.
Autre métrique, beaucoup plus "brute", sur la même base de code:
% find -type f -exec cat {} \+ > /tmp/concat
sed 's/[0-9]//g' /tmp/concat | wc -c
3598252
% sed 's/[^0-9]//g' /tmp/concat | wc -c
173930
% sed 's/[^&"'\''(-_)=]//g' /tmp/concat | wc -c
672044
Moins de 5% des caractères sont des chiffres, contre plus de 18% qui sont des caractères accessibles sans modificateurs d'aucune sorte. En vrai, je m'attendais quand même à moins de caractères non alphanumériques et plus d'alpha, comme quoi…
Toujours est-il que très clairement, bloquer une ligne pour les chiffres est inefficace pour de la programmation, au moins en C ou C++, et dans mon expérience. Mais honnêtement, je doute très fort que le langage change la donne tant que ça, ou que des expériences plus… digitales, je suppose, puissent faire mieux que doubler la valeur des chiffres, et dans ce cas, je doute fort qu'il y ait moins de (, ), -, =, …
Posté par freem .
En réponse au lien L’après Bépo : Ergo‑L.
Évalué à 5 (+3/-0).
Dernière modification le 03 juin 2024 à 13:23.
et les chiffres sont bien utiles aussi en programmation.
Ben en fait, pas tant que ça.
En programmation, on utilise les chiffres pour mettre une valeur précise dans un symbole, puis on manipule le symbole, ça facilite la maintenance quand on n'a pas besoin de se demander quelles autres occurrences d'un nombre doivent être modifiées.
Si je prend le cas de mon mod d'Unvanquished, par exemple, sur les 137438 lignes de code (et vides, et commentaires, et licences, certes), seules 12764 contiennent le pattern: \<[0-9].
6341 de ces lignes contiennent celui-ci: \<0\(\.\(0\)*\)*\> qui correspond à la valeur 0, flottante ou entière, utilisée pour (ré)initialiser. Donc, 6423 lignes contiennent a coup sûr des nombres pertinents, ce qui nous fais moins de 5% (à noter que, la aussi, ça inclue les commentaires et les licences!).
Donc, non, les chiffres ne sont pas très utiles en programmation. Je serais surpris que les valeurs changent tant que ça avec d'autres projets, et d'ailleurs, unvanquished est un jeu 3D, on devrais, justement, s'attendre a pas mal de chiffres, mais non.
Je pourrais faire la mesure avec les parenthèses, accolades, crochets, moins, plus, astérisque, barres obliques et droites, esperluettes, arobases, mais… est-ce vraiment utile?
Il a changé, mais de là à le présenter comme plus complexe c'est se fourvoyer amha.
Si on regarde sur 40 ans, je pense que l'IT moderne est effectivement plus complexe que dans les années 90 ou le début des années 2000, et ce principalement pour la raison des exécutions en parallèle.
La prévalence des interactions réseau, aussi. Je suis persuadé (pas convaincu, persuadé, autrement dit, ça repose sur l'affect et non une démarche objective) que même si il y avait du réseau il y a 40 ans (je sais que c'est le cas, merci) il était nettement moins utilisé dans les applications, et la complexité qu'ajoute une connexion réseau n'est pas un truc que j'ai halluciné: établir une connexion a un serveur, et vérifier qu'elle est en bon état, la redémarrer ou la maintenir, ce n'est pas simple. Ajoutons à ça la communication radio (a comparer a des paires de cuivre, la stabilité n'est pas la même), les capacités des processeurs qui font que de nos jours, la bande passante entre la RAM et le CPU est l'un des goulots d'étranglement classique avec un CPU qui glande a 80% du temps (avant, l'idée était plutôt d'éviter de cramer des cycles pour rien, quitte a utiliser de l'assembleur inline), et probablement de nombreux problèmes que j'oublie, oui, je pense que l'informatique moderne est plus complexe.
Certes, avant (80s, début des 90s) il n'y avais pas de directX, il fallait piloter directement le matériel dans certaines applications pour lesquelles ce n'est plus nécessaire (jeux sous ms-dos par exemple. Oui, je sais, on pilote toujours le matériel dans certaines applications, mais c'est enlever la catégorie des jeux vidéo vire déjà une bonne partie de l'offre logicielle) et il était plus difficile d'accéder à du code fait par autrui pour se faciliter le travail, mais je ne crois pas que ça compense, vu qu'avant, trouver un manuel ou une référence potable pour un produit, ce n'était pas la croix et la bannière (parce que c'était livré avec, tout simplement).
On peut aussi mentionner le fait que les langages étaient beaucoup moins bien foutus et les compilateurs moins performants, mais pareil, ça me semble pas compenser l'augmentation de la complexité des programmes.
Après, on peut aussi arguer que le dev, il fera du frontend ou utilise un langage type python qui fait tout magiquement et donc la perf il s'en balance, mais… bon, primo, ça dépend du milieu dans lequel le dev évolue, et secondo moi, ça me dérange très fortement cette attitude. Rapport a jeter du matériel qui pourtant marche parfaitement, juste parce qu'une personne a voulu ajouter des coins arrondis simulés par de la transparence, des effets de transitions qui font perdre du temps à l'utilisateur, ou des publicités qui te sautent à la gueule.
Concrètement, les couches logicielles sont plus simples à utiliser, mais je pense clairement que l'infrastructure IT est largement plus complexe, ce qui se reflète nécessairement sur le métier.
Pour les méthodes utilisées, je ne sais pas, je n'avais pas assez d'expérience pour juger, il y a 15 ans, mais ça, ça change d'entreprise en entreprise de toute façon.
Je suppose que le point est que ça ne génèrera pas un makefile qui gère les libs aussi souplement qu'un makefile à la main qui utilisera probablement pkg-config.
Je ne fait que supposer, ici.
Ma foi, je ne savais pas que c'était un format interprétable directement par make que ça crachais, je ne connaissais la fonctionnalité que grâce à la doc de ninja, je n'ai jamais eu la curiosité d'ouvrir ces fichiers. Merci de l'info.
Lors de mises à jour, je suis régulièrement consulté pour savoir si je préfère ma version de /etc/vim/vimrc, avec un outil permettant de voir le diff. Donc je suppose qu'en effet, il aurait été possible de demander.
J'imagine que le /etc/apt/sources.list est exclut d'une manière ou d'une autre? Possiblement historique?
Après tout, il est aussi généré par le système, et je n'ai jamais eu cet outil de diff dessus (et pourtant, j'ai une vieille habitude de le modifier, même si je sais que je devrais utiliser /etc/apt/sources.list.d/… j'essaie, mais les habitudes sont dures, et le changement pas si pertinent).
Ce paquet est, en effet, très bien intégré… pour les installations 32 bits, parce que les gens de valve ne sont apparemment pas capables de compiler leurs trucs pour du 64 bits, en 2024. Pardon, 2022 ou 2023, parce que Debian, c'est vieux.
Pour un usage général, le plus simple est d’utiliser l’un des éditeurs de texte fournis avec macOS. Si vous souhaitez utiliser un éditeur de texte graphique, servez-vous de TextEdit (dans le Launchpad). Sinon, utilisez l’un des éditeurs en ligne de commande inclus avec macOS
Pour ceux qui, comme moi, se demandaient ce que pouvait bien vouloir radio-france à la Forme de Backus-Naur qui est probablement plus connue du public de linuxfr :D
Et surtout, ça n'a, mais alors, rien à voir avec 1984, univers dans lequel l'art n'est pas banni (mais instrumentalisé, si ma mémoire est bonne, après la scène de départ ou le héros dirige sa colère contre le Parti et non contre l'ennemi désigné, il y a une scène ou le mode de vie des gens pas rebelles est décrit, et la musique y est clairement mentionnée).
Ça serait bien plus proche de Farenheit 451…
Note préliminaire: j'enchéris sur sobriquet et suis d'accord.
C'est moi, ou les tech ne sont pas considérés comme informaticiens ici?
Non, parce que bon, je pense qu'il y a plus de tech que d'admins et de dev, hein, et les techs n'ont pas du tout de raison majeure d'utiliser vim/emacs. En fait, c'est pire, ils doivent souvent faire avec juste notepad de windows…
Je pense qu'environ 1% des informaticiens sont des devs ou admins, et dans ceux-la, oui, ok, peut-être que 50% ont un intérêt à utiliser vim/emacs. Les autres n'y ont même pas accès! Pour rappel, windows est toujours un environnement informatique majeur, c'est pas parce qu'il y a moins de PC vendus qu'il y a moins de windows utilisés.
D'ailleurs, macOS, ça embarque vim ou emacs? M'étonnerais, et pourtant c'est un UNIX.
On pourrait aussi déduire les vieux barbus qui ont dû à une époque de leur carrière apprendre à maîtriser vi, mais qui sont bien contents de recourir à d'autres outils aujourd'hui.
Pour ma part, je ne suis pas (encore) un vieux (et je me tond, donc pas barbu), mais j'ai appris a utiliser vim volontairement il y a ~15 ans. Scintilla existait déjà (la base de notepad++ et de code::blocks, entres autres).
J'y vois plusieurs intérêt, mais ce n'est pas le sujet.
J'ai aussi vu des jeunes sortis de l'école s'intéresser a vim en voyant ma façon de bosser (en tant que dev C++ sous debian), mais quand ils sont passés à vim, ils sont aussi et surtout passés à i3, et je pense que c'est parce que je ne connais aucun IDE potable hors DE monolithique (KDE, Gnome, etc) et que i3+rxvt+vim, justement, permets d'avoir un système léger et pourtant bien intégré (les terminaux, ça marche vachement bien avec un bon gestionnaire de fenêtres après tout).
Perso, je pense qu'il est important de laisser chacun choisir sa façon de bosser tant que ça impacte pas l'équipe.
Le reste, sérieux, on s'en fout. Imposer un style de code, par exemple, c'est utile, parce que si fait correctement, on peut utiliser le VCS pour gérer automatiquement la transition de styles, et donc tout le monde peut bosser avec ce qu'il préfère (ok, il y a un impact quand on utilise des outils non-locaux… mais pourquoi faire ça dans un cadre quotidien?).
Et franchement, ce délire d'unification est typique des usines. Sur un chantier, personne ne va dire a un plaquiste de plaquer autrement ou avec d'autres outils, par exemple, j'ai d'ailleurs souvenir que les gens ne prêtent pas leurs outils parce qu'ils les modifient (les manches) pour leurs mains. Hors, vim, justement, est conçu pour… être plus efficace au niveau des frappes. Je suppose, de certaines personnes, au moins.
Ça marche pour moi, je n'ai plus de douleurs à la main droite (non, c'est pas la b… d'ailleurs, je suis pas sourd, mais bien les voyages souris<->clavier) mais ça ne marchera pas pour tous les métiers ou personnes. C'est normal. Les gens ont des usages, cultures et physionomies différentes.
[^] # Re: C'est le moment pour un petit XKCD !
Posté par freem . En réponse au journal LWN : A plea for more thoughtful comments. Évalué à 9 (+7/-0).
Je trouve personnellement un peu triste qu'un avis personnel, surtout venant d'une des personnes qui aident a encadrer le site, alimente avec autant d’opiniâtreté une polémique sur une exclusion qu'elle est la seule à détecter, sur plusieurs pages, en réponse à un article appelant, justement, à réduire ce genre choses.
Et ce, pour la raison simple: l'idée du article me semble être d'appeler à l'auto-modération de sorte a diminuer le travail… de l'équipe de modération. Ironique, non?
Aussi, les gens qui ont des rôles de modération ou d'administration ont implicitement le rôle associé à leur pseudonyme. C'est naturel et loin d'être limité à la modération d'un site. En fait, c'est le lot de toute "personne publique": maires, préfets, ministres, sénateurs, directeurs d'entreprises, et bien d'autres.
L'avantage d'internet, c'est que le pseudonymat est plus que possible. Donc, pour réduire le problème, il suffirait donc de créer une identité dédiée à ce rôle.
Typiquement, quand je joue sur des serveurs dont je suis admin (et qui ne sont pas les miens), j'ai tendance a changer de pseudonyme justement pour ce type de raison (pour pouvoir jouer sans avoir à discuter ou expliquer certains points, en bref, être un lambda parmi les lambda, même si on peut reconnaître un joueur via d'autres méthodes).
Évidemment, les règles de ce site interdisent à une même personne d'avoir plusieurs comptes. Mais bon, d'une part je me suis toujours posé la question du pourquoi, d'autre part je ne vois pas comment ça serait techniquement faisable, ensuite, je pense que cette règle ne devrais pas concerner les personnes qui ont des rôles officiels, et pour finir, les règles du site ne sont de toute façon pas si appliquées que ça (typiquement, nombre de liens sont hors-sujet. Je laisse aux lecteurs le soin d'apprécier si c'est, ou non, une bonne chose, je n'ai plus d'avis sur le sujet depuis que je ne fréquente quasi plus linuxfr).
Au pire, les règles, ça se change quand le besoin se fait sentir.
[^] # Re: Vrai et compliqué à la fois... quota ?
Posté par freem . En réponse au journal LWN : A plea for more thoughtful comments. Évalué à 2 (+0/-0).
Peut-être du fait de l'accès gratuit et immédiat, cela dit?
[^] # Re: Mouais, à voir
Posté par freem . En réponse au lien L’après Bépo : Ergo‑L. Évalué à 3 (+1/-0).
En quoi c'est hors sujet?
Je prouve juste sur un projet réel que les chiffres sont largement moins utilisés que les autres caractères utiles en prog (et plus précisément C++ ici, d'autres langages ont peut-être un ratio différent en faveur des chiffres, mais j'attend une preuve). C'est tout.
Me dire que dans les commits et les tickets on utilise des chiffres, ça c'est hors contexte, parce que les gestionnaires de tickets et de version sont loin d'être exclusifs à la programmation (cf PLM).
Qui plus est, la gestion des tickets et des commits, bien que très utile quand fait correctement, ne prend pas vraiment une part importante des frappes clavier quand on écrit du code… le déboguage et l'écriture, par contre si.
Je rappelle que le message d'origine de ce thread dit ceci (le gras est de moi):
[^] # Re: Génération Z
Posté par freem . En réponse au journal C11, listes variantes et le turfu. Évalué à 2 (+0/-0).
Clang, et surtout C++11. En fait, je pense que clang a simplement adopté les erreurs améliorées avant qu'elles ne soient dans le standard officiel, même si c'était dans le draft de C++0x.
Ça et la performance du compilateur sont les 2 raisons qui m'ont fait adopter clang pour mes builds itératifs. Pour les builds de release, je me contente d'utiliser g++ sans trop réfléchir, parce qu'il paraît que les binaires générés sont mieux optimisés. Mais je n'ai jamais vérifié ça moi même.
[^] # Re: Quel est le problème ?
Posté par freem . En réponse au lien Repérage des piscines non déclarées : l’IA de l’administration fiscale patauge. Évalué à 2 (+0/-0).
Au cas ou un (vieil) exemple serait nécessaire: https://fr.wikipedia.org/wiki/R%C3%A9volte_des_Nu-pieds
Beaucoup plus récemment (temps que les moins de 20 ans connaissent), on peut rappeler la taxe carbone, et d'autres.
Oui, un impôt peut être considéré comme du racket, et des impôts ont créé des évènements violents à de nombreuses reprises, l'état n'hésite pas si souvent a "user de la force".
[^] # Re: C'est le moment pour un petit XKCD !
Posté par freem . En réponse au journal LWN : A plea for more thoughtful comments. Évalué à 8 (+6/-0).
Certains apprécient le comique de répétition. Ce n'est pas a moi de juger leur humour.
[^] # Re: Génération Z
Posté par freem . En réponse au journal C11, listes variantes et le turfu. Évalué à 2 (+0/-0). Dernière modification le 04 juin 2024 à 13:18.
J'ai aussi moins de 40 ans, mais je me souviens très bien des PC de mon enfance.
Je n'ai jamais dis que les formations n'ont pas évolué, par exemple je n'ai pas appris l'assembleur en terminale électronique, mais le C, alors que mon père, qui a fait la même classe 15 ans plus tôt, avait de l'assembleur motorola.
Je doute aussi qu'UML existait il y a 40 ans, par contre merise oui. J'ai découvert UML en BTS, et merise dans une formation plus tard (et j'ai plus utilisé merise à des fins réellement utiles dans ma vie qu'UML… amusant constat).
Je pensais que l'on parlais du métier, pas des formations. Je n'avais pas compris la limite sur les 15 ans, non plus.
Donc, mes excuses. Problème de compréhension de ma part.
Ah ça c'est clair, je me souviens très bien de l'horreur qu'était comprendre une erreur dans un template!
[^] # Re: Mouais, à voir
Posté par freem . En réponse au lien L’après Bépo : Ergo‑L. Évalué à 3 (+1/-0).
Je me contentais de répondre a la partie qui suggère que les chiffres sont plus usités en programmation que les caractères "autres", rien de plus.
La gestion des tickets (et de l'historique du code) n'est techniquement pas de la programmation, ce genre de choses sont utilisées dans d'autres domaines, après tout. Et malgré tout, je serais curieux de voir le ration de chiffres vs autres dans un descriptif de commit. Si le descriptif se contente d'un numéro de ticket sans autre information, alors franchement c'est moche, ça casse le workflow de devoir aller chercher un autre outil pour avoir une info complète.
Mais je suppose qu'en effet, les caractères de la barre des chiffres en azerty n'y ont que peu d'intérêt. Malgré tout, l'écriture des textes de commit est une tâche mineure. On pourrais aussi arguer (avec une bonne dose de mauvaise foi, ça devrais passer…) que des IDs ne sont pas des nombres, et qu'un autre logiciel utilisera à la place un autre système (non, je n'en connais pas :)). Sur le papier, ça tiens.
Je me suis mal exprimé ici, mais je pense que tu as bien compris que par "caractères accessibles sans modificateurs d'aucune sorte" j'entendais en azerty, d'une part, et d'autre part que je parlais des caractères dans la regex, qui sont une partie de ceux disponibles. En programmation, les autres ne me servent à rien, vu que je programme exclusivement en anglais (j'y arrive pas en français, aucune idée de pourquoi)
[^] # Re: C'est le moment pour un petit XKCD !
Posté par freem . En réponse au journal LWN : A plea for more thoughtful comments. Évalué à 10 (+9/-0). Dernière modification le 04 juin 2024 à 13:02.
Bon, puisque certains râlent, je me permets: 386
Trouvé via cette recherche, 1er lien, pour les curieux de la méthode. ENfin, j'ai trouvé le domaine comme ça, et ajouté
/386à la fin, parce que je suis un geek qui trouve ça naturel, je suppose.[^] # Re: C'est le moment pour un petit XKCD !
Posté par freem . En réponse au journal LWN : A plea for more thoughtful comments. Évalué à 5 (+4/-1).
Il va donc falloir interdire les liens en anglais.
[^] # Re: J’ai très récemment pris conscience des limites de debian
Posté par freem . En réponse au journal Merci Debian ! Des heures de perdues en installant une nouvelle carte graphique !. Évalué à 2 (+0/-0).
En même temps, je ne serais pas surpris si steam lui-même n'était maintenu que par des stagiaires… ce truc est quand même vachement lent et buggué, pour un soft d'une boîte qui est censée être capable de développer des jeux vidéo performants.
J'aimerai vraiment connaître leur excuse pour le 32bits, franchement, parce que selon wikipedia: «Première version 12 septembre 2003», «2003
AMD introduces its Opteron and Athlon 64 processor lines», «2004
Intel, reacting to the market success of AMD, admits it has been developing a clone of the AMD64 extensions named IA-32e», «2006
Sony, IBM, and Toshiba begin manufacturing the 64-bit Cell processor for use in the PlayStation 3» donc ce n'est pas comme si leur logiciel était tellement plus vieux que les archi 64.
Au vu de la lourdeur et des bugs du bouzin, en plus, c'est très probablement juste une application étronJS de nos jours, donc il a probablement eu réécriture vu que «Première version 15 juillet 2013» et donc c'est plutôt assez dur a pardonner pour moi, sauf, bien sûr, si le truc n'est maintenu que par des stagiaires (et des stagiaires de BTS, maximum, hein) depuis 20 ans.
[^] # Re: Mouais, à voir
Posté par freem . En réponse au lien L’après Bépo : Ergo‑L. Évalué à 3 (+1/-0).
Autre métrique, beaucoup plus "brute", sur la même base de code:
Moins de 5% des caractères sont des chiffres, contre plus de 18% qui sont des caractères accessibles sans modificateurs d'aucune sorte. En vrai, je m'attendais quand même à moins de caractères non alphanumériques et plus d'alpha, comme quoi…
Toujours est-il que très clairement, bloquer une ligne pour les chiffres est inefficace pour de la programmation, au moins en C ou C++, et dans mon expérience. Mais honnêtement, je doute très fort que le langage change la donne tant que ça, ou que des expériences plus… digitales, je suppose, puissent faire mieux que doubler la valeur des chiffres, et dans ce cas, je doute fort qu'il y ait moins de (, ), -, =, …
[^] # Re: Mouais, à voir
Posté par freem . En réponse au lien L’après Bépo : Ergo‑L. Évalué à 5 (+3/-0). Dernière modification le 03 juin 2024 à 13:23.
Ben en fait, pas tant que ça.
En programmation, on utilise les chiffres pour mettre une valeur précise dans un symbole, puis on manipule le symbole, ça facilite la maintenance quand on n'a pas besoin de se demander quelles autres occurrences d'un nombre doivent être modifiées.
Si je prend le cas de mon mod d'Unvanquished, par exemple, sur les 137438 lignes de code (et vides, et commentaires, et licences, certes), seules 12764 contiennent le pattern:
\<[0-9].6341 de ces lignes contiennent celui-ci:
\<0\(\.\(0\)*\)*\>qui correspond à la valeur 0, flottante ou entière, utilisée pour (ré)initialiser. Donc, 6423 lignes contiennent a coup sûr des nombres pertinents, ce qui nous fais moins de 5% (à noter que, la aussi, ça inclue les commentaires et les licences!).Donc, non, les chiffres ne sont pas très utiles en programmation. Je serais surpris que les valeurs changent tant que ça avec d'autres projets, et d'ailleurs, unvanquished est un jeu 3D, on devrais, justement, s'attendre a pas mal de chiffres, mais non.
Je pourrais faire la mesure avec les parenthèses, accolades, crochets, moins, plus, astérisque, barres obliques et droites, esperluettes, arobases, mais… est-ce vraiment utile?
[^] # Re: Génération Z
Posté par freem . En réponse au journal C11, listes variantes et le turfu. Évalué à 2 (+0/-0).
Si on regarde sur 40 ans, je pense que l'IT moderne est effectivement plus complexe que dans les années 90 ou le début des années 2000, et ce principalement pour la raison des exécutions en parallèle.
La prévalence des interactions réseau, aussi. Je suis persuadé (pas convaincu, persuadé, autrement dit, ça repose sur l'affect et non une démarche objective) que même si il y avait du réseau il y a 40 ans (je sais que c'est le cas, merci) il était nettement moins utilisé dans les applications, et la complexité qu'ajoute une connexion réseau n'est pas un truc que j'ai halluciné: établir une connexion a un serveur, et vérifier qu'elle est en bon état, la redémarrer ou la maintenir, ce n'est pas simple. Ajoutons à ça la communication radio (a comparer a des paires de cuivre, la stabilité n'est pas la même), les capacités des processeurs qui font que de nos jours, la bande passante entre la RAM et le CPU est l'un des goulots d'étranglement classique avec un CPU qui glande a 80% du temps (avant, l'idée était plutôt d'éviter de cramer des cycles pour rien, quitte a utiliser de l'assembleur inline), et probablement de nombreux problèmes que j'oublie, oui, je pense que l'informatique moderne est plus complexe.
Certes, avant (80s, début des 90s) il n'y avais pas de directX, il fallait piloter directement le matériel dans certaines applications pour lesquelles ce n'est plus nécessaire (jeux sous ms-dos par exemple. Oui, je sais, on pilote toujours le matériel dans certaines applications, mais c'est enlever la catégorie des jeux vidéo vire déjà une bonne partie de l'offre logicielle) et il était plus difficile d'accéder à du code fait par autrui pour se faciliter le travail, mais je ne crois pas que ça compense, vu qu'avant, trouver un manuel ou une référence potable pour un produit, ce n'était pas la croix et la bannière (parce que c'était livré avec, tout simplement).
On peut aussi mentionner le fait que les langages étaient beaucoup moins bien foutus et les compilateurs moins performants, mais pareil, ça me semble pas compenser l'augmentation de la complexité des programmes.
Après, on peut aussi arguer que le dev, il fera du frontend ou utilise un langage type python qui fait tout magiquement et donc la perf il s'en balance, mais… bon, primo, ça dépend du milieu dans lequel le dev évolue, et secondo moi, ça me dérange très fortement cette attitude. Rapport a jeter du matériel qui pourtant marche parfaitement, juste parce qu'une personne a voulu ajouter des coins arrondis simulés par de la transparence, des effets de transitions qui font perdre du temps à l'utilisateur, ou des publicités qui te sautent à la gueule.
Concrètement, les couches logicielles sont plus simples à utiliser, mais je pense clairement que l'infrastructure IT est largement plus complexe, ce qui se reflète nécessairement sur le métier.
Pour les méthodes utilisées, je ne sais pas, je n'avais pas assez d'expérience pour juger, il y a 15 ans, mais ça, ça change d'entreprise en entreprise de toute façon.
[^] # Re: Notes
Posté par freem . En réponse au journal C11, listes variantes et le turfu. Évalué à 2 (+0/-0).
Je suppose que le point est que ça ne génèrera pas un makefile qui gère les libs aussi souplement qu'un makefile à la main qui utilisera probablement pkg-config.
Je ne fait que supposer, ici.
Ma foi, je ne savais pas que c'était un format interprétable directement par make que ça crachais, je ne connaissais la fonctionnalité que grâce à la doc de ninja, je n'ai jamais eu la curiosité d'ouvrir ces fichiers. Merci de l'info.
[^] # Re: Tu n'étais pas sous Bookworm quand tu as installé ta carte ?
Posté par freem . En réponse au journal Merci Debian ! Des heures de perdues en installant une nouvelle carte graphique !. Évalué à 2 (+0/-0).
Lors de mises à jour, je suis régulièrement consulté pour savoir si je préfère ma version de
/etc/vim/vimrc, avec un outil permettant de voir le diff. Donc je suppose qu'en effet, il aurait été possible de demander.J'imagine que le
/etc/apt/sources.listest exclut d'une manière ou d'une autre? Possiblement historique?Après tout, il est aussi généré par le système, et je n'ai jamais eu cet outil de diff dessus (et pourtant, j'ai une vieille habitude de le modifier, même si je sais que je devrais utiliser /etc/apt/sources.list.d/… j'essaie, mais les habitudes sont dures, et le changement pas si pertinent).
[^] # Re: J’ai très récemment pris conscience des limites de debian
Posté par freem . En réponse au journal Merci Debian ! Des heures de perdues en installant une nouvelle carte graphique !. Évalué à 2 (+0/-0).
ici
[^] # Re: J’ai très récemment pris conscience des limites de debian
Posté par freem . En réponse au journal Merci Debian ! Des heures de perdues en installant une nouvelle carte graphique !. Évalué à 2 (+0/-0). Dernière modification le 14 mai 2024 à 14:18.
supprimé, parce que je disais la même qu'un autre.
[^] # Re: J’ai très récemment pris conscience des limites de debian
Posté par freem . En réponse au journal Merci Debian ! Des heures de perdues en installant une nouvelle carte graphique !. Évalué à 4 (+2/-0).
Ce paquet est, en effet, très bien intégré… pour les installations 32 bits, parce que les gens de valve ne sont apparemment pas capables de compiler leurs trucs pour du 64 bits, en 2024. Pardon, 2022 ou 2023, parce que Debian, c'est vieux.
[^] # Re: Sans vouloir faire mon vieux con...
Posté par freem . En réponse au lien dte : un autre éditeur de texte normal. Évalué à 2 (+0/-0).
Non, j'ai juste mal lu, désolé.
J'ai mal lu ce passage:
# BNF: Banque National de France
Posté par freem . En réponse au lien BnF : comment le numérique préserve notre mémoire commune ?. Évalué à 0 (+1/-3). Dernière modification le 13 mai 2024 à 13:02.
Pour ceux qui, comme moi, se demandaient ce que pouvait bien vouloir radio-france à la Forme de Backus-Naur qui est probablement plus connue du public de linuxfr :D
[^] # Re: Sans vouloir faire mon vieux con...
Posté par freem . En réponse au lien dte : un autre éditeur de texte normal. Évalué à 2 (+0/-0).
Et alors? Je peux aussi installer vim, emacs et nano sur windows, ce n'est pas pour autant qu'ils sont installés par défaut..
[^] # Re: Marrant ça
Posté par freem . En réponse au lien Apple détruit tout : la publicité iPad qui fait scandale. Évalué à 3 (+1/-0).
Et surtout, ça n'a, mais alors, rien à voir avec 1984, univers dans lequel l'art n'est pas banni (mais instrumentalisé, si ma mémoire est bonne, après la scène de départ ou le héros dirige sa colère contre le Parti et non contre l'ennemi désigné, il y a une scène ou le mode de vie des gens pas rebelles est décrit, et la musique y est clairement mentionnée).
Ça serait bien plus proche de Farenheit 451…
[^] # Re: Sans vouloir faire mon vieux con...
Posté par freem . En réponse au lien dte : un autre éditeur de texte normal. Évalué à 2 (+0/-0).
Mais quel idiot, j'ai oublié cette option! Bien vu! Un DVCS peut prendre plusieurs sources, pas forcément fixes, en plus, en fonction.
[^] # Re: Sans vouloir faire mon vieux con...
Posté par freem . En réponse au lien dte : un autre éditeur de texte normal. Évalué à 2 (+2/-2).
Note préliminaire: j'enchéris sur sobriquet et suis d'accord.
C'est moi, ou les tech ne sont pas considérés comme informaticiens ici?
Non, parce que bon, je pense qu'il y a plus de tech que d'admins et de dev, hein, et les techs n'ont pas du tout de raison majeure d'utiliser vim/emacs. En fait, c'est pire, ils doivent souvent faire avec juste notepad de windows…
Je pense qu'environ 1% des informaticiens sont des devs ou admins, et dans ceux-la, oui, ok, peut-être que 50% ont un intérêt à utiliser vim/emacs. Les autres n'y ont même pas accès! Pour rappel, windows est toujours un environnement informatique majeur, c'est pas parce qu'il y a moins de PC vendus qu'il y a moins de windows utilisés.
D'ailleurs, macOS, ça embarque vim ou emacs? M'étonnerais, et pourtant c'est un UNIX.
Pour ma part, je ne suis pas (encore) un vieux (et je me tond, donc pas barbu), mais j'ai appris a utiliser vim volontairement il y a ~15 ans. Scintilla existait déjà (la base de notepad++ et de code::blocks, entres autres).
J'y vois plusieurs intérêt, mais ce n'est pas le sujet.
J'ai aussi vu des jeunes sortis de l'école s'intéresser a vim en voyant ma façon de bosser (en tant que dev C++ sous debian), mais quand ils sont passés à vim, ils sont aussi et surtout passés à i3, et je pense que c'est parce que je ne connais aucun IDE potable hors DE monolithique (KDE, Gnome, etc) et que i3+rxvt+vim, justement, permets d'avoir un système léger et pourtant bien intégré (les terminaux, ça marche vachement bien avec un bon gestionnaire de fenêtres après tout).
Perso, je pense qu'il est important de laisser chacun choisir sa façon de bosser tant que ça impacte pas l'équipe.
Le reste, sérieux, on s'en fout. Imposer un style de code, par exemple, c'est utile, parce que si fait correctement, on peut utiliser le VCS pour gérer automatiquement la transition de styles, et donc tout le monde peut bosser avec ce qu'il préfère (ok, il y a un impact quand on utilise des outils non-locaux… mais pourquoi faire ça dans un cadre quotidien?).
Et franchement, ce délire d'unification est typique des usines. Sur un chantier, personne ne va dire a un plaquiste de plaquer autrement ou avec d'autres outils, par exemple, j'ai d'ailleurs souvenir que les gens ne prêtent pas leurs outils parce qu'ils les modifient (les manches) pour leurs mains. Hors, vim, justement, est conçu pour… être plus efficace au niveau des frappes. Je suppose, de certaines personnes, au moins.
Ça marche pour moi, je n'ai plus de douleurs à la main droite (non, c'est pas la b… d'ailleurs, je suis pas sourd, mais bien les voyages souris<->clavier) mais ça ne marchera pas pour tous les métiers ou personnes. C'est normal. Les gens ont des usages, cultures et physionomies différentes.