Merci, en lisant le titre j'allai me dire que bientôt je pourrait acheter du nvidia, mais en fait non c'est une vieille news qui, comme on pouvait s'y attendre à l'époque n'a pas vraiment amélioré le support des carte nvidia, toujours plusieurs pilotes en fonction des cartes, un support limité dans le temps, et des perfs du pilote libre souvent en deçà du proprio, qui lui peut arrêter d'être mis à jour.
Donc je reste sur mes cartes AMD qui fonctionnent parfaitement et durablement sous Linux.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Le seul truc qui change vraiment, c'est que la glu entre le noyau et le code proprio est "libre", ce qui offre un meilleur découplage entre les parties libres et proprio, ce qui permettra de l'avoir dans un module mainline et donc signé par les distros, ce qui facilite l'utilisation de SecureBoot avec les pilotes NVidia.
Les parties "intéressantes" des pilotes restent propriétaires, et les blobs de firmwares sont toujours bien fermés.
Pour diverses raisons, j'ai étudié un peu la structure du code "libre" de nvidia, puis j'ai obtenu de la part d'un ingénieur de cette belle entreprise la confirmation d'une observation que j'ai faite : le code publié est le résultat de la compilation d'un code "inconnu" hébergé en interne chez nvidia. Ce n'est en aucun cas le code sur lequel ils travaillent.
Prenons un cas concrêt : les cartes embarquées Tegra de la génération Thor (pas michel, non). Ces cartes utilisent le pilote openrm, ie le pilote libre, youhou ! Sauf que… quand on regarde, le code diverge massivement du code publié sur Github, au point que je n'ai pas réussi à trouver le moment où le code a divergé.
Donc question philosophique: quand on publie le résultat d'une génération de code, depuis une base propriétaire, ce résultat peut être sous licence libre, mais est-ce vraiment un logiciel libre, peut-on l'étudier, le modifier "sincèrement" ? Joyeux débats de fin d'année à tous !
Pas forcément philosophique : ça peut être une simple question de licence (donc un débat sans fin, mais pour juristes, pas pour philosophes :)). Par exemple la GPL dit « The “source code” for a work means the preferred form of the work for making modifications to it. » (le code source est la forme préférée pour faire des modifications). Donc on ne pourrait pas dire que la version « rot-13 » ou « base64 » ou « gzippée » du code est la forme préférée pour faire des modifications par exemple (quand bien même il y aurait stricte équivalence entre les deux).
Alors juste pour chipoter.
Il n'y a pas de différence entre une version "source code" telle que l'on l'entends et une version « rot-13 » ou « base64 » ou « gzippée »
les 3 dernières propositions sont simplement un détail d'implémentation au niveau de l'encodage, voir du stockage.
Dans tous les cas j'ai besoin d'un logiciel pour pouvoir la lire car je ne sais pas lire directement les cellules magnétiques d'un support de stockage.
Et à ma connaissance, il n'y a pas dans la définition de la GPL (corrigez moi si je me trompe) de spécification sur le format : zcat est un outil de visualisation autant GPL-friendly que nano.
Et pour rot-13 c'est encore plus évident, la table ASCII étant une interprétation des données binaires, il me suffit de définir une table d'interprétation des caractères qui va bien.
making modifications pas visualisation. Si tu édites le flux gzip de tête, oui admettons.
Derrière on voit deux aspects différents :
si toutes les bijections sont équivalentes mathématiquement, il n'en reste pas moins que un "vrai code source" est plus facile à manipuler que le même converti en série de chiffres découpés en ISBN et dont on remplace chaque ISBN par l'intégralité du contenu de l'ouvrage (ou des RFC si tu as peur de ne pas avoir les droits sur tous les ISBN). Techniquement on peut revenir au code initial, mais c'est pénible.
si la transformation n'est pas bijective (perte de commentaires, perte des noms de variables/fonctions, mélange des instructions, etc.), on peut supposer une volonté de dissimulation/verrouillage, justement pour ne pas donner "le vrai code source" (exemple: bytecode Java vs source Java, C++ vs assembleur, JS minifié vs JS, etc.)
Pour les transformations non bijectives, c'est plus clair. Même s'il reste des zones d'ombres, notemment au niveau des commentaires et de la lisibilité.
Pour ce qui est bijectif j'ai tout de même tendance à penser que c'est plus une histoire d'outils. Pour reprendre du gzip, bien sur que je ne lis et n'écrit pas en gzip, mais il y a des tas de logiciels qui me montrent et me permettent d'éditer un fichier texte gzippé (du verbe gzipper…) à la volée. Même si je suis d'accord que c'est un peu nul niveau consommation de ressources.
De toute façon sur quasi nimporte quelle définition même les plus simples, dès qu'on gratte un peu on voit que les bords sont flous.
Alors quand on part sur quelque chose d'aussi complexe qu'une licence libre…
Techniquement on peut revenir au code initial, mais c'est pénible.
Pas nécessairement beaucoup de logiciel libres sont fourni en gzip et il ont même une couche supplémentaire tar derrière. C’est même un flux bien plus simple que d’éparpiller le code source dans pleins de pages HTML, l’autre grande solution est avec une série de patch, compressé par zlib, tu ne peut pas modifié quoi que ce soit sans avoir reconstruit l’arborescence.
Mais c’est pas si pénible. Ce qui est marrant c’est qu’une méthode explicitement validée par la FSF est bien plus pénible : fournir un CD avec le code sous paiement à prix coutant de l’envoi du CD.
# Gagné quoi ?
Posté par Voltairine . Évalué à 10 (+9/-1).
Je ne vois aucun gain. Les pilotes restent sous licence propriétaires.
# 2022
Posté par Axone . Évalué à 10 (+13/-0).
L'article date de mai 2022.
[^] # Re: 2022
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
Titre modifié pour préciser le contexte et indiquer la date (j'ai gardé le « Linus a gagné » initial quoi que j'en pense).
[^] # Re: 2022
Posté par fearan . Évalué à 9 (+6/-0).
Merci, en lisant le titre j'allai me dire que bientôt je pourrait acheter du nvidia, mais en fait non c'est une vieille news qui, comme on pouvait s'y attendre à l'époque n'a pas vraiment amélioré le support des carte nvidia, toujours plusieurs pilotes en fonction des cartes, un support limité dans le temps, et des perfs du pilote libre souvent en deçà du proprio, qui lui peut arrêter d'être mis à jour.
Donc je reste sur mes cartes AMD qui fonctionnent parfaitement et durablement sous Linux.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: 2022
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
la capitalisation de Nvidia: 5 000 milliards de $
2 000 milliards il y a moins de deux ans.
Donc, non, de toute façon, ils ont pas besoin de ton argent.
"Si tous les cons volaient, il ferait nuit" F. Dard
# Déplacement du problème
Posté par cg . Évalué à 6 (+4/-0).
Le seul truc qui change vraiment, c'est que la glu entre le noyau et le code proprio est "libre", ce qui offre un meilleur découplage entre les parties libres et proprio, ce qui permettra de l'avoir dans un module mainline et donc signé par les distros, ce qui facilite l'utilisation de SecureBoot avec les pilotes NVidia.
Les parties "intéressantes" des pilotes restent propriétaires, et les blobs de firmwares sont toujours bien fermés.
# oups
Posté par nomorsad . Évalué à 5 (+4/-0).
Non fausse joie vous pouvez circuler
# Un code généré par un code non libre est-il libre...
Posté par Pinaraf . Évalué à 4 (+2/-0).
Pour diverses raisons, j'ai étudié un peu la structure du code "libre" de nvidia, puis j'ai obtenu de la part d'un ingénieur de cette belle entreprise la confirmation d'une observation que j'ai faite : le code publié est le résultat de la compilation d'un code "inconnu" hébergé en interne chez nvidia. Ce n'est en aucun cas le code sur lequel ils travaillent.
Prenons un cas concrêt : les cartes embarquées Tegra de la génération Thor (pas michel, non). Ces cartes utilisent le pilote openrm, ie le pilote libre, youhou ! Sauf que… quand on regarde, le code diverge massivement du code publié sur Github, au point que je n'ai pas réussi à trouver le moment où le code a divergé.
Donc question philosophique: quand on publie le résultat d'une génération de code, depuis une base propriétaire, ce résultat peut être sous licence libre, mais est-ce vraiment un logiciel libre, peut-on l'étudier, le modifier "sincèrement" ? Joyeux débats de fin d'année à tous !
[^] # Re: Un code généré par un code non libre est-il libre...
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Un élément de réponse : https://forge.chapril.org/tgodefroy/Traduction-en-francais-GPLv3/wiki/Traduction-en-fran%C3%A7ais-de-la-GNU-GPLv3#section1
Adhérer à l'April, ça vous tente ?
[^] # Re: Un code généré par un code non libre est-il libre...
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Pas forcément philosophique : ça peut être une simple question de licence (donc un débat sans fin, mais pour juristes, pas pour philosophes :)). Par exemple la GPL dit « The “source code” for a work means the preferred form of the work for making modifications to it. » (le code source est la forme préférée pour faire des modifications). Donc on ne pourrait pas dire que la version « rot-13 » ou « base64 » ou « gzippée » du code est la forme préférée pour faire des modifications par exemple (quand bien même il y aurait stricte équivalence entre les deux).
[^] # Re: Un code généré par un code non libre est-il libre...
Posté par moi1392 . Évalué à 3 (+1/-0).
Alors juste pour chipoter.
Il n'y a pas de différence entre une version "source code" telle que l'on l'entends et une version « rot-13 » ou « base64 » ou « gzippée »
les 3 dernières propositions sont simplement un détail d'implémentation au niveau de l'encodage, voir du stockage.
Dans tous les cas j'ai besoin d'un logiciel pour pouvoir la lire car je ne sais pas lire directement les cellules magnétiques d'un support de stockage.
Et à ma connaissance, il n'y a pas dans la définition de la GPL (corrigez moi si je me trompe) de spécification sur le format : zcat est un outil de visualisation autant GPL-friendly que nano.
Et pour rot-13 c'est encore plus évident, la table ASCII étant une interprétation des données binaires, il me suffit de définir une table d'interprétation des caractères qui va bien.
[^] # Re: Un code généré par un code non libre est-il libre...
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Alors juste pour surchipoter
making modifications pas visualisation. Si tu édites le flux gzip de tête, oui admettons.
Derrière on voit deux aspects différents :
[^] # Re: Un code généré par un code non libre est-il libre...
Posté par moi1392 . Évalué à 3 (+1/-0).
Pour les transformations non bijectives, c'est plus clair. Même s'il reste des zones d'ombres, notemment au niveau des commentaires et de la lisibilité.
Pour ce qui est bijectif j'ai tout de même tendance à penser que c'est plus une histoire d'outils. Pour reprendre du gzip, bien sur que je ne lis et n'écrit pas en gzip, mais il y a des tas de logiciels qui me montrent et me permettent d'éditer un fichier texte gzippé (du verbe gzipper…) à la volée. Même si je suis d'accord que c'est un peu nul niveau consommation de ressources.
De toute façon sur quasi nimporte quelle définition même les plus simples, dès qu'on gratte un peu on voit que les bords sont flous.
Alors quand on part sur quelque chose d'aussi complexe qu'une licence libre…
Et comme j'avais dit c'était du chipotage ;)
[^] # Re: Un code généré par un code non libre est-il libre...
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Pas nécessairement beaucoup de logiciel libres sont fourni en gzip et il ont même une couche supplémentaire tar derrière. C’est même un flux bien plus simple que d’éparpiller le code source dans pleins de pages HTML, l’autre grande solution est avec une série de patch, compressé par zlib, tu ne peut pas modifié quoi que ce soit sans avoir reconstruit l’arborescence.
Mais c’est pas si pénible. Ce qui est marrant c’est qu’une méthode explicitement validée par la FSF est bien plus pénible : fournir un CD avec le code sous paiement à prix coutant de l’envoi du CD.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.