L'expérience utilisateur date de la version DOS. On aime ou on aime pas. D'un côté, ça permet de travailler en étant pleinement concentré sur ce qu'on fait et sans interférences. Mais d'un autre, il y a plein de petites choses qui ne marchent pas comme prévu (en particulier tout ce qui tourne autour du presse-papier et de la saisie de texte).
En tout cas ça n'empêcherait pas de moderniser un peu l'interface et au moins d'avoir une police de caractères proportionnelle, qui serait plus agréable.
Je travaille (entre autres) avec Exocet qui tient le blog 16 couleurs. Du coup, GrafX2 a un peu évolué depuis ces articles et les choses sont devenues un peu plus simples pour la gestion des contraintes graphiques (c'est une des nouveautés de la version 2.5).
Mais en effet, l'un des intérêts est de pouvoir travailler directement avec des filtres assez tordus, du genre "une ligne sur deux, il n'y a que 4 couleurs utilisables, et pour les autres lignes, on a 16 couleurs mais les pixels sont deux fois plus larges" (ici par exemple: http://julien-nevo.com/mahjong/ )
Plus généralement, l'idée est de travailler exclusivement avec des images palettisées et donc on va aller plus loin que GIMP sur des traitements assez spécifiques, par exemple éclaircir/assombrir une couleur ne se fait pas du tout de la même façon quand on peut faire du RGB ou quand on doit choisir parmi 16 couleurs seulement. On a donc plusieurs outils pour gérer les couleurs, en les mettant dans un ordre précis, par exemple.
Un autre aspect, c'est l'idée de contrôler individuellement chaque pixel. Les outils par défaut ne font donc pas d'antialiasing, et on a des raccourcis claviers pour se déplacer d'un pixel à l'autre de façon précise (une souris ne permet pas de le faire facilement, à moins de zoomer vraiment beaucoup et du coup de ne plus avoir de vue d'ensemble sur l'image.
Les captures d'écran insérées dans l'article montrent des images qui ont été réalisées avec GrafX2, on peut voir les versions complètes et d'autres images ici ou là. Le style est assez différent de ce qu'on fait avec GIMP, et la façon de travailler aussi.
Je peux comprendre que ça devienne irritant quand on reçoit tout le temps les mêmes critiques, qu'on sait que ça serait bien de changer, mais qu'on ne peut rien faire parce qu'il y a trop d'impacts.
Mais bon, la solution est peut-être d'ajouter une entrée dans la FAQ, dans ce cas. Au moins on a pas besoin de re-rédiger la réponse à chaque fois et on peut pointer les gens sur la réponse existante.
La FSFE, ils sont sympas, et ils ont plein de supports de communication en CC-BY-SA traduits dans plein de langues. Merci à eux pour leur travail :)
Ils sont indépendants de la FSF (comme expliqué ici: https://fsfe.org/about/fsfnetwork.fr.html ) et ils ont également pris soin de préciser qu'ils ont, je cite, "chacun sa propre culture".
Techniquement, il n'y a rien de spécial pour un fax par rapport à un téléphone. Le fax transforme l'image en sons et la transfère sur une ligne de téléphone sans se poser de questions.
Il y a deux problèmes:
- La latence, si le protocole utilisé a besoin d'un acquittement dans un temps réduit.
- Si la ligne téléphonique utilisée compresse le son (avec perte), ça risque de ne pas marcher assez bien pour un fax
Donc, il n'y a pas de garantie sur ces deux points, le fournisseur de la box s'engage à ce que ça fonctionne avec un téléphone et rien d'autre. Mais avec un peu de chance ça pourrait marcher quand même.
C'est assez différent, parce que tu pourras accéder au même contenu, gratuitement, avec Chromium, ou n'importe quel autre navigateur gratuit (dont certains sont, en plus, libres). Pourquoi donc irai-je payer Mozilla pour quelque chose que d'autres font tout aussi bien et gratuitement?
Si c'est juste par militantisme, alors la page de donation existante marche très bien. Et si c'est pour gagner des goodies, non merci, je n'ai pas envie d'accumuler du bazar chez moi et de dépenser des ressources écologiques en fabrication et expédition de trucs qui vont servir… à faire de la pub pour Mozilla. à mes frais, du coup.
Le problème ce n'est pas l'API ou le lien dynamique. Le problème, c'est de distribuer un logiciel comme un ensemble complet et fonctionnel.
Prenons l'exemple d'un livre. On pourrait imaginer que quelqu'un a écrit un chapitre et l'a diffusé sous licence GPL. Toi, tu écris le chapitre suivant, et tu veux diffuser les deux ensemble. Tu auras beau essayer de les imprimer comme deux tomes séparés (c'est l'équivalent du lien dynamique), ça ne change rien: la diffusion de l'ensemble est sous GPL à cause des contraintes sur le premier chapitre. Note que cela concerne uniquement l'ensemble des deux tomes. Si par contre tu vends uniquement le tome 2 séparément, alors il n'y a pas de contamination. Mais les gens ne vont rien comprendre à l'histoire.
Et là où on rentre un peu plus dans l'interprétation, c'est si une boutique met en ligne, séparément, les tomes 1 et 2. On peut se demander si c'est possible d'acheter le tome 2 sans avoir besoin du 1. Même s'ils sont vendus séparément, il est possible que le juge décide que non, le tome 2 n'est pas indépendant, et que par conséquent la "contamination" par la GPL s'applique.
Pour en revenir aux logiciels: tu peux par exemple avoir un logiciel qui utilise des plug-ins entièrement optionnels. Il y a une API entre le logiciel et les plug-ins. Certains plug-ins sont en GPL et d'autres pas. Et même, cette API est standard et plein d'autres logiciels vont utiliser les mêmes plug-ins.
Dans ce cas, il n'y a pas de dépendance ni dans un sens ni dans l'autre entre le code GPL et le reste. Ils sont seulement interopérables. Et ça, ça ne pose pas problème. La technique utilisée est la même (lien dynamique), mais du point de vue de la GPL (et du droit d'auteur) c'est tout à fait différent.
Ce qui définit un travail dérivé dans ton exemple, ce n'est pas l'utilisation de l'API. Si tu as deux bibliothèques qui implémentent la même API et que ton logiciel peut se lier indifféremment avec l'une ou l'autre, alors il constitue vraiment une entité indépendante, et cette API peut être une frontière pour l'application de la GPL. Mais en pratique, tu ne vas pas t'embêter et prendre uniquement la deuxième librairie avec une licence qui te coûtera moins d'aspirine ;)
La question s'est posée pour GCC quand Next a voulu l'utiliser comme base pour faire un compilateur Objective-C sans publier les sources de leur frontend. Ils ont imaginé un truc de ce genre, mais ils n'ont pas trouvé de solution acceptable.
Il faut bien voir que la GPL n'est pas rédigée d'un point de vue technique. La façon dont les différents composants communiquent ne change rien. La question, c'est est-ce qu'il s'agit de deux composants indépendants et donc, est-ce qu'on peut les utiliser l'un sans l'autre. Le mieux pour le prouver étant d'avoir un remplacement du morceau de code en GPL, mais une fois que tu l'as écrit, on voit mal l'intérêt de continuer à intégrer la version GPL de départ avec le reste de ton code :o)
En gros, la chose est laissée à l'appréciation du juge, et les bricolages du genre "je lance un programme et je lis la sortie standard donc ça va y'a pas de problème" vont plutôt passer pour de la mauvaise foi qu'autre chose.
En ce qui me concerne, j'ai décidé que la GPL était trop compliqué, que j'avais autre chose à faire que de me lancer dans des études de droit ou embaucher un juriste pour savoir ce que j'avais le droit de faire avec mon propre code, et maintenant, je publie mon code sous licence MIT autant que possible.
Le problème c'est pas de créer le service, c'est qu'il soit intégré dans la liste des autorités de certification reconnues par les navigateurs web. Distribuer des certificats c'est bien, mais s'ils ne sont reconnus par personne ça ne sert pas à grand chose.
Effectivement, faire signer le même certificat par plusieurs autorités semble être une bonne idée. Comme ça ça fonctionne tant que au moins une d'entre elles est reconnue.
On a des oiseaux migrateurs qui s'en sortent très bien, et qui passent l'hiver dans le sud de la France plutôt que d'aller jusqu'en Afrique maintenant.
On a aussi des rats et des pigeons ramiers qui n'ont aucun problème avec la présence de villes de taille importante.
Donc ça va, il y a bien des espèces qui se déplacent et qui s'adaptent. Pas sûr que l'espèce humaine continue d'en faire partie encore longtemps, par contre.
Je rappelle que le format Office Open XML est standardisé et qu'il y a des normes ECMA et ISO (source: https://fr.wikipedia.org/wiki/Office_Open_XML). En quoi peut-on encore le qualifier de format propriétaire?
Le filtre SPAM partagé je m'en passerais bien. Il met souvent à la poubelle plein de mails qui m'intéressent, et je ne peux pas faire grand chose (je surveille mon dossier spam et je fais le tri à la main, mais je n'ai pas un grand poids par rapport à la quantité d'utilisateurs qui partagent le filtre).
Et surtout, c'est impossible de le désactiver, ce qui fait que je suis obligé de relever mon inbox ET le dossier spam et de faire le tri moi même.
Ah tiens et pendant qu'on parle de BeOS, une source interne me dit que de nombreux devs. de Be sont de nouveaux rassemblés et travaillent actuellement sur Fuchsia.
Du coup, il va falloir suivre le projet avec intérêt, même pour ceux qui n'ont pas envie de le suivre avec bienveillance parce que Google. Faisons au moins en sorte de leur piquer leurs bonnes idées avant qu'il ne soit trop tard :)
C'est rare de ne pas trouver u-boot sur une machine ARM, de nos jours? Alors en effet, il y a souvent un bootloader "stage 1" en dessous. Mais c'est juste un niveau de découpage en plus (ou plus visible) par rapport au x86.
Précisément, l'Académie Française constate et prend en compte les évolutions. Elle n'est pas là pour proposer des réformes ou des changements (et heureusement, le Français n'est pas la Novlangue). Il y a bien eu une réforme en 1990 (qui consistait en gros à rectifier quelques incohérences). On est 30 ans après et y'a encore des gens pour râler sur cette nouvelle orthographe…
Alors j'ai lu l'article "j'ai utilisé l'iPad pro comme machine de dev". En vrai, l'iPad est utilisé comme client SSH et VNC parce qu'il n'y a pas un éditeur de texte potable et que le navigateur web n'a pas de web inspector.
Donc je peux presque écrire le même article, "j'ai utilisé un Minitel comme machine de dev". Et j'ajoute qu'on parle d'un iPad avec un clavier bluetooth, et que du coup, bientôt Apple va nous faire un iPad avec un clavier physique intégré et ça sera une révolution. Mais il faut d'abord attendre que les gens aient oublié ce que c'est qu'un PC portable, je suppose.
Euh… je vois plutôt un Office 365 "dans le cloud" et qui s'utilise depuis n'importe quelle machine pourvu qu'il y aie un navigateur web. Donc au contraire cela permettrait de passer plus facilement d'une plateforme à l'autre sans devoir changer tous ses logiciels.
Qui peut croire qu'il sera possible d'exécuter une déviance libre construite à partir du noyau Fuchsia sur un hardware ultra-propriétaire dont on n'a pas les spécifications ?
Je te pose la même question pour Android, GNU/Linux, Haiku, FreeBSD, ou n'importe quel OS de ton choix.
Le problème n'est peut-être pas du côté des développeurs du système.
Pour Android, il y a le projet Android, et il y a les Google Apps. C'est clairement deux choses séparées, et oui, il est évident que Google a peu d'intérêt à développer le client mail par défaut d'Android et préfère mettre ses efforts sur l'application GMail. Est-ce vraiment surprenant?
Donc pour moi, le problème d'avoir un OS libre, il est déjà réglé. Mais on a raté un truc, c'est d'avoir du matériel sur lequel on peut continuer à lancer cet OS. Je ne pense pas que la faute soit du côté de Google. En ce qui me concerne, le dernier téléphone que j'ai acheté est vendu par un fabricant qui publie au moins les sources de sa version d'Android et propose un autre système (Sailfish). Mais il va falloir continuer à mettre la pression sur les fabricants de matériel et leur expliquer que du matériel où on peut pas lancer le système de notre choix, ça ne nous intéresse pas. Et le fait d'avoir effectivement plusieurs systèmes à lancer (Android, Sailfish et Fuchsia, donc) est plutôt un argument de poids dans ce sens.
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.
[^] # Re: Ca semble vraiment sympa
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche GrafX2 enfin en version 2.5. Évalué à 3.
L'expérience utilisateur date de la version DOS. On aime ou on aime pas. D'un côté, ça permet de travailler en étant pleinement concentré sur ce qu'on fait et sans interférences. Mais d'un autre, il y a plein de petites choses qui ne marchent pas comme prévu (en particulier tout ce qui tourne autour du presse-papier et de la saisie de texte).
En tout cas ça n'empêcherait pas de moderniser un peu l'interface et au moins d'avoir une police de caractères proportionnelle, qui serait plus agréable.
[^] # Re: Sympa !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche GrafX2 enfin en version 2.5. Évalué à 8. Dernière modification le 25 mai 2018 à 12:54.
Je travaille (entre autres) avec Exocet qui tient le blog 16 couleurs. Du coup, GrafX2 a un peu évolué depuis ces articles et les choses sont devenues un peu plus simples pour la gestion des contraintes graphiques (c'est une des nouveautés de la version 2.5).
Mais en effet, l'un des intérêts est de pouvoir travailler directement avec des filtres assez tordus, du genre "une ligne sur deux, il n'y a que 4 couleurs utilisables, et pour les autres lignes, on a 16 couleurs mais les pixels sont deux fois plus larges" (ici par exemple: http://julien-nevo.com/mahjong/ )
Plus généralement, l'idée est de travailler exclusivement avec des images palettisées et donc on va aller plus loin que GIMP sur des traitements assez spécifiques, par exemple éclaircir/assombrir une couleur ne se fait pas du tout de la même façon quand on peut faire du RGB ou quand on doit choisir parmi 16 couleurs seulement. On a donc plusieurs outils pour gérer les couleurs, en les mettant dans un ordre précis, par exemple.
Un autre aspect, c'est l'idée de contrôler individuellement chaque pixel. Les outils par défaut ne font donc pas d'antialiasing, et on a des raccourcis claviers pour se déplacer d'un pixel à l'autre de façon précise (une souris ne permet pas de le faire facilement, à moins de zoomer vraiment beaucoup et du coup de ne plus avoir de vue d'ensemble sur l'image.
Les captures d'écran insérées dans l'article montrent des images qui ont été réalisées avec GrafX2, on peut voir les versions complètes et d'autres images ici ou là. Le style est assez différent de ce qu'on fait avec GIMP, et la façon de travailler aussi.
[^] # Re: Journal ou dépêche
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Les serveurs de clefs incompatibles avec le règlement général sur la protection des données ?. Évalué à 2.
Je peux comprendre que ça devienne irritant quand on reçoit tout le temps les mêmes critiques, qu'on sait que ça serait bien de changer, mais qu'on ne peut rien faire parce qu'il y a trop d'impacts.
Mais bon, la solution est peut-être d'ajouter une entrée dans la FAQ, dans ce cas. Au moins on a pas besoin de re-rédiger la réponse à chaque fois et on peut pointer les gens sur la réponse existante.
# Va voir plutôt la FSFE
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal La FSF n-a-t-elle rien compris au libre ?. Évalué à 9.
La FSFE, ils sont sympas, et ils ont plein de supports de communication en CC-BY-SA traduits dans plein de langues. Merci à eux pour leur travail :)
Ils sont indépendants de la FSF (comme expliqué ici: https://fsfe.org/about/fsfnetwork.fr.html ) et ils ont également pris soin de préciser qu'ils ont, je cite, "chacun sa propre culture".
[^] # Re: Quel est le problème ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Remplacement ligne FAX. Évalué à 7.
Techniquement, il n'y a rien de spécial pour un fax par rapport à un téléphone. Le fax transforme l'image en sons et la transfère sur une ligne de téléphone sans se poser de questions.
Il y a deux problèmes:
- La latence, si le protocole utilisé a besoin d'un acquittement dans un temps réduit.
- Si la ligne téléphonique utilisée compresse le son (avec perte), ça risque de ne pas marcher assez bien pour un fax
Donc, il n'y a pas de garantie sur ces deux points, le fournisseur de la box s'engage à ce que ça fonctionne avec un téléphone et rien d'autre. Mais avec un peu de chance ça pourrait marcher quand même.
[^] # Re: Payer un abonnement
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la publicité dans Firefox (sur un air de déjà vu). Évalué à 6.
C'est assez différent, parce que tu pourras accéder au même contenu, gratuitement, avec Chromium, ou n'importe quel autre navigateur gratuit (dont certains sont, en plus, libres). Pourquoi donc irai-je payer Mozilla pour quelque chose que d'autres font tout aussi bien et gratuitement?
Si c'est juste par militantisme, alors la page de donation existante marche très bien. Et si c'est pour gagner des goodies, non merci, je n'ai pas envie d'accumuler du bazar chez moi et de dépenser des ressources écologiques en fabrication et expédition de trucs qui vont servir… à faire de la pub pour Mozilla. à mes frais, du coup.
[^] # Re: Contacter les auteurs de Geogebra?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Du respect de la licence des logiciels libres : GeoGebra - SimulaMaths. Évalué à 2.
Le problème ce n'est pas l'API ou le lien dynamique. Le problème, c'est de distribuer un logiciel comme un ensemble complet et fonctionnel.
Prenons l'exemple d'un livre. On pourrait imaginer que quelqu'un a écrit un chapitre et l'a diffusé sous licence GPL. Toi, tu écris le chapitre suivant, et tu veux diffuser les deux ensemble. Tu auras beau essayer de les imprimer comme deux tomes séparés (c'est l'équivalent du lien dynamique), ça ne change rien: la diffusion de l'ensemble est sous GPL à cause des contraintes sur le premier chapitre. Note que cela concerne uniquement l'ensemble des deux tomes. Si par contre tu vends uniquement le tome 2 séparément, alors il n'y a pas de contamination. Mais les gens ne vont rien comprendre à l'histoire.
Et là où on rentre un peu plus dans l'interprétation, c'est si une boutique met en ligne, séparément, les tomes 1 et 2. On peut se demander si c'est possible d'acheter le tome 2 sans avoir besoin du 1. Même s'ils sont vendus séparément, il est possible que le juge décide que non, le tome 2 n'est pas indépendant, et que par conséquent la "contamination" par la GPL s'applique.
Pour en revenir aux logiciels: tu peux par exemple avoir un logiciel qui utilise des plug-ins entièrement optionnels. Il y a une API entre le logiciel et les plug-ins. Certains plug-ins sont en GPL et d'autres pas. Et même, cette API est standard et plein d'autres logiciels vont utiliser les mêmes plug-ins.
Dans ce cas, il n'y a pas de dépendance ni dans un sens ni dans l'autre entre le code GPL et le reste. Ils sont seulement interopérables. Et ça, ça ne pose pas problème. La technique utilisée est la même (lien dynamique), mais du point de vue de la GPL (et du droit d'auteur) c'est tout à fait différent.
Ce qui définit un travail dérivé dans ton exemple, ce n'est pas l'utilisation de l'API. Si tu as deux bibliothèques qui implémentent la même API et que ton logiciel peut se lier indifféremment avec l'une ou l'autre, alors il constitue vraiment une entité indépendante, et cette API peut être une frontière pour l'application de la GPL. Mais en pratique, tu ne vas pas t'embêter et prendre uniquement la deuxième librairie avec une licence qui te coûtera moins d'aspirine ;)
[^] # Re: Fichtre un acronyme récursif
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche 2018, curl a vingt ans. Évalué à 3. Dernière modification le 30 avril 2018 à 14:53.
Il n'est pas récursif.
[^] # Re: Contacter les auteurs de Geogebra?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Du respect de la licence des logiciels libres : GeoGebra - SimulaMaths. Évalué à 6.
La question s'est posée pour GCC quand Next a voulu l'utiliser comme base pour faire un compilateur Objective-C sans publier les sources de leur frontend. Ils ont imaginé un truc de ce genre, mais ils n'ont pas trouvé de solution acceptable.
Il faut bien voir que la GPL n'est pas rédigée d'un point de vue technique. La façon dont les différents composants communiquent ne change rien. La question, c'est est-ce qu'il s'agit de deux composants indépendants et donc, est-ce qu'on peut les utiliser l'un sans l'autre. Le mieux pour le prouver étant d'avoir un remplacement du morceau de code en GPL, mais une fois que tu l'as écrit, on voit mal l'intérêt de continuer à intégrer la version GPL de départ avec le reste de ton code :o)
En gros, la chose est laissée à l'appréciation du juge, et les bricolages du genre "je lance un programme et je lis la sortie standard donc ça va y'a pas de problème" vont plutôt passer pour de la mauvaise foi qu'autre chose.
En ce qui me concerne, j'ai décidé que la GPL était trop compliqué, que j'avais autre chose à faire que de me lancer dans des études de droit ou embaucher un juriste pour savoir ce que j'avais le droit de faire avec mon propre code, et maintenant, je publie mon code sous licence MIT autant que possible.
[^] # Re: Mouais
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La croissance phénoménale de Let's Encrypt pourrait poser des problèmes (SPOF). Évalué à 7.
Le problème c'est pas de créer le service, c'est qu'il soit intégré dans la liste des autorités de certification reconnues par les navigateurs web. Distribuer des certificats c'est bien, mais s'ils ne sont reconnus par personne ça ne sert pas à grand chose.
Effectivement, faire signer le même certificat par plusieurs autorités semble être une bonne idée. Comme ça ça fonctionne tant que au moins une d'entre elles est reconnue.
[^] # Re: Un début de travail (mais dans le domaine informatique)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Matériel libre ou s'en approchant. Évalué à 7.
https://fr.wikipedia.org/wiki/The_Toaster_Project
[^] # Re: Nous sauver de l'IoT qui va nous réduire à l'état d'esclave ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 2018, l'année de Linux dans l'embarqué ou de Linux métastasé ?. Évalué à 0.
On a des oiseaux migrateurs qui s'en sortent très bien, et qui passent l'hiver dans le sud de la France plutôt que d'aller jusqu'en Afrique maintenant.
On a aussi des rats et des pigeons ramiers qui n'ont aucun problème avec la présence de villes de taille importante.
Donc ça va, il y a bien des espèces qui se déplacent et qui s'adaptent. Pas sûr que l'espèce humaine continue d'en faire partie encore longtemps, par contre.
[^] # Re: LibreOffice Online est mort
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Sortie de la suite bureautique en ligne ONLYOFFICE en version 5.1. Évalué à 2.
Je rappelle que le format Office Open XML est standardisé et qu'il y a des normes ECMA et ISO (source: https://fr.wikipedia.org/wiki/Office_Open_XML). En quoi peut-on encore le qualifier de format propriétaire?
[^] # Re: Ne pas tirer sur le messager
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Thunderbird, mon premier contact est une déception !. Évalué à 5.
Le filtre SPAM partagé je m'en passerais bien. Il met souvent à la poubelle plein de mails qui m'intéressent, et je ne peux pas faire grand chose (je surveille mon dossier spam et je fais le tri à la main, mais je n'ai pas un grand poids par rapport à la quantité d'utilisateurs qui partagent le filtre).
Et surtout, c'est impossible de le désactiver, ce qui fait que je suis obligé de relever mon inbox ET le dossier spam et de faire le tri moi même.
[^] # Re: Propriétarisation?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Windows bronsonnisé ?. Évalué à 4.
Ah tiens et pendant qu'on parle de BeOS, une source interne me dit que de nombreux devs. de Be sont de nouveaux rassemblés et travaillent actuellement sur Fuchsia.
Du coup, il va falloir suivre le projet avec intérêt, même pour ceux qui n'ont pas envie de le suivre avec bienveillance parce que Google. Faisons au moins en sorte de leur piquer leurs bonnes idées avant qu'il ne soit trop tard :)
[^] # Re: Effet de mode?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ARM vs Intel. Évalué à 1.
C'est rare de ne pas trouver u-boot sur une machine ARM, de nos jours? Alors en effet, il y a souvent un bootloader "stage 1" en dessous. Mais c'est juste un niveau de découpage en plus (ou plus visible) par rapport au x86.
[^] # Re: Genre...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Khaganat, des stands et des avancées. Évalué à 2.
Précisément, l'Académie Française constate et prend en compte les évolutions. Elle n'est pas là pour proposer des réformes ou des changements (et heureusement, le Français n'est pas la Novlangue). Il y a bien eu une réforme en 1990 (qui consistait en gros à rectifier quelques incohérences). On est 30 ans après et y'a encore des gens pour râler sur cette nouvelle orthographe…
[^] # Re: souhaits != réalité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Windows bronsonnisé ?. Évalué à 10.
Alors j'ai lu l'article "j'ai utilisé l'iPad pro comme machine de dev". En vrai, l'iPad est utilisé comme client SSH et VNC parce qu'il n'y a pas un éditeur de texte potable et que le navigateur web n'a pas de web inspector.
Donc je peux presque écrire le même article, "j'ai utilisé un Minitel comme machine de dev". Et j'ajoute qu'on parle d'un iPad avec un clavier bluetooth, et que du coup, bientôt Apple va nous faire un iPad avec un clavier physique intégré et ça sera une révolution. Mais il faut d'abord attendre que les gens aient oublié ce que c'est qu'un PC portable, je suppose.
[^] # Re: Une manière de supprimer la concurrence et l'innovation comme sur tout marché
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Windows bronsonnisé ?. Évalué à 3.
Euh… je vois plutôt un Office 365 "dans le cloud" et qui s'utilise depuis n'importe quelle machine pourvu qu'il y aie un navigateur web. Donc au contraire cela permettrait de passer plus facilement d'une plateforme à l'autre sans devoir changer tous ses logiciels.
[^] # Re: souhaits != réalité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Windows bronsonnisé ?. Évalué à 2.
J'ai envie de répondre "challenge accepted" mais j'ai vraiment pas le temps de me lancer là dedans.
[^] # Re: Propriétarisation?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Windows bronsonnisé ?. Évalué à 5.
Je te pose la même question pour Android, GNU/Linux, Haiku, FreeBSD, ou n'importe quel OS de ton choix.
Le problème n'est peut-être pas du côté des développeurs du système.
Pour Android, il y a le projet Android, et il y a les Google Apps. C'est clairement deux choses séparées, et oui, il est évident que Google a peu d'intérêt à développer le client mail par défaut d'Android et préfère mettre ses efforts sur l'application GMail. Est-ce vraiment surprenant?
Donc pour moi, le problème d'avoir un OS libre, il est déjà réglé. Mais on a raté un truc, c'est d'avoir du matériel sur lequel on peut continuer à lancer cet OS. Je ne pense pas que la faute soit du côté de Google. En ce qui me concerne, le dernier téléphone que j'ai acheté est vendu par un fabricant qui publie au moins les sources de sa version d'Android et propose un autre système (Sailfish). Mais il va falloir continuer à mettre la pression sur les fabricants de matériel et leur expliquer que du matériel où on peut pas lancer le système de notre choix, ça ne nous intéresse pas. Et le fait d'avoir effectivement plusieurs systèmes à lancer (Android, Sailfish et Fuchsia, donc) est plutôt un argument de poids dans ce sens.
[^] # 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.