J'aimerais bien aussi, mais malheureusement beaucoup passent à matrix et certains mettent un bridge vers IRC, alors c'est sympa mais du coup les utilisateurs d'IRC se prennent des choses un peu pénible liées au fonctionnalités de matrix comme
Correction d'un message
16:04 <jean> Qelqu'un a déjà eu ce problème sur Debian 5 ?
16:04 <jean> Quelqu'un a déjà eu ce problème sur Debian 5 ?
Envoi d'une image
13:37 <m2i> jean uploaded an image: <http://mysuperimageservice/1298dka02398da.png>
J'ai irssi dans un tmux sur un shell d'un VPS, j'aime pas znc et je comprends aussi les personnes qui souhaitent utiliser une application/service qui supporte directement l'historique en cas d'absence.
IRC n'est pas voué à disparaitre rapidement mais je pense qu'on est quand même dans un déclin progressif.
git is great because linus did it, mercurial is better because he didn't
Overdose d'IA pour ma part, de base ça m'attirait pas mais ça m'attire encore moins pour cette obsession des fabricants et des développeurs
Mais il y a à boire et à manger, tout n'est pas à jeter et heureusement. L'IA reste utile pour de nombreuses choses mais le plus important est de savoir ce que l'on décide d'en faire.
En bons exemples on peut évidemment citer tout ce qui est de la santé (à prendre avec des pincettes bien sûr), des sondes qui permettent de détecter des anomalies du cœur, cérébrales et pouvoir en être averti par des outils de tous les jours comme des montres cela est très bien. Des outils du quotidien pour nous aider dans des tâches stupides, c'est pratique. Quand je commence à remplir ma liste de courses et que mon outil de rappels me propose des choses que j'ai déjà notées dans le passé, j'avoue c'est plutôt simple mais agréable. Le détourage automatique des photos, faut être honnête ça claque et ça facilite clairement le travail. En automobile la détection de franchissement de ligne ça reste aussi bluffant même si j'ose espérer que cela reste à titre d'aide et que les conducteurs continueront d'être attentif et ne pas prendre ça comme excuse à l'inattention. Fort heureusement les voitures se doivent d'émettre un avertissement sonore au bout d'un certain temps. Toutes ces choses sont plutôt intelligentes selon moi mais évidemment l'être humain ne s'arrête pas là.
Je fais de la musique, je fais du développement et je le fais avec passion depuis plus de 20 ans. Je dois admettre que dans mon métier je vois de tous les âges et j'ai bien remarqué que les mentalités évoluent. Je passe très peu de temps sur les forums et je pose presque aucune question car j'ai appris à développer en lisant les pages de manuel, le code opensource des autres, les questions déjà posées et je vois clairement une tendance à la paresse. Beaucoup de mes collègues plus jeunes ont tendances à dégainer un google pour une question très bateau dès la première erreur de compilateur. Certains utilisent ChatGPT pour détecter des erreurs. Certes ça aide sur le moment, mais pas sur le long terme car ils vont probablement pas retenir de leur erreur puisqu'ils ne cherchent pas à la comprendre par eux même.
Concernant la musique et le graphisme je suis très inquiet. C'est incroyablement bluffant à quel points les outils vont loin et quand je cherche des images libres de droit pour illustrer mes musiques avant la production finale, je tombe déjà sur du contenu fait par IA. Ok c'est chouette pour moi car j'ai l'embarras du choix mais les personnes qui vivent de ça avec lesquelles je souhaite collaborer pour l'art final vont probablement voire leur travail sursaturé par du contenu auto généré par des personnes n'ayant ni le talent ni la passion pour le faire. Question musique, je suis incroyablement surpris par la qualité des musiques crées par IA utilisant la voix des autres, je pense bien sûr à cette chanson d'Angèle qui l'a prise de surprise elle même. J'ai bien peur que le contenu des plateforme en ligne finisse par être mélangé entre artistes et opportunistes.
Bref, j'avoue être alarmiste à ce sujet et j'ai de moins en moins envie de continuer dans le monde numérique.
Ce qui m'exaspère le plus c'est la génération de contenu frauduleux et deep fake dont on a encore malheureusement une mauvaise éducation, beaucoup de gens y croient…
git is great because linus did it, mercurial is better because he didn't
En fait les Makefiles bien écrits sont déjà auto-suffisant dès lors qu'on a pas trop besoin de portabilité et qu'on utilise gcc et clang, -MMD permet de générer des règles automatiques pour les entêtes. On peut donc avoir un Makefile qui recompile tous les fichiers y compris ceux avec dépendances indirectes.
On peut par exemple avoir un Makefile tout à fait correct pour compiler un projet sans écrire aucune règle, cela est encore plus flagrant quand on a un nom d'exécutable du même nom du fichier.
Non ça génère des règles de dépendances en fonction des en-tête que tu as inclus. Donc si un fichier foo.c inclue foo.h alors foo.c sera recompilé en cas de modification de foo.h grâce à une règle que gcc -MMD/gcc -MM va générer sous la forme :
foo.o: foo.c foo.h
Cela est nécessaire pour garantir une recompilation du code source notamment pour assurer la compatibilité binaire. Sans ça, modifier une structure ou une fonction dans un entête ne provoquera pas la recompilation des fichiers dépendants, utilisant donc une version binaire non compatible.
git is great because linus did it, mercurial is better because he didn't
En C23 tout cela devient des keywords, donc à éviter.
C'est quand même bien d'avoir des threads utilisables sur tous les OS…
Bof, les C11 threads sont extrêmement limités. En vrai personne ne les utilise et on préfère pthread la plupart du temps (quand on a pas besoin de portabilité) parce que les C11 threads n'ont pas de read-write lock (comme pthread_rwlock) et c'est dommage car c'est quand même pratique.
Il y a aucune fonction pour afficher les erreurs en chaine de caractère donc on peut pas faire un convivial perror ni strerror(errno).
On a aucune garantie de ce qui s'applique avec ces threads (partage des signaux bloqués, etc).
Autre note en vrac, pourquoi des script shell pour compiler du code et pas un Makefile/ CMake ?
git is great because linus did it, mercurial is better because he didn't
J'ai utilisé dotclear il y a une quinzaine d'années, j'aimais beaucoup. Je suis agréableemnt surpris de le voir encore en vie \o/ ! Par contre je dois admettre que je ne connais plus aucun blog l'utilisant /o.
git is great because linus did it, mercurial is better because he didn't
Je ne sais pas trop ce que l'auteur espère faire passer, les premières versions du noyau linux ne compilent pas non plus actuellement. y compris avec certains compilateurs anciens. parfois il y a des erreurs de code dont les compilateurs étaient plus laxistes.
j'ai une fois essayé de recompiler minix depuis minix en suivant la doc, j'ai aussi eu une erreur. shit happens.
git is great because linus did it, mercurial is better because he didn't
C'est un clavier azerty je suppose ? J'avais effectivement vu qu'il a un agencement un peu inhabituel. En revanche, le qwerty US est exact à ceux des PC (modulo l'échange super/alt).
git is great because linus did it, mercurial is better because he didn't
Le karma de l'utilisateur est particulièrement négatif et contient une grande partie de sujet anti vaccins et COVID n'ayant aucun rapport avec linuxfr.
Je suggère un ban.
git is great because linus did it, mercurial is better because he didn't
Oui, ce sont des ordinateurs EFI depuis presque 20 ans. On peut installer le système de son choix et éventuellement passer à opencore pour mettre du macOS plus récent. La plupart des gens aiment bien recycler des vieux Mac en Linux.
git is great because linus did it, mercurial is better because he didn't
Qu'on soit honnête, les iPad (surtout les Pro) sont de puissantes machines particulièrement intéressantes dans le graphisme et autres utilisations plus pratique qu'un laptop.
C'est bien plus qu'une tablette de divertissement où on va regarder youtube et jouer à candy crush, ce sont de véritables ordinateurs, ça n'a aucun sens de pouvoir faire ce qu'on veut d'un mac mais pas d'un iPad.
Apple devrait ouvrir l'iPad entièrement comme un Mac, qu'on puisse y installer le système que l'on souhaite.
git is great because linus did it, mercurial is better because he didn't
Quand j'ai vu le titre j'ai aussi pensé au vénérable X.Org et j'ai tout de suite pensé à une distribution qui aurait eu l'audace de plus fournir X.Org. Je suis décu, donc.
git is great because linus did it, mercurial is better because he didn't
Dans l'opensource depuis 20 ans, j'ai vu beaucoup de choses dont sourceforge, googlecode, bitbucket et le self-hosting. Clairement GitHub est le plus utilisé pour la plupart des projets que j'utilise.
Pour ma part je n'aime ni Git, ni GitHub (par pur choix personnel, rien à voir avec Microsoft) et je dois admettre que je suis ennuyé de voir cette plateforme comme la « référence » surtout avec des projets comme crates.io qui nécessite carrément d'avoir un compte GitHub pour y poser ses paquets.
Go est un peu plus permissif et permet de définir des dépendances sur des sites externes en revanche mais c'est bien plus marginal dans la communauté Rust.
Mon SCM de choix et inchangé est Mercurial depuis 2008 et ça m'amuserait de faire un paquet externe pour Rust/Go sans Git ni GitHub juste pour voir à quel point cela emmerderait les gens, habitué à « ce standard ».
git is great because linus did it, mercurial is better because he didn't
Ça ne dit pas s'ils regrettent ou non. Au départ on pense que c'est une bonne idée parce que ça a été popularisé pendant les année 2010 et on se rend compte au fur et à mesure de tout ce qui est pénible. Julien Danjou en a déjà écrit des articles concernant Lua et pourquoi il regrette l'avoir mis dans awesome. Malheureusement il semble avoir supprimé son blog donc il faudrait chercher dans webarchive.
Lua est en déclin et ce n'est pas sans raison. Pour ceux qui downvotent, j'ai maintenu Lua pendant plusieurs années dans mon application ainsi que dans ma bibliothèque Lua-SDL2 (note : ce dépôt n'est plus à moi) et j'ai beaucoup aimé le langage au début. Il y a des concepts sympa, techniquement à l'époque c'était bien au dessus de Javascript puis quand j'en ai eu marre de maintenir des #ifdef de partout j'ai estimé que ça n'en valait pas la peine. À mon travail nous sommes entrain de le retirer pour les mêmes raisons (spoiler : l'idée ne vient pas de moi).
Maintenant nous avons des alternatives ayant des fonctionnalités plus modernes avec une garantie de rétro compatibilité (ECMAScript >= 7, le monumental quickjs en pur C et étant JIT pour ne citer que lui).
git is great because linus did it, mercurial is better because he didn't
C'est tout comme en Semantic Versionning, changement cassant -> nouvelle version majeure. Ce sont des choses qui arrivent dans absolument tout les projets.
Lua ne suit pas le semantic versioning et les versions sortent à dates aléatoires puis la dernière version rend la précédente obsolète. C'est précisément ce choix arbitraire qui fait la fragmentation et une tonne de modules qui sont compatible qu'avec une version très précise de Lua.
Ce n'est pas pour rien que plus personne se risque d'écrire des modules Lua, personne n'a envie de prendre le risque de se retrouver au pied du mur. C'était notamment le cas de LuaSocket qui a mis du temps à être disponible sur les nouvelles versions car pour le développeur ça nécessite de rajouter une quantité phénoménale de #ifdef/#endif dans son module natif et des if au runtime pour un module Lua.
C'est un langage destiné à être embarqué dans un processus hôte mais même comme ça c'est une plaie pour le développeur. Love est toujours basé sur Lua 5.1 avec des petits backports par là des versions plus récentes, par conséquent on est obligé de fournir la documentation pour une version précédente et la documenter soi même en cas de modifications.
Bref, un langage destiné à faire perdre du temps avec une syntaxe et des concepts farfelus, je déconseille à tout sain d'esprit.
git is great because linus did it, mercurial is better because he didn't
Un essai a déjà été fait chez NetBSD et ça mène à rien. Lua est un mauvais langage fait par trois développeurs qui s'intéressent qu'à eux faisant chaque version un cassage de l'API C et l'API Lua en plus d'avoir une dizaines de bizarreries.
Si vous voulez perdre du temps, foncez.
git is great because linus did it, mercurial is better because he didn't
Je vais probablement passer pour un boomer mais tant pis.
J'ai atteint environ 1/3 de ma vie en âge et je dois admettre qu'après 20 ans dans le logiciel libre et le développement j'ai atteint un dégoût profond envers mon métier (je suis développeur) et la technologie en général.
À chaque fois que je regarde un produit il y a toujours quelque part un marketing "Vision" "AI ready" et autres termes inutiles.
Tout ce qui tourne autour de l'IA actuellement me donne des boutons. Certains de mes collègues utilisent ChatGPT pour répondre à des problèmes dans leur code, certains l'ont même utilisé pour me répondre à une question lors d'une merge-request. Non seulement j'ai trouvé ça particulièrement irrespectueux mais ça m'a encore plus questionné sur ce que nous sommes entrain de faire. Cet individu n'a soit pas eu envie de me répondre directement par ses propres mots soit pas compris ma question et s'est dit que ChatGPT allait me répondre à sa place. Le commentaire en question était à côté de la plaque et il ne répondait pas à ma question mais m'expliquait le morceau de code comme si j'avais aucune idée du contenu. Pour faire court, la merge request ajoutait du code pour faire une requête HTTP, le collègue a utilisé par erreur un entête content-type application/x-www-form-urlencoded or la requête envoyait du JSON, on a demandé pourquoi il a mis ce content-type précisément et la réponse de ChatGPT m'expliquait à quoi sert un content-type (merci je connais HTTP).
J'ai 20 ans de développement derrière moi, toutes mes connaissances sont acquises par l'investissement personnel, la lecture, les essais, les dents cassés, etc. Mais je sais ce que je fais dans les domaines où j'interviens. En ce moment je vois une recrudescence de collègues utilisant massivement ChatGPT au moindre problème sans même essayer d'y réfléchir et y trouver la solution. J'ai le sentiment qu'on tend vers la médiocrité croissante où le but final va être de faire un produit rapidement sans même allumer son cerveau. Tout le monde va finir par copier-coller des trucs par ci par là sans utiliser aucune des connaissances personnelles.
Ah et puis dans le côté musical, je préfère même pas commenter.
git is great because linus did it, mercurial is better because he didn't
sourcehut est une forge intéressante, mais de mon point de vue, c'est un peu le souk;
Tu cites sourcehut qui est développé par une personne ayant un égo surdimensionné, en plus cette même personne préfère justement le développement/contributions par mail plutôt que par merge requests.
Pour ceux qui pensent aller sur sourcehut, je vous invite à prendre en compte que les fortes opinions de Drew peut vous risquer votre dépôt quand un jour il décidera que ce que vous y faites n'est pas éthique selon lui.
git is great because linus did it, mercurial is better because he didn't
Et il y a eu beaucoup de contributions externes? Parce que c'est un peu l'intérêt majeur de sourceforge, github et gitlab, pour moi.
Sur un point je suis d'accord ça facilite les contributions mais ne pas passer par GitHub ça permet aussi de s'affranchir des personnes qui ne veulent pas faire les efforts nécessaires ou recevoir des PRs qui n'ont aucun sens.
Certains projets populaires sont parfois spammés par des gens qui ne font même pas parti du projet dès qu'une PR ou un tickets GitHub est popularisé via un partage reddit/hn, etc. Donc on a des individus qui débarquent sur des projets où ils n'ont jamais été juste pour “I was here” ou coller un emoji quelconque.
Les CIs sont pratiques quand on veut fournir des projets continuellement, je pense par exemple à RetroArch qui fournit des binaires tous les jours ce qui est pratique pour les projets qui changent beaucoup, ce n'est pas mon cas. La seule CI qui pourrait me servir est de m'assurer que mes projets compilent sur toutes les plateformes avant de faire une release et ça je le fais plutôt manuellement avec plusieurs VMs locales. Je n'ai pas spécialement besoin de l'automatiser.
Mais comme je suis tout de même un gens sympa et raisonnable j'ai mis des miroirs GitHub de la plupart de mes projets.
git is great because linus did it, mercurial is better because he didn't
J'ai simplement dit que la configuration n'a pas changé, les mises à jour sont faites par le gestionnaire de paquets (aka sysupgrade/pkg_add -u dans mon cas).
git is great because linus did it, mercurial is better because he didn't
L'auto-hébergement est une plaie, mais il faut être sysadmin.
Ma configuration Mercurial/nginx n'a pas changé depuis 2009. Après bien entendu installer son propre GitLab nécessite un peu de connaissance mais on parle pas non plus de faire tourner une plateforme entière. Un cgit, hgweb, gotweb c'est aisé.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: IRC
Posté par David Demelier (site web personnel) . En réponse au journal ICQ sera bronsonisé fin juin. Évalué à 3 (+1/-0).
Encore plus quand on est sur des salons peuplés de gif et d'emojis à tout va.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: XKCD et IRC
Posté par David Demelier (site web personnel) . En réponse au journal ICQ sera bronsonisé fin juin. Évalué à 2 (+0/-0).
J'aimerais bien aussi, mais malheureusement beaucoup passent à matrix et certains mettent un bridge vers IRC, alors c'est sympa mais du coup les utilisateurs d'IRC se prennent des choses un peu pénible liées au fonctionnalités de matrix comme
Correction d'un message
Envoi d'une image
J'ai
irssidans untmuxsur un shell d'un VPS, j'aime paszncet je comprends aussi les personnes qui souhaitent utiliser une application/service qui supporte directement l'historique en cas d'absence.IRC n'est pas voué à disparaitre rapidement mais je pense qu'on est quand même dans un déclin progressif.
git is great because linus did it, mercurial is better because he didn't
# À boire et à manger
Posté par David Demelier (site web personnel) . En réponse au message IA / LLM mode ou enjeu ? . Évalué à 6 (+4/-0). Dernière modification le 15 mai 2024 à 10:11.
Overdose d'IA pour ma part, de base ça m'attirait pas mais ça m'attire encore moins pour cette obsession des fabricants et des développeurs
Mais il y a à boire et à manger, tout n'est pas à jeter et heureusement. L'IA reste utile pour de nombreuses choses mais le plus important est de savoir ce que l'on décide d'en faire.
En bons exemples on peut évidemment citer tout ce qui est de la santé (à prendre avec des pincettes bien sûr), des sondes qui permettent de détecter des anomalies du cœur, cérébrales et pouvoir en être averti par des outils de tous les jours comme des montres cela est très bien. Des outils du quotidien pour nous aider dans des tâches stupides, c'est pratique. Quand je commence à remplir ma liste de courses et que mon outil de rappels me propose des choses que j'ai déjà notées dans le passé, j'avoue c'est plutôt simple mais agréable. Le détourage automatique des photos, faut être honnête ça claque et ça facilite clairement le travail. En automobile la détection de franchissement de ligne ça reste aussi bluffant même si j'ose espérer que cela reste à titre d'aide et que les conducteurs continueront d'être attentif et ne pas prendre ça comme excuse à l'inattention. Fort heureusement les voitures se doivent d'émettre un avertissement sonore au bout d'un certain temps. Toutes ces choses sont plutôt intelligentes selon moi mais évidemment l'être humain ne s'arrête pas là.
Je fais de la musique, je fais du développement et je le fais avec passion depuis plus de 20 ans. Je dois admettre que dans mon métier je vois de tous les âges et j'ai bien remarqué que les mentalités évoluent. Je passe très peu de temps sur les forums et je pose presque aucune question car j'ai appris à développer en lisant les pages de manuel, le code opensource des autres, les questions déjà posées et je vois clairement une tendance à la paresse. Beaucoup de mes collègues plus jeunes ont tendances à dégainer un google pour une question très bateau dès la première erreur de compilateur. Certains utilisent ChatGPT pour détecter des erreurs. Certes ça aide sur le moment, mais pas sur le long terme car ils vont probablement pas retenir de leur erreur puisqu'ils ne cherchent pas à la comprendre par eux même.
Concernant la musique et le graphisme je suis très inquiet. C'est incroyablement bluffant à quel points les outils vont loin et quand je cherche des images libres de droit pour illustrer mes musiques avant la production finale, je tombe déjà sur du contenu fait par IA. Ok c'est chouette pour moi car j'ai l'embarras du choix mais les personnes qui vivent de ça avec lesquelles je souhaite collaborer pour l'art final vont probablement voire leur travail sursaturé par du contenu auto généré par des personnes n'ayant ni le talent ni la passion pour le faire. Question musique, je suis incroyablement surpris par la qualité des musiques crées par IA utilisant la voix des autres, je pense bien sûr à cette chanson d'Angèle qui l'a prise de surprise elle même. J'ai bien peur que le contenu des plateforme en ligne finisse par être mélangé entre artistes et opportunistes.
Bref, j'avoue être alarmiste à ce sujet et j'ai de moins en moins envie de continuer dans le monde numérique.
Ce qui m'exaspère le plus c'est la génération de contenu frauduleux et deep fake dont on a encore malheureusement une mauvaise éducation, beaucoup de gens y croient…
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Notes
Posté par David Demelier (site web personnel) . En réponse au journal C11, listes variantes et le turfu. Évalué à 3 (+1/-0).
En fait les Makefiles bien écrits sont déjà auto-suffisant dès lors qu'on a pas trop besoin de portabilité et qu'on utilise
gccetclang,-MMDpermet de générer des règles automatiques pour les entêtes. On peut donc avoir un Makefile qui recompile tous les fichiers y compris ceux avec dépendances indirectes.On peut par exemple avoir un Makefile tout à fait correct pour compiler un projet sans écrire aucune règle, cela est encore plus flagrant quand on a un nom d'exécutable du même nom du fichier.
Avec GNU Make:
Démonstration:
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Notes
Posté par David Demelier (site web personnel) . En réponse au journal C11, listes variantes et le turfu. Évalué à 3 (+2/-1).
Non ça génère des règles de dépendances en fonction des en-tête que tu as inclus. Donc si un fichier foo.c inclue foo.h alors foo.c sera recompilé en cas de modification de foo.h grâce à une règle que
gcc -MMD/gcc -MMva générer sous la forme :Cela est nécessaire pour garantir une recompilation du code source notamment pour assurer la compatibilité binaire. Sans ça, modifier une structure ou une fonction dans un entête ne provoquera pas la recompilation des fichiers dépendants, utilisant donc une version binaire non compatible.
git is great because linus did it, mercurial is better because he didn't
# Notes
Posté par David Demelier (site web personnel) . En réponse au journal C11, listes variantes et le turfu. Évalué à 4 (+2/-0).
Sous licence GPL, pour une bibliothèque c'est la plaie. Personne ne va l'utiliser, au pire LGPL.
En C23 tout cela devient des keywords, donc à éviter.
Bof, les C11 threads sont extrêmement limités. En vrai personne ne les utilise et on préfère pthread la plupart du temps (quand on a pas besoin de portabilité) parce que les C11 threads n'ont pas de read-write lock (comme pthread_rwlock) et c'est dommage car c'est quand même pratique.
Il y a aucune fonction pour afficher les erreurs en chaine de caractère donc on peut pas faire un convivial
perrornistrerror(errno).On a aucune garantie de ce qui s'applique avec ces threads (partage des signaux bloqués, etc).
Autre note en vrac, pourquoi des script shell pour compiler du code et pas un Makefile/ CMake ?
git is great because linus did it, mercurial is better because he didn't
# Et bien dis donc
Posté par David Demelier (site web personnel) . En réponse au message dotclear ne répond pas... Évalué à 3 (+1/-0).
J'ai utilisé dotclear il y a une quinzaine d'années, j'aimais beaucoup. Je suis agréableemnt surpris de le voir encore en vie \o/ ! Par contre je dois admettre que je ne connais plus aucun blog l'utilisant /o.
git is great because linus did it, mercurial is better because he didn't
# Pas étonnant
Posté par David Demelier (site web personnel) . En réponse au lien MS-DOS 4.0 Source Code Fails to Compile. Évalué à 8 (+6/-0).
Je ne sais pas trop ce que l'auteur espère faire passer, les premières versions du noyau linux ne compilent pas non plus actuellement. y compris avec certains compilateurs anciens. parfois il y a des erreurs de code dont les compilateurs étaient plus laxistes.
j'ai une fois essayé de recompiler minix depuis minix en suivant la doc, j'ai aussi eu une erreur. shit happens.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Il était temps
Posté par David Demelier (site web personnel) . En réponse au lien Apple sera forcé d’ouvrir l’iPad en Europe, comme l’iPhone - numerama. Évalué à 3 (+1/-0).
C'est un clavier azerty je suppose ? J'avais effectivement vu qu'il a un agencement un peu inhabituel. En revanche, le qwerty US est exact à ceux des PC (modulo l'échange super/alt).
git is great because linus did it, mercurial is better because he didn't
# Ban ?
Posté par David Demelier (site web personnel) . En réponse au journal Epidémie de Fraudes : Où l’on reparle de l’HCQ.. Évalué à 7 (+10/-5).
Le karma de l'utilisateur est particulièrement négatif et contient une grande partie de sujet anti vaccins et COVID n'ayant aucun rapport avec linuxfr.
Je suggère un ban.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Il était temps
Posté par David Demelier (site web personnel) . En réponse au lien Apple sera forcé d’ouvrir l’iPad en Europe, comme l’iPhone - numerama. Évalué à 4 (+2/-0).
Sur un Intel tu maintiens la touche option au démarrage et tu boot sur la clé USB de ton choix (Windows, Linux).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Il était temps
Posté par David Demelier (site web personnel) . En réponse au lien Apple sera forcé d’ouvrir l’iPad en Europe, comme l’iPhone - numerama. Évalué à 3 (+1/-0).
Oui, ce sont des ordinateurs EFI depuis presque 20 ans. On peut installer le système de son choix et éventuellement passer à opencore pour mettre du macOS plus récent. La plupart des gens aiment bien recycler des vieux Mac en Linux.
git is great because linus did it, mercurial is better because he didn't
# Il était temps
Posté par David Demelier (site web personnel) . En réponse au lien Apple sera forcé d’ouvrir l’iPad en Europe, comme l’iPhone - numerama. Évalué à 2 (+0/-0).
Qu'on soit honnête, les iPad (surtout les Pro) sont de puissantes machines particulièrement intéressantes dans le graphisme et autres utilisations plus pratique qu'un laptop.
C'est bien plus qu'une tablette de divertissement où on va regarder youtube et jouer à candy crush, ce sont de véritables ordinateurs, ça n'a aucun sens de pouvoir faire ce qu'on veut d'un mac mais pas d'un iPad.
Apple devrait ouvrir l'iPad entièrement comme un Mac, qu'on puisse y installer le système que l'on souhaite.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: À côté
Posté par David Demelier (site web personnel) . En réponse au lien X c’est fini. Évalué à 3 (+2/-1).
Quand j'ai vu le titre j'ai aussi pensé au vénérable X.Org et j'ai tout de suite pensé à une distribution qui aurait eu l'audace de plus fournir X.Org. Je suis décu, donc.
git is great because linus did it, mercurial is better because he didn't
# J'espère voir une décentralisation
Posté par David Demelier (site web personnel) . En réponse à la dépêche Codeberg, la forge en devenir pour les projets libres ?. Évalué à 10 (+9/-1).
Dans l'opensource depuis 20 ans, j'ai vu beaucoup de choses dont sourceforge, googlecode, bitbucket et le self-hosting. Clairement GitHub est le plus utilisé pour la plupart des projets que j'utilise.
Pour ma part je n'aime ni Git, ni GitHub (par pur choix personnel, rien à voir avec Microsoft) et je dois admettre que je suis ennuyé de voir cette plateforme comme la « référence » surtout avec des projets comme crates.io qui nécessite carrément d'avoir un compte GitHub pour y poser ses paquets.
Go est un peu plus permissif et permet de définir des dépendances sur des sites externes en revanche mais c'est bien plus marginal dans la communauté Rust.
Mon SCM de choix et inchangé est Mercurial depuis 2008 et ça m'amuserait de faire un paquet externe pour Rust/Go sans Git ni GitHub juste pour voir à quel point cela emmerderait les gens, habitué à « ce standard ».
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quelle idée
Posté par David Demelier (site web personnel) . En réponse au lien Lunatik - Un framework pour scripter le noyau Linux avec Lua. Évalué à 3 (+1/-0).
Ça ne dit pas s'ils regrettent ou non. Au départ on pense que c'est une bonne idée parce que ça a été popularisé pendant les année 2010 et on se rend compte au fur et à mesure de tout ce qui est pénible. Julien Danjou en a déjà écrit des articles concernant Lua et pourquoi il regrette l'avoir mis dans awesome. Malheureusement il semble avoir supprimé son blog donc il faudrait chercher dans webarchive.
Lua est en déclin et ce n'est pas sans raison. Pour ceux qui downvotent, j'ai maintenu Lua pendant plusieurs années dans mon application ainsi que dans ma bibliothèque Lua-SDL2 (note : ce dépôt n'est plus à moi) et j'ai beaucoup aimé le langage au début. Il y a des concepts sympa, techniquement à l'époque c'était bien au dessus de Javascript puis quand j'en ai eu marre de maintenir des
#ifdefde partout j'ai estimé que ça n'en valait pas la peine. À mon travail nous sommes entrain de le retirer pour les mêmes raisons (spoiler : l'idée ne vient pas de moi).Maintenant nous avons des alternatives ayant des fonctionnalités plus modernes avec une garantie de rétro compatibilité (ECMAScript >= 7, le monumental quickjs en pur C et étant JIT pour ne citer que lui).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quelle idée
Posté par David Demelier (site web personnel) . En réponse au lien Lunatik - Un framework pour scripter le noyau Linux avec Lua. Évalué à 1 (+0/-1).
Lua ne suit pas le semantic versioning et les versions sortent à dates aléatoires puis la dernière version rend la précédente obsolète. C'est précisément ce choix arbitraire qui fait la fragmentation et une tonne de modules qui sont compatible qu'avec une version très précise de Lua.
Ce n'est pas pour rien que plus personne se risque d'écrire des modules Lua, personne n'a envie de prendre le risque de se retrouver au pied du mur. C'était notamment le cas de LuaSocket qui a mis du temps à être disponible sur les nouvelles versions car pour le développeur ça nécessite de rajouter une quantité phénoménale de
#ifdef/#endifdans son module natif et desifau runtime pour un module Lua.C'est un langage destiné à être embarqué dans un processus hôte mais même comme ça c'est une plaie pour le développeur. Love est toujours basé sur Lua 5.1 avec des petits backports par là des versions plus récentes, par conséquent on est obligé de fournir la documentation pour une version précédente et la documenter soi même en cas de modifications.
Bref, un langage destiné à faire perdre du temps avec une syntaxe et des concepts farfelus, je déconseille à tout sain d'esprit.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Barbant
Posté par David Demelier (site web personnel) . En réponse au lien Pour Linus Torvalds, voir toute cette hype sur l'IA c'est hilarant 🍿. Évalué à 7 (+5/-0).
Mandrake 10.0 ~2003/2004, pentium 4 et 512Mo de RAM à 14-15 ans donc. Oui j'ai connu et installé firefox 1.0, KDE 3.5, GNOME 2.8 (Fedora Core 3 ❤️) 🫠.
git is great because linus did it, mercurial is better because he didn't
# Quelle idée
Posté par David Demelier (site web personnel) . En réponse au lien Lunatik - Un framework pour scripter le noyau Linux avec Lua. Évalué à -1 (+1/-4).
Un essai a déjà été fait chez NetBSD et ça mène à rien. Lua est un mauvais langage fait par trois développeurs qui s'intéressent qu'à eux faisant chaque version un cassage de l'API C et l'API Lua en plus d'avoir une dizaines de bizarreries.
Si vous voulez perdre du temps, foncez.
git is great because linus did it, mercurial is better because he didn't
# Barbant
Posté par David Demelier (site web personnel) . En réponse au lien Pour Linus Torvalds, voir toute cette hype sur l'IA c'est hilarant 🍿. Évalué à 10 (+26/-0).
Je vais probablement passer pour un boomer mais tant pis.
J'ai atteint environ 1/3 de ma vie en âge et je dois admettre qu'après 20 ans dans le logiciel libre et le développement j'ai atteint un dégoût profond envers mon métier (je suis développeur) et la technologie en général.
À chaque fois que je regarde un produit il y a toujours quelque part un marketing "Vision" "AI ready" et autres termes inutiles.
Tout ce qui tourne autour de l'IA actuellement me donne des boutons. Certains de mes collègues utilisent ChatGPT pour répondre à des problèmes dans leur code, certains l'ont même utilisé pour me répondre à une question lors d'une merge-request. Non seulement j'ai trouvé ça particulièrement irrespectueux mais ça m'a encore plus questionné sur ce que nous sommes entrain de faire. Cet individu n'a soit pas eu envie de me répondre directement par ses propres mots soit pas compris ma question et s'est dit que ChatGPT allait me répondre à sa place. Le commentaire en question était à côté de la plaque et il ne répondait pas à ma question mais m'expliquait le morceau de code comme si j'avais aucune idée du contenu. Pour faire court, la merge request ajoutait du code pour faire une requête HTTP, le collègue a utilisé par erreur un entête content-type
application/x-www-form-urlencodedor la requête envoyait du JSON, on a demandé pourquoi il a mis ce content-type précisément et la réponse de ChatGPT m'expliquait à quoi sert un content-type (merci je connais HTTP).J'ai 20 ans de développement derrière moi, toutes mes connaissances sont acquises par l'investissement personnel, la lecture, les essais, les dents cassés, etc. Mais je sais ce que je fais dans les domaines où j'interviens. En ce moment je vois une recrudescence de collègues utilisant massivement ChatGPT au moindre problème sans même essayer d'y réfléchir et y trouver la solution. J'ai le sentiment qu'on tend vers la médiocrité croissante où le but final va être de faire un produit rapidement sans même allumer son cerveau. Tout le monde va finir par copier-coller des trucs par ci par là sans utiliser aucune des connaissances personnelles.
Ah et puis dans le côté musical, je préfère même pas commenter.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 1 (+0/-1).
Tu cites sourcehut qui est développé par une personne ayant un égo surdimensionné, en plus cette même personne préfère justement le développement/contributions par mail plutôt que par merge requests.
Pour ceux qui pensent aller sur sourcehut, je vous invite à prendre en compte que les fortes opinions de Drew peut vous risquer votre dépôt quand un jour il décidera que ce que vous y faites n'est pas éthique selon lui.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 3 (+1/-0).
Sur un point je suis d'accord ça facilite les contributions mais ne pas passer par GitHub ça permet aussi de s'affranchir des personnes qui ne veulent pas faire les efforts nécessaires ou recevoir des PRs qui n'ont aucun sens.
Certains projets populaires sont parfois spammés par des gens qui ne font même pas parti du projet dès qu'une PR ou un tickets GitHub est popularisé via un partage reddit/hn, etc. Donc on a des individus qui débarquent sur des projets où ils n'ont jamais été juste pour “I was here” ou coller un emoji quelconque.
Les CIs sont pratiques quand on veut fournir des projets continuellement, je pense par exemple à RetroArch qui fournit des binaires tous les jours ce qui est pratique pour les projets qui changent beaucoup, ce n'est pas mon cas. La seule CI qui pourrait me servir est de m'assurer que mes projets compilent sur toutes les plateformes avant de faire une release et ça je le fais plutôt manuellement avec plusieurs VMs locales. Je n'ai pas spécialement besoin de l'automatiser.
Mais comme je suis tout de même un gens sympa et raisonnable j'ai mis des miroirs GitHub de la plupart de mes projets.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 4 (+2/-0).
J'ai simplement dit que la configuration n'a pas changé, les mises à jour sont faites par le gestionnaire de paquets (aka
sysupgrade/pkg_add -udans mon cas).git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 2 (+0/-0). Dernière modification le 03 avril 2024 à 11:22.
Ma configuration Mercurial/nginx n'a pas changé depuis 2009. Après bien entendu installer son propre GitLab nécessite un peu de connaissance mais on parle pas non plus de faire tourner une plateforme entière. Un cgit, hgweb, gotweb c'est aisé.
git is great because linus did it, mercurial is better because he didn't
# Réaction de GitHub
Posté par David Demelier (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 10 (+9/-0).
GitHub a fermé le compte de Lasse Collin et les enregistrements DNS (xz.tukaani.org) Comme si Lasse était 100% responsable.
Voilà pourquoi je conseille à tout le monde d'héberger ses propres projets opensource.
git is great because linus did it, mercurial is better because he didn't