Moi j'ai beau avoir fait anglais du début jusqu'à la fin j'ai jamais appris they comme pronom neutre (mes études se sont finies en 2012). Alors si les temps changent il faut aussi former les gens à l'utiliser et forcément avec l'âge certains sont moins ouvert à ça.
Essayer de faire adopter iel à des >= 50 ans, je serais curieux de voir le résultat.
Déjà, ce genre de formulation, c'est mauvais signe.
Mauvais signe c'est peut-être un peu brutal. Ils ont probablement juste pas envie de se faire surcharger par des MR qui ne sont pas techniques. Chez OpenBSD et FreeBSD je me suis déjà fait refuser des commit cosmétique juste parce que « ça ne résout pas un problème directement ».
De mémoire Andreas Kling est suédois, je ne sais pas trop comment fonctionnent les pronoms dans cette langue mais dans la notre nous avons aussi un éternel problème de genre.
Dans l'exemple qu'on voit l'utilisateur anon n'est même pas physique donc le pronom he/she n'a aucun sens. Refuser le changement est discutable mais pas spécialement lié à une appartenance de genre ou quelconque misogynie soupçonnée. Certes la réponse de Andreas fut brutale et j'en suis moi même surpris compte tenu de toutes les vidéos que j'ai déjà pu voir en live où il répond aux questions avec beaucoup de diplomatie et de bienveillance.
Pour revenir à l'exemple, si je devais écrire cette documentation naïvement en français je pourrais le faire sous cette forme :
« Retirez l'utilisateur anon du groupe wheel et il ne pourra plus utiliser /bin/su »
L'utilisateur au sens système d'exploitation est irréel et n'a donc aucune notion de genre. Pour notre langue, ce sera donc bien il qu'on utilisera. En anglais si je ne dis pas de bêtises they est accepté comme neutre mais pas légalement et pour une bonne partie des non-natif une phrase comme celle ci peut sembler étrange.
La formulation de base devrait être écrire d'une manière complètement différente comme :
“To prevent this, remove anon from the wheel group and it will no longer be able to run /bin/su”
ou
“Remove anon from wheel group to disable use of /bin/su”
Quoi qu'il en soit, je crois qu'on arrive dans une époque où on se sent obligé de catégoriser les personnes dès la première incompréhension. Les personnes ayant interagit avec Andreas sur cette issue et par les mastodon interposés ne le connaissent probablement pas personnellement et ont immédiatement lancé une presse à scandale pour quelque chose de particulièrement superflu.
Dans serenity quasiment tout est fait maison et le projet n'a pas d'ambition d'être un OS grand public donc l'idée de tout développer n'est pas un problème car c'est fait par passion et par envie. Le projet ladybird a commencé dans serenity de la même manière, être d'abord un petit navigateur pour afficher la documentation et puis au fur et à mesure on est allé plus loin.
Mon avis : si on doit créer des navigateur basés sur gecko/webkit/chromium on aura effectivement une grande partie du travail déjà réalisé mais nous sommes d'ores et déjà noyé par une quantité de navigateurs opensource. En plus, les 3/4 se ressemblent déjà visuellement alors je n'y vois peu d'intérêt à en faire un énième sur le même moteur.
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.
[^] # Re: dev principal de Ladybird
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é à 8.
Moi j'ai beau avoir fait anglais du début jusqu'à la fin j'ai jamais appris
theycomme pronom neutre (mes études se sont finies en 2012). Alors si les temps changent il faut aussi former les gens à l'utiliser et forcément avec l'âge certains sont moins ouvert à ça.Essayer de faire adopter
ielà des >= 50 ans, je serais curieux de voir le résultat.AI is a mental disorder
[^] # Re: Tout le monde aime le Milkshake Duck
Posté par David Demelier (site web personnel) . En réponse au lien Changement de gouvernance pour le navigateur indépendant Ladybird . Évalué à 4.
Mauvais signe c'est peut-être un peu brutal. Ils ont probablement juste pas envie de se faire surcharger par des MR qui ne sont pas techniques. Chez OpenBSD et FreeBSD je me suis déjà fait refuser des commit cosmétique juste parce que « ça ne résout pas un problème directement ».
De mémoire Andreas Kling est suédois, je ne sais pas trop comment fonctionnent les pronoms dans cette langue mais dans la notre nous avons aussi un éternel problème de genre.
Dans l'exemple qu'on voit l'utilisateur
anonn'est même pas physique donc le pronomhe/shen'a aucun sens. Refuser le changement est discutable mais pas spécialement lié à une appartenance de genre ou quelconque misogynie soupçonnée. Certes la réponse de Andreas fut brutale et j'en suis moi même surpris compte tenu de toutes les vidéos que j'ai déjà pu voir en live où il répond aux questions avec beaucoup de diplomatie et de bienveillance.Pour revenir à l'exemple, si je devais écrire cette documentation naïvement en français je pourrais le faire sous cette forme :
« Retirez l'utilisateur anon du groupe wheel et il ne pourra plus utiliser /bin/su »
L'utilisateur au sens système d'exploitation est irréel et n'a donc aucune notion de genre. Pour notre langue, ce sera donc bien
ilqu'on utilisera. En anglais si je ne dis pas de bêtisestheyest accepté comme neutre mais pas légalement et pour une bonne partie des non-natif une phrase comme celle ci peut sembler étrange.La formulation de base devrait être écrire d'une manière complètement différente comme :
“To prevent this, remove
anonfrom thewheelgroup and it will no longer be able to run/bin/su”ou
“Remove
anonfromwheelgroup to disable use of/bin/su”Quoi qu'il en soit, je crois qu'on arrive dans une époque où on se sent obligé de catégoriser les personnes dès la première incompréhension. Les personnes ayant interagit avec Andreas sur cette issue et par les mastodon interposés ne le connaissent probablement pas personnellement et ont immédiatement lancé une presse à scandale pour quelque chose de particulièrement superflu.
AI is a mental disorder
[^] # Re: Pourquoi refaire un moteur de rendu ?
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é à 8.
Dans serenity quasiment tout est fait maison et le projet n'a pas d'ambition d'être un OS grand public donc l'idée de tout développer n'est pas un problème car c'est fait par passion et par envie. Le projet ladybird a commencé dans serenity de la même manière, être d'abord un petit navigateur pour afficher la documentation et puis au fur et à mesure on est allé plus loin.
Mon avis : si on doit créer des navigateur basés sur gecko/webkit/chromium on aura effectivement une grande partie du travail déjà réalisé mais nous sommes d'ores et déjà noyé par une quantité de navigateurs opensource. En plus, les 3/4 se ressemblent déjà visuellement alors je n'y vois peu d'intérêt à en faire un énième sur le même moteur.
AI is a mental disorder
# 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