pulkomandy a écrit 2019 commentaires

Doxygen ce n'est pas de la magie.

Faire une documentation de qualité, c'est un métier et ça demande d'y passer du temps.

En fait, Doxygen peut même être nuisible pour ce genre de choses. L'idée est de mettre la documentation et le code dans le même fichier, en se disant que comme ça les gens vont peut-être mieux arriver à garder les deux synchronisés. Mais l'inconvénient, c'est que ça conduit souvent à une documentation qui est seulement une paraphrase du code: on va sagement mettre un gros commentaire Doxygen au début de chaque fonction et bêtement répéter ce que fait le code dedans. ça n'a aucun intérêt. Une documentation est utile quand elle arrive à prendre de la hauteur et à décrire l'architecture sans trop rentrer dans les détails.

Il y a des cas ou Doxygen marche plutôt bien, par exemple pour documenter les APIs d'un module. Il est possible de l'utiliser pour faire une documentation d'architecture complète, mais ça reste beaucoup de travail. Et surtout, c'est pénible de devoir inclure toute cette documentation dans les fichiers source, dont ça encombre la lecture. J'ai en tête un projet qui a trouvé une solution en mettant les commentaires Doxygen dans des fichiers séparés du code source pour éviter ce problème. Mais du coup, Doxygen n'a plus grand intérêt, si ce n'est de parser les fichiers .h du projet pour vérifier que les APIs documentées sont bien celles qui sont implémentées.

J'ai lu quelque part des arguments contre la publication complète des jeux de données et du code utilisé sous licence libre, qui m'on paru plus ou moins pertinents.

En gros, ne pas publier ces outils forcerait les gens à refaire l'expérience de leur côté, et permettrait de s'assurer qu'elle est reproductible et qu'ils ne trouvent pas des résultats différents. Il serait gênant d'avoir un résultat faux à cause d'un bug, et que personne ne s'en aperçoive tant que tout le monde utilise le même code et les mêmes données.

Des idées sur quoi faire pour éviter ce problème?

Je sais pas, le ";-)" à la fin du commentaire par exemple?

Cela dit on va apprendre plein de choses sur la prononciations de l'anglais, et je remercie les gens qui réagissent toujours sérieusement et avec des faits pour étayer leur propos. J'apprécie souvent les discussions (parfois hors-sujet, mais c'est pas grave) qui en résultent.

J'aime bien l'analogie avec un bâtiment, ça semble en effet plus proche de ce qu'on devrait faire dans le logiciel.

Le code source, ça serait donc l'équivalent des plans d'architecte.

La grosse différence, c'est que passer du code source au binaire prend au pire quelques heures (sur un très gros projet). Du coup, mettre le truc en production et continuer à faire des changements ensuite ne pose pas de problèmes, on peut facilement générer de nouvelles versions.

Par contre, en faisant ça on peut avoir plein d'autres problèmes (migrations de schémas de bases de données, ce genre de choses).

Mais pour revenir à l'exemple de la construction d'un aéroport qui a été mentionné plus haut: je ne crois pas que l'architecte se lance tête baissée dans la réalisation des plans. Je ne crois pas non plus que le plan donne toutes les informations. Par exemple, il n'indiquera pas le nombre de passagers par jour attendus, ce qui est quand même un élément important pour comprendre les choix qui ont été faits. Ou le type d'avions qu'on veut pouvoir accepter (la piste d'atterrissage est trop courte pour un A380: est-ce que c'est un problème?)

Changer ces données en cours de projet et essayer de modifier les plans pour correspondre, c'est pénible et compliqué. Même en ignorant la partie "compilation" ou construction du bâtiment à partir des plans. Au bou d'un moment, l'architecte en a marre que son client change d'avis tout le temps et il n'a pas envie de jeter ses plans et de tout recommencer une 15ème fois. C'est là que la qualité du travail fourni baisse.

Existe-t-il un atelier pour le développement très rapide de plans d'aéroports? Comment fait-il pour prendre en compte toutes les contraintes? (les montagnes ou buildings ou zones résidentielles à proximité, etc). Est-ce que ça marche aussi si on veut construire un port maritime ou une gare? ou un supermarché?

Il a l'air possible d'installer koreader en conservant le Linux fourni par Kobo:
https://github.com/koreader/koreader/wiki/Installation-on-Kobo-devices

J'ai un doute sur la possibilité de remplacer les cahiers.

J'ai un très gros doute sur la possibilité pour une liseuse de survivre dans un cartable d'écolier de façon durable.

J'ai également un Kindle, mais je l'utilise avec des livres que je télécharge ailleurs que chez Amazon, ce qui marche plutôt bien avec le logiciel par défaut sauf pour les fichiers epub. Mais il est très facile d'installer un autre lecteur d'ebooks sur les Kindle (Duokan lite, Koreader, …) ou de faire plein d'autres choses avec (j'ai vu par exemple un Kindle transformé en station météo).

