pulkomandy a écrit 2018 commentaires

Et après tu viens nous dire que t'es nul en marketing? ;)

L'article a été écrit dans un état d'esprit basé sur une idéologie libriste, c'est à dire avec pour principe de base que les quatre libertés sont une nécessité, et que l'utilisateur qui le souhaite doit pouvoir faire son informatique avec du logiciel dont il a le contrôle, ce qui est le but du mouvement du logiciel libre.
La phrase rajoutée par les modérateurs met en avant le fait que le logiciel libre soit devenu "un élément majeur de l'informatique moderne", sous-entendant que le but recherché ici serait d'accroître la part de code libre et de licences libres dans le monde informatique en général, et place la communauté du libre comme un acteur économique comme les autres, désirant diffuser ses productions au plus grand nombre et conquérir le monde informatique. Cette vision des choses existe, ce n'est pas celle du mouvement du logiciel libre, c'est celle du mouvement OpenSource, pour qui les quatre libertés sont un bonus, et adopte le point de vue du développeur qui cherche à toucher un maximum de monde, et non de l'utilisateur qui veut garder le contrôle de son informatique.
C'est important de savoir dans quelle idéologie s'inscrit l'article, parce que cela va totalement changer la façon dont on le lit, et la façon dont on le comprend.

Je trouve que la distinction est bien posée entre deux visions, et pour une fois, pour une raison qui me semble valable. Après, on met les mots qu'on veut dessus. Là, personne n'a dit qu'il y avait une opposition irréconciliable entre les deux: juste qu'il y a plusieurs points de vue, des objectifs plus ou moins communs, et des façons différentes de les atteindre.

Donc, il ne s'agit pas forcément de diviser, mais de comprendre qu'il y a des gens et des entreprises qui ont chacun leurs intérêts et leurs compromis. C'est intéressant de voir ce que ça va donner du côté du matériel, où il y a des coûts de fabrication autrement important que pour le logiciel, et donc des gens prêts à payer pour juste la fabrication. Est-ce qu'un écosystème viable peut s'en dégager? Pas sûr: la boîte qui fait toute la conception du matériel sortira forcément un produit plus cher que ses concurrents qui reprennent le design tout prêt pour le mettre en production.

Moi ça m'arrive de temps en temps de jouer du fer à souder.

Et sur une carte mère pas trop mal foutue, remplacer certains composants est même très facile. Par exemple, changer le CPU ou augmenter la quantité de RAM, c'est très facile sur la plupart des machines, même si aujourd'hui on en trouve certaines ou c'est soudé directement sous prétexte de gagner de la place.

Tu as pu faire ce changement logiciel parce que le noyau Linux (je suppose que c'est de lui dont on parle) est libre (et donc tu as accès au code source), mais aussi parce qu'il est conçu de façon un peu modulaire, et qu'il a été possible de trouver le bon fichier où faire le changement.

C'est pareil pour du matériel: si tu as juste une carte mère, tu peux pas faire grand chose sans de gros efforts. Si tu as les schémas et/ou la doc des composants qui sont dessus, tu peux déjà faire certaines modifications "simples". Changer un composant défectueux, ou même pourquoi pas, ajouter un composant sur le SMBus où sont branchés les capteurs de température (c'est 3 fils à souder).

Si tu veux faire des changements plus compliqués, dans les deux cas, tu devras faire de plus gros efforts. Recompiler tout le noyau en modifiant plein de fichiers d'un côté, et peut-être refaire une carte électronique complète de l'autre dans les cas les plus désespérés. Mais patcher du hardware pour un petit défaut de conception, c'est possible.

Et ça, c'est sans même parler des firmwares, ou, plus bas niveau, des bitstreams utilisés pour programmer des CPLD ou des FPGAs, qui pourraient très bien être remplacés sans sortir le fer à souder. Plus le matériel devient compliqué, plus il y a de morceaux qui sont en fait "logiciels". Tout simplement parce que personne, personne ne peut faire du hardware "tout en dur" qui marche du premier coup pour les trucs compliqués.

