Constructeur et vendeur de materiel non-libre

Ce que je propose c'est que le constructeur/vendeur respecte au moin que le code de sont matériel (firmware) respecte les 4 règles édicter par RMS.

Après je ne sais pas si le faite de demander un support pour divers OS soit dans la philosophie du mouvement du libre.
Ce que j'ai compris c'est surtout qu'on ai le droit de le lire, modifier, copier, redistribuer du code bref de ne pas être restreint.

Je pense que le support de l'os entre dans le droit du consommateur, non ?

Personnellement je préfère avoir les sources des firmwares que d'avoir juste un drivers fermer.

Ce serait un plus que les constructeurs fasse des drivers pour chaque OS existant (c'est ce qu'ils aurait du faire depuis le débuts)

Cela éviterez que les retro ingénieur ne se casse la têtes sur du matériel qui devrais être libre.

Le lien poster ce ne sont pas les mêmes que ce lien ?:
http://non.aux.racketiciels.info/petition/

Après en matériel avec source ouvert je connais ça:
https://www.olimex.com/Products/OLinuXino/open-source-hardware
C'est pas libre mais open sources au moins ce n'est pas fermer.

Je réalise maintenant que ton outil serait parfait au sein de h-node. Je ne pense pas que ce soit une bonne idée de créer encore un nouveau site répertoriant du matériel : h-node a maintenant une base de donnée conséquente, a acquis une certaine notoriété et est véritablement orienté "logiciel libre" (et non "compatibilité Linux", blobs inclus).

À ta place je contacterai donc les gens derrière h-node et verrai avec eux comment réaliser ce travail. J'imagine un lien à cliquer sur la page qui se réfère à un matériel spécifique et qui mènerai à une fenêtre de texte contenant un courrier type (à personnaliser) qui référence le matériel en question et un bouton pour envoyer le courrier.

'man lsmod' t'apprend que 'lsmod' ne fait que formater le contenu de /proc/modules (d'une façon qui t'ennuie plus qu'elle ne t'aide). Un "while read" te permet d'itérer sur les lignes de ce fichier et de mettre le premier champs dans une variable séparée (ici "modulename") :
while read modulename rest
do
modinfo $modulename
done < /proc/modules

Une autre solution, plus proche de ce que tu as fait, en utilisant une boucle "for" :
for modulename in $(cut -d ' ' -f 1 /proc/modules)
do
modinfo $modulename
done

Sauf qu'il n'y a même pas besoin de boucle parce que 'modinfo' peut prendre plusieurs noms de module en argument :
modinfo $(cut -d ' ' -f 1 /proc/modules)

Mais, franchement, h-node doit déjà avoir des scripts bien plus sophistiqués.

'man lsmod' t'apprend que 'lsmod' ne fait que formater le contenu de
/proc/modules (d'une façon qui t'ennuie plus qu'elle ne t'aide). Un "while
read" te permet d'itérer sur les lignes de ce fichier et de mettre le
premier champs dans une variable séparée (ici "modulename") :
while read modulename rest
do
modinfo $modulename
done < /proc/modules

Mais, franchement, h-node doit déjà avoir des scripts bien plus
sophistiqués.

Bash s'installe sur à peu près n'importe quel système inspiré d'UNIX... mais n'est pas nécessairement installé par défaut. La plupart des shells implémente la norme POSIX. Vois https://en.wikipedia.org/wiki/Unix_shell

