Comme la quasi-totalité des webcams sur le marché utilisent ce module, elles ne sont donc plus supportées par Linux. C'est un coup dur pour Linux sur le poste client... En attendant une autre solution ?
Fin du support Linux des webcams Philips
26
août
2004
Suite à la décision des mainteneurs du noyau d'exclure la possibilité d'utiliser un module binaire conjointement au module GPL pwc (philips webcam), le mainteneur du module pwc-pwcx a décidé d'arrêter définitivement le support de ce module, et a fermé son site web et retiré les fichiers en téléchargement.
Comme la quasi-totalité des webcams sur le marché utilisent ce module, elles ne sont donc plus supportées par Linux. C'est un coup dur pour Linux sur le poste client... En attendant une autre solution ?
Comme la quasi-totalité des webcams sur le marché utilisent ce module, elles ne sont donc plus supportées par Linux. C'est un coup dur pour Linux sur le poste client... En attendant une autre solution ?
# mais quel gâchis !!!
Posté par Axel . Évalué à 10.
Quel gâchis!
[^] # Re: mais quel gâchis !!!
Posté par DonKiShoot (site web personnel) . Évalué à 2.
J'éspère qu'il va y avoir une solution car c'est un vrai problème pour les personnes comme moi qui possedent une webcam philips usb !!!
[^] # Re: mais quel gâchis !!!
Posté par spart . Évalué à 10.
Il explique tranquillement que l'expiration de son NDA avec Philips l'autorise à mettre tout cela sous GPL depuis plus d'un an, mais que non, il ne va pas le faire, parce que vous comprenez, ce serait mauvais pour la "confiance" de Philips.
Qu'est-ce que la confiance vient faire là-dedans ?
Si Philips lui fait signer un NDA à _échéance_, c'est pour faire joli ?
Encore une triste histoire d'orgueil et de pouvoir, m'est avis.
[^] # Re: mais quel gâchis !!!
Posté par ced . Évalué à 3.
Il va nous faire un coup à la donnez moi 42 000¤ et je libère les sources ?
C'est triste de voir que beaucoup de gens ont le kiki tout dur dès qu'il ont quelque chose que les autres veulent... Surout que là c'est quand même assez important, ce n'est pas une histoire de billes de gamin de maternelle mais le comportement est le même.
Je trouve ça désolant...
[^] # Re: mais quel gâchis !!!
Posté par Nicolas Boulay (site web personnel) . Évalué à -3.
Linux est 100% GPL. La tolérance pour les modules non GPL provient d'une subtilité dans la définition de la "combined forme of work". En gros, on rajoute un système de fichier (AFS, je crois à poser le pb le premier) ou un driver video (déveloper en 1 er pour windows). C'est ok.
Or, là, il s'agit purement d'un travail en vue d'utilisation pour linux et uniquement linux à 100%. Il ne respecte donc pas la GPL.
Sinon, son attitude dans son mail est déplorable. Comment ose-t-il demander le retrait de son code du kernel ? C'est du code GPL !
Et pourquoi n'a-t-il pas libéré le code depuis 1 an ? C'est bien qu'il a envis de faire chier son monde !
"La première sécurité est la liberté"
[^] # Re: mais quel gâchis !!!
Posté par 007 . Évalué à 4.
Il a le droit ! Le code lui appartient.
Par contre l'importe qui peut remettre le code dans Linux :-)
C'est le GPL touch .
[^] # Re: mais quel gâchis !!!
Posté par Philippe F (site web personnel) . Évalué à 9.
[^] # Re: mais quel gâchis !!!
Posté par spart . Évalué à 2.
Passé la date, ils sont plutot encouragés à causer :)
Note, je dis pas que c'est la même chose, je dis juste que ce genre de papier est monnaie courante.
[^] # Re: mais quel gâchis !!!
Posté par Philippe F (site web personnel) . Évalué à 6.
En plus, je soupconne que la seule raison pour laquelle philips ne veut pas rendre ce code open source, c'est parce que avec un algo de compression, ils vont se faire attaquer de toute part par des mecs qui ont des brevets sur tout et n'importe quoi. C'est moins risque de garder le code close source.
[^] # Re: mais quel gâchis !!!
Posté par Joaquim Fellmann . Évalué à 2.
A la question "Veux tu te porter volontaire et maintenir ça ?" posée par Linus, Alan Cox a répondu "oui":
http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.3/2082.html(...)
Le driver pwc (sans hook) devrait réapparaitre sous peu.
--
Joaquim
# Post LKML
Posté par tgl . Évalué à 6.
Anyway, c'est là :
http://lkml.org/lkml/2004/8/24/278(...)
# pwc vs pwcx
Posté par bhybct . Évalué à 2.
Il ne permet pas d'exploiter les webcam au maximum, mais reste acceptable.
[^] # Re: pwc vs pwcx
Posté par Philippe F (site web personnel) . Évalué à 4.
[^] # Re: pwc vs pwcx
Posté par bhybct . Évalué à -2.
Mais est-ce qu'on est obligé de le faire ?
[^] # Re: pwc vs pwcx
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: pwc vs pwcx
Posté par Emmanuel Seyman . Évalué à 4.
[^] # Re: pwc vs pwcx
Posté par Jerome Herman . Évalué à 10.
Il peut exiger que ca se fasse pour que son nom ne soit plus associé avec le module dans le kernel (il reste toujours dans les contributeurs du code, mais sort des contributeurs du kernel). Après ca la personne qui réintroduit le code prend sa place vis à vis du kernel.
C'est tout ce qu'il demande.
Kha
[^] # Re: pwc vs pwcx
Posté par grafit . Évalué à 2.
Je croyais que les droits d'auteurs étaient inalienables ?!?
[^] # Re: pwc vs pwcx
Posté par Jerome Herman . Évalué à 2.
Ils le sont, il reste toujours l'auteur du code. Par contre le fait de faire ceci le sort des contributeurs du noyau. C'est juste un problème de decorum dans le noyau. Ca ne change rien a ses droits sur le code.
Kha
[^] # Re: pwc vs pwcx
Posté par mickabouille . Évalué à 1.
[^] # Re: pwc vs pwcx
Posté par Éric (site web personnel) . Évalué à 4.
- le produit n'est pas diffusé qu'en France et donc en dehors de France ils ne sont je pense pas tenu par les droits d'auteurs français qui sont assez spécifiques mais par les accords internationnaux.
- l'auteur peut jouir de son droit moral et interdire une utilisation de son oeuvre mais s'il s'était engagé à dire "oui" avant je suppose que celui qui se voit notifié l'interdiction peut demander droit à compensation (même si l'auteur a le droit de le faire, en le faisant il casse tout de même un accord qu'il a fait volontairement).
[^] # Re: pwc vs pwcx
Posté par Cédric Blancher . Évalué à 3.
Fallait pas publier sous GPL...
[^] # Re: pwc vs pwcx
Posté par mickabouille . Évalué à 2.
Bien sûr, ça ne s'applique que si l'oeuvre est placée sous le droit français, ce qui n'est pas le cas ici.
[^] # Re: pwc vs pwcx
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: pwc vs pwcx
Posté par Christophe BAEGERT . Évalué à 0.
[^] # Re: pwc vs pwcx
Posté par Anonyme . Évalué à 1.
Il me semble qu'exiger un tel retrait, même avec les lois Françaises, est, dans la pratique, impossible.
Je me demande ce qu'un juriste en dirait.
[^] # Re: pwc vs pwcx
Posté par Éric (site web personnel) . Évalué à 2.
En gros celui qui dédomagepourrait peut être n'être tenu que de la perte du code en question et pas des conséquences. Or le code a été fournit gratuitement. Pas sûr qu'il y ai un dédomagement autre que symbolique.
Enfin bon, là on parle dans le paté, Linus n'est pas en France, il n'a à priori pas à respecter ces clauses très spécifiques au droit français (ou du moins j'en serai étonné).
# euhh ... mainteneurs oupsss ?
Posté par snurpsss . Évalué à 2.
"Suite à la décision des mainteneurs du noyau d'exclure la possibilité d'utiliser un module binaire conjointement au module GPL pwc (philips webcam)"
les mainteneurs ont ils pris cette decision en sachant que "quasi-totalité des webcams sur le marché utilisent ce module" ? doit on comprendre que la quasi totalité des webcams , sous entendu webcams Philips ( d'où le titre de la news) ou bien TOUTE les webcams ?
Meme si il ne s'agit que des webcams philips , je trouve ca trés génant . J'espère que les personnes qui ont pris cette décision vont revenir en arriere ou proposé une alternative fonctionnelle rapide .
On se croyerai presque chez M. Fenetre où quand on change d'os , bah les drivers sont plus compatibles , et tampis si ca marche pas : rachetez vous du matos ....
(ps n'étant pas moi meme un développeur je ne me permet pas de critiquer leur travail , mais leur maniere de faire . Peux etre aurais t il fallu attendre qu une alternative a ce module soit developper avant d exclure une partie des possesseur de webcam.)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Dafatfab . Évalué à 2.
Je ne saisi pas le(s) motif(s) de cet abandon....
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Dafatfab . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Dalton joe . Évalué à 1.
Puis y a eu la separation du module en 2 (le cote obscure et l'autre).
C'est vrais que Philips n'aide pas trop sur ce coup là, mais on avait des webcams utilisable et qu'on pouvaient adapter à d'autres utilisation (astronomique par exemple).
Bref je pense qu'Alan et les autres veulent pousser dans le sens de l'ouverture, et donc connaissant la loi de la mecanique générale, y a un peu d'inertie.
Le problème est général à Linux et aux relation avec les constructeurs.
Je crois d'ailleur que le flameware est ouvert sur LKML pour la liste noire ou blanche.
Ah, au faite depuis mon passage en 2.6.8.1 je peux plus graver, bizarre...
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par fredix . Évalué à 2.
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.2/0091.html(...)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Serge Rossi (site web personnel) . Évalué à 2.
http://linuxfr.org/2004/08/14/17040.html(...)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Croconux . Évalué à 5.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 10.
Les mainteneurs du noyeau en ont un peut marre qu'on viole la GPL à tour de bras. Aujourd'hui il n'autorisent les modules proprio à titre exceptionnel et derogatoire qu'en passant par un sous ensemble de l'API, et le gas avait écrit un truc dans le driver libre spécialement concu pour charger son module proprio.
Du coup le type il rebelle parce que ca fait 3 ans qu'il avait fait ca. Mais je ne crois pas que y a 3 ans il y avait deja cette histoire de sous ensemble d'API pour les drivers proprios.
Maintenant la question est de savoir si il y a les specs complete de la cam et si on peut reecrire son bidule sans passer 3 mois à reverse enginerer les anciens drivers ou ceux de win.
Si ya pas les specs complete et publique, franchement, personne ne peut prétendre ne pas avoir été prévenu du risque de perte partielle de performance... Avec tout ce qui a été expliqué mainte et mainte fois sur le sujet... Et j'en remet une couche : qu'en on utilise un driver proprio qui implement des fonctionnalités non documenté d'un matériel, on s'expose au risque qu'il disparaisse. C'est dommage mais ce n'est surrement pas de la faute des developpeurs du noyeau qui sur le coup sont on ne peut plus coherent avec leur politique... Si on commence a autoriser que chaque driver libre ait un hook pour implenter un driver proprio qui gerera les fonctions interressante du materiel, on se retrouve vite avec une grosse bouse.
Si y a les specs completes et publique alors un driver libre complet renaitra surrement, ce qui est une bonne chose.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 7.
Ben justement, ils ont ete plutot incoherent en laissant faire pendant 3 ans, le temps que les gens se mettent a utiliser leurs webcams pour plein de trucs, y compris des gens n'ayant aucune idee de ce que la GPL est, pour finir par virer ce support du kernel et mettre tous ces gens dans la m...
Ils auraient du soit le refuser depuis le debut, soit trouver un arrangement pour faire en sorte qu'ils fonctionnent encore, mais la les seuls gens qui paient le prix ce sont les utilisateurs qui se retrouvent avec leurs matos qui marchait et qui ne marche plus.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Philippe F (site web personnel) . Évalué à 10.
Je pense que l'auteur est pas tout a fait objectif mais il n'en reste pas moins le resultat. Un perte nette pour tout utilisateur de linux.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 10.
Heu, non, moi, ça ne m'affecte pas du tout. J'ai pas de webcam.
Et j'ai pas l'intention d'en avoir une avant qu'il y ait clairement marqué sur la
boiboite "Linux 2.4" ou "Linux 2.4/2.6", comme pour les clefs USB.
"Si y'a pas de support pour X, j'achète pas". Message simple, efficace,
extrémement facile à comprendre même pour les plus gland des commerciaux,
fonctionne bizarrement trés bien dans le milieu professionnel, et bizarrement
trés mal sur le grand public...
--
S'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Philippe F (site web personnel) . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 8.
*?!* Si je puis me permettre cette expression de mon plus vif étonnement.
Y'a marqué "Linux 2.4" sur la boite (officielle) neuve du produit en
question ?!
Jusqu'à preuve du contraire : Non. Ce n'est pas le cas pour les clefs USB, si je
reprends mon exemple.
Pas marqué Linux© = Poubelle. (je sais, je suis un gros con, un radical, un
brutal, un talibanux. Mais c'est avec ce type de boycott passif que certains
constructeurs changent d'avis)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Fred Albrecht . Évalué à 2.
Je n'ai pas souvenir qu'il y avait marqué "Linux" sur la boîte de la carte nVidia que j'ai achetée il y a peu mais c'est portant pour son support Linux (Linux AMD64 plus précisément) que je l'ai achetée. Si on attend que ce soit systématquement écrit sur la boîte, on n'achète pas grand-chose.
Je crois que les seuls matériels dont je dispose qui étaient officiellement supportés sont mon lecteur de cartes OmniFlash (pour les appareils photo) et une carte Ethernet de je ne sais plus quelle marque livrée avec une disquette comportant un pilote tout pourri pour RH 6 (mais elle est supportée par le noyau de base).
Sinon vu que mes machines sont quasiment 100% Linux (sauf pour les jeux et mon prochain portable qui sera probablement un Powerbook), il va de soi que je me documente longuement avant d'acheter un matériel qui risque de poser problème. Mais attendre un engagement officiel des fabriquants est illusoire. Obtenir un engagement officieux est déjà bien (et avec quelques mails on l'a déjà assez souvent).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gabuzo . Évalué à 1.
Ça aurait changé pas mal de chose si un fabricant avait effectivement marqué compatible Linux sur sa boîte. Si ça avait été le cas cela aurait voulu dire que le fabricant s'engageait sur la compatibilité. Donc en cas de retrait du noyau du hook comme cela s'est fait il aurait probablement livré un module externe.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Éric (site web personnel) . Évalué à 2.
Pour les clés USB la mienne a sur la boite marqué "compatible Linux" (sisi).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Fred Albrecht . Évalué à 2.
À l'inverse nVidia qui semblent être ceux qui se fatiguent le plus pour sortir des pilotes régulièrement (même si ceux-ci sont "fermés") n'ont pas de marquage particulier sur leurs produits (enfin évidemment ils ne vendent habituellement pas leurs produits en direct).
[^] # Pilotes binaires linux
Posté par Rafael (site web personnel) . Évalué à 1.
C'est la raison qui m'a fait préférer un ibook à un powerbook.
Rafael
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jean Parpaillon (site web personnel) . Évalué à 10.
Maintenant que les contructeurs ont compris que Linux existe, il va falloir passer à la vitesse supérieure, c'est à dire que les constructeurs comprennent qu'ils n'ont rien à perdre à faire des pilotes libres.
Parce que, d'accord, les solutions de secours existent (reverse ingeneering ou drivers propriétaires) mais ça laisse encore beaucoup de matériel de côté : modems internes (et oui, ça sert encore), cartes graphiques, webcams, modems ADSL, etc.
Peut-être faut-il rappeler l'intérêt d'un pilote libre : portage facile, pérennité, etc.
C'est peut-être pratique d'avoir un pilote linux pour son matériel xyz, mais si ça marche que sur le noyau 2.4.24 ou 2.6.4 et qu'un autre matériel ne fonctionne qu'avec un noyau 2.5.43, c'est pas vraiment une solution.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à -1.
Non, non.
Depuis Linux 2.4 (milieu 2.4) et surtout 2.6, le mécanisme a été renforcé avec EXPORT_SYMBOL. Avant il fallait auditer manuellement le code et maintenant non.
> les seuls gens qui paient le prix
pasBill pasGates tu supportes pas un OS payant "à tous les étages" ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 1.
Ce qui ne change rien, jusqu'a il y a peu, ca marchait, et ca a marche pendant 3 ans.
pasBill pasGates tu supportes pas un OS payant "à tous les étages" ?
Plutot qu'essayer de lancer un troll n'ayant rien a voir avec le sujet, concentres toi sur le sujet en question.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à -8.
>
> Plutot qu'essayer de lancer un troll n'ayant rien a voir avec le sujet, concentres toi sur le sujet en question.
Ce n'est pas hors sujet. Linux "dicte" son utilisation (avec EXPORT_SYMBOL, etc).
De plus Linux est une exception à la GPL qui permet d'utilise les modules binaires (dictature douce et ouverture au binaire incompatible avec la GPL).
Et encore "de plus", rien empêche le "Monsieur" de diffuser un patch pour le noyau si c'est nécessaire pour son driver.
Donc, il n'y a aucun problème s'il fait preuve d'un minimum de bonne volonté.
Avec MS, si tu (le développeur du driver et l'utilisateur) n'alignes pas le pognon, t'es "klonqué". Si tu as besoin de patcher le noyau, tu ne peux pas, etc...
Donc pasBill pasGates, tes leçons de morale aux développeurs de Linux (en les accusant presque d'intégristes/fanatiques du logiciel libre) sont très mal placées, et j'ai presque envis de t'inviter à te casser d'ici (pour ce thread seulement :-)).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par mdlh . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à -2.
PBPG à dit :
Ils auraient du soit le refuser depuis le debut, soit trouver un arrangement pour faire en sorte qu'ils fonctionnent encore, mais la les seuls gens qui paient le prix ce sont les utilisateurs qui se retrouvent avec leurs matos qui marchait et qui ne marche plus.
PBPG : "Ils auraient du soit le refuser depuis le debut"
C'est le mainteneur de pwc qui a fait l'erreur ! C'est lui qui a _présenté_ son code comme GPL alors qu'il ne l'était pas.
PBPG : ", soit trouver un arrangement"
Un arrangement avec du proprio ! C'est limite de la provocation.
Puis il n'y a pas d'arrangement à faire avec une licence. Surtout avec la GPL car il faut que tout le monde soit d'accord. Il est pratiquement impossible de changer la licence (GPL) de Linux et ça PBPG le sait.
Linux n'a pas demandé comme arrangement de mettre tout le driver sous GPL comme l'exige la licence GPL _choisi_ par le mainteneur.
PBPG : "pour faire en sorte qu'ils fonctionnent encore"
Le mainteneur (NB : qui n'est pas Philips et qui manifestement en a rien à foutre de Linux depuis au moins 1 an) peut toujours proposer le driver.
Linux (le mainteneur USB) a seulement "corriger" un fichier pour qu'il respecte la GPL. Ça n'a pas fait plaisir au mainteneur et _il_ (pas Linux) a demandé la suppression complète de son drivers.
NB : n'importe qui peut maintenant ajoute le driver puisqu'il était sous GPL (la version vraiment sous GPL:-)).
Le mainteneur est libre de proposer tous les patchs sur son site "qui vont bien" pour "faire en sorte qu'ils fonctionnent encore". Mais Linux ne peut pas car il y a une licence qui l'engage vers ses l'utilisateurs et développeurs => Il faut du libre.
Ça aussi PBPG doit le savoir (ou alors il est un peu c.. vu depuis le temps qu'il traine ici).
PBPG : ", mais la les seuls gens qui paient le prix ce sont les utilisateurs qui se retrouvent avec leurs matos qui marchait et qui ne marche plus."
Je trouve PBPG, bien "facile" de critiquer Linux et trouver Linux trop stricte, "manquant de coeur".
Là il n'y a qu'un développeur, pas de pognon, des sources qui ne respectent pas la licence de Linux et aucun soutient de Philips depuis 1 an (pas NDA, pas de doc) !
Imagine la même situation avec Windows (OS "référence" de PBPG) :
- Un développeur, pas de pognon, une licence incompatible avec la licence de Windows et aucune doc pour bosser.
Question à PBPG :
- "Tu croix que MS serait plus "coolant", plus généreux que Linux et que tu retrouverais le driver en standard dans Windows ?"
Évidemment que non.
De plus avec Linux, tu peux contourner le problème (mettre tous les patches qui vont bien à part et tout recompiler). Ceci est impossible avec Windows.
Btw, l'utilisateur "paient le prix" de quoi (sous Windows ou Linux) :
- L'utilisateur paye Windows
- L'utilisateur paye la carte. Pognon de la carte qui paye les développeurs pour le driver Windows (+les licences de développement Windows :-)) et pognon aussi donné à Microsoft pour avoir le label "design for Windows" ou pour être en standard dans Windows et autres conneries de ce type.
Donc, et ironie, un acheteur Linux de périphérique, souvent paye les développements "close source" du drivers sous Windows rien qu'en achetant le périphérique. Les développements étant "close source" ils ne profitent pas à Linux (le driver Linux étant souvent développé bénévolement).
L'utilisateur Linux se retourve "comme un con" à payer le driver Windows (qui ne lui sert à rien) et à ne rien avoir pour Linux.
Donc, qui fait "payer le prix" à l'utilisateur Linux et sans fournir de driver ?
- Philips et Microsoft.
> Pour le coup PbPg n'a traite personne d'integriste.
Ben il a une vision bien spéciale de la situation (et toi aussi).
PS : je donne l'impression d'être dure avec le mainteneur de pwc, mais le "gros crétin" dans l'histoire, c'est Philips.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par isydor . Évalué à 2.
je traîne depuis un peu de temps sur linuxfr et là j'ai découvert des trucs :)
excellent d'avoir pensé à ça : en achetant du matériel, on paye aussi pour le développement des pilotes, l'achat de l'étiquette "designed for widowsXX".
(alors que ça ne nous sert pas)
brillant :)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à -2.
Ben voyons, ca fait 3 ans et tout le monde est au courant de la situation, faut pas te foutre du monde non plus.
Puis il n'y a pas d'arrangement à faire avec une licence. Surtout avec la GPL car il faut que tout le monde soit d'accord. Il est pratiquement impossible de changer la licence (GPL) de Linux et ça PBPG le sait.
Ben alors pourquoi donc permettent ils toutes ces exceptions avec les drivers graphiques, etc... ?
Ton histoire ne tient pas, trouves d'autres raisons pour accuser les autres de mauvaise foi.
Là il n'y a qu'un développeur, pas de pognon, des sources qui ne respectent pas la licence de Linux et aucun soutient de Philips depuis 1 an
T'as oublie d'ajouter : Et un module qui a ete accepte pendant 3 ans et que plein de gens utilisent
De plus avec Linux, tu peux contourner le problème (mettre tous les patches qui vont bien à part et tout recompiler). Ceci est impossible avec Windows.
Avec Windows le probleme ne se pose pas, t'as pas besoin de recompiler le kernel pour faire marcher un driver.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 5.
Avec Linux non plus, je te rassure ;) C'est pas le kernel qu'il faut recompiler mais le driver ;)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
Il y a plein de société qui rève de patché Windows et recompiler. Mais ce n'est pas possible.
MS fournis les sources à quelques clients sélectionnés il me semple. Ce n'est pas pour patcher les sources et recompiler ?
C'est pour quoi si ça ne sert à rien ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 3.
J'attends toujours un exemple ou patcher le kernel serait necessaire pour faire tourner un driver
MS fournis les sources à quelques clients sélectionnés il me semple. Ce n'est pas pour patcher les sources et recompiler ?
Non, c'est pour auditer le code, faire de la recherche,... ils n'ont pas le droit de modifier les sources et deployer les binaires modifies.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par ced . Évalué à 1.
Certains drivers pour Microsoft™ Windows© XP ne fonctionneraient pas avec la mise à jour Service Pack 2 installée.
Après moi je connais pas assez Windows© pour dire si une telle mise à jour remplace le noyau ou non, mais c'est ce que les autres ont voulu dire.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à -1.
Comment ose-tu dire ça sérieusement ?
Dans quel cas, je doit rebooter ?
=> lorsque je change de noyau
Pourquoi changer de noyau
=> car il a changé !
Comment a-t-il changé
=> avec un patch !
C'est bon, tu suis toujours, c'est pas trop compliqué ?
Quel est l'OS qui demande le plus de reboot pour un driver ?
=> Windows
Ce n'est vraiment pas chance.
Autre exemple.
Par exemple, Windows n'a pas ATM et tu ajoutes un driver qui uilise ATM.
=> faut patch/recompiler
Certe, ce n'est pas toi qui le recompile mais tu n'as plus le même noyau (c'est SP1 ou 2 ou 4587 mais ce n'est plus le même). C'est obligé.
Certe, la modification n'a pas été faite avec un patch mais la différence entre les sources des noyau avec et sans ATM peut-être ramener à patch. C'est un peu l'objectif de patch, si tu n'as remarqué :-)
Autre exemple.
Windows 95 n'avais USB (c'est une version très très très très buggé) et il a fallu attendre la version OSR2 pour avoir un truc potable.
=> Nouveau noyau (donc patch et recompilation) pour des drivers USB.
Autre exemple.
Drivers pour gros disque dure. Quand il a fallu dépasser l'énorme valeur 8 Go pour Windows :-)
=> Nouveau noyau
Autre exemple.
Non, tu es d'une mauvaise fois infini.
Reviens quand Windows ne demandera pas de rebooter lorsque t'installes un drivers, change de couleur de fond d'écran, etc...
Ou explique nous quel est le caca dans Windows qui impose de rebooter 1000 fois plus souvent qu'avec Linux.
Merci.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Larry Cow . Évalué à 8.
Autant pour toi.
Reviens quand Windows ne demandera pas de rebooter lorsque t'installes un drivers, change de couleur de fond d'écran, etc...
Tu devrais utiliser Windows plus souvent (en fait, non, mais au moins tu pourrais critiquer sans dire de la merde). Sur 2000 ou XP, rares sont les drivers qui demandent un reboot (le seul exemple que j'ai sous le coude c'est la carte vidéo).
Ou explique nous quel est le caca dans Windows qui impose de rebooter 1000 fois plus souvent qu'avec Linux.
Très honnètement, c'est de moins en moins vrai (on pourrait même argumenter que ce n'est plus vrai du tout). En six mois d'utilisation de Windows, les seuls reboot "fréquents" sont ceux liés au besoin de remplacer un fichier utilisé par le système (ça semble très chiant à l'utilisateur linux que je suis, mais dans l'idée c'est pas plus stupide pour éviter certaines merdes).
Au final, tu as _beaucoup_ de raisons philosophiques ou morale de critiquer Windows, tu as suffisament de raisons techniques également. Alors inutile de rajouter des affirmations péremptoires non-appuyées (tautologiquement), ça donne vraiment pas une image crédible de toi (ni de la communauté, pour ceux qui sont amateurs de généralisations abusives).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
C'est vrai que j'ai arrêté avec Windows NT4.
Mais je ne vais pas suivre ce conseil :-)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Volnai . Évalué à 7.
Je ne veut pas me battre contre la machine, alors je reboote betement (et je perds 10 minutes, bah oui, windows 2000 c'est un peu long a booter au bout d'un moment).
Alors bon, 007 n'a peut etre pas utilisé de windows depuis longtemps, mais moi j'en utilise un tout les jours. Et un linux aussi, et des BSD aussi, et tiens même des Solaris. Et clairement, celui qui reboote le plus est le windows; alors que paradoxalement j'installe vachement moins de drivers/modules dessus (le dernier en date est un driver de touchpad -> reboot), et que je fait des truc vachement plus sympa (BD, routage, vpn, test cartes pci exotiques... et j'en passe) avec mes machines de test sous linux/bsd qu'avec mon poste de travail bureautique sous windows.
C'est mon expérience, ca n'engage que moi, mais faudrait voir a arreter de déconner, windows s'est énormement amélioré au niveau des reboot, mais c'est encore du foutage de gueule par rapport aux autres systèmes.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par mickabouille . Évalué à 3.
Il rebootait chaque fois.
Une fois quand on a ajouté le pilote de carte éthernet.
Une fois pour le pilote TCP.
Une fois quand j'ai changé l'adresse IP.
Il faut qu'il reboote à chaque fois qu'il change de réseau et modifie son adresse IP.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 2.
1) La stack IP est presente par defaut, pas besoin de l'installer
2) Il n'y a pas besoin de rebooter pour changer d'addresse IP
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par mickabouille . Évalué à 2.
Faut dire que je suis un vrai boulet sous windows, j'y arrive pas :S
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Ph Husson (site web personnel) . Évalué à -1.
A part peut-être pour le pilote de la carte ethernet (j'en sais trop rien la dessus)
Le reste peut etre fait a la volée ou est deja fait par defaut
A moins qu'il y ai eu regression entre win 2k et xp mais bon faut le faire
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gabuzo . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 8.
"Très honnètement, c'est de moins en moins vrai (on pourrait même argumenter que ce n'est plus vrai du tout). En six mois d'utilisation de Windows, les seuls reboot "fréquents" sont ceux liés au besoin de remplacer un fichier utilisé par le système"
Mouahah, le vieux mensonge :p
C'est marrant, mais a chaque formation Microsoft que j'ai faite, Active Directory pour la derniere, tu passes ton temps à rebooter la machine... Le jour ou tu pourras faire un dcpromo sous windows sans rebooter, on en reparlera ;) Si je me souviens bien, quand tu install le dns via le admin.pak, il te demande aussi de rebooter.
apt-get install openldap samba bind et pas besoin de reboot.
Quand tu passes un 2000/2003 en controleur de domaine, le truc se met a ramer comme une merde... C'est trop bon à la formation, dcpromo, reboot, et la : "Monsieur, c'est normal que ca rame" et le formateur dégouté... Et pourtant c'etait des beaux pc Dell avec beaucoup de ram et un bon proc. Ben mon pauvre laptop(cerelon 900 et 192 Mo) sous Suse + ldap + samba boot trois fois plus vite( 2x en comptant le démarrage de Kde).
Mais bon, bien sur, comme d'hab, c'est pas vrai, on est de gros menteurs, ca n'arrive jamais, j'as pas vu deux windows 2000 mettrent 15 minutes pour booter aujourd'hui... Mais bon, ca peut arriver un probleme, sous Linux aussi, mais vu la verbosité du boot windows, ca aide vachement a comprendre le probleme... (et rien dans les logs :p)
Et qu'on vienne pas me dire que c'etait une formation de merde ;) Elle etait Microsoft Powered la formation meme que j'ai un papier signé de la main de Steeve Balmer qui dit que je sais me servir d'une souris. Ce qui est faut vu que le formateur m'a lancé deux fois la ligne de commande pour désactiver certaines options que la GUI refusait de remettre à leur état d'origine. Je pourrais aussi parlé de WMI avec le formateur qui te montre comment recupéré le nom de l'utilisateur du processus sur la machine d'a coté et que t'as bien envie de lui dire que ses dix lignes de code, tu fais la meme chose en 1 ligne sous Linux :)
Ah, ca fait du bien :) Quel rapport avec la choucroute? Aucun :)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Larry Cow . Évalué à 2.
J'aurais du préciser, mea culpa.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Dafatfab . Évalué à 0.
Bilan : 2 reboot obligatoires pour une vulgaire maj de securité ""critique"" :-)....devinez les quels des 2 des 3 serveurs il a fallu rebooté alors que ce sont des serveurs qu'utilisent ts le monde tout le temps ??
arf...windows ca reboot tjs comme un 98...
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 4.
Ben c'est tres simple, j'utilises Windows et j'ai des yeux et un cerveau
Dans quel cas, je doit rebooter ?
=> lorsque je change de noyau
Pourquoi changer de noyau
=> car il a changé !
Comment a-t-il changé
=> avec un patch !
Je vais t'apprendre un truc gigantesque : Quand tu ajoutes le support ATM a Windows, tu ne changes pas le noyau, tu charges un driver, un fichier separe, comme un module sous Linux.
Si tu veux modifier ATM, tu ne modifies pas le noyau, tu modifies le driver. Il n'y a _pas besoin_ de toucher au noyau
Par exemple, Windows n'a pas ATM et tu ajoutes un driver qui uilise ATM.
=> faut patch/recompiler
Non c'est faux, tu charges le driver ATM, tu ne touches pas au noyau.
Drivers pour gros disque dure. Quand il a fallu dépasser l'énorme valeur 8 Go pour Windows :-)
=> Nouveau noyau
Non, nouveau driver IDE
Non, tu es d'une mauvaise fois infini.
Je dirais plutot que c'est toi qui est un ane qui ne comprend rien a Windows et ne sait pas du tout comment il fonctionne.
Reviens quand Windows ne demandera pas de rebooter lorsque t'installes un drivers, change de couleur de fond d'écran, etc...
C'est bon je suis de retour.
T'es franchement pathetique, rien de ce que tu ne dis ne tient debout.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à -6.
Si tu passes en 64 bits d'adressage memoire, t'ajoute ipv6, nouvelle gestion de la vm, utilisation des instructions K7 avec SSE2 au-lieu de i386, ajout de SeWindows (l'équivalent d'SeLinux), activation des informations de debug, controle de débordement de la stack, NTFS V10 qui support le zerocopy depuis le réseau via l'appel système sendfile(), etc...
Réponds pas,
j'ai deviné => nouveaux drivers et pas de reboot.
Putain, c'est beau.
C'est clair, je connais bien Linux ((((("""""et si ce que tu dis est vrai"""""))))), je peux t'affirmer que Linux est complètement largué, à la ramasse de à la ramasse.
Putain, le mythique hurd vient de se prendre une mega baffe.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 6.
Tu continues a t'enfoncer.
Tu veux ajouter IPv6, effectivement tu ne changes pas le noyau, IPv6 c'est un driver(tcpip6.sys), tout comme IPv4 l'est. Tu vas sur XP, tu tapes dans une ligne de commande : ipv6 install, la stack IPv6 est installee, pas besoin de reboot.
Je vais meme t'apprendre un truc magique, tu peux enlever la stack IPv4 en tapant : net stop tcpip dans une ligne de commande(a condition qu'aucun driver n'ait de handle sur le driver bien entendu), pas besoin de recompilation, pas besoin de reboot non plus.
Tu veux updater NTFS, effectivement tu ne touches pas au noyau, NTFS c'est un driver, il s'appelle ntfs.sys d'ailleurs.
Les 64bits, c'est un passage de plateforme, rien a voir.
K7 ou SSE2 je vois pas le rapport, si t'updates le noyau pour les supporter, t'as pas besoin de toucher les drivers. Si tu veux que ton driver en tire partie, pas besoin de toucher le noyau, juste le driver
Activation des infos de debug non plus, il y a tout un systeme de tracing, et si tu veux plus, il y a la version debug du noyau dispo dans ce qu'on appelle la version "checked" de Windows.
Controle des debordements de la stack non plus, si tu les veux dans le driver, faut evidemment recompiler le driver, pas le noyau
etc...
Le jour ou tu comprendras que rebooter != changer le noyau et que driver != noyau, t'auras fait un grand pas dans ta comprehension de l'informatique
Tu ferais mieux de t'arreter maintenant, t'as eu l'air assez idiot deja.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à -4.
Avec Red Hat et Fedora, le noyau et les modules vont ensembles.
Lors de la mise à jours du système l'un va toujours avec l'autre.
En phase de développement, c'est l'enfer, il faut rebooter (gnagna, changer de noyau) parfois tous les 2 jours.(*)
Exemple :
http://fw07.dmacc.net/rawhide-reports/(...)
kernel-2.6.8-1.526 : le 23/08
kernel-2.6.8-1.525 : le 21/08
kernel-2.6.8-1.524 : le 19/08
Mes amis, j'en ai plein le cul de cet OS complètement "has been".
> t'as eu l'air assez idiot deja.
Tu es si intelligent TOOaa.
Vu le niveau de Windows, fichtre, faut être con pour utiliser Linux.
Je viens même d'apprendre que ntfs est dans le fichier ntfs.sys et qu'on peut le remplacer à chaud.
Et ce truc, dingue de chez dingue :
ou peut ajouter ipv6 à chaud.
Oyé Oyé amis Linuxiens!
Je cite notre espion MS :
- "Tu vas sur XP, tu tapes dans une ligne de commande : ipv6 install, la stack IPv6 est installee, pas besoin de reboot."
"pas besoin de reboot",
et il faut seulement taper "ipv6 install". vous avez bien lu.
Amis Linuxiens, reconnaissez le avec moi :
c'est fou !
Il y a encore deux ou trois rumeurs folles de ce calibre, mais je préfère attendre confirmation avant de les communiquer.
C'est claire, face à windows, on peut tous allez se rhabiller.
(*) : je ne vais pas dire pourquoi, j'ai honte.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 2.
C'est pas que j'ai qq chose à te reprocher, juste que c'est marrant que le fait que win soit pas la bouse finie à laquelle tu t'attendais en tant que end user te mettes autant en colère :p
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à -1.
Tu n'y es pas.
J'ai deux frères informatiens.
Je suis aussi l'informaticien. Moi c'est Unix/Linux et eux Windows.
J'ai utilisé Windows jusqu'à NT 4 (après j'ai décroché).
Mes frères sont d'intécrotables windowsiens (totalement insensibles au logiciel libre, sa philosophie, etc).
Malgrès ça ils ne pipotent pas.
Si tu lis mes posts, a aucun endroit (ou presque) je mets un truc du type :
- Linux c'est mieux que Windows.
Je m'énerve sur le FUD de pb pg qui avance des choses fausses :
- intérêt de patch ou recompiler le noyau windows
- avec linux il faut recompiler le noyau pour installer un driver
- pas de compatibilité binaire car c'est un OS libre
- Les dev Linux sont pas cool avec les utilisateurs de pwc qu'ils laissent tomber.
- etc...
Mes frères ne me sorte jamais de tels conneries !
Pour le côté "bouse finie", Windows n'est pas de la bouse. J'ai dit que mes frères ne pipotaient pas et il ne m'ont jamais dit que Windows était une bousse (Sauf NT qui rebootait tous seul ou restait figé :-)).
D'ailleur nul part j'ai dis ça. Sauf pour les reboots de Windows (et avec Win 9x et Win NT que j'ai connu, je (et mes frères aussi) confirme très très fort qu'il faut rebooter 50 fois le bousin à l'installation du moindre driver).
Pour bien te montrer que j'en est rien à foutre que Windows soit mieux ici ou là, les "ntfs.sys", "ipv6 install", le changement à chaud de driver, de pile tcp/ip etc, me laisse totalement indifférent, mais ça m'amuse de faire croire à PB PG qu'il m'impression.
Linux fait tout ça, très bien, et depuis longtemps (Linux 2.0 (à l'époque de win95) et avec le chargement à la demande).
C'est dire si ça ne m'affole pas de voir pb pg trouver des qualités à Windows :-)
Par contre, son FUD sur Linux me les brise, d'autant plus qu'il y a une majorité de personne ici (linuxfr) qui croit au FUD récurrent de PB PG.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 2.
- intérêt de patch ou recompiler le noyau windows
- avec linux il faut recompiler le noyau pour installer un driver
- pas de compatibilité binaire car c'est un OS libre
- Les dev Linux sont pas cool avec les utilisateurs de pwc qu'ils laissent tomber.
- etc...
1) Tu m'as toujours pas montre un seul driver qui demandait de patcher le noyau Windows, pourtant j'ai fait des demandes repetees
2) J'ai jamais dit ca
3) Jamais dit ca non plus
4) J'ai critique l'auteur de pwc ? Non, pourtant c'est un dev Linux. Mais bien sur, des que j'emets une critique et que le mot Linux est a moins de 100m, tu prends ca pour une critique de l'ensemble Linux
Bref, tu t'enfonces encore plus.
Pour bien te montrer que j'en est rien à foutre que Windows soit mieux ici ou là, les "ntfs.sys", "ipv6 install", le changement à chaud de driver, de pile tcp/ip etc, me laisse totalement indifférent
Bien sur ca te laisse totalement indifferent, c'est pour ca que tu nous a pondu une liste de 10 trucs differents(et tu t'es ramasse sur chacun d'eux) soi-disant demandant une recompilation du noyau, t'avais surement rien d'autre a faire a ce moment la et tu t'es dit que ca serait drole de faire une liste fantaisiste.
mais ça m'amuse de faire croire à PB PG qu'il m'impression.
T'as pas idee a quel point c'est important pour moi d'impressionner qq'un qui est borne, grossier et qui ne sait pas de quoi il parle.
Tu devrais te recycler dans la speologie, t'as des qualites indeniables pour ce qui est de t'enfoncer.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
Mais c'est de la SF (science-fiction).
Mais comment je fais ?
- JE N'AI PAS LES SOURCES
- TOUT EST PROPRIO SOUS WINDOWS
- PERSONNE À PART MS PEUT PATCHER WINDOWS
Pour Linux tu transformes un "on peut compiler Linux ..." en un "Il faut compiler Linux..."
Pour Windows tu transforme un "on ne peut pas compiler windows..." en un "Il n'est pas nécessaire de compiler windows..."
T'es salement pervert car après tu me demandes de démontrer qu'll est nécessaire de compiler windows alors que tu sais qu'on ne peut pas compiler windows !
Ce n'est pas parce que je ne peut pas voler à mach 1 qu'il n'est pas intéressant et/ou necessaire d'aller à mach 1. btw, ne me demandes de voler à mach 1 pour te démontrer que c'est intéressant. C'est comme pour la compilation de Windows, je ne peux pas.
Sinon, tu joues le jeu et tu me donnes un acces CVS ou Source Safe ou je_sais_pas_quoi avec les sources de windows.
Idéalement il faut aussi les log comme ça on verrait des trucs :
- fix for driver bidule
- add support for firewire
- etc
Tu dis que le noyau n'a jamais besoin de patch ou d'être compilé, alors démontre le.
Trouves une pages sur www.microsoft.com qui indique les fichiers mise à jours, dis quel est le fichier lié au noyau et on regarde l'historique du noyau.
Normalement (selon toi) il n'y aura rien pour le noyau (jamais nécessaire de le compiler selon toi).
Tu dis qu'il est inutile de patcher/compiler le noyau pour un driver. OK, donc n'importe quelle driver soit marcher sur toute les versions de Windows.
Si un driver ne marche pas sous win 2000 mais marche sous win 2000 SP2, c'est qu'il faut patcher/compiler le noyau (patcher win 2000 pour en faire un win 2000 SP2) pour que le driver fonctionne.
Trouve moi un truc ou une doc qui montre que tous les drivers marchent pour toutes les versions de Windows.
Tu dis que ça sert à rien de patcher/compiler Windows, alors pourquoi Microsoft ne met pas les sources à disposition ?
Que risque MS puisque tu répètes qu'il n'est pas nécessaire de patcher ou compiler windows. Si ce n'est pas nécessaire (car tout est déjà parfait, nickel et adapté aux nouveaux périphériques des 20 prochaines année) alors personne ne va le faire. Si personne le fait, que risque MS ?
Au pire il faut mettre un driver à jour (genre ntfs.sys). Mais ça, ce n'est pas le noyau.
T'es dans un boîte proprio, c'est à toi de faire la démontration. Ou alors tu me donnes accès au CVS de Windows.
Sur ce, bon journée.
Je te félicite pour la qualité de tes trolls (à ce demander si tu n'est pas coatché par MS).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 2.
- JE N'AI PAS LES SOURCES
- TOUT EST PROPRIO SOUS WINDOWS
- PERSONNE À PART MS PEUT PATCHER WINDOWS
Ben tu vois c'est pas si dur, tu viens de reconnaitre qu'il n'est pas necessaire de recompiler ce noyau pour que tes drivers fonctionnent vu que c'est pas possible et que ca marche quand meme
Pour Linux tu transformes un "on peut compiler Linux ..." en un "Il faut compiler Linux..."
Montres moi ou j'ai dit ca
Sinon, tu joues le jeu et tu me donnes un acces CVS ou Source Safe ou je_sais_pas_quoi avec les sources de windows.
Idéalement il faut aussi les log comme ça on verrait des trucs :
- fix for driver bidule
- add support for firewire
- etc
Inutile, t'as qu'a regarder le contenu des patchs qu'on sort, tu verras que les fichiers pour ATM, TCP/IP, etc... ne sont jamais presents en meme temps que les fichiers du kernel.
Bref, il n'y a aucune dependance de ces drivers vis a vis de la version du kernel
Tu dis que le noyau n'a jamais besoin de patch ou d'être compilé, alors démontre le.
Trouves une pages sur www.microsoft.com qui indique les fichiers mise à jours, dis quel est le fichier lié au noyau et on regarde l'historique du noyau.
Tu delires, j'ai pas dit qu'il n'avait jamais besoin d'etre patche, il est evident que pour corriger des bugs dans le kernel il faut le recompiler.
Tu dis qu'il est inutile de patcher/compiler le noyau pour un driver. OK, donc n'importe quelle driver soit marcher sur toute les versions de Windows.
Non, un driver qui depend de features presentes uniquement dans XP ne va evidemment pas marcher sur Win2000.
Si tu prenais la peine de t'informer avant de raconter n'importe quoi, tu irais lire le DDK de Windows et tu verrais que les drivers utilisent un API tres clairement defini et fige. Tant que ces drivers ne font pas de cochonneries(= trucs non documentes), ils continueront a tourner quel que soit le kernel. Evidemment si ils touchent a des trucs non-documentes et qu'on change ca, ils vont claquer.
Trouve moi un truc ou une doc qui montre que tous les drivers marchent pour toutes les versions de Windows.
Tous c'est impossible car certains font des trucs non documentes et donc vont casser.
La preuve est tres simple : tu regardes les patchs, et tu remarqueras que les fichiers du kernel ne viennent avec _aucun_ driver. Bref, il n'y a aucune dependance binaire entre le kernel et les drivers vu que tu peux installer ces patchs du kernel et tes drivers continueront a tourner. De meme pour les drivers, tu peux les installer sur Win2000/SP2/3/4 , et les drivers ne sont jamais livres avec un kernel, ils viennent tous seuls.
T'es dans un boîte proprio, c'est à toi de faire la démontration. Ou alors tu me donnes accès au CVS de Windows.
Elle est faite, la reponse est dans le contenu de nos patchs.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
btw, relis tous tes posts, tu verras que tu ne dis pas toujours la même chose.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Etienne Juliot (site web personnel) . Évalué à 1.
C'est impressionant les mecs !
Vous vous êtes engeulé comme ça toute la nuit !!!
Ca, c'est un troll qui devrait rester dans les mémoires de Linuxfr.
En plus, c'est le bon troll du style : "j'ai 10 ans, mes frères y font du windows, c'est nuuuul parce que ...... euh, bah je vais sortir des trucs techniques, ca va faire le mec qui s'y connait ..... ça pue".
pBpB, je trouve que là, tu as vachement été patient quand même. Le pb, c'est que ce sont des "défenseurs" de linux comme 007 qui disent des conneries grosses comme eux qui en fait le discrédite et l'amateurise.
PS pour 007 : j'ai fait du NT4 et du Win98 aussi, mais promis, ils se sont vachement améliorés depuis. Tant mieux. La concurrence est saine, et Windows n'est pas le mal absolue.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par isydor . Évalué à -1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -1.
Sous windows, on ne peut pas patcher on ne fait que remplacer des binaires...
"La première sécurité est la liberté"
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 0.
Tu installes VS.NET 2003, tu compiles ton soft avec le flag /GS, et oh miracle, ton soft aura le code pour detecter un stack overflow.
Le kernel n'a rien a voir avec la detection d'un stack overflow, pourtant tu n'as pas modifie un seul byte du kernel.
Tu peux avoir 2 drivers compiles pour ca, et le kernel ainsi que tous les autres drivers qui ne le font pas, c'est totalement independant du systeme, ca ne depend que du code genere par le compilateur pour le binaire.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnujsa . Évalué à 5.
Ça fait des années que tu joue à ce petit jeu. Tu pose un appât à troll dans le genre:
« Avec Windows le probleme ne se pose pas, t'as pas besoin de recompiler le kernel pour faire marcher un driver. »
Dans une news sur Linux, on comprend tous, forcement: « contrairement à Linux » même si tu le dit pas.
Et ensuite tu profite que quelqu'un s'énerve, pour mettre en avant un détail technique ou Windows serait supérieur à Linux.
Mais on s'en fout. On es un peu con, car on préfère Linux malgré qu'il soit beaucoup moins bien que Windows. Des tas de très grosse boite font aussi la même erreur, je comprend que ça te fasse râler. Et puis on a une sale manie aussi, on aime bien avoir quelque chose d'un peu plus consistent que du blabla comme preuve: Les sources.
Ma petite histoire:
Il y a quelques années, j'était sous Windows 98, puis je suis passé à Windows 2000. A ce moment là, mon scanner et ma webcam ne marchaient plus. Plus de pilotes. J'ai oublié le nom du scanner. Pour la webcam, il s'agissait d'une Creative Webcam II sur port parallèle. Et bien j'aurais été très content de pouvoir recompiler le noyau ou le pilote pour les faire fonctionner. Mais avec du logiciel propriétaire ça n'est pas possible.
pasBill pasGates: Mais tu n'aurais pas eu besoin de recompiler le noyau, juste le pilote.
Ça j'en sais rien, à part te croire sur parole. De toute façon, il s'agit d'un problème générale des logiciels propriétaires et pas que Windows.
Maintenant je suis sous GNU/Linux, et je dois avoir du bol, car je n'ai jamais eu à patcher mon noyau pour faire fonctionner mes périphériques, mais si c'est la seul solution, ça reste possible.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 1.
Faut croire que non vu que nicO a repris cet exemple precis.
Dans une news sur Linux, on comprend tous, forcement: « contrairement à Linux » même si tu le dit pas.
Si vous etes des paranos voyant des attaques contre Linux partout c'est franchement pas mon probleme, allez vous faire soigner, me demandez pas de me taire.
Et ensuite tu profite que quelqu'un s'énerve, pour mettre en avant un détail technique ou Windows serait supérieur à Linux.
Mais il faut arreter le delire mon cher, j'ai pas compare a un seul moment Linux dans cette histoire, je n'ai fait qu'expliquer a 007 que non, Windows ne fonctionnait pas comme il pensait.
Mais on s'en fout. On es un peu con, car on préfère Linux malgré qu'il soit beaucoup moins bien que Windows. Des tas de très grosse boite font aussi la même erreur, je comprend que ça te fasse râler. Et puis on a une sale manie aussi, on aime bien avoir quelque chose d'un peu plus consistent que du blabla comme preuve: Les sources.
Qu'est ce que tu veux que ca me fasse ? Tu m'as deja vu demander a qq'un de rester sous Windows plutot que passer a Linux ? Non, c'est encore ton imagination qui te fait croire que j'ai un probleme avec ca.
Et bien j'aurais été très content de pouvoir recompiler le noyau ou le pilote pour les faire fonctionner. Mais avec du logiciel propriétaire ça n'est pas possible.
Ben essaye de prendre un driver pour MacOS 9 et le recompiler sous Linux, tu verras c'est pas facile. Pourtant c'est ce que tu demandes ici, des drivers qui marchent pour 2 OS completement differents.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
C'est seulement linuxfr ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 0.
Bref, Linux j'ai pas attendu les belles GUI et la mode pour m'y mettre, ni d'etre chez MS pour m'y interesser.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnujsa . Évalué à 0.
Il s'est passé plein de chose depuis 1999. Tu devrai essayer le noyau 2.4 et surtout le 2.6, sinon tu est aussi crédible quand tu parle de Linux, que ceux qui parle de Windows 95/98
http://linuxfr.org/comments/416770.html#416770(...)
« Dans Linux, de ce que j'en ai vu(bref, jusqu'aux pre-2.4), la separation entre les elements et leur interactions n'etait pas aussi claire. »
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par mdlh . Évalué à 1.
Evidement il precise pas. Mais quand je lis "Linux depuis 95", je me dis qu'il y a du linux qui traine encore quelque part.
Je vais commencer par me poser des questions sur ma comprehension de la langue francaise. Ca a surement horriblement evolue depuis que j'ai quitte le territoire.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 3.
2) Mon commentaire parlait des entrailles du kernel, que je n'ai pas fouille depuis les pre-2.4, il parle pas du systeme entier. Si tu veux on peut faire un sondage du nombre de gens qui connaissent les structures interne du kernel ici, tu verras t'auras probablement pas besoin de plus d'une main ou deux.
Mais comme toujours, faut trouver une variation de mes commentaires qui satisfasse tes idees.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par isydor . Évalué à 2.
Encore une fois, si tu voulais améliorer ça tu te comporterais autrement. Après, tes motivations pour continuer comme ça t'appartiennent : caractère de cochon, joie du troll, orgueil, rémunération, ennui, peu importe... On peut même imaginer des trucs marrants comme la simple joie de voir que certains continuent à t'encourager au premier degré alors que tu as sciemment usé d'une astuce réthorique...
Ce qui est rageant, c'est ça, le fait que de manière plus ou moins involontaire tu sèmes la zizanie, alors que c'est pour de mauvaises raisons (c'est souvent la longueur du thread et la faiblesse du rapport contenu/bruit qui amènent cette zizanie).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par chl (site web personnel) . Évalué à 4.
Si j'ai bien compris, tu parles de PBPG, et je ne suis pas du tout d'accord avec toi.
Je prefere 100 fois un commentaire de PBPG, qui corrigera quelqu'un qui raconte n'importe quoi sur Windows, quitte a ce qu'il y ai ce que tu appelles une zizanie (moi j'appellerais ca de la "non pensée unique"), plutot que de lire des commentaires de gars qui pensent que Linux c'est parfait, genial et que MS Windows de la merde en barre, alors qu'il ne connaissent que W98.
C'est pas parcequ'on aime bien tous GNU/Linux, que l'on doit se voiler la face et ne pas entendre parler de MS Windows, ni dire qu'un mec qui en parle le fait forcement pour foutre sa merde/zizanie, ou troller.
Trop de pensée unique, tue la liberté d'expression et l'ouverture d'esprit.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par isydor . Évalué à 2.
Mon message n'a rien d'un appel à la pensée unique, je rappelle simplement que pour qu'un message soit entendu il faut _s'adapter_ à celui qui est en face, sinon on a droit au début à un dialogue de sourds et à la fin à des insultes, ce qui n'apporte rien. grosso modo, ici nous sommes dans un environnement _linux_, avec des gens _linux_, si pbpg veut parler de _windows_ qu'il s'adapte, qu'il y mette les formes, sinon de toute façon il ne sera pas correctement entendu. Je remarque qu'il ne fait pas cet effort, cf mon premier commentaire. Je m'interroge - sur un ton amusé - sur ses motivations.
C'est de la pensée unique, franchement ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
J'ai jamais dit que Windows était de la merde en barre ou un bouse ou un mauvais système ...
Arrête d'affabuler.
Je ne savait pas qu'il y avait un fan club de Windows ici.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par chl (site web personnel) . Évalué à 2.
Arrête d'affabuler.
Tu passeras le bonjour a tes 2 freres ! \o_
Je ne savait pas qu'il y avait un fan club de Windows ici.
Je vois pas pourquoi je serai membre d'un fan club de Windows ! Mais si ca peut te faire plaisir, j'invite tes 2 freres, a s'inscrire avec nous ! :)
Le fait d'utiliser GNU/Linux n'impliquent pas automatiquement d'etre anti MS Windows, agent 007.
Cependant, les mecs comme toi qui racontent 3 conneries a la minute sur MS Windows, pour dire que Linux c'est mieux, ca m'interesse pas, et je pense pas etre tout seul.
En conclusion, TU racontes pas mal de conneries, PBPG non. Le fait qu'il defende MS windows est secondaire.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à -1.
Un pro-Windows encore plus con que le plus con des pro-Linux...
> Le fait d'utiliser GNU/Linux n'impliquent pas automatiquement d'etre anti MS Windows, agent 007.
Tiens, j'ai dérapé dans un de mes commentaires aujourd'hui :
http://linuxfr.org/comments/466896,1.html(...)
Windows n'est pas une merde.
Question à toi, donneur de leçon de mes couilles (car j'en ai un peu marre), à part avoir dit que Windows demandait beaucoup de reboot, quelles sont les critiques que j'ai formuler contre Windows ?
En conclusion :
Le fait d'être pro-Windows, ne t'impose pas de dire des conneries.
PS : Je n'ai pas dit que mes frères étaient fan de Windows ou pro-Windows mais seulement qu'ils étaient d'"indécrottables windowsiens". Ils sont trop habitués à ce système et n'ont pas envis d'allez voir ailleur.
C'est différent. Ils seraient pro-Windows, ils feraient comme PBPG ou toi et viendrait ici "fuder" sur Linux.
PS2 : j'en ai vraiment marre des petits donneurs de leçon de merde en ton genre.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Stibb . Évalué à -1.
Je suis meme sur qu'avec un pauvre driver en kernel space tu peux le faire...
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 21rdoma . Évalué à 1.
le problème est donc qu'il doit rester sous un os difficilement sécurisable(*) aka windows 98 parcequ'il n'a pas de driver pour sa webcam
c'est cool windows
* ce n'est pas de moi mais de la résponsable des systèmes d'exploitation chez microsoft qui le dit
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par nullisimo . Évalué à 2.
C'est impressionant les mecs !
Vous vous êtes engeulé comme ça toute la nuit !!!
Ca, c'est un troll qui devrait rester dans les mémoires de Linuxfr.
Et tout ca juste pour une histoire de compatibilite d'ABI ;-)
Windows conserve, au moins par major version une ABI compatible, mais pas forcement linux.
En effet, joli dialogue de sourds...
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jean-Baptiste Mayer . Évalué à 6.
Si Windows permet d'installer des drivers sans avoir à trop réfléchir sur les compatibilités des drivers, c'est parce que les API sont stables (et c'est sûrement ça qui fait que Longhorn soit largement retardé par rapport au planning initial, me trompé-je?), et parceque l'abi du compilo utilisé l'est aussi.
Le problème de pwc est un changement brutal d'api du noyau: et dans un modèle où les développeurs du noyau sont subordonés à ses utilisateurs (relation fournisseur-client -- comme MS), ce genre de chose ne peut pas arriver.
C'est deux logiques qui s'opposent: une logique d'évolution rapide, où l'existant ne pose pas trop de problème car la recompilation est possible à faible coût, et une logique de maintien de l'hérité, car la recompilation n'est pas possible.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
Encore une preuve que le FUD de pb pg marche super bien.
Vous comparer ce qui n'est pas comparable.
Si vous comparer Winows XP, qui est un produit bien supporté, professionel (c'est à dire fait pour que d'autres boîtes puissent développer/invertir dessus), avec Gentoo ou Fedora, alors oui la stabilité de l'api de GNU/Linux en général est nullissime.
Gentoo/Fedora/Mandrake/etc c'est un peut la version de développement de GNU/Linux, le Longhorn de GNU/Linux.
Par contre prennez une distribution bien supporté type RHEL et là vous aurez 5 ans d'api absolument stable et aussi la compatibilité avec la version N-1.
Les gros distributeurs intègrent les contraintes commerciales professionnelles qu'on ne peut demander à la communauté.
La communauté est fun, elle aime aller de l'avant et pas faire des bugfix et des backport de sécurité avec une api qui ne doit pas bouger pendant 5 ans.
Faire ça gratuitement à la demande de sociétés commerciales qui veulent un api stable pour garantir leur investissement : non merci.
On peut aussi remarquer que certains gros projet n'ont pas d'évolution d'api très rapide. Gnome est compatibible source et binaire pour toutes les versions 2.x . KDE doit avoir un truc de ce type pour les version 3.x (à confirmer).
Il reste quoi en "incontrôlable" => le noyau.
Ce n'est pas le bout du monde. Les gros distributeurs sont à même de rendre l'évolution du noyau d'une distribution "pro" ... très ennuyeuse.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 0.
Vous comparer ce qui n'est pas comparable.
Quel FUD ? J'ai dit que c'etait different sous Linux ?
T'en as pas marre d'inventer des conneries ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à -1.
Ce n'est pas grave.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à -1.
Ce n'est pas grave.
Et merci pour tous les lumières sur Windows, ça manque cruellement sur linuxfr.
btw, et t'as pas répondu :
- quel est le fichier qui fait noyau dans Windows
- ou j'ai la liste des patches avec les noms de fichiers affectés et la description du "pourquoi".
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
Pour avoir des info sur Windows, il suffit de te parler de Linux. Cool.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 4.
En 5 ans, la gestion de mémoire a complètement changé 2 fois, la gestion de périphs a complètement changé, la gestion des modules a complètement changé, le support VesaFB a été mis au ban puis remplacé par directFB en user space puis remis pour debug only.
Le protocole X a grandement évoulé, notament au niveau des methodes de chargement et d'affichage des bitmaps et de la gestion des extensions. Les TTYs on changé, les pseudos TTYs ont changés aussi. Les Files Sytem ont évolués dans des proportions dantesques. La gestion de l'IDE en a pris plein la tête. Les threads ont complètements changés.
Et là je parle seulement du fondamental, parceque si il fallait aller jeter un oeuil sur les libs plus haut niveau ca serait la fête.
Alors de deux choses l'une : soit RHEL tourne sur un noyau 2.2.12 ou inférieur, soit ils ont codés tellement de wrappers en kernel space que leur noyau explose les 100Mos soit tu racontes n'importe quoi.
Il reste quoi en "incontrôlable" => le noyau.
Ce n'est pas le bout du monde.
Euh.... Si ?
Parceque le noyau c'est la base. Le noyau peut peter l'esemble des APIs quand il veut. Un changement de droit et paf il faut reprendre tous les programmes a aller ajouter les modifs qui vont bien....
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 2.
http://www.redhat.com/software/rhel/(...)
Une RHEL qui _vient_ de sortir n'a pas des technologies vieilles de 5ans !
la RHEL 3 est basée sur RH9 et la RHEL 4 sera basée sur FC3 (Linux 2.6, Gnome 2.8, KDE 3.3, SeLinux, Xorg 6.8.0, etc).
Par contre, une fois que c'est sorti, ça ne bouge plus au niveau api. Ce qui n'empêche pas de sortir une nouvelle version. Il y a donc plusieurs versions RHEL maintenue en même temps. Lorsque la 4 sera sortie, il y aura de maintenu en même temps :
- RHEL 2.1
- RHEL 3
- RHEL 4
Comme MS fait (au pif):
- Win Millenium
- Win NT
- Win 2000
par exemple.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Éric (site web personnel) . Évalué à 2.
Il n'empeche que du passage d'une version à l'autre les interfaces changent, et c'est de ça que PbPg parlait. Le problème c'est que pour un driver de webcam ce qui nous intéresse c'est qu'il soit encore valable sur le nouveau système qui vient de sortir sans tout retapper le driver, pas sur une install vieille de plusieurs années qu n'a subit que les maj de sécu. Et pour ça ce qu'il faut c'est la compatibilité entre les différentes versions (ce que Win fait relativement bien et Linux assez mal), pas la durée du support (qui n'a rien à voir et dont tu me parles avec RHEL).
> Par contre prennez une distribution bien supporté type RHEL et là vous aurez 5
> ans d'api absolument stable et aussi la compatibilité avec la version N-1.
Dommage, ce qui aurait intéressé tout le monde c'est justement d'avoir un N+1, voire un N+X.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
Tu te trompes. PbPg explique à qui veut l'entendre qu'il ne fait jamais référence à Linux mais parle uniquement de Windows. RHEL n'étant pas Windows, l'avis de PbPg ne conserne en rien RHEL et Linux.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Bapt (site web personnel) . Évalué à 2.
Bien sûr je connais connais quelqu'un dans une Grosse SSII Française, qui développait un Gros Soft en Python/PyGTK pour une Société fournissant de l'électricité en France ;),
Il devait utilisait RHEL dernière version.
Et la le drame un gros bug GTK, une ligne de code ultra simple PyGTK faisait planté GTK lamentablement, contact du support RHEL (payé), le gars de l'autre côté :
"Oui je le note, c'est un bug connu de GTK, nous prenons note que vous avez eu le soucis", jamais le Bug n'a été corrigé, donc APi absoluement Stable, fo pas déconner non plus, résultat passage en dernière minute à Fedora Core 2.
Tout ça pour dire, RHEL pour moi c'est du bidon. C'est pour les décideurs pressés qui croient qui croient qu'ils auront un vrai support. c'est un produit bien foutu mais si tu as une merde, tu te retrouve dans la même situation que sous MDK, Debian, Fedora ou autre.
PS: Je ne dit pas que c'est mieux sous Win, à mon avis, si tu trouve un bug dans les Api graphique qui font tout craché, je ne pense pas qu'il te reçoiven beaucoup mieux. ;)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Elly . Évalué à 1.
En même temps, API stable, ça veut dire que la façon d'appeler les fonctionnalités du programme/librairire/noyau ne changent pas d'une version à l'autre, pas que ça plante pas :) (en plus je crois qu'il parlait que du noyau).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 0.
Franchement, t'es grave. Mandrake et Gentoo, ca te fait bander de dire une annerie pareil?
Sinon, je reste solidaire avec PBPG(meme si j'aime bien le taquiner avec les problemes que je rencontre sous windows au taf), balancer des FUD les un derriere les autres, ca rend pas crédible ;)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
Je parlais de "produit bien supporté, professionel (c'est à dire fait pour que d'autres boîtes puissent développer/invertir dessus)"
Alors regardes les faits. RH ou SuSE sont des solutions professionnelles (ou c'est considéré comme tel par le décideur pressé si tu préfères).
Je vois que très rarement d'annonces du type :
- "Amazon/Wallstreet... bascule tous leur serveur sous Gentoo ou Fedora."
Je me trompe ?
On va encore me dire que ce n'est pas la faute de Gentoo ou Mandrake si les décideurs pressés sont des crétins profonds et accrochent a la pub/marketing de RH/SuSE...
Et en plus cet """argument""", ça ne va pas être considéré comme du FUD...
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Volnai . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
c'est avoir de grosses compétences. Red Hat et SuSE ont beaucoup de développeurs Linux/gcc/libc (et des grands noms).
Il n'y a pas de mystère.
Oracle ne va pas engager sa réputation avec la distribution bidule si derrière ça n'assure pas un minimum.
On ne devient pas une distribution professionnelle car on est certifié Oracle mais car on "assure" suffisament pour être certifié Oracle.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Stibb . Évalué à 4.
Le noyau Windows est un micro-noyau (en fait un hybride car les modules s'executent en kernel space),donc pas de recompilation du noyau pour installer un module (les API sont tres bien limite, absolument catastrophique a utiliser, mais encadre tout proprement le developpement=> tu ne "touches" jamais au noyau). Le noyau est stocke dans le fichier ntoskrnl.exe. Ce fichier n'est mis a jour que tres rarement, pour les SP, car il est impossible que le noyau n'evolue jamais. Mais oui, pas besoin de recompiler le noyau pour changer de driver, et surtout (ahh, le jour ou se sera possible sous linux en standard parce que c'est tres chiant de recompiler ses drivers quand on met a jour son noyau) pas besoin de changer de driver quand on change de noyau (un driver windows xp sp1 fonctionnera NORMALEMENT sous sp2). Evidement entre 2000 et xp y a quelques changements donc certains drivers peuvent ne plus fonctionner.
Et non on a pas les sources du noyau, c'est pour ca que krosoft a fait ce systeme, pour que les entreprises puissent developpe
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 2.
Sous Linux aussi ;) Mais c'est clairement pas conseillé :) Y'a une option pour pouvoir charger un modules d'un noyau n-1 dans un noyau n.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Larry Cow . Évalué à 2.
- pas de compatibilité binaire car c'est un OS libre
- Les dev Linux sont pas cool avec les utilisateurs de pwc qu'ils laissent tomber.
- etc...
Mes frères ne me sorte jamais de tels conneries !
Ca risque pas, en effet, si comme tu le dis ils sont d'indécrottables windowsiens. pBpG est un linux-user, en plus d'être employé chez Microsoft: il bénéficie donc des deux "cultures", et est certainement plus à même que toi (linuxien) ou tes frangins (windowsiens) de faire des comparaisons entre les fonctionnements respectifs de linux et windows.
Très franchement, si je limitais mes connaissances de linux à des versions datant de NT4, je n'irais pas bien loin.
Par ailleurs, le chargement à la demande sur linux 2.0, tu dois mal te souvenir: il y avait bien un support de modules, mais pour le "hotplug" c'était pour ainsi dire inexistant. Sans parler de l'ipv6 qui était plus que balbutiant (voire absent).
je (et mes frères aussi) confirme très très fort qu'il faut rebooter 50 fois le bousin à l'installation du moindre driver).
Je t'affirme (et je poste ce message depuis un windows XP, c'est dire à quel point je pousse la rigueur scientifique dans l'expérimentation) que la seule installation qui m'ait motivée un reboot était celle d'une carte vidéo, et que donc au pire un driver nécessite "50" fois moins de reboot que tu ne le prétends. Si j'étais énervé, je te taxerais même de mauvaise foi, pour l'exemple.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnujsa . Évalué à 1.
pBpG a avoué avoir arreter Linux avant la série 2.4 Mais il connait peut-etre trés bien Linux 1.x
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par MalMok . Évalué à 1.
Il n'a jamais avoué avoir arrêté avant le série 2.4...
Je cite : J'ai Linux chez moi depuis 1995 sans interruption, dont 2 ans uniquement sur Linux aux environs de 1997-1999, ;)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Thomas Douillard . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnujsa . Évalué à 2.
On est pas là pour faire son procés, mais comme je l'ai déjà vu sortir des énormités sur Linux, je pense qu'il s'y connait surtout en Windows (ou alors les Linux d'il y a quelques années). Sinon moi aussi, je connais trés bien Windows vu que j'ai eu Windows 3.1, 3.11, 95, 98, ... (j'avais même installé Windows 1.0 juste pour rigoler)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 2.
Allez je t'aide, dans le poste du dessus j'ai dit qu'on supportait ce soft qu'on a ecrit en 98 encore aujour'hui, tu crois qu'on fait ca sur un GameBoy en cross-compilation vers Linux ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 2.
Je ne critique pas Windows ! J'ai dit dans un coin que selon mon expérience il fallait beaucoup rebooter. Mon expérience (Win 9x et Win NT), c'est mon expérience et je vais pas me mettre à Windows pour te faire plaisir.
Tu peux vénérer aussi pBpG pour ces connaissances Linux, mais quand je vois qu'il maîtrise mal la GPL, qu'il s'extasie que sous Windows on peut mettre à jour ntfs ou le réseau car c'est un driver alors qu'avec Linux c'est possible depuis la version 2.0 (1995, époque de Win95), qu'il croit qu'il faut recompiler un noyau Linux pour installer un nouveau driver (plus tard il dit qu'il ne dit pas ça mais tout le monde comprend ça...) alors que c'est faut, je me marre que tu puisses prendre pBpG pour un expert Linux.
btw, je ne me prends pas pour un expert Windows et personne ici me prend pour un expert Windows.
> Par ailleurs, le chargement à la demande sur linux 2.0, tu dois mal te souvenir: il y avait bien un support de modules,
Le Modules-HOWTO de linux 2.0 :
http://www.minet.net/linux/HOWTO-fr/Module-HOWTO-2.html#ss2.3(...)
Bon, vous avez lu tout ceci, et je vous sens fébrile et pressé d'essayer... Maintenant, oubliez tout ce que vous savez concernant le chargement et le déchargement des modules !
Grâce au démon kerneld, toutes ces opérations seront effectuées automatiquement.
[...]
A chaque fois qu'un programme veut que le noyau utilise un gestionnaire qui n'est disponible que sous la forme d'un module, et que le noyau ne l'a pas déjà installé, alors le noyau va demander au démon de bien vouloir s'occuper du problème.
> mais pour le "hotplug" c'était pour ainsi dire inexistant.
Linux 2.0 supportait PCMCIA. C'est "hotplug". Et fait pas chier en disant que c'est faut, car j'utilisais PCMCIA sous Linux 2.0.
De plus, le "hotplug", ce n'est pas le chargement à la demande et je ne parlais pas de "hotplug".
Exemple :
# grep cdrom /proc/modules
# head /dev/cdrom > /dev/null
# grep cdrom /proc/modules
cdrom 32668 1 ide_cd, Live 0xe0954000
Ça c'est du chargement à la demande et pas du hotplug.
> Sans parler de l'ipv6 qui était plus que balbutiant
Ça tombe bien, j'ai jamais qu'il y avait ipv6 dans Linux 2.0.
> "50" fois moins de reboot que tu ne le prétends.
C'est une image coco. Je dis "bousin", tu ne vas pas pas corriger pour me dire pour me dire que Windows n'est pas un bousin.
Si ?
Ben fait comme tu veux.
Ce qu'il y a de bien avec ton message c'est que maintenant je sais que tu es aussi nul que pBpG en Linux.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 2.
Mais c'est super, tu continues a nous pondre des delires sur mes paroles.
J'ai dit que c'etait genial ? J'ai dit que Linux ne pouvait pas le faire ?
T'as fume quoi pour deblaterrer autant de conneries a la minute ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
pBpG, a informé la communauté linuxfr que Windows, etc, etc,
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
Tu le savais ?
T'as une référence vers debian-legal (ou n'importe quoi d'autre) ? Si possible un truc vieux de 3 ans :-)
Il y a eu un problème rectifié par Alan Cox et maintenant ça. Moi je ne sais rien plus mais toi t'es très doué.
Puisque tu sais tout, répond à ces deux questions :
* Combien de lignes de code ne respectent pas la GPL ?
* Quel est le ratio avec le nombre de ligne de code total de Linux ?
Tu te fout de ma gueule.
Linux doit être au courrant de tous les problèmes de licence (d'ailleur tout le monde doit le savoir) mais MS rate d'ÉNORME trou de sécurité dans leur code et c'est normal.
T'es spécial.
> Ben alors pourquoi donc permettent ils toutes ces exceptions avec les drivers graphiques, etc... ?
Toi qui sait tout, qui connais chaque ligne de code non GPL dans le noyau Linux (que tu n'utilises pas) tu n'as pas lu COPYING.modules .
T'as remarque montre que tu n'as rien compris au problème actuel.
Le driver pwc serait uniquement binaire et proprio, il n'y aurait pas de problème (mais il ne serait pas dans le Linux officiel). Mais oublions, lis les autres messages pour éclairer ta lamterne casse.
> Avec Windows le probleme ne se pose pas, t'as pas besoin de recompiler le kernel pour faire marcher un driver.
J'adore. Bingo !
Tu reproches à Linux d'être strict et après du dit que Windows c'est bien car on ne peut pas recompiler (du moins ce n'est pas reprochable).
Ben met toi ça dans la tête :
- Linux c'est GPL only (ce qui n'est pas vrai mais faisont une caricature afin de ne pas "favoriser" Linux)
et dit toi que c'est aussi bien, cool, généreux, etc que :
- Windows c'est binary only
Comme ça ils sont pas cool tout les deux et tu n'as pas à faire la morale aux développeurs de Linux.
Fin de l'histoire.
- Ta mauvais foi me casse les burnes
- Ton FUD est plussoyé ici et c'est allucinant
- Apparament, moins de 20 % du public de linuxfr connait la GPL. Suffit de lire les autres commentaires, c'est affligeant. Pas la peine de rentrer dans les "subtilités" (grosse comme un pain de campagne de 800g) entre GPL et LGPL.
- moins de 0.2 % connais l'exception dans COPYING.modules
Affligeant. Je dis pas ça toi particuliairement. Tu es dans "ton rôle" de casser Linux, la GPL, le modèle open source, de dire "binary roxor" et tout ça.
Mais voir la majorité de linuxfr être d'accord avec toi est affligeant (pour moi et une minorité).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 2.
Arrete de dire n'importe quoi.
Ce que voulait dire le monsieur, c'est qu'un un driver compilé pour la version n du noyau fonctionnera encore apres une mise à jour de ce dernier(n+1). Sous Linux, c'est faisable(via une option a la compil du kernel) mais c'est vraiment pas conseillé.
Mais si tu veux faire un driver libre pour windows, tu peux ;)
Bon, par contre, PBPG se plante en disant que sous Linux il faut recompiler le noyau pour avoir un nouveau driver, il regarde trop les vidéos matrixiennes faites par ses patrons :)
ps: Pour ceux qui pense que le Hurd reglera le probleme des drivers proprios vu que un driver est un programme comme les autres, perdu, le Hurd n'autorise pas l'execution d'un soft proprio :)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
Un driver pour win95 ne marche pas avec Win2000. Il faut bien recompiler (et même réécrire le driver).
OK, l'exemple est con.
Mais toutes les noyaux RHEL 3 sont compatibles. Red Hat assure la compatibilité binaire. Par contre les modules pour RHEL 3 ne marcherons pas pour RHEL 4 (comme win95/win2000).
RHEL est supporté 5 ans et c'est du logiciel libre.
Donc ça n'a rien à voir avec "libre vs proprio" et ce n'est pas un problème technique. C'est un "problème" de gestion de projet et d'objectif. L'objectif de RHEL est la stabilité, l'objectif de Linux est le développement. Comme pour Linux, j'imagine bien que les beta Windows demande parfois la recompilation et/ou l'adaptation des drivers au évolution de l'OS.
Ou alors Windows est un OS mort :-)
Linux c'est la possibilité de recompiler le noyau. Pas l'obligation.
Windows c'est l'interdiction de recompiler.
Linux est orienté source, pourvu que ça dure.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Vincent LE LIGEOUR . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Vincent LE LIGEOUR . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 2.
Tu prends un driver de Win95.
Si tu veux faire tourner ce driver, faut modifier/recompiler le driver, pas le kernel Win2000
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
Par contre 2000 est compatible XP.
Et là ce sont les incompatibilités "simplifiés".
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 2.
C'est déjà pas si mal pour des OS quand meme assez différents.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
Pour les applis, je suis d'accord.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 21rdoma . Évalué à 0.
et comme on a pas accés aux sources du noyau on ne pourrait pas recompiler le driver a moins qu'on puisse recompiler sans rien savoir du noyaux
le tout sans nda
[^] # Relis ca phrase
Posté par mcjo . Évalué à 2.
[^] # Re: Relis ca phrase
Posté par pasBill pasGates . Évalué à 1.
Je parles de devoir recompiler le noyau, il n'y a jamais besoin de recompiler le noyau pour faite tourner un driver.
[^] # Re: Relis ca phrase
Posté par 007 . Évalué à 0.
Je suis en admiration, subjugué.
Ce sont des exemples qui ne sont pas tiré de la réalités. Mais tant pis.
Exercice 1 :
J'ai Win 95.
SATA ne marche pas avec Win 95 (ya pas SATA).
SATA marche avec Win 98.
J'ajoute un controleur SATA à mon système, dois-je (ou MS) recompiler le noyau pour avoir SATA ?
OUI - NON (rayer la mention inutile)
Exercice n°2 (attention, il y a un piège):
J'ai Win 98.
SATA ne marche pas avec Win 95 (ya pas SATA).
SATA marche avec Win 98.
J'ajoute un controleur SATA à mon système, dois-je (ou MS) recompiler le noyau pour avoir SATA ?
OUI - NON (rayer la mention inutile)
Exercice n°3 (toujours plus dure):
J'ai RHEL 3.
TRALALA ne marche pas avec RHEL 3 du 01/2004
TRALALA marche avec RHEL 3 du 01/2005 (update 3) qui a un nouveau noyau recompilé.
Rappel : RHEL 3 garanti la compatibilité binaire de toutes les versions RHEL 3
J'ajoute un contrôleur TRALALA à mon système, dois-je (ou RH) recompiler le noyau pour avoir TRALALA ?
OUI - NON (rayer la mention inutile)
Exercice n°4 (toujours plus dure, il vaut 7 points):
J'ai RHEL 3 update 3
TRALALA pour RHEL 3 (update 0) est fourni en binaire par la société ZZIIPP.
Rappel : RHEL 3 garanti la compatibilité binaire de toutes les versions RHEL 3
J'ajoute un contrôleur TRALALA à mon système, dois-je (ou RH) recompiler le noyau pour avoir TRALALA ?
OUI - NON (rayer la mention inutile)
Exercice n°5 :
Considérez les réponses des exercices n°1 à 4.
a)Dans quel cas faut-il recompiler un noyau ?
b)Dans quel cas il n'est pas nécessaire de recompiler un noyau ?
Exercice n°6 :
a)Sachant qu'un nouveau driver ne demande pas de changer de noyau, faut-il recompiler un noyau ?
b)Sachant qu'un nouveau driver demande de changer de noyau, faut-il recompiler un noyau ?
c) faite la synthèse de a) et b)
------------------
Solution n°5 :
a) Lorsqu'il faut le changer
b) Lorsqu'on ne le change pas
Solution n°6 :
a) non.
b) oui.
c) C'est vraiment cons comme questions.
[^] # Re: Relis ca phrase
Posté par pasBill pasGates . Évalué à 1.
Avec Win2K/XP, les questions 1 & 2 repondent NON
Arretes de t'enfoncer, ca en devient est risible.
[^] # Re: Relis ca phrase
Posté par 007 . Évalué à -1.
T'as raison, te fais pas chié, fais les questions toi même.
Je dois t'avouer un truc :
- Je t'aime.
[^] # Re: Relis ca phrase
Posté par Jerome Herman . Évalué à 3.
Exercice 1 :
Soit windows 95 ne voit pas le périph du tout et le discarde au quel cas uen recompilation ne servirait a rien, un changement d'architecture s'impose pour supporter la gamme SATA, soit windows 95 voit le périph, son IRQ et ses zones mémoires auquel cas un pilote peut-être écrit qui prenne en charge le périph (éventuellement en s'aidant d'un wrapper vers SCSI)
Réponse : Non, recompiler le kernel ne servira a rien.
Exercice 2
Si windows 98 est capable de reconnaitre et de faire fonctionner du SATA sans l'intervention de microsoft, on peut en déduire que windows 98 n'a pas besoin d'être recompilé. Dans le cas ou il faille uen version modifiée du kernel pour que ca marche cf première partie de la réponse a l'exercice 1.
Réponse : Non, recompiler le kernel ne servira a rien.
Exercice 3
Comme RHEL assure la compatibilité binaire entre les versions. Si la versions 01/2004 ne supporte pas des périphs que la version 01/2005 supporte celà ne peut que vouloir dire que le pilote ne supporte pas la modularisation. La prise en charge de TRALALA nécessite donc de la part de Red Hat l'activation dans le kernel de la bonen option pour le support de TRALALA.
Réponse : Oui, une activation dans le kernel d'une nouvelle option et la recompilation du kernel ont été necessaire pour le support de TRALALA
Exercice 4
On sait que le pilote de TRALALA n'est pas modularisable, au moins en environement RHEL (cf exercice 3). la fourniture du pilote en binaire n'apporte donc rien, a mois qu'il ne s'agise d'un patch binaire du noyau RHEL3 update 3. Suposons que la probabilité du patch binaire est nulle. On se retrouve donc dasn le cas de l'exercice 3
Réponse : Oui, mais la recompilation a déjà été effectuée par Red Hat (cf exercice 3).
Exercice 5
Sous Windows il ne faut jamais recompiler une noyau, la prise en charge de nouveaux périphs impliquent un changement d'architecture ou un ajout de code. Une simple recompilation n'ammenera probablement nulle part. Celà s'explique par le fait que le noyau windows n'a pas d'options de prise en charge pilote désactivés.
Sous Linux la recompilation du noyeau est necessaire a cause du système de pilotes intégrés au noyau, pour tous les pilotes non modularisables (comme ceux vu dans les exercice 3 et 4).
Exercice 6
a) Oui si le pilote en question n'est pas modularisable et que l'option n'a pas été activée en première compil. Non dans les autres cas.
b) Non, deux noyaux différents peuvent être compatibles vis a vis des pilotes même si ce cas n'a pas été vu en exercice. Dans cette optique un module pour un noyau peut être transposer dans un autre.
Kha
[^] # Re: Relis ca phrase
Posté par 007 . Évalué à 0.
Exercice 1 :
Oui, il faut recompiler.
L'énoncé dit :
- SATA ne marche pas avec Win 95 (ya pas SATA).
S'il marche pas avec Win 95, il faut patcher win 95 vers Win 98 et recompiler (C'est Microsoft qui fait ça).
NB : il faut monter en version et passer à Win 98.
Exercice 2 :
Non, il ne faut pas recompiler.
Exercice 3 :
Oui, il faut recompiler.
Exercice 4 :
Non, il ne faut pas recompiler.
En effet, il est indique que le driver TRALALA de la société ZZIIPP (qui comme tout le monde sait n'a rien à voir avec le driver TRALALA de Red Hat de l'exercice 3) marche avec RHEL 3 update 0. Red Hat assurant la compatibilité binaire, le driver TRALALA marche parfaitement avec RHEL 3 update 3 sans rien recompiler.
Exercice 5 :
a) Lorsqu'il faut le changer
b) Lorsqu'on ne le change pas
Je sais, c'est dure.
Exemple : Si tu as besoin de Win 2000 pour avoir un système de fichier de 2 To alors que tu as Win 3.11 (workgroup), il faut patcher son Win 3.11 vers Win 2000 et recompiler.
NB : il faut monter en version et passer à Win 2000.
Exemple inverse : Si tu as Win 3.11 (workgroup), que tout marche bien, que tu ne sais pas quoi lui reproche à ce noyau et que tu n'as absolument aucune raison de le changer, alors il ne faut pas le modifier/patcher et le recompiler.
Je sais, c'est subtile de comprend les tenants à les aboutissants de la contre rotation de la queue de la vache par pleine lune, mais telle est la vérité.
Exercice 6 :
a) non.
b) oui.
c) C'est vraiment cons comme questions.
Relire tout doucement l'énoncé pour ceux qui sont surpris par la correction.
Si nous ne comprenez pas les réponses aux questions a) et b), ignorer la question et la réponse c).
[^] # Re: Relis ca phrase
Posté par Ph Husson (site web personnel) . Évalué à 1.
Rassure moi parce que la franchement j'ai jamais vu une anerie pareil (bien que tu as en partie raison mais bon une petite partie)
En plus tu parle de comparer ce qui est comparable plus haut (entre windows et mdk/gentoo/autre ca va pas fo comparer avec RHEL) ben la aussi faut faire la meme chose!!!
Pour passer de win 3.11 a win 2000 c'est encore pire que si tu passais de linux 0.01 a linux 2.6.8
Tu serais assez fou pour faire ca?
Alors arrete de dire des conneries
En plus toujours pour parler de ce qui est comparable
Tu penses que y aurais pas besion de recompiler le noyau de RHEL quand on voudra passer de la limite de 2To a 2Po? (imagination powa)
Pour ton exemple sur le SATA imaginons que tu prenne un noyau disons de mdk 7.1 (si ca supporte le SATA c machin la c grave) comment tu fais (sans recompiler le noyau bien sur) pour supporter le SATA
Alors autant j'sui un fervent defenseur de Linux
Mais j'sui aussi un fervent defenseur de la véritée!
Donc bien que je ne defende pBpG d'indirectement n'empeche qu'il a (en plus grande partie que toi) raison!
[^] # Re: Relis ca phrase
Posté par 007 . Évalué à 1.
Non.
Remonte le thread pour tomber sur l'énoncer.
Ça débute par :
Ce sont des exemples qui ne sont pas tiré de la réalités. Mais tant pis.
Ça me semble assez claire.
Un ennoncé ne se discute pas, il a toujours raison.
[^] # Re: Relis ca phrase
Posté par Ph Husson (site web personnel) . Évalué à 1.
Ça me semble assez claire.
Un ennoncé ne se discute pas, il a toujours raison.
Ben désolé mais des exemples équivalents qui marchent vraiment j'en vois pas
[^] # Re: Relis ca phrase
Posté par Jerome Herman . Évalué à 2.
Ou donc changer de système. A noter qu'avec ta définition ultralarge de "patcher" on peut aussi patcher Win95 en linux 2.6.8 et le tour est joué.
A noter encore que quand on patche on ne recompile pas le même noyau, on en compile un nouveau...
qui comme tout le monde sait n'a rien à voir avec le driver TRALALA de Red Hat de l'exercice 3)
Tout le monde c'est toi ? Ou bien je me suis planté d'univers en me levant ce matin ?
a) Lorsqu'il faut le changer
b) Lorsqu'on ne le change pas
MWAHAHAHA....
Bon tu me diras je t'ai poussé a la faute, masi celle là elle est belle quand même.
Alors voila j'ai un PC avec 1Go de ram, mon kernel qui peut supporter jusqu'à 64Go de ram a été compilé avec une option qui ne gére pas la ram au delà d'1Go. J'ai envie de mettre 4Go de ram sur mon PC, devine comment je vais faire pour résoudre ce problème sans changer ni mon système ni mon kernel ....
Et je te laisse déduire de l'exemple précédent les réponses a la question 6 a).
Pour la 6 b) je te conseille les *BSD ou même le Hurd ou éventuellement QNX dans lesquelles il existe une version bianire du noyeau que quasiment personen ne touche. Pour me faire bien comprendre : il y a compilation du noyau par les équipes concernés mais jamais REcompilation d'un même noyau (ou presque).
Ceci étant ta definition de recompilation étant aussi farfelue que celle de patch....
Kha
[^] # Re: Relis ca phrase
Posté par 007 . Évalué à -1.
>
> Tout le monde c'est toi ?
C'est comme à l'école etc, chaque ennoncé est indépendant.
Donc "comme tout le monde sait", tout ce qu'il y a dans l'exercice 3 (par exemple le driver TRALALA de Red Hat) n'est rien à voir avec l'exercice 4 (et vice-versa).
> devine comment je vais faire pour résoudre ce problème sans changer ni mon système ni mon kernel ....
Ben tu recompiles noyau comme indiqué en 5 a)
Q : Dans quel cas faut-il recompiler un noyau ?
R : Lorsqu'il faut le changer
Là tu as besoin de le changer. Si tu recompiles ton noyau avec une configuration différente (support 64 Go), le noyau est différent et tu l'as changé. Non ?
> Et je te laisse déduire de l'exemple précédent les réponses a la question 6 a).
Incompréhensible.
> Ceci étant ta definition de recompilation étant aussi farfelue que celle de patch...
man patch : patch - appliquer un fichier diff à un original
man diff : diff - Trouver les différences entre des fichiers.
Nul part il est dit que ça doit conserner les sources d'une même OS. Marche parfaitement entre Windows et Linux ou Solaris.
Je ne te comprend pas...
[^] # Re: Relis ca phrase
Posté par Jerome Herman . Évalué à 2.
Dans la phrase "Lorsqu'il faut le changer" en réponse à "Dans quel cas faut-il recompiler un noyau ?". Je comprend il faut recompiler le noyau quand on change de noyau. Parceque sinon dire qu'il faut recompiler le noyau quand on veut changer des paramètres et des réglages du noyeau je ne vois pas l'interet.
Pour la question 6 a)
a)Sachant qu'un nouveau driver ne demande pas de changer de noyau, faut-il recompiler un noyau ?
la réponse reste parfois oui si on prend changer au sens auquel je l'ai pris (a savoir utiliser un autre noyau) et est non si on le prend au sens ou tu semble le prendre (a savoir faire des modifications et des reglages au sein d'un même noyau). Effectivement si on ne change rien dun un kernel donné il faudrait être bien abruti pour le recompiler (à la limite recompiler les modules parcequ'on les a corrompus je comprend, mais le kernel entier...)
En d'autres termes, quand on n'a besoin de toucher a rien, il n'y a pas besoin de mettre les maisn dans le cambouis.
Si c'est le sens que tu donnais a tes phrases je te prie de m'excuser de mon entrée dans le troll et de mon attitude un peu agressive. Mais cependant même si "ce qui va sans dire va encore mieux en le disant", là on est quand même en plein dans les lapalissades...
En ce qui concerne ta définition de patch, je en met pas en doute sa validité, je dis juste que la plupart des gens que je connais on tendance a remplacer les fichiers plutot qu'à les patcher passé un certains pourcentage de divergence... Donc patcher du 3.1 en 2000 ....
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 2.
Oui, mais RedHat ne fait que rajouté des patchs de sécu, ie, pas de passage à la version n+1.
Avec la SP2 de windows par exemple, je suis sur que certaines parties ont clairement changées et pourtant tu te manges pas un "undefined symbol" en installant un driver :p
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
Évidement puisque l'API ne bouge pas :-) Remarque, si l'API de linux ne bouge pas, il n'y a pas de raison de ne pas passer à n+1 (faut tricher sur la version pour que modprobe te laisse en paix).
Par contre, il peut y avoir des ajoutes de drivers (pour les 2 premières années il me semble) et correction de bug (les 3 premières années).
Exemple (il n'y a pas que des patchs de sécu) :
https://rhn.redhat.com/errata/rhel3as-errata.html(...)
> Avec la SP2 de windows par exemple, je suis sur que certaines parties ont clairement changées et pourtant tu te manges pas un "undefined symbol" en installant un driver :p
Et ?
btw, il me semble qu'il y a des incompatibilités dans SP2. T'as peut-être pas de "undefined symbol", mais certain truc ne marchent plus avec SP2 (Je ne suis pas de façon précise l'actu de Windows donc je me trompe peut-être).
Donc il faut recompiler/adapter certains drivers/services.
Si tu as utilisé Windows, je pense que tu as remarqué pour certains drivers lorsque tu les downloades tu as le chois:
- version 95 SR2
- version 98
- version 98 sp3
Je ne sais pas si ces versions existent réellement mais je peut te garantir que j'ai déjà vu des trucs de ce type et plus d'une fois.
Donc la compatibilité binaire (bien que très bonne sous Windows, c'est indéniable) n'est pas toujours parfaite même entre version mineur (Service Pack).
N'oublions pas les programmes qui écrasent 10 dll système car pas très compatibles.
Faut pas rèver, MS à les même contraites que Linux.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Christophe Merlet (site web personnel) . Évalué à 0.
> les downloades tu as le chois:
> - version 95 SR2
> - version 98
> - version 98 sp3
Tu serais vraiment crédible si tu connaissais un minimum windows. En l'occuence, ne même pas connaitre les différentes version de windows sur le marché te ridiculise au plus haut point.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
Oui. Déjà ces versions de Windows ne sont plus sur le marché et elles ont plus de 5 ans. Mais si tu peux me rafraichir la mémoire, n'hésite pas.
Je dis ça ... comme ça mais le prend pas mal hein.
C'est linuxfr et pas windowsfr. Si tu ne trouves pas sur ce site des informations de haute qualité sur Windows,
c'est normal.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Ph Husson (site web personnel) . Évalué à -1.
alors la 007 tu fais fort
mais alors la a un point
bon je t'aide
95 OSR2
98
98 SE (Second Edition)
Comme le dit christophe niveau crédibilité c'est proche de 0
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par isydor . Évalué à 2.
Á un moment de votre vie il faudra cesser d'être scolaires pour devenir des adultes consentants :)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Ph Husson (site web personnel) . Évalué à 1.
Ben disons que 007 parle quasi exclusivement de 95 98 (un peu me et nt4)
pas des systemes recent tels que win 2k, 2k3 ou xp
Donc on peut supposer que c'est parce que c'est les systemes qu'il connait
Ben faut croire que non
Donc apparement il connait quasi rien à windows
Donc vous voyez ou je veux en venir :)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par isydor . Évalué à 1.
Et certaines personnes sont complètement hermétiques au versionnage alors qu'elles connaissent bien les architectures logicielles ou matérielles.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
Et oui, je ne connait pas ou 2k, 2k3 ou xp.
> Donc apparement il connait quasi rien à windows
J'ai utilisé ÉNORMÉMENT Windows jusqu'en 97. C'est simple, il y avait que ça au boulot. Après s'était un mix Unix/Windows et maintenant c'est que Unix/Linux (à 95 %).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 3.
Non non :)
C'est pas légal de faire tourner du proprio sous le Hurd, tu violes la GPL ;)
Ils sont forts ces hurdistes :)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Elly . Évalué à 1.
Pas faire tourner de translator proprio, je veux bien si la lib pour les faire est en GPL, mais pas de proprio sous le Hurd, ça voudrait dire que la libc est en GPL au lieu de LGPL, dont j'ai un doute là quand même :)
Accessoirement, s/proprio/non compatible GPL/, un soft peut être libre sans être compatible avec la GPL
(d'ailleurs, je trouve ça un peu dommage, je veux dire, y'aurait pas moyen de mettre un truc du genre "vous pouvez linker un logiciel avec ce programme à condition de donner les sources, de permettre la modficiation et la redistribution de ce code" dans une licence ?)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par bleh . Évalué à 2.
C'est quand même pas la même chose. Une faille de sécurité peut être énorme dans le sens où elle permet de faire beaucoup de chose une fois exploitée et pour autant à peine visible dans un code source. Etre au courant des licences dans un noyau demande quand même un niveau d'expertise et de vigilence plus bas. Si tu ne vois franchement pas la différence ...
Je doute que les mainteneurs (je suppose que c'est eux que tu identifie à Linux ... Mr Linux ?) ne soient pas au courant depuis longtemps de ce problème (Alan Cox avait déjà fait des remarques à propos de ce pilote comme de nombreuses personnes l'ont fait remarquer) alors c'est dommage que ça n'ait pas été relevé plus tôt et qu'une solution n'ait pas été trouvée.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par oliv . Évalué à 3.
Il n' y a pas d' exception avec les drivers graphiques:
Quand un driver est écrit à partir de rien et qu'il utilise les fonctionnalités non publiques du noyau, il est considéré comme code dérivé, donc sujet à la GPL.
Les drivers de NVidia sont adaptés pour linux à partir de code (pré-)existant sous d'autres OS. Ils ne sont donc pas considérés comme des dérivés du code Linux et peuvent donc ne pas être sous GPL.
De la bouche de Linus même:
http://groups.google.com/groups?selm=Pine.LNX.4.44.0210170958340.67(...)
Alors, arrêtes de dire n'importe quoi s'il te plaît. Merci.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 21rdoma . Évalué à 1.
A: It was there for the explicit purpose to support a binary only
module. That goes against the kernel's documented procedures, so I
had to take it out.
Q: That hook had been in there for years! Why did you suddenly decide
to remove it now?
A: I was really not aware of the hook, and the fact that it was only
good for a binary module to use. I'm sorry, I should have realized
this years ago, but I didn't. Recently someone pointed this hook out
to me, and the fact that it really didn't belong in there due to the
kernel's policy of such hooks. So, once I became aware of it, I had
no choice but to remove it.
Q: Why did you delete the whole pwc driver from the tree?
A: That is what the original author (Nemosoft) wanted to happen. It was
his request, and I honored it. Go ask him why he wanted it out if
you are upset about this, I merely accepted his decision as he was
the current maintainer and author of the code.
Q: But you took away my freedom! Isn't Linux about freedom?
A: Again, it was Nemosoft's decision. The kernel also has to abide by
it's documented procedures, so that is why the hook had to go.
Remember, the original driver was released under the GPL, so you are
free to take that code and maintain it if you so desire. I'd gladly
support someone taking the GPL code and agreeing to maintain it, and
resubmitting it for inclusion in the main kernel tree. That's the
freedom that Linux provides, no closed source OS would allow you to
do that, if a company pulled support for a product (which happens all
the time.)
Q: You jerk, I had invested lots of money in this camera, you are
costing me money by ripping it out. You should be ashamed of
yourself!
A: See the above question about freedom. If it means that much to you,
then offer to maintain the code, it's that simple.
Q: You are keeping companies from wanting to write binary drivers for
Linux.
A: Duh! What do you think all of the kernel developers have been
stating for years, in public. Binary drivers only take from Linux,
they do not give back anything. See Andrew Morton's OLS 2004 keynote
address for more information and background on this topic.
Q: You are a fundamentalist turd / jerk / pompous ass /
GNU-freebeer-biased-idiot-fundamentalist fucktard / ignorant slut!
A: I've been called worse by better people, get over yourself.
"Q: Why did you remove the hook from the pwc driver?
A: It was there for the explicit purpose to support a binary only
module. That goes against the kernel's documented procedures, so I
had to take it out.
Q: That hook had been in there for years! Why did you suddenly decide
to remove it now?
A: I was really not aware of the hook, and the fact that it was only
good for a binary module to use. I'm sorry, I should have realized
this years ago, but I didn't. Recently someone pointed this hook out
to me, and the fact that it really didn't belong in there due to the
kernel's policy of such hooks. So, once I became aware of it, I had
no choice but to remove it.
Q: Why did you delete the whole pwc driver from the tree?
A: That is what the original author (Nemosoft) wanted to happen. It was
his request, and I honored it. Go ask him why he wanted it out if
you are upset about this, I merely accepted his decision as he was
the current maintainer and author of the code.
Q: But you took away my freedom! Isn't Linux about freedom?
A: Again, it was Nemosoft's decision. The kernel also has to abide by
it's documented procedures, so that is why the hook had to go.
Remember, the original driver was released under the GPL, so you are
free to take that code and maintain it if you so desire. I'd gladly
support someone taking the GPL code and agreeing to maintain it, and
resubmitting it for inclusion in the main kernel tree. That's the
freedom that Linux provides, no closed source OS would allow you to
do that, if a company pulled support for a product (which happens all
the time.)
Q: You jerk, I had invested lots of money in this camera, you are
costing me money by ripping it out. You should be ashamed of
yourself!
A: See the above question about freedom. If it means that much to you,
then offer to maintain the code, it's that simple.
Q: You are keeping companies from wanting to write binary drivers for
Linux.
A: Duh! What do you think all of the kernel developers have been
stating for years, in public. Binary drivers only take from Linux,
they do not give back anything. See Andrew Morton's OLS 2004 keynote
address for more information and background on this topic.
Q: You are a fundamentalist turd / jerk / pompous ass /
GNU-freebeer-biased-idiot-fundamentalist fucktard / ignorant slut!
A: I've been called worse by better people, get over yourself.
voila la reponse du type qui a virer le hook
[^] # a peine parti et bientôt de retour
Posté par 21rdoma . Évalué à 1.
pwc us useless without pwcx
While we don't want/intend to take sides in the pwcx/kernel dispute,
we want to make it clear that these claims are simply not true.
The pwc driver is very useful without pwcx.
The LavaRnd project uses webcams with lens caps an entropy sources
for generating random numbers (see http://www.lavarnd.org(...)). One of
our reference webcams is the Logitech QuickCam 3000 Pro - pwc730 webcam
(see http://www.lavarnd.org/developer/pwc730.html(...)).
On Fri, Aug 27, 2004 at 07:16:18PM -0700, lkml-mail@asthe.com wrote:
>>
>> We would be happy to discuss ways that the pwc might be maintained
>> in the linux kernel. If we can help, please ask us (see
>> http://www.lavarnd.org/about-us/contact-us.html(...) for our EMail address).
Great. Here's what you can do. Take the patch availble at:
http://linux.bkbits.net:8080/linux-2.5/cset@412d8e0cqutBsdGubqorXXC(...)
and apply it reversed to your kernel tree (with -R as an option to
patch). That patch has the binary hook already removed.
Then clean up the text a bit to point to you as the maintainer, that no
one should bother the original author anymore, and such. Cleanup and
change anything else that you think needs to be done to the driver, and
then send me that patch as documented in the
Documentation/SubmittingPatches in the kernel tree.
Then you would be the new maintainer of the driver, and the code would
be back in the kernel tree.
Sound good?
thanks,
greg k-h
[^] # Re: a peine parti et bientôt de retour
Posté par Christophe BAEGERT . Évalué à -2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Philippe F (site web personnel) . Évalué à 6.
> et si on peut reecrire son bidule sans passer 3 mois à reverse enginerer les anciens drivers ou ceux de win.
La reponse est non. Un algorithme de compression proprietaire, je doute que tu arrives a faire de reverse- engineering dessus, surtout quant le mec le plus competent ne peut plus travailler dessus.
Il s'agit donc d'une perte nette de toute webcam utilisant un chipset philips, c'est a dire une tres grosse majorite. Par exemple, j'ai une logitech sur mon bureau qui ne marchera plus.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Christophe Chailloleau-Leclerc . Évalué à 2.
Comme cela à été signalé directement à son auteur sur la liste où est apparu le "problème", son module est... sous GPL. Il n'y a donc pas de reverse engineering ou de ré-écriture à faire. Il a demandé à supprimer son travail, ce qui a (je crois) été fait dans le CVS. Mais n'importe qui peut, sans aucune autorisation de sa part, le remettre... C'est un peu le principe de la GPL, son travail "appartient" à la communauté, qui est LIBRE de le réutiliser...
A bon entendeur, ...
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Philippe F (site web personnel) . Évalué à 4.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Christophe Chailloleau-Leclerc . Évalué à 3.
J'ai raté quelque chose ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Chris K. . Évalué à 2.
Non je ne pense pas, mais vu le nombre de personnes qui pataugent (dont moi) je pense qu'une explication plus claire dans la news serait la bienvenue.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Temsa (site web personnel) . Évalué à 3.
A partir de là, "l'algo de compression proprio" est certainement une faible variante du JPEG (ou eventuellement du MPEG, mais j'en doute). J'aurais du temps à consacrer à ça, ayant le module pwcx et une webcam philips, avec des outils bien trouvés, je tenterais bien d'apporter au minimum ma pierre au problème, malheureusement je ne dispose ni des outils nécessaires (qu'il me faudrait trouver) ni des connaissances necessaires avec l'usb, ni du temps pour apprendre tout ça en ce moment. Dommage, ça va atterir dans mes TODO (mais après le plugin jpeg2000 pour gimp que j'ai jamais terminé, et qui est trop lent) pour le moyen terme ;-)
Car en fait j'en ai besoin de ce driver, notre robot (Coupe e=m6) utilise cette webcam!!!
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Colin Leroy (site web personnel) . Évalué à 3.
http://www.ece.uvic.ca/~mdadams/jasper/(...)
Son auteur est assez sympa pour l'avoir re-licencié avec une licence style MIT qui permet de la linker à du code GPL ; avant c'était une licence beaucoup moins libre, et il l'a changé pour nous (developpeurs d'ayttm) arranger.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Sébastien Rohaut . Évalué à 10.
De ce que je peux comprendre, mossieu est vexé. Mossieu ne veut pas diffuser son module hors du noyau parce que le projet de mossieu serait considéré comme un projet de second plan...
Alors voila ; vous n'êtes pas condamné à voir le support de votre webcam disparaître à cause des mainteneurs du noyau. Personne n'empêche ce type de diffuser ses modules en téléchargement hors du noyau, via un site de type sourceforge ou autre, propriétaire ou pas. Mais voila il est vexé. Alors il ne le fera pas. Et il n'assume plus.
Ce n'est pas bien. Tiens pour ma part, j'ai une webcam Logitech Quickcam Web. Elle n'est pas par défaut dans le noyau, il faut télécharger et compiler le pilote à part. A priori c'est libre. Et personne n'en fait un caca nerveux. http://qce-ga.sourceforge.net/(...)
Voila.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par fouinto . Évalué à 4.
C'est bien pour toi et moi cette solution, mais il est hors de question d'utiliser cette solution pour l'utilisateur moyen (non pas que je me situe au dessus) qui veut juste que ca marche... surtout s'il vient du monde de windows...
P.S. attention, il y a pas mal de webcam logitech qui utiliserait le driver philips en question...
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Nicolas Ternisien (site web personnel) . Évalué à 1.
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Sébastien Rohaut . Évalué à 0.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par SoWhat . Évalué à 2.
Moi je lis: "There's nothing I can do about that; I'm bound by an NDA." ; et NDA = "non disclosure agreement". Donc le code binaire fermé, il n'a a priori pas le droit de l'ouvrir. De plus, si tu lis ce qu'il dit, il ne veut plus continuer car cela obligerait à patcher le kernel pour utiliser le binaire, et il ne veut pas supporter cela ("it would probably confuse a lot of people").
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Emmanuel Seyman . Évalué à 5.
Le NDA a expiré l'année dernière, apparament.
"Actually, I've got a little surprise for you. The NDA I signed with Philips
has already expired a year ago."
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par GhZaaark3 . Évalué à 1.
Les gars du DRI pourrait s'en occuper?
Ainsi, on aurait des binaires mais contrôlés par des dev libres au faîte de l'évolution du kernel.
j'dis peut-être des conneries mais ça serait une solution meilleure que le tout closed.
+
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par mickabouille . Évalué à 10.
Car avoir accès à des documentations/sources/recettes de cuisine qui ne sont pas publique risque de le mettre en porte à faux, et de l'empêcher de contribuer à d'autres projets complètement libres.
Il ne faut pas "pourrir" un bon développeur élevé au bio!
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par GhZaaark3 . Évalué à 2.
C'était une idée comme ça, je ne connaissais rien à cette problèmatique.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 10.
Le Mossieu vient d epasser trois ans de sa vie a ecrire patch sur patch et a faire demandes sur demandes au dev du kernel pour que telle ou telle fonction soit prise en compte/authorisée/réactivée. Le mossieur il en a pris pleins les dents sur la mailing liste et dans les faits pendant qu'il s'occupait d'un module de premier plan. On lui a peter son module cinq ou six fois au cours des dernières années dont au moins deux fois exprès. Alors le mossieur il veut même pas savoir ce que ca ferait de continuer le même boulot en etant considéré par les devs de premier plan comme accessoire, de seconde zone, facultatif.
Et moi le Mossieur je le comprend un peu au moins sur ce plan là.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 10.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 10.
Il n'ay a AUCUNE dérogation a la GPL a fournir un hook qui permet un accés direct au matériel. Et il n'y a aucne derogation a la GPL a ce qu'un modules ou une appli propriétaire utilise ce hook.
Les applis propriétaires ont le droit d'utiliser les API et les appels fondamentaux du système. Prétendre le contraire revient a dire qu'un programme non GPL n'a pas le droit de demander une allocation mémoire physique.
En ce qui concerne l'argument du kernel space/ User space c'ets très simple on a deux solutions :
- Soit on se permet de lancer des bribes d'applicatifs en kernel space et c'est pas très propre.
- Soit on place les accès direct hardware et les inits de périphs en user space et là c'est carrément immonde et en plus ca fait un trou de sécurité assez grand pour y fourrer Jupiter et tous ses satellites.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Nap . Évalué à 5.
On sent la fibre de l'écrivain qui ressort :D
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 4.
Parce que les modules proprio, ils ont le droit de se servir que de choses d'API bien définies, si ils ne font pas ca les modules ils deviennent travail dérivé du noyau et donc sous GPL ou rien. C'est pas moi qui le dit c'est les kernel hacker. Et cet API elle est pas défini par le premier quidam venu, sinon je fais un module GPL wrapper qui encapsule TOUS les appels à TOUTES les fonctions du noyau, et pis apres bien tranquilement je déclare que je suis dieu et que cet API peut etre utilisée pour linké des modules proprio qui font ce qu'ils veulent.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 4.
Mais je suis tout a fait d'accord avec celà. Seulement il y a des fois ou ca n'est pas possible. Dans le cas présent il faut remonter des informations du kernel space (pilote V4L) et de l'User space (lancement de gnome meeting dans une certaine résolution, en overlay a une certaine vitesse) directement vers le device pour le réinitialiser comme il faut...
Ne pas se coller en kernel space, voudrait dire laisser une appli user space acceder directement a un périphérique. Tout le problème est là, le code d'initialisation de la webcam était sous NDA....
Parce que les modules proprio, ils ont le droit de se servir que de choses d'API bien définies, si ils ne font pas ca les modules ils deviennent travail dérivé du noyau et donc sous GPL ou rien.
Oui mais là encore c'est un peu plus complexe, les accès direct au matériel sont authorisés dans une certaine mesure qui varien en fonction du dit matériel. On ne pourra jamais avoir un accès direct a de la ram alors qu'un accès direct au disque dur pose peu de problèmes. Mais dans le cas de la webcam, c'est un accès direct non pas a la webcam, mais au port USB... Donc il y a problème. Ceci étant ce problème a été considéré comme négligeable pendant 3 ans. Et c'est définitvement pas parceque les mainteneurs du kernel ne l'avait pas vu...
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 2.
Là ce qui clochait en fin de compte c'était que à cause du fait que le truc proprio utilise le hook, il se transformait (illégalement) en travail dérivé. C'est ce que semble penser Greg KH.
On en revient un peu au meme point, c'est à dire est-ce qu'il faut laisser un type écrire un patch pour creer un hook dans une partie de gestion matérielle de nux (usb, ieee1394, pci, etc..) afin de satisfaire ses besoins de pilote proprio. Et si il ne faut pas alors soit il s'agit de limite légales (c'est ce qui est dit sur la LKML par Greg KH : Think legal limits, not arbitrary.) soit le mec il peut continuer à écrire des patchs qui recraient le hook et à se moment là son retrait est juste une question d'ego.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 2.
C'est ce qui m'ennuie. Soit le hook est effacé pour un problème de licence mais je ne vois pas lequel et les demandes qui fusent sur le flame de la LKML aident pas vraiment. Soit il a été retiré parcequ'un des mainteneurs interprete une phrase de Linus qui dit : "Pas de hook pour du propriétaire seul." Le fait de se charger dans le l'espace mémoire d'une autre appli et de s'y executer ne constitue pas de facto une violation de la GPL. Il faut encore que le programme ainsi chargé fasse appel a des fonctions spécifiques du programme chargeant. Or là j'ai un peu de mal a voir le coté "spécifique Linux" du binaire, surtout que les algos utilisés on été écrit a la base pour Windows et Mac.
D'un autre coté je n'ai pas la certitude non plsu que le binaire en question ne fasse pas un appel un peu trop spécifique suite au modifs. mais j'aimerais juste qu'on me dise lequel dans ce cas là...
Par contre ce contre quoi je me bats personellement dans ce long threads c'est juste les personnes qui déclarent : "Ca linke du GPL sans être soit même en GPL donc il y a forcément violation."
Parceque ca n'est pas vrai (même si dans 99% des cas ca se vérifie.)
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par ecyrbe . Évalué à 3.
rappelons que la GPL ne parle pas de linkage mais de dépendance...c'est à dire que si un code non GPL est dépendant d'un code GPL, c'est une violation...le code non-GPL doit devenir GPL pour devenir légal...
sinon un code GPL peut très bien appeler du proprio, car sinon on pourrait rien executer sous windows qui soit GPL (et qui cible uniquement la platteforme windows ex:cigwin) car même un logiciel GPL fait appel à un moment donné au système...
Donc, j'ai l'impression que refuser qu'un driver du kernel-space sous GPL fasse appel à du proprio c'est pas vraiment interdit par la GPL mais interdit par les mainteneurs du noyau...
le problème est donc de savoir si pwcx est dépendant vis-à-vis de pwc...si c'est le cas...c'est ça qui viole la GPL...et qui fait que le hook à du être retiré...
c t clair?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Clément Stenac (site web personnel) . Évalué à 1.
et l'inverse ?
du code GPL peut-il charger des trucs propriétaires ? (je pense notamment aux codecs)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 2.
Grosso-modo, si tu as deux programmes un en GPL et l'autre pas, ils ont le droit d'interagir ensemble si et seulement si les seuls fonctions qu'un des programmes appelle chez l'autre sont des fonctions de
- chargement en mémoire
- notification de présence/ d'éxecution
- demande d'accès a des données ou des flux sous forme brute (ie sans que la logique de l'autre programme ne les ait mis en forme, execpetion faite des cas ou cette mise en forme est necessaire au fonctionnement (par exemple l'adressage virtuel de mémoire fait par un kernel))
- ou des fonctions standards définies hors du programme (RFC, POSIX, X Protocol etc.)
Donc si un programme GPL appelle chez un programme non GPL de la logique qui ne rempli pas les conditions ci dessus il y a faute. Même chose si un programme propriétaire ne remplit pas les même conditions.
Pour simplifier encore la formulation : tant que deux programmes n'apellent pas la logique spécifique de l'autre ils peuvent raisonablement être considérés comme indépendants. Et donc tant qu'on ne les distribue pas ensemble on a le droit d'en avoir un seul des deux en GPL.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Christophe Lucas (site web personnel) . Évalué à 2.
Bah apparemment le NDA que Nemosoft Unv.avait signé à expirer il y a un an et à la déscision de ne plus permettre de faire des hook pour charger un binaire, celui-ci aurait décider de supprimer toutes traces de son travail, enfin du moins le travail qu'il a fais sous NDA, car ce qu'il a laissé en GPL restera.
Christophe
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 9.
a - PWC fonctionne en stand alone et PWCX fonctionne en stand alone (moyennant bidouilles) Celà ne constitue donc pas une violationd e la GPL
b - La GPL authorise des lib proprios a lier des applis GPL et des libs GPL a lier des applis ou ldes libs proprios a condition que les parties propriétaires soient inhérentes au système. Comme il s'agit du Kernel et de modules du kernel je pense que l'on peut raisonablement penser que l'on est dans un cas ou c'est inhérent au système. Donc ca ne viole toujours pas la GPL.
c - Le link se fait via un hook qui permet de charger un décompresseur video. Sans ce hook aucun decompresseur ne peut être chargé (les decompresseur fonctionnent comme des inits qui passent la webcam d'un mode a un autre), qu'il soit GPL ou non. Il est très facile (même si ca n'existe pas vu que c'ets el fonctionnement de base) de créer un module GPL qui ferait du RAW (IE n'apellerait rien et ne chargerait aucun compresseur). Donc ca ne constitue pas une violation de la GPL.
C'est dommage mais ce n'est surrement pas de la faute des developpeurs du noyeau qui sur le coup sont on ne peut plus coherent avec leur politique
Niveau cohérence en effet c'est assez fort :
- Ca fait plus de 3 ans que c'est comme ca.
- Il y a un paquets d'exemples de hooks qui servent a charger aussi des drivers/modules propriétaires (Au hasard les drivers XFree/AGP de chez Nvidia, mais il y en a d'autres)
- Enlever ce morceau n'apporte rien au noyeau, ni au niveau architectural, ni au niveau perf, ni au niveau legal. Le seul point de doute pourrait être levé par un driver GPL qui ne fait rien (CF c- plus haut).
- Ca pénalise par contre les utilisateurs tant dans leurs choix que dans l'utilisation de leur machines.
Ne nous y trompons pas, on a affaire a une guerre d'ego. D'un coté une personne qui a décidé pour une raison X ou Y que le module ne lui plaisait pas, et de l'autre une personne qui n'etant plus sous NDA decide de quand même garder les sources fermées pour un motif noble ou non.
Ce qui m'embete le plus c'est que j'ai déjà vu ce type de comportement... Chez XFree86.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Flink . Évalué à 3.
et on a vu ce que ça a donné ;)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Sébastien Rohaut . Évalué à 6.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Krunch (site web personnel) . Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par GhZaaark3 . Évalué à 5.
Si vous ne changer pas votre manière de penser, ça risque bien, à savoir qu'on est pas tous des hackeurs barbus qui se contentent d'une console 80x25 (généreux) pour exploiter son PIV 3.0ghz ou qu'on bosse tous dans des entreprises, le desktop familial/Personnel a une part tout aussi importante, non?.
On est plus à il y a 4-5ans.
C'est bien de vendre Linux en disant "meilleur ci, meilleur ça" même si ça l'est vraiment, mais si l'utilisateur - qui est libre avant tout de choisir - ne peut pas faire ce pourquoi il utilise un ordi, il ne voit aucun intérêt et ira se mettre un Windows (à contre coeur) ou au meilleur cas prendra un Mac.
Finalement je pense que l'excuse des jeux video ne va plus valoir, non pas qu'il y aura un certain bOOm concernant le nombre de jeux nunux compliant mais je pense surtout qu'avec l'avènement des nouvelles consoles de jeux vidéo la donne va vite changer (Sony ne fera pas 2x la même erreur)
Et puis c'est tellement mieux de jouer sur console. chacun son domaine...
Mais comme je ne cesse de le répèter, il n'y a pas que les jeux qui demandent de la 3D et de ce fait ce ne sont pas les jeux qui ont poussé Nvidia à faire des pilotes nunux/*BSD!
Donc merci quand même ces enf*** d'Nvidia de nous pondre des pilotes de bonnes factures qui pour l'instant ne rendent pas mon système instable, mais merci d'autant plus de nous fournir les specs ou d'ouvrir votre code, ce n'est pas pour autant que je (on) baissera les bras. :)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 2.
C'est bien jolie tout ca mais Nvidia est une multinationale. Qui est la pour faire de la thune! Le code des drivers Nvidia est aussi important que les puces presentes dans les cartes. Certain algo des drivers ne seront jamais offert à la concurrence, faut pas rever.
Pour les specs, mouahaha, Nvidia a signé des NDA avec des constructeurs de puces(donc pas de specs completes), et Nvidia ne laissera jamais des developpeurs de logiciel libre venir faire de l'ombre à leurs drivers(qui leur coute des thunes). Surtout que un drivers libre avec la moitié des specs, ca donne les drivers DRI pour les cartes ATI: perf de merde. Et ca, c'est pas non plus bon pour l'image de Nvidia.
Bref, faut pas rever, Nvidia ne bougera pas d'un poil. Si tu veux changer quelque chose, demande toi si c'est pas plutot le monde liberticide dans lequel tu vis qu'il faut changer.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 2.
Je parlais d'un driver 3D gros malin :p
Je vois pas en quoi le driver "nv" vient faire de l'ombre à leur driver proprio.
"nvidia qui ne laissera jamais un dev libre voir les specs en nda"
Ca tombe bien, tout ceci n'est pas présent dans le driver "nv"
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jean Roc Morreale . Évalué à 1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Éric (site web personnel) . Évalué à 2.
Maintenant j'avais ouie dire que nvidia avait embauché le gars sur une période donnée rien que pour ça (bref, que ce n'était pas un employé de nvidia avant et que ça ne l'était pas après), si je ne me trompe pas ça revient bien à filer les specs sous nda à un dev libre, sauf qu'en plus eux ils ont la bonté de payer le gars pour qu'il fasse le développement.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jean Roc Morreale . Évalué à 2.
les specs ne sont jamais sortit de chez Nvidia et si demain le développement du pilote nv devait cesser personne ou alors très difficilement pourrait en reprendre le code obfuscqué et non documenté, qu'il soit sous GPL ou pas.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 0.
Ça marche si le noyau est proprio et le driver GPL. Mais là, c'est l'inverse.
Donc ça ne marche pas. Le noyau est plus "inhérent au système" qu'un driver.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à -1.
Mince, il va falloir le dire a NVidia, Connexant, ATI et pleins d'autres.
Le noyau est plus "inhérent au système" qu'un driver.
Dans un kernel monolithique, ca me ferait un peu mal.... Tu savais que la gestion mémoire par exemple c'était un driver ?
De toute facon je peux lier une appli complètement propriétaire aux bibliothèques standards en GPL. Et ca tombe un peu bien d'ailleurs, parceque sinon pour faire du proprio sur Linux il faudrait y aller franco...
Le fait d'utiliser les APIs standards, les bibliothèques standards ou les appels standards d'un système ne peut pas constituer une violation de la GPL. Si ca n'était pas le cas on ne pourrait soit pas écrire de programmes GPL sous des OS propriétaires, soit pas écrire de programmes propriétaires sous des OS GPL.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 2.
Alors tes gentils, mais va apprendre la difference entre GPL et LGPL et revient dire tes conneries après. Va aussi lire le coup de RMS qui a dit a je sais plus qui de passer son soft utilisant readline sous GPL ou d'arreter d'utiliser readline si tes pas bien convaincu.
Avant de vouloir parler d'un truc, faut ptet etre au courant avant, non mais !
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par ckyl . Évalué à 2.
"Readline is free software, distributed under the terms of the GNU General Public License, version 2. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license. If you would like advice on making your license GPL-compatible, contact licensing@gnu.org.'
Pour les licences compatibles GPL : http://docs.mandragor.org/files/Philosophy/licenses/license-list.fr(...)
(bin oui comme d'hab gnu.org est mort, ils doivent tourner sous Hurd...)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par nicolassanchez . Évalué à 1.
Parce que si c'est le cas, il suffit d'écrire un bibliothèque en LGPL pour accéder à readline et faire un logiciel propriétaire au dessus de cette bibliothèque en LGPL... non ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
non. Tout doit être GPL.
Puis techniquement il n'y a pas de hiérarchie de librairie (sauf l'ordre durant l'édition de lien). Donc il n'y a pas de "au-dessus de".
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 2.
Bon ben je vais en dire une dernière quand même.
Le kernel est en GPL, c'est le seul à gerer les accès a la mémoire physique. Donc toutes les applis qui tuilsent les APIs du kernel pour obtenir une allocation mémoire (en kernel ou en userspace) sont donc soit en GPL, soit sont des exceptions. (La LGPL n'a pas le droit de lier la GPL)
Donc toutes les applis qui fonctionnent sous Linux sont soit en GPL soit tirent parti d'une exception d'une appli ou d'un bibliothèque en dessous d'elles.
Le truc c'est que c'est bien des exceptions, mais pas du tout des entorses a la GPL, mais une non application ou une application parteilel de la protection contre les éléments non GPL. Et ces exceptions sont présente dans la GPL :
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
La clef c'est can be reasonably considered independent Si on considére que d'utiliser des bibliothèques GPL bas niveau d'un système c'est mettre son programme sous GPL, alors aucun programme en peut être raisonablement considéré comme indépendant.
Le terme Bibliothèques standard te gène peut-être. Remplaçons le par "bibliothèques fondamentales". Et dans ce cas de même qu'un programme GPL sous windows peut faire appel a l'API win32 (et heureusement), un programme non GPL sous Linux peut allouer de la mémoire (et heureusement aussi, il y a pas de raison.)
En ce qui concerne readline, la Glibc, la libc ou QT les remarques du thread sont tout a fait valables, mais parce que ce sont des bibliothèques et des applis de trop haut niveau.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 6.
Soit tu utilise des appels systèmes, distants, RPC, un protocole, etc, ... et il n'y a pas de link donc on ne pas prétendre à un travail dérivé. Donc pas de problème.
Soit tu te met à linker des truc proprio avec des lib GPL, et tu violes alors la GPL en beauté (et accessoirement 500 personnes vont te tomber dessus, ta boite mail va etre explosée par des protestations, et un voodoo va te jeter un sort)
Soit tu link le plus légalement du monde avec de la LGPL.
Il n'y a pas énorment de lib bas niveau en GPL, justement pour qu'on puisse faire des appli proprio
Tu parles de biblio std mais LA biblio std est en LGPL et pour ta gouverne il s'agit de la libc.
Il n'y a rien en dessous de la libc, si ce n'est une API par appel système, et non pas une API par appel de fonctions tournant dans le meme user space.
Donc on a le droit de faire des appels systèmes au noyau, quelque soit les 2 licences (du noyau et de l'appli)
PAR CONTRE
On a pas le droit de linker un truc avec le noyau, qui soit pas sous GPL
SAUF, si il utilise des fonctions qui ont été considérées comme une interface bien determinée, ne générant pas un travail dérivé.
J'avoue avoir parlé incorrectement d'exception, car en général une exception c'est l'autorisation d'utiliser une partie proprio avec une partie libre sous GPL. On considère qu'il y a travail dérivé.
La l'API permettant de linker en kernel space ne fait meme pas considéré qu'il y a travail dérivé. C'est heureux car sinon il devrait y avoir une autorisation par module proprio.
Par contre le hook du gas est là pour brancher un travail qu'on ne peut que définir par travail dérivé, donc ca à disparu, et c'est normal.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par djano . Évalué à 2.
Mais s/gas/gars/
Tu as fait plusieurs fois l'erreur il me semble et la je supporte plus.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 0.
Que ceux que ca énervent inutilise ce commentaire pour se venger...
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 3.
Pas du tout.
En fait il est extrèmement complexe de savoir si un code qui lie une appli GPL devient GPL ou non. C'est pour eviter cela que dans le kernel il y a désormais les EXPORT_SYMBOL_GPL. Celà donne uen bonne indication pour savoir si l'on est en train de plonger un peu trop dans le noyau. Grosso modo il y a eu un audit du code Linux et un certain nombre d'EXPORT_SYMBOL ont été changés en EXPORT_SYMBOL_GPL. Si on a besoin pour faire fonctionner son module de faire appel a des entrées qui ont été exportées par EXPORT_SYMBOL_GPL alor son peut être certain que le module DOIT passer en GPL. Par contre pour les EXPORT_SYMBOL ca n'est pas sur, peut-être que le code du module n'est pas obligé de passer en GPL.
On Thu, 4 Dec 2003, Jason Kingsland wrote:
> > - anything that has knowledge of and plays with fundamental internal
> > Linux behaviour is clearly a derived work. If you need to muck around
> > with core code, you're derived, no question about it.
>
>
> If that is the case, why the introduction of EXPORT_SYMBOL_GPL and
> MODULE_LICENSE()?
It is really just documentation.
This is exactly so that it is more clear which cases are black-and-white,
and where people shouldn't even have to think about it for a single
second. It still doesn't make the gray area go away, but it limits it a
bit ("if you need this export, you're clearly doing something that
requires the GPL").
Note: since the kernel itself is under the GPL, clearly anybody can modify
the EXPORT_SYMBOL_GPL() line, and remove the _GPL part. That wouldn't be
against the license per se. But it doesn't make a module that needs that
symbol any less needful of the GPL - exactly because the thing is just a
big cluehint rather than anything else.
Il n'y a pas énorment de lib bas niveau en GPL, justement pour qu'on puisse faire des appli proprio
Ben les appels du kernel sont bas niveau. Et c'est de celà que l'on parle prioritairement non ? Sinon je citerais les stdio et autres malloc/kalloc qui sont vraiment bas niveau.
Donc on a le droit de faire des appels systèmes au noyau, quelque soit les 2 licences (du noyau et de l'appli)
Tout a fait, quand on bosse en user space, on peut dificilement faire un travail dérivé du kernel. Donc la question ne se pose pas. Néamoins ca n'est pas le seul cas ou on a à faire à un travail qui en utilise un autre sans pour autant être un projet dérivé. Le problème se pose surtout quand on porte une application d'une plateforme quelconque vers une plateforme GNU. On peut dificilement considérer un programme comme un projet dérivé d'une lib si le programe existe depuis plus longtemps que la lib qu'il lie sous Linux.
SAUF, si il utilise des fonctions qui ont été considérées comme une interface bien determinée, ne générant pas un travail dérivé.
J'imagine que tu fais allusion aux EXPORT_SYMBOL vu plus haut. dans ce cas je suis tout a fait avec toi, mais ca n'est pas une exception au kernel. Les fonctions qui existaient et etait normés bien avant Linux ou la GPL (maloc(), cat, vi, grep, ed, etc, free() et j'en passe ) ne passe pas en GPL si on les compile avec un lien vers une bibliothèque GPL. Il ne fait aucun doute que ce sont des travaux qui ne sont pas dérivés des librairies qu'ils linkent, et de fait tant qu'on les distribue séparément ils ne sont pas soumis a la GPL.
Par contre le hook du gars est là pour brancher un travail qu'on ne peut que définir par travail dérivé, donc ca à disparu, et c'est normal.
La je suis d'accord avec ton raisonement. Mais par contre je ne le suis pas avec tes hypothéses. Je ne vois pas en quoi la notion de travail dérivé est si évidente que celà....
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 2.
Sinon on en revient toujours au meme point : dans un soft ou il existe un système de plugin, imagine un type qui met, disons dans le fichier définissant l'interface des plug'ins, toutes les fonctions du code dans des wrappers, et distribue cette modif sous GPL.
Il peut ensuite bien tranquillement coder en dérivant le soft sans le dériver :p
Et si on lui dit "euh, t'es bien gentil, mais ton truc est dépendant du bidule GPL, donc met le sous GPL ou arrete de le distribuer", ben il lui suffit de reimplementer toutes les fonctions utilisées pour qu'elles fassent le moins de chose possible tout en permettant à son truc proprio de faire semblant de fonctionner, ou alors pour faire un truc qui a completement rien à voir...
J'ai bien l'impression qu'ici c'est de ca dont il s'agit : en standalone le truc du gars il sert à rien, et le type avait rajouté un hook dans le noyau rien que pour son truc proprio.
Donc on est bien obligé de croire les gars du noyau quand ils disent : le proprio c'est cet API et pas une autre. Sinon c'est la porte ouverte à toutes les dérivations masquées. Genre un noyau linux GPL rempli de hook qui font tous des appels à un truc proprio pour supporter une nouvelle archi... Et pour justifier la non dépendance, des programmes qui appelent les fonctions propriétaire pour utiliser certains algorithme d'une autre manière, ou carrement un système de test complet...
Alors, possible ou pas ? Faut-il violer consciemment la volontée des auteurs de linux, qui est de ne pas utiliser autre chose qu'un certain ensemble de fonction quand on est proprio, et si oui est-il légal de le faire ? Ont-ils clairement auparavent stipulés qu'ils ne souhaitent pas que des bidules proprio se chargent sans passer par l'interface officielle ? Le chargement du controlleur proprio de la webcam oubliait-il opportunnement de pourrir le noyau ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 2.
Pas du tout. Ca a d'ailleurs été le but de l'audit de Linux. Grosso modo charger un plug-in, le laisser s'executer et lui envoyer les infos qu'il demande sans les avoir traitées par une logique en GPL permet au plug-in et au programme de garder les licences qu'ils veulent.
Ensuite les trucs qui existent depuis longtemps (Posix par exemple), pour lesquels il existe dans le programme une logique en GPL, peuvent être utilisés par des programmes non GPL (On a pas la spécificité du code GPL, là c'ets juste l'implémentation d'une norme)
Pour finir les trucs qui ont une logique GPL spécifique, mais qui sont obligatoires et n'apportent rien au programme (Gestion de mémoire virtuelle pour un programme qui fait juste des allocations/libérations, file system pour un programme qui utilise l'API pour créer/déplacer/détruire des fichiers) ne compte pas non plus et on peut les appeler depuis du non GPL.
Par contre créer un demi module non GPL qui utilise de la logique spécifique en GPL est interdit.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 4.
Va lire COPYING.modules des sources de Linux. Il y a une exception à la GPL et c'est pour ça que ces drivers proprios sont autorisés. Pour pwc c'est un autre problème.
> De toute facon je peux lier une appli complètement propriétaire aux bibliothèques standards en GPL.
Non. Et regarde bien, libc, etc sont sous LGPL et pas GPL.
Qt est GPL et tu ne peux pas faire d'appli proprio avec. Vas sur le site trolltech pour te renseigner.
> Le fait d'utiliser les APIs standards, les bibliothèques standards ou les appels standards d'un système ne peut pas constituer une violation de la GPL.
Le problème est de savoir qui utilise qui.
- C'est le noyau Linux qui utilise le driver ?
- C'est le driver qui utilise le noyau Linux ?
Pour un programme, on peut dire qu'un programme proprio utilise la libc mais on ne dit jamais l'inverse.
> Si ca n'était pas le cas on ne pourrait soit pas écrire de programmes GPL sous des OS propriétaires
C'est le programme sous GPL qui utilise des lib proprio et pas l'inverse. Donc pas de problème (tant que les libs sont "inhérentes au système").
Linux est GPL et pas LGPL.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 2.
C'est un autre problème dans la mesure ou contrairement a ATI et Nvidia, pwcx peut fonctionner avec un feed raw qui ne vient pas du noyeau, et peut de fait être considéré comme raisonablement indépendant. Le gros problème c'est que pour faire ca ca implique de passer l'initialisation de la webcam en userspace et de faire un trou de sécurité dans le kernel pour qu'il laisse l'appli aller taper le hardware directement.
En fait la seule chose que fait le hook de pwc c'est de permettre a pwcx de "voir" le flux de données vidéos au travers du kernel et d'initialiser la camera dans un mode ou un autre.
Après on peut partir dans de grands debats sur ce que "raisonablement indépendant" veut dire dans les faits, mais très sincèrement une appli qui ne fait que demander un moyen d'acceder directement au matériel, non pas en utilisant les fonctions du kernel mais en passant au travers, rentre définitivement dans la définition.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
J'ai dit ailleur que c'est un "bête" problème de respet de la GPL.
Il a un code sous GPL il appèle un truc non GPL. C'est tout.
Avec Linux c'est possible (NVidia le fait :-)) mais il faut le faire selon COPYING.modules (voir les sources de Linux).
Il n'y a rien de subjectif ici.
Comme déjà dit à plein d'endroit ici, avec un petit effort, le mainteneur de pwc peut tout remettre dans l'ordre.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 1.
Il a un code sous GPL il appèle un truc non GPL. C'est tout.
En fait il a du code GPL qui lui ouvre un tuyeau vers le periph en direct sans passer par le kernel. C'est bien le problème. ce n'est pas tant une exception a la GPl, qu'une exception au kernel qui ouvre grand les portes pour laisser passer un module fermé.
Et puisse que tu cites le copying.modules, je te renvois a uen discussion assez passionante sur le kernel trap qui défini assez bien pourquoi un driver non GPL peut parfaitement être appelé/chargé par le noyau sans qu'il y est la moindre infraction a la GPL...
http://kerneltrap.org/node/view/1735/5354(...)
On y trouve notamment :
Basically:
- anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work.
- anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it.
Par M Linus lui même.
Le problème dans le cas qui nous interresse est que 1) PWCX n'utilise pas les fonctions standard du kernel, il utilise une fonction spécifique pour pouvoir paser au travers du kernel pour les accès périphs, par contre il utilise une connection USB via le kernel donc il est sur la tangente. 2) Les algos de compression et de décompression ainsi que les initialisations diverses n'ont pas été faites spécifiquement pour Linux. Elle marcherait sous n'importe quel système pour peu qu'elles soient envoyés en direct sur le port USB, cependant ces algos ont étés portés sous Linux, notamment pour la compatibilité V4L...
Bref on a un truc qui est un poil entre deux chaises. Sans utiliser les fonctions du kernel, il profite quand même d'un accès port USB ouvert par le kernel, sans avoir été écrit pour Linux, il a été retouché de ci de là pour mieux s'integrer.
Le problème c'est déjà présenté une fois :
Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area.
Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.
Maintenant savoir si PWCX doit être considéré comme un travail dérivé ou non me passe très loin au dessus de la tête. Mon opinion perso est que non, et je ne pense pas que ce soit trivial...
kha.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
Justement, le fichier qui pose problème est GPL !
Le driver est dans les sources Linux officiel qui doit être GPL !
On ne parle pas d'un modules séparé (quoique maintenant il a été viré Linux :-)).
Si tout son modules est proprio, il n'y a pas de problème. En conséquence, il ne fait plus parti du Linux officiel, il ne peut être diffusé avec Linux, etc...
Des désagréments que supporte NVidia etc...
Pour le reste, je suis fatigué.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 2.
Pas du tout, le fichier en GPL (ie le pilote PWC) est parfaitement légal et ne pose aucun problème. C'est juste que le hook qu'il créé a été retiré parcqu'il était utilisé seulement par un binaire propriétaire.
On ne parle pas d'un modules séparé (quoique maintenant il a été viré Linux :-)).
Et bien ci, PCWX (le binaire proprio) est séparé.
Pour le reste, je suis fatigué.
Menteur, je viens de lire ton troll contre PBPG, tu tiens plutôt la forme...
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par 007 . Évalué à 1.
Faudrait savoir. S'il est l'égal, pourquoi il faut le modifier alors ?
Je suis impatient de connaitre ta réponse.
> Et bien ci, PCWX (le binaire proprio) est séparé.
Lui il ne pose pas de problème.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 2.
Je suis impatient de connaitre ta réponse.
Ben j'attend toujours celel de greg donc...
Apparament Linus aurait déclaré que l'on ne faisait pas de hook dans le kernel seulement pour des binaires proprios. Pour que le hook existe et reste il fallait qu'il y ait aussi des applis GPL qui utilisent ce hook. Et comme pour le hook de PWC il n'y a que PWCX qui l'utilise, paf dehors...
Le problème est que Linus a dit en fait qu'il ne fallait pas rajouter de hook au kernel seulement pour un binaire proprio, or le hook en question n'a pas été rajouté récamment (du moins après les paroles de Linus) mais bien avant...
Quand a la légalité du truc elle est inconnu vu que c'est justement en faisant l'audit des exports que les devs sont tombés la dessus. En fait ils l'ont giclé avant de l'auditer...
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Emmanuel Seyman . Évalué à 5.
J'ai l'impression que tu crois que NVidia, ATI, ... ont reçu l'autorisation de lier leur code proprio a la GPL. Ce n'est pas le cas.
Linus a dit "Si vous utilisez l'interface documentée pour modules non-GPL, on ne portera pas plainte". Et depuis, tout le monde fait comme ça.
Emmanuel
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par CoinKoin . Évalué à 5.
Attention toutefois : la GPL autorise bien le code libre et le code propriétaire à être liés entre eux, et même autant que l'on veut. Simplement, l'ensemble doit être placé sous GPL s'il y a _redistribution_ de l'ensemble. Nvidia peut légalement faire un pilote propriétaire et le diffuser, mais pas le diffuser lié à un noyau. L'utilisateur peut légalement télécharger ce pilote et le lier lui-même, mais il perd alors le droit de redistribuer le noyau ainsi obtenu (il faudrait pouvoir distribuer les sources de l'ensemble).
Mais tant que le programme n'est PAS redistribué, on peut faire ce que l'on veut, la GPL reste silencieuse.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par isydor . Évalué à 2.
yoper, aurox, xandros, etc... parlent de drivers 3D NVIDIA (et pas nv) inclus. Ils trichent ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par gnumdk (site web personnel) . Évalué à 2.
Je m'etait tjs demandé pourquoi Suse ne faisait pas comme mdk mais vu ton explication, c'est MandrakeSoft qui a tord :/
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par ced . Évalué à -1.
nvidia: module license 'NVIDIA' taints kernel.
Tu as une idée de ce que va dire ou je t'explique ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Éric (site web personnel) . Évalué à 2.
Ce n'est pas la notification d'un changement de licence. Le module nvidia ne passe pas GPL parce que toi dans ton garage tu l'utilises avec un noyeau GPL, et inversement le loyeau GPL ne passera pas d'un coup proprio (le GPL ne pourra jamais que respecter la GPL) sous prétexte qu'on y rajoute un module.
Quand tu fais l'exécution des deux ensemble dans ton garage il n'y a aucun changement de licence, aucune contamination de licence (ni d'un coté ni de l'autre), aucune violation de licence (rien dans la GPL ne limite l'exécution, seule la diffusion est restreinte).
Bref, ça veut juste dire "si tu fais ça faudra pas venir nous emmerder si ça marche pas" et "attention car tu utilises des trucs pas compatibles GPL". Ca ne change rien au débat puisqu'il n'y a rien de légal là dedans.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 5.
Ca change rien.
Le fait de laisser le hook du gas n'aurait pas entrainé de violation de GPL directement, mais la seule utilisation qui en était faite en était une. Du coup ca saute. Si le gas veut continuer son truc en entrant dans le coté obscure, il a cas faire un patch. Et si t'es pas très regardant sur les licence tu pourra continuer a utiliser PWCX. Les distri pourront plus certes, mais vu que c'est illégal...
2) Non.
Le propriétaire est simplement toléré dans le noyeau sous certaines conditions.
Le fait est que ces conditions n'etaient pas respectées sur le driver. Le fait est qu'il existe depuis peu un moyen de maitriser automatiquement le respect des conditions (précision de la licence dans le driver, etc...) donc le coup du "ca fait longtemps que je bosse dessus" est caduc.
- Ca pénalise par contre les utilisateurs tant dans leurs choix que dans l'utilisation de leur machines.
Ben deja utiliser nux ca pénalise les users à la base. Faut commencer a comprendre que nux c'est aussi la GPL, pas simplement un superbe noyeau sur lequel tout le monde peut linker un module sous n'importe quelle licence.
Si l'user il a envi d'utiliser n'importe quoi sans ce préocupper de savoir si ca a marché ou pas et sans comprendre les raisons qui font que ca marchait bien et tout d'un coup ca marche moins bien, ben faut surtout qu'il utilise win et jamais de mac ni de nux....
-- En plus on masque les vrais problèmes avec cette histoire... Qu'est ce qui jusitifie que les spec d'une webcam ne soit pas publiques ??? Est ce que quelqu'un va oser me sortir que les specs permettrait aux concurrents de faire une puce plus simplement et de comprendre comment la cam marche en interne ? (note on ma déjà fait le coup avec les CG et j'y ai meme cru à moitié pendant 5 minutes ;)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 2.
Ca change rien.
Ca change tout, parceque si il peut fonctionner sans utiliser le noyeau (ce qu'il fait déjà, mais bon) ca veut dire qu'on peut quand même raisonablement le considérer comme indépendant. Par suite si il est distribué séparément du noyeau, il n'a pas a se soumettre a la GPL et c'est de ca qu'on parle.
2) Non.
Le propriétaire est simplement toléré dans le noyeau sous certaines conditions.
Le propriétaire, ou les licenses non compatibles sont authorisées a utilsier des programmes GPL sous reserve que "l'on puisse raisonablement le considerer comem indépendant". Je veux bien que l'on m'explique que cette condition n'est pas ou plus satisfaite pour pwcx, mais que l'on ne vienne pas parler de tolérance : c'est dans le texte de la GPL !
Ben deja utiliser nux ca pénalise les users à la base. Faut commencer a comprendre que nux c'est aussi la GPL, pas simplement un superbe noyeau sur lequel tout le monde peut linker un module sous n'importe quelle licence.
Une fois de plus la GPL présente une option qui peut être remplie par des modules sous n'importe quelle license.
Qu'est ce qui jusitifie que les spec d'une webcam ne soit pas publiques
A priori pas grand chose. Les formats de couleur et de compression sont pour la plupart connus. Un mémlange de NDA croisés et d'accord tacites j'imagine.
(note on ma déjà fait le coup avec les CG et j'y ai meme cru à moitié pendant 5 minutes ;)
Si c'est a un de mes posts précédent que tu fais référence, je susi désolé que ca n'ait pas marché plus de 5 minutes...
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 3.
Sinon ca serait trop la rave, suffirait de faire des modules dynamiques qui se chargent dans 3 appli différentes pour pouvoir faire n'importe quoi.
Ca ne peut marcher que si les hooks du run time sont autorisé initialement. Un contributeur ne peut pas venir changer la licence et dire "tient, je rajoute un bout de code, et je dit que l'appel de cette fonction ne generera pas de travail dérivé".
Sinon il suffit d'encapsuler toutes les fonctions dans des hooks définis par le contributeur comme travail dérivé pour pouvoir linker du GPL libre avec du proprio, sans controle des interfaces et en integration totale. D'ou par l'absurde la conclusion que rajouter un petit hook personel pour pouvoir linker son petit truc proprio dans le kernel est impossible. Et c'est bien de ca qu'on parle ! Le fait qu'il est aussi possible que pwcx fasse aussi le café en user space ni change absolument RIEN.
* you are going to accept that there is a driver in the Linux kernel that
has a hook that _may_ be used to load a binary-only decompressor part into
the kernel, at the user's disgression. Maybe, one day, that part will be
open source too but I cannot guarantuee that.
Ca aurait du te suffire pour te convaincre qu'on parle bien ici d'un travail dérivé.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . Évalué à 2.
Et non...
Le fait d'intégrer un module (binaire ou non) dans un programme ou dans une lib ne fait pas du module un produit dérivé.
Typiquement si je créé un editeur de texte que j'apelle totoEdit et que je place sous GPL, et que dans cet éditeur de texte je créé un système de plugins. Maintenant un autre programmeur aime bien certaines fonctionnalités de mon éditeur (comme le broswer et les joulies icones) mais pas du tout l'interface de saisie, et il décide de créer mod_vi_bsd parcequ'il aime bien la version BSD de vi. mais comme c'est un mechant vilain pas beau, il ne distribue pas le code source et fait payer les autres pour ce plug-in (ce que la licence BSD permet)
Ben déjà je vais avoir du mal a prétendre que vi devient un travail dérivé de totoEdit (genre beaucoup même), je pense même que si j'essaye on va violamment se fiche de moi.
Ensuite si le mec qui a utilisé mon système de plugins pour changer l'interface de sasie n'utilise que des appels non spécifiques à mon appli (genre utiliser ma trappe a évènements) et bien il ne violera même pas la GPL. Il suffit juste qu'il ne distribue pas l'ensemble appli+plug-in sur le même support...
Le gros problème est cic de savoir quand il dépasse la limite en faisant un appel a une fonction qui est trop aprticulière a mon prog pour qu'on puisse encore raisonablement considérer son travail comme indépendant... Là c'est le hic.
Dans le cas qui nous interresse les mecs qui ont filés les specs pour faire pwcx en avait rien a faire de Linux, il est donc très probable qu'aucun algo dans ce qu'ils ont filé ne soit spécifique Linux. A partir de la si tout ce que fait le module binaire c'est de se charger en mémoire kernel et d'acceder en direct au la webcam, normalement il ne viole pas non plus la GPL...
Kha.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 1.
La clef de ton exemple est une précision dans la licence: l'utilisation de tel ensemble de fonction ne constitue pas un travail dérivé. Sinon personne ne peut le deviner.
Maintenant si quelqu'un fait un patch qui modifie ton logiciel (pas juste faire un plugin) pour rajouter une fonction et que cette fonction est utilisée pour charger du code proprio, je doutes que le chargement du code proprio qui ne passe pas par l'API que tu avais autorisé pour les travaux non dérivés soit très catholique.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Éric (site web personnel) . Évalué à 2.
> pourra l'utiliser, puisque la combinaison du tout violerait la GPL.
La seule question au niveau licence c'est de savoir si on peut diffuser la partie proprio (indépendament ou pas). L'utilisation par les gens est elle forcément possible du point de vue licence. La GPL ne limite que la diffusion. Chacun est libre d'utiliser chez lui du GPL avec du non GPL, de lier les deux, de modifier du GPL en y mettant des bouts de proprio dedans (enfin c'est autorisé par la GPL en tout cas), etc.
Donc grosso modo c'est tout le contraire de ce que tu dis ;). Qu'on ai le droit de le diffuser en proprio ou non, tout le monde aura forcément le droit de l'utiliser.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 2.
En même temps qu'en j'y repense c'est mieux comme ca. J'ai été tellement habitué aux lois liberticides et aux copyright plus que fermé de partout que j'ai même plus l'habitude de penser à faire strictement ce que je veux chez moi, snif... !
Bon pour en revenir au module proprio de la webcam, il faut voir si se ne serait pas un travail dérivé de sa modif GPL du noyau (donc un travail dérivé du noyau en bref), ce qui constiturait une violation nan ?
Parce que si l'on ne considère pas cette possibilité, alors il n'y aurait aucun problème à diffuser un prog non compatible GPL capable d'utiliser Readline, et on sait bien que ce n'est pas possible. Donc ya forcement un truc.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . Évalué à 3.
Si c'est a un de mes posts précédent que tu fais référence, je susi désolé que ca n'ait pas marché plus de 5 minutes...
Ah c'etait toi ? :)
Ben en fait j'y crois plus qu'à 25 % là :p
Je ne prétend pas que ce que tu disais était impossible. J'en suis arrivé à un point ou j'attend simplement de voir. Or il ne me sera surrement pas donné de voir un driver de CG proprio dans ma vie, donc à mon d'aller bosser chez NVidia pour en faire, ce que je ne souhaite pas, je ne peux que supposer que ca dévoilerait beaucoup trop d'info ou non. Et je penche dans la balance de "ca pourrait devoiler quelques info interressantes, mais rien de crucial vis à vis des connaissances à peu près aussi étendu du concurrent".
Je considère aussi un echange technologique simultanné (qui si je reste réaliste ne se produira certes jamais) et je me demande ce que ca donnerait si il était mis en place par ouverture simultané des sources des deux cotés.
Là j'avoues que je vais un peu trop loin dans mes rêves utopiques :)
[^] # Noyau
Posté par Gart Algar . Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Noindex Nofollow . Évalué à 2.
> de la cam et si on peut reecrire son bidule sans passer 3 mois à
> reverse enginerer les anciens drivers ou ceux de win.
Euh... là j'ai des doutes. Je m'explique.
1- s'il a signé un NDA, il ne pourra pas diffuser les specifications techniques qu'il a obtenues grâce à ce NDA. Donc oublions les specs complètes. Soit il les a rendues, soit elles resteront bien au chaud chez lui.
2- si reverse engineering il doit y avoir, ce n'est certainement pas sur le software, car je suis persuadé que ce serait une violation de l'EULA de Philips.
Autrement dit: on oublie une récupération rapide du pilote/module. Les utilisateurs de webcam Philips vont devoir patienter.
Maintenant, il est tout à fait possible que quelqu'un signe un nouveau NDA avec Philips. Des volontaires?
En revanche, il doit être possible de faire du reverse-engineering sur ce qui entre et sort de la webcam, mais ça c'est un autre problème.
Je me goure?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par tao popus . Évalué à 1.
Comme dit precedement, la NDA à éxpirée mais il ne veut pas pour ca diffuser le code, pour pas froisser Philips, mais si le NDA était limité en temps, c'est parce que Philips l'a voulu, donc c'est plutot le dev, qui veut garder le contrôle total du projet. Donc, il n'est plus vraiment dans la philosophie du libre....
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par tao popus . Évalué à 5.
Ca me parait excessif, de nombreuses webcam logitech et d'autres marques, utilisent ce driver qui est libre:
http://qce-ga.sourceforge.net/(...)
(certaines utilisent le chip philips)
D'autres utilisent ce driver:
http://spca50x.sourceforge.net/spca50x.php(...)
ou bien ca:
http://www.crynwr.com/qcpc/(...)
De plus, les appareils photos, cameras (via port d'acquisition video (analogique ou digital)), peuvent faire webcam, etc...
Peux etre aurais t il fallu attendre qu une alternative a ce module soit developper avant d exclure une partie des possesseur de webcam.
Bah, il faut un peu faire bouger les choses, surtout que le NDA est fini depuis plus d'un an, je comprend l'impatience des defenseurs du libre que sont les devs de Linux.
Je pense que des gens vont se faire le plaisir de faire du reverse engeenering. Cela étant légal pour des produits non-portés sur un OS (il n'y aura pas un lobby qui poussera a l'emprisonement comme pour les DVD).
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Christophe BAEGERT . Évalué à 2.
> driver qui est libre:
Certes.... et tu les trouves où ???? La plupart ne sont plus produites depuis longtemps ou n'ont jamais été distribuées à grande échelle.
Moi ce que je vois c'est que sur le marché français, les webcams sont :
- soit non supportés sous linux
- soit supportées par pwc
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par tao popus . Évalué à 1.
http://www.rue-montgallet.com/prix/75012/comparer/208/Webcams/(...)
Pour la logitech quickcam express, dans certains pack d'abonnement de certains fournisseurs d'acces.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Christophe BAEGERT . Évalué à 0.
quand à ton lien, la quickcam express n'est que dans 2 boutiques (dont le surcouf, laisse tomber) et specktel (mais va savoir si elle est vraiment en rayon). en plus il semblerait que les dernières quickcam express aient changé de chip (une fois de plus, merci Logitech !!!), sans qu'on puisse savoir laquelle on achète, et la nouvelle a un driver "expérimental"... quant aux autres logitech, c'est des pwc pour la plupart.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Croconux . Évalué à 3.
La solution est simple : Faire comme pour tous les autre drivers comportant une partie binaire non libre (Nvidia) : Les distribuer à part. Après si l'auteur ne veut pas le faire quelqu'un d'autre peut s'en charger.
On se croyerai presque chez M. Fenetre où quand on change d'os , bah les drivers sont plus compatibles , et tampis si ca marche pas : rachetez vous du matos ....
Et quel est le point commun entre Fenêtre et ce driver ? Bah ils sont tous les deux binary only. Les gens qui utilisaient se driver savaient qu'en utilisant un driver binaire ils n'avaient aucune garantie de pérénité.
Peux etre aurais t il fallu attendre qu une alternative a ce module soit developper avant d exclure une partie des possesseur de webcam
L'alternative on l'a : Distribuer le driver séparément. Ce n'est la faute des devs si l'auteur fait un cace nerveux plaque tout.
# pas cool :/
Posté par fouinto . Évalué à 2.
J'ai utilisé ce driver pour la première fois il y a un peu plus de 3 ans, et je dois dire qu'ils fonctionnaient déjà très bien à l'époque.
On doit justement recommander des webcams... il va falloir que je me re-casse le c*l pour trouver des webcams performantes et compatibles linux... que j'explique à mes chefs pourquoi ça ne fonctionne plus (plus aussi bien à priori, et puis, s'il faut qu'ils recompilent un noyau, je vais rire...) sous linux...
J'estime que Linux a perdu sur ce coup là un driver de qualité et que mes chefs ne vont pas tarder à me tomber dessus pour repasser à Winmachin...
Franchement, je trouve l'attitude des mainteneurs du noyau assez intaigriste sur ce coup là... et j'imagine que je ne vais plus avoir de support du modem de mon portable sans recompilation du noyau non plus...
Linux perd un driver de qualité (je l'ai déjà dit) et vu que le support du matos est déjà une faible de linux, ce vraiment pas cool.
[^] # Re: pas cool :/
Posté par Guillaume Knispel . Évalué à 3.
??? Comprend pas du tout cette phrase.
[^] # Re: pas cool :/
Posté par snurpsss . Évalué à 0.
a moins que comme écris plus haut toute cette histoire ne soit que gaminerie entre des personnes qui ne s apprécie pas .
on verra si les mainteneurs du noyau qui ont pris cette decision vont jusqu au bout de leur pensée et font de meme avec les autres drivers qui sont dans le meme cas technique .
[^] # Re: pas cool :/
Posté par Guillaume Knispel . Évalué à 5.
[^] # Re: pas cool :/
Posté par gpe . Évalué à 1.
Si seul des gens qui sont appréciés par les mainteneurs du noyau peuvent faire des drivers, le LL ne va pas aller bien loin. Parce que dans le proprio on arrive parfaitement à gérer ce genre de situation... (je parle par expérience).
Il faudrait aussi que les grands gourous du LL s'aperçoivent que maintenant il y a des utilisateurs du LL et que donc ils n'ont pas le droit de les ignorer.
[^] # Re: pas cool :/
Posté par 007 . Évalué à 4.
C'est le ponpon ça !
Il y a un licence dans Linux qui est là pour les utilisateur et les développeurs respectent cette licence pour les utilisateurs.
Si l'utilisateur pense trouver son bonheur avec du proprio, alors qu'il utilise un OS proprio et fin de l'histoire pour l'utilisateur qui en a rien à foutre du LL.
Je suis utilisateur et _client_ de LL. Il est hors de question que le LL soit du logiciel proprio (cherchez l'erreur :-)). Point barre.
[^] # Re: pas cool :/
Posté par gpe . Évalué à 0.
Mais dans ce cas il ne fallait pas laisser la situation s'installer!
Là il s'agit de gérer une situation existante, qui de plus semble plus être un conflit de personne qu'autre chose (à ce que j'ai compris). Et bien dans ce cas je maintiens ce que j'ai dis. Tu ne peux pas ignorer les utilisateurs qui en plus ne sont pas forcément informaticien et ne comprennent donc rien aux pseudos raisons techniques de la chose...
[^] # Re: pas cool :/
Posté par 007 . Évalué à 1.
Je ne crois pas. C'est un problème de licence.
> Tu ne peux pas ignorer les utilisateurs
Et les développeurs qui travaillent gratuitement, avec des convictions éthiques fortes, qui ne demandent aucun droit sur leur travail parfois génial, pour avoir une solution libre sympatique, tu en fais quoi ?
Même pour le logiciel libre le client (client de quoi puisqu'il n'achete rien) est roi ?
[^] # Re: pas cool :/
Posté par gpe . Évalué à 1.
A partir du moment où tu fais quelquechose que tu diffuses largement pour que se soit utilisé par autrui tu ne peux pas ignorer le destinataire final, même si tu le fais bénévolement.
Je vais prendre un exemple que je pense très parlant:
Je fais de la spéléo, je suis même initiateur spéléo, et au sein de mon club ou de la fédé je fais de l'encadrement en initiation ou perfectionnement. Je fais tout celà bénévolement. Avec ton raisonnement, je n'ai donc aucune obligation vis-à-vis des personnes que j'encadre... Si la personne tombe, se blesse ou se tue, tanpis pour elle, moi je suis bénévole... Et ben, non, ça ne se passe pas comme ça, j'ai des obligations envers elle, j'en ai même énormément!
Par contre personne ne m'oblige à faire de l'encadrement, comme personne n'oblige un développeur à faire du LL. Donc si tu ne veux pas être embêté par les utilisateurs, tu peux aussi ne pas faire de LL...
[^] # Re: pas cool :/
Posté par 007 . Évalué à 1.
Je reprend.
Tu fais de la spéléo bénévolement. C'est ton chois, ton plaisir, ta mission, etc... Tu est aussi à l'écoute.
Je suis un utilisateur/client de tes talents et je te demande de m'initialiser à l'escalade en t'expliquant que je suis ton client, que tu as des responsabilité envers des clients etc.
Que va-t-il se passer ?
Tu va m'envoyer balader et tu auras bien raison. Tu veux faire de la spéléo et pas de l'escalade.
Ici, mon impression est que les developpeurs Linux dans leur ensemble veulent que Linux soit GPL et qu'on leur demande d'ignorer leur "envis" de GPL pour être arrangeant avec pwc.
Tu comprends mieux ?
[^] # Re: pas cool :/
Posté par gpe . Évalué à 0.
ça je ne le leur reproche pas au contraire! La seule chose que je reproche c'est la façon de gérer la situation existante...
[^] # Re: pas cool :/
Posté par 007 . Évalué à 1.
C-à-d ?
[^] # Re: pas cool :/
Posté par gpe . Évalué à 0.
Moi je dis qu'entre ces 2 situations il ne doit pas y avoir de rupture de "service". C'est tout...
[^] # Re: pas cool :/
Posté par 007 . Évalué à 1.
pwc c'était déjà fait attrapé par la "patrouille" (Alan Cox). Le mainteneur a recommencé.
> il ne doit pas y avoir de rupture de "service".
C'est à 95 % de la responsabilité du mainteneur du driver :
- Il ne veut pas respecter la GPL
- Il a demandé la suppression du driver du Linux officiel
- Il a fermé ça page web
Et pourquoi ?
Car il veut avoir le privilège de ne par respecter la GPL et ce à la barbe de tous les dev Linux.
Tu peux estimer que mon apréciation est subjectif, mais là il ne pouvait y avoir qu'un clash.
[^] # Re: pas cool :/
Posté par gnujsa . Évalué à 2.
Bé quand même, ils sont pas tous barbus !
Ah mais tu parlais d'Alan Cox ?
;-)
[^] # Re: pas cool :/
Posté par Croconux . Évalué à 2.
Il s'agit quand même d'activités très différentes. Tu prends en charge des personnes que tu vas guider dans une activité qui peut être dangereuse si on ne s'y connait pas. Si tu fais des conneries tu peux être accusé de mise en danger de la vie d'autrui. C'est quand même plus grave qu'un driver pour webcam, non ?
Dans le cas présent il s'agit plus de satisfaire les désirs des utilisateurs. Et là il n'y a aucune garantie. Si un débutant viens te voir et te demandes de l'emmener dans un gouffre dangereux est-ce que tu le ferais ? Et s'il t'engueulait parce que tu ne veux pas suivre à les lettre ses désirs comment réagirais-tu ?
[^] # Re: pas cool :/
Posté par fouinto . Évalué à -1.
Je ne pense pas dire de conneries sur ce coup là...
et puis... un firmware, c'est considéré comme binaire dans ce cas?
Et puis... pour revenir au driver des webcams philips, je voulais préciser que, le développeur du module en question n'avait pas le choix de mettre cette partie en binaire a cause du NDA qu'il avait signé :(
[^] # Re: pas cool :/
Posté par Flink . Évalué à 2.
Enfin bref si c'est le cas, ils ont tout compris pour refaire passer les gens de linux à windows, on applaudit bien fort
[^] # Re: pas cool :/
Posté par Quentin Delance . Évalué à 3.
En l'occurrence c'est bien d'avoir un noyau libre mais si c'est pour avoir besoin de firmwares ou modules binaires closed source ben non merci.
Cette histoire de webcam m'ennuie depuis un moment. Je suis le malheureux proprio de ce type de web cam qui avait fait gaffe au support du matos sous Linux. A l'epoque c'etait possible de faire tourner le module PWC (open source) sans le binaire (PWCX). Depuis les dernieres versions c'etait plus possible (enfin d'apres ce que je lis a droite a gauche sur les forums), binaire obligatoire, donc pas de support "out of the box" donc chiant. Bref pas grand public (oui du coup la detection auto et le montage des bons pilotes tu peux la rever). Tres loin de l'esprit libre tout ca (en ce qui me concerne un achat inutile).
[^] # Re: pas cool :/
Posté par Flink . Évalué à 4.
Par exemple j'ai une carte graphique nvidia et je suis très content du driver de chez nvidia même s'il est proprio, au moins y'a du support de la part du constructeur. Et les perfs sont au rendez vous pas comme avec des ATI ou le driver libre nvidia qui permet de rien faire...
Y'a le sens pratique aussi des fois qui est en jeu
[^] # Re: pas cool :/
Posté par Quentin Delance . Évalué à 9.
Faut il vraiment sacrifier l'esprit de liberte (en autorisant l'utilisation de binaires) maintenant qu'il commence a prendre de l'importance pour gagner plus vite des parts de marche ?
Pour ma part c'est non. Les binaires proprio c'est MAL (tm) et moins il y en aura mieux on se portera (ne serait ce que pour la facilite d'install, il me semble que les binaires de nVidia par exemple n'ont pas toujours ete un modele de facilite a installer d'apres ce que j'ai lu dans les forums, on ne peut pas demander aux distribs de gerer tous les cas particuliers des binaires fournis par les constructeurs, sans parler des droits de redistribution).
Et non je n'ai pas peur de passer pour un extremiste.
[^] # Re: pas cool :/
Posté par pasBill pasGates . Évalué à -1.
Ah bon ?
Tu crois que Linux serait utilise par bcp de gens sans le support webcam, drivers Nvidia, drivers ATI,... ?
Moi j'ai comme un doute, ils ont grandement facilite l'arrivee de Linux sur les desktops.
[^] # Re: pas cool :/
Posté par Quentin Delance . Évalué à 4.
Effectivement on se coupe de pas mal d'utilisateurs potentiels mais quand j'ai commence sous Linux c'est ma carte graphique qui ne marchait pas de base. Et ca ne m'a pas empeche de passer a Linux.
[^] # Re: pas cool :/
Posté par pasBill pasGates . Évalué à 5.
Maintenant, le truc est que 90% des gens le demandent, donc eux ils passeront pas sous Linux.
Ensuite, tu vas expliquer aux 10% restant qu'ils ne seront jamais plus que 10% et que si dans 1 an ils veulent une webcam ou une carte 3D, ils devront repasser sous Windows.
Tu vas vite arriver a une part de marche similaire a celle du Hurd comme ca.
[^] # Re: pas cool :/
Posté par Emmanuel Seyman . Évalué à -1.
Est ce que tu peux m'expliquer d'ou tu sors ce chiffre de 90% ?
[^] # Re: pas cool :/
Posté par pasBill pasGates . Évalué à 4.
- jouent (donc 3D)
- font de l'IM avec webcam
[^] # Re: pas cool :/
Posté par Christophe BAEGERT . Évalué à -4.
[^] # Re: pas cool :/
Posté par Emmanuel Seyman . Évalué à 1.
Les gamers ne changeront pas d'OS.
> - font de l'IM avec webcam
Population minoritaire, AMHA. Sans compter que si un pilote libre arrive pour remplacer le proprio, ils n'auront rien perdu.
[^] # Re: pas cool :/
Posté par Guillaume Knispel . Évalué à 6.
Maintenant si les constructeurs donnent les moyens de se servir de leur matériel, ou ecrivent des pilotes libres, ou des pilotes proprio _en respectant les conditions_, alors les gens pourront jouer et faire de l'im.
La clef c'est le respect des conditions... Tu dirais quoi si je telechargeais les sources de win2k sur edonkey et que je codais un OS qui serait un mix entre un BSD et win ? Je crois pas que ca serait toléré. Je vois pas pourquoi un autre truc qui ne respecte pas les conditions serait plus toléré que ca, juste pour avoir plus d'utilisateurs.
[^] # Re: pas cool :/
Posté par 007 . Évalué à 5.
Tout à fait. Le but d'un OS libre, est d'être libre. Si en plus il domine toute la planette alors tant mieux. Mais la priorité N°1 est d'être libre.
Puis un OS Libre qui devient non libre pour dominer la planette à la place des OS non libre, quel intérêt ?
[^] # Re: pas cool :/
Posté par DiZ . Évalué à 3.
>- jouent (donc 3D)
>- font de l'IM avec webcam
En entreprise c'est pas loin de 0%.
Si un jour les parts de marché de Linux sont autour de 10/15% sur les postes clients d'entreprise et que ces mêmes entreprises demandent des drivers libres, pour avoir, par example, le support RedHat (qui ne supporte pas les noyaux "tainted" ), on verra à ce moment la ce que feront les constructeurs :)
Linux est arrivé jusque la sans les logiciels propiétaires et sans les utilisateurs demandeurs de logiciel propriétaires....
[^] # Re: pas cool :/
Posté par Jerome Alet (site web personnel) . Évalué à 2.
Sachant où tu travailles, on ne peut pas dire que cela soit vraiment significatif... Les gens qui sont autour de toi utilisent effectivment et vraisemblablement le système équipant autour de 90% des PC, cela n'en fait pas une loi universelle pour autant.
[^] # Re: pas cool :/
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
Ceux qui sont pénalisés aujourd'hui, c'est nous même. Et je ne retournerai pas sous win parce que ma web cam n'est pas supportée.
Par contre si cela permet de faire avancer les choses et d'avoir un VRAI support natif et libre comme on aime l'avoir avec Linux, alors peux être un jours les simple utilisateurs windows pourront utiliser Linux.
[^] # Re: pas cool :/
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
# emerge usb-pwcx
C'est drôle comme les distributions dites 'avancées' simplifient les choses!
[^] # Re: pas cool :/
Posté par un_brice (site web personnel) . Évalué à 2.
[^] # Re: pas cool :/
Posté par Temsa (site web personnel) . Évalué à 2.
J'ai essayer de leur faire mettre un noyau vanilla mais il y avait plein de truc qui ne fonctionnait plus (genre les supermount, etc...). Ca c'est terminé en install de gentoo pour tout le monde!
[^] # Re: pas cool :/
Posté par djibb (site web personnel) . Évalué à 2.
[^] # Re: pas cool :/
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
En parlant de distribution 'avancée' c'est exactement le contraire que j'ai écris...
> si tu en doute on peut faire l'expèrience (et je te fait grâce des temps de compilation).
C'est gentil de me faire grace des temps de compilation d'un driver binaire... ;-)
[^] # Re: pas cool :/
Posté par 007 . Évalué à 2.
Tu rèves. Linux a débuter sans 3d, sans, sans...
Il ne va pas s'écroulé car il y a un driver en moins.
[^] # Re: pas cool :/
Posté par Guillaume Knispel . Évalué à 6.
Nous on veut expliquer aux fabriquants de webcam que c'est pas parce qu'ils expliquent comment on peut s'en servir qu'ils vont couler le lendemain. De toute manière pour moi un matériel sans spec, c'est un matériel inutile, qui me servira tout autant dans une poubelle que sur mon PC. Ya bien que MS pour vouloir nous faire croire que le matériel est de manière inhérente lié au logiciel, et au logiciel proprio édité uniquement par le constructeur en plus, ce qui nous soumet à sa merci, et le pire c'est que les constructeurs de matos se mettent à y croire aussi toujours plus souvent (ce qui est un peu logique dans une optique de controle de leur vente... on veut faire acheter du nouveau matos ? suffit d'arreter le support de l'ancien sur les nouveaux systèmes...)
Si linux ce met à etre rempli de truc proprio non controllés, et que les auteurs décident un jours d'arreter, alors une nouvelle version de nux pourrait être bien pire que tout ce qui peut se passer si l'on suit une politique strict et cohérente en matière d'acceptation conditionnelle dérogatoire de pilote proprio. Parce que quand quelqu'un a un droit sous condition, ben ca n'implique tout simplement pas qu'il à le même droit sans condition (en l'occurence de faire du proprio sans ce soucier des api qui sont autorisées ou non, ce qui est la politique du noyeau)
[^] # Re: pas cool :/
Posté par 007 . Évalué à 1.
C'est comme une voiture sans mode d'emploi. Tu serais obligé d'utiliser un driver (chauffeur) proprio pour utiliser ta voiture même si tu as envie de la conduire ou que tu ne veux plus du driver (chauffeur) car il conduit trop dangereusement à ton goût ou qu'il grille systématique les feux rouges et tu aimerais bien corriger ce "défaut".
[^] # Re: pas cool :/
Posté par Sayena Yefka . Évalué à -1.
C'est comme si pour conduire tu exigeais d'obtenir toutes les specs de la voiture, les plans de montage, de conception detaillee du moteur...
[^] # Re: pas cool :/
Posté par 007 . Évalué à 8.
- "comment utiliser le volant, la boite de vitesse, les clignotants, etc"
Linux ne veux pas savoir si le moteur est en acier ou titane, ou si les suspensions sont types multi-bras ou pont rigide.
Le but est de savoir conduire la voiture (le droit de l'utilisateur à utiliser :-)), pas de refaire la même voiture à l'identique ou de faire de l'espionnage technologique.
[^] # Re: pas cool :/
Posté par Nap . Évalué à 3.
sinon, je pense qu'ici des gens confondent logiciel libre et matos libre. Si on interdit les firmwares binaires et qu'on veut rester cohérent, il faut interdire tout matériel ne fournissant pas l'intégralité de ses specs, que ce soit un modem, une webcam, le processeur ou le chipset... En effet le firmware est souvent fait pour tourner sur le matériel lui-même, pas sur l'ordinateur. Donc si on que même ce qu'il y a sur le matos soit libre, il faut aller jusqu'au bout de ses idées.
[^] # FCPU ?
Posté par Gart Algar . Évalué à 3.
[^] # Re: FCPU ?
Posté par Nap . Évalué à 2.
bon courage à eux, surtout qu'après il leur faudra sortir des chipsets de CM , des chipset graphiques, des modems, des... webcams :)
en tout cas c'est bien beau comme projet
[^] # Re: pas cool :/
Posté par nicolassanchez . Évalué à 2.
De plus je ne comprends pas le risque qu'il y a à donner les sources d'un driver... ça ne sert à rien de les cacher puisqu'ils sont spécifiques à une carte... à moins que ces sources ne permettent de voire le fonctionnement interne de la carte...
[^] # Re: pas cool :/
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
[^] # Re: pas cool :/
Posté par Toufou (site web personnel) . Évalué à 0.
Mouarf :) Dans les revues de key people peut-être mais pas dans ma boite (recherche scient.). Ce qui fait que quelques personnes ici utilisent linux c'est la souplesse et la polyvalence des outils l'accompagnant, ainsi que pour les environnements complets de developpement / travail fournis en standard : le rapport qualité prix quoi :)
Cette qualité vient de sa liberté et de la souplesse d'un système non bridé (debug / extension d'appli, accès total à toutes les fonctionnalités), non pas du support de quelques fonctionnalités essentiellement utilisées par les gamers et les netjunkies.
Ce qui fait que peu de gens de ma boite utilisent GNU/Linux en poste de travial, c'est uniquement la résistance au changement pour beaucoup (y a word et internet sur linux ?), et parfois, l'utilisation d'applis MS-Windows uniquement : certainement pas les lacunes en drivers.
[^] # Re: pas cool :/
Posté par Emmanuel Seyman . Évalué à 2.
???
J'ai une ATI Radeon 7200 et je trouve les perfs tout a fait acceptable sous Fedora Core 2 (comprendre: j'arrive a jouer a Tuxracer sans ralentissements).
Je suis une exception ?
> Y'a le sens pratique aussi des fois qui est en jeu
Le fait de retirer un pilote qui fonctionne mal dans le noyau Linux a souvent pour éffet qu'un nouveau pilote plus performant apparait peu de temps après. Ca s'est vérifié avec plusieurs pilotes SCSI et cartes son.
[^] # Re: pas cool :/
Posté par Flink . Évalué à 3.
Pis ensuite tu testes avec des jeux (quake3, ennemy teritory, ut2004, etc) et pas tuxracer, y'aura certainement une différence ;)
Ensuite pour ce qui est d'avoir un driver qui par la suite sera mieux, ça serait bien mais dans l'état actuel des choses ça a pas l'air sûr (devoir reverse ingeenerer les algos de philips & co, etc, ca va prendre un certain temps tout ça, et pendant ce temps les gens qui ont une webcam philips ben ils pourront booter un windows pour l'utiliser en gros)
[^] # Re: pas cool :/
Posté par djano . Évalué à 2.
Il peut aussi utiliser un vieux noyau:
- (I) demand that the PWC driver is removed from any further Linux kernel releases; Open source or not, it's still _my_ work.
Il demande juste que le driover PWC soit retirer des prochaines release du noyau. Pas de celles sur lesquelles il a travaille.
[^] # Re: pas cool :/
Posté par Guillaume Knispel . Évalué à 2.
Donc les mainteneur peuvent (et vont surrement) ne pas accepter.
Y a rien qui les obligent à accepter. Sont truc est libre, n'importe qui peut le REdistribuer, meme si il choisit d'arreter de le distribuer.
[^] # Re: pas cool :/
Posté par djano . Évalué à 2.
Rien n'empeche quelqu'un de mettre son nez dedans le source GPL et de le redistribuer / modifier / etudier / faire marcher.
[^] # Re: pas cool :/
Posté par dguihal . Évalué à 2.
Je ne sais pas ou tu as pu trouver ce genre de pilote, mais la radeon 9600 n'a pas de pilotes 3D libres
cf :
http://dri.sourceforge.net/cgi-bin/moin.cgi/ATI?action=highlight&am(...)
categorie [Specifications]
Donc ton pote fonctionnant en version OpenGL logicielle (Mesa), c'est normal qui n'y avait pas photo
[^] # Re: pas cool :/
Posté par djano . Évalué à 2.
Je suis une exception ?
Je dirais meme plus!
ATI Rage Fury sur un PII 350 + mandrake 10 permet de faire tourner Tuxracer sans presque aucun raletissement (je me rapelles meme plus s'il y en a).
Le fait de retirer un pilote qui fonctionne mal dans le noyau Linux a souvent pour éffet qu'un nouveau pilote plus performant apparait peu de temps après. Ca s'est vérifié avec plusieurs pilotes SCSI et cartes son.
Que dieu t'entende! Que dieu t'entende! (je precise, je n'ai aucun lien avec celui-la)
[^] # Re: pas cool :/
Posté par SF . Évalué à 1.
C'est une blague ;-)
Non? il ne blague pas .......
[^] # Re: pas cool :/
Posté par Cédric Blancher . Évalué à 1.
J'en ai une, et elle marche _très_ bien sans utiliser la partie binaire du driver. Je me demande d'ailleurs pourquoi tu n'essayes pas plutôt que de faire confiance au "à droite à gauche"...
oui du coup la detection auto et le montage des bons pilotes tu peux la rever
Gni ? "Chaimoissamarche"
Bon maintenant, que des gens veuillent avoir un kernel 100% libre, je le comprends et je suis pour aussi. Mais d'un autre côté, il y a du matos pour lequel on n'a pas d'autre solution que de faire appel à des firmwares ou des modules propriétaires. Refuser la possibilité aux gens d'utiliser ce matos me semble une très mauvaise idée, qui ira plus dans le sens de faire cracher sur la GPL par les gens qui la connaisse mal qu'autre chose.
Et quand on parle de violation de la GPL, au lieu de se bourrer le mou avec des détails de ce genre en se braquant comme des gosses de 6 ans façon "c'est pas moi c'est lui" au lieu de discuter ouvertement et dans le calme, on ferait peut-être mieux de s'intéresser à des cas comme les gens de chez Sveasoft qui distribue du logiciel GPL via des comptes payants mais te ferme ton compte si tu redistribues leur soft ensuite...
Perso, ça me choque nettement plus, mais bon.
[^] # Re: pas cool :/
Posté par Quentin Delance . Évalué à 0.
Ben chez moi la debian me charge pwc par defaut (mais evidemment je n'ai pas pwcx...). Par contre l'acces au periph /dev/video0 deconne toujours et en faisant des recherches, je suis arrive sur le forum gnome meeting ou j'ai cru comprendre que pwc necessitait pwcx depuis les dernieres versions (pas eu le temps de creuser pour savoir si ca tient au linux 2.6 ou au pwc 9). Du coup je ne me suis pas compiler mon PWC 9. Ceci dit cette solution est quand meme penible car chaque MAJ de noyau t'oblige a refaire une compil des modules (puisque le dernier PWC n'est pas integre au noyau).
Mais ca ne m'empeche pas d'etre choque egalement par les entreprises qui violent la GPL.
[^] # Re: pas cool :/
Posté par glandvador . Évalué à 5.
J'ai un modem ADSL pci. Une partie du module est binaire. Depuis le passage au kernel 2.6 il ne marche plus. Pour le moment, j'ai encore du support, mais aprés ?! Si le kernel ou gcc changent un tout petit peu je l'ai bien qque part.
Quand je l'ai acheté, j'ai juste vu qu'il était supporté sous linux. J'ai téléchargé le driver et j'ai vu des sources et je me suis dit cool ca marche. Alors, si les constructeurs ne donnent pas le driver alors trés bien, mais qu'ils ne disent pas que ca marche sous linux.
En ce qui concerne le firmware, si c'est du code qui tourne sur la carte il peut être propio. C'est juste une facilité d'utilisation, car ils auraient pu mettre une flash avec le code. Mais si c'est du code qui tourne sur le PC, il doit être libre.
Je prefere encore, pas de hardware du tout qu'un truc qui ne marchera que 2 années.
[^] # Re: pas cool :/
Posté par Emmanuel Seyman . Évalué à 2.
Il faut aussi penser aux architectures autres que x86. J'ai utilisé une alpha pendant très longtemps comme poste de travail et je me suis rendu compte que les binaires sont impossible a trouver. Pour les logiciels libres, on peut recompiler sans trop de problèmes mais c'est impossible a faire avec les trucs proprio.
[^] # Re: pas cool :/
Posté par gabuzo . Évalué à 4.
Tout bien réfléchi je ne pense pas que la décision soit uniquement motivée par des motifs idéologiques: si tout ce qui est dans le noyau, ou plus exactement distribué avec le noyau standard, doit être en GPL c'est aussi parce que l'utilisateur qui utilise Linux ait la garantie que toutes les fonctionnalités proposée par le noyau sont libres et ne nécessitent pas le chargement d'un module propriétaire. Pour NVidia il n'y a aucun problème car Linux (le noyau) ne propose pas le support pour ces cartes. Quelqu'un désirant utiliser une telle carte sait qu'il doit passer par un driver externe.
Pour PWC la situation est différente car en regardant le drivers fournis par le noyau on pense légitimement que les webcams Philips sont supportées en standard. Et c'est là que le problème arrive car pour utiliser toutes les possibilités de la caméra il faut un module propriétaire. Or lorsque je lis le fil du lkml j'ai vraiment l'impression que dans la pratique il ne faut pas espérer utiliser la caméra sans le décompresseur propriétaire. À mon avis cela pose effectivement un vrai problème car la présence de pwc dans le noyau peut faire croire à un utilisateur que le driver est libre alors que ce n'est pas le cas. Un mode de distribution à la NVidia serait donc moins trompeur pour les utilisateurs potentiels.
Autre point intéressant soulevé sur LKML: le NDA liant le Philips avec l'auteur du driver a expiré depuis un an. Certes je suis d'accord qu'il ne serait pas correct de diffuser les infos sans en référer à Philips mais je n'ai pas vraiment l'impression qu'il ait essayé de le faire.
[^] # Re: pas cool :/
Posté par Flink . Évalué à 0.
et ce passage du post sur la lkml est plus que réaliste, je vous laisse réfléchir là dessus :
To come back to Linus´s comment "if a change is needed [...] in order to get
a closed source module to work, that module must be made opensource". Well,
that ain't gonna work. There is no way that manufacturers are suddenly
going to wave their hands in the air and start panicking "Oh dear, we're
going to loose Linux support! What must we do?! Should we open source?
Argh!" It is not going to happen. Period. Get down to earth, now.
[^] # Re: pas cool :/
Posté par Maxx . Évalué à 4.
Tiens, et pourquoi ne pas lancer une pétition pour que Philips fournisse un driver/module (2) de qualité pour Linux ? ;)
(1) Les deux commentaires de suite:
http://linuxfr.org/2004/08/23/17087.html#463121(...)
(2): euh là par contre y'a un truc que je comprends pas... la différence entre module et driver ??? (ouais je sais, sale newbie :D)
[^] # Re: pas cool :/
Posté par Philippe F (site web personnel) . Évalué à 5.
Il faut pas rever, avec une politique comme ca, linux ne sera jamais supporte sur tous les materiels.
[1]: linus pete l'architecture du noyau et des drivers tous les un ou deux ans, mais c'est juste pour l'ameliorer, c'est pas pour faire chier tous les utilisateurs et les mainteneurs qui n'ont que ca a faire.
[^] # Re: pas cool :/
Posté par bastien (site web personnel) . Évalué à 4.
[^] # Re: pas cool :/
Posté par Jerome Herman . Évalué à 7.
Disons que c'est a la fois complètement vrai et totalement faux. Pour developper un module linux il suffit 9 fois sur 10 de reprendre 3 bouts de codes a d'autres modules et de changer les déclarations ainsi que l'enregistrement.
Le plus dur est souvent de savoir quel appel système sert a quoi et ensuite derrière c'est du velour.
Par contre Linux n'est pas stable au niveau des interfaces. Tant au niveau du noyeau (en ce moment par exemple c'est la fête a l'IDE) que de l'environement de compilation ou encore que des bibliothèques. Bref parti pour écrire un module on se retrouve souvent a en ecrire 10, subtilement différents ou a faire des automakes de 100 pieds de long pour que les APIs linux fonctionnent (OSS -> Alsa, XFree86 -> X.org, lpr-> gimp print, Defvfs -> Udev etc.)
Généralement quand on met une équipe réduite sur un driver Linux un peu baleze (Une carte d'aquisition temps réel, pour prendre un exemple que je connais) on a pas le temps de finir les specs qu'on peut déjà les mettre a la poubelle. En bref sous Linux on a le droit a grand maximum 8 mois pour faire l'ensemble pilote/interfaces/outils. Et après on est bon pour le maintenir 24h/24 au gré des variations subtiles de la gestion des registres et des appels mémoires.
Voilà pour la problématique.
Kha
[^] # Re: pas cool :/
Posté par Raphael Berlamont (site web personnel) . Évalué à 1.
[^] # Re: pas cool :/
Posté par Philippe F (site web personnel) . Évalué à 4.
Non!
En fait, si, ca arrive parfois. Mais c'est aleatoire, il faut pas croire que si tu mets un logiciel open source, une horde de programmeur va se jeter dessus pour y contribuer. Il faut un ensemble de conditions complexes pour arriver a recuperer des contributeurs.
[^] # Re: pas cool :/
Posté par Jean Parpaillon (site web personnel) . Évalué à -4.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: pas cool :/
Posté par 007 . Évalué à 3.
20 fois moins de développeurs et 3 à 4 fois plus de boulot, ils sont forts les développeurs Linux (à vu de pif, 1 dev Linux = 60 à 80 dev Windows).
[^] # Re: pas cool :/
Posté par JoeltheLion (site web personnel) . Évalué à 5.
Au contraire, maintenant que de plus en plus de gens passent à linux, il faut en profiter pour faire pression sur les constructeurs pour qu'ils proposent des drivers open source.
[^] # Re: pas cool :/
Posté par Paul Chavent (site web personnel) . Évalué à 2.
A moins que cela n'existe déjà ?!
Merci.
[^] # Re: pas cool :/
Posté par Nyx . Évalué à 2.
Bien sur il faut trier les webcams qui utilisent pwc, ce n'est pas encore mis à jour.
[^] # Re: pas cool :/
Posté par Toufou (site web personnel) . Évalué à 5.
Utiliser un soft ou matériel proprio c'est être bloqué à plus ou moins court terme : tu es à la merci du fournisseur. Ce qui se passe là en est une preuve supplémentaire : toto fait un driver proprio, il a un problème avec les kernel developpeurs (qui a tort ou raison ? ce n'est pas le problème ici) et il fait un caca nerveux qui amène à une regression.
La totalité du module aurait été libre, toto n'aurait pas emmerbeté tout le monde, il aurait juste eu réglement de compte chez les devs et le module complet serait resté : la technique aurait survécu à des querelles intestines.
Les développeurs noyau ont donc raison de vouloir tendre à l'élimination des parties plus ou moins proprio du noyau et d'empècher qu'elles ne se regreffent dessus par des moyens plus ou moins directs (la webcam c'est moins vital que la carte vidéo, il peuvent prendre une décision ferme).
Plus tard on les élimine, plus on aura de problème à les éliminer.
Le proprio ce n'est pas le Mal parce que c'est immoral (ça c'est subjectif), c'est le mal parce que c'est les emm*rdes assurés (ça c'est objectif): dégageons le de nos machines et de linux, il y a assez de problèmes techniques et humains comme ça :)
[^] # Re: pas cool :/
Posté par Éric (site web personnel) . Évalué à 3.
Je ne doute pas que le problème soit réel, je ne juge pas le coté moral, mais dire que c'est parce qu'on est dépendant du fournisseur me fait doucement rigoler. Au lieu d'avoir peut être des emmerdes légères plus tard (maj) on vient d'avoir dès maintenant des emmerdes importantes. A choisir .....
[^] # Re: pas cool :/
Posté par gabuzo . Évalué à 1.
Je ne pense pas qu'être dépendant du fournisseur est la raison. Je pense qu'il s'agit plus pour les dév kernel d'être honnêtes vis à vis des utilisateurs potentiels. Le noyau Linux est marketté comme étant en GPL. Donc mettre un bout driver en GPL qui ne fonctionne qu'après chargement d'un module propriétaire est plus ou moins une tromperie. Bien sûr dans le cas de PWC un peu de discussion n'aurait pas fait de mal. Ceci-dit je pense que plus les fabricants de matériel s'intéresseronts à Nunux plus il deviendra courant d'avoir des drivers propriétaires ce qui risque de changer les habitudes des utilisateurs de Nunux.
[^] # Re: pas cool :/
Posté par Éric (site web personnel) . Évalué à 3.
> module propriétaire est plus ou moins une tromperie.
Tiens, c'est peut être l'explication la plus simple que j'ai vu jusqu'à maintenant, et probablement la meilleure.
[^] # Re: pas cool :/
Posté par Toufou (site web personnel) . Évalué à 0.
D'expérience, c'est du peut-être à 99% d'être sur d'être embété : tôt au tard, le gars va abandonner (pas envie, mort de la boite, non rentabilité du truc...) et tu n'auras aucun moyen de reprendre (combien de projets abandonnés deviennent libres ? 1% ?).
les dev kernels viennent de faire cesser (*c'est sûr*) dès *maintenant* la possibilité *d'utilisation* du matos.
Plus tu attends, plus tu as de monde qui utilise la fonctionnalité dans de plus en plus de cas d'utilsation et plus tu auras de problèmes et de travail pour faire la migration quand tu le devras (à mettre en paralelle avec le moment ou le fournisseur va dire : ah beh non, j'arrete). Quitte à avoir le problème, autant l'avoir au plus tôt pour le résoudre au plus tôt.
[^] # Re: pas cool :/
Posté par spell (site web personnel) . Évalué à 5.
J'en ai marre que l'on traite les défenseurs du libre d'intégriste. Pour moi les intégristes, c'est les constructeurs qui obligent à installer leur pilote pour avoir accès à leur matériel; Les intégristes c'est ceux qui refusent de donner les specs pour pouvoir écrire un driver.
# Autre solution: hors kernel ?
Posté par Yves Martin . Évalué à 10.
Le problème vient du fait que l'interaction entre le module GPL pwc nécessite un système de callback pour travailler avec pwcx (code protégé par un NDA) ! Et c'est cela qui dérange les développeurs (je l'ai comprends un peu, c'est pas sécurisé, c'est pas beau...)
Mais par analogie, les drivers de scanner de Sane ne sont pas dans le kernel. Sane communique au niveau utilisateur (simple processus) avec le périphérique USB par l'intermédiaire de libusb.
D'où ma naïve question: pourquoi ne pas modifier le code "module" en une bibliothèque de communication par libusb ? Ce code serait simplement remonté au niveau applicatif (plus dans le kernel) comme pour Sane.
[^] # Re: Autre solution: hors kernel ?
Posté par Flink . Évalué à 3.
En effet on peut se demander pourquoi ça serait pas possible de faire un truc userspace, et dans ce cas cela remet en cause la façon de voir du dev de pwc non?
[^] # Re: Autre solution: hors kernel ?
Posté par fouinto . Évalué à 1.
Je pense que pour que le developpeur change sa façon de faire, il aurait surement fallu s'y prendre autrement... peut-être lui envoyer un mail pour lui expliquer? (peut-être que cela a été fait d'ailleur...) mais j'ai l'impression qu'il a été autant vexé par la forme que par le fond...
Si c'est possible, j'espere que le developpeur du module reviendra sur sa decision et utilisera une solution alternative.
[^] # Re: Autre solution: hors kernel ?
Posté par pasBill pasGates . Évalué à -3.
Il n'y peut rien, les devs du kernel ont simplement change d'avis du jour au lendemain et lui ont retire la permission de linker avec du non-GPL alors qu'ils le lui avaient permis pendant 3 ans sans qu'il ne fasse rien de mal/inapproprie.
[^] # Le NDA a expiré !!
Posté par boubou (site web personnel) . Évalué à 4.
Le NDA a expiré depuis un an ! Donc il a parfaitement le droit de divulger les sources, mais il fait sa tête de cochon et franchement, je ne comprends pas pourquoi !
[^] # Re: Le NDA a expiré !!
Posté par Dafatfab . Évalué à 1.
Je pense que la pétition générale est une bonne solution pour attirer philips sur ce probleme.
[^] # Re: Le NDA a expiré !!
Posté par boubou (site web personnel) . Évalué à 5.
Il a indiqué lui-même qu'il pensait avoir le droit mais que ses relations de confiance avec Philipps pourrait en pâtir, bla bli bla bla. Je signe régulièrement des NDA et je t'assure que quand ils ont expiré, je ne les respecte plus ! La durée du NDA est d'ailleurs toujours un point de négociation bien chiant.
[^] # Re: Le NDA a expiré !!
Posté par djano . Évalué à 1.
Il pourrait divulguer s'il le voulait, mais si des brevets viennent mettre le boxon la dedans, on s'en sort pas (cf SCO pour les droits de propriete).
[^] # Re: Le NDA a expiré !!
Posté par Maxx . Évalué à 2.
maudits brevets...
pour une webcam en plus (mais qu'est-ce qu'on peut bien breveter dans l'algorithme de gestion d'une webcam...?)
[^] # Re: Le NDA a expiré !!
Posté par Gruik Man . Évalué à 2.
[^] # Re: Le NDA a expiré !!
Posté par Philippe F (site web personnel) . Évalué à 3.
[^] # Re: Le NDA a expiré !!
Posté par fredix . Évalué à 1.
Lien, source ? Je ne vois pas le développeur d'un driver Linux continuer à faire du proprio juste pour le plaisir.
[^] # Re: Le NDA a expiré !!
Posté par Emmanuel Seyman . Évalué à 1.
C'est dans le mail de Nemosoft sur LKML:
"Actually, I've got a little surprise for you. The NDA I signed with Philips
has already expired a year ago."
[^] # Re: Le NDA a expiré !!
Posté par fredix . Évalué à 3.
"Yet, I didn't just throw the decompressor
code on the Internet. First, there could still be legal remedies since the
cams are still in production to this very day. Second, that NDA was signed on a basis of trust and I do not want to lose that trust."
Ses arguments se discutent, mais bon il devrait négocier directement avec Philips...
Sinon j'apprécie vraiment pas son espèce de chantage, soit les mainteneurs du kernel acceptent son module qui appelle le binaire, soit il retire toute trace de son driver sur le Net. Ca en dit l'on sur sa mentalité, d'ailleurs il n'a apparement pas compris la GPL :
"In case the answer is "No", then I will:
- demand that the PWC driver is removed from any further Linux kernel
releases; Open source or not, it's still _my_ work."
[^] # Re: Le NDA a expiré !!
Posté par Éric (site web personnel) . Évalué à 2.
On peut dire la même chose des dev : soit il passe tout en GPL, soit il passe tout en user space, soit on empeche l'utilisation du module purement et simplement. Il y a le même genre de réaction des deux cotés.
[^] # Re: Le NDA a expiré !!
Posté par gabuzo . Évalué à 1.
[^] # Re: Autre solution: hors kernel ?
Posté par Philippe F (site web personnel) . Évalué à 2.
[^] # Re: Autre solution: hors kernel ?
Posté par Romuald Delavergne . Évalué à 2.
[^] # Re: Autre solution: hors kernel ?
Posté par Cédric Blancher . Évalué à 1.
Perso, j'ai l'impression qu'il s'agit clairement d'une guerre d'ego, et personne ne semble avoir envie d'y mettre du sien, d'un côté comme de l'autre, l'un préférant se la jouer "de toute manière c'est moi qui décide" et l'autre le Caliméro...
[^] # Re: Autre solution: hors kernel ?
Posté par 007 . Évalué à 4.
Pas seulement (de ce que j'ai compris).
Le drivers rend une fonction proprio public au noyau. C'est-à-dire que les autres parties du noyau peuvent appeler directement cette fonction (classique).
Mais il y a un patch qui appel une fonction proprio depuis le "coeur" GPL de Linux.
C'est comme si dans Linux il y avait :
read() {
if (!decrypt_data()) {
printf("permission denied") ;
}
}
Et que decrypt_data() était une fonction proprio.
[^] # Re: Autre solution: hors kernel ?
Posté par Alex . Évalué à 0.
Si on fait ça avec le module pwc, il faudrait faire un vrai API en userland pour l'accès a celui-ci.
Le fait d'avoir pwc en kernelland permet de la faire supporter par V4L (a ma connaissance il n'est pas possible de mettre un drivers pour V4L en userland), donc une même API pour accéder a toutes les périph gérant de la vidéo (webcam, carte TV...). Le fait de ne plus utiliser V4L casserait encore plus de chose (a peu près toutes les applis utilisant un périph vidéo)
[^] # Re: Autre solution: hors kernel ?
Posté par Yves Martin . Évalué à 1.
D'un autre côté V4L est une API kernel - je suppose que c'est aussi une API dans une librairie. Il serait toujours possible de faire un nouvelle librairie qui respecte cette même API mais en passant par libusb pour la communication avec la webcam. Certes, cela complique l'applicatif...
# alternatives ?
Posté par Xmanu . Évalué à 2.
[^] # Re: alternatives ?
Posté par ChickenKiller . Évalué à 0.
[^] # Re: alternatives ?
Posté par FlashCode (site web personnel, Mastodon) . Évalué à 1.
WeeChat, the extensible chat client
[^] # Re: alternatives ?
Posté par Xmanu . Évalué à 0.
[^] # Re: alternatives ?
Posté par Jerome Herman . Évalué à 2.
Kha
[^] # Re: alternatives ?
Posté par Arnaud . Évalué à 2.
http://members.brabant.chello.nl/~j.vreeken/se401/(...)
[^] # Re: alternatives ?
Posté par Serge Rossi (site web personnel) . Évalué à 10.
Ca permet dans tous les cas d'avoir du 640x480 en 25 images/s avec une qualité bien au delà de tout ce que peuvent faire les Webcam.
[^] # Re: alternatives ?
Posté par bhybct . Évalué à 1.
Malheureusement ça ne me convient pas parceque j'ai un portable.
[^] # Re: alternatives ?
Posté par Christophe Chailloleau-Leclerc . Évalué à 1.
[^] # Re: alternatives ?
Posté par Éric (site web personnel) . Évalué à 3.
# Solution ?
Posté par aille . Évalué à 6.
quel est l"intérêt pour eux ? Bloquer un concurrent ? Ne pas se froisser avec Microsoft en supportant ouvertement Linux ? Quand on achète du matériel on veut pouvoir s'en servir, et comme ils font du fric sur le chipset et pas sur le driver qui va avec, ils seraient temps qu'ils comprennent que c'est DANS LEUR INTERET d'avoir un maximum d'OS supportés. Au lieu de ca, ils jouent au chat et à la souris en autorisant un dév à écrire un module mais en le contraignant avec un NDA. Vraiment n'importe quoi.
Burn, Philips, Burn !
[^] # Re: Solution ?
Posté par Quentin Delance . Évalué à 3.
Ils font des webcams basees sur les chips Philips
Et niveau qualite on touche le fond.
J'ai achete ma webcam apres avoir regarde le site de PWC avec attention et a l'epoque ma webcam marchait sans pb. En realite derriere une meme ref il y avait un nouveau chip (non supporte a l'epoque par PWC).
C'est a ce genre de details (c'est frequent j'ai deja eu un pb de ce type avec une carte reseau DLink) qu'on reconnait les grands constructeurs de matos et qu'on se dit que le support sous Linux n'est pas pres d'arriver...
[^] # Re: Solution ?
Posté par Serge Rossi (site web personnel) . Évalué à 2.
D'ailleurs, quels sont les exemples dans le passé ou une protestation/demande de la communeauté Linux à permis de faire lever un NDA ?
[^] # Re: Solution ?
Posté par CdeMills . Évalué à 1.
Un exemple de la vie réelle: une association de plongeurs était devenue locataire d'une ancienne carrière (belge) auprès de la société qui l'avait exploitée. C'était un très beau site de plongée. Un jour, le propriétaire (la société) a voulu mettre fin au contrat. Les réactions des plongeurs ont été tellement épidermiques que non seulement la société n'a jamais revu sa position, mais qu'en outre, au niveau des autorités locales, plus personne n'a voulu entendre parler d'une solution de reprise de la carrière qui aurait permis de continuer à l'exploiter comme site de plongée. A semer le vent ...
[^] # Re: Solution ?
Posté par Guillaume Knispel . Évalué à 2.
Faut arreter l'extasie un peu.
[^] # Re: Solution ?
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Solution ?
Posté par Vincent LE LIGEOUR . Évalué à 2.
Pour résumer un peu le pwc c'est bien le pwcx c'est mieux. En effet sans le pwcx on ne peut par exemple pas faire tourner deux webcams simultanément sur un même port USB ou alors en USB2 on ne peut pas monter deux webcams en 800x600.
Je suis également d'accord avec le mainteneur quand il dit qu'il ne veut pas perdre la confiance que Phillips a mis a l'intérieur de lui ;). C'est normal Phillips lui donne depuis pas mal de temps les specs des webcams et même avant les sorties il me semble (le contrôle des moteurs sur les caméras faisant du tracking.
Concernant cette histoire si ça se trouve c'est un gigantesque troll pour faire pression sur Phillips :) ce qui serait super.
Yoda - Le petit nain vert
# C'est un coup dur pour linux embarqué...
Posté par Jean-Baptiste Mayer . Évalué à 9.
Et là, on perd le support de la seule caméra à peu prés bien fonctionnelle sous linux...
D'ailleurs, si on regarde la lkml, le driver GPL 'pwc' a lui aussi été retiré du noyau.
Adieu linux sur nos robot! :((
Bilan: Bah... je suis parti pour un grand moment d'ingéniérie inverse.
[^] # Ingénerie reverse
Posté par Ph Husson (site web personnel) . Évalué à 1.
de faire de l'ingenerie inverse sur les drivers pwcx
Apres tout pwcx ne contient "que" un algorithme de compression (j'y connais rien donc en fait c'est ptet super compliqué)
Donc ca doit etre faisable non?
[^] # Re: Ingénerie reverse
Posté par Gniarf . Évalué à 2.
parce que l'auteur (et pas Phillips) a explicitement retiré ces (ses !) drivers de la circulation, ce n'est donc pas comme si tu trifouillais les drivers pour Windows fournis par Phillips ou par les vendeurs de la caméra.
[^] # Re: Ingénerie reverse
Posté par Jean-Baptiste Mayer . Évalué à 2.
[^] # Re: Ingénerie reverse
Posté par Gniarf . Évalué à 2.
[^] # Re: Ingénerie reverse
Posté par Ph Husson (site web personnel) . Évalué à -1.
Et on a donc le droit de faire de l'ingénerie inverse à des fins d'interpolaritées(Ah merde comme le driver existe deja ca va ptet pas aller)
Sinon chose faisable:
Modifier la partie GPL pour pouvoir voir ce que sort (ou rentre) le module pwcx
Ou (avec deux machines et le cable usb qui va bien ©) faire un pont et regarder ce qui passe
Bon dans tout les cas c pas simple :/
[^] # Re: Ingénerie reverse
Posté par mickabouille . Évalué à 2.
Tant qu'il marche. Et qu'il est distribué.
Et l'espérance de vie d'un pilote non maintenu, cest pas folichon...
[^] # Re: C'est un coup dur pour linux embarqué...
Posté par Dalton joe . Évalué à 1.
http://lin4astro.org/(...)
# Linux est-il assez déployé pour se permettre ca?
Posté par Zenitram (site web personnel) . Évalué à 2.
Chez pas mal d'utilisateurs, Linux est installé "pour voir", et il est facile de le faire retourner a Windows.
Voila, comme ca c'est fait : beaucoup d'utilisateurs de webcam Philips risquent de repasser a windows, a cause de mainteneur qui prennent un peu la grosse tête, sans penser aux répercussions que cela a sur les utilisateurs.
Philips ne mettra rien en open-source, car le marché perdu est trop ridicule pour que ca les touche.
Les mainteneurs auraient peut-etre du attendre un peu que Linux soit un poids pour le grand public avant de prendre ce genre de décision...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Flink . Évalué à -1.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par djano . Évalué à 3.
Les utilisateurs de linux les achetaient donc en priorite s'ils voulaient une webcam sur leur OS favori. Maintenant, ce ne sera plus le cas. Je crois qu'ils vont le ressentir sur la vente de ce produit.
Maintenant, reste a savoir s'ils vont le prendre en compte ou pas.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . Évalué à 2.
Le probleme c'est que les "acheteurs Linux" representent une part infime des ventes, donc je suis franchement pas sur qu'ils vont voir la difference.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par djano . Évalué à 3.
J'avance que les webcams philips etaient bien connues (les plus connues?) pour marcher sous linux et que donc si les linuxiens voulaient une webcam pour linux, ils les achetaient en priorite.
_Peut-etre_ qu'ils representent une part non negligeable.
Maintenant tu arrives avec tes gros sabots pour declarer sereinement avec force et sans la moindre preuve "qu'ils representent une part infime des ventes".
J'attends toujours des chiffres de ta part quand tu enonces tes verites universelles.
Pour une carte video, je suis a croire que les linuxiens sont tres tres tres largement minoritaire (les hardcore gamers sous linux sont rares et je ne pense pas que les graphistes representent le gros des ventes de CG). Mais la, je ne suis pas d'accord avec toi.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . Évalué à 4.
Les sondages disent que Linux a ~3% de parts de marche sur le desktop, tu soustrais a cela tous ceux qui n'ont pas de webcam, reste plus grand-chose. Je pourrais te retrouver les liens si tu veux mais faudra attendre demain, la c'est 3h du matin et j'ai sommeil.
Pour une carte video, je suis a croire que les linuxiens sont tres tres tres largement minoritaire
De mon point de vue c'est justement l'inverse, tout le monde a besoin d'une carte graphique, et quasiment toutes les cartes vendues sont 3D, alors qu'une webcam c'est pas essentiel pour utiliser un ordinateur.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Christophe Chailloleau-Leclerc . Évalué à -1.
[...] mais faudra attendre demain, la c'est 3h du matin et j'ai sommeil.
C'est moi qui ai fumé ou ???
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par ckyl . Évalué à 3.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Maxx . Évalué à 2.
GMT + 2 c'est Athènes... ;)
@Christophe Chailloleau-Le a.k.a. zekrap:
si tu t'étais un peu intéressé à ce môsieur pBpG tu saurais qui il est vraiment, et donc supposé où il vit... ;) surtout vu son pseudo.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Christophe Chailloleau-Leclerc . Évalué à 2.
Ceci étant dit, même en m'intéressant à monsieur, je ne suis pas sûr de trouver facilement toutes les infos sur sa vie son oeuvre... Mais vais faire un p'tit tour chez lui pour me renseigner !
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par x0ra . Évalué à 1.
Greenwich Mean Time
Thursday, 26 August 2004 16:42:45
Your Local Time
Thu Aug 26 18:42:45 2004
(http://wwp.greenwichmeantime.com/(...))
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
On doit maintenant parler UTC ou TAI: http://www.bipm.org/fr/practical_info/time_server.html(...)
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par x0ra . Évalué à 1.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
$ date --utc ; date
jeu aoû 26 23:39:34 UTC 2004
ven aoû 27 01:39:34 CEST 2004
En ce moment nous avançons de 2 heures.... C'est bien ça !
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par djano . Évalué à 1.
Personne a part les hardcore gamers et les graphistes. Les premiers sont quasi absent de linux et les seconds sont minoritaires.
Ceci dit, il est tout a fait vrai que tout un chacun a besoin d'une CG, mais pas forcement a son max => d'ou les drivers libres qui doivent suffire pour faire du desktop.
Ensuite, pour le pb de la webcam USB, je dis que les linuxiens achetent en priorite une webcam philips car elles sont (etaient) reputees pour fonctionner sous linux. Quand je dis en priorite, cela signifie qu'il doit y avoir un pourcentage non negligeable (je ne vais pas citer de pourcentages en l'air qui ne veulent rien dire).
Sous windows, je crois pas que les gens se ruent en priorite sur les webcams philips. Ils prennent la premiere webcam qui correspond a leur besoin pour le plus petit prix possible (si tant est qu'ils savent de quoi ils ont besoin et qu'ils ne prennent pas la moins chere tout cours. Donc la plus pourrie).
Les philips peuvent etre les moins cheres, mais c'est pas dit.
Maintenant, si on met en balance les deux populations, il se trouve que le rapport entre les utilisateurs windows et linux est bien different (pour ces webcams particulieres) de celui des autres webcams.
Dans quelle mesure cela est la question pour savoir si les attentes des linuxiens seront ecoutees ou pas.
Bref, j'ai clairement expose mon raisonnement.
Quelque chose me dis que cela ne te convainc pas.
C'est pourquoi je n'irais pas plus loin. J'aurais essaye au moins.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par GhZaaark3 . Évalué à 2.
Personne a part les hardcore gamers et les graphistes. Les premiers sont quasi absent de linux et les seconds sont minoritaires.
oké, donc Linux est un système pour Codeurs, administrateurs réseaux, Comptables...basta??!
Si je suis ta logique, je devrais dire à tous les graphistes de rester/aller sous MacOSx (ce que j'aurais fais si encore une fois pas d'NVIDIA)
+
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par djano . Évalué à 2.
Putain c'est impossible de developper un argumentaire ici sans se faire tailler en piece a la moindre phrase!! (je le sais je le fais aussi ;-) )
Bon bref, oui je veux des specs pour tous les matos!!!
Mais pour une bonne partie des gens, il me semble qu'un driver libre moins performant suffirait (j'avoue, j'aime pas les chichi graphiques du bureau qui servent qu'a ralentir la machine).
Je peux me tromper, je suis pas infaillible.
Maintenant, si il y a assez de graphistes et de hardcore gamers qui viennent sous linux, banco!! Je vais pas les jeter (reste la si j'ai bien compris ce qu'il y avait entre les lignes).
Ils permettront de faire pression sur les fabricants de CG en plus des autres (qui en ont moins besoin).
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Nimlar . Évalué à 3.
On aurait des drivers performant comme il faut, ca ralentirait même pas...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par GhZaaark3 . Évalué à 2.
mais ça me fiche les boules tous ces arguments :
"On a pas besoin de ci, donc on a pas besoin de ça"...
Je fais donc partie d'une minorité comme tu le dis, c'est d'autant plus difficile pour moi car j'adore les LL donc GNU/Linux mais pour faire ce que je fais j'ai besoin d'un support de mes "outils"
Je fais quoi, que faisons nous alors? utiliser du libre sur du proprio_crade? ou utiliser un peu de proprio sur du LIBRE?
Je fais peut-être partie des rares graphistes à qui la GPL veut dire autre chose que GRATOS et qui a passé 5ans à s'adapter et à comprendre les LL.
Vous comprendrez donc que je suis tiraillé des deux côtés, car à cause d'NVIDIArhée/ATIfus y a 2 côtés.
voilà, j'éspère que les prochains en tiendront compte.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par spart . Évalué à 1.
<consulte sa carte des fuseaux horaires>
voilà qui explique bien des choses :-]
je me demanderai toujours s'ils procèdent par _implantation_ ou par _trépanation_ ...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Emmanuel Seyman . Évalué à 3.
L'une des réponses a Nemosoft était celle de Rob van Nieuwkerk:
"I use 1000 Philips webcams in a product. We are evaluating camera's for
a 2nd generation product of which several thousands more may be built.
Having the source for the driver available would certainly improve
chances that I'll use the Philips cams again."
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par GhZaaark3 . Évalué à 1.
carte TV chipset BTxxx
caméra conventionnel, et voilà
+
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par cortex62 . Évalué à 3.
Pourquoi FAUDRAIT-IL que les mainteneurs compromettent leur travail ? L' utilisation de linux par le grand public est plus une conséquence de leur travail qu' un objectif.
Et on peut ce demander si cette situation n' est pas préférable pour le moment.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Jean Parpaillon (site web personnel) . Évalué à 5.
Linux est un système d'exploitation type UNIX libre et pour PC, ce qui veut dire :
- il existe des UNIX pour PC (Solaris, Minix, etc)
- il existe des systèmes d'exploitation pour PCs ;)
-> la seule raison d'être de Linux est d'être libre => si Linux n'est plus libre, aucun intérêt
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Christophe BAEGERT . Évalué à 0.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Emmanuel Seyman . Évalué à 1.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Toufou (site web personnel) . Évalué à 3.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Christophe BAEGERT . Évalué à -1.
> les developeurs du système d'exploitation.
Justement, NVidia les fournit, et Philips a passé un contrat avec un développeur lui permettant de les fournir. Là ce dont on parle c'est de refuser ces drivers fournis par le constructeur ou presque.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Emmanuel Seyman . Évalué à 2.
Les developeurs du noyau ont enlevé un mécanisme qui permettait au module pwc d'appeler des modules exterieurs.
Le seul module exterieur connu a ce jour est un module proprio.
La seule raison pour laquelle il est proprio est un NDA passé avec Philips qui a expiré il y'a un an.
De la à dire que les developeurs refusent "ces drivers fournis par le constructeur ou presque", il y'a un pas que je ne franchirais pas.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Quentin Delance . Évalué à 7.
Un mec comme RMS il a commence et il n'y avait rien, il a consacre sa vie au libre. Maintenant que Linux devient utilisable (le fait qu'une webcam ne soit pas supportee ne remet pas au cause la possibilite de faire de la bureautique, de l'internet etc etc bcp de choses dont pas mal de gens revent encore) il n'y a pas de raison de dire "bon c'etait sympa RMS cette idee de faire un truc libre mais maintenant on passe aux choses serieuses et on utilise du binaire".
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Zenitram (site web personnel) . Évalué à -1.
Comment expliquer a un petit nouveau qu'entre Linux qui fait 99% de ce qu'il veut, et Windows qui fait 100% de ce qu'il veut, il faut choisir le 99%?
(sachant que pour le petit gars, le cout, la GPL n'ont aucune importance, mais aucune importance...)
Il est possible d'installer Linux a certains endroits, "parce que c'est libre", a condition que 100% de ce que le gars veut soit rempli. Sans Webcam, c'est n'est pas 100%, donc exit Linux parfois...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Jean Parpaillon (site web personnel) . Évalué à 6.
Ce n'est pas de l'élitisme. Je me fous du côté technique (ergonomie, facilité d'utilisation, etc., etc.). Mais Linux est un système libre. Point
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Cédric Blancher . Évalué à 1.
Ben surtout que le Windows, il est déjà installé sur son ordi la plupart du temps... Donc, dans ce cas, il est même raisonnable de dire que le p'tit nouveau risque de ne pas voir grand intérêt à faire un effort non négligeable (installer Linux et apprendre à s'en servir) pour à la fin se retrouver avec un OS qui ne remplit pas 100% de ses besoins, alors qu'avant, quand il n'avait pas fait le moindre effort, c'était le cas...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Cédric Blancher . Évalué à 10.
Au taff, on m'a filé un laptop, un Dell Latitude D600 pour ne pas le citer. Bon, je suis sous Linux. Pour faire marcher le WiFi, je dois passer par ndiswrapper qui utilise le driver Windows propriétaire. Le modem, il faut aussi un driver proprio (mais je ne l'utilise pas). Pour aller taper ma messagerie, j'ai longtemps du utiliser le plugin propriétaire (aujourd'hui libre) de Evolution. Ça me fait chier, mais ça me permet de _bosser_ sous Linux et de ne plus toucher _du tout_ à Windows pour ça.
Oui, j'utilise du proprio, en toute connaissance de cause. Mais cet accro que je considère somme toute minime (comparé à la dose de LL qui tourne sur ce laptop) m'a permis de faire un pas que je trouve assez énorme : la suppression pure et simple de Windows dans un contexte professionel. En plus, ça me permet de faire du prosélitisme, en montrant aux gens qu'on peut bosser sous Linux sans problème. Et ça marche. J'ai des collègues qui passent sous Linux, pour voir, et quelques uns qui hésitaient à franchir le pas qui sont heureux. Donc ça fait moins d'utilisateurs de Windows (au moins un, moi), et plus d'utilisateurs de Linux, donc plus de gens susceptibles de faire chier un constructeur pour avoir des spécifications et/ou des drivers libres.
En parallèle, je signe les pétitions chez Broadcom, ATI et tutti quanti. Mais je vais pas chialer et ne pas utiliser le matos que j'ai sous la main. De toute manière, ils en ont rien à foutre les constructeurs, il est déjà acheté ;)
My last 0.02¤...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Emmanuel Seyman . Évalué à 3.
J'ai un Latitude D800 et j'utilise le pilote ipw2100 fourni Intel sous GPL. Ca marche très bien.
Le site web du pilote: http://ipw2100.sourceforge.net/(...)
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Cédric Blancher . Évalué à 1.
Si tu arrives à faire marche ma Broadcomm avec, tu hésites pas à me mailer...
OK, ----> []
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Gilles Crebassa . Évalué à 0.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à 5.
Je crois que beaucoup ne comprennent pas le problème.
Linux n'interdit pas d'_utiliser_ du proprio.
Linux (et Linus) interdit qu'on le modifie pour du proprio !
Linux (le coeur de l'OS, pas les drivers) ne veut pas être dépendant du proprio.
C'est aux développeurs de driver de suivre les specs de Linux et non l'inverse. C-à-d que ce n'est pas à un module proprio d'adapter Linux à ses besoins.
Un exemple, le passage à 4KSTACK.
Linux passe à 4KSTACK et NVidia doit adapter son driver. Linux n'a pas à rester en 8KSTACK car le driver NVidia ne marche pas en 4KSTACK.
Et si NVidia ne veut pas ou ne peut pas adapter son driver pour 4KSTACK alors :
1)- tant pis
2)- NVidia peut fournir un patch pour le noyau et l'utilisateur recompile le tout.
3)- Le modules NVidia gère le stack et écrase la gestion faite par défaut par Linux (techniquement ce n'est pas possible mais faisons "comme si").
NB, le 2) n'est pas possible avec un OS proprio. Alors arrêtons de considérer Linux comme intégriste alors qu'il est beaucoup plus "coolant" que tous les OS proprios et ce pour 0 ¤.
Le 3) est interdit par Linux car les fonctionnalités proches du coeur de Linux doivent être 100 % GPL. Une fonction centrale de Linux n'a pas a appeler du code proprio. pwc est dans ce cas.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Cédric Blancher . Évalué à 3.
Ça me gène un peu de lire des commentaires du style "de mon temps y'avait rien et j'y ai survécu". Même mon grand-père a fini par dépasser ce stade.
Pour ce qui est de ton parallèle avec 4KSTACK, je le trouve démesuré. D'abord parce que 4KSTACK est une fontion centrale qui impacte tous les drivers, alors que pwc n'est qu'un driver qui n'écrase, afaik, rien au fonctionnement du noyau. On est quand même à des kilomètres du cas évoqué...
Pour le 3, pwc marche sans pwcx, donc sur un kernel 100% GPL, que le hook soit là ou pas.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à 1.
Tout à fait.
> pwc n'est qu'un driver qui n'écrase, afaik, rien au fonctionnement du noyau.
Il y a déjà eu une crainte de ce type dans le passé (durant le 2.4 et relatif aux systèmes de fichier en module mais j'ai oublié les détails). D'où les SYMBOL_EXPORT etc.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Cédric Blancher . Évalué à 0.
Et dire que le NDA est expiré...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à 2.
Une licence ça se respecte. Point.
Sinon MS va copier du code GPL et le mettre dans Windows sans fournir les sources etc. Et on ne pourra rien reprocher à MS puis qu'on le tolère pour les autres.
Au final, un code sous GPL n'aura plus aucune signification et tout le monde y perd (sauf les sociétés pro-proprio qui adorent piller le LL).
Un gus demande à ne par respecter la licence GPL alors que le code est sous GPL.
Je vais passer pour un mec buté, mais je ne suis absolument pas d'accord avec la requête du mainteneur de pwc.
On peut repproche à Linux de ne pas avoir vu cette anomalie plus tôt.
Mais c'est le mainteneur de pwc qui a mis un bout de code sous GPL alors qu'il ne devait pas. Si on pousse la logique, il est maintenant obligé demande à philips de mettre le reste sous GPL. Mais heureusement, on n'est pas aussi buté :-)
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Cédric Blancher . Évalué à 1.
Et il y a différentes manières d'arriver au même but. Je pense que ce changement aurait pu se faire de façon nettement plus diplomatique et tout le monde aurait été content, modulo un peu de temps.
Si on pousse la logique, il est maintenant obligé demande à philips de mettre le reste sous GPL.
Ça serait pas mal en fait...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à 1.
Ooops, ce n'est pas le cas de pwc. C'est un problème "classique" de respect de la GPL. Du code sous GPL est utilisé pour appeler une fonction proprio (qui n'est pas dans les exceptions Linux).
C'est tout.
Clairement, ce code doit être retiré de Linux. Ce qui a été fait. Le driver peut marché pour les utilisateurs qui n'utilisaient pas le parti proprio. Mais le mainteneur de pwc c'est énervé et a demande la suppression de tout le driver.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . Évalué à 1.
Le 2 est un cas qui ne se presente pas avec un OS proprio, car avec un OS proprio il n'y a jamais besoin de recompiler le kernel pour faire marcher une carte graphique, suffit d'installer un nouveau driver.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à -6.
T'es un connard de merde toi.
Avec le libre tu as cette possibilité !
Prends une RHEL 3 ou SuSE et tu n'as jamais à recompiler le noyau pour installer un driver RHEL. C'est comme Windows mais il n'y a rien de proprio. Mais si tu en as besoin tu peux recompiler le noyau.
btw, tu peux aussi installer NVidia etc sur RHEL sans recompiler le noyau et Red Hat te garantie la compatibilité binaire pour tous les noyau RHEL 3 (Si ça marche à la sortie, ça marche jusqu'à la fin du support (5 ans après) et sans recompiler les modules (libre ou proprio)).
On peut aussi regarder vers une distribution plus communautaire avant que tu recommence à dégueuler de conneries
Fedora :
http://dag.wieers.com/home-made/apt/mega-merge.php(...)
Cherche les paquets kernel-module :
Fichtre, y a pas à recompiler le noyau ! Ya aussi kernel-module-pwcx !
Merci de nous avoir expliqué qu'IBM par exemple ne recompile jamais Windows car dans tous les cas ça ne sert jamais à rien avec Windows.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . Évalué à 2.
Va prendre des cours de francais et reste poli
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Guillaume Knispel . Évalué à 2.
Ceci étant il est tout a fait vrai qu'on peut faire des drivers proprio sous win, avec quasiment aucune limitation (je crois que la plus grande limitation est d'eviter de prétendre que c'est MS qui les a fait ou de ce faire de la pub associant MS au produit sans son accord en disant que ca dérive d'un code de MS du ddk, ce qui est assez permissif :), ce que l'on ne peut pas faire sous nux.
Les libertés dépandent de la vision des choses que l'on a, certain préfèrent le copyleft, d'autres trouvent que le copyleft restraint la liberté de faire du proprio. Les premier rétorques qu'interdire une restriction de la liberté n'est pas vraiment une perte de liberté, etc...
Quand a savoir si le copyleft doit s'appliquer dans ce cas précis de driver de webcam (et donc le hook enlevé), cela dépand "juste" du statut du module proprio : dérivation de linux ou pas ? le reste ("ouin ca marchait pendant 3 ans, maintenant ca marche plus") n'a pas vraiment d'importance si il s'avère que la suppression du hook etait indispensable pour preserver la liberté de nux, fusse au dépend du nombre d'utilisateurs.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à 0.
- "Le 2 est un cas qui ne se presente pas avec un OS proprio, car avec un OS proprio il n'y a jamais besoin de recompiler le kernel pour faire marcher une carte graphique, suffit d'installer un nouveau driver."
Soit :
- "Le 2 est un cas qui se présente avec un OS libre, car avec un OS libre tu as parfois besoin de recompiler le kernel pour faire marcher une carte graphique, il ne suffit pas d'installer un nouveau driver."
J'ai cru que c'était un comparaison avec Linux. J'avais tord ?
Ben désolé. Merci pour ces infos sur les OS proprios dans une news Linux. Passionnant.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . Évalué à 2.
Oui
Ben désolé. Merci pour ces infos sur les OS proprios dans une news Linux. Passionnant.
C'est toi qui a commence a parler d'OS proprios et de recompilation de kernels proprios, te plaint pas si on te repond.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à -2.
Quand sur un site dédié à Linux tu réponds à un posts qui parle de Linux ( http://linuxfr.org/comments/464879,1.html(...) ) dans une news sur Linux,
si tu ne veux pas aborder Linux, pitié mon ami dit le !
Sinon la prochaine foi je t'insulte encore. Normal.
btw, je dois comprendre que dans d'autres messages tu ne sous-entends pas qu'il faut recompiler le noyau linux pour un driver.
J'ai cru un moment que tu pensais que Windows avait un avantage sur Linux.
Mais tu as la tête sur les épaules et tu sais que ce n'est pas le cas.
Merci pour ces précisions !
La hache de guerre est enterrée.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . Évalué à 1.
si tu ne veux pas aborder Linux, pitié mon ami dit le !
Je te cites, du post que tu as linke :
NB, le 2) n'est pas possible avec un OS proprio. Alors arrêtons de considérer Linux comme intégriste alors qu'il est beaucoup plus "coolant" que tous les OS proprios et ce pour 0 ¤.
Non seulement tu ne sais pas lire ce que j'ecris, mais en plus t'es meme pas capable de relire ce que tu as ecris ?
Faut retourner a la maternelle mon cher, il y a du travail en perspective.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à -1.
C'est pas un truc qui parle de recompiler Linux ?
btw, je dis qu'avec un OS proprio c'est pas possible et ton amour du proprio dit "Tu n'en a pas besoin". Formidable, passionnant mais pas toujours vrai.
C'est dommage, je venais à peine de me réconciler.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par un_brice (site web personnel) . Évalué à 2.
On peut suppose que tu sous-entend que sous les autres cette opération soit nécessaire.
Au passage, c'est la première fois que je te voit être aussi grossier... on va mettre ça sur le compte d'un thread qui te casse les nerfs et d'une mauvaise soirée.
Sinon (pour qu'il y ait quand même un rapport avec le sujet) je pense que les devs ont eu raison de faire en sorte que leur noyau ne soutienne pas un pilote (partiellement) proprietaire. C'est une question de cohérence (qui me fait dire qu'ils ont tort d'utiliser BitKeeper, mais c'est un autre sujet).
Après, si l'auteur veut publier son driver bâtard sur l'internet, il a le droit (ou non?).
Dommage qu'il se soit énérvé, mais y'a une différence importante entre une situation approuvée et une situation tolérée pour l'instant. Il aurait dû le comprendre.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par oliv . Évalué à 0.
> Va prendre des cours de francais et reste poli
Pas besoin d'être injurieux pour être malpoli, il suffit d'être insultant et condescendant, comme tu nous le prouves si bien.
Merci de cette contribution de haut niveau à ce débat, débat que tu ne comprends pas entièrement (voir par exemple ton incompréhension du cas des drivers Nvidia).
Et au passage, en français, il existe des accents et des cédilles, ainsi que des points à la fin des phrases. Je tape ce message sur un clavier anglais, donc je ne veux pas entendre d'excuses bidons du genre mon clavier est US. La paille, la paille...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par bleh . Évalué à 1.
En même temps 007 l'a traité de "connard de merde" (ce que tu n'as pas manqué de remarquer si tu as lu le thread) donc ça explique le fait qu'il soit un peu plus violent qu'à l'accoutumée mais bon apparemment l'exigence de la politesse ne s'applique visiblement qu'à ceux qui ont le tort de défendre une opinion qui va à l'encontre de la majorité. Merci pour cette belle leçon.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à 2.
Tu fais bien de le remarquer. Je le regrette et je m'excuse.
Mais le pétage de plomb, ça arrive.
Regardes ses premiers messages (ordre chronologie), pBpG surfe sur le mécontentement/incompréhension créé par la news pour sapper Linux. Et comme en plus je suis tombé dans un de ses trolls, j'étais très énervé.
Mais maintenant que j'ai compris son fonctionnement, ça ne devrait plus arriver.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par gnumdk (site web personnel) . Évalué à 2.
Le monsieur te dis que sous Linux, un module est linké au noyau. Sous windows ce n'est pas le cas car la couche d'abstraction est bien plus grande. C'est ce qui permet comme je l'explique plus haut de faire fonctionner un driver avec la version n+1 du noyau.
Sous windows y'a pas ce genre de truc quoi:
CONFIG_MODVERSIONS: ?
? ?
? Usually, you have to use modules compiled with your kernel. ?
? Saying Y here makes it sometimes possible to use modules ?
? compiled for different kernels, by adding enough information ?
? to the modules to (hopefully) spot any changes which would ?
? make them incompatible with the kernel you are running. If ?
? unsure, say N.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à 1.
Je comprend, ne t'inquiète pas.
Le problème est de dire qu'un OS libre demande la recompilation d'un noyau pour un nouveau driver.
Ce n'est pas lié au fait que l'OS soit libre ou proprio. C'est un problème de gestion de projet. Soit tu décides de figer l'API (comme Red Hat/SuSE etc) pour facilité la vie de tes clients, soit tu veux que les choses avances vites en développement et tu casses l'API de temps à autre.
J'ai donné l'exemple de RHEL mais il y a aussi ça pour Apache. De la version 2.0.0 à 2.0.33 (environ car j'ai oublié) à chaque fois il fallait recompiler les modules (php, etc...). Depuis la version 2.0.33, l'API n'a pas bougé (ou j'ai raté un épisode) et il n'est plus nécessaire de recompiler les modules.
Pour subversion, avant la version 1.0.0 à chaque nouvelle version mineur, il fallait faire un dump/restore. Depuis la version 1.0.0, je n'ai pas fait un seul dump/restore.
Tu comprends ? Ce n'est pas qu'un problème technique, ou de licence (libre vs proprio). C'est aussi un problème d'objectif.
btw, Windows n'a pas trouvé la racette magique qui permet de figée l'API à jamais. De temps à autre, comme pour SP2, il y a des changements/incompatibilité.
> CONFIG_MODVERSIONS
Ya pire :-)
config MODULE_SIG
bool "Module signature verification (EXPERIMENTAL)"
depends on MODULES && EXPERIMENTAL
select CRYPTO_SHA1
select CRYPTO_SIGNATURE
help
Check modules for valid signatures upon load.
config MODULE_SIG_FORCE
bool "Required modules to be validly signed (EXPERIMENTAL)"
depends on MODULE_SIG
help
Reject unsigned modules or signed modules for which we don't have a key.
C'est dans Fedora depuis quelques semaines. On est très loins de la compatiblité binaire sur plusieurs années...
C'est bien un problème d'objectif et pas de "libre vs proprio" ou je_ne_sais_pas_quoi_que_va_nous_inventer_pb_pg.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Anonyme . Évalué à 1.
Cet argument est parfaitement ridicule. Installer un pilote pour Windows revient à installer un module pour Linux.
Rien (...)ne t'empeche jamais de charger un module, s'il est compilé pour ton noyau.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par tgl . Évalué à 9.
Et oui, c'est tellement évident.
Certains ne veulent pas l'admettre, mais pourtant, tous ici sans exception, nous le faisons. Quand on boot nos machines, on fait tous tourner le code proprio des firmwares. Quand on fait des requêtes sur google, on fait tous tourner le gros soft bien proprio et bien secret d'une boite qui utilise le libre pour des raisons techniques mais ne lui rend rien. Beaucoup ici prétendent n'utiliser que du libre, et font les vierges effarouchées quand quelqu'un à la franchise d'admettre que ça lui est impossible, mais ils se complaisent en fait dans un mensonge confortable.
Ils ont beaucoup d'arguments pour préserver leurs illusions. Ils disent que google c'est pas pareil, parceque c'est pas chez eux que ça tourne mais sur une autre machine, alors ça compte pas. Ou bien encore que les firmwares non plus c'est pas pareil, certes c'est chez eux, mais c'est en dessous de l'OS, donc ça compte pas non plus.
Mais ce sont autant de frontières artificielles, dessinées par pur pragmatisme. Ils se gargarisent de leur couple "OS + logithèque locale" qui est à 100% libre, mais que valent 100% d'un échantillon si savament choisi ? Pourquoi ça et juste ça ? Bah parceque en l'état actuel des choses, c'est leur meilleurs objectif atteignable. Pur pragmatisme disais-je, un simple calcul assurant leur tranquilité intellectuelle.
Et il n'y a pas de quoi les en blâmer d'ailleurs, c'est parfaitement humain de laisser à nos inconscients le soin de nos compromissions, pour que nos consciences, elles, ne ne nous embêtent pas trop. Seulement voilà, il ne faudrait pas non plus en profiter pour montrer du doigt ceux pour qui le "meilleurs objectif atteignable" en matière de libre est l'OS sauf quelques pilotes, ou bien la logithèque à de rares exceptions près, ou encore une large logithèque mais pas l'OS, etc. Ça ne sont pas des positions plus impures, ou si peu... Il faut seulement y voir des nuances dans les réalisations d'une même démarche, des gouttes d'eau dans un vin qui en contenait déjà tant.
Enfin voilà, désolé pour la verve maladroite et la philo de comptoir, mais c'est pas la première fois que je vois ici les ténors du noyau non-teinté la ramener pour accuser à tour de bras leurs voisins de manquement au librisme, et ça commence à me gonfler. Quand ils balancent des « t'as qu'à te passer de webcam », j'ai vraiment envie de répondre « t'as qu'à te passer de PC, et alors tu seras vraiment, à 100%, un libriste ». Nan, franchement, un peu d'humilité ne leur ferait pas de mal. L'important quand on a des idéaux, ça n'est pas de se convaincre qu'on les incarne à 100% alors que le voisin non, mais c'est juste de chercher toujours à les appliquer mieux, et à les promouvoir. Merci à ceux qui le font, quelque soit le degré de leur succès.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à 2.
Tu mélanges tout.
Il y a ici un problème de non respect de licence de Linux.
Une licence (libre ou pas) doit être respectée. Point final. Sinon c'est le bordel.
Si tu veux du proprio, installes du proprio. Ce sont tes oignons.
Il ne faut pas confondre
1)- "violation de licence"
2)- "utilisation de logiciels proprios qui ne violent aucune licence"
Ici, c'est le 1) qui nous préoccupe.
La licence te donne des droits. Si tu en a rien à foutre des droits données par la GPL, n'utilise pas de programme sous GPL et surtout ne développe pas avec la GPL si tu n'as pas l'intention de la respecter.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . Évalué à 1.
Une licence (libre ou pas) doit être respectée. Point final. Sinon c'est le bordel.
Le probleme etant que les mainteneurs du kernel ont accepte cette violation en connaissance de cause pendant 3 ans, et c'est bien ca qu'on leur reproche, leur incoherence .
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Cédric Blancher . Évalué à 3.
En outre, comme le fait remarquer Kixit (ou qqch dans le genre, pardon si j'ai écorché) la version 9.0 de PWCX nécessite de patcher le kernel pour y inclure le code directement lors de la compilation et éviter le problème de versioning. C'est vrai que ça ne sera pas non plus la lune de rajouter le hook dans PWC dans ce patch. PWC resterait dans le kernel sans le hook, maintenu par son auteur, qui serait tout à fait capable de fournir, à moindre effort, à côté, comme il le fait actuellement, un patch pour ajouter le hook. De toute manière, pour avoir PWCX, faut patcher !
Et tout le monde serait content. Mais la mauvaise foi des deux parties aidant, on est bloqué à cause d'une querelle de personnes. Personnellement, plus je retourne l'histoire, plus j'en veux à l'auteur du driver. Lui qui parle de grandir et redescendre sur Terre, il pourrait un peu balayer devant chez lui...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par tgl . Évalué à 2.
Ça dépend ce que tu désignes par ton "ici". Je suis bien d'accord que le n½ud de cette histoire de retrait de driver est une violation de la GPL, et là dessus j'approuve la décision des mainteneurs du noyau. Mais la branche de la discussion dans laquelle j'ai dumpé est elle une digression bien plus générale sur le bien fondé, ou non, de l'utilisation de pilotes binaires proprio sous linux.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . Évalué à 1.
Oui
> sur le bien fondé, ou non, de l'utilisation de pilotes binaires proprio sous linux.
Mouaifff...
Perso, quand ça cause de "code proprio de firmware" même si c'est vrai, ça sent le troll à plein nez.
Alan Cox utilise aussi des firmware proprio et j'espère que tu ne vas pas remettre en cause sont engagement pour le libre.
Et Alan Cox utilise aussi Google.
Le LL n'est pas une dictature.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par tgl . Évalué à 2.
Bah bien sûr que non, justement, mon propos est qu'être en partie tributaire de code proprio n'est pas incompatible avec un engagement pour le libre.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par bruno_rufier . Évalué à 3.
Merci pour ces paroles pleinnes de bon sens. Comme tu le dis tres bien tout est question de capacités personnelles.
En effet tout le monde n'est pas capable de recompiler son noyau a chaque fois qu'il faut installer un "driver" ou autre "firmware".
En tout cas mois je n'en suis pas capable. Et je ne vois pas pourquoi, n'etant pas capbles de faire cela je ne pourrai PLUS (et je dit bien PLUS et non pas PAS) utiliser ma WEBCAM.
C'est d'autant plus dommage que les webcams philips sont a mon avis les meilleures du marché.
Et merci encore tgl.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Gloo . Évalué à 0.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Anonyme . Évalué à 2.
Le débat est-il "qu'utilise t-on tous réellement" ou "que veut-on utiliser" ?
Mettre de l'eau dans son vin, c'est constater que la situation n'est pas conforme à ce que l'on peut avoir pour idéal ? Pour ma part, je considère qu'il s'agit juste d'un constat, ne devant en rien impliquer un changement d'idéal.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par nicolassanchez . Évalué à 1.
À te lire, en t'ayant vendu un PC, ils ont réalisé l'affaire du siècle...
Je pense que leur but est d'en vendre encore à d'autres gens...
Or là, tu leur fait de la mauvaise pub, et du coup ils vont peut-être moins en vendre... et peut-être qu'ils ne s'en foutront plus...
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Jiel (site web personnel) . Évalué à 1.
Voilà pourquoi il faut expliquer le libre aux gens avant de leur installer GNU/Linux.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par jcs (site web personnel) . Évalué à 2.
Je suis sûr que tu es comme moi, les problèmes de raréfaction de l'eau potable et de pollution t'inquiète. Tout comme moi, tu va faire des effort pour consommer moins d'eau et d'électricité en isolant ton logement, en achetant des ampoules à basse consommation... Mais certainement pas au point de vivre dans le noir, d'avoir froid chez toi, pas au point de ne prendre une douche que tous les deux jours. Dans la même idée, combien de personnes ont un serveur qui tourne chez elle 24h/24 ?
Certes la comparaison est brutale et démesurée mais elle montre bien le problème : si je suis conscient, voir concerné par un problème comme l'ouverture des formats de données, je veux bien chercher à le résoudre mais sans en pâtir moi-même.
Alors le libre oui, cenf fois oui, mais à l'unique condition que ça fonctionne aussi bien que le propriétaire.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Anonyme . Évalué à 1.
Mais le libre n'est qu'une approche, sans garantie de résultats dans 100 % des cas.
Les problèmes qu'il résoud peuvent être technique mais son sens est bien plus politique.
Comme l'exemple de Microsoft le montre très bien, on peut écrire de très bon logiciels en suivant le modèle propriétaire.
"si je suis conscient, voir concerné par un problème comme l'ouverture des formats de données, je veux bien chercher à le résoudre mais sans en pâtir moi-même."
C'est logique. Mais on ne peut pas toujours se contenter de suivre ses idées que lorsque ça n'a aucunes implications. A chacun de voir quels efforts il est pret à faire pour un objectif donné.
Je ne jette la pierre à personne. Tout le monde fait des choix, chacun choisit ses priorités.
Par exemple j'évite personnellement de faire des achats de produits de firmes malhonnetes (paradis fiscaux, corruption, exploitation du tiers monde) mais je m'achete tout de même des lames de rasoir (la barbe c'est pas mon trip) et du coup j'y suis contraint assez régulièrement...
# PWC en GPL ?
Posté par Sébastien Rohaut . Évalué à 3.
Aujourd'hui il en demande le retrait du noyau., lui aussi en GPL. Il a probablement le droit de demander, mais les mainteneurs du noyau ne sont pas obligés de le faire. Ils peuvent partir de la dernière version libre et décider d'inclure le module quand même, il me semble que rien ne leurt empêche, la GPL l'autorise explicitement dans ses quatre libertés...
Non ?
[^] # Re: PWC en GPL ?
Posté par Serge Rossi (site web personnel) . Évalué à 1.
[^] # Re: PWC en GPL ?
Posté par bhybct . Évalué à 1.
Par exemple, pwc suffit pour que gnomemeeting soit fonctionnel. Ca marche très bien sauf que la taille d'affichage est plus petite sans pwcx.
[^] # Re: PWC en GPL ?
Posté par Sébastien Rohaut . Évalué à 2.
[^] # Re: PWC en GPL ?
Posté par Christophe BAEGERT . Évalué à 1.
[^] # Re: PWC en GPL ?
Posté par Cédric Blancher . Évalué à 1.
pwc Philips webcam module version 9.0.1 loaded.
pwc Supports Philips PCA645/646, PCVC675/680/690, PCVC720[40]/730/740/750 & PCVC830/840.
pwc Also supports the Askey VC010, various Logitech Quickcams, Samsung MPC-C10 and MPC-C30,
pwc the Creative WebCam 5 & Pro Ex, SOTEC Afina Eye and Visionite VCS-UC300 and VCS-UM100.
pwc Philips PCVC730K (ToUCam Fun)/PCVC830 (ToUCam II) USB webcam detected.
pwc Registered as /dev/video0.
drivers/usb/core/usb.c: registered new driver Philips webcam
drivers/usb/core/usb.c: registered new driver snd-usb-audio
Et camstream fonctionne dans les résolution annoncées, que certains pourraient ne pas trouver "utilisable" pour leurs applications, certes.
[^] # Re: PWC en GPL ?
Posté par Sébastien Rohaut . Évalué à 2.
[^] # Re: PWC en GPL ?
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
[^] # Re: PWC en GPL ?
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: PWC en GPL ?
Posté par oliv . Évalué à 2.
Mais, rien n'empêche les distros d'intégrer le patch à leur kernel. On peut parier qu'elles le feront car elles s'occupent de légalité, mais pas de morale (ce n'est pas une critique, juste une observation).
http://marc.theaimsgroup.com/?l=linux-kernel&m=109356656720969&(...)
[^] # Re: PWC en GPL ?
Posté par Anonyme . Évalué à 1.
# Ai-je bien compris ?
Posté par Tripnotik . Évalué à 7.
Dans ce cas de figure les modules du genre Nvidia ne sont pas menacés, car (encore une fois si j'ai bien saisi) ce genre de module se rattache directement au noyau en passant directement par son API (dudit noyau). Cela est toléré, et rajoute un ptit message dans syslog pour tout de même manifester son mécontentement (ie tainted kernel)
Donc ce que ne veulent pas les mainteneurs, c'est un module "batard" qui permette de lui rattacher un module binaire. Dans ce cas de figure, je suis d'accord avec eux, et je les trouve cohérents.
Alors pourquoi dans la plupart des posts précédents les gens s'angoissent à écrire : "et pour mes drivers Nvidia, ATI, etc ..." ?
En outre, est-il possible pour Nemosoft (une fois calmé ...;o) d'écrire un module complètement binaire ? le temps que Phillips ouvre le code de ce dernier ?
[^] # Re: Ai-je bien compris ?
Posté par gabuzo . Évalué à 2.
Parce que les gens n'ont pas lu (pas le temps ou pas possible parce qu'en anglais) ce qui s'est dit sur LKML ;-).
En outre, est-il possible pour Nemosoft (une fois calmé ...;o) d'écrire un module complètement binaire ? le temps que Phillips ouvre le code de ce dernier ?
Yep lorsqu'il se sera calmé car pour l'instant il dit : « It would mean a demotion of PWC to a 2nd rank module, and probably quite a bit more work to maintain ». Bref retirer pwc du noyau en ferait un module de seconde zone.
# coup dur pour linux ou philips ?
Posté par fasthm . Évalué à 3.
l'exploiter sous linux après avoir un peu galéré, sous xp ça
a toujours été la galère aussi, mais je ne me ferais pas avoir
deux fois : ouste philips pour les achats de matériel.
et comme beaucoup de gens sur ce site je pense, je suis souvent
interrogé par des gens qui veulent acheter du matériel -> philips
a perdu quelques ventes de webcam grace à moi... certes c'est une
goutte d'eau, mais une réputation ça se construit, et notamment
en n'empechant pas les utilisateurs d'utiliser le matériel qu'ils ont
acheté de la façon qu'ils souhaitent, et pour un geek faché, il y a bien
10 ou 15 utilisateurs qui iront voir ailleurs.
(ça m'ennuie d'autant plus qu'on a un philips à caen qui bat de
l'aile...).
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: coup dur pour linux ou philips ?
Posté par djibb (site web personnel) . Évalué à 4.
tu prends une toucam pro... tu la branches... pouf gnomedmeeting marche (derniere version)
y'a rien a faire le driver pwc accepte 15 img/s en petite res.
bien sur pour du 20img/s a 640*480 il faut pwcx mais PWC est utilisable "out of the box"
la toucam pro/ toucam pro II sont les meilleures webcam jamais produites. excellente electronique et (et !!) excellente compression. essaye avec d'autres cam d'avoir une bonne qualite a 640*480 a 20 img/s ou en format plus petit a 30 img/s...
Ma webcam phillips n'a plus rien a voir avec une webcam du commerce vu qu'elle accepte les longues poses (plusieurs secondes) et que je l'ai equipee d'un capteur N&B
Il y a eu du reverse ingeniering pour virer les programmes de philips dans les eeproms pour les astronomoes amateurs. Je peux te dire que ce sont des cameras sacrement bien faites et TRES solides. Ce n'est pas pour rien que logitech utilise dans ses webcams haut de gamme les memes algo et les memes capteurs que phillips.
PWC n'est pas perdu (GPL) et donc les utlisateurs "normaux" de webcam n'auront pas de pbs (gnomemeeting et autres) mais pour les utilisateurs avances (astronomie) par contre, c une grande perte. hereusement qu'il avait fait une lib independante.
[^] # Re: coup dur pour linux ou philips ?
Posté par TiTiX . Évalué à 2.
Oui sauf que du coup tu es limité en taille à 160x120, ce qui est a peine digne de la qualite que j'avais il y a quelques années avec mon 56k
avec le haut debit c'est presque indecent de diffuser des images inferieurs a 320x240 (640x480 sert plus pour une utilisation locale, petite photos, diffusion sur un lan ..)
Donc c'est une perte aussi pour les "normaux" =/
Ce qui est vraiment dommage c'est que tout ça n'est qu'une histoire d'ego, Nemo souhaite que tout fonctionne "out of the box", et refusait l'option de patcher le noyau afin de modifier le comportement de PWC, pourtant si on suit les instructions d'installation de PWCX 9.0 voila ce que l'on peut lire :
# patch -p1 -s < ~/pwcx-9.0/patch-2.6.4
ça ne ressemble pas deja a un patch ça ?
de la mauvaise foi, et rien d'autre !
--
TiTiX
[^] # Re: coup dur pour linux ou philips ?
Posté par Cédric Blancher . Évalué à 2.
C'est parce que le 2.6.4 arrive avec la version 8.4... Mauvaise foi ?
[^] # Re: coup dur pour linux ou philips ?
Posté par TiTiX . Évalué à 0.
En d'autres termes, pour pouvoir profiter des fonctionalites de pwcx, et ce quelque soit la version du noyau il fallait depuis pwcx 9.x patché le noyau pour modifier la structure de compilation de la branche USB mais aussi copier divers fichiers sources dans l'arborescence du noyau :
- Copy the proper libpwcx.a to the directory; see the various
subdirectories for builds of the library. You may also have to rename
the library while copying, e.g.
# cp ~/pwcx-9.0/mipsel/libpwcx-mips4.a drivers/usb/media/libpwcx.a
- Copy the glue code to the directory
# cp ~/pwcx-9.0/pwcx/*.[ch] drivers/usb/media
Donc s'il est vrai que PWC marchait out of the box, ça n'etait pas du tout le cas pour pwcx, il y avait quand meme des manipulations (certes mini) a faire.
Donc l'argument de Nemo ne tiens plus trop la route sur la facilite d'utilisation du pilote pour des gens peu experimentés.
en gros la seule concession qu'il aurait eut a faire c'est d'avoir a rajouter un patch pour pwc.c afin qu'il accepte le module pwcx. (patch necessaire seulement pour les utilisateurs souhaitant profiter de la compression et qui laisserait dans le cas ou on ne l'applique pas un module pwc conforme au exigences des devels du kernel et qui fournirait un service minimum pour la webcam (ie 160x120@10 fps "out of the box") )
--
TiTiX
[^] # Re: coup dur pour linux ou philips ?
Posté par Cédric Blancher . Évalué à 2.
Exact.
Je tournais avec le driver téléchargé sur le site, pas celui du kernel. Donc forcément, je patchais à mort ;)
Finallement, on a affaire à une belle brochette de têtes de mule dans cette histoire (surtout un manifestement)...
[^] # Re: coup dur pour linux ou philips ?
Posté par Davinux . Évalué à 1.
Ce patch sert uniquement:
- à modifier le Makefile qui sert déjà à compiler pwc, de manière à compiler aussi pwcx.
- à rajouter pwcx dans les options de compilation du noyau.
[^] # Re: coup dur pour linux ou philips ?
Posté par TiTiX . Évalué à 1.
--
TiTiX
[^] # Re: coup dur pour linux ou philips ?
Posté par fasthm . Évalué à 1.
je confirme (ct il y a 3 ou 4 ans) que je me suis emm... quiquiné
pour avoir la vidéo sous nux avec la toucam, et qu'aujourd'hui
encore cette cam qui est maintenant sur un poste XP ne sort
que du 160x100 avec en plus une appli de config qui part en vrille
à tout bout de champ.
mon constat :
- sous un OS libre, elle m'a cassé les pieds,
- sous un OS proprio, philips a du passer à autre chose, les drivers
pourris sont et pourris resteront.
la qualité de l'electronique ne change rien à l'affaire (et effectivement,
j'ai le souvenir d'une image plutot clean).
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
# au risque d'être un peu radical....
Posté par moudj . Évalué à 3.
c'est plus côté user.
je dit ça tranquillement en plus vu que ma webcam est une philips ;-)
[^] # Re: au risque d'être un peu radical....
Posté par TiTiX . Évalué à -1.
La partie qui n'a rien a faire dans le noyau par contre c'est ce qui touche a la conversion de format (et l'algorithme de decompression), Nemo en avait deja pris pour son grade par Alan Cox, qui avait demandé que tout soit replacé dans l' userspace
--
TiTiX
[^] # Re: au risque d'être un peu radical....
Posté par moudj . Évalué à 3.
radical alors stp ;-)
> La partie qui n'a rien a faire dans le noyau par contre c'est ce qui touche a la conversion de format
C'est ce que je sous-entendais aussi, mais bon comme ça avait déjà été dit... sortir la conversion du noyau pour la laisser au niveau applicatif.
# 300 \o/
Posté par Gniarf . Évalué à -3.
\_o<
[^] # Re: 300 \o/
Posté par Ph Husson (site web personnel) . Évalué à -2.
[^] # Re: 300 \o/
Posté par Ph Husson (site web personnel) . Évalué à -2.
ah ben nan 300 maintenant :p
[^] # Re: 300 \o/
Posté par Guillaume Knispel . Évalué à 0.
[^] # Re: 300 \o/
Posté par Vincent LE LIGEOUR . Évalué à 2.
PS : ça peut aussi devenir une excellente methode de notation automatique de copies d'élèves
[^] # Re: 300 \o/
Posté par Guillaume Knispel . Évalué à 1.
Un coup de bz2 sur la page oueb, et hop, t'obtiens direct la quantité d'information disponible :p
[^] # Re: 300 \o/
Posté par coujou . Évalué à 0.
# pardon ...
Posté par Prae . Évalué à -3.
Plus le temps passe, moins certaines personnes de l'opensource laissent le libre choix entre LL et LP ...
finalement, je me demande pourquoi je me suis mis aux LL : au final c'est la meme choix, on m'interdit d'utiliser son contraire ...
[^] # Re: pardon ...
Posté par SoWhat . Évalué à 1.
- les dev du noyau Linux cèdent aux exigences de l'auteur du driver
- l'auteur du driver cède aux exigences des devs du kernel
En quoi la 1ere solution serait meilleur que la première?
Et puisque tu parles d' open source, saches que l'auteur a le choix de continuer en respectant le choix les développeurs du noyau ; et il préfère ne pas le faire. Pourtant, il (et toi aussi) dispose des sources et de tout ce qu'il faut pour les modifier et recompiler le kernel pour y mettre son driver.
# Quelqu'un sait...
Posté par Dany Martineau . Évalué à 3.
Maintenant, mon problème est que si je désires changer de noyau, je ne pourrai plus utiliser ma webcam!
J'ai cherché sur le net et le ménage a été bien fait! :-( Rien!
Si quelqu'un peu m'aider, ce serait apprécié! :-)
[^] # Re: Quelqu'un sait...
Posté par djibb (site web personnel) . Évalué à 2.
[^] # Re: Quelqu'un sait...
Posté par Cédric Blancher . Évalué à 3.
http://www.netexit.com/~sid/pwc/pwc-9.0.1.tar.gz(...)
http://www.netexit.com/~sid/pwc/pwcx-9.0.tar.gz(...)
Je n'ai pas vu dans le README de condition limitative à la redistribution de PWCX.
[^] # Re: Quelqu'un sait...
Posté par Stephane Levant . Évalué à 1.
mail => rajouter free.fr
[^] # Re: Quelqu'un sait...
Posté par Cédric Blancher . Évalué à 2.
http://web.archive.org/web/20040202174433/http://www.smcc.demon.nl/(...)
Dernière update du 02/02/2004.
[^] # Re: Quelqu'un sait...
Posté par Cédric Blancher . Évalué à 3.
http://www.smcc.demon.nl/webcam/(...)
# Les faits, rien que les faits...
Posté par oliv . Évalué à 9.
Alors, je vais faire un petit résumé de l' "affaire":
Les mainteneurs du noyau n'ont pas pris une décision d'exclure la possibilité d'utiliser un module binaire. Ils ont décidé il y a plus de 10 ans d'avoir recours à la GPL pour écrire le noyau. La GPL n'autorise pas d'avoir un module binaire car il s'agit de code dérivé. L'interface noyau-module n'est pas une interface publique. Pour les pilotes propriétaires, il faut écrire du code GPL qui fait le lien vers du code externe au noyau.
Gerg Kroah a remarqué récemment qu'il y avait un problème d'incompatibilité d'un morceau de code pour ces caméras avec la GPL et a corrigé ce problème. Ça n'a pas plu au créateur du code qui a demandé soit que le code effacé soit remis en place (d'où retour à une situation de non respect de licence par le code Linux, ce qui est inacceptable), soit que l'ensemble du code soit retiré.
Greg a donc retiré l'ensemble du code, selon la volonté de l'auteur. Lui, Andrew Morton et Linus ont bien précisé qu'ils le faisaient pour respecter les volontés de l'auteur. Rien n'interdit légalement en effet à Linux de continuer à utiliser la partie correcte du code, vu que l'auteur l'a fournie sous license GPL. Néanmoins, Linus ne veut pas violer la volonté de l'auteur pour des raisons morales.
Il n'y a donc eu aucun intégrisme ou fanatisme. Linus, Andrew et les autres ne veulent pas violer les licenses ou la loi, c'est tout. Si l'auteur d'un driver ne veut pas écrire du code "propre", c'est lui qui est en tort. Si il ne tolère pas que son code soit corrigé pour respecter les licenses, c'est encore son tort. Il a posé un ultimatum, ils n'ont pas cédé.
Greg a pris acte de la volonté de l'auteur, l'a remercié de sa contribution à Linux, lui a souhaité bonne chance, et a souhaité le revoir dans la communauté un jour.
[^] # Re: Les faits, rien que les faits...
Posté par Jerome Herman . Évalué à 2.
Non La GPL n'autorise pas d'avoir un module binaire livré avec le code GPL QUAND il s'agit de code dérivé.
Bon ceci étant aparament le pilote propio faisait massivement appels aux fonctions USB du kernel d'après Andrew Morton. Et dans ce cas là crack il y a violation de licence.
Par contre ce qui me chagirne c'est que le code a été enlevé d'abord dans une guerre d'egos et que la faute a été trouvée après (et manifestement a demandé a Andrew pas mal de temps).
Mais bon.
Kha
[^] # Re: Les faits, rien que les faits...
Posté par oliv . Évalué à 3.
"There is NOTHING in the kernel license that allows modules to be non-GPL'd"[1]
Et ce n'est pas nouveau. Ce message date de 2002, et est déjà un rappel. L'exception de certains modules est due à la nature non-dérivée de leur code vis à vis du kernel, car porté à partir d'un autre OS (e.g. drivers Nvidia).
[1] http://groups.google.com/groups?selm=Pine.LNX.4.44.0210170958340.67(...)
[^] # Re: Les faits, rien que les faits...
Posté par Jerome Herman . Évalué à 1.
Tu peux avoir des modules non dérivés même si non portés depuis un autre OS. a GPL dit explicitement que les travaux que l'on peut raisonablement considéré comme indépendant n'ont pas à être en GPL si ils sont distribués séparément.
Ca n'est pas uen fleur faite pas les dev du kernel, c'ets la GPL.
La question est donc de savoir si le driver PCWX est indépendant du kernel ou si c'est un travail dérivé.
Kha
[^] # Re: Les faits, rien que les faits...
Posté par oliv . Évalué à 2.
Je n'ai jamais mentionné de fleur des développeurs, pour la simple raison qu'il n'y en a aucune.
pour faire bref, la position des développeurs est:
MODULE => headers du kernel inclus => dérivé du kernel => GPL
Il y a des cas ou la seconde implication n'est pas vraie (NVidia). Mais ces cas sont rares.
# en route vers le record
Posté par Xmanu . Évalué à 0.
[^] # Re: en route vers le record
Posté par Ph Husson (site web personnel) . Évalué à 1.
Mais c'est vrai que 400 reponses sur un truc pareil......
Jamais pensé a un troll pareil
Et pourtant ils l'ont fait!
Ralala il est fort l'auteur de pwcx lacher un troll pareil 'tin ca devrait pas etre permis
Enfin bon en meme temps fo bien que pBpG ai qqc a dire :)
[^] # Re: en route vers le record
Posté par Christophe BAEGERT . Évalué à 1.
C'est un vrai problème, on ne pourra pas continuer longtemps comme ça, il faudra que ça se débloque d'un côté où de l'autre, on ne peut pas faire changer des millions d'¤ de matos à chaque caprice de développeur ou constructeur... ou alors on peut déjà prédire une baisse de Linux sur le desktop (quoique le problème se pose aussi sur les serveurs, avec par ex. les drivers de carte raid...)
[^] # Re: en route vers le record
Posté par jmfayard . Évalué à 4.
Je ne sais pas a combien il est d´ailleurs, mais les deux news a haut debit trollifere qui m´ont marque sont :
- 101 choses que fait Mozilla et pas MS-IE (521 commentaires) avec un troll velu qui osait critique Mozilla : http://linuxfr.org/2002/11/07/10231.html(...)
- XAML et l'avenir de GNOME (588 commentaires) un modele du genre melant des grands classiques comme Gnome, Miguel de Icazia et Microsoft. Et surtout PieD qui declenche le troll du siecle en 2 petits mots et a peine 7 caracteres : http://linuxfr.org/comments/365612.html#365612(...)
- ... (d´autres ?)
[^] # Re: en route vers le record
Posté par Maxx . Évalué à 3.
Miam... j'avais jamais lu la suite, et faut dire que le lâcher est particulièrement réussi... et le troll poilu à souhait ^^
[^] # Re: en route vers le record
Posté par Aurélien Maille . Évalué à 1.
[^] # Re: en route vers le record
Posté par jmfayard . Évalué à 2.
Système de notation sur LinuxFr (923 commentaires) http://linuxfr.org/2003/04/26/12220.html(...) [1]
Rajoutons dans la liste Fin du support Linux des webcams Philips http://linuxfr.org/2004/08/26/17101.html(...) qui va vers ses 500 commentaires, ce qui lui assure une place dans le haut du panier.
[1] Autant les deux trolls sus-cites etaient marrants, autant celui-ci est bien malsain, on dirait une explosion de rancoeur et de nombrilisme accumules au cours des annees.
[^] # Re: en route vers le record
Posté par Ph Husson (site web personnel) . Évalué à -1.
Dommage qu'il soit parti (il revient aujourd'hui)
On va voir comment il va réagir pour ce magnifique troll
Et pis 521 bon
La news est pas encore términée la :)
(20 commentaires au moins en une heure donc bon :)
[^] # Re: en route vers le record
Posté par Maxx . Évalué à 2.
sur des news de ce genre-là avec autant de commentaires, son navigateur open-source il en prend un coup :'(
[^] # Re: en route vers le record
Posté par Dafatfab . Évalué à -1.
[^] # Re: en route vers le record
Posté par Fabien Engels . Évalué à -2.
[^] # Re: en route vers le record
Posté par Gloo . Évalué à -1.
[^] # Re: en route vers le record
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
J'ajoute que le code html invalide aide pas la toolbar a fonctionner correctement :)
# C'est les sites de cul qui vont être triste !
Posté par syj . Évalué à -1.
Software is like sex... It's better when it's free
Bon week-end,
Syj
____________________
Le vendredi, c'est permis.
# FAQ par le mainteneur Greg Kroah Hartmann
Posté par oliv . Évalué à 7.
"Summarizing the PWC driver questions/answers"
http://lwn.net/Articles/99639/(...)
C'est une lecture bien instructive qui évitera peut-être qu'on lise ici encore plus d'âneries du genre "Lhinux Thorvhalds es un aintaigriste" ou bien "C'est pas libreu linnuxe". Il répond aussi à la question existentielle "Mais qu'est ce qu'on va devenir????"
À bon lecteur, salut.
[^] # Re: FAQ par le mainteneur Greg Kroah Hartmann
Posté par 007 . Évalué à 2.
Il faut préciser que Greg Kroah Hartmann n'est pas le mainteneur de pwc !
C'est le mainteneur d'USB (je crois).
# Alleluia
Posté par jmfayard . Évalué à -1.
[^] # Re: Alleluia
Posté par Ph Husson (site web personnel) . Évalué à 1.
D'ailleurs qui est pour organiser une fois par mois une récompense pour le meilleur troll du mois?
Et parmis les heureux gagnants on fera un tirage tout les ans :)
Nan?
Moi je dis faut organiser ca :)
# Dégouté..
Posté par Anonyme . Évalué à -9.
Les autres peuvent bien aller voter PS s'ils veulent, de toute façon ils se plaindront toujours car ils se feront toujours baiser.
Quand les profiteurs qui nous gouvernent émettront des lois qu'après approbation du peuple par referendum, la, ont pourras commencer a parler de démocratie, en attendant ne pas voter LCR ou FO c'est se faire niquer.
TIENS. UNE IDEE ..... JUSTE COMME CELA CAR COMME SUR CE SITE et comme ailleurs la populasse névrosée ne sait que critiquer mais jamais proposer (normal ils ne savent pas)
Et si un socialiste, un vrai, se proposait aux élection de manière a avoir droit à un bulletin de vote dans les urnes, en promettant bien sur de démissionner immédiatement après. Au moins LA ont verrait ou sont les voies des forces de progrés. Et les gros cons pourront vraiment les comptabiliser. Mais pour ça il faut avoir envie d’agir, concrètement, et non pas passer son temps en critiquant pierre Paul jaques ou Pierre sans jamais rien proposer à la place. Tout le reste n'est que verbiage inutile.
Y en à pas un qui à les couilles d'agir. Où est le temps béni où les révolutionnaires nihilistes poseurs de bombes défrayaient la chronique? Pour écrire sur le net, ça vous êtes très fort.
Mais lequel d'entre vous agit vraiment?
Pour ces salauds de bourgeois, esclavagistes de tous rangs, qui se gavent à la sueur de notre front. Ces enfoirés qui gagnent tout leur pognon et qui, pour s'engraisser encore plus, nous jettent les miettes de notre travail.
Oui camarades!!! Un jour les gens descendront dans la rue pour protester et on leur pétera la gueule à ces pourris qui veulent nous aliéner, à tous ces dominants, fruits d'une longue hérédité d'empêcheurs de vivre comme bon nous semble , les hommes lèveront leur poing pour le foutre sur la gueule de ses salauds de bourgeois.
Alors ils nous enverront leur police mais comme on sera les plus nombreux, nous vaincrons et nous crèveront leur panse gavée par notre sueur et les survivants finiront dans l'enfer des goulags.
http://octobre1917.skyblog.com/(...)
Luttons tous ensemble pour un monde égalitaire !!!
[^] # Re: Dégouté..
Posté par Xmanu . Évalué à -1.
En effet, vous déclarez voter pour FO-LCR, bien vous en fasse, mais sachez toutefois que d'après ce que vous dîtes, vous voteriez plutôt LO-LCR. FO (Force Ouvrière) étant un syndicat assez proche du PS, parti que vous critiquez sans détour.
Enfin dire que vous n'avez jamais voté pour autre que LO-LCR montre votre jeune âge, puisque la marche commune de ces deux mouvements politiques, représentés respectivement par A. Laguiller et A. Krivine, est récente. Il y a bien eu les européennes de 1979, mais ça fait plus de vingt ans et de nombreuses divergences ont eu lieu entre temps.
Ne critiquant pas le fond de votre intervention, bien qu'elle me semble tout à fait déplacée ici, n'oubliez pas que pour être crédible il faut éviter les erreurs (surtout quand elles se répètent).
A moins que ce soit la fatigue -à 02:15, en week-end il faut manquer d'imagination pour être derrière un moniteur, même un LCD 23" (?)- vous n'êtes qu'un imposteur.
Bonne journée tout de même !
[^] # Re: Dégouté..
Posté par Anonyme . Évalué à -3.
Les nouvelles ce matin
20% pour l'horreur
20% pour la peur
Ivres d'inconscience
Tous Fils de France
Au pays des Lumières
Amnésie suicidaire
Nous sommes nous sommes...la nation des Droits de l'Homme
Nous sommes nous sommes...la nation de la tolérance
Nous sommes nous sommes...la nation des Lumières
Nous sommes nous sommes...à l'heure de la résistance
Pour les rêves qu'on a fait,et pour ceux qu'on fera
Pour le poing qu'on a levé,pour celui qu'on levera
Pour un idéal,pour une utopie
Allons marchons ensemble enfants de la Patrie !!
Fils de France !!
Ca pour baisser la tête,ah oui ça t'aimes bien les minutes de silence !
Fils de France !!
C'était ta peine hier et déjà tu brandis le drapeau de l'ignorance !
Fils de France !!
Nous n'oublierons jamais que nous sommes et serons les fils de la résistance !
Fils de France !!
Au royaume des aveugles,tu sais bien ce qu'on dit,les borgnes sont les rois !
Y'a ces ombres derrière nous,y'a ces idées vendues
Y'a ces drapeaux qui flottent,et les hymnes dessus
Et puis y'a toi mon frère,oui toi qui n'y croit plus
Et puis y'a nos prières,et nos causes perdues
Honte à notre pays,honte à notre Patrie
Honte à nous,la jeunesse,honte à la tyrannie
Honte à notre pays,revoilà l'ennemi
Allons marchons ensemble enfants de la Patrie
Nous sommes nous sommes...la nation des Droits de l'Homme
Nous sommes nous sommes...la nation de la tolérance
Nous sommes nous sommes...la nation des Lumières
Nous sommes nous sommes...à l'heure de la résistance
Nous sommes nous sommes...la nation des Droits de l'Homme
Nous sommes nous sommes...la nation de la tolérance
Nous sommes nous sommes...la nation des Lumières
Nous sommes nous sommes...à l'heure de la résistance
[^] # plop
Posté par Meuh! Meuh! . Évalué à 1.
[^] # Re: Dégouté..
Posté par Gabriel . Évalué à 1.
Les trolls jouent dans le jardin.
Un peu de sauce pour la salade?
[^] # Re: Dégouté..
Posté par archaons . Évalué à 1.
# M...
Posté par Bernard LAMBERT . Évalué à 1.
Horreur . si le Pb n'est pas réglé rapidement, les supporters de M$ vont bien rire et cela va apporter de l'eau au moulin
Vous voyez bien que linux pour le PC n'est pas prêt, coté serveur la bataille est perdu pour bilou
je n'ai pas bien compris le différent qui oppose le developpeur et la communauté linux en charge du support USB, il me semble qu' il y a du bon arguments de chaque coté et qu'un compromis devrait se trouver d'autant que c'est peut être valable pour d'autre camera USB ?
j'attend avec impatience des nouvelles
# Le driver webcam philips ne sera PAS supprimé du noyau
Posté par effco . Évalué à 3.
http://kerneltrap.org/node/view/3747?PHPSESSID=1357f0b91d882d470fbd(...) (anglais)
# 500 commentaires sur http://linuxfr.org/2004/08/26/17101.html [20040903]
Posté par Le_Rat_2004 . Évalué à 2.
Cela fait très lourd à lire (plusieurs heures).
Pour consulter cet article ultérieurement, j'ai enregistré la page HTML.
Je voudrais savoir quels outils (sous linux) utiliser pour en faire des statistiques. Par exemple je voudrais savoir quels mots reviennent le plus souvent. Les outils que je cherche peuvent être indépendants ou intégrés dans un logiciel (traitement de texte par exemple).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.