Je pense que la réflexion autour de l'OpenHardWare est en effet assez difficile à trancher car la la complexité des architecture et leur évanescence fait que même une carte dont on disposerait de toutes les sources ne serait pas forcément hackable si un composant majeur tombait en panne et que le design pas forcément simplement modifiable en cas de rupture de stock d'un composant. Le travail d'ingénierie pour concevoir un monde OpenHardWare est énorme et bien plus compliqué que son homologue logiciel.

Genre, le logiciel, c'est simple?

On peut aussi écrire du logiciel libre mais très chiant à modifier, si on veut. Ou alors, on peut faire une architecture modulaire, du code bien documenté, et donc un truc facile à maintenir et à faire évoluer. On peut aussi écrire un logiciel, le publier avec une licence libre, et ne jamais faire aucun support.

C'est tout pareil avec le matériel. Alors oui, il se rajoute le problème que fondre un ASIC ou fabriquer un PCB avec 6 couches de pistes, ça coûte des sous et on peut difficilement le faire chez soi dans son garage. Mais bon, est-ce qu'il y a beaucoup de gens qui compilent tous leurs logiciels chez eux? La plupart utilisent une distribution Linux ou BSD avec des trucs déjà empaquetés et ne vont pas forcément voir les sources.

Il me semble que le "Hello (again)" de l'iMac est déjà une référence à une campagne de pub pour l'Apple III Plus, lancé après plein de problèmes matériels sur l'Apple III. Mais maintenant que Apple a réutilisé le nom pour sa conférence, cela m'empêche de retrouver une source dans mon moteur de recherche…

Est-ce que quelqu'un a essayer de le compiler depuis les sources? Quelles sont les dépendances? J'ai regardé le code rapidement et j'ai vu du Qt. Est-ce que tout est en Qt natif, ou bien est-ce qu'il y a besoin d'une QtWebView ou un trc du genre? Dans ce dernier cas, est-ce qu'il faut absolument celle basée sur Blink, ou est-ce que QtWebKit fonctionne aussi?

(ça m'intéresse pour tenter un portage sous Haiku, qui dispose de QtWebKit mais pas encore de Blink).

Et il est en GTK surtout parce qu'il y a GTK-DirectFB, ce qui permet à l'installeur graphique de ne pas avoir besoin de X11/Wayland/Mir. Il n'y a à ma connaissance pas d'équivalent pour Qt.

Cela peut être intéressant pour d'autres projets aussi, pourquoi juste le noyau?

Il faut bien comprendre que XML, c'est pas juste des tags et des balises. C'est aussi XML-Schema (qui définit la structure du contenu du fichier), xpath (qui permet de rechercher des infos dans un contenu XML), xslt (qui permet de transformer un XML sans tout casser).

Si tous les outils qui vont avec XML sont bien utilisés, alors oui, il est possible de manipuler un document sans comprendre tout le contenu.

Après, si on se contente du premier niveau (la syntaxe XML avec des nœuds et des attributs), c'est sur que ça va être plus compliqué de faire un truc qui marche.

Je ne suis pas d'accord avec le fait de n'avoir que des +1 (on est pas chez les bisounours).

Il ne faut pas prendre les choses personnellement, les gens votent +1 ou -1 pour n'importe quelles raisons, bonnes ou mauvaises, mais, en général, ce n'est pas contre les gens. Si ça te dérange, il doit bien y avoir un moyen de cacher ces scores?

L'idée d'avoir plus de choix (pertinent, inutile, trollesque, incompréhensible, etc) est intéressante. ça donnerait un peu de nuances. Cependant, c'est aussi moins évident de calculer un score "global" pour le commentaire, ce qui est quand même l'intérêt du truc, au départ. à moins d'avoir plusieurs scores (pertinence, trollitude, clarté, ?) et des seuils réglables pour chaque?

Je n'ai pas l'impression que ça soit forcément critiqué, du moment que c'est écrit "journal bookmark" dessus et qu'on sait à quoi s'attendre?

Ce qui est parfois critiqué, c'est le journal de 12 pages qui en fait n'apporte pas plus d'infos et qui aurait pu être un journal bookmark de 2 lignes.

ça c'est parce que tu n'as jamais utilisé un périphérique de pointage pas précis :)