Dash est un petit shell léger et rapide. Contrairement à bash et ses bashisms (c'est à dire des directives pratiques mais pas dans la norme et donc pas forcément comprises par un autre shell), dash satisfait tout juste la norme POSIX. Par conséquent, si il exécute ton script, alors il y a de grande chance pour qu'il soit conforme à cette norme et qu'il soit donc correctement exécuté par ksh, bash, zsh, etc.

Bash est lent à l'exécution, oui. Voilà même la première phrase de la section "BUGS" de 'man bash' :
It's too big and too slow.

En fait, dash a été créé par Debian pour que son init soit plus rapide. Maintenant que les scripts Shell d'initialisation vont être remplacés par de petits fichiers descriptifs (merci systemd), cette raison n'aura plus lieu d'être. Néanmoins, dash demeure plus rapide que bash. Ceci étant, si le temps d'exécution est dominé par l'exécution des commandes appelées, alors les performances du shell n'importent pas.

AWK est un super langage lorsqu'il s'agit de traiter linéairement du texte. AWK est aussi normé dans POSIX... et GNU AWK va, comme bash, au delà de la norme. Donc, la aussi, tu risques de ne pas être portable. D'ailleurs, Ubuntu et Trisquel ne viennent pas avec gawk par défaut mais avec mawk qui est plus minimaliste et plus rapide. C'est exactement le même discours que pour bash vs. dash.

Remarque que bash et gawk acceptent tous deux une option --posix qui retire les fonctionnalités non présente dans la norme. Il est donc tout à fait possible de travailler avec ces outils pour écrire des scripts portables.

À propos de ton script :

• Je n'enregistrerais que ce qui est utile (mais enregistrerais quelque part la version du script, histoire de savoir comment traiter la sortie d'un script qui aura évolué) : je doute que tu ais besoin d'appeler 'lspci' avec autre chose que "-vmm" ou qu'il te soit utile d'avoir la sortie de 'dmesg';
• J'éviterais de créer des fichiers dont l'information est déjà présente dans un autre fichier : une fois que tu as enregistré toute la sortie de 'dmidecode' ou de 'lsmod', pourquoi rappeler ces commandes ?, pourquoi ne pas appeler 'lspci' et 'lsusb' seulement de la façon la plus "verbeuse" ?;
• Pour des raisons plus esthétique qu'autre chose, j'éviterais d'exécuter plusieurs commandes quand une seule fait l'affaire : 'mkdir -p $out/xorg $out/module_info' ou 'cp -r /etc/X11 /usr/share/X11/xorg.conf.d xorg' par exemple;
• Puisque tu souhaites recevoir les fichiers créés par des utilisateurs sur toute la planète, tu veux probablement définir LC_ALL=C au début du script, sinon tu vas te retrouver avec des fichiers dans toutes les langues !

Bash s'installe sur à peu près n'importe quel système inspiré d'UNIX...
mais n'est pas nécessairement installé par défaut. La plupart des shells
implémente la norme POSIX. Vois https://en.wikipedia.org/wiki/Unix_shell

Dash est un petit shell léger et rapide. Contrairement à bash et ses
bashisms (c'est à dire des directives pratiques mais pas dans la norme et
donc pas forcément comprises par un autre shell), dash satisfait tout juste
la norme POSIX. Par conséquent, si il exécute ton script, alors il y a de
grande chance pour qu'il soit conforme à cette norme et qu'il soit donc
correctement exécuté par ksh, bash, zsh, etc.

Bash est lent à l'exécution, oui. Voilà même la première phrase de la
section "BUGS" de 'man bash' :
It's too big and too slow.

En fait, dash a été créé par Debian pour que son init soit plus rapide.
Maintenant que les scripts Shell d'initialisation vont être remplacés par
de petits fichiers descriptifs (merci systemd), cette raison n'aura plus lieu
d'être. Néanmoins, dash demeure plus rapide que bash. Ceci étant, si le
temps d'exécution est dominé par l'exécution des commandes appelées,
alors les performances du shell n'importent pas.

AWK est un super langage lorsqu'il s'agit de traiter linéairement du texte.
AWK est aussi normé dans POSIX... et GNU AWK va, comme bash, au delà de la
norme. Donc, la aussi, tu risques de ne pas être portable. D'ailleurs,
Ubuntu et Trisquel ne viennent pas avec gawk par défaut mais avec mawk qui
est plus minimaliste et plus rapide. C'est exactement le même discours que
pour bash vs. dash.

Remarque que bash et gawk acceptent tous deux une option --posix qui retire
les fonctionnalités non présente dans la norme. Il est donc tout à fait
possible de travailler avec ces outils pour écrire des scripts portables.

Quatre conseils basiques :

N'enregistre que ce qui est utile : je doute que tu ais besoin d'appeler
'lspci' avec autre chose que "-vmm" ou qu'il te soit utile d'avoir la sortie
de 'dmesg';
Évite de créer des fichiers dont l'information est déjà présente dans un
autre fichier : une fois que tu as enregistrée toute la sortie de
'dmidecode' ou de 'lsmod', pourquoi rappeler ces commandes ?, pourquoi ne pas
appeler 'lspci' et 'lsusb' seulement de la façon la plus "verbeuse" ?;
Évite de lancer plusieurs commandes quand une seule fait l'affaire : 'mkdir
-p $out/xorg $out/module_info' ou 'cp -r /etc/X11 /usr/share/X11/xorg.conf.d
xorg' par exemple;
Puisque tu souhaites recevoir les fichiers créés par des utilisateurs sur
toute la planète, tu veux probablement définir LC_ALL=C au début du
script, sinon tu vas te retrouver avec des fichiers dans toutes les langues !