Je comprend pas tout ?

• [^]Re: Je comprend pas tout ?

  Posté par Bapt (page perso, ) le 12/02/2007 à 15:45. (lien). Évalué à 10.

  Parce que depuis les sources il faut quand même écrire les makefile pour fabriquer les modules FreeBSD.
  
  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 () le 12/02/2007 à 18:13. (lien). Évalué à 3.

    donc a priori, pas de pertes de performances de fonctionnement, non ?

    --
    http://nikoolinux.zeblog.com/

    • [^]Re: Je comprend pas tout ?

      Posté par imalip (page perso, ) le 12/02/2007 à 21:43. (lien). Évalué à 7.

      Ben si, parce que ca veut dire que le noyau a une couche de "glue" pour que les drivers Linux puissent communiquer avec.
      
      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.

      --
      "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

Bonne idée ?

• [^]Re: Bonne idée ?

  Posté par Diablo150 (page perso, ) le 12/02/2007 à 16:19. (lien). Évalué à 4.

  Etant donné les grosse différences de philosophie entre BSD et Linux, je pense qu'il serait difficile de trouver un terrain d'entente pour les voir bosser ensemble.
  
  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 () le 12/02/2007 à 18:03. (lien). Évalué à -3.

    Linux est déjà tout juste prêt pour le desktop de monsieur tout-le-monde.
    (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 () le 12/02/2007 à 18:07. (lien). Évalué à -2.

      >(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 ??).
      
      Faut quand même avouer que pour eux, au niveau logiciel, Mac OS est génial.

    • [^]Re: Bonne idée ?

      Posté par alpage (page perso, ) le 13/02/2007 à 04:47. (lien). Évalué à 4.

      Tu es quand meme un peu dur sur les logiciels de musiques. Il y a plein de bonnes choses dans ce domaine et de nombreuses cartes pro sont supportees. Les choses on pas mal bougees ces dernieres annees.

      • [^]Re: Bonne idée ?

        Posté par farvardin (page perso, ) le 13/02/2007 à 06:21. (lien). Évalué à 1.

        peut être que je n'ai pas eu de chance, mais j'avais acheté il y a plusieurs années une prise à brancher sur le port joystick, cela fonctionne sans pb sous windows, mais sous linux c'est la galère, avec un noyau de base cela fait des kernel panic, avec un noyau real time cela fonctionne mais comme pour ces projets de noyau RT ils ne fournissent pas les sources modifiées du noyau (que cela soit pour studio64 ou jacklab) il n'est pas possible d'utiliser des modules à compiler pour d'autres applications.
        
        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)

        --
        "Every line of code that is written to our standards is a small victory ; every line of code that is written to any other standard is a small defeat. "
        Evangelism is War

        • [^]Re: Bonne idée ?

          Posté par Laurent Moussault () le 13/02/2007 à 18:48. (lien). Évalué à 5.

          J'utilise aussi une prise joystick<->midi, ça fonctionne sans pb aussi bien avec un noyau classique que RT.
          
          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 farvardin (page perso, ) le 14/02/2007 à 12:38. (lien). Évalué à 2.

            pour le patch RT intégré depuis le 2.6.18, il y a bien une option RT / preempt dans le noyau 2.6.19 "vanilla" que j'ai recompilé, mais même s'il était bien marqué comme étant RT, il ne fonctionnait pas comme le noyau fourni par jacklab (sous opensuse).
            
            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
            
            

            > Using the SMP kernel I can build the module but it will not
            > install into
            > the kernel, it complains that the version magic is wrong and
            > when I look
            > at the version string for the nvidia module it does not have the
            > SMP
            > string.

            --
            "Every line of code that is written to our standards is a small victory ; every line of code that is written to any other standard is a small defeat. "
            Evangelism is War

            • [^]Re: Bonne idée ?

              Posté par Laurent Moussault () le 14/02/2007 à 16:26. (lien). Évalué à 2.

              Le patch RT est intégré _progressivement_ au noyau officiel, vu qu'il touche beaucoup d'endroits différents. Donc pour l'instant il faut toujours utiliser le patch d'Ingo Molnar sur un vanilla kernel pour obtenir les mêmes performances.
              
              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 alpage (page perso, ) le 14/02/2007 à 03:59. (lien). Évalué à 3.

          Avec un nouyeau realtime maison (patch realtime-lsm) sous Slackware, je n'ai pas remarque de latence, avec 3 a 5 pistes en lecture et une piste en enregistrement, le tout en tirant parti des entrees/sorties mutiples d'un M-Audio Delta 44. Allez courage, tu peux le faire :)

    • [+] [^]Re: Bonne idée ?

      Posté par Axioplase Ashi (page perso, ) le 13/02/2007 à 07:19. (lien). Évalué à -1.

      >> Mais alors, FreeBSD, OpenBSD, et Cie, à part dans un serveur ou de l'embarqué, je les vois mal ailleurs !
      
      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...)

      --
      J'aime la liberté.
      J'aime BSD.

      • [^]Re: Bonne idée ?

        Posté par -=[ Benoit Plessis ]=- (page perso, ) le 14/02/2007 à 10:18. (lien). Évalué à 0.

        Sans vouloir remuer le couteau dans la plaie, le projet ALSA c'est
        Advanced Linux Sound Architecture. Donc bon ça n'a pas vraiment
        été fait pour etre portable...

        --
        Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)

      • [+] [^]Re: Bonne idée ?

        Posté par freebourg () le 22/02/2007 à 09:02. (lien). Évalué à -2.

        Attention ! Moi je parle en fait seulement de FreeBSD, OpenBSD, et NetBSD. Je mets de côté les PC-BSD et l'autre dont je ne me souviens plus du nom.
        
        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 () le 12/02/2007 à 18:09. (lien). Évalué à 3.

    Quelle difference de philosophie? Tu veux parler plutot de methodologie de developpement peut etre; il est vrai que FreeBSD est plus conservateur que Linux sur ce point la.
    
    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 (page perso, ) le 12/02/2007 à 17:29. (lien). Évalué à 3.

  Sur le point très particulier des développeurs de pilotes pour FreeBSD, en ce qui concerne les webcams, c'est simple, il n'y a rien d'existant.
  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

