Pour ARM, on a ARM qui conçoit le CPU et fournit un (plusieurs, en fait) coeur qui est intégré par différents fondeurs dans leurs SoC (ou ils vont ajouter plein de périphériques autour).
Pour x86, on a Intel qui fournit le CPU déjà fabriqué et le chipset, mais qui ne permet pas à d'autres fabricants d'intégrer ce même coeur dans leurs puces. Par contre, on a d'autres implémentations indépendantes, chez AMD et Via en ce moment mais il y en a eu aussi chez Cyrix, IBM, et quelques autres (https://en.wikipedia.org/wiki/List_of_x86_manufacturers). Et on a encore plein d'autres entreprises qui fabriquent des chipsets pour aller autour de ces CPUs.
Pour moi ça donne un avantage au x86, pour deux raisons. D'une part il y a de la concurrence sur le design de l'architecture, et donc oui, Intel est obligé de continuer à faire évoluer son architecture sous peine de se voir rattrapé et dépassé (si ce n'était pas le cas ils ne s'embêteraient pas à sortir régulièrement de nouveaux modèles plus performants). Et d'autre part, quand on a un problème du genre Spectre/Meltdown, on a une petite chance que l'une des implémentations ne soit pas impactée. Le tout en pouvant exécuter les mêmes binaires sur ces différents CPUs, et donc avec un coût plus faible pour remplacer le matériel quand c'est nécessaire.
La solution la plus intéressante serait donc un jeu d'instruction standardisé (avec discussions entre les différents fondeurs pour la faire évoluer) et plusieurs implémentations. Mais ça risquerait de finir comme POSIX: un standard très minimaliste, et des extensions plus ou moins spécifiques à chaque implémentation.
Ce que je dis au-dessus à propos de l'intégration des drivers dans l'upstream Linux.
Faire marcher une distribution Linux "classique" sans modifications sur n'importe quelle machine à base de ARM est difficile parce que Linux fait le choix d'embarquer tous les drivers dans un seul dépôt git et de tout packager ensemble. Du coup, tous les fabricants de SoC qui ne sont pas d'accord avec cette approche font un fork (et le maintiennent très rarement). Résultat, on a plein de forks pas maintenus et on avance pas.
Le problème n'est pas forcément technique, mais dans la façon de s'organiser et de collaborer. Et donc oui, le fork qui a choisi une organisation différente et qui marche (un peu) mieux, il s'appelle Android.
Je suis très étonné d'entendre que Fuchsia servirait à propriétariser la plateforme de Google. Pour un OS entièrement développé sous licence libre et avec des dépôts git publics (là ou Android continue à être développé en interne et publié uniquement une fois une version stable terminée), j'ai du mal à comprendre comment tu en arrive à cette conclusion?
Alors oui, il y a parmi les contributeurs beaucoup (voire explusivement) de gens payés par Google pour écrire du code libre. Mais comment on peut appeler ça une propriétarisation? Est-ce que c'est de leur faute si personne d'autre ne veut participer à ce projet, ou si tous ceux qui contribuent finissent par se faire embaucher chez eux?
D'abord sur OABI, EABI, EABI-hf: ce sont des ABIs, il y a exactement le même problème sur x86 selon qu'on utilise un compilateur Visual Studio ou un gcc, par exemple. Le CPU n'est pas directement concerné, sauf pour EABI-hf, qui se permet d'utiliser les registres des unités à virgule flottante directement (il faut que ces registres soient donc présents). Il me semble que maintenant tout le monde fait de l'EABI-hf, ce problème est donc largement réglé (sauf pour les gens qui font de l'embarqué avec des CPUs qui n'ont pas de FPU, mais ce n'est pas la question ici). Ce serait donc comme se plaindre qu'il y a des problèmes sur x86 quand on veut écrire du code qui tourne aussi bien sur un 486 que sur le dernier Core i7.
Ensuite sur la détection du matériel: ARM est effectivement uniquement une architecture CPU (comme x86), pas une architecture de machine (comme le "compatible PC"). Donc, c'est fourni sans BIOS ou UEFI, et surtout sans bus permettant d'énumérer les périphériques et de découvrir le matériel présent (sur un PC ce rôle est rempli en partie par le BIOS, et en partie par le bus PCI).
Enfin sur les versions de l'architecture matérielle: oui, il y en a plusieurs. Mais ça n'a dérangé personne de voir apparaître de nouvelles instructions (MMX, SSE, SSE2, …) sur les processeurs x86. Ni de voir AMD développer son propre jeu d'instruction concurrent (3DNow!) ou décider de faire une version 64 bits (que Intel a ensuite cloné). Pourquoi chez ARM soudainement ça serait un problème? Il est normal qu'une architecture de CPU évolue à chaque génération.
Cependant, les choses avancent. Du côté de ARM, tout un tas de choses qui ne sont pas purement du CPU sont standardisées petit à petit: la MMU, un timer qui déclenche une interruption à intervalles réguliers, etc. Du côté de Linux, les applications et tout l'userspace fonctionnent sur toutes les machines (c'est la moindre des choses qu'on attend d'un OS: fournir une couche d'abstraction du matériel). Le noyau devrait pouvoir le faire aussi, normalement. Pour cela on a besoin d'un "device tree" qui décrit le matériel (à quelle adresse sont les différents périphériques, la mémoire, etc) et dans le cas de Linux, de drivers intégrés dans le noyau mainline. C'est surtout de ce côté que ça coince: il ne semble pas raisonable pour la plupart des constructeurs de devoir absolument stocker leurs drivers dans le dépôt Git de Linus et de devoir passer toutes les étapes de revue de code (les défenseurs de cette stratégie diront que c'est pour leur bien, que ça augmente la qualité du code et qu'en échange ils assureront la maintenance). Pour l'instant le support des différents systèmes ARM repose donc largement sur la communauté, mais c'est comme ça que Linux a pu se faire une place sur le marché du PC aussi, au moins au début.
Le "compatible Android" a déjà remplacé le "compatible PC" comme standard de machine le plus répandu. Que Linux n'arrive pas encore à s'y adapter, c'est un autre problème.
Le problème ce n'est pas vraiment quand tu appuies sur une touche. Si tu fais par exemple un "cat grosfichier", dans la plupart des cas l'affichage sur le terminal va être plus lent que la lecture du fichier depuis le disque.
Dans mon cas, ça peut être avec une suite de tests unitaires qui génère beaucoup de logs dans le terminal, que je ne consulte pas forcément sauf si un test échoue. J'aimerais donc que ça s'affiche très rapidement sans ralentir l'exécution des tests.
Il y a des partenariats entre les divers relais colis et les transporteurs maintenant. Par exemple il est possible de se faire livrer un colis expédié par FedEx dans un point Mondial Relay.
Ils commencent à comprendre que passer chez les gens pendant les horaires de travail et sans prévenir avant c'est pas franchement utile…
Mon employeur verse un panier repas équivalent à la part patronale des titres restaurant, dans les cas où le salarié ne peut pas utiliser ces derniers (missions chez un client où il n'y a pas de restaurant à prix raisonnable à proximité). Dans ce cas, l'avantage en nature est préservé.
Je suppose que ça devrait fonctionner aussi si on passe aux titres électroniques et qu'ils sont acceptés nulle part.
Pour la génération des fichiers de traduction, ce sont également des outils développés par Haiku. Il s'aggit de collectcatkeys qui va parser des sources C++ à la recherche d'appels à une famille de macros (B_TRANSLATE) et extraire les chaînes de caractères passées en paramètre.
Pour chaque appel à la macro on peut avoir:
- La chaîne à traduire
- Un "contexte" (qui permet d'avoir la même chaîne avec des traductions différentes, par exemple quand un nom et un verbe sont homonymes en anglais mais pas dans les traductions)
- Un commentaire (qui est là pour informer les traducteurs)
Ces trois informations sont affichées par l'outil de traduction.
Le résultat est un fichier "catkeys" qui contient simplement ces entrées, une par ligne, avec les 3 infos séparées par des tabulations (les chaînes elle-mêmes sont stockées avec les caractères spéciaux échappés comme en C, donc s'il y a une tabulation ou un retour à la ligne dans la chaîne à traduire, il est remplacé par un \t ou un \n).
Ensuite on convertit les fichiers traduits dans un format binaire qui permet un accès plus rapide aux traductions.
Pour les outils de traduction, il y a d'abord eu un premier outil maison (c'était vers 2009 ou 2010), avant le passage à Pootle. Pootle fonctionne bien pour le système, mais nous n'avons pas réussi à y intégrer des applications tierces sous forme de projets indépendants. Pour la version ancienne, c'est en cours de migration!
Un problème de Pootle est qu'il est écrit en Python (si je me souviens bien) et donc en héberger une instance nécessite un serveur qui permet de faire des pages en Python. Ce n'est pas un problème pour le projet Haiku, mais ça l'est pour plusieurs projets de petites applications qui sont hébergées juste sous forme d'un projet github. Et là on a un développeur qui a eu envie de se faire la main sur le développement d'application web, je crois :)
En gros, le format est presque un langage de script qui permet au traducteur d'exprimer tout un tas de conditions sur les données à formater. On l'utilise principalement pour gérer correctement le nombre (singulier/pluriel en français, mais c'est plus compliqué dans d'autres langues, comme on peut le voir dans la base de données CLDR.
Comment ça se passe avec gettext pour gérer ce genre de problèmes?
La version française de la licence: "Faites ce que vous voulez, j'en ai rien à branler." contient bien une clause d'exclusion de garanties (indice: c'est la partie après la virgule). Par contre ça ne semble pas être le cas de la version anglaise.
Si ta fonction et tes arguments et leurs types sont nommés correctement, alors tu n'as pas besoin de répéter ces informations évidentes dans un cartouche de documentation.
En exagérant un peu, du code qui a besoin de documentation, c'est du code pas clair et mal écrit. Il vaut mieux passer du temps à nettoyer ton code qu'à le documenter. En suivant ce principe, on devrait pouvoir se faire une idée de l'architecture globale en regardant l'organisation des fichiers, ou les scripts de build.
Maintenant, c'est vrai que ce n'est pas facile d'en arriver là, et donc avoir une documentation peut être pertinent. La rédiger sous forme d'une TODO list (avec la liste de tous les trucs pas clairs) peut être un bon moyen de se souvenir que c'est comme ça qu'elle fonctionne, et que le but du développeur est de faire que la documentation ne soit plus nécessaire, parce que le code parle de lui-même.
Pootle, pour la traduction des applications fournies avec le système,
Polyglot, un outil maison, pour la traduction des applications tierces,
Un autre outil maison pour la traduction de la documentation du système.
Je précise que nous avons aussi choisi de ne pas utiliser gettext, nos traductions sont basées sur le support fourni par ICU qui donne pas mal de contrôle au traducteur pour le format des messages, et permet notamment une gestion correcte du pluriel dans toutes les langues (certaines ont des règles complexes ou inhabituelles).
Une conséquence est l'utilisation de notre propre format de fichier pour les traductions. Ce format a été intégré dans Pootle mais à ma connaissance pas dans les autres outils. Nous avons aussi une application native pour traduire ces fichiers, mais l'utilisation d'un outil en ligne et collaboratif est finalement plus conviviale.
Nous avons aussi un ensemble de documents destinés aux traducteurs afin d'aider la coordination, le choix d'un vocabulaire commun, etc: https://dev.haiku-os.org/wiki/i18n
On en a conscience, mais on fait ce qu'on peut avec les contributeurs qu'on a. Plutôt que de pleurer de honte dans ton coin, viens te moquer de nos goodies tous moche, et faire des propositions de nouveaux designs!
Pour un projet libre, c'est déjà difficile de recruter des développeurs, c'est encore plus compliqué de recruter des gens pour faire de la communication, du graphisme, de la comptabilité, de l'administration système, et plein d'autres trucs.
On a essayé de confier quelques tâches "design" aux participants du Google Code-In cette année. La conclusion est que comme on a pas de personne compétente/formée dans le domaine dans notre équipe, on a beaucoup de mal à obtenir des résultats corrects car on ne sait pas dire ce qui ne va pas dans les travaux qui nous sont remis dans ce cadre.
Il n'y a pas vraiment de controverse. Simplement, on passe beaucoup de temps dans un éditeur, c'est notre principal outil de travail, après tout. Et c'est bien d'avoir le choix entre différents outils, qui fonctionnent différemment et du coup conviennent aux besoins de chacun. Je suppose que c'est le cas aussi dans la plupart des autres métiers.
C'est vrai, il y a des sexistes parmi les hackers, et c'est vrai aussi, c'est un (gros) problème. Mais ça m'embête déjà qu'on en fasse une généralité, et encore plus un "ciment" (c'est fort, quand même!). Si on va aussi loin, ça donne l'impression qu'il n'y a plus rien à faire à part détruire les dits groupes (tous les groupes de hackers sont visés sans distinction, du coup).
On peut être un hacker, même en groupe, sans être sexiste.
Il n'y a pas de problème dans ton équipe, et c'est très bien. Mais ça ne répond pas à une question, qu'est-ce qu'on fait dans les cas où il y a manifestement un problème et qu'on arrive pas à s'en sortir?
Mettre en place un quota c'est une solution extrême et risquée, mais je ne sais pas s'il y a autre chose qui pourrait fonctionner (à part dissoudre l'équipe et recommencer, et encore).
En tout cas je travaille actuellement dans une équipe qui manque de diversité (pas juste homme/femme, on a aussi presque tous à peu près le même âge, des formations similaires, etc). Qu'est-ce qu'on peut faire pour se mettre un coup de pied aux fesses et essayer d'améliorer ça?
On va parler de comment ça se passe chez Haiku, tiens.
Nos paquets sont construits automatiquement à partir de recettes qui sont sur un dépôt github. On a un certain nombre de contributeurs actifs sur ce dépôt, mais surtout un tas de gens qui font des pull requests: soit des utilisateurs qui avaient besoin d'utiliser un logiciel et qui ont écrit une recette eux-même, soit de plus en plus, des développeurs upstream qui viennent eux-même mettre à jour nos recettes ou au moins nous ouvrir un ticket quand ils publient une nouvelle version (surtout si elle corrige une faille de sécurité).
En échange, on essaie de penser à faire des patchs propres et à les envoyer à l'upstream, même si on est pas toujours très efficaces ou réactifs (c'est qu'on gère beaucoup de paquets à la fois, quand même).
Pour l'instant ça se passe plutôt bien dans l'ensemble.
Sauf que cet article ne vise pas spécifiquement le code source. En fait ils ont plutôt en tête les sites de streaming vidéo, musique, etc. L'incidence sur le logiciel (libre ou pas) est accidentelle, les rédacteurs de l'article n'y ont probablement pas vraiment pensé et oublié que le code des logiciels est soumis lui aussi au droit d'auteur.
C'est pour ça qu'il y a besoin d'un peu de lobbying pour rappeler notre existence et expliquer que ce cas particulier est problématique, afin que la rédaction de l'article soit analysée et si nécessaire modifiée pour pallier le problème.
ça va être compliqué de contacter toutes les entreprises de l'univers connu pour leur demander si elles ont un bout de code (ou tout autre oeuvre soumise au droit d'auteur) qu'elles souhaitent voir protégé.
Donc je ne vois pas de solution raisonnable, sauf celle ou c'est le propriétaire des droits qui est à l'initiative de la chose. Par contre, avec cette loi, l'hébergeur sera obligé de mettre en place les moyens nécessaires. En contrepartie, il aura la collaboration du propriétaire des droits de l'oeuvre.
Soyons clairs: cette loi est écrite avec en tête des œuvres dont la gestion des droits est organisée très différemment. L'idée c'est que la SACEM va pouvoir venir mettre son nez chez Deezer, Spotify, Dogmazic ou leurs concurrents et leur demander de vérifier les droits de ce qu'ils diffusent - et va donc devoir leur donner accès à son catalogue pour leur permettre de faire les vérifications. Mais je doute que l'Agence pour la Protection des Programmes en fasse de même avec Github, Gitlab ou Framagit.
Avec un quota, tu vas volontairement écarter des gens qui conviennent parfaitement pour en mettre d'autres qui conviennent moins. Pour de l'idéologie.
Tu as raté un virage dans le raisonement.
Si tu fais une équipe avec les gens "qui conviennent parfaitement" uniquement, tu vas construire une monoculture. J'ai vécu ça dans une boîte: tous les employés venaient de la même fac avec le même diplôme avant que j'arrive. Donc oui, ils s'entendaient bien et ils réfléchissaient tous de la même façon. Et ils faisaient des trucs pas du tout efficace sans s'en rendre compte.
Si au contraire tu fais l'effort de sortir de la zone de confort, tu vas enrichir la culture de ton entreprise avec des gens d'horizons différents. Et ils vont t'apporter des trucs que personne n'aurait pu prévoir.
Ce qui est important, c'est d'apporter de la diversité et des points de vue différents.
ça peut marcher tout seul si ton équipe de départ a compris que la diversité était importante et apportait de l'ouverture. Mais si ce n'est pas le cas, il va falloir forcer un peu les choses, et le recours à des "quotas" peut être une solution.
J'étais un peu inquiet avec cette affaire, mais en lisant l'article dans le détail:
prennent, en coopération avec les titulaires de droits, des mesures destinées à assurer le bon fonctionnement des accords
Du coup, si quelqu'un veut que son code soit protégé, il doit venir demander et doit coopérer pour mettre en place les contrôles.
Ces mesures doivent être appropriées et proportionnées.
Je dirais qu'une mesure du genre "demander la licence à la personne qui soumet du code" serait déjà tout à fait appropriée (ce n'est pas le cas sur GitHub par exemple et il y a plein de code sans licence ou avec une licence pas claire) et serait plutôt une bonne chose pour le logiciel libre.
On peut la compléter d'un "si vous voyez du code qui vous appartient, contactez-nous, on vérifie et on le supprime s'il y a lieu" qui me semble assez adapté.
Est-ce que ceci semble approprié et proportionné? Je pense que oui. Si une forge décide d'aller plus loin et de mettre en place un truc chiant, ça va juste faire que ses utilisateurs iront voir ailleurs, non?
Note pour moi-même, vérifier que les dépendances listées par le .deb sont bien les seules réellement nécessaires, c'est une piste de râlage potentiel… ou un moyen d'apprendre une technique pour faire du code plus indépendant du système: d'un côté ou de l'autre, je gagnerai à étudier ça.
Fais attention, bientôt tu vas te retrouver à envoyer des rapports de bugs à Microsoft, voire même à contribuer à régler le problème (gasp!).
J'utilise le menu formulaire pour fabriquer… ben des formulaires.
Par exemple, les fiches d'inscription dans une école de musique, que je peux ainsi exporter en formulaires PDF que les adhérents peuvent compléter et renvoyer par mail ou imprimer. Ce qui me permet d'avoir des adresses mails écrites par ordinateur et pas des gribouillages illisibles. Le gain de temps est appréciable et c'est très facile à faire.
C'est la première fois que j'entends dire qu'il y a des fonctionnalités en trop dans LibreOffice.
Le VPU c'est une unité utiliser pour décoder de la vidéo. Ce sera utilisé par exemple par ffmpeg ou gstreamer. Rien ne t'oblige à afficher la dite vidéo sur un écran (en passant par le GPU). Tu peux très bien décider de la ré-encoder dans un autre format, de l'envoyer sur le réseau, etc.
Donc le VPU (décodage vidéo) et le GPU (accélération 3D) ne sont pas liés. En plus, sur ce genre de puces le GPU lui-même n'est même pas branché directement à la partie affichage qui gère le framebuffer. Le GPU fait uniquement l'accélération 3D, et fait son rendu dans la RAM (rendu que tu pourrais très bien… envoyer au VPU pour l'encoder, sans jamais l'afficher à l'écran).
Ce sont donc des blocs complètement indépendants.
Sur les architectures x86, le GPU et le VPU sont effectivement souvent regroupés dans la partie "carte graphique", avec une séparation un peu moins claire.
[^] # Re: Effet de mode?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ARM vs Intel. Évalué à 5.
En effet, c'est assez différent.
Pour ARM, on a ARM qui conçoit le CPU et fournit un (plusieurs, en fait) coeur qui est intégré par différents fondeurs dans leurs SoC (ou ils vont ajouter plein de périphériques autour).
Pour x86, on a Intel qui fournit le CPU déjà fabriqué et le chipset, mais qui ne permet pas à d'autres fabricants d'intégrer ce même coeur dans leurs puces. Par contre, on a d'autres implémentations indépendantes, chez AMD et Via en ce moment mais il y en a eu aussi chez Cyrix, IBM, et quelques autres (https://en.wikipedia.org/wiki/List_of_x86_manufacturers). Et on a encore plein d'autres entreprises qui fabriquent des chipsets pour aller autour de ces CPUs.
Pour moi ça donne un avantage au x86, pour deux raisons. D'une part il y a de la concurrence sur le design de l'architecture, et donc oui, Intel est obligé de continuer à faire évoluer son architecture sous peine de se voir rattrapé et dépassé (si ce n'était pas le cas ils ne s'embêteraient pas à sortir régulièrement de nouveaux modèles plus performants). Et d'autre part, quand on a un problème du genre Spectre/Meltdown, on a une petite chance que l'une des implémentations ne soit pas impactée. Le tout en pouvant exécuter les mêmes binaires sur ces différents CPUs, et donc avec un coût plus faible pour remplacer le matériel quand c'est nécessaire.
La solution la plus intéressante serait donc un jeu d'instruction standardisé (avec discussions entre les différents fondeurs pour la faire évoluer) et plusieurs implémentations. Mais ça risquerait de finir comme POSIX: un standard très minimaliste, et des extensions plus ou moins spécifiques à chaque implémentation.
[^] # Re: Effet de mode?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ARM vs Intel. Évalué à 3.
Ce que je dis au-dessus à propos de l'intégration des drivers dans l'upstream Linux.
Faire marcher une distribution Linux "classique" sans modifications sur n'importe quelle machine à base de ARM est difficile parce que Linux fait le choix d'embarquer tous les drivers dans un seul dépôt git et de tout packager ensemble. Du coup, tous les fabricants de SoC qui ne sont pas d'accord avec cette approche font un fork (et le maintiennent très rarement). Résultat, on a plein de forks pas maintenus et on avance pas.
Le problème n'est pas forcément technique, mais dans la façon de s'organiser et de collaborer. Et donc oui, le fork qui a choisi une organisation différente et qui marche (un peu) mieux, il s'appelle Android.
# Propriétarisation?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Windows bronsonnisé ?. Évalué à 10.
Je suis très étonné d'entendre que Fuchsia servirait à propriétariser la plateforme de Google. Pour un OS entièrement développé sous licence libre et avec des dépôts git publics (là ou Android continue à être développé en interne et publié uniquement une fois une version stable terminée), j'ai du mal à comprendre comment tu en arrive à cette conclusion?
Les sources de Fuchsia: https://fuchsia.googlesource.com
Avec tout ce qu'on attend d'un projet libre:
Alors oui, il y a parmi les contributeurs beaucoup (voire explusivement) de gens payés par Google pour écrire du code libre. Mais comment on peut appeler ça une propriétarisation? Est-ce que c'est de leur faute si personne d'autre ne veut participer à ce projet, ou si tous ceux qui contribuent finissent par se faire embaucher chez eux?
[^] # Re: Effet de mode?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ARM vs Intel. Évalué à 8.
Faisons le point là-dessus.
D'abord sur OABI, EABI, EABI-hf: ce sont des ABIs, il y a exactement le même problème sur x86 selon qu'on utilise un compilateur Visual Studio ou un gcc, par exemple. Le CPU n'est pas directement concerné, sauf pour EABI-hf, qui se permet d'utiliser les registres des unités à virgule flottante directement (il faut que ces registres soient donc présents). Il me semble que maintenant tout le monde fait de l'EABI-hf, ce problème est donc largement réglé (sauf pour les gens qui font de l'embarqué avec des CPUs qui n'ont pas de FPU, mais ce n'est pas la question ici). Ce serait donc comme se plaindre qu'il y a des problèmes sur x86 quand on veut écrire du code qui tourne aussi bien sur un 486 que sur le dernier Core i7.
Ensuite sur la détection du matériel: ARM est effectivement uniquement une architecture CPU (comme x86), pas une architecture de machine (comme le "compatible PC"). Donc, c'est fourni sans BIOS ou UEFI, et surtout sans bus permettant d'énumérer les périphériques et de découvrir le matériel présent (sur un PC ce rôle est rempli en partie par le BIOS, et en partie par le bus PCI).
Enfin sur les versions de l'architecture matérielle: oui, il y en a plusieurs. Mais ça n'a dérangé personne de voir apparaître de nouvelles instructions (MMX, SSE, SSE2, …) sur les processeurs x86. Ni de voir AMD développer son propre jeu d'instruction concurrent (3DNow!) ou décider de faire une version 64 bits (que Intel a ensuite cloné). Pourquoi chez ARM soudainement ça serait un problème? Il est normal qu'une architecture de CPU évolue à chaque génération.
Cependant, les choses avancent. Du côté de ARM, tout un tas de choses qui ne sont pas purement du CPU sont standardisées petit à petit: la MMU, un timer qui déclenche une interruption à intervalles réguliers, etc. Du côté de Linux, les applications et tout l'userspace fonctionnent sur toutes les machines (c'est la moindre des choses qu'on attend d'un OS: fournir une couche d'abstraction du matériel). Le noyau devrait pouvoir le faire aussi, normalement. Pour cela on a besoin d'un "device tree" qui décrit le matériel (à quelle adresse sont les différents périphériques, la mémoire, etc) et dans le cas de Linux, de drivers intégrés dans le noyau mainline. C'est surtout de ce côté que ça coince: il ne semble pas raisonable pour la plupart des constructeurs de devoir absolument stocker leurs drivers dans le dépôt Git de Linus et de devoir passer toutes les étapes de revue de code (les défenseurs de cette stratégie diront que c'est pour leur bien, que ça augmente la qualité du code et qu'en échange ils assureront la maintenance). Pour l'instant le support des différents systèmes ARM repose donc largement sur la communauté, mais c'est comme ça que Linux a pu se faire une place sur le marché du PC aussi, au moins au début.
Le "compatible Android" a déjà remplacé le "compatible PC" comme standard de machine le plus répandu. Que Linux n'arrive pas encore à s'y adapter, c'est un autre problème.
[^] # Re: iTerm2
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Quel terminal pour 2018 ?. Évalué à 5.
Il y a un standard appelé Sixel. ça date des terminaux VT5xx de chez Dec si je ne dis pas de bêtises. Quelques terminaux le supportent.
Outils et exemples ici: https://github.com/saitoha/libsixel
[^] # Re: pardon mais...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Quel terminal pour 2018 ?. Évalué à 4.
Le problème ce n'est pas vraiment quand tu appuies sur une touche. Si tu fais par exemple un "cat grosfichier", dans la plupart des cas l'affichage sur le terminal va être plus lent que la lecture du fichier depuis le disque.
Dans mon cas, ça peut être avec une suite de tests unitaires qui génère beaucoup de logs dans le terminal, que je ne consulte pas forcément sauf si un test échoue. J'aimerais donc que ça s'affiche très rapidement sans ralentir l'exécution des tests.
[^] # Re: Et plus encore !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Quel terminal pour 2018 ?. Évalué à 2.
Il manque aussi yeahconsole (un autre quake-like), ainsi que pangoterm et x86term, tous les deux basés sur libvterm (http://www.leonerd.org.uk/code/libvterm/).
Et bien sur les vrais terminaux! Chez moi, j'ai un Minitel qui me sert occasionnellement à ça :)
[^] # Re: Une situation généralisée
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un technicien Free a coupé ma fibre optique pour connecter un voisin.. Évalué à 3.
Il y a des partenariats entre les divers relais colis et les transporteurs maintenant. Par exemple il est possible de se faire livrer un colis expédié par FedEx dans un point Mondial Relay.
Ils commencent à comprendre que passer chez les gens pendant les horaires de travail et sans prévenir avant c'est pas franchement utile…
[^] # Re: Vous savez qui paye les titres restau ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal [HS] Tickets restaurants. Évalué à 3.
Mon employeur verse un panier repas équivalent à la part patronale des titres restaurant, dans les cas où le salarié ne peut pas utiliser ces derniers (missions chez un client où il n'y a pas de restaurant à prix raisonnable à proximité). Dans ce cas, l'avantage en nature est préservé.
Je suppose que ça devrait fonctionner aussi si on passe aux titres électroniques et qu'ils sont acceptés nulle part.
[^] # Re: Quels outils ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal On ne contribue pas que du code. Évalué à 3.
Pour la génération des fichiers de traduction, ce sont également des outils développés par Haiku. Il s'aggit de collectcatkeys qui va parser des sources C++ à la recherche d'appels à une famille de macros (B_TRANSLATE) et extraire les chaînes de caractères passées en paramètre.
Pour chaque appel à la macro on peut avoir:
- La chaîne à traduire
- Un "contexte" (qui permet d'avoir la même chaîne avec des traductions différentes, par exemple quand un nom et un verbe sont homonymes en anglais mais pas dans les traductions)
- Un commentaire (qui est là pour informer les traducteurs)
Ces trois informations sont affichées par l'outil de traduction.
Le résultat est un fichier "catkeys" qui contient simplement ces entrées, une par ligne, avec les 3 infos séparées par des tabulations (les chaînes elle-mêmes sont stockées avec les caractères spéciaux échappés comme en C, donc s'il y a une tabulation ou un retour à la ligne dans la chaîne à traduire, il est remplacé par un \t ou un \n).
Ensuite on convertit les fichiers traduits dans un format binaire qui permet un accès plus rapide aux traductions.
Pour les outils de traduction, il y a d'abord eu un premier outil maison (c'était vers 2009 ou 2010), avant le passage à Pootle. Pootle fonctionne bien pour le système, mais nous n'avons pas réussi à y intégrer des applications tierces sous forme de projets indépendants. Pour la version ancienne, c'est en cours de migration!
Un problème de Pootle est qu'il est écrit en Python (si je me souviens bien) et donc en héberger une instance nécessite un serveur qui permet de faire des pages en Python. Ce n'est pas un problème pour le projet Haiku, mais ça l'est pour plusieurs projets de petites applications qui sont hébergées juste sous forme d'un projet github. Et là on a un développeur qui a eu envie de se faire la main sur le développement d'application web, je crois :)
Pour le format d'ICU, je ne sais pas si je peux répondre car je connaît assez mal celui utilisé par gettext. Il y a quelques exemples ici:
http://userguide.icu-project.org/formatparse/messages
En gros, le format est presque un langage de script qui permet au traducteur d'exprimer tout un tas de conditions sur les données à formater. On l'utilise principalement pour gérer correctement le nombre (singulier/pluriel en français, mais c'est plus compliqué dans d'autres langues, comme on peut le voir dans la base de données CLDR.
Comment ça se passe avec gettext pour gérer ce genre de problèmes?
[^] # Re: Oui mais non
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Twitch et copyleft. Évalué à 4.
La version française de la licence: "Faites ce que vous voulez, j'en ai rien à branler." contient bien une clause d'exclusion de garanties (indice: c'est la partie après la virgule). Par contre ça ne semble pas être le cas de la version anglaise.
[^] # Re: Merci pour ce partage - mais la doc fouque
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Publication de bibliothèques c++ sous licence libre. Évalué à 3.
Si ta fonction et tes arguments et leurs types sont nommés correctement, alors tu n'as pas besoin de répéter ces informations évidentes dans un cartouche de documentation.
En exagérant un peu, du code qui a besoin de documentation, c'est du code pas clair et mal écrit. Il vaut mieux passer du temps à nettoyer ton code qu'à le documenter. En suivant ce principe, on devrait pouvoir se faire une idée de l'architecture globale en regardant l'organisation des fichiers, ou les scripts de build.
Maintenant, c'est vrai que ce n'est pas facile d'en arriver là, et donc avoir une documentation peut être pertinent. La rédiger sous forme d'une TODO list (avec la liste de tous les trucs pas clairs) peut être un bon moyen de se souvenir que c'est comme ça qu'elle fonctionne, et que le but du développeur est de faire que la documentation ne soit plus nécessaire, parce que le code parle de lui-même.
[^] # Re: Quels outils ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal On ne contribue pas que du code. Évalué à 6.
Pour Haiku, on utilise:
Je précise que nous avons aussi choisi de ne pas utiliser gettext, nos traductions sont basées sur le support fourni par ICU qui donne pas mal de contrôle au traducteur pour le format des messages, et permet notamment une gestion correcte du pluriel dans toutes les langues (certaines ont des règles complexes ou inhabituelles).
Une conséquence est l'utilisation de notre propre format de fichier pour les traductions. Ce format a été intégré dans Pootle mais à ma connaissance pas dans les autres outils. Nous avons aussi une application native pour traduire ces fichiers, mais l'utilisation d'un outil en ligne et collaboratif est finalement plus conviviale.
Nous avons aussi un ensemble de documents destinés aux traducteurs afin d'aider la coordination, le choix d'un vocabulaire commun, etc: https://dev.haiku-os.org/wiki/i18n
[^] # Re: goodies
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Aider les associations du Libre en achetant leurs goodies. Évalué à 5.
On en a conscience, mais on fait ce qu'on peut avec les contributeurs qu'on a. Plutôt que de pleurer de honte dans ton coin, viens te moquer de nos goodies tous moche, et faire des propositions de nouveaux designs!
Pour un projet libre, c'est déjà difficile de recruter des développeurs, c'est encore plus compliqué de recruter des gens pour faire de la communication, du graphisme, de la comptabilité, de l'administration système, et plein d'autres trucs.
On a essayé de confier quelques tâches "design" aux participants du Google Code-In cette année. La conclusion est que comme on a pas de personne compétente/formée dans le domaine dans notre équipe, on a beaucoup de mal à obtenir des résultats corrects car on ne sait pas dire ce qui ne va pas dans les travaux qui nous sont remis dans ce cadre.
[^] # Re: Éditeur de code sans le code
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal un éditeur de code portable par Microsoft?. Évalué à 5.
Il n'y a pas vraiment de controverse. Simplement, on passe beaucoup de temps dans un éditeur, c'est notre principal outil de travail, après tout. Et c'est bien d'avoir le choix entre différents outils, qui fonctionnent différemment et du coup conviennent aux besoins de chacun. Je suppose que c'est le cas aussi dans la plupart des autres métiers.
[^] # Re: Un peu de documentation sur le sujet
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Misogynie et discrimination à l'embauche. Évalué à 5.
C'est vrai, il y a des sexistes parmi les hackers, et c'est vrai aussi, c'est un (gros) problème. Mais ça m'embête déjà qu'on en fasse une généralité, et encore plus un "ciment" (c'est fort, quand même!). Si on va aussi loin, ça donne l'impression qu'il n'y a plus rien à faire à part détruire les dits groupes (tous les groupes de hackers sont visés sans distinction, du coup).
On peut être un hacker, même en groupe, sans être sexiste.
[^] # Re: Hem...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Misogynie et discrimination à l'embauche. Évalué à 2.
Il n'y a pas de problème dans ton équipe, et c'est très bien. Mais ça ne répond pas à une question, qu'est-ce qu'on fait dans les cas où il y a manifestement un problème et qu'on arrive pas à s'en sortir?
Mettre en place un quota c'est une solution extrême et risquée, mais je ne sais pas s'il y a autre chose qui pourrait fonctionner (à part dissoudre l'équipe et recommencer, et encore).
En tout cas je travaille actuellement dans une équipe qui manque de diversité (pas juste homme/femme, on a aussi presque tous à peu près le même âge, des formations similaires, etc). Qu'est-ce qu'on peut faire pour se mettre un coup de pied aux fesses et essayer d'améliorer ça?
[^] # Re: Impolitesse ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 8.
On va parler de comment ça se passe chez Haiku, tiens.
Nos paquets sont construits automatiquement à partir de recettes qui sont sur un dépôt github. On a un certain nombre de contributeurs actifs sur ce dépôt, mais surtout un tas de gens qui font des pull requests: soit des utilisateurs qui avaient besoin d'utiliser un logiciel et qui ont écrit une recette eux-même, soit de plus en plus, des développeurs upstream qui viennent eux-même mettre à jour nos recettes ou au moins nous ouvrir un ticket quand ils publient une nouvelle version (surtout si elle corrige une faille de sécurité).
En échange, on essaie de penser à faire des patchs propres et à les envoyer à l'upstream, même si on est pas toujours très efficaces ou réactifs (c'est qu'on gère beaucoup de paquets à la fois, quand même).
Pour l'instant ça se passe plutôt bien dans l'ensemble.
[^] # Re: C'est pas trop mal
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Directive sur le droit d'auteur. Évalué à 5.
Sauf que cet article ne vise pas spécifiquement le code source. En fait ils ont plutôt en tête les sites de streaming vidéo, musique, etc. L'incidence sur le logiciel (libre ou pas) est accidentelle, les rédacteurs de l'article n'y ont probablement pas vraiment pensé et oublié que le code des logiciels est soumis lui aussi au droit d'auteur.
C'est pour ça qu'il y a besoin d'un peu de lobbying pour rappeler notre existence et expliquer que ce cas particulier est problématique, afin que la rédaction de l'article soit analysée et si nécessaire modifiée pour pallier le problème.
[^] # Re: C'est pas trop mal
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Directive sur le droit d'auteur. Évalué à 3.
ça va être compliqué de contacter toutes les entreprises de l'univers connu pour leur demander si elles ont un bout de code (ou tout autre oeuvre soumise au droit d'auteur) qu'elles souhaitent voir protégé.
Donc je ne vois pas de solution raisonnable, sauf celle ou c'est le propriétaire des droits qui est à l'initiative de la chose. Par contre, avec cette loi, l'hébergeur sera obligé de mettre en place les moyens nécessaires. En contrepartie, il aura la collaboration du propriétaire des droits de l'oeuvre.
Soyons clairs: cette loi est écrite avec en tête des œuvres dont la gestion des droits est organisée très différemment. L'idée c'est que la SACEM va pouvoir venir mettre son nez chez Deezer, Spotify, Dogmazic ou leurs concurrents et leur demander de vérifier les droits de ce qu'ils diffusent - et va donc devoir leur donner accès à son catalogue pour leur permettre de faire les vérifications. Mais je doute que l'Agence pour la Protection des Programmes en fasse de même avec Github, Gitlab ou Framagit.
[^] # Re: Hem...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Misogynie et discrimination à l'embauche. Évalué à 6.
Tu as raté un virage dans le raisonement.
Si tu fais une équipe avec les gens "qui conviennent parfaitement" uniquement, tu vas construire une monoculture. J'ai vécu ça dans une boîte: tous les employés venaient de la même fac avec le même diplôme avant que j'arrive. Donc oui, ils s'entendaient bien et ils réfléchissaient tous de la même façon. Et ils faisaient des trucs pas du tout efficace sans s'en rendre compte.
Si au contraire tu fais l'effort de sortir de la zone de confort, tu vas enrichir la culture de ton entreprise avec des gens d'horizons différents. Et ils vont t'apporter des trucs que personne n'aurait pu prévoir.
Ce qui est important, c'est d'apporter de la diversité et des points de vue différents.
ça peut marcher tout seul si ton équipe de départ a compris que la diversité était importante et apportait de l'ouverture. Mais si ce n'est pas le cas, il va falloir forcer un peu les choses, et le recours à des "quotas" peut être une solution.
# C'est pas trop mal
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Directive sur le droit d'auteur. Évalué à 9.
J'étais un peu inquiet avec cette affaire, mais en lisant l'article dans le détail:
Du coup, si quelqu'un veut que son code soit protégé, il doit venir demander et doit coopérer pour mettre en place les contrôles.
Je dirais qu'une mesure du genre "demander la licence à la personne qui soumet du code" serait déjà tout à fait appropriée (ce n'est pas le cas sur GitHub par exemple et il y a plein de code sans licence ou avec une licence pas claire) et serait plutôt une bonne chose pour le logiciel libre.
On peut la compléter d'un "si vous voyez du code qui vous appartient, contactez-nous, on vérifie et on le supprime s'il y a lieu" qui me semble assez adapté.
Est-ce que ceci semble approprié et proportionné? Je pense que oui. Si une forge décide d'aller plus loin et de mettre en place un truc chiant, ça va juste faire que ses utilisateurs iront voir ailleurs, non?
# Rapport de bug
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal un éditeur de code portable par Microsoft?. Évalué à 10.
Fais attention, bientôt tu vas te retrouver à envoyer des rapports de bugs à Microsoft, voire même à contribuer à régler le problème (gasp!).
[^] # Re: Quelles sont les fonctionnalités malheureuses, selon vous ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Sortie de LibreOffice 6.0. Évalué à 10.
J'utilise le menu formulaire pour fabriquer… ben des formulaires.
Par exemple, les fiches d'inscription dans une école de musique, que je peux ainsi exporter en formulaires PDF que les adhérents peuvent compléter et renvoyer par mail ou imprimer. Ce qui me permet d'avoir des adresses mails écrites par ordinateur et pas des gribouillages illisibles. Le gain de temps est appréciable et c'est très facile à faire.
C'est la première fois que j'entends dire qu'il y a des fonctionnalités en trop dans LibreOffice.
[^] # Re: Crowdfunding pour Driver VPU
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Free-electrons se fait attaquer en justice par Free, et change de nom. Évalué à 10.
Et ben non, pas sur les puces ARM.
Le VPU c'est une unité utiliser pour décoder de la vidéo. Ce sera utilisé par exemple par ffmpeg ou gstreamer. Rien ne t'oblige à afficher la dite vidéo sur un écran (en passant par le GPU). Tu peux très bien décider de la ré-encoder dans un autre format, de l'envoyer sur le réseau, etc.
Donc le VPU (décodage vidéo) et le GPU (accélération 3D) ne sont pas liés. En plus, sur ce genre de puces le GPU lui-même n'est même pas branché directement à la partie affichage qui gère le framebuffer. Le GPU fait uniquement l'accélération 3D, et fait son rendu dans la RAM (rendu que tu pourrais très bien… envoyer au VPU pour l'encoder, sans jamais l'afficher à l'écran).
Ce sont donc des blocs complètement indépendants.
Sur les architectures x86, le GPU et le VPU sont effectivement souvent regroupés dans la partie "carte graphique", avec une séparation un peu moins claire.