Une couche d'adaptation a été écrite (sous licence BSD), permettant de faire de lien entre les API Linux et les API FreeBSD.
Le développement a principalement été axé sur les pilotes USB. Plusieurs ont ainsi été portés et sont disponibles dans les ports (particulièrement des webcams). Ci-dessous, vous trouverez les liens pour les ports des pilotes de webcam USB gspca et ov511, en espérant que beaucoup d'autres suivront.
Aller plus loin
- Le site de l'auteur (15 clics)
- Le module noyau de compatibilité (18 clics)
- Le port du pilote gspca (12 clics)
- Le port du pilote ov511 (10 clics)
- Journal à l'origine de la dépêche (23 clics)
# Je comprend pas tout ?
Posté par Le Pnume . Évalué à 4.
Merci de vos lumiere
[^] # Re: Je comprend pas tout ?
Posté par Bapt (site web personnel) . Évalué à 10.
De plus la compatibilité n'est pas fonctionnelle pour 100% des drivers, les drivers présentés correspondent aux drivers testé lors le création de la couche de compatibilité linux.
Les port dont il est question sont en fait un packaging des drivers linux pour qu'il puisse compiler sous freeBSD (pas de modification de code, mais modification des makefiles) et ensuite mis à disposition par le biais des ports.
[^] # Re: Je comprend pas tout ?
Posté par Nikoo . Évalué à 3.
[^] # Re: Je comprend pas tout ?
Posté par imalip . Évalué à 7.
Alors qu'un driver natif va faire un truc du genre :
API native
driver -|-> noyau
la ca va faire
API Linux API native
driver -|-> glue -|-> noyau
La perte n'est pas forcement monstrueuse, mais il faut se convertir les appels de fonction ce qui dans le noyau est penalisant, vu qu'a ce niveau on essaie d'etre le plus efficace possible.
# Bonne idée ?
Posté par ondex . Évalué à 5.
Je m'explique : le fonctionnement interne de Linux et FreeBSD doit probablement être différent. Est ce qu'une simple couche d'adaptation peut faire l'affaire ? Par exemple, dans les cas des pilotes SMP-safe (ou non) ?
Ensuite, cela ne risque t'il pas de décourager les développeurs de pilotes pour FreeBSD ? Ne serait pas plus raisonnable de réfléchir ensemble à une API commune pour les pilotes ?
Enfin, on sait que l'API interne de Linux est relativement changeante (euphémisme), le projet va t'il tenter de suivre l'API Linux ou plutôt se fixer sur une version ?
[^] # Re: Bonne idée ?
Posté par Florian.J . Évalué à 4.
N'étant pas utilisateur d'un système BSD, je vois cette info de loin, mais par contre, j'ai essayé à plusieurs reprises d'installer PC-BSD, sans succès, si ce genre d'initiative peut aider a améliorer le support matériel, c'est du tout bon.
[^] # Re: Bonne idée ?
Posté par freebourg . Évalué à -3.
(par-contre, je n'irais pas le recommander à des musiciens, graphistes, et Cie qui ont besoin de bons logiciels. Elle est où la version Linux de Cubase, Finale, Sibelius, et des cartes MIDI, et audio Pro ??).
Mais alors, FreeBSD, OpenBSD, et Cie, à part dans un serveur ou de l'embarqué, je les vois mal ailleurs !
Personnellement, j'ai un serveur OpenBSD à la maison qui gère parfaitement mes serveurs, mon LAN et mon WLAN et qui sécurise le réseau et permet de faire des branchements entre les parties en VPN et avec Internet (WAN tant qu'on est dans les acronymes à 3-4 lettres), il est très stable, les mises à jour arrivent vite, tourne avec un petit PC, quoi de mieux ?
[^] # Re: Bonne idée ?
Posté par freebourg . Évalué à -2.
Faut quand même avouer que pour eux, au niveau logiciel, Mac OS est génial.
[^] # Re: Bonne idée ?
Posté par rhizome . Évalué à 4.
[^] # Re: Bonne idée ?
Posté par B16F4RV4RD1N . Évalué à 1.
Ensuite il faut se configurer jack et compagnie, même si sur le principe c'est très bien, c'est largement plus compliqué que sous windows et on obtient parfois des résultats aléatoires, par exemple j'ai eu des configurations où cela aurait du fonctionner, mais il fallait démarrer une troisième applications pour "débloquer" la sortie midi, mais peut être que c'était lié à cette prise joystick. Du coup je vais acheter une prise midi usb, mais c'est pas donné (50 euros), j'espère que cela ira mieux.
J'ose pas imaginer sous freebsd...
Et pour l'enregistrement audio, il y avait également des latences (mais je n'ai pas encore essayé avec un noyau real time)
Par contre pour les logiciels, rien à redire, Audacity est super bien selon moi, Rosegarden également. Je n'ai pas encore essayé les autres (Ardour etc)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Bonne idée ?
Posté par drakmaniso . Évalué à 5.
Jack est préconfiguré dans les distribs audios, et c'est _réellement_ qqchose qui manque aux musicos sous windows, ils le reconnaissent eux-même (enfin, ceux que je connais).
Afaik, les sources des noyaux des distribs audios sont toujours dispos. Pour 64studio:
http://archive.64studio.com/pool/main/l/linux-2.6/
Ces noyaux sont indispensables pour avoir des latences correctes, la bonne nouvelle c'est que le patch RT d'Ingo Molnar est peu à peu intégré au noyau officiel, depuis le 2.6.18.
Comme dit précédemment, les choses ont drôlement bougé ces derniers temps pour la mao sous linux... et continuent de bouger (qtractor, jokosher, aldrin, Ardour 2, lash, wired...).
[^] # Re: Bonne idée ?
Posté par B16F4RV4RD1N . Évalué à 2.
Pour résumer : le noyau RT dit multimedia de jacklab permettait de faire fonctionner correctement mon adaptateur midi, si je redémarre avec le noyau opensuse non RT et que j'essaye d'utiliser le midi, cela fait un kernel panic. Avec mon noyau recompilé et la config utilisée par opensuse, mais avec l'option RT activée, cela faisait également un kernel panic (mais un peu moins rapidement apparemment).
C'est peut être lié au matériel et à la carte son, en tout cas c'est pas facile à utiliser, car si on veut garder le noyau RT de jacklab, comme j'ai dit on n'a pas les sources modifiées apparement.
Pour studio64 que j'ai installé également, je n'ai pas réussi à faire fonctionner le clavier avec, je ne dis pas que cela ne fonctionne pas, mais en tout cas cela est tellement peu pratique que je vais tenter l'achat d'un adaptateur midi usb, en espérant que cela pourra fonctionner avec un noyau standard. Je vais regarder les sources que tu pointes, mais d'autres utilisateurs ont eu les mêmes soucis que moi pour recompiler des modules extérieurs, par ex
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Bonne idée ?
Posté par drakmaniso . Évalué à 2.
En ce qui concerne tes kernel panic, j'avoue que je suis perplexe...
Pour le noyau de 64 Studio, ils ont simplifié la situation avec la 1.1.1, tu devrais peut-être réessayer... Sinon la situation devrait être encore plus claire avec la 2.0, c'est à dire une fois que Etch sera sorti! ^_^'
[^] # Re: Bonne idée ?
Posté par rhizome . Évalué à 3.
[^] # Re: Bonne idée ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -1.
Et bien achète toi de nouvelles lunettes alors !
Ca fait des années que j'utilise plus que BSD comme desktop et je le vois très bien ainsi...
Ce n'est pas parcequ'on fait les meilleurs serveurs avec BSD qu'on n'en fait rien d'autre ! *sifflote*
Et puis y'en a marre des applis linux.
Si vous voulez faire du vrai code libre, pratique, portable, faites des applis avec des bibliothèques qu'on retrouve sur un max d'OS ! (je pense à ALSA par exemple. Ultra portable de la mort qui tue que c'est, ca m'empeche d'utiliser des applis audio que j'aimerai utiliser...)
[^] # Re: Bonne idée ?
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 0.
Advanced Linux Sound Architecture. Donc bon ça n'a pas vraiment
été fait pour etre portable...
[^] # Re: Bonne idée ?
Posté par freebourg . Évalué à -2.
Avec les BSD c'est tellement compliqué pour un Linuxien d'installer des trucs, à part en ligne de commandes où il faut faire des "locate", ou des pkg_add -r alors qu'on ne connaît même pas le nom des "progs".
Sur Gentoo aussi on peut compiler depuis les sources, mais c'est nettement plus perfectionné et plus simple.
Installation de Gnome : Je ne sais pas si c'est parce que j'ai fait ça dans une machine virtuelle mais il a bien fallu une demi-heure pour qu'il me charge la carte graphique, le clavier et la souris correctement. Le son je n'en ai pas eu (j'ai pas cherché longtemps faut dire).
Sans compter qu'il faut faire des tas de recherches pour que l'utilisateur puisse faire quelque chose, y'a des quantités de groupes et autres, et pas moyen d'avoir un super-utilitaire qui propose juste des petites cases à cocher.
Et bonne chance pour mettre la dernière version de Firefox. Il faut compiler depuis les sources ! (sans compter qu'il faille installer toutes les dépendances manuellement avant).
Alors bon. BSD: pour les geeks.
Et concernant la musique sous Linux, je m'excuse, mais j'avais testé ça il y a 3-4 ans, mais je crois qu'il n'y a encore rien pour concurrencer Sibelius, Finale, Cubase, et consorts. Mais effectivement, ce sont de gros logiciels, et développés en communauté ça prendrait un temps énorme. Surtout quand on voit le prix des logiciels que je viens de citer, on comprend mieux comment est financé leur développement.
[^] # Re: Bonne idée ?
Posté par Matthieu Lemerre . Évalué à 3.
Ceci etant dit, les deux noyaux sont relativement semblable: dans les deux cas il s'agit d'un gros noyau monolithique fournissant une interface UNIX similaire (evidemment avec quelques extensions de chaque cote). Ils sont beaucoup plus proche que par exemple, de Minix ou QNX (pour rester dans le UNIX-Like).
Pour faire des noyaux SMP-safe, il "suffit" de faire en sorte que les appels de fonctions et macros pour prendre des locks, faire des updates atomiques dans Linux soient transcrits en leur equivalents FreeBSD (et il y a toujours un equivalent, puisque les noyaux sont structures identiquement). Il y a quelques differerences comme les locks RCU sous Linux, mais de toute facon rien n'interdit de porter une primitive de locking d'un OS a un autre.
Ce travail a surement de plus ete facilite par le fait que la couche USB de Linux tente d'etre generique et accessible depuis l'espace utilisateur.
C'est quand meme un gros travail, et je felicite le courage des personnes qui l'ont fait. Peut etre que ce travail peut d'ailleurs reservir a d'autres systemes libres?
[^] # Re: Bonne idée ?
Posté par ZooL . Évalué à 3.
Jusqu'à présent, on avait un port de pwc, mais le statut était le même que pour linux, et c'est tout.
Les webcams ne sont pas à proprement parler une technologie récente. Si quelqu'un de capable avait voulu faire des drivers, il aurait eu tout le temps.
Ce débat me rappelle vaguement celui pour le projet evil (ndiswrapper). En l'occurence, ça n'a découragé personne : peut être que je ne suivais pas assez avant, mais j'ai l'impression que le monde des développeurs de drivers de carte wifi pour BSD est en ébullition en ce moment, guidé par Damien Bergamini. Ca n'a pas non plus découragé les constructeurs, puisque si j'en crois le rapport trimestriel de FreeBSD, atheros va plus ou moins donner les specs pour ses derniers chipsets (genre ceux du DWL-G132, ou uath chez OpenBSD)
Evidemment, ça ne va pas encourager les constructeurs de webcam, mais en même temps, ils n'ont jamais fait aucun effort.
Pour ce qui est de l'API interne de linux, je suis encore moins un spécialiste pour répondre, mais FreeBSD a déjà une couche de compatibilité linux, avec récemment (enfin, en cours), un passage à la version 2.6 du noyau (oui, on est pas en avance :))
Je pense pas que ce soit pire de suivre les changements de l'API par rapport à ceux du noyau.
J'ai testé la chose en question. Ca marche très bien avec un de mes deux webcams, l'autre est seulement détectée, mais d'après luigi, ça devrait mieux marcher par la suite, après quelques optimisations.
C'est vraiment fantastique de pouvoir utiliser la webcam, sans avoir à se soucier d'installer 30000 drivers.
De toute manière, je pense pas vraiment que *BSD (prenez celui que vous voulez) a les ressources pour développer tous les drivers de tous les trucs possibles. Linux en a plus, donc si on peut reprendre un peu pour le hardware pas critique, je vois pas vraiment où est le problème.
# licenses
Posté par hervé Couvelard . Évalué à -5.
[^] # Re: licenses
Posté par allcolor (site web personnel) . Évalué à 1.
[^] # Re: licenses
Posté par IsNotGood . Évalué à 3.
Un source sous BSD dans un projet GPL a sa licence toujours respecté.
L'inverse est faut. Si un projet est sous BSD, alors on peut le distribuer sans les sources. Si est fichier de ce projet est source GPL, on viole la GPL.
[^] # Re: licenses
Posté par allcolor (site web personnel) . Évalué à 1.
[^] # Re: licenses
Posté par Sylvain Sauvage . Évalué à 2.
[^] # Re: licenses
Posté par Bapt (site web personnel) . Évalué à 2.
Si ils n'ont pas le droit de le faire, ils n'ont pas plus le droit de fournir gcc, pourtant ils le font, et ils modifient les makefile de gcc pour le mettre dans le userland or ils le font le plus légalement du monde.
[^] # Re: licenses
Posté par IsNotGood . Évalué à 3.
Rien à voir. Gcc est sous GPL qu'il soit fournit pas FreeBSD ou Linux. Evites de glisser dans le FUD.
gcc n'est pas un travail dérivé de Linux. Les drivers de Linux le sont (en fait ça dépend, Linus n'a pas exactement la même interprétation que RMS).
Si un drivers est sous GPL, il ne peut être mis dans le noyau FreeBSD et redistribué. La licence GPL du driver est en contradiction avec la licence BSD et vice versa.
Par contre le driver peut être délivré séparément.
Mais beaucoup de driver Linux sont sous double licence BSD-GPL.
[^] # Re: licenses
Posté par Bapt (site web personnel) . Évalué à 5.
Donc c'est bien ce que je dis la situation est la même que pour la fourniture de gcc ou d'autres drivers GPL déjà livrés avec FreeBSD (en modules pas en dur).
Je ne glisse pas dans le FUD, mais des réactions celle de Herve_2 m'énerve car il n'y a pas l'once d'un renseignement avant de sortir des affirmations complètement fausses. Idem pour ton intervention d'ailleurs.
Donc je le répète si s'agit de fournir les drivers en modules (en leur laissant leur license quelqu'elle soit) en non des les incorporer au noyau.
Tout ce qui à terme pourra être incorporé au noyau c'est l'interface d'adaptation qui est sous license BSD et a été écrit "from scratch".
[^] # Re: licenses
Posté par IsNotGood . Évalué à 1.
Merci. Mais herve_02 a raison. Relis le (lentement et tous les mots).
> Donc c'est bien ce que je dis la situation est la même que pour la fourniture de gcc
Non.
[^] # Re: licenses
Posté par Yth (Mastodon) . Évalué à 6.
Je ne vois vraiment pas où est le problème.
D'ailleurs c'est bien le grand intérêt des projets libres non ? De pouvoir être réutilisés ?
Les clauses de la GPL n'ont aucune raison de ne pas être respectées, ils peuvent fournir les sources - et le font, puisque BSD est généralement compilé, ce qui ne saurait se faire sans les sources - qui restent sous GPL.
Modifier le Makefile, ils peuvent le faire, il suffit de laisser le nouveau Makefile en GPL et de le fournir ce qui est relativement aisé à faire, pour ne pas dire trivial.
C'est vraiment gavant ces hurlements de vierge effarouchée dès qu'il est question de la GPL et du noyau Linux, je trouve ça très bien qu'il soit possible de repomper des drivers écrit pour Linux, et de les utiliser dans un autre système libre aussi.
C'est une preuve de l'intérêt et de la pérennité de ce modèle, ça améliore globalement le libre, ça évite de diviser les efforts, et personne n'y perd quoi que ce soit... Et c'est totalement dans la philosophie du libre.
Yth.
[^] # Re: licenses
Posté par IsNotGood . Évalué à -2.
Ça, après avoir regardé dans le détail, ne doit pas poser de problème.
Mais herve_02, qui se fait moinser injustement, dit :
- "Si ils doivent modifier le makefile pour les compiler sous freeebsd, il n'ont pas le droit de les redistribuer (ensemble et compilés)"
herve_02 a raison. Le système de score dlfp a encore tord...
[^] # Re: licenses
Posté par allcolor (site web personnel) . Évalué à 2.
Comme de la livraison du module gpl compilé sur un cd avec le système freebsd. Tant que les sources du module gpl sont disponibles c'est tout à fait légal et ceci est bien ensemble et compilés.
Et donc non il n'a pas raison et/ou il FUD pour rien.
[^] # Re: licenses
Posté par Bapt (site web personnel) . Évalué à 2.
Mais tu le fais exprès.
Dans un CD FreeBSD tu as des drivers GPL compilés en modules (par exemple reiserfs) tu as des logiciels de bases en GPL sont fournis en userland (donc dans le CVS officiel de projet FreeBSD) qui sont donc compilés sur le même CD c'est le cas de gcc que j'invoquais avant. Si tu regardais d'un peu plus près FreeBSD tu verais que l'intégralité des sources du système sont disponibles y compris les modules GPL donc c'est légal sans problèmes. si les drivers en question sont fournis dans les prochaines version de FreeBSD ils seront aussi légaux que ceux déjà fournis.
Je dis qu'il y a FUD car toi comme Herve_2 dénoncez un côté illégal sur des suppositions. Or ce que vous dites ne correspond en rien à la réalité du fonctionnement d'un FreeBSD. si tu veux les sources disponibles pour les modules GPL du noyaux, tu les as ici : http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/gnu/
Elles sont aussi dans les CD d'installation FreeBSD si tu demandes a installer les sources.
Ils ont donc parfaitement le droit de les redistribuer (ensemble et compilés)" comme ils le font déjà pour les autres modules. Les éventuelles modifications le seront en respectant la GPL et en refournissant le tout sous license GPL.
[^] # Re: licenses
Posté par allcolor (site web personnel) . Évalué à 2.
Des fois ça fait pas de mal de le faire.
[^] # Re: licenses
Posté par Bapt (site web personnel) . Évalué à 2.
[^] # Re: licenses
Posté par imalip . Évalué à 4.
Et c'est toi qui accuse les autres de faire du FUD ?
Un driver sous GPL peut etre mis dans le noyau FreeBSD et redistribue, de la meme maniere qu'un noyau sous licence BSD peut etre mis dans un noyau sous licence GPL et redistribue. Par contre, dans les deux cas, l'ensemble doit etre distribue selon les termes de la GPL. Y compris sous forme binaire.
La raison pour laquelle FreeBSD n'integre pas de module GPL directement dans la "distribution" est uniquement pour respecter le fait que le projet considere qu'il fournit un systeme entierement sous licence BSD (modu gcc). Je ne suis pas perso un fan de la licence BSD, mais c'est une position que je ne peux que respecter.
Et avant que tu me dises que "l'ensemble doit etre distribue selon les termes de la GPL donc ca veut dire que le noyau devient GPL", tu peux tout a fait distribuer l'ensemble, auquel cas je peux recuperer les sources, virer ce qui est sous GPL et le redistribuer juste le code sous BSD, auquel cas je n'ai que la licence BSD a respecter. Le code du noyau est reste sous sa licence d'origine.
[^] # Re: licenses
Posté par Panda . Évalué à 2.
# LibUSB
Posté par TeraHertZ . Évalué à 3.
[^] # Re: LibUSB
Posté par Pol' uX (site web personnel) . Évalué à 3.
Mais j'avoue que je trouve cette librairie bien faite. Cependant, cela ne suffit pas pour offrir une infrastructure de drivers. libusb permet seulement de développer des drivers usb en user mode.
Adhérer à l'April, ça vous tente ?
[^] # Re: LibUSB
Posté par TeraHertZ . Évalué à -2.
De mieux en mieux.
Non, non, c'est sûrement objectif comme jugement!
J'ai dû en chatouillé quelques uns... :)
# Mais pourquoi faire simple...
Posté par Aza . Évalué à -2.
[^] # Re: Mais pourquoi faire simple...
Posté par vjm . Évalué à 2.
Le projet FreeBSD n'a pas les ressources nécessaires pour obtenir un support aussi complet que Linux ou inciter les éditeurs à porter leurs applications sous FreeBSD (à défaut de simplement les convaincre de faire quelque chose de réellement portables...).
Ca ne m'empêche pas de préférer le modèle de développement de FreeBSD, les choix techniques de FreeBSD, la communauté FreeBSD, etc.
Si c'est pour utiliser les mêmes logiciels de toute façon, pourquoi les linuxiens ont le choix entre plusieurs distributions ? Et c'est même pire, vous, vous avez le même noyau...
[^] # Re: Mais pourquoi faire simple...
Posté par fmaz fmaz . Évalué à 10.
Cela m'a toujours amusé chez les linuxiens : ils peuvent utiliser certains executables windows (wine, vmware, qemu) et maintenant certains drivers windows (ndiswrapper). Bon mais si c'est pour utiliser linux et aller prendre les drivers et les application sous windows pourquoi ne pas utiliser directement windows ?
[^] # Re: Mais pourquoi faire simple...
Posté par Bapt (site web personnel) . Évalué à 10.
En revanche j'utiliserai certainement cette couche pour les drivers USB car j'ai du matériel USB non encore reconnu sous FreeBSD. Pourquoi ne pas utiliser Linux directement dans ces cas là ? Parce qu'il y a plein de chose que je préfère sous FreeBSD par rapport à Linux.
Par exemple :
- devfsd que je préfère très très largement à udev (qui change tous les quatres matins) : simple avec toujours la même syntaxe depuis des lustres.
- les drivers mettent du temps à venir sous FreeBSD mais quand on les a ils sont très souvent excellent, et ne changent pas à chaques mises à jours (l'acpi + cpufreq est un bonheur sous FreeBSD pour mon portable comparer à ce qu'il faut faire pour arriver au même fonctionnement sous Linux)
- PF, ça viens d'OpenBSD mais c'est disponible sous FreeBSD, quand on y a gouté on ne peux plus revenir sur du iptables.
La documentation : tous les éléments du noyau et du userland sont documentés complètement, y compris chaque driver. par exemple pour un ordinateur portable, j'avais besoin d'un connecteur ethernet en USB. Pour trouver du matériel compatible, ma démarche a été la suivante :
apropos eth | grep USB
j'obtiens la liste suivant :
aue(4), axe(4), cdce(4), cue(4), kue(4), rue(4), udev(4)
Ce sont les drivers pour les connecteurs ethernet USB, un man sur chacun d'eux me donne une liste de matériels compatibles y compris les noms commerciaux pas que les chipsets.
Je me suis rabattu sur le matériel reconnu par le driver axe (ASIX Electronics AX88172 - va trouver du matos avec juste cette référence...) Dans le man en question j'ai une petite section HARDWARE dans laquelle je trouve :
- Buffalo (Melco inc.) LUA-U2-KTX
- D-Link DUBE100
- LinkSys USB200M
- ...
J'ai maintenant les références du matériel compatible et je ne me fait pas avoir. Je vais chez mon revendeur préférer et lui dit précisément ce que je veux.
Pour le matériel USB dont je parlais plus haut, je l'ai acheté avant de me mettre à FreeBSD.
La dernière fois que j'ai voulu faire la même chose pour linux, je te dis pas la galère : la doc du noyau, dans le meilleur des cas on obtient le nom des chipsets puis google pour voir quel matos utilise le driver en question, ensuite vérifier si le driver est dans le kernel ou séparé (sinon beaucoup de risque de merde en cas de mise à jour du kernel) etc, etc.
[^] # Re: Mais pourquoi faire simple...
Posté par Ulrich Blondel . Évalué à 4.
Le développement des *BSD est plus rigoureux, globalement si ce qui est codé n'est pas fonctionnel à 100% alors ça ne sera pas incorporé à la distri.
Bien sûr, nous avons pas tous les avantages des linuxiens pour ce qui est de la reconnaissance du matériel, mais c'est petit souci par rapport à la Grandeur de FreeBSD ;)
FreeBSD sailfutur!
[^] # Re: Mais pourquoi faire simple...
Posté par david_c . Évalué à 1.
Comme ULE ??
--> []
[^] # Re: Mais pourquoi faire simple...
Posté par ola . Évalué à 0.
# Les boules
Posté par C0UNTZ3R0 . Évalué à -2.
Avec des pilotes Linux, ça va devenir une vraie catastrophe...
Enfin... heureusement, il y a Vista... http://www.guwiv.com
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.