S'il faut 1 seconde pour arriver à viser un bouton ou sélectionner du texte, ça devient rapidement très pénible. Pour s'en rendre compte, il suffit de prendre n'importe quel smartphone et d'essayer de naviguer sur un site pas conçu pour les mobiles, avec plein de petits boutons. C'est de ce genre de problème qu'on parle.

Pour la souris, les choses sont en général assez bien faites, et c'est plus subtil qu'il n'y paraît (courbes d'accélération, vitesse max, gérées à la fois par le capteur optique et l'électronique de la souris, et par le logiciel sur le pc).

J'arrive très bien à utiliser un trackpoint sans avoir besoin d'une souris. ça demande un peu d'habitude, mais maintenant j'ai beaucoup de mal quand je n'ai droit qu'à un trackpad… (les souris ça va, j'y arrive encore).

Mais dans le cas contraire, t'es bon pour avoir des reproches dans tous les sens.

Y'a que ceux qui font rien qui se trompent jamais /o\

(donc, au lieu de faire des reproches, ils feraient mieux de contribuer aux dépêches avant qu'elles ne soient publiées. Pour les journaux, par contre, on peut pas faire grand chose).

Pour l'USB3, ces machines ont un port ExpressCard, qui permet d'ajouter une carte USB3 connectée directement au bus PCI. Un truc dans ce genre: http://www.ldlc.com/fiche/PB00110523.html (pas testé ce modèle en particulier!). C'est donc aussi bien qu'un contrôleur USB3 intégré sur la carte mère, et surtout c'est réutilisable même si on change l'ordinateur qu'il y a autour (tant qu'il reste des ports ExpressCard, en tout cas…)

ça m'est arrivé quelques fois de devoir suivre ce genre de vidéo, je n'ai pas trouvé ça très pratique. La vidéo va soit trop vite, soit trop lentement, et du coup, il faut mettre en pause ou attendre que ça avance dans la vidéo.

Je préfère largement du texte. Et en plus, pas besoin de sortir les écouteurs pour avoir le son.

Personnellement, je trouve pas ça terrible. On est pas là pour compter les points et savoir qui contribue le plus.

Et puis, pourquoi les dépêches sur le noyau seraient spéciales? Certes, ce sont des dépêches intéressantes et de qualité, mais c'est peut-être juste parce qu'il n'y a pas assez de monde qui contribue aux autres dépêches? (et puis, n'étant pas utilisateur du noyau Linux, ce ne sont pas forcément les plus pertinentes pour moi). Je vais aller voter pour un renommage en LibreFr.org, donc!

Niveau mal au bras après utilisation intensive, je pense que c'est le seul truc avec les écrans tactiles, qui fait pire qu'une souris.
D'ailleurs, même Thomson a fini par proposer une souris sur ses machines un petit peu plus récentes (le TO8 et le TO9).

Tu peux prendre les 4 ou 5 mots du générateur et fabriquer une phrase en français avec, en les mettant dans un ordre qui marche bien, conjuguant les verbes, at ajoutant ponctuations, articles et conjonctions. Je ne pense pas que ça détruise trop l'entropie (on en perd un peu en mettant les mots un peu tout le temps dans le même ordre, mais on doit pouvoir la récupérer en ajoutant les autres trucs)

Seiko-Epson est Japonais, aussi!

Je n'en suis pas forcément surpris. Ceux qui ont essayé de créer leur entreprise et de la faire tourner tous les jours se rendront bien compte que finalement, on ne peut que difficilement faire ça, et à la fois continuer à écrire du code (tant mieux pour ceux qui y arrivent tout de même). Du coup, un entrepreneur du libre, c'est effectivement, d'abord et avant tout, un entrepreneur.

le mangling, c'est juste le premier truc qui se voit et qui empêche que ça marche. Si tes compialteurs ont le même mangling (comme en C, vu que c'est souvent juste "on met le nom de la fonction dans le symbole", avec éventuellement un underscore en préfixe), tu peux avoir aussi des problèmes beaucoup plus chiants à débugger, quelques exemples au hasard:
- Les deux compilateurs ne mettent pas les arguments sur la stack dans le même ordre
- Les long int ne font pas la même taille
- Un des deux compilateurs choisit de passer des paramètres via des registres, l'autre non (ou pas les mêmes paramètres dans les mêmes registres)
- La gestion des varargs est différente
- …