C'est un peu inattendu de la part d'Amazon, mais il y a peu de verrouillage logiciel sur les Kindle. Il est facile de se connecter en ssh ou telnet puis de faire un "/etc/init.d/framework stop" pour se débarasser de leur application et se retrouver avec un système Linux tout à fait normal.

Je monte mon Kindle en mass storage et j'utilise la commande cp. Je ne crois pas avoir rencontré de problèmes avec cette solution. Est-ce que ça a changé sur les modèles plus récents?

Le but d'UML, c'est de fournir un langage. Comme un langage de programmation, en fait. On pourrait donc écrire tout le comportement du logiciel en UML et donner ça à un compilateur qui en ferait un binaire.

L'avantage d'un langage comme UML, c'est qu'il est plus facile à lire que du code en C, par exemple. L'inconvénient, c'est qu'il est beaucoup plus compliqué à compiler et aussi peut-être trop subtil pour certaines choses.

Du coup on se retrouve avec des outils qui font au mieux la moitié du chemin (genre, transformer l'UML en un squelette d'application Java ou C++ qu'il faut compléter à la main) et du coup on ne peut pas automatiser complètement le processus.

Pour moi, la conclusion, c'est qu'on ne peut pas encore fusionner les spécifications et le code qui les implémente. L'un est lisible par les humains, l'autre par les ordinateurs. Et on ne parle pas encore la même langue.

Je peux te faire un retour personnel là dessus. Il y a pour moi un problème principal (dans la façons don't c'est réalisé par chez moi). Si tu es tout seul, en 10 minutes le transport à la demande te dépose à l'arrêt de tramway le plus proche et c'est très pratique. Par contre s'il y a un peu de monde qui a réservé sur le même créneau que toi, c'est parti pour la tournée de tous les villages du canton, qui peut parfois prendre plus d'une heure. Du coup si tu as besoin d'arriver à un horaire précis, tu es obligé de prévoir une heure de marge en cas de période de pointe.

Finalement, je fais le trajet jusqu'à l'arrêt de tramway en vélo. Sauf cas particuliers, du genre je dois aller prendre un train ou un avion et j'ai un gros bagage à transporter (encore que, avec un peu d'habitude ça peut se faire en vélo aussi).

Les banques proposent des prêts "relais" pour ce genre d'opération, ce qui permet d'acheter d'abord, puis de vendre ensuite, sans trop de problèmes financiers.

Ben oui, la pluie ça mouille.

Personellement je fais 15km de vélo pour aller travailler, et je mets à peine plus de temps que mes collègues qui font à peu près le même trajet en voiture. Et oui, il m'arrive d'être trempé quand il y a une averse. Je prévois des vêtements de rechange, et le problème est réglé (sans avoir à construire autoroutes, bretelles de déviation, rond points, tout ça).

Supprimons les patacoufins!

Tiens d'ailleurs, en espagnol, le masculin s'écrit souvent avec une terminaison en o, le féminin en a, et l'écriture inclusive en @ qui est un mélange des deux. Ce qui est un peu moins pénible à lire (mais pas plus simple à prononcer) qu'en français.

On parle de son absence (ou plutôt de l'absence d'un équivalent en français).

Répondre "qu'a-t-on dit?" fait un peu bizarre, mais ça marcherait, non?

Il y a plein d'approches pour faire ce genre de choses.

Dans le cas de KeeperFX, très peu de code en mode réel, puisque Dungeon Keeper utilise (comme la plupart des jeux "DOS" de l'époque) un DOS extender (probablement DOS4GW?) qui permet de travailler en mode protégé (avec des "appels systèmes" qui passent en mode réel pour accéder au DOS là ou c'est nécessaire). Mais tout ça ça commence à être de l'archéologie. Mais je pensais qu'il travaillait plutôt à partir de la version Windows 95?

Même sans les sources, il est peut-être possible de faire quelque chose, même si ce sera plus une réécriture du moteur qu'un portage. Les projets de ce genre ne manquent pas et aujourd'hui on peut jouer à plein de jeux sous Linux grâce à cela (si on possède un CD ou une disquette du jeu avec les données originales, bien sûr).