• [^]Re: licenses

  Posté par allcolor (Jabber id, page perso, ) le 12/02/2007 à 18:43. (lien). Évalué à 1.

  Et pourquoi donc ? si les drivers sont GPL, ils restent GPL et freeBSD étant en BSD donc compatible il n'y aucun problème.

  --
  All those moments will be lost in time, like tears in the rain.

  • [^]Re: licenses

    Posté par IsNotGood () le 12/02/2007 à 19:42. (lien). Évalué à 3.

    La BSD est compatible avec la GPL mais pas l'inverse.
    
    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 (Jabber id, page perso, ) le 12/02/2007 à 19:50. (lien). Évalué à 1.

      Dans ce cas uniquement... on parle distribuer des modules gpl avec freebsd... c'est légal, maintenant si un récipiant du tout décide de prendre freebsd et de le distribuer sans l'accès au sources il violerait la GPL mais seulement lui. Donc comme dit plus haut qu'est-ce qui empêche de livrer des modules GPL avec freeBSD ? rien.

      --
      All those moments will be lost in time, like tears in the rain.

      • [^]Re: licenses

        Posté par Sylvain Sauvage () le 14/02/2007 à 14:11. (lien). Évalué à 2.

        *récipiant → récipiendaire

• [^]Re: licenses

  Posté par Bapt (page perso, ) le 12/02/2007 à 19:13. (lien). Évalué à 2.

  Tu peux étayer s'il te plait car c'est un peu facile de lancer des FUD comme ça.
  
  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 () le 12/02/2007 à 19:39. (lien). Évalué à 3.

    > ils n'ont pas plus le droit de fournir gcc
    
    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 (page perso, ) le 12/02/2007 à 20:04. (lien). Évalué à 5.

      Il n'a jamais été question de mettre les drivers en dur dans le kernel, mais de les fournir en GPL (l'interface d'adaptation est BSD mais les drivers conservent les licenses) et ne pourront pas être compiler en dur, ils seront disponible uniquement en module tout comme zfs (CDDL) reiserfs (GPL) etc.
      
      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 () le 12/02/2007 à 20:48. (lien). Évalué à 1.

        > 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.
        
        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 (Jabber id, ) le 12/02/2007 à 20:09. (lien). Évalué à 6.

      Il y a écrit « en tant que module », donc il n'est pas question de compiler un binaire du noyau BSD avec des drivers Linux dedans, mais bien de continuer à livrer un noyau BSD classique, et à côté des modules extrait de Linux, sous GPL.
      
      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 () le 12/02/2007 à 20:41. (lien). Évalué à -2.

        > Il y a écrit « en tant que module », donc il n'est pas question de compiler un binaire du noyau BSD avec des drivers Linux dedans, mais bien de continuer à livrer un noyau BSD classique, et à côté des modules extrait de Linux, sous GPL.
        
        Ç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 (Jabber id, page perso, ) le 12/02/2007 à 21:03. (lien). Évalué à 2.

          Sauf que l'on parle de modules depuis le début cf. l'article, donc je comprends ceci:
          
          

          
          (ensemble et compilés)
          

          
          
          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.

          --
          All those moments will be lost in time, like tears in the rain.

          • [^]Re: licenses

            Posté par Bapt (page perso, ) le 12/02/2007 à 21:33. (lien). É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.

            
            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 (Jabber id, page perso, ) le 12/02/2007 à 22:01. (lien). Évalué à 2.

              Euh tu devrais relire un peu... c'est exactement ce que je dis en répondant à isnotgood...
              
              Des fois ça fait pas de mal de le faire.

              --
              All those moments will be lost in time, like tears in the rain.

              • [^]Re: licenses

                Posté par Bapt (page perso, ) le 12/02/2007 à 22:19. (lien). Évalué à 2.

                C'est pas à toi que je répondais, mais à IsNotGood :) désolé, je me suis gouré en cliquant répondre :)

    • [^]Re: licenses

      Posté par imalip (page perso, ) le 12/02/2007 à 21:45. (lien). Évalué à 4.

      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.

      
      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.

      --
      "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

      • [^]Re: licenses

        Posté par Panda (page perso, ) le 12/02/2007 à 22:38. (lien). Évalué à 2.

        Moi je trouve que c'est une bonne nouvelle, si y'a moyen qu'il coopère ensemble pour sortir des driver compatible bsd/linux, ça ne fera qu'augmenter la liste du matos supporté.

        --
        http://travisnux.byethost9.com