Donc, mélanger les compilateurs, même si on fait du C ou du "struct&pointers", c'est dangereux. Sauf s'il y a une ABI définie pour la plateforme qui précise tout ça (et pas juste le mangling). Et quand il n'y a pas d'ABI standard, finalement, il vaut peut être mieux que le mangling soit différent, au moins, on voit le problème à l'édition de liens (ou lors du chargement du plugin) et pas à l'exécution (on fait pas du Python, ici ;)).

Je ne vois pas bien l'intérêt d'une ABI universelle standardisée. ça n'est d'ailleurs pas le cas pour le C.

L'ABI comprend par exemple:
- La façon dont les noms de fonctions/méthodes sont traduits en noms de symboles (mangling, en C++), et les cas dans lesquels il peut y avoir des conflits,
- La façon dont les paramètres d'une fonction sont passés,
- Les règles d'alignement des membres d'une structure.

Si on peut arriver à utiliser le même mangling partout pour le 1er point, les autres sont très liés à l'architecture matérielle et aux possibilités du CPU utilisé. Les paramètres d'une fonction peuvent être passés dans des registres ou sur la pile. En commençant par celui de droite ou celui de gauche. En faisant éventuellement les choses différemment selon la taille des paramètres, ou même selon leur type (par exemple sur un motorola 68000, il y a des registrer pour stocker des entiers, et d'autres pour stocker des pointeurs).

Donc, on ne peut pas demander mieux que d'avoir une ABI par famille de CPUs. ARM en fournit une, avec des variantes en fonction de l'OS utilisé. Sur x86, il n'y en a pas et c'est laissé au choix de l'OS et du compilateur.

En fait, les problèmes arrivent surtout quand il y a plusieurs ABI "plus ou moins" compatibles. C'est le cas en C++ sous Windows, par exemple, ou on peut lier des dll compilées avec différents compilateurs, et tout marchera bien, sauf les exceptions.

Je trouve ça bizarre qu'on fasse du logiciel libre sans se préoccuper de comment il est distribué (sauf si on utilise la licence WTFPL, bien sûr). C'est quand même la base du logiciel libre, de pouvoir distribuer les choses. Est-ce qu'il est nécessaire/utile/constructif de sous-traiter ça aux responsables de paquets des différentes distributions? C'est un peu la solution de facilité, non?

Merci pour ces exemples.

Je prend le cas du système d'exploitation pour deux raisons, d'abord parce que je le connaît bien, et d'autre part parce que ça couvre déjà pas mal de choses: noyau, drivers, librairies, applications.

Mais on est d'accord, j'ai une vue très "système" sur les choses, et c'est ça qui fait de C++ un bon choix pour moi. Certainement pas un langage universel.

Pour la transpilation, ça ne me paraît pas être un problème (pas plus que la compilation). Mes interrogations portent sur le langage, plutôt que sur la façon dont il est exécuté. Par exemple, pour faire de la programmation système en Java, il y a plein de problèmes lié au langage lui-même. Au hasard, pas de pointeurs et donc pas de moyen d'accéder directement à une adresse mémoire, donc pas possible d'écrire un driver; le langage a besoin d'un garbage collector qui peut difficilement être écrit en Java, etc.

Cela dit, il y a d'autres raisons qui font que la transpilation rend les choses pénibles: c'est chiant à debugger, c'est moins pratique pour développer les choses, etc. Et donc, on a bien besoin d'un ou plusieurs langages complémentaires pour ces cas là, merci pour les exemples!