David Demelier a écrit 753 commentaires

J'ai eu toutes les nintendo occidentales. La NES, la snes, le superscope, tout ce qui a suivi. Tout. Et en passant à l'âge adulte j'ai tout vendu comme un abruti.

Bon dans tous les cas je me souviens que ma NES n'était pas dans ses meilleurs jours à la fin et même si c'est considéré comme inefficace (on l'a tous fait ne me regardez pas comme ça) il était fréquent que je souffle dans la cartouche où la réinsère à plusieurs reprises pour que la console démarre. C'est bien sa fragilité la plus connue.

Du coup je me demande si ce jeu innovant va pouvoir trouver sa place auprès de joueurs car les NES pleinement fonctionnelles restent des objets assez rare ces dernières années.

git is great because linus did it, mercurial is better because he didn't

Et du coup, ça me pose des questions coté sécu car n'importe qui peut ce connecter dessus via le Bluetooth (changer la conf ou autre)

Non je pense que c'est au premier appairage comme la plupart des périphériques bluetooth. Après il faut sans doute faire une manipulation côté imprimante pour autoriser une nouvelle connexion par exemple.

git is great because linus did it, mercurial is better because he didn't

J'imprime au travail. Problème résolu.

Plus longue histoire, j'ai une imprimante HP pas très chère car j'avais déjà une HP auparavant et je me souviens que ça marchait partout grâce à HPLIP. Cette imprimante avait bien une dizaine d'années et n'était plus réparable alors j'ai acheté une nouvelle HP pour pas grand chose. Elle se connecte aussi en réseau via le wifi mais contrairement à l'autre pas d'écran tactile pour la configurer. J'ai du la brancher à mon mac pour qu'il lui transfère les informations du wifi. Je ne sais pas comment ça fonctionne et j'avoue que ça c'était plutôt magique. Je meurs d'envie de savoir si une telle fonctionnalité existe depuis les paramètres de GNOME ou l'interface web de CUPS.

N'imprimant que très peu, j'ai voulu l'autre jour faire une photocopie exceptionnelle et là ce fut le drame : seulement le violet est sorti sur la feuille. Je regarde le niveau des cartouches : 75%. J'exaspère, les cartouches ont visiblement séché.

Maintenant, j'imprime mes 3 documents par an au travail et j'utilise mon imprimante que pour scanner…

git is great because linus did it, mercurial is better because he didn't

J'ai quand même plusieurs incompréhensions, j'ai normalement souscrit auprès de ma banque (la Caisse d'Épargne) à une option qui active la double authentification pour tout achat fait avec une CB, je dois sur mon téléphone ouvrir l'application de la banque, rentrer mon code secret, et valider l'achat. Je n'ai pas reçu de notification pour ces 2 transactions.

Les paiements via 3dsecure ne sont pas obligatoires (malheureusement). C'est propre au marchands et beaucoup ne le font pas pour leur raisons :

• Ça bloque certains acheteurs qui aiment pas ça.
• Ça coute de l'argent.

J'ai plusieurs sites où malheureusement je continue de payer sans aucune authentification de ma part.

J'ai aussi eu des paiements frauduleux en 2018 mais c'est ma banque qui m'a avertit directement en m'appelant. Un paiement d'environ 70€ sur un site de robes… choses que j'achète assez peu. Je remercie ma banque d'avoir pris cette précaution et d'avoir remarqué je ne sais par quelle manière ce paiement car en plus de ça j'étais en vacances alors je ne regardais pas spécialement mon compte tous les jours.

À ce jour, je n'ai aucun moyen de savoir comment cela a pu arriver.

git is great because linus did it, mercurial is better because he didn't

Il faut arrêter de lister "écrit en $X" comme une fonctionnalité. "$X" ne rendra jamais un projet intrinsèquement meilleur.

Je suis pas d'accord. J'utilise plantuml au travail pour nos diagramme (non, faire ça en graphviz pur serait du pur masochisme) et je t'assure que ça m'embête bien d'avoir une dépendance à OpenJDK juste pour faire des diagrammes pendant la compilation de la documentation.

git is great because linus did it, mercurial is better because he didn't

• AltGr-WEur qui revient souvent comme alternative sur LinuxFr : il y a aussi bien les accents en AltGr que les touches mortes

Mais il est super chouette cet agencement. Surtout pour les accents graves qui étaient pénibles avec le altgr-intl. Je m'en vais tester ça pour la journée, merci !

git is great because linus did it, mercurial is better because he didn't

Exact, c'est fonctionnel sous macOS et Windows. Quoi qu'il en soit c'est pas spécialement ergonomique (sous un clavier mac ça va encore car ctrl et alt (option) sont cote à cote alors ça peut s'appuyer avec juste le pouce).

git is great because linus did it, mercurial is better because he didn't

En pas portable (Linux only) tu peux simplement lire /proc/self/exe. En très portable c'est plutôt compliqué mais il existe des modules sympathiques comme whereami

git is great because linus did it, mercurial is better because he didn't

Supposons que le programme ait besoin d'ouvrir un fichier data.txt situé dans le même répertoire que l'exécutable. Le plus simple est d'écrire :

Là où est l'exécutable et le répertoire courant sont deux choses différentes.

git is great because linus did it, mercurial is better because he didn't

Premièrement, les distributions sont plus forcément basées sur GNU alors le terme GNU/Linux est obsolète depuis pas mal d'années.

Deuxièmement, bien que je sois assez d'accord avec toi ça reste une bonne opportunité pour lancer des applications Linux spécifique sur Windows. Sinon, on arrête aussi le développement de Wine ?

Je développe des applications spécifiques aux unices libres car je pense que POSIX devrait être supporté par tous. Mais j'avoue avoir été content de pouvoir lancer une de nos applications à mon travail car le malheureux logiciel de gestion de notre imprimante RFID ne fonctionne que sous Windows, au moins j'ai eu aucun effort de portabilité à faire.

git is great because linus did it, mercurial is better because he didn't

Tout ce que je déteste. Les devs upstream qui tentent d'essayer d'être intelligent selon le système cible en testant des fichiers aléatoires comme /etc/debian_version, uname etc mais qui va foirer dès qu'on quitte les distributions populaires.

De plus, j'aime pas trop lancer un script sans savoir ce qu'il va faire. Va t-il polluer mon ~/. ou au contraire appeler sudo/doas pour installer des paquets à ma place ?

Au bucher tous ces curl | sh (et curl de binaires préconstruits aussi).

git is great because linus did it, mercurial is better because he didn't

Surtout que POSIX demande qu'un système conforme ai un compilateur C99 qui a lui aussi 24 ans.

Pour ma part c'est le minimum que je demande, les systèmes qui n'ont pas C99 je ne les accepte pas et c'est tant pis (de plus MSVC supporte plutôt bien C99 maintenant). Ne pas avoir C99 c'est une pelleté de fonctionnalités en moins :

• designated initializers
• snprintf
• long long
• inline
• nombres complexes

git is great because linus did it, mercurial is better because he didn't

Parce que ça n'apporte rien à partir du moment où une variable est bien nommée. Si un jour tu écris mapPlayers car ton type de données est une map. Ok. Tu commences à la référencer à plein d'endroits et le jour où tu changes de type tu dois renommer la variable à plein d'endroits. Oui on peut faire un rechercher remplacer mais ça reste une opération inutile d'autant plus que tu introduis des possibles merge-conflicts.

Si je lis une variable delay je me doute que ce sera probablement un nombre. Si je lis clients je me doute que ce sera probablement une collection de clients.

git is great because linus did it, mercurial is better because he didn't

Notamment le point 9.4 et 9.5. Les FAM peuvent être risqués mais les union sont particulièrement pratiques, les interdire complètement est un peu rigide.

L'annexe E est extrêmement subjective.

• Une fonction de 500 lignes c'est beaucoup trop et j'en ai rarement vu dans des projets propres.
• E4.5, non, on ne doit pas faire des types maison en _t. C'est réservé par POSIX.
• E4.7, pitié la notation hongroise doit disparaitre.

git is great because linus did it, mercurial is better because he didn't

Le rapport avec les logiciels libres ?

git is great because linus did it, mercurial is better because he didn't

Je… comprends pas trop l'intérêt. Est-ce qu'un linker a vraiment besoin d'être développé sur un temps complet ? Ça reste un outil assez anecdotique.

Si encore le développeur était entrain de travailler sur un moteur de jeu, un environnement de bureau ou autre, je comprendrais la demande de financement.

Mais bon, c'est à la mode pour les bibliothèques simples.

git is great because linus did it, mercurial is better because he didn't

Ce qui me choque le plus c'est sur mobile, la vidéo qui s'ouvre directement sans ton accord et prend 1/3 de l'écran en étant fixé relativement ainsi même en scrollant ça reste toujours en haut de ton écran.

Ensuite, tu as 3 à 4 suggestion d'autres articles entre chaque paragraphe. À quel moment ça devient lisible ?

git is great because linus did it, mercurial is better because he didn't

La question, c'est plutôt l'avancement de la transition vers libadwaita qui crée un écosystème particulièrement hétérogène avec les applications Gtk 3/4.

git is great because linus did it, mercurial is better because he didn't

Les smart pointers de C++ semblent plus proches de ce dernier cas ?

Je ne peux pas comparer car je connais pas assez Rust.

Les smart pointers permettent surtout :

• std::unique_ptr permet de bien marquer l'ownership d'un pointeur. Cet objet n'est pas copiable mais uniquement déplaçable. De ce fait il est impossible de faire un double-free quand on l'utilise. C'est le smart pointer le plus simple, quand il est détruit il détruit l'objet sous jacent s'il est présent
• std::shared_ptr permet d'avoir une donnée avec un reference-count. Tant qu'un shared_ptr existe et est copié plusieurs fois, le pointeur n'est pas supprimé. C'est le moyen le plus sûr de partager un pointeur à travers plusieurs parties du code. Néanmoins son utilisation doit rester occasionnelle car elle indique souvent un problème de conception.

git is great because linus did it, mercurial is better because he didn't

Autrement dit des perfs en moins.

Ça n'a absolument aucun sens ce que tu dis. Dans tous les cas la mémoire que tu as allouée doit être désallouée. Les smart pointeurs permettent simplement de s'affranchir de faire des memory leak parce qu'on a oublié de le faire à un fil d'exécution du code. D'ailleurs un std::unique_ptr compilé avec les optimisations au max génère le même code assembleur.

Les smarts pointers permettent surtout d'éviter ce genre de problèmes avant qu'ils existent.

Foo *instance = get_my_instance_driver();

// Okay...
if (something_has_failed) {
    log("it failed");
    delete instance;
    return false;
}

do_something_that_may_throw_an_exception();
// Oups, si cette fonction a levé une exception j'ai un bon gros leak des familles.

return true;

git is great because linus did it, mercurial is better because he didn't

Challenge accepted!

~ $ file /bin/* /usr/bin/* /sbin/* /usr/sbin/* | grep -ic perl
15
~ $ file /bin/* /usr/bin/* /sbin/* /usr/sbin/* | grep -i perl 
/usr/bin/callgrind_annotate:                   Perl script text executable
/usr/bin/callgrind_control:                    Perl script text executable
/usr/bin/cg_annotate:                          Perl script text executable
/usr/bin/cg_diff:                              Perl script text executable
/usr/bin/cloc:                                 Perl script text executable
/usr/bin/ms_print:                             Perl script text executable
/usr/bin/perl:                                 ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, stripped
/usr/bin/perl5.34.1:                           ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, stripped
/usr/bin/perldoc:                              Perl script text executable
/usr/bin/pod2html:                             Perl script text executable
/usr/bin/pod2man:                              Perl script text executable
/usr/bin/pod2text:                             Perl script text executable
/usr/bin/pod2usage:                            Perl script text executable
/usr/bin/podchecker:                           Perl script text executable
/usr/bin/streamzip:                            Perl script text executable

Par contre tous les pod* ne comptent pas puisqu'ils viennent depuis perl directement. Donc en realité sur ma machine il n'y a que cloc, valgrind et git-send-email qui sont codés en perl visiblement.

~ $ apk info -r perl
perl-5.34.1-r0 is required by:
perl-sub-quote-2.006006-r1
perl-error-0.17029-r1
cloc-1.92-r0
perl-role-tiny-2.002004-r1
perl-regexp-common-2017060201-r2
perl-class-method-modifiers-2.13-r2
perl-algorithm-diff-1.201-r0
git-perl-2.36.1-r0
perl-moo-2.005004-r1
perl-parallel-forkmanager-2.02-r3

git is great because linus did it, mercurial is better because he didn't

Ne prenez pas mon titre comme une provocation, c'est une question légitime. Je ne connais pas beaucoup d'outils codés en Perl encore actuellement. Sur ma machine, perl est installé pour cloc et irssi.

Qui utilise encore Perl par choix et pour quoi, quel domaine ?

git is great because linus did it, mercurial is better because he didn't

On a l'impression que d'aucuns se sentent insultés parce que l'OS propriétaire qu'ils utilisent n'est pas supporté.

Aucun rapport. Je n'utilise pas Windows et je n'ai pas de Windows chez moi, pour autant j'ai pas envie de limiter mes projets à des OS libres. Si mon projet fonctionne aussi sur Windows c'est tant mieux car ça fait une audience supplémentaire.

Pour ma part, je critique simplement le point que le projet affirme directement « Les OS non libres ne seront pas supportés » et même si je fais que de l'opensource développé sous de l'opensource, je ne veux pas me limiter à ça.

Si on veut pousser le vice encore plus loin on fait une nouvelle version d'une licence pro-opensource qui dit « attention ce logiciel n'a pas le droit de tourner sur un système non libre » ? Ça n'a aucun sens et c'est simplement un doigt levé des opinions imbue de Drew.

git is great because linus did it, mercurial is better because he didn't

Quand j'écris un programme, je n'ai aucune envie de m'assurer qu'il puisse être compilé sur un OS privateur.

C'est ton avis mais affirmer noir sur blanc “ne sera pas supporté” pour moi c'est pas juste une non-envie de s'en occuper mais un doigt levé à quiconque le demande ou souhaite fournir le support pour.

Beaucoup de gens ne fournissent pas le support pour X ou Y système parce qu'ils n'ont ni les compétences, ni le matériel pour mais de là fermer la porte immédiatement c'est à mon sens inconcevable pour un langage.

Avant je n'avais pas de mac et pour autant j'ai jamais dit sur un quelconque de mes projets « il ne sera jamais disponible pour macOS ». Un jour une personne m'a aidé à porter mon programme pour et j'étais ravi qu'il ai pu m'aider à le faire.

git is great because linus did it, mercurial is better because he didn't

Avec une affirmation aussi - propre à son opinion habituelle -, j'ai du mal à y croire.

“Hare does not, and will not, support any proprietary operating systems.”

Je vois mal des gens faire un portage downstream qui soit pas officialisé.

git is great because linus did it, mercurial is better because he didn't