Si vous ne vous y connaissez pas en réseau, ces adresses étaient jusqu'à présent réservée pour une utilisation locale sur une machine. La plus connue étant 127.0.0.1, mais c'est possible d'en utiliser d'autres.
Si cette proposition est adoptée, les adresses à partir de 127.1.0.0 jusqu'a 127.1.255.255 deviendront des adresses tout à fait normales, routables sur internet.
Il y avait déjà eu des problèmes lors d'opérations similaires avec les adresses 1.x.x.x et 128.x.x.x (liens donnés en références dans le draft), qui étaient simplement réservées (sans utilisation définie) avant d'être finalement attribuées. Leur mise en service a nécessité de contacter des opérateurs télécoms ayant une configuration incorrecte, de mettre à jour des routeurs, ou encore de déployer un firmware mis à jour sur des modems ADSL qui utilisaient ces adresses en interne. Elles recevaient aussi du traffic de client HTTP mal programmés, et plein d'autres choses non identifiées.
Cela consiste principalement en fichiers pour l'impression 3D du boîtier. La borne fonctionne sous Android avec une Tinker Board ASUS. Pas de détails sur l'écran et la webcam utilisés, dans quelle mesure d'autres écrans seront-ils compatibles sans devoir modifier l'impression 3D?
La documentation explique aussi que l'application ne peut pas être mise à jour via le play store car la borne n'est pas associée à un compte Google. Elle n'est pas disponible sur F-Droid?
Guarín-Zapata was taught computer basics in high school — how to save, how to use file folders, how to navigate the terminal — which is knowledge many of his current students are coming in without.
Oui ben voilà: les gens qui ont eu une formation en informatique pendant leurs études ont appris ce que c'est qu'un dossier et comment ça s'utilise. Et puis à un moment quelqu'un s'est dit que ces cours ne servaient plus à rien et que les nouveaux étudiants allaient connaître ça instinctivement. Et c'était une erreur. Google n'a rien à voir là dedans, non?
Personnellement j'ai eu quelques cours d'informatique au collège (fichiers, dossiers, traitement de texte, etc). Sans quoi je n'aurai probablement pas vraiment compris tout seul comment ça marchait (bien que ayant déjà utilisé des ordinateurs avant ça). Et plus tard quand je suis arrivé en IUT informatique, une séance de travaux pratiques là dessus pour vérifier que si tout le monde était au point ou si des cours sur le sujet étaient nécessaires.
Il y a plusieurs choses qui devraient normalement être listées pour chaque bouton:
Un descripteur physique qui indique quelle moitié du corps (gauche, droite, les deux à la fois, ou n'importe laquelle) et quelle partie (il y a une énumération comprenant tous les doigts, orteils, yeux, oreilles, genoux, etc) doit être utilisée pour activer le bouton, ainsi qu'un "effort" (0 pour le bouton placé juste en dessous du doigt, puis ça augmente pour les boutons moins faciles à atteindre)
Un "usage" qui indique à quoi sert le bouton. Il y a des usages spécifiques pour "select" et "start" et une distinction entre "bouton" (activé avec le pouce) et "gachette" (activée avc l'index). Mais il y a aussi une longue liste d'usages plus spécifiques: différents types de clubs de golf, les contrôles pour piloter un char d'assaut, et plein d'autres
Enfin, si un bouton est identifiable par un symbole (A, B, X, Y ou autre, on a droit à tout Unicode) sur le contrôleur, il devrait y avoir un descripteur contenant la chaîne de caractères correspondante.
Malheureusement, la plupart des gamepads font plutôt quelque chose du genre "voici 15 boutons dans un ordre aléatoire" sans donner plus de détails.
La liste des "usages" possibles: https://usb.org/sites/default/files/hut1_22.pdf (mises à jour régulièrement, on peut voir sur le site usb.org la liste des nouveaux usages en cours de discussion, c'est tout aussi divertissant que la liste des emojis dans Unicode)
Le seul truc que je n'ai pas trouvé, c'est comment décrire la couleur des boutons. Ce qui est dommage parce que mon gamepad Gravis a juste des couleurs pour différencier les boutons, et pas de texte ou de symboles.
Je vais probablement réutiliser ces informations dans Haiku également. Par contre je trouve la liste de boutons disponibles dans SDL2 un peu limitée: http://wiki.libsdl.org/SDL_GameControllerButton (pas de bouton SELECT par exemple?)
C'est difficile de faire ça bien parce que la plupart des contrôleurs ne fournissent pas d'infos sur la position physique des boutons (alors que c'est possible dans l'USB HID). Donc il faut renseigner à la main ce genre de fichier pour avoir les infos nécessaires.
Dans les 3 premiers cas, on retrouve à peu près toujours les mêmes en tête de classement. La question c'est plutôt pourquoi Javascript est à ce point sous-évalué par TIOBE?
En effet. J'ai trouvé un benchmark qui conclut que ça marche plutôt bien, 3 fois plus rapide que l'implémentation qui teste les octets un par un: https://gist.github.com/nico/2624336
Gcc fait des optimisations auxquelles on ne s'attend pas forcément. Quelques cas auxquels je pense:
Il optimise printf("chaine\n") en puts("chaine")
Dans Haiku, dans notre libc on teste dans nos fonctions de manipulations de chaîne (strcpy, strlen, …) si un pointeur null est passé en paramètre. Dans le standard C, l'appel de ces fonctions avec un paramètre null est un comportement indéfini. Gcc optimise notre implémentation en enlevant le test qu'on avait ajouté. Il peut aussi décider de ne pas du tout appeler la fonction et d'utiliser sa propre implémentation.
Les compilateurs font usage de tout ce qui est dit dans la spécification, et la spécification est architecturée pour ça. Par exemple la spécification du C décrit un mode "hosted" et un mode "freestanding", dans le deuxième, la plupart des fonctions de la librairie standard ne sont plus définies. Ce qui permet au compilateur de savoir qu'il doit désactiver les optimisations correspondantes.
L'idée qu'on se fait d'une architecture bien découpée en couches indépendantes ne tient en fait pas la route quand on regarde les détails d'implémentation.
Celui-ci ajoute d'autres implémentations: la fonction memchr en C est équivamente, et il y a différentes implémentations dans différentes biblothèque C. Certaines plus lentes et certaines plus rapides que l'implemenation "naive" avec une simple boucle.
Cela a donné lieu à une discussion sur la mailing list du musl: https://www.openwall.com/lists/musl/2016/09/18/3 avec des liens supplémentaires vers d'autres cas ou des libraries C proposent une implémentation "optimisée" qui est en fait plus lente que l'implémentation triviale en C. D'ou la conclusion: on peut faire confiance au compilateur pour optimiser le code simple et lisible de façon pas trop mauvaise. Même si le compilateur n'est pas parfait et que les fonctions de la glibc sont très génériques, et souvent on peut écrire du code plus efficace, ce n'est pas la peine d'essayer de le faire systématiquement.
Je ne vois pas comment on peut tester l'égalité de chaque moitié d'un registre 64bit séparément avec une seule instruction de comparaison non vectorisée.
Au mieux on peut faire un XOR bit à bit, et ensuite il faut regarder si les 32 premiers ou les 32 derniers bits sont tous à 0. Ce qui fait toujours 2 comparaisons.
Ma dernière utilisation de Mac OS X remonte à quelques années mais on voyait bien que c'était une tentative de réunifié l'interface de NeXT avec celle de Mac OS 9 et que la mayonnaise n'a pas vraiment pris.
La cohérence, c'est plein de petits détails. Le fait que le bouton "ok" dans les boîtes de dialogues soit à droite ou à gauche. Que le menu "préférences" soit rangé dans "édition" ou plutôt dans "fenêtre". Ces deux exemples sont pris dans Firefox 2, ou ce genre de chose étaient différentes entre les versions Linux et Windows pour s'adapter aux conventions de chaque système.
D'un point de vue de l'apparence, c'est le fait de pouvoir choisir la bolice de caractère et sa taille une seule fois, et que ce choix soit appliqué par toutes les applications. Qu'elles se comportent toutes de la même façon quand on déplace une fenêtre entre deux écrans de résolution différente, et qu'on ait pas certaines applications qui se grossissent automatiquement, et d'autres pas.
C'est avoir des raccourcis claviers standardisés (mais ça, ça marche à peu près bien sous Linux et Windows). Des options en ligne de commande qui marchent toujours pareil (pas comme dd, ou sous Windows c'est pire avec la moitié des programmes qui veulent des options commençant par / et l'autre moitié par -)
Ça va bien au-delà de la couleur et de la police de caractère choisies pour l'affichage, donc. Et la comparaison avec la ligne de commande va plus loin: de la même façon que on peut combiner grep, sed, awk, etc… pour faire un script shell, il serait intéressant de pouvoir combiner des applications graphiques. Dans Haiku, on ne prévoit pas d'avoir un IDE tout-en-un. On prévoit d'avoir un outil de gestion de projet (un genre de frontend graphique pour make ou cmake), qui va communiquer avec un éditeur de texte pour lui dire quel fichier ouvrir, quelle ligne de code afficher dedans, etc. Le protocole entre les deux est documenté et chaque partie peut être remplacée.
C'est possible, mais les développeurs de Blink et Chromium sont franchement hostiles à ce genre de choses. Par exemple ils refusent d'inclure les patches pour le support de FreeBSD ou OpenBSD, qui sont donc maintenus dans un fork.
Et tout ça pour avoir des applications consommant des gigaoctets de mémoire et avec une interface ne s'intégrant pas proprement avec le reste du système.
Personellement, ça ne m'intéresse pas de passer du temps à faire ça. Mais je ne doute pas que d'autres développeurs s'y mettront un jour ou l'autre.
Sur mon téléphone j'utilise le clavier MessagEase (pas libre, j'attends toujours que quelqu'un se décide à en faire une copie libre…). C'est un clavier conçu pour les écrans tactiles (il a fait ses débuts sur certains PDA avant d'arriver sur les téléphones)
D'ailleurs je me souviens de l'époque ou j'utilisais un PDA et il me semble qu'il y avait un peu plus de tentatives pour des méthodes de saisie plus adaptées. Alors qu'aujourdhui on se traîne encore des claviers de machines à écrire conçus il y a 2 siècles avec des contraintes complètement différentes…
Je ne sais pas ce qui me déconcerte le plus là dedans: le buzzword bingo gagnant à chaque paragraphe, le fait cue l'entreprise soit domiciliée dans une péniche, ou le nom de la péniche qui est unjeu de mot digne des meilleurs salons de coiffure?
Je n'ai pas réglé ce bug dans Linux, X11, etc parce queje suis occupé à écrire un système d'exploitation ou il n'y a pasce genre de bugs. D'autres questions?
On a quelques gens pas contents qui sont partis du projet à différentes étapes. Ou qui sont toujours plus ou moins là mais qui continuent à râler sur certains trucs.
Je pense par exemple à la décision d'utiliser C++ dans le noyau, au gestionnaire de paquets et à la façon dont il fonctionne qui rend certains dossiers accessibles seulement en lecture, et à la décision de conserver la compatibilité avec BeOS et donc de pouvoir compiler une grande partie du code avec gcc2. Et sûrement plein d'autres raisons. Mais pour l'instant, ça n'a jamais encore abouti à un fork vraiment actif.
Non, c'est une supposition ou confusion de Macadoum. Les participants au Google Summer of Code pour Haiku sont pour la plupart d'entre eux étudiants en Inde, et on ne collecte pas plus d'infos que ça. En fait on ne demande que le nom, prénom et fuseau horaire, mais la plupart des participants indiquent leur université et donc leur pays de résidence.
Pourquoi autant de succès en Inde pour Haiku? Je ne sais pas. Mais le Google Summer of Code est assez intéressant d'un point de vue financier par rapport au coût de la vie. Il y a quelques années, le paiement était le même quel que soit le pays de résidence, maintenant il est un peu ajusté. Il y a aussi assez peu de difficultés à faire reconnaître la participation au summer of code comme un stage (compliqué en France par exemple parce que Google est techniquement l'employeur, mais ne veut pas signer de convention de stage spécifique pour chaque étudiant)
Par contre tu dis d'un coté que l'intérêt c'est qu'il n'y a qu'une seule équipe pour tout et de l'autre que tu aimerais voir des projets se lancer sur haiku, ça ne me semble pas aller ensemble.
Oui, c'est compliqué.
Cela dit, actuellement il y a de nombreux projets qui sont maintenus par les même développeurs que l'OS. En fait c'est plutôt l'inverse: des gens commencent par développer une application, trouvent des bugs dans l'OS qui les empêchent d'avancer, et finissent par se retrouver contributeurs sur le système.
Souvent, les applications adoptent les conventions de nommage et de formatage de code de Haiku, ainsi que les conventions d'interface graphique. Je pense qu'on retrouve un peu la même chose dans un projet comme GNOME ou KDE, sauf qu'il y a une frontière par exemple entre GNOME-GTK-applications et les couches plus basses (libc, noyau). Pas infranchissable, mais compliquée, en particulier parce qu'il y a plusieurs implémentations de la libc (glibc, musl, bsd, …) et du noyau (Linux, BSD, …). En conséquence, utiliser une fonctionnalité nécessite qu'elle soit disponible dans toutes les implémentations, et finalement on doit se contenter de ce qui est commun entre tous les systèmes.
Dans Haiku, il n'y a pas de frontière de ce type. Si on a besoin de rajouter quelque chose dans le noyau ou dans la libc, on peut le faire directement.
Il n'y a pas non plus la frontière entre la distribution Linux et les paquets qui sont intégrés dedans. Donc, gestion commune des sorties de nouvelles versions, par exemple. Ce qui facilite la maintenance.
D'un autre côté, on a maintenant plein d'applications basées sur Qt, et on retrouve là un certains nombre de problèmes qu'il y a sous Linux. Mais actuellement c'est compliqué d'utiliser Haiku sans ces applications, car il n'y a pas beaucoup d'applications natives. Ce qui demande donc de faire un compromis. Faut-il essayer d'améliorer ces applications Qt, ou bien plutôt écrire des applications natives? Le deuxième choix est probablement meilleur à long terme, mais pas à court terme. Et si le système n'est pas utilisable à court terme, les développeurs de Haiku ne vont pas pouvoir l'utiliser, et ils vont être moins motivés pour contribuer et développer de nouvelles applications.
est-ce qu'on retrouve "autant" de logiciels non libre sur Haiku ?
Non. Mais on espère que ça viendra un jour quand on aura un peu plus d'utilisateurs :)
Ça avait un peu commencé du temps de BeOS (l'ancêtre de Haiku) mais il y a plusieurs projets qui n'ont pas trop abouti à l'époque suite à l'abandon du développement de BeOS.
Après, j'ai répondu à la question "à quoi sert Haiku" de mon point de vue et ça ne veut pas dire que les autres systèmes (Linux, BSD, …) n'ont pas aussi leur place. L'une des choses qui rendent Linux intéressant, c'est d'avoir plein de choix de logiciels et d'environnements de bureau qui conviennent à beaucoup de monde, et d'avoir réussi à avoir une part de marché suffisante pour attirer l'attention aussi bien des développeurs d'outils professionnels (Slack, Teams, …) que de jeux vidéos (Steam). On en serait probablement pas là si GNOME, KDE et les autres environnement de bureaux (et/ou les distributions Debian, Arch, Ubuntu, …) avaient chacun choisi de développer leur propre OS sans rien partager.
Probablement, mais c'est un peu ça le problème que je soulève. Mon problème, ce n'est pas tellement qu'il manque une fonctionalité. On l'a rajoutée dans Haiku. On pourrait la rajouter dans les outils que j'utilise sous Linux aussi (en l'occurence, Terminator et PCManFM).
Mais j'utilise Debian. Donc ma première question va être de savoir si le problème est juste parce que Debian utilise une vieille version de ces outils (pas eu le temps de commencer la migration vers Debian 11 pour l'instant). Il faudrait aussi identifier lequel des deux a un problème pour pouvoir remonter le bug au bon endroit.
En fait le souci c'est plutôt que les bugs sous Linux ont tendance à s'accumuler aux endroits ou il y a 2 ou 3 logiciels (développés par des équipes différentes) en jeu. C'est le genre de cas ou on ne sait pas trop vers qui se tourner pour remonter un bug. C'est aussi le genre de cas ou les développeurs de plusieurs projets vont devoir se mettre d'accord.
L'approche de Haiku évite ce problème puisqu'il n'y a qu'une seule équipe qui développe à peu près tout.
Je l'ai présenté avec mon point de vue de développeur, mais je pense que c'est ressenti aussi par les utilisateurs dans certains cas. Par exemple le fait qu'il y ait un seul endroit ou remonter les bugs, un seul forum pour demander de l'aide. Ça peut être un peu le cas pour Linux aussi, avec les distributions Linux qui peuvent un peu assurer le rôle de "support niveau 1": réponse aux questions des utilisateurs, et remontée des bugs aux projets concernés s'il y a lieu. Mais je ne sais pas si ça fonctionne bien (les quelques bugs que j'ai remonté à Debian n'ont pas abouti à grand chose…).
Je l'utilise sur mon PC et j'en suis globalement content. Aucun environnement de bureau sous Linux n'est aussi abouti, il y a tout le temps des problèmes d'intégration entre les différents logiciels et les développeurs passent leur temps à se renvoyer la balle au lieu de corriger les problèmes.
Dans Haiku, y'a un seul dépôt git et j'y ai accès en écriture, je peux donc corriger mes problèmes tout seul.
Par exemple sur mon pc linux au travail:
- lorsque je sors le pc de veille, l'écran déverouillé s'affiche pendant une seconde avant de revenir sur l'écran de mot de passe. Bonjour la sécurité.
- par défaut, les notifications de thunderbird pour les nouveaux mails s'affichent par dessus l'écran de veille. Mauvaise interaction entre thunderbird, xscreensaver et xorg. Ils ont chacun un bug ouvert à ce sujet depuis 10 ans mais ne se sont toujours pas mis d'accord pour savoir qui doit corriger quoi.
- je ne peux pas glisser-déposer un fichier depuis mon navigateur de fichiers vers mon terminal pour insérer son nom dans la commande que je suis en train de taper.
- libreoffice ne peut pas ouvrir et enregistrer des fichiers sur un partage smb. Je pense que c'est parce qu'il y a un ":" dans le chemin ou le partage est monté
- quand j'ouvre un fichier depuis mon navigateur de fichiers avec onlyoffice, parfois onlyoffice s'ouvre avec un document vide.
Est-ce que tous ces problèmes pourraient être corrigés? Oui, sans doute. Est-ce que je pourrais le faire? Peut-être. Est-ce que je vais m'amuser à télécharger et recompiler la douzaine de logiciels concernés pour démêler d'ou ça vient? Je pense que je vais me décourager avant.
Ceci sans parler du confort d'utilisation des APIs de Haiku qui me permettent d'écrire une application vite fait en une demi journée, chose que je suis incapable de faire avec Qt et encore moins avec GTK (et sous Linux je serais obligé de jongler entre les deux). Et aussi de pouvoir travailler sur tous les aspects en utilisant une seule façon de formater mon code, un seul outil de contrôle des sources (git), un seul langage de programmation.
Ça, c'est ma vision de dévelopeur. Mais je pense que ça se ressent sur le reste du système, dans l'ensemble, ça "juste marche" même s'il y a encore beaucoup de travail pour tout faire comme on voudrait.
Après, chacun son truc, si vous êtes content de Linux et que ça vous convient, c'est tant mieux pour vous :)
# Qu'est-ce que ça va casser?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les adresses IP en 127.x.x.x bientôt routables sur Internet. Évalué à 8.
Si vous ne vous y connaissez pas en réseau, ces adresses étaient jusqu'à présent réservée pour une utilisation locale sur une machine. La plus connue étant 127.0.0.1, mais c'est possible d'en utiliser d'autres.
Par exemple la synchronisation d'un serveur NTP avec un récepteur GPS situé sur la même machine utilise des adresses en 127.127.x.x: https://gist.github.com/edro15/c3fbaaabfe31ecb799363ffab587f336
Si cette proposition est adoptée, les adresses à partir de 127.1.0.0 jusqu'a 127.1.255.255 deviendront des adresses tout à fait normales, routables sur internet.
Il y avait déjà eu des problèmes lors d'opérations similaires avec les adresses 1.x.x.x et 128.x.x.x (liens donnés en références dans le draft), qui étaient simplement réservées (sans utilisation définie) avant d'être finalement attribuées. Leur mise en service a nécessité de contacter des opérateurs télécoms ayant une configuration incorrecte, de mettre à jour des routeurs, ou encore de déployer un firmware mis à jour sur des modems ADSL qui utilisaient ces adresses en interne. Elles recevaient aussi du traffic de client HTTP mal programmés, et plein d'autres choses non identifiées.
# Étiquettes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les adresses IP en 127.x.x.x bientôt routables sur Internet. Évalué à 5.
Message pour la modération:
Étiquettes repérées lors de la rédaction de ce lien, qui peuvent probablement être fusionnées/masquées:
# Analyse
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La Borne passe sanitaire (BPS), le premier produit en open hardware de la Gendarmerie !. Évalué à 4.
Les fichiers sont disponibles sur github: https://github.com/GendarmerieNationale/Borne-Passe-Sanitaire
Cela consiste principalement en fichiers pour l'impression 3D du boîtier. La borne fonctionne sous Android avec une Tinker Board ASUS. Pas de détails sur l'écran et la webcam utilisés, dans quelle mesure d'autres écrans seront-ils compatibles sans devoir modifier l'impression 3D?
La documentation explique aussi que l'application ne peut pas être mise à jour via le play store car la borne n'est pas associée à un compte Google. Elle n'est pas disponible sur F-Droid?
# ça s'apprend
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La génération qui a grandi avec Google ne sait pas utiliser un système de fichiers. Évalué à 10.
Oui ben voilà: les gens qui ont eu une formation en informatique pendant leurs études ont appris ce que c'est qu'un dossier et comment ça s'utilise. Et puis à un moment quelqu'un s'est dit que ces cours ne servaient plus à rien et que les nouveaux étudiants allaient connaître ça instinctivement. Et c'était une erreur. Google n'a rien à voir là dedans, non?
Personnellement j'ai eu quelques cours d'informatique au collège (fichiers, dossiers, traitement de texte, etc). Sans quoi je n'aurai probablement pas vraiment compris tout seul comment ça marchait (bien que ayant déjà utilisé des ordinateurs avant ça). Et plus tard quand je suis arrivé en IUT informatique, une séance de travaux pratiques là dessus pour vérifier que si tout le monde était au point ou si des cours sur le sujet étaient nécessaires.
[^] # Re: Haiku
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 3.
Il y a plusieurs choses qui devraient normalement être listées pour chaque bouton:
Malheureusement, la plupart des gamepads font plutôt quelque chose du genre "voici 15 boutons dans un ordre aléatoire" sans donner plus de détails.
La liste des "usages" possibles: https://usb.org/sites/default/files/hut1_22.pdf (mises à jour régulièrement, on peut voir sur le site usb.org la liste des nouveaux usages en cours de discussion, c'est tout aussi divertissant que la liste des emojis dans Unicode)
La spécification USB HID et en particulier la section 6.2.3 pour les descripteurs physiques: https://usb.org/sites/default/files/hid1_11.pdf
Le seul truc que je n'ai pas trouvé, c'est comment décrire la couleur des boutons. Ce qui est dommage parce que mon gamepad Gravis a juste des couleurs pour différencier les boutons, et pas de texte ou de symboles.
[^] # Re: Haiku
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 4.
Pour le binding, SDL2 permet déjà de le faire mais il faut lui fournir ce fichier: https://github.com/gabomdq/SDL_GameControllerDB
Je vais probablement réutiliser ces informations dans Haiku également. Par contre je trouve la liste de boutons disponibles dans SDL2 un peu limitée: http://wiki.libsdl.org/SDL_GameControllerButton (pas de bouton SELECT par exemple?)
C'est difficile de faire ça bien parce que la plupart des contrôleurs ne fournissent pas d'infos sur la position physique des boutons (alors que c'est possible dans l'USB HID). Donc il faut renseigner à la main ce genre de fichier pour avoir les infos nécessaires.
[^] # Re: Lien cassé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 6.
En effet, erreur dans le lien, le projet se trouve ici: https://github.com/pulkomandy/avrstuff/tree/master/grip2hid
Je fais mes schémas et PCBs avec Kicad et la production est faite par Seeed Studio
[^] # Re: Cohérence ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Intégration continue - Travis, la stratégie commerciale défaillante ?. Évalué à 4.
On peut se logger sur gitlab.com avec un compte github (ainsi que d'autres fournisseurs openid). Donc c'est pas vraiment un problème.
[^] # Re: Bravo !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien [TIOBE] Python programming language number 1!. Évalué à 4.
Il y a d'autres approches, par exemple regarder le nombre de dépôts github ou le nombre de pull requests, ou encore le nombre de questions sur StackOverflow. On peut aussi essayer de regarder uniquement les projets qui changent de langage et écrivent un blog à ce sujet.
Dans les 3 premiers cas, on retrouve à peu près toujours les mêmes en tête de classement. La question c'est plutôt pourquoi Javascript est à ce point sous-évalué par TIOBE?
[^] # Re: le plus rapide en code simple
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Recherche de valeur dans un tableau et l'écosystème des compilateurs C++. Évalué à 2.
En effet. J'ai trouvé un benchmark qui conclut que ça marche plutôt bien, 3 fois plus rapide que l'implémentation qui teste les octets un par un: https://gist.github.com/nico/2624336
[^] # Re: Vectorisation illégale
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Recherche de valeur dans un tableau et l'écosystème des compilateurs C++. Évalué à 7.
Gcc fait des optimisations auxquelles on ne s'attend pas forcément. Quelques cas auxquels je pense:
Les compilateurs font usage de tout ce qui est dit dans la spécification, et la spécification est architecturée pour ça. Par exemple la spécification du C décrit un mode "hosted" et un mode "freestanding", dans le deuxième, la plupart des fonctions de la librairie standard ne sont plus définies. Ce qui permet au compilateur de savoir qu'il doit désactiver les optimisations correspondantes.
L'idée qu'on se fait d'une architecture bien découpée en couches indépendantes ne tient en fait pas la route quand on regarde les détails d'implémentation.
# Un autre benchmark
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Recherche de valeur dans un tableau et l'écosystème des compilateurs C++. Évalué à 6.
Celui-ci ajoute d'autres implémentations: la fonction memchr en C est équivamente, et il y a différentes implémentations dans différentes biblothèque C. Certaines plus lentes et certaines plus rapides que l'implemenation "naive" avec une simple boucle.
https://gms.tf/stdfind-and-memchr-optimizations.html
Cela a donné lieu à une discussion sur la mailing list du musl: https://www.openwall.com/lists/musl/2016/09/18/3 avec des liens supplémentaires vers d'autres cas ou des libraries C proposent une implémentation "optimisée" qui est en fait plus lente que l'implémentation triviale en C. D'ou la conclusion: on peut faire confiance au compilateur pour optimiser le code simple et lisible de façon pas trop mauvaise. Même si le compilateur n'est pas parfait et que les fonctions de la glibc sont très génériques, et souvent on peut écrire du code plus efficace, ce n'est pas la peine d'essayer de le faire systématiquement.
[^] # Re: le plus rapide en code simple
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Recherche de valeur dans un tableau et l'écosystème des compilateurs C++. Évalué à 3.
Je ne vois pas comment on peut tester l'égalité de chaque moitié d'un registre 64bit séparément avec une seule instruction de comparaison non vectorisée.
Au mieux on peut faire un XOR bit à bit, et ensuite il faut regarder si les 32 premiers ou les 32 derniers bits sont tous à 0. Ce qui fait toujours 2 comparaisons.
[^] # Re: Question bête…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku embauche un développeur à (presque) plein temps. Évalué à 5.
Ma dernière utilisation de Mac OS X remonte à quelques années mais on voyait bien que c'était une tentative de réunifié l'interface de NeXT avec celle de Mac OS 9 et que la mayonnaise n'a pas vraiment pris.
La cohérence, c'est plein de petits détails. Le fait que le bouton "ok" dans les boîtes de dialogues soit à droite ou à gauche. Que le menu "préférences" soit rangé dans "édition" ou plutôt dans "fenêtre". Ces deux exemples sont pris dans Firefox 2, ou ce genre de chose étaient différentes entre les versions Linux et Windows pour s'adapter aux conventions de chaque système.
D'un point de vue de l'apparence, c'est le fait de pouvoir choisir la bolice de caractère et sa taille une seule fois, et que ce choix soit appliqué par toutes les applications. Qu'elles se comportent toutes de la même façon quand on déplace une fenêtre entre deux écrans de résolution différente, et qu'on ait pas certaines applications qui se grossissent automatiquement, et d'autres pas.
C'est avoir des raccourcis claviers standardisés (mais ça, ça marche à peu près bien sous Linux et Windows). Des options en ligne de commande qui marchent toujours pareil (pas comme dd, ou sous Windows c'est pire avec la moitié des programmes qui veulent des options commençant par / et l'autre moitié par -)
Ça va bien au-delà de la couleur et de la police de caractère choisies pour l'affichage, donc. Et la comparaison avec la ligne de commande va plus loin: de la même façon que on peut combiner grep, sed, awk, etc… pour faire un script shell, il serait intéressant de pouvoir combiner des applications graphiques. Dans Haiku, on ne prévoit pas d'avoir un IDE tout-en-un. On prévoit d'avoir un outil de gestion de projet (un genre de frontend graphique pour make ou cmake), qui va communiquer avec un éditeur de texte pour lui dire quel fichier ouvrir, quelle ligne de code afficher dedans, etc. Le protocole entre les deux est documenté et chaque partie peut être remplacée.
[^] # Re: Question bête…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku embauche un développeur à (presque) plein temps. Évalué à 4.
C'est possible, mais les développeurs de Blink et Chromium sont franchement hostiles à ce genre de choses. Par exemple ils refusent d'inclure les patches pour le support de FreeBSD ou OpenBSD, qui sont donc maintenus dans un fork.
Et tout ça pour avoir des applications consommant des gigaoctets de mémoire et avec une interface ne s'intégrant pas proprement avec le reste du système.
Personellement, ça ne m'intéresse pas de passer du temps à faire ça. Mais je ne doute pas que d'autres développeurs s'y mettront un jour ou l'autre.
[^] # Re: oust
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien AnySoftKeyboard impose des notifications covid à ses utilisateurs. Évalué à 2.
Sur mon téléphone j'utilise le clavier MessagEase (pas libre, j'attends toujours que quelqu'un se décide à en faire une copie libre…). C'est un clavier conçu pour les écrans tactiles (il a fait ses débuts sur certains PDA avant d'arriver sur les téléphones)
D'ailleurs je me souviens de l'époque ou j'utilisais un PDA et il me semble qu'il y avait un peu plus de tentatives pour des méthodes de saisie plus adaptées. Alors qu'aujourdhui on se traîne encore des claviers de machines à écrire conçus il y a 2 siècles avec des contraintes complètement différentes…
[^] # Re: touches multimédia ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Clavier Logitech G213 Prodigy. Évalué à 4.
Oui, c'est standardisé dans l'USB HID (human interface devices) depuis que l'USB existe (donc plutôt 25 ans maintenant?)
# Péniche Nouvelle Vague
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien DevOps REX : 10 façons de rater son passage vers l’agilité. Évalué à 4. Dernière modification le 03 septembre 2021 à 23:55.
Je ne sais pas ce qui me déconcerte le plus là dedans: le buzzword bingo gagnant à chaque paragraphe, le fait cue l'entreprise soit domiciliée dans une péniche, ou le nom de la péniche qui est unjeu de mot digne des meilleurs salons de coiffure?
[^] # Re: Question bête…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku embauche un développeur à (presque) plein temps. Évalué à 9.
Je n'ai pas réglé ce bug dans Linux, X11, etc parce queje suis occupé à écrire un système d'exploitation ou il n'y a pasce genre de bugs. D'autres questions?
[^] # Re: Question bête…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku embauche un développeur à (presque) plein temps. Évalué à 5.
On a quelques gens pas contents qui sont partis du projet à différentes étapes. Ou qui sont toujours plus ou moins là mais qui continuent à râler sur certains trucs.
Je pense par exemple à la décision d'utiliser C++ dans le noyau, au gestionnaire de paquets et à la façon dont il fonctionne qui rend certains dossiers accessibles seulement en lecture, et à la décision de conserver la compatibilité avec BeOS et donc de pouvoir compiler une grande partie du code avec gcc2. Et sûrement plein d'autres raisons. Mais pour l'instant, ça n'a jamais encore abouti à un fork vraiment actif.
[^] # Re: Ban telegram
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 beta 3 - Haiku a 20 ans !. Évalué à 7.
Non, c'est une supposition ou confusion de Macadoum. Les participants au Google Summer of Code pour Haiku sont pour la plupart d'entre eux étudiants en Inde, et on ne collecte pas plus d'infos que ça. En fait on ne demande que le nom, prénom et fuseau horaire, mais la plupart des participants indiquent leur université et donc leur pays de résidence.
Pourquoi autant de succès en Inde pour Haiku? Je ne sais pas. Mais le Google Summer of Code est assez intéressant d'un point de vue financier par rapport au coût de la vie. Il y a quelques années, le paiement était le même quel que soit le pays de résidence, maintenant il est un peu ajusté. Il y a aussi assez peu de difficultés à faire reconnaître la participation au summer of code comme un stage (compliqué en France par exemple parce que Google est techniquement l'employeur, mais ne veut pas signer de convention de stage spécifique pour chaque étudiant)
[^] # Re: Question bête…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku embauche un développeur à (presque) plein temps. Évalué à 4.
Oui, c'est compliqué.
Cela dit, actuellement il y a de nombreux projets qui sont maintenus par les même développeurs que l'OS. En fait c'est plutôt l'inverse: des gens commencent par développer une application, trouvent des bugs dans l'OS qui les empêchent d'avancer, et finissent par se retrouver contributeurs sur le système.
Souvent, les applications adoptent les conventions de nommage et de formatage de code de Haiku, ainsi que les conventions d'interface graphique. Je pense qu'on retrouve un peu la même chose dans un projet comme GNOME ou KDE, sauf qu'il y a une frontière par exemple entre GNOME-GTK-applications et les couches plus basses (libc, noyau). Pas infranchissable, mais compliquée, en particulier parce qu'il y a plusieurs implémentations de la libc (glibc, musl, bsd, …) et du noyau (Linux, BSD, …). En conséquence, utiliser une fonctionnalité nécessite qu'elle soit disponible dans toutes les implémentations, et finalement on doit se contenter de ce qui est commun entre tous les systèmes.
Dans Haiku, il n'y a pas de frontière de ce type. Si on a besoin de rajouter quelque chose dans le noyau ou dans la libc, on peut le faire directement.
Il n'y a pas non plus la frontière entre la distribution Linux et les paquets qui sont intégrés dedans. Donc, gestion commune des sorties de nouvelles versions, par exemple. Ce qui facilite la maintenance.
D'un autre côté, on a maintenant plein d'applications basées sur Qt, et on retrouve là un certains nombre de problèmes qu'il y a sous Linux. Mais actuellement c'est compliqué d'utiliser Haiku sans ces applications, car il n'y a pas beaucoup d'applications natives. Ce qui demande donc de faire un compromis. Faut-il essayer d'améliorer ces applications Qt, ou bien plutôt écrire des applications natives? Le deuxième choix est probablement meilleur à long terme, mais pas à court terme. Et si le système n'est pas utilisable à court terme, les développeurs de Haiku ne vont pas pouvoir l'utiliser, et ils vont être moins motivés pour contribuer et développer de nouvelles applications.
[^] # Re: Question bête…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku embauche un développeur à (presque) plein temps. Évalué à 6.
Non. Mais on espère que ça viendra un jour quand on aura un peu plus d'utilisateurs :)
Ça avait un peu commencé du temps de BeOS (l'ancêtre de Haiku) mais il y a plusieurs projets qui n'ont pas trop abouti à l'époque suite à l'abandon du développement de BeOS.
Après, j'ai répondu à la question "à quoi sert Haiku" de mon point de vue et ça ne veut pas dire que les autres systèmes (Linux, BSD, …) n'ont pas aussi leur place. L'une des choses qui rendent Linux intéressant, c'est d'avoir plein de choix de logiciels et d'environnements de bureau qui conviennent à beaucoup de monde, et d'avoir réussi à avoir une part de marché suffisante pour attirer l'attention aussi bien des développeurs d'outils professionnels (Slack, Teams, …) que de jeux vidéos (Steam). On en serait probablement pas là si GNOME, KDE et les autres environnement de bureaux (et/ou les distributions Debian, Arch, Ubuntu, …) avaient chacun choisi de développer leur propre OS sans rien partager.
[^] # Re: Question bête…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku embauche un développeur à (presque) plein temps. Évalué à 8.
Probablement, mais c'est un peu ça le problème que je soulève. Mon problème, ce n'est pas tellement qu'il manque une fonctionalité. On l'a rajoutée dans Haiku. On pourrait la rajouter dans les outils que j'utilise sous Linux aussi (en l'occurence, Terminator et PCManFM).
Mais j'utilise Debian. Donc ma première question va être de savoir si le problème est juste parce que Debian utilise une vieille version de ces outils (pas eu le temps de commencer la migration vers Debian 11 pour l'instant). Il faudrait aussi identifier lequel des deux a un problème pour pouvoir remonter le bug au bon endroit.
En fait le souci c'est plutôt que les bugs sous Linux ont tendance à s'accumuler aux endroits ou il y a 2 ou 3 logiciels (développés par des équipes différentes) en jeu. C'est le genre de cas ou on ne sait pas trop vers qui se tourner pour remonter un bug. C'est aussi le genre de cas ou les développeurs de plusieurs projets vont devoir se mettre d'accord.
L'approche de Haiku évite ce problème puisqu'il n'y a qu'une seule équipe qui développe à peu près tout.
Je l'ai présenté avec mon point de vue de développeur, mais je pense que c'est ressenti aussi par les utilisateurs dans certains cas. Par exemple le fait qu'il y ait un seul endroit ou remonter les bugs, un seul forum pour demander de l'aide. Ça peut être un peu le cas pour Linux aussi, avec les distributions Linux qui peuvent un peu assurer le rôle de "support niveau 1": réponse aux questions des utilisateurs, et remontée des bugs aux projets concernés s'il y a lieu. Mais je ne sais pas si ça fonctionne bien (les quelques bugs que j'ai remonté à Debian n'ont pas abouti à grand chose…).
[^] # Re: Question bête…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku embauche un développeur à (presque) plein temps. Évalué à 10.
Je l'utilise sur mon PC et j'en suis globalement content. Aucun environnement de bureau sous Linux n'est aussi abouti, il y a tout le temps des problèmes d'intégration entre les différents logiciels et les développeurs passent leur temps à se renvoyer la balle au lieu de corriger les problèmes.
Dans Haiku, y'a un seul dépôt git et j'y ai accès en écriture, je peux donc corriger mes problèmes tout seul.
Par exemple sur mon pc linux au travail:
- lorsque je sors le pc de veille, l'écran déverouillé s'affiche pendant une seconde avant de revenir sur l'écran de mot de passe. Bonjour la sécurité.
- par défaut, les notifications de thunderbird pour les nouveaux mails s'affichent par dessus l'écran de veille. Mauvaise interaction entre thunderbird, xscreensaver et xorg. Ils ont chacun un bug ouvert à ce sujet depuis 10 ans mais ne se sont toujours pas mis d'accord pour savoir qui doit corriger quoi.
- je ne peux pas glisser-déposer un fichier depuis mon navigateur de fichiers vers mon terminal pour insérer son nom dans la commande que je suis en train de taper.
- libreoffice ne peut pas ouvrir et enregistrer des fichiers sur un partage smb. Je pense que c'est parce qu'il y a un ":" dans le chemin ou le partage est monté
- quand j'ouvre un fichier depuis mon navigateur de fichiers avec onlyoffice, parfois onlyoffice s'ouvre avec un document vide.
Est-ce que tous ces problèmes pourraient être corrigés? Oui, sans doute. Est-ce que je pourrais le faire? Peut-être. Est-ce que je vais m'amuser à télécharger et recompiler la douzaine de logiciels concernés pour démêler d'ou ça vient? Je pense que je vais me décourager avant.
Ceci sans parler du confort d'utilisation des APIs de Haiku qui me permettent d'écrire une application vite fait en une demi journée, chose que je suis incapable de faire avec Qt et encore moins avec GTK (et sous Linux je serais obligé de jongler entre les deux). Et aussi de pouvoir travailler sur tous les aspects en utilisant une seule façon de formater mon code, un seul outil de contrôle des sources (git), un seul langage de programmation.
Ça, c'est ma vision de dévelopeur. Mais je pense que ça se ressent sur le reste du système, dans l'ensemble, ça "juste marche" même s'il y a encore beaucoup de travail pour tout faire comme on voudrait.
Après, chacun son truc, si vous êtes content de Linux et que ça vous convient, c'est tant mieux pour vous :)