pulkomandy a écrit 1717 commentaires

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.

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…

Oui, c'est standardisé dans l'USB HID (human interface devices) depuis que l'USB existe (donc plutôt 25 ans maintenant?)

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 :)

Le problème est de savoir quand on est en train de faire un truc "un peu sérieux" ou un truc "vite fait et jetable".

Ça m'est arrivé plusieurs fois de me dire "ça va je peux faire ça en 3 lignes de bash" et de me retrouver des mois plus tard à regretter de pas avoir fait du Python. Maintenant, j'arrête d'écrire du bash dès que le script dépasse 3 lignes, c'est le moment ou il est encore facile de le convertir en Python avant qu'il ne soit trop tard.

À partir de quand un traitement de données devient-il "un peu sérieux"?

La séparation se fait assez bien (j'ai plein de projets qui ne concernent pas directement Haiku) et de toutes façons, quand on fait des choses intéressantes on ne voit pas le temps passer. Et il y avait peu de comptes à rendre pour Haiku, à part un décomptage des heures passées. Mais Haiku ne pouvait pas me financer à plein temps, et j'avais dû trouver un autre client (enfin, disons qu'on m'a proposé autre chose) pour compléter. Et là c'est devenu un peu compliqué de jongler entre les deux projets.

Mon travail salarié actuel n'est pas moins intéressant. Je suis responsable technique d'une équipe et on me laisse suffisament de liberté sur les choix techniques, et il y a d'autres gens qui s'occupent des choses que je n'aime pas faire (les réunions interminables avec les clients et fournisseurs, la négociation des contrats, …). Alors certes, il m'arrive souvent de râler sur Linux, Yocto, ou d'autres trucs mal fichus, mais globalement, ça marche quand même pas si mal que ça, et pour ce qu'on fait avec (du système embarqué), ça convient très bien.

Mais surtout, j'ai droit à plein de congés payés, et je reçois mon salaire à une date fixe tous les mois sans avoir à rédiger des factures. Et un salaire plus élevé, aussi. À l'éhoque ou je travaillais pour Haiku, ma compagne payait la moitié du loyer de notre logement. En ce moment j'habite tout seul chez moi et le budget serait un peu plus compliqué à gérer à moins de négocier un salaire plus haut. Enfin, plein de petits trucs qui font que finalement le salariat, ça me convient plutôt mieux, en tout cas avec mon employeur actuel.

• La vidéo complète: https://www.youtube.com/watch?v=Vj04MKykmnQ
• Les sources publiées: https://community.umidigi.com/forum.php?mod=viewthread&tid=20572

Le travail est déjà en cours pour l'intégration dans PostMarketOS.

Oui, je fais partie de la liste des précédents contrats: en 2009 via le Google Summer of Code (3 mois), en 2010 (2 mois) pour travailler sur l'internationalisation, et en 2014 (1 an) pour le navigateur web.

En ce moment j'ai un emploi à plein temps, intéressant sur le plan technique et plus stable que ce que peut proposer Haiku, et c'est moins compliqué d'être salarié que auto-entrepreneur (Haiku inc ne pouvant pas embaucher directement une personne à l'étranger facilement, c'était la solution retenue).

Donc pour l'instant je fais autre chose.

Si les finances de Haiku permettent un jour d'embaucher une deuxième personne, ce sera peut être moi, mais pour l'instant on en est pas là.

Surtout que si tu as juste besoin de retrouver le nom d'une option, tu trouveras ta réponse plus vite dans le --help de la commande plutôt que dans sa page de man.

Ce qui permet d'avoir une page de man un peu plus détaillée pour les gens qui ne connaîssent pas du tout la commande ou qui ont besoin de détails plus précis.

C'est dommage si la page de man ne dit pas plus de choses que le --help.

Des exemples seraient bienvenus pour des commandes un peu plus complexes (grep, sed, …)

On en trouve pas mal dans la documentation de Linux proprement dit (epoll, par exemple) et des APIs de systemd (sd_notify, les APIs pour récupérer les logs de journalctl). Dans ces cas là il n'y a en général aucune autre documentation disponible, et quand la page de man n'existe pas ou ne donne pas d'exemple, ça devient vite compliqué.

Un cas que j'ai à traiter en ce moment, c'est la configuration des ports CAN sous linux en utilisant les sockets netlink. On trouve quelques infos sur SocketCAN dans la doc du noyau, il y a un peu de documentation sur netlink dans les pages de man, mais au final je n'ai pas eu d'autre choix que de tracer l'exécution de la commande ip avec strace pour voir exactement ce qu'elle fait, et reproduire les mêmes appels dans mon application. Un exemple m'aurait probablement fait gagner pas mal de temps (j'ai aussi essayé de lire le code de la commande ip, mais je me suis perdu dans plein de niveaux d'abstraction dont je n'avais pas besoin)

Oui, j'ai un clavier qui débloque.

(et j'ai fait exprès pour le titre, hein)

J'anticipe parce que forcément quelqu'un va râler: c'est un fil Twitter. Merci de grouper les commentaires inutiles à ce sujet en-dessous de celui-ci.

Fait gaffe, t'as pas de return TRUE à la fin de AddSysROMObjects() :P

Ah oui j'ai brutalement découpé un petit morceau de la fonction pour faire cet exemple , en vrai elle est un peu plus longue et il y a bien le return à la fin.

Et je soupçonne que Group devrait être écrit ’group’ :)

En effet.

Ce code vient de http://ace.cpcscene.net (dont j'ai pas trop parlé ici parce que c'est pas libre, choix de l'auteur original). Je m'occupe du portage pour Haiku et le mélange des conventions de codage n'est pas simple. Le code original est en C pour MorphOS avec une UI implémentée en C orienté objet avec plein de macros. L'interface graphique pour Haiku est écrite en partant de ces fichiers et en remplaçant tout ça par du C++ et en adaptant en partie le style. D'où parfois des variables ou paramètres qui ont gardé les conventions de la version originale. J'essaie de rester proche de l'original car ça me facilite la comparaison avec les versions suivantes pour intégrer les changements.

On ne voit pas sur la capture d'écran le mélange de tabulations et d'espaces pour l'indentation, aussi…

D'où l'intérêt d'avoir une bonne coloration syntaxique pour s'y retrouver, au moins le temps que je fasse un peu de nettoyage ;)

On peut supposer que c'est pas trop dans les habitudes de Doctolib et dans leur culture d'entreprise de gérer ce genre de pics d'activité. Après tout, ça ne fait que quelques mois qu'ils gèrent les rendez-vous pour la vaccination, et je ne vois pas de précédent où ils auraient reçu une telle activité. Forcément il y a des mauvaises surprises à l'arrivée, dans ce cas.

Il y a deux exemples dans le README du dépôt github dont le lien est à la fin du journal (avec un avant/après pour voir la différence).