Je suis le projet serenity depuis le début et j'adore voir son avancé. Je suis content pour le navigateur ladybird et ce don massif mais c'est vrai que les derniers temps il fait un peu d'ombre au projet entier. J'espère que serenity ne passera pas trop au second plan car c'est impressionnant le travail réalisé en si peu de temps.
J'aime pas spécialement Rust (surtout pour sa syntaxe, donc complètement subjectif) mais j'ai rien contre le langage directement. Par contre je déteste les crates.io et l'écosystème qui en est lié. Déjà parce qu'il faut obligatoirement un compte GitHub pour publier mais parce qu'il est conçu comme npm, on fait des modules de 10 lignes et on en revient à télécharger la terre entière pour un projet quelconque.
Alors pour Rust on va dire que c'est moins grave car les LTO et la compilation fait que cela reste moins bloat que les projets nodejs mais ça n'en est pas moins énervant. Plus il y a de pièces en mouvements dans un moteur, plus il y a de risques. Le gros problème est évidemment lié au SPOF. N'importe qui avec une simple dépendance peut introduire une backdoor en rien de temps.
Ce qui me chiffonne le plus c'est l'aspect mise à jour de sécurité. Là où des bibliothèque partagées permettent de sécuriser un système avec une simple mise à jour de la .(dll|so|dylib), les projets Rust doivent tous être recompilés. On va dire que ce n'est pas mieux avec les projets externes directement intégrés dans un projet mais ça doit rester anecdotique.
Aucune solution n'est parfaite mais pour moi tous les écosystèmes basés sur ce concept comme Rust, Go et npm sont vérolés de base en plus d'être des plaies pour les packagers Linux/*BSD.
ça c'est pas spécialement lié à la nouvelle fonctionnalité, on aurait pu faire en sorte qu'en cas de kp le contexte graphique bascule sur la console (comme on peut faire un chvt actuellement). d'ailleurs FreeBSD a une option pour ça de mémoire.
Chez RedHat au lieu d'écrire un frontend décent à rpm on invente des écran de kernel panic pour quelque chose qui n'arrive jamais.
20 ans de vie sous Linux, les rares kernel panic que j'ai eu étaient liés à ma carte nvidia des années 2004/2005.
Pourtant, je cherche les embrouilles, entre fedora, arch et des kernels maison je suis tout de même à risque. m'enfin, on a aussi inventé plymouth pour que ce soit joli au démarrage, au moins ce sera aussi joli au crash.
Architecture ouverte, explicitement simple et extensions clairement définies donc facile à implémenter côté outils de développement et fabrication de puces.
D'ailleurs quand ARM a essayé de détruire RISC-V avec leur campagne de FUD, le retour de baton a été dur et explique notamment en quoi ARM est inférieur. Voir arm-basics.com et ses milliards d'extensions différentes et incompatibles.
De plus quiconque s'aventure dans le développement embarqué pour ARM se doit de se faire prescrire une quantité astronomique d’antidépresseur. Entre les toolchains fournis par ARM et leur documentation compliquées à rechercher, les licences à tout va, les SDKs fournis par les fabricants complètement incompatible avec un toolchain ou un autre et CMSIS qui dans la théorie est bien mais est complètement inutilisable on arrive vite à un sentiment de frustration. Puis même les plus anciens comprennent toujours pas la différence entre Keil et ARM tellement c'est un foutoir monstre.
Oh, je parle pas de tous ces fabricants fournissant un IDE sous eclipse (hein, STM32, NXP).
J'ai acheté une milk-v meles dès que j'ai eu une notification de stock et j'ai aussi pris un coupon pour leur futur milk-v oasis. Hâte de voir ce que ça peut donner au quotidien, en tout cas des essais sur une carte mère haut de gamme comme la pioneer n'a pas enchanté certains testeurs.
Je suis fan de RISC-V et je veux voir cette architecture avancer à grand pas. J'utilise beaucoup de modules ESP32 chez moi (les variantes RISC-V bien entendu) et je les pousse au travail aussi.
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.
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…
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.
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 ?
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.
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.
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).
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.
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.
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.
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.
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 ».
Ç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).
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.
# La classe
Posté par David Demelier (site web personnel) . En réponse à la dépêche Pour 100 briques t'as plus rien : le navigateur Ladybird reçoit un million de brouzoufs. Évalué à 5.
Je suis le projet serenity depuis le début et j'adore voir son avancé. Je suis content pour le navigateur ladybird et ce don massif mais c'est vrai que les derniers temps il fait un peu d'ombre au projet entier. J'espère que serenity ne passera pas trop au second plan car c'est impressionnant le travail réalisé en si peu de temps.
AI is a mental disorder
# Éternel problème des SPOF
Posté par David Demelier (site web personnel) . En réponse au journal Mon inquiétude sur les dépendances en Rust. Évalué à 10.
J'aime pas spécialement Rust (surtout pour sa syntaxe, donc complètement subjectif) mais j'ai rien contre le langage directement. Par contre je déteste les crates.io et l'écosystème qui en est lié. Déjà parce qu'il faut obligatoirement un compte GitHub pour publier mais parce qu'il est conçu comme npm, on fait des modules de 10 lignes et on en revient à télécharger la terre entière pour un projet quelconque.
Alors pour Rust on va dire que c'est moins grave car les LTO et la compilation fait que cela reste moins bloat que les projets nodejs mais ça n'en est pas moins énervant. Plus il y a de pièces en mouvements dans un moteur, plus il y a de risques. Le gros problème est évidemment lié au SPOF. N'importe qui avec une simple dépendance peut introduire une backdoor en rien de temps.
Ce qui me chiffonne le plus c'est l'aspect mise à jour de sécurité. Là où des bibliothèque partagées permettent de sécuriser un système avec une simple mise à jour de la
.(dll|so|dylib), les projets Rust doivent tous être recompilés. On va dire que ce n'est pas mieux avec les projets externes directement intégrés dans un projet mais ça doit rester anecdotique.Aucune solution n'est parfaite mais pour moi tous les écosystèmes basés sur ce concept comme Rust, Go et npm sont vérolés de base en plus d'être des plaies pour les packagers Linux/*BSD.
AI is a mental disorder
[^] # Re: article de merde
Posté par David Demelier (site web personnel) . En réponse au lien Le BSOD pour Linux, ce sera dans le noyau 6.10. Enfin ;-). Évalué à 2.
Ça fait un moment que la console fait plus que 80 caractères même sans DRM.
AI is a mental disorder
[^] # Re: article de merde
Posté par David Demelier (site web personnel) . En réponse au lien Le BSOD pour Linux, ce sera dans le noyau 6.10. Enfin ;-). Évalué à 4.
ça c'est pas spécialement lié à la nouvelle fonctionnalité, on aurait pu faire en sorte qu'en cas de kp le contexte graphique bascule sur la console (comme on peut faire un
chvtactuellement). d'ailleurs FreeBSD a une option pour ça de mémoire.AI is a mental disorder
[^] # Re: article de merde
Posté par David Demelier (site web personnel) . En réponse au lien Le BSOD pour Linux, ce sera dans le noyau 6.10. Enfin ;-). Évalué à 3.
D'autant plus que dès le départ le titre est faux :
Non justement, le kernel panic a déjà des détails, l'ajout de ce *SOD aura pour but de le rendre moins disgracieux pour le commun des mortels.
AI is a mental disorder
# Ah RedHat
Posté par David Demelier (site web personnel) . En réponse au lien Le BSOD pour Linux, ce sera dans le noyau 6.10. Enfin ;-). Évalué à 1. Dernière modification le 25 juin 2024 à 13:26.
Chez RedHat au lieu d'écrire un frontend décent à
rpmon invente des écran de kernel panic pour quelque chose qui n'arrive jamais.20 ans de vie sous Linux, les rares kernel panic que j'ai eu étaient liés à ma carte nvidia des années 2004/2005.
Pourtant, je cherche les embrouilles, entre fedora, arch et des kernels maison je suis tout de même à risque. m'enfin, on a aussi inventé plymouth pour que ce soit joli au démarrage, au moins ce sera aussi joli au crash.
AI is a mental disorder
[^] # Re: Je reçois ma milk-v meles bientôt
Posté par David Demelier (site web personnel) . En réponse au journal Le RISC-V pour le Desktop, on en reparle ?. Évalué à 6. Dernière modification le 19 juin 2024 à 11:30.
Architecture ouverte, explicitement simple et extensions clairement définies donc facile à implémenter côté outils de développement et fabrication de puces.
D'ailleurs quand ARM a essayé de détruire RISC-V avec leur campagne de FUD, le retour de baton a été dur et explique notamment en quoi ARM est inférieur. Voir arm-basics.com et ses milliards d'extensions différentes et incompatibles.
De plus quiconque s'aventure dans le développement embarqué pour ARM se doit de se faire prescrire une quantité astronomique d’antidépresseur. Entre les toolchains fournis par ARM et leur documentation compliquées à rechercher, les licences à tout va, les SDKs fournis par les fabricants complètement incompatible avec un toolchain ou un autre et CMSIS qui dans la théorie est bien mais est complètement inutilisable on arrive vite à un sentiment de frustration. Puis même les plus anciens comprennent toujours pas la différence entre Keil et ARM tellement c'est un foutoir monstre.
Oh, je parle pas de tous ces fabricants fournissant un IDE sous eclipse (hein, STM32, NXP).
AI is a mental disorder
# Je reçois ma milk-v meles bientôt
Posté par David Demelier (site web personnel) . En réponse au journal Le RISC-V pour le Desktop, on en reparle ?. Évalué à 10.
J'ai acheté une milk-v meles dès que j'ai eu une notification de stock et j'ai aussi pris un coupon pour leur futur milk-v oasis. Hâte de voir ce que ça peut donner au quotidien, en tout cas des essais sur une carte mère haut de gamme comme la pioneer n'a pas enchanté certains testeurs.
Je suis fan de RISC-V et je veux voir cette architecture avancer à grand pas. J'utilise beaucoup de modules ESP32 chez moi (les variantes RISC-V bien entendu) et je les pousse au travail aussi.
Vive RISC-V !
AI is a mental disorder
[^] # Re: IRC
Posté par David Demelier (site web personnel) . En réponse au journal ICQ sera bronsonisé fin juin. Évalué à 3.
Encore plus quand on est sur des salons peuplés de gif et d'emojis à tout va.
AI is a mental disorder
[^] # Re: XKCD et IRC
Posté par David Demelier (site web personnel) . En réponse au journal ICQ sera bronsonisé fin juin. Évalué à 2.
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.
AI is a mental disorder
# À boire et à manger
Posté par David Demelier (site web personnel) . En réponse au message IA / LLM mode ou enjeu ? . Évalué à 6. 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…
AI is a mental disorder
[^] # Re: Notes
Posté par David Demelier (site web personnel) . En réponse au journal C11, listes variantes et le turfu. Évalué à 3.
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:
AI is a mental disorder
[^] # Re: Notes
Posté par David Demelier (site web personnel) . En réponse au journal C11, listes variantes et le turfu. Évalué à 3.
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.
AI is a mental disorder
# Notes
Posté par David Demelier (site web personnel) . En réponse au journal C11, listes variantes et le turfu. Évalué à 4.
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 ?
AI is a mental disorder
# Et bien dis donc
Posté par David Demelier (site web personnel) . En réponse au message dotclear ne répond pas... Évalué à 3.
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.
AI is a mental disorder
# 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.
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.
AI is a mental disorder
[^] # 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.
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).
AI is a mental disorder
# 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.
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.
AI is a mental disorder
[^] # 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.
Sur un Intel tu maintiens la touche option au démarrage et tu boot sur la clé USB de ton choix (Windows, Linux).
AI is a mental disorder
[^] # 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.
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.
AI is a mental disorder
# 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.
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.
AI is a mental disorder
[^] # Re: À côté
Posté par David Demelier (site web personnel) . En réponse au lien X c’est fini. Évalué à 3.
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.
AI is a mental disorder
# 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.
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 ».
AI is a mental disorder
[^] # 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.
Ç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).
AI is a mental disorder
[^] # 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.
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.
AI is a mental disorder