Un idée me viens en tête, je ne dois certainement pas être le premier à l'avoir, mais je l'expose :
Pour tous les développeurs de kernels libres : linux, variantes BSD, reactos, ... Il y a un problème majeur, la reconnaissance du matériel et surtout du matériel récent par des driver libres.
Pour pouvoir développer ces drivers, ils veulent les specs du matos.
De plus, il est courant de voir des drivers sur disponibles sur certains OS, ne pas être disponibles sur d'autres, la portage n'est pas facile : architecture logicielle différentes, etc. Par exemple les moults driver linux non présent sur OpenBSD ou le driver pour le dernier chipset wifi d'Intel complètement libre et propre sous OpenBSD ce qui n'est pas le cas sous Linux.
La plupart du temps quand un développeur fait un driver, vue qu'il n'a pas les specs, il fait du reverse engineering sur le matériel pour connaître son fonctionnement et pouvoir s'interfacer avec. Il découvre donc les specs au fur et à mesure. Si un dev linux le fait pour le driver Linux, il est certain qu'un dev OpenBSD le refera aussi, pour NetBSD etc. pourquoi ne pas centralisé cet effort
Au final beaucoup de ressources gaspillées à refaire le même travail. Ne serait il pas intéressant de créer un site sur le modèle de wikipedia pour centraliser les specs du matériels, de manière légal, que ce soit les specs découvertes, mais aussi les specs officielles des constructeurs quand ceux-ci sont assez ouverts pour les fournir.
Ainsi les développeurs quelques soit l'OS sur lequel ils développent rempliraient/compléteraient cette base d'information et pourrait ainsi collaborer entre eux sur cette partie là.
Tout le monde y gagnerait non ?
Un peu sur le même principe que : http://wiki.multimedia.cx/index.php?title=Main_Page pour les formats multimédias
Qu'est ce que vous en pensez ? réalisable ? intéressant (des devs kernel dans la salle ?) légal (peut être pas dans tous les pays) de mettre à dispo des specs découvertes" ?
Journal openspec c'est possible ???
9
août
2006
# Bonne idée !
Posté par Ton chat. . Évalué à 1.
[^] # Re: Bonne idée !
Posté par Gluck_ (site web personnel) . Évalué à 6.
Maintenant, si c'est pris en charge par la FSF et que c'est basé dans un pays sympa, pourquoi pas...
[^] # Re: Bonne idée !
Posté par nemrod . Évalué à 2.
1) Une équipe pour le reverse qui documente les spécifications.
2) Une deuxième qui code le driver à partir des specifications produites par la première équipe.
Donc, ce type de site regrouperais les efforts des équipes de reverse (1). On pourrait rester sur de l'intéropérabilité pour le (1) ?. Donc pas de problème au niveau légalité ?
Pour les drivers broadcom le
(1) http://bcm-specs.sipsolutions.net/
(2) http://bcm43xx.berlios.de/
cf wikipedia, technique de la muraille de chine http://en.wikipedia.org/wiki/Chinese_wall#Computer_science (anglais)
[^] # Re: Bonne idée !
Posté par BAud (site web personnel) . Évalué à 7.
Pour ceux qui sont sympathiques, cela ne coûte rien d'ajouter un lien vers les specs existantes.
Pour ceux qui ne sont pas sympathiques, cela peut permettre de montrer que le boulot se fait (difficilement) sans eux ou pas...
Et ça tombe bien, c'est un wiki...
On en avait déjà parlé sur https://linuxfr.org/2006/05/11/20800.html
Autant ne pas refaire une nième initiative séparer et plutôt contribuer à l'existant, non ?
[^] # Re: Bonne idée !
Posté par Bapt (site web personnel) . Évalué à 3.
[^] # Re: Bonne idée !
Posté par BAud (site web personnel) . Évalué à 2.
il sera ensuite temps de regarder l'état des specs disponibles pour les constructeurs récalcitrants... par exemple : http://prism54.org/
# Use the source luke
Posté par chl (site web personnel) . Évalué à 3.
Les kernel hacker (Linux ou BSD) developpent leurs drivers. Je ne pense pas que ca les amuseraient de rediger les specs qu'ils ont eu tant de mal a retrouver par reverse enginering.
Ensuite, si un driver existe sous Linux mais pas pour BSD, un kernel hacker BSD, peut tres bien lire le code Linux en GPL pour en refaire un en BSD. C'est arrivé encore recement pour un driver wifi si je me souviens bien.
Pour l'inverse, un code BSD peut etre inclus dans un code GPL, donc c'est encore plus simple.
[^] # Re: Use the source luke
Posté par Vador Dark (site web personnel) . Évalué à 3.
[^] # Re: Use the source luke
Posté par Bapt (site web personnel) . Évalué à 5.
Mais là je suis d'accord que le hacker linux n'aura pas envie de se faire chier a faire des specs qui ne lui resserviront pas.
En revanche, les architectures kernel sont très différentes entre les différents OS libre, par exemple (je n'y connais rien en hack kernel c'est ce que j'ai cru comprendre, merci de me corriger si j'ai tord :)) les hackers linux sont assez libres pour le devs de drivers réseaux et l'architecture de leur driver, sous les BSD, ce n'est pas la cas, tous les drivers en tout cas sous OpenBSD reprennent la même architecture, imposée par le kernel pour facilité la maintenance et le développement. Cette architecture n'est pas forcément compatible avec celle de linux donc un hacker linux aura certainement beaucoup de difficulté à rééutiliser un driver BSD, d'ailleur il n'y a pas à ma connaissance beaucoup de repompe de code BSD sous linux ces derniers temps en ce qui concerne les drivers.
De plus, par reverse engineering un hacker arrivera a retrouver les specs mais pas toujours de manière complète, elles lui permetteront de faire un driver fonctionnel, mais peut être pas un driver ayant toutes les fonctionnalités offerte par le matos, et un autre hacker d'un autre kernel aura peux être d'autre partie de ces specs, et les complètera, permettant au premier d'enrichir son driver.
De plus, il y a peut être plein de gens qui savent faire du reverse engineering sur du matériel, et donc pondre des specs sans pour autant savoir (avoir envie de) coder des drivers : apparemment l'équipe des drivers broadcom linux fonctionne séparément (comme dit plus haut) avec des spécificateurs et des codeurs. Ca pourrait pas mal faire avancé les choses, moins de reverse pour les hackers, plus de specs.
Enfin a long terme ça peut peut être pousser les constructeurs à déposer leurs specs eux-même sur un tel site (je rêve peut être un peu là :)).
[^] # Re: Use the source luke
Posté par Joc M . Évalué à 2.
Heu... c'est pas justement l'inverse le principe de l'Open Source ? Partager son travail par ce qu'il est pas évident et qu'il peut servir aux autres...
[^] # Re: Use the source luke
Posté par chl (site web personnel) . Évalué à 4.
En developpant un driver et en ouvrant son code, le kernel hacker partage son travail. Mais il n'a pas forcement envie d'ecrire une jolie documentation... D'ailleurs il n'y a pas meilleure documentation qu'un code ! :-)
[^] # Re: Use the source luke
Posté par Joc M . Évalué à 2.
Oui, c'est vrai et on ne peux pas le blamer (je comprend ce que tu veux dire)
Mais il peut aussi vouloir le faire. dans ce cas, le projet de notre ami prend tout son sens car aujourd'hui, si j'ai bien compris (ce que voulait dire l'auteur de ce journal), il n'y a pas grand chose pour le faire si ce n'est que de prendre sa plume et de publier ca sur sa page perso.
> D'ailleurs il n'y a pas meilleure documentation qu'un code
C'est un point de vue. Ce n'est d'ailleurs pas le miens. Je dirais plus que ca dépend de quel type de code. (Typiquement un driver est plutôt "platefrom dependant" et il y a des chances pour que beaucoup de choses soit à refaire et donc à recomprendre).
Je partage par exemple la conclusion de la commision européenne qui juge que le code rendu "publique" par Microsoft ne suffie pas et n'est pas un documentation suffisante pour assurer l'interopérabilité. Et ce malgré le fait que le code de Microsoft était très commenté.
[^] # Re: Use the source luke
Posté par Bapt (site web personnel) . Évalué à 7.
C'est très pratique pour connaitre le matériel supporté : et comment utiliser le driver : http://www.freebsd.org/cgi/man.cgi?query=axe&apropos=0&a(...) par exemple à partir de là j'ai acheté mon adaptateur usb/ethernet sans me poser de question.
Des ajouts sont régulièrement fait au niveau compatibilité du matériel : les scanners usb sont un bon exemple, la chaine d'identification du scanner est rajoutée au driver, et le nom du scanner rajouté au manpage :
http://www.freebsd.org/cgi/man.cgi?query=uscanner&apropo(...)
Très pratique.
Ca ne prend pas beaucoup de temps au dev et ça change la vie des utilisateurs.
De la même manière les interfaces dans le kernel sont documentées pour facilité la vie des développeurs, au sein de manpages, par exemple :
http://www.freebsd.org/cgi/man.cgi?query=usb&sektion=4&a(...)
Un peu de documentation ça ne fait de mal (c'est chiant et rébarbatif), mais c'est important.
Pour revenir au sujet :
Si le mainteneur du driver vient à changé pour des raisons diverses, le suivant sera bien content de trouver les specs, pour pouvoir améliorer le driver, le dev initial a peut être fait un driver qui marche, mais il n'est pas forcément optimum, et du code cochon n'est pas facile à lire, il peut aussi s'être trompé en implémentant certaines parties des spécifications. Bref le code ne reflète pas forcément correctement, ni proprement les specs.
[^] # Re: Use the source luke
Posté par Nicolas Schoonbroodt . Évalué à 8.
Tu mérites des baffes, heureusement qu'il y a le smiley...
# wikihardware.org
Posté par bsheep . Évalué à 2.
Avec un ami on avait l'intention de créer un site à la wikipedia, qui avait pour but de mettre en relation utilisateur et développeur.
A l'époque, en avril, on avait fait des petites réunions, on avait même réservé le nom de domaine wikihardware.org.
Si ca t'intéresse, je te met un compte rendu de réunion (prise de note), sinon le projet est une bonne idée.
On voulait conseiller l'achat de matériel bien supporté, mettre des robots qui scanne automatiquement les site des constructeurs et qui remplissent automatiquement des modèles (ordinateur portables, desktop, ...) en python.
Y a deja le robot pywikipedia pour interargir avec mediawiki.
Voici le lien pour le compte rendu :
http://bsheep.org/wiki-hardware.txt
Si tu veux, on peut te mettre a disposition gracieusement le nom de domaine.
[^] # Re: wikihardware.org
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Le tout ferais un message pour une base de donnée. Le but étant de repérer les config qui marchent toute seul, les éventuels conflit, les périphériques qui changent de puces sans changer de nom, etc...
"La première sécurité est la liberté"
[^] # Re: wikihardware.org
Posté par Sufflope (site web personnel) . Évalué à 1.
[^] # Re: wikihardware.org
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: wikihardware.org
Posté par BAud (site web personnel) . Évalué à 2.
le souci c'est que launchpad n'étant pas diffusé, il n'est pas instanciable sur un serveur séparé... ;-(
[^] # Re: wikihardware.org
Posté par BAud (site web personnel) . Évalué à 2.
l'idée était plutôt de partir sur une base de données qu'un wiki http://dev.librehwdb.tuxfamily.org/tiki-index.php?page=Doc+D(...)
et profiter des hwdb-clients des différentes distributions pour "automatiser" le process
Cela est arrêté pour l'instant, mais les ressources sont librement utilisables : il y aurait http://dev.librehwdb.tuxfamily.org/tiki-directory_browse.php à compléter avec http://wiki.eagle-usb.org/wakka.php?wiki=HwDbExistingResourc(...) (il faut s'inscrire au tiki-wiki pour proposer des ajouts) et oui c'est encore un annuaire du libre (matériel) ;-)
=> cela fait déjà une bonne analyse de l'existant
[^] # Re: wikihardware.org
Posté par Bapt (site web personnel) . Évalué à 6.
- Je n'y connais rien (pour le moment ?) en développement de driver.
- Je n'y connais rien (pour le moment ?) en Hardware et encore moins en spécification harware.
- Je n'ai pas de site sur lequel l'héberger.
- Enfin et surtout, j'aimerai bien savoir la légalité de la chose avant de me lancé la dedans.
En ce qui concerne le fait de ne rien y connaitre en hardware et spec hardware, c'est à mon avis très génant pour ce lancer dans l'aventure, car je pense (peut être à tord) que la présentation et la lisibilité des specs est un point important pour que le projet soit réellement utilisé et utilisable. De plus il faut savoir un minimum de quoi on parle. Il s'agit là d'un réflection de quelqu'un (moi) qui n'a aucune idée de ce que peut être le développement de drivers, j'ai juste des infos vulgarisés sur le domaine, mais certainement beaucoup trop vulgarisé (comprendre plein de non sens, idées reçues), et les éléments majeurs d'un tel projets devraient selon moi auvoir une certaine crédibilité auprès des dev kernel pour les motiver à participer un peu plus.
Secondo, comme précisé plus haut, il serait peut être intéressant de contacter vendorwatch pour héberger ce projet.
En revanche ce que je peux faire, c'est aidé si quelqu'un se lance là dedans : essayé de récupérer les specs déjà disponible en ligne pour les centralisées, contacté les développeurs kernel des divers projets d'OS OpenSource : Linux, Hurd, FreeBSD, NetBSD, OpenBSD, DragonFly-BSD, Reactos, et tous les autres que j'oublie là mais que j'aurais vite fait de répertorié à se moment là pour les motiver à contribuer.
En clair je n'ai pas de pétrole, mais des idées et je pense que c'est un bon point de départ.
[^] # Re: wikihardware.org
Posté par lasher . Évalué à 3.
Et pourquoi ne pas le faire si personne ne se lance là-dedans ? Dans tous les cas, ce serait quelque chose d'utile, et en plus, ça pourrait un peu inciter certaines personnes à justement commencer à faire quelque chose aussi (mais pas moi, parce que j'ai piscine).
Ton idée est bonne, mais comme la plupart des initiatives pour le LL, il ne faut pas trop attendre quelque chose des autres au départ : ce n'est qu'une fois que le projet aura un minimum de résultats concrets que tu verras arriver de l'aide (« on ne prête qu'aux riches » etc.)
[^] # Re: wikihardware.org
Posté par Bapt (site web personnel) . Évalué à 2.
Je ne me défile pas pour le projet, je veux (et c'est pour ça que je le présente) le réaliser, mais dans la mesure de mes compétences. Il est important si on ne veut pas faire un projet mort né de s'entourrer des personnes compétentes. De plus il ne s'agit pas là d'un projet de dev, ou je peux pondre un code pas propre mais qui fonctionne, qui attire des gens, et que j'apprenne au fur et a mesure à codé propre grâce au projet. Là si les informations présentées sont inutilisables, personne ne pourra s'en servir. En revanche si quelqu'un de compétent le fait, je serai à même d'apprendre et à en faire d'autres propres, donc utiles.
[^] # Re: wikihardware.org
Posté par Bapt (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.