Au passage je mentionne http://osgameclones.com qui liste les jeux qui sont plus ou moins dans ce cas (certains utilisant les données originales, d'autres ayant déjà remplacé toutes les données en plus du code). Je trouve que la liste est étonnamment longue, ce qui est une bonne chose.

Ben oui, s'il y a une ligne de code avec cette licence dans le projet, il faut appliquer la licence. Par contre tu peux peut-être négocier un prix à la ligne de code avec le vendeur.

La licence est donc incompatible avec la GPL, et en plus, si le code a été touché par une douzaine d'intermédiaires, et qu'ils choisissent tous d'avoir une version commerciale, a priori il faut donc leur acheter une licence à chacun (à moins qu'ils se refacturent les choses entre eux?)

Bref, ça devient très vite très compliqué.

C'est là la vraie différence, en fait: quand j'écris du code et que je le publie (en général sous licence MIT dans mon cas), ça n'est certainement pas pour "lutter contre le copyright" (ou contre quoi que ce soit).

C'est parce que j'utilise tout un tas de logiciels libres (ou juste gratuits, parfois) et que je trouve que la moindre des choses, c'est de donner un truc en retour.

Je ne pense pas que le logiciel libre pourra gagner en se mettant en conflit avec le copyright (sur lequel les licences copyleft posent leurs fondements légaux, de toutes façons). Il pourra peut-être en montrant que ça marche mieux et que ça fait gagner du temps à tout le monde de partager du code.

C'est du singuriel. Si on enlève le genre de la grammaire, y'a pas de raison de distinguer le nombre non plus.

Tu peux essayer d'ajouter un point d'ironie, mais ça ruine un peu l'effet.

https://fr.wikipedia.org/wiki/Point_d'ironie

dans le second tome de son Rapport sur l’exposition de 1839. Industrie française, il publie Des lacunes de la typographie, où il propose plusieurs signes typographiques émotionnels supplémentaires.

C'est un peu l'ancêtre des emojis unicode, en fait. Il est disponible dans les caractères spéciaux de Linuxfr.

Bonus spécial pour celleui qui réussit à écrire une implémentation en C+=, le fork féministe (et parodique -enfin j'espère) de C++:

https://github.com/TheFeministSoftwareFoundation/C-plus-Equality

ça fait assez longtemps que Sony publie les sources de leur noyau adapté pour AOSP (la version libre d'Android) et rend facile le déblocage du bootloader sur leurs téléphones (et même certaines smartwatches).

C'est plutôt bien de leur part et l'une des raisons pour lesquelles j'ai acheté un téléphone de chez eux.

D'après la news, on aura pas beaucoup mieux pour Jolla: uniquement les sources du noyau. De ce que j'ai compris, Sailfish X sera une "ROM" vendue 50 euros.

Par contre, cela veut dire qu'on peut avoir un noyau Linux standard avec les pilotes qui vont bien dedans, et probablement essayer de faire un debootstrap (ou l'équivalent dans votre distro préférée) puis développer une interface utilisateur libre par dessus. Là, c'est aux libristes de prendre les choses en main pour la suite!

Y'a un peu un gros message au dessus du graphique qui dit ceci:

This report contains preview data that has NOT been reviewed by Quality Assurance.

D'autre part, ils n'affichent pas les nombres absolus, seulement des pourcentages. Il se pourrait bien que Linux et Mac ne bougent pas beaucoup, mais que Windows baisse d'un coup (ce serait quand même intéressant de comprendre pourquoi).

Quand tu as une API stable, tu peux au moins essayer de l'utiliser, et de faire ton driver crade comme tu veux de ton côté avec. Si ça marche pas, tu peux alors faire l'effort de faire des changements dans le noyau. Mais ça rend tout de suite clair dans quoi tu te lances: il va falloir récupérer les sources du noyau, le recompiler, faire les changements, puis maintenir ce fork.

ça ne rend pas le code automatiquement de meilleure qualité hein. Mais par contre, ça force les gens à se dire "ouhlà, j'ai franchi la ligne rouge". À mon avis, ça rend juste les choses assez pénibles à faire pour que le dev se pose deux minutes et se demande s'il a pas moyen d'arriver à faire ce qu'il veut avec l'API qu'on lui a donné. Pas parce que c'est plus propre, mais parce que ça l'embête de devoir recompiler le noyau et pas juste son bout de driver.

Dans le fonctionnement actuel, c'est un peu "voilà les sources du noyau, débrouille-toi avec ça". Et c'est considéré normal que chaque pilote écrit aie besoin de réécrire la moitié du noyau (j'ai arrêté de compter combien de fois ils ont changé la stratéglie d'allocation mémoire pour les pilotes graphiques, par exemple).

En ce qui concerne l'unicité du matériel, ARM a fait pas mal de progrès pour tout ce qui est de base. Tu as une MMU standard, ainsi qu'un timer système pour faire tourner un scheduler. Déjà c'est pas mal. Autour de ça, il commence aussi à y avoir des standards de fait sur certains autres points. Par exemple, sur n'importe quelle plateforme ARM tu as toutes les chances de trouver une UART compatible 16C550 (la même qui pilote les ports série sur PC). Après pour les trucs plus avancés, cartes graphiques, etc, oui, c'est pas standard. Sur PC non plus, mais le BIOS dépanne en fournissant au moins un mode texte et du VESA pour pouvoir afficher des pixels sans accélération. Mais c'est pas vraiment là qu'est le gros du travail, en fait.

C'est vrai que c'est plus diversifié que sur l'architecture PC/x86, mais quand même, ça ne me semble pas insurmontable si les choses sont faites un minimum proprement.

L'architecture ARM est un gros merdier alors qu'il domine sur les tablettes et téléphones. Son avantage de son faible coût et de sa faible consommation pour une puissance raisonnable l'ont rendu incontournable. Mais faute de BIOS ou équivalent disponible (l'UEFI arrive petit à petit mais c'est long et pas généralisé sur l'ARM64) rend toutes ces puces légèrement incompatibles avec le voisin avec peu de possibilités simples pour avoir un système unique qui s'adapte à la machine.

