D'ailleurs en voyant tous ces raccourcis, on ressent que le créateur est féru d'emacs. En tant que féru de vim, j'ai peur pour mes doigts tant je n'ai pas l'habitude. Surtout quand je vois des raccourcis comme :
C-x C-c s
Quelqu'un a déjà utilisé next au quotidien pour partager son avis ?
git is great because linus did it, mercurial is better because he didn't
Je ne comprends pas pourquoi tu passes tout simplement pas à côté de ces choses qui te dérangent.
Je ne lis pas tous les journaux tout simplement parce que certains ne m'intéressent pas. Comme tu le dis, quand ça part dans des débats ou totalement à côté de l'informatique : je passe tout simplement au suivant.
git is great because linus did it, mercurial is better because he didn't
de plus en plus d'essais de compiler une distro Linux entière avec LLVM
C'est ce que je suis entrain de faire. Dans l'ensemble ça fonctionne plutôt bien avec 2/3 patchs par ci par là.
Le plus gros problème sont les projets surtout initiés par RedHat qui contiennent pas mal d'extensions et pas toujours compatible. À ce jour, grub, elfutils et le noyau Linux nécessitent encore gcc.
En grande partie, le système peut tourner sans GCC (ni libgcc/gcc_s).
git is great because linus did it, mercurial is better because he didn't
Parfois j'ai l'impression que beaucoup de personnes pensent que RMS est le père et le dieu gourou du libre. Ce qu'il pense, ce qu'il fait ça n'a pas d'importance. GNU n'est pas le seul projet libre sur terre.
Par ailleurs, les distributions ne dépendent plus forcément de projets GNU et donc ni Linux ni le libre doit être associé à GNU. Le terme GNU/Linux n'est plus si vrai, il y a beaucoup de distributions qui se passent des composants GNU.
En bref, ne plus faire l'amalgame de RMS/GNU == Libre. Non, loin de là. Il a écrit des licences, il a écrit emacs et GCC mais il y a pas que ça sur terre en libre. Et heureusement. Ainsi peu importe comment RMS se comporte ou agit, ça n'a aucune influence sur le libre.
git is great because linus did it, mercurial is better because he didn't
Le libre c'est pas une guerre contre les logiciels privateurs. Personnellement je m'en fiche que des serveurs dans le monde ou que mon entourage utilise Windows, c'est leur problème pas le mien. D'ailleurs un ami à moi s'est fait pirater son serveur Windows par un ransomware, je lui ai simplement dit que s'il utilisait un système correct avec des backups ce ne serait pas arrivé. C'est en faisant des erreurs qu'on apprend.
Il y a plusieurs types de visions du libre dans ce domaine, il y a les sectaires purs et durs qui sont anti logiciels privateurs et tentent au maximum de faire changer les choses et il y a les gens comme moi qui font du libre simplement parce qu'ils aiment ça.
La vision du libre varie tellement qu'on a différentes licences. Ça se résume plus ou moins entre le permissif et le non permissif. Moi je fais du permissif parce que la seule chose qui m'intéresse c'est de fournir mon code et qu'on puisse y contribuer, voir, commenter. Si on l'utilise et qu'on me contribue en retour je suis content, si on l'utilise pour faire du privateur, tant pis c'est pas si grave. Le reste, c'est à vous en tant que consommateur de faire les bon choix. Si Apple, Microsoft ou Google ne rend pas en retour, alors n'achetez pas leur produit. Aussi simple que ça.
git is great because linus did it, mercurial is better because he didn't
Je viens de tester c'est pas génial avec les polices monospaces. Par exemple la table des matière alignées avec des …… pour les numéros de pages sont complètement illisibles avec le mode lecture.
git is great because linus did it, mercurial is better because he didn't
Ah, et les bibliothèques, c'est fait pour les chiens ?
Oh le naïf. Penses-tu vraiment que c'est aussi simple que ça ? Rien que la bibliothèque alsa nécessite plusieurs appels de fonctions pour juste récupérer le volume courant. Alors imagine quand il s'agit de transmettre du son. En plus il existe plusieurs bibliothèques, mais à vrai dire le son sous Linux a toujours et malheureusement été un bordel monstre.
Tiens sinon une question que je me pose … Peut-on avoir sur une mahines deux instances de serveur pulseaudio qui redirigerait les sons vers deux hardwares différents ? Pas 1 serveur qui gère tout, mais la possibilité d'avoir 1 serveur par carte son par exemple (c'est pas anodin comme question, je pourrais avoir besoin de ça un de ces 4).
Je ne sais pas pour pulseaudio, en tout cas NAS était prévu pour ça mais il est largement tombé en désuétude. Je l'ai un peu essayé par le passé mais c'était loin d'être parfait.
git is great because linus did it, mercurial is better because he didn't
Exactement, c'est au serveur de son de faire le travail. D'autant plus que si on utilise plusieurs applications audio, on a pas envie de se prendre la tête à rediriger chacune d'entre elle via les options / configuration / interfaces graphique de celles ci.
Sinon on implémente la même fonctionnalité 1000 fois dans toutes les applications qui font de l'audio et on a donc 1000 fois une implémentation avec possibles bugs à résoudre et maintenir.
En bref à chacun sa responsabilité :
lecteur audio : salut, je joue ça maintenant.
serveur audio : bien reçu j'envoie ça sur l'enceinte bluetooth via bluez.
git is great because linus did it, mercurial is better because he didn't
Oui mais d'un point de vue perf tu y gagne avec Lua.
LuaJIT oui, Lua pur non.
Et Lua est un langage assez simple et relativement connu surtout dans le scripting pour jeu.
C'est un langage simple mais pas spécialement agréable à utiliser pour l'avoir mis dans mes applications. Comparé au Javascript moderne :
Pas de support complet de l'unicode (ormis 2-3 fonctions anémiques) ;
Orienté objet pénible ;
Aucune rétrocompatibilité garantie (et les 3 auteurs ne se retiennent pas à casser plein de choses d'une version à l'autre) ;
Pas de continue mais break et goto existent ;
Les tableaux commencent à 1 (oui on peut les faire commencer à 0 mais les fonctions standard ne les fonctionneront pas bien avec) ;
Syntaxe non égal(e) bizarre ~= ;
Les tableau et maps sont le même objet et ça pose pas mal de problèmes et d'incompréhensions ;
Expressions régulières maison largement inférieures.
Et à côté de ça : l'API C est aussi régulièrement cassée d'une version à l'autre rendant tous les modules externes quasiment toujours obsolètes. Un module phare a été longtemps inutilisable en Lua 5.3 : LuaSocket.
Pour ma part, j'ai fini avec ce langage :)
git is great because linus did it, mercurial is better because he didn't
Regarde avant de commenter. Je n'ai pas ouvert quoi que ce soit c'est une personne qui fournit un patch et le mainteneur qui ne veut pas l'intégrer parce que pour lui glibc est la référence et tout le monde doit s'y plier.
git is great because linus did it, mercurial is better because he didn't
Les logiciels de nos gestionnaires de paquets sont fortement couplés entre eux. Très fortement même. Si une nouvelle version d’un logiciel demande une nouvelle version d’une dépendance, en règle général, la distribution va attendre 6 mois et sa prochaine version avant de faire les mises à jour, plutôt que de risquer de casser quelque chose.
Et parfois c'est nécessaire. GNOME et KDE fournissent tous deux des bibliothèques communes à tout leur composants. Théoriquement ça veut dire que si tu utilises GNOME Maps 3.30, tu dois avoir les bases 3.30 (en réalité ça fonctionne de mixer la plupart du temps). Linux est bien plus basé sur des bibliothèques communes que Windows. Autre exemple : Gtk et Qt. Ça me ferait bien c***** de me taper ces dépendances dans chaque paquet. En plus, en ayant une unique version partagée par le système on s'assure d'une cohérence maximale. Que se passera-t-il si un des paquets qui embarque sa propre version de Qt décide de compiler sans le support de X ou Y ? Peut-être une frustration.
Si on veut distribuer un logiciel propriétaire d’ailleurs, et bien on peut faire comme ca. Un zip avec tout dedans. Et on clique sur le lancermonlogiciel.sh
Ou les :
curl http://mysuperproject.io | sudo bash
Je reviens je vais vomir.
La question est donc de savoir si l’on souhaite ou non démocratiser l’utilisation de GNU/Linux auprès du grand public.
Moi je n'y crois pas. Je n'aime pas flatpak pour la plupart des raisons que tu as citées. Pour moi ça fonctionnait déjà très bien avant et il n'y avait rien à corriger. C'est une fausse solution à un faux problème. Le vrai problème était la simplicité à installer des paquets et depuis un moment on a des interfaces graphiques conviviales qui le permettent comme anciennement GNOME Packagekit et maintenant GNOME Software, qui vous donne même des captures d'écrans.
git is great because linus did it, mercurial is better because he didn't
C'est trop facile d'exiger aux autres de faire l'effort.
Rien à voir.
Comme tu peux le voir, il y a une personne qui a envoyé plusieurs patchs et il ne l'a toujours pas inclus et a argumenté contre l'idée de musl avant en gros : pourquoi intégrer votre patch ? c'est vous qui ne voulez pas vous plier à glibc alors payez les conséquences.
Le patch est là, il y a juste à appliquer.
git is great because linus did it, mercurial is better because he didn't
Snap était là bien avant flatpak. Red Hat a fait flatpak par après et a décidé de propulser son support dans GNOME Software. Je pense que c'est tout à fait compréhensible de la part de Canonical de se sentir frustré de pas être logé à la même enseigne pour quelque chose qu'ils ont débuté avant. Je pense que c'est plutôt Red Hat qui a un syndrôme NIH. Systemd après Upstart, Flatpak après Snap. Il y a d'autres choses mais je n'ai plus toute la liste en tête.
Note : je ne défends en aucun cas Canonical, pour moi ça reste une entreprise qui « détruit » tout autant la simplicite et beauté de Linux que Red Hat.
git is great because linus did it, mercurial is better because he didn't
Je souris légèrement à ces réactions excessives du côté des développeurs chez Red Hat et GNOME. « Ah vous n'installez plus GNOME Software dans votre distribution ? Tant pis on supprime le support de snap ».
Red Hat et GNOME sont loin d'être blancs comme neige et ne jouent pas toujours franc jeu non plus. Il y a qu'à voir la plupart des réactions chez systemd qui se finissent souvent par « on fait comme ça et tant pis si vous ne suivez pas ». Autre exemple dont je suis affecté, un développeur GNOME qui pense que glibc est le standard sous Linux et ne souhaite visiblement pas supporter d'autres alternatives.
Pour faire bref : l'herbe n'est jamais plus verte ailleurs. Chaque distribution fait un peu des conneries dans son coin. Mais c'est aussi grâce à ça qu'on fait des erreurs et on arrive à trouver parfois une bonne solution. Exemple simple : les fichiers .desktop, XDG, FDO en général.
En revanche, on peut pas vraiment jeter la pierre à Canonical pour développer snap, ça a commencé avant flatpak.
git is great because linus did it, mercurial is better because he didn't
Par exemple sur un tour à commande numérique en stage de 3ème (il y a fort longtemps) j'ai réussi à déplacer la fenêtre de commande de l'écran tactile du tour devant mon tuteur. Surprise ! Un menu démarrer en bas, il s'agissait d'un Windows 95. Malheureusement une version très réduite car il y avait à peine des outils comme bloc note, calculatrice. Pas de démineur :(
Et sur les écrans de certains BUS de Strasbourg, l'interface tourne sur une version spéciale de Linux. Une fois partie en reboot permanent, j'ai vu le démarrage avec deux tux et ensuite un tty avec écrit « Lumiplan Platform » si j'ai bien vu.
git is great because linus did it, mercurial is better because he didn't
Hmm, dans ce cas bonjour le code source si on doit commencer à implémenter du code spécifique à chaque matériel pour un lecteur vidéo/audio. Bonjour les quantités de bugs introduits en plus à traiter au cas par cas.
git is great because linus did it, mercurial is better because he didn't
Concernant ce support, je me suis toujours demandé comment cela se passait côté code source. Par exemple si je prends mpv (ou totem, mplayer, peu importe). Il y a-t-il du code obligatoire et spécifique à la raspberry pi 4 pour que ces deux formats soient spécifiquement traités par le matériel ? Ou tout cela passe simplement par le driver vidéo qui gère ensuite le flux ? J'avoue manquer un peu de connaissance à ce sujet :)
git is great because linus did it, mercurial is better because he didn't
Chez moi aussi hier soir impossible d'accéder globalement à internet. Mon teléphone en 4G ne fonctionnait plus (un petit ! à côté de la barre de réseau) et pareil en wifi. C'est revenu vers 22h.
J'ai orange en internet et mobile.
git is great because linus did it, mercurial is better because he didn't
Hmm, je me demande comment tu vas déclarer tes impôts dans les années à venir. Car le site administratif français n'est pas libre et la déclaration papier ne sera bientôt plus possible.
Tu ne vas que sur des site web libres alors ?
git is great because linus did it, mercurial is better because he didn't
Il y a un truc que je n'arrive toujours pas à comprendre. Il me semble que la plupart des sites qui font du direct download sont en https. Comment HADOPI pourrait il détecter un quelconque téléchargement illégal ?
À l'heure ou quasiment tout est chiffré et que les logiciels comme eMule ont largement quitté le quotidien des personnes j'ai du mal à comprendre comment les gens peuvent ils se faire avoir avec HADOPI.
Notez que je ne supporte en aucun cas le téléchargement illégal et que j'achète systématiquement ma musique (étant audiophile, je veux de toute façon ripper en flac :)).
git is great because linus did it, mercurial is better because he didn't
D'ailleurs je ne sais plus sous quelle distribution ou système BSD il y avait un message disant que les modelines étaient risquées (en installant le paquet je crois).
git is great because linus did it, mercurial is better because he didn't
Ou l'inverse. Avoir une licence plus permissive permet aux entreprise de pouvoir utiliser quelque chose même privateur. Oui c'est mal mais tant pis. Parfois ces entreprises le rendent bien en fournissant du support, des améliorations et même simplement de la visibilité.
Rien qu'llvm, ça gagne en popularité aussi depuis qu'apple en a fait son compilateur par défaut. Incitant notamment plus de personne à y contribuer.
git is great because linus did it, mercurial is better because he didn't
ZSH est effectivement un shell riche en fonctionnalité. Mais je vois pas en quoi on peut le considérer bloat. En terme de consommation mémoire on est encore large en dessous de ce que je peux appeler un programme bloat.
Si tu me trouve un shell aussi puissant en autocomplétion (avec menu ultra convis) je suis preneur.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Keybinds de malheur
Posté par David Demelier (site web personnel) . En réponse au journal Next browser 1.3.2: réagir aux évènements avec les hooks, paquet Debian tout frais et plus encore. Évalué à 2. Dernière modification le 26 septembre 2019 à 11:22.
D'ailleurs en voyant tous ces raccourcis, on ressent que le créateur est féru d'emacs. En tant que féru de vim, j'ai peur pour mes doigts tant je n'ai pas l'habitude. Surtout quand je vois des raccourcis comme :
C-x C-c sQuelqu'un a déjà utilisé next au quotidien pour partager son avis ?
git is great because linus did it, mercurial is better because he didn't
# Passer à côté ?
Posté par David Demelier (site web personnel) . En réponse au journal Au revoir, LinuxFR. Évalué à 10.
Je ne comprends pas pourquoi tu passes tout simplement pas à côté de ces choses qui te dérangent.
Je ne lis pas tous les journaux tout simplement parce que certains ne m'intéressent pas. Comme tu le dis, quand ça part dans des débats ou totalement à côté de l'informatique : je passe tout simplement au suivant.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ça attaque sec
Posté par David Demelier (site web personnel) . En réponse au journal Microsoft ouvre sa bibliothèque standard C++. Évalué à 6. Dernière modification le 18 septembre 2019 à 10:49.
C'est ce que je suis entrain de faire. Dans l'ensemble ça fonctionne plutôt bien avec 2/3 patchs par ci par là.
Le plus gros problème sont les projets surtout initiés par RedHat qui contiennent pas mal d'extensions et pas toujours compatible. À ce jour, grub, elfutils et le noyau Linux nécessitent encore gcc.
En grande partie, le système peut tourner sans GCC (ni libgcc/gcc_s).
git is great because linus did it, mercurial is better because he didn't
# Il n'est pas un dieu
Posté par David Demelier (site web personnel) . En réponse au journal Richard Stallman, l'affaire Epstein et des positions franchement douteuses. Évalué à 4.
Parfois j'ai l'impression que beaucoup de personnes pensent que RMS est le père et le dieu gourou du libre. Ce qu'il pense, ce qu'il fait ça n'a pas d'importance. GNU n'est pas le seul projet libre sur terre.
Par ailleurs, les distributions ne dépendent plus forcément de projets GNU et donc ni Linux ni le libre doit être associé à GNU. Le terme GNU/Linux n'est plus si vrai, il y a beaucoup de distributions qui se passent des composants GNU.
En bref, ne plus faire l'amalgame de RMS/GNU == Libre. Non, loin de là. Il a écrit des licences, il a écrit emacs et GCC mais il y a pas que ça sur terre en libre. Et heureusement. Ainsi peu importe comment RMS se comporte ou agit, ça n'a aucune influence sur le libre.
git is great because linus did it, mercurial is better because he didn't
# Ce n'est pas une guerre
Posté par David Demelier (site web personnel) . En réponse au journal Le libre a perdu. Évalué à 0. Dernière modification le 30 août 2019 à 09:13.
Le libre c'est pas une guerre contre les logiciels privateurs. Personnellement je m'en fiche que des serveurs dans le monde ou que mon entourage utilise Windows, c'est leur problème pas le mien. D'ailleurs un ami à moi s'est fait pirater son serveur Windows par un ransomware, je lui ai simplement dit que s'il utilisait un système correct avec des backups ce ne serait pas arrivé. C'est en faisant des erreurs qu'on apprend.
Il y a plusieurs types de visions du libre dans ce domaine, il y a les sectaires purs et durs qui sont anti logiciels privateurs et tentent au maximum de faire changer les choses et il y a les gens comme moi qui font du libre simplement parce qu'ils aiment ça.
La vision du libre varie tellement qu'on a différentes licences. Ça se résume plus ou moins entre le permissif et le non permissif. Moi je fais du permissif parce que la seule chose qui m'intéresse c'est de fournir mon code et qu'on puisse y contribuer, voir, commenter. Si on l'utilise et qu'on me contribue en retour je suis content, si on l'utilise pour faire du privateur, tant pis c'est pas si grave. Le reste, c'est à vous en tant que consommateur de faire les bon choix. Si Apple, Microsoft ou Google ne rend pas en retour, alors n'achetez pas leur produit. Aussi simple que ça.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Firefox, mode lecture
Posté par David Demelier (site web personnel) . En réponse au journal [ma vie] Parfois, il est préférable de ne rien faire. Évalué à 3.
Je viens de tester c'est pas génial avec les polices monospaces. Par exemple la table des matière alignées avec des …… pour les numéros de pages sont complètement illisibles avec le mode lecture.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: pas le boulot du lecteur audio
Posté par David Demelier (site web personnel) . En réponse au journal Écouter de la musique sous Plasma. Évalué à 1.
Oh le naïf. Penses-tu vraiment que c'est aussi simple que ça ? Rien que la bibliothèque alsa nécessite plusieurs appels de fonctions pour juste récupérer le volume courant. Alors imagine quand il s'agit de transmettre du son. En plus il existe plusieurs bibliothèques, mais à vrai dire le son sous Linux a toujours et malheureusement été un bordel monstre.
Je ne sais pas pour pulseaudio, en tout cas NAS était prévu pour ça mais il est largement tombé en désuétude. Je l'ai un peu essayé par le passé mais c'était loin d'être parfait.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: pas le boulot du lecteur audio
Posté par David Demelier (site web personnel) . En réponse au journal Écouter de la musique sous Plasma. Évalué à 10. Dernière modification le 19 juillet 2019 à 09:14.
Exactement, c'est au serveur de son de faire le travail. D'autant plus que si on utilise plusieurs applications audio, on a pas envie de se prendre la tête à rediriger chacune d'entre elle via les options / configuration / interfaces graphique de celles ci.
Sinon on implémente la même fonctionnalité 1000 fois dans toutes les applications qui font de l'audio et on a donc 1000 fois une implémentation avec possibles bugs à résoudre et maintenir.
En bref à chacun sa responsabilité :
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Lua ?
Posté par David Demelier (site web personnel) . En réponse au journal Bellard strikes again: QuickJs, un moteur JavaScript. Évalué à 10.
LuaJIT oui, Lua pur non.
C'est un langage simple mais pas spécialement agréable à utiliser pour l'avoir mis dans mes applications. Comparé au Javascript moderne :
continuemaisbreaketgotoexistent ;~=;Et à côté de ça : l'API C est aussi régulièrement cassée d'une version à l'autre rendant tous les modules externes quasiment toujours obsolètes. Un module phare a été longtemps inutilisable en Lua 5.3 : LuaSocket.
Pour ma part, j'ai fini avec ce langage :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: « Guerres »
Posté par David Demelier (site web personnel) . En réponse au journal Canonical refait cavalier seul et annonce une nouvelle boutique logicielle centrée sur Snap. Évalué à 3.
Regarde avant de commenter. Je n'ai pas ouvert quoi que ce soit c'est une personne qui fournit un patch et le mainteneur qui ne veut pas l'intégrer parce que pour lui glibc est la référence et tout le monde doit s'y plier.
git is great because linus did it, mercurial is better because he didn't
# Sans moi
Posté par David Demelier (site web personnel) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 1. Dernière modification le 14 juillet 2019 à 08:02.
Et parfois c'est nécessaire. GNOME et KDE fournissent tous deux des bibliothèques communes à tout leur composants. Théoriquement ça veut dire que si tu utilises GNOME Maps 3.30, tu dois avoir les bases 3.30 (en réalité ça fonctionne de mixer la plupart du temps). Linux est bien plus basé sur des bibliothèques communes que Windows. Autre exemple : Gtk et Qt. Ça me ferait bien c***** de me taper ces dépendances dans chaque paquet. En plus, en ayant une unique version partagée par le système on s'assure d'une cohérence maximale. Que se passera-t-il si un des paquets qui embarque sa propre version de Qt décide de compiler sans le support de X ou Y ? Peut-être une frustration.
Ou les :
Je reviens je vais vomir.
Moi je n'y crois pas. Je n'aime pas flatpak pour la plupart des raisons que tu as citées. Pour moi ça fonctionnait déjà très bien avant et il n'y avait rien à corriger. C'est une fausse solution à un faux problème. Le vrai problème était la simplicité à installer des paquets et depuis un moment on a des interfaces graphiques conviviales qui le permettent comme anciennement GNOME Packagekit et maintenant GNOME Software, qui vous donne même des captures d'écrans.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: « Guerres »
Posté par David Demelier (site web personnel) . En réponse au journal Canonical refait cavalier seul et annonce une nouvelle boutique logicielle centrée sur Snap. Évalué à 4.
Rien à voir.
Comme tu peux le voir, il y a une personne qui a envoyé plusieurs patchs et il ne l'a toujours pas inclus et a argumenté contre l'idée de musl avant en gros : pourquoi intégrer votre patch ? c'est vous qui ne voulez pas vous plier à glibc alors payez les conséquences.
Le patch est là, il y a juste à appliquer.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Toujours le même
Posté par David Demelier (site web personnel) . En réponse au journal Canonical refait cavalier seul et annonce une nouvelle boutique logicielle centrée sur Snap. Évalué à 4.
Snap était là bien avant flatpak. Red Hat a fait flatpak par après et a décidé de propulser son support dans GNOME Software. Je pense que c'est tout à fait compréhensible de la part de Canonical de se sentir frustré de pas être logé à la même enseigne pour quelque chose qu'ils ont débuté avant. Je pense que c'est plutôt Red Hat qui a un syndrôme NIH. Systemd après Upstart, Flatpak après Snap. Il y a d'autres choses mais je n'ai plus toute la liste en tête.
Note : je ne défends en aucun cas Canonical, pour moi ça reste une entreprise qui « détruit » tout autant la simplicite et beauté de Linux que Red Hat.
git is great because linus did it, mercurial is better because he didn't
# « Guerres »
Posté par David Demelier (site web personnel) . En réponse au journal Canonical refait cavalier seul et annonce une nouvelle boutique logicielle centrée sur Snap. Évalué à 2. Dernière modification le 12 juillet 2019 à 09:09.
Je souris légèrement à ces réactions excessives du côté des développeurs chez Red Hat et GNOME. « Ah vous n'installez plus GNOME Software dans votre distribution ? Tant pis on supprime le support de snap ».
Red Hat et GNOME sont loin d'être blancs comme neige et ne jouent pas toujours franc jeu non plus. Il y a qu'à voir la plupart des réactions chez systemd qui se finissent souvent par « on fait comme ça et tant pis si vous ne suivez pas ». Autre exemple dont je suis affecté, un développeur GNOME qui pense que glibc est le standard sous Linux et ne souhaite visiblement pas supporter d'autres alternatives.
Pour faire bref : l'herbe n'est jamais plus verte ailleurs. Chaque distribution fait un peu des conneries dans son coin. Mais c'est aussi grâce à ça qu'on fait des erreurs et on arrive à trouver parfois une bonne solution. Exemple simple : les fichiers .desktop, XDG, FDO en général.
En revanche, on peut pas vraiment jeter la pierre à Canonical pour développer snap, ça a commencé avant flatpak.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: On veut plus !
Posté par David Demelier (site web personnel) . En réponse au journal Windows dans les copieurs. Évalué à 8. Dernière modification le 05 juillet 2019 à 08:41.
Parfois pas grand chose.
Par exemple sur un tour à commande numérique en stage de 3ème (il y a fort longtemps) j'ai réussi à déplacer la fenêtre de commande de l'écran tactile du tour devant mon tuteur. Surprise ! Un menu démarrer en bas, il s'agissait d'un Windows 95. Malheureusement une version très réduite car il y avait à peine des outils comme bloc note, calculatrice. Pas de démineur :(
Et sur les écrans de certains BUS de Strasbourg, l'interface tourne sur une version spéciale de Linux. Une fois partie en reboot permanent, j'ai vu le démarrage avec deux tux et ensuite un tty avec écrit « Lumiplan Platform » si j'ai bien vu.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: H264, H265
Posté par David Demelier (site web personnel) . En réponse au journal Arrivée du Raspberry Pi 4. Évalué à 1.
Et comment pouvons nous être sûr que le lecteur multimédia utilise bien la version accélérée et ne fait chauffer le CPU ?
Enfin, je suppose RTFM le lecteur multimédia que j'utilise.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: H264, H265
Posté par David Demelier (site web personnel) . En réponse au journal Arrivée du Raspberry Pi 4. Évalué à 2.
Hmm, dans ce cas bonjour le code source si on doit commencer à implémenter du code spécifique à chaque matériel pour un lecteur vidéo/audio. Bonjour les quantités de bugs introduits en plus à traiter au cas par cas.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: H264, H265
Posté par David Demelier (site web personnel) . En réponse au journal Arrivée du Raspberry Pi 4. Évalué à 1.
Concernant ce support, je me suis toujours demandé comment cela se passait côté code source. Par exemple si je prends mpv (ou totem, mplayer, peu importe). Il y a-t-il du code obligatoire et spécifique à la raspberry pi 4 pour que ces deux formats soient spécifiquement traités par le matériel ? Ou tout cela passe simplement par le driver vidéo qui gère ensuite le flux ? J'avoue manquer un peu de connaissance à ce sujet :)
git is great because linus did it, mercurial is better because he didn't
# Down un peu hier soir
Posté par David Demelier (site web personnel) . En réponse au journal Orange http(s) KO. Évalué à 1. Dernière modification le 20 juin 2019 à 09:06.
Chez moi aussi hier soir impossible d'accéder globalement à internet. Mon teléphone en 4G ne fonctionnait plus (un petit ! à côté de la barre de réseau) et pareil en wifi. C'est revenu vers 22h.
J'ai orange en internet et mobile.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Erreur de casting
Posté par David Demelier (site web personnel) . En réponse au journal Militantisme : parler d'un sujet pour convaincre. Évalué à 4. Dernière modification le 18 juin 2019 à 15:04.
Hmm, je me demande comment tu vas déclarer tes impôts dans les années à venir. Car le site administratif français n'est pas libre et la déclaration papier ne sera bientôt plus possible.
Tu ne vas que sur des site web libres alors ?
git is great because linus did it, mercurial is better because he didn't
# Hadopi, se faire avoir wn 2019 ?
Posté par David Demelier (site web personnel) . En réponse au journal Les 10 ans d'Hadopi. Évalué à 2.
Il y a un truc que je n'arrive toujours pas à comprendre. Il me semble que la plupart des sites qui font du direct download sont en https. Comment HADOPI pourrait il détecter un quelconque téléchargement illégal ?
À l'heure ou quasiment tout est chiffré et que les logiciels comme eMule ont largement quitté le quotidien des personnes j'ai du mal à comprendre comment les gens peuvent ils se faire avoir avec HADOPI.
Notez que je ne supporte en aucun cas le téléchargement illégal et que j'achète systématiquement ma musique (étant audiophile, je veux de toute façon ripper en flac :)).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Rien de nouveau
Posté par David Demelier (site web personnel) . En réponse au journal [FAILLE] Code execution dans Vim via un fichier malicieux forgé. Évalué à 4. Dernière modification le 11 juin 2019 à 17:48.
J'allais le dire.
D'ailleurs je ne sais plus sous quelle distribution ou système BSD il y avait un message disant que les modelines étaient risquées (en installant le paquet je crois).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Random crappish website
Posté par David Demelier (site web personnel) . En réponse au journal journalistes -> ça m'énerve.... Évalué à 10.
Bah moi déjà je vois « digital » je sais que le site n'est pas crédible :}
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Une autre façon de voir ça
Posté par David Demelier (site web personnel) . En réponse au journal zsh remplace bash comme shell par défaut sous macOS. Évalué à 2. Dernière modification le 07 juin 2019 à 10:36.
Ou l'inverse. Avoir une licence plus permissive permet aux entreprise de pouvoir utiliser quelque chose même privateur. Oui c'est mal mais tant pis. Parfois ces entreprises le rendent bien en fournissant du support, des améliorations et même simplement de la visibilité.
Rien qu'llvm, ça gagne en popularité aussi depuis qu'apple en a fait son compilateur par défaut. Incitant notamment plus de personne à y contribuer.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: mais si tu savais comme on s'en fout
Posté par David Demelier (site web personnel) . En réponse au journal zsh remplace bash comme shell par défaut sous macOS. Évalué à 6.
ZSH est effectivement un shell riche en fonctionnalité. Mais je vois pas en quoi on peut le considérer bloat. En terme de consommation mémoire on est encore large en dessous de ce que je peux appeler un programme bloat.
Si tu me trouve un shell aussi puissant en autocomplétion (avec menu ultra convis) je suis preneur.
git is great because linus did it, mercurial is better because he didn't