LibUSB

• [^]Re: LibUSB

  Posté par Pol' uX () le 13/02/2007 à 06:31. (lien). Évalué à 3.

  Certainement pour des raisons de performance ...
  
  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.

  --
  Soutenez le logiciel libre, en adhérant dès maintenant à l'April

  • [+] [^]Re: LibUSB

    Posté par TeraHertZ () le 14/02/2007 à 12:49. (lien). Évalué à -2.

    HAHA, même ma question totalement légitime est moinssée!
    De mieux en mieux.
    Non, non, c'est sûrement objectif comme jugement!
    
    J'ai dû en chatouillé quelques uns... :)

[+] Mais pourquoi faire simple...

• [^]Re: Mais pourquoi faire simple...

  Posté par vjm () le 13/02/2007 à 13:13. (lien). Évalué à 2.

  Personnellement, en tant qu'utilisateur de FreeBSD, je n'utilise uniquement des applications ou des drivers Linux/Windows lorsque je n'ai pas le choix.
  
  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...

  --
  vjm

• [^]Re: Mais pourquoi faire simple...

  Posté par fmaz fmaz () le 13/02/2007 à 14:07. (lien). Évalué à 10.

  Transposition libre:
  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 (page perso, ) le 13/02/2007 à 14:14. (lien). Évalué à 10.

  Je n'utilise que très rarement la compatibilité linux pour mon desktop et jamais pour mes serveurs.
  
  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 () le 14/02/2007 à 15:40. (lien). Évalué à 4.

  FreeBSD c'est une simplicité, une efficacité, une organisation.
  
  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 () le 15/02/2007 à 10:10. (lien). Évalué à 1.

    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.
    
    Comme ULE ??
    
    --> []

    • [^]Re: Mais pourquoi faire simple...

      Posté par ola () le 15/02/2007 à 20:39. (lien). Évalué à 0.

      nan, il manque ULE dans la distrib....

[+] Les boules