Si les PCs avaient connus la même situation, cela aurait été difficile. Imagine s'il fallait une image Linux spéciale pour les HP, Dell, Acer ou autres, voire entre HP avec un Intel i386 et AMD compatible i686. Je doute que Linux en serait là aujourd'hui. Car cela aurait complexifié la venue de contributeurs et d'utilisateurs et les développeurs perdraient du temps à gérer cette situation plutôt que d'ajouter des fonctionnalités intéressantes.

D'autant plus que le problème des téléphones est exacerbé par le fait que les fondeurs de puces type Qualcomm, Broadcom font du mauvais travail. Linux gère leur téléphone mais ce travail est fait à l'arrache faute de temps et de budget. Ce qui fait que le noyau Linux officiel ne peut bénéficier de ces travaux et peut difficilement fonctionner sur ces puces.

Moui… Pour moi c'est plutôt Linux qui a mis beaucoup trop de temps à réagir et à mettre en place les device trees pour les architectures ARM. Résultat, les constructeurs n'ont pas eu trop de choix que de bricoler avec ce qu'ils avaient sous la main.

Le BIOS n'y est pour rien, dans les PC il n'est quasiment pas utilisé par Linux (un peu par GRUB, mais c'est tout) et sur la plupart des machines ARM tu vas trouver un u-boot qui fait tout aussi bien et même mieux dans la plupart des cas (rappelons que le BIOS ça date des années 70, quand même).

La différence avec les PC, c'est la présence du bus PCI qui permet d'énumérer le matériel, et auparavant de l'ISA plug-n-play. Sur ARM, il n'y a pour l'instant (en général - on trouve des machines avec un bus PCI) pas d'équivalent pour ça. Du coup, la solution c'est le device tree, qui décrit le matériel et qui normalement permet d'utiliser le même noyau partout.

L'autre souci, c'est que pour Linux, tous les drivers devraient être intégrés dans le git de Linus Torvalds pour être maintenus. Mais ce n'est pas une approche réaliste pour plein de cas. Du coup, chaque fabricant préfère vivre avec son propre fork du noyau, ce qui coûte moins cher à court et moyen terme (et il y a peu de fabricants qui maintiennent leurs puces sur le long terme - c'est plus simple de les remplacer par des versions plus récentes).

Si Linux avait une API stable pour les drivers et qu'on pouvait les maintenir séparément et indépendamment de la version du noyau, ça serait simple de garder les drivers du fabricant et de mettre à jour le noyau.

Au final, pour un fabricant de puces, ça coûte moins d'effort de faire un truc rapide et pas propre et pas intégrable, et y'a pas vraiment de raison de faire autrement.