Il parle de mettre les patchs a part et tout recompiler, je lui explique simplement que sous Windows ca ne sert a rien, j'ai pas dit que c'etait necessaire sous Linux.
Bon mon petit debile, avant d'insulter les gens, tu m'expliques ou est-ce que dans mon commentaire je dis que chez Linux il y a besoin de recompiler le kernel pour avoir son driver ?
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.
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 .
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 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.
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.
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.
J'attends toujours des chiffres de ta part quand tu enonces tes verites universelles.
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.
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.
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.
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.
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.
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.
Que veux tu que le developpeur fasse ? Il n'a pas le choix, il a du signer un NDA avec Phillips pour pouvoir supporter decemment les webcams et il n'est pas _autorise_ a divulger les sources.
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.
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
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.
J'ai même l'impression que reiser4 est une étape importante. Les FS : XFS, JFS et NTFS sont maintenant dépassés par une solution libre. J'ai même l'impression qu'aucune concurrence ne viendra plus lui contester sa suprématie.
Depasses en quoi ?
Les plugin ? Deja dans NTFS depuis des lustres
Optimisation pour petits fichiers ? Deja dans NTFS depuis longtemps(ils vont dans la MFT, n'utilisent pas de clusters)
...
Et je serais pas surpris du tout que XFS ou JFS soient dans le meme panier.
Je crois surtout que tu t'es laisse impressioner par une page pleine de mots techniques et un manque de connaissance des autres FS
Et il y a une autre chose qu'il ne faut pas oublier, c'est que les features d'un filesystem sont totalement inutiles si rien dans les couches du dessus ne les utilise, il faudra du temps pour voir si les couches hautes de Linux se mettent a supporter les extensions de ReiserFS
Ca sera plus lent sur une machine tres chargee, mais si ta machine est tres chargee, t'auras d'autres problemes a resoudre que les qqe % de perfs de ton FS a mon avis
Certaines fois il vaut mieux effectuer plus d'operations, car si c'est fait comme il faut, ca va plus vite.
Ton soft recoit une "allocation" de 50'000 cycles CPU par secondes ( chiffre fantaisiste pour l'exemple) par le scheduler, le truc dont il faut se souvenir ici, c'est que si tu ne les utilises pas, tu les perds, tes allocations ne s'accumulent pas.
Un soft qui doit effectuer 200'000 operations, si il veut terminer son job le plus vite possible, a donc tout interet a effectuer le plus d'op/s possible, surtout sur un desktop, car un desktop c'est un gachis enorme de cycles CPU, la charge monte rarement au dessus de 25% sur un desktop, il y a donc bcp de temps dispo pour faire ses operations sans ralentir le systeme.
Est-ce que avoir un %CPU eleve risque de ralentir tout le systeme ? Pas forcement, car le scheduler va faire la police et donner du temps a tout le monde a tour de role selon les priorites de chaque process. Le truc etant d'avoir les bonnes priorites sur les process, mettre une haute priorite a un process gourmand en CPU, c'est un moyen tres sur d'avoir une machine avec une UI tres lente.
Pour ce qui est de l'utilisation du CPU, il n'y a aucune logique dans le fait qu'une haute utilisation du CPU implique une meilleure gestion des opérations bloquantes! Si la gestion des opérations bloquantes est bonne, je suis d'accord qu'une plus haute utilisation du CPU n'est pas un gros problème, mais je ne vois pas d'autres liens entre ces 2 paramètres.
Ben fait le test suivant :
Tu ecris deux softs qui font le meme gros calcul.
Dans un des 2 tu mets un sleep() de 1s de temps en temps.
Compares le % de CPU utilise dans les 2 cas, marrant, mais le process le plus lent a le % de CPU le plus faible.
Tu peux comprendre ca de la maniere suivante :
Les 2 softs font 200'000 operations.
Un soft les fait en 4s --> 50'000 op/s
L'autre les fait en 10s --> 20'000 op/s (en 10s car il fait les choses dans le mauvais ordre, pas en non-bloquant, etc...)
Resultat : le 2eme soft a un % CPU plus faible, mais il est bcp plus lent.
Non non, il y a une whitelist pour ca, tu mets le soft sur la whitelist et l'OS ne tiendra pas compte du bit NX pour ce process, ce qui permet au process de tourner.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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 pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à -1.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 1.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Va prendre des cours de francais et reste poli
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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 pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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: Solution ?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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: pas cool :/
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 4.
- jouent (donc 3D)
- font de l'IM avec webcam
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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: Linux est-il assez déployé pour se permettre ca?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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: pas cool :/
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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 pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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: Autre solution: hors kernel ?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par pasBill pasGates . En réponse à la dépêche Fin du support Linux des webcams Philips. É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: Innovations...
Posté par pasBill pasGates . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 8.
Depasses en quoi ?
Les plugin ? Deja dans NTFS depuis des lustres
Optimisation pour petits fichiers ? Deja dans NTFS depuis longtemps(ils vont dans la MFT, n'utilisent pas de clusters)
...
Et je serais pas surpris du tout que XFS ou JFS soient dans le meme panier.
Je crois surtout que tu t'es laisse impressioner par une page pleine de mots techniques et un manque de connaissance des autres FS
Et il y a une autre chose qu'il ne faut pas oublier, c'est que les features d'un filesystem sont totalement inutiles si rien dans les couches du dessus ne les utilise, il faudra du temps pour voir si les couches hautes de Linux se mettent a supporter les extensions de ReiserFS
[^] # Re: Pas d'inquiétudes
Posté par pasBill pasGates . En réponse au journal Reiserfs 4 !. Évalué à 3.
[^] # Re: Pas d'inquiétudes
Posté par pasBill pasGates . En réponse au journal Reiserfs 4 !. Évalué à 10.
Certaines fois il vaut mieux effectuer plus d'operations, car si c'est fait comme il faut, ca va plus vite.
Ton soft recoit une "allocation" de 50'000 cycles CPU par secondes ( chiffre fantaisiste pour l'exemple) par le scheduler, le truc dont il faut se souvenir ici, c'est que si tu ne les utilises pas, tu les perds, tes allocations ne s'accumulent pas.
Un soft qui doit effectuer 200'000 operations, si il veut terminer son job le plus vite possible, a donc tout interet a effectuer le plus d'op/s possible, surtout sur un desktop, car un desktop c'est un gachis enorme de cycles CPU, la charge monte rarement au dessus de 25% sur un desktop, il y a donc bcp de temps dispo pour faire ses operations sans ralentir le systeme.
Est-ce que avoir un %CPU eleve risque de ralentir tout le systeme ? Pas forcement, car le scheduler va faire la police et donner du temps a tout le monde a tour de role selon les priorites de chaque process. Le truc etant d'avoir les bonnes priorites sur les process, mettre une haute priorite a un process gourmand en CPU, c'est un moyen tres sur d'avoir une machine avec une UI tres lente.
[^] # Re: Pas d'inquiétudes
Posté par pasBill pasGates . En réponse au journal Reiserfs 4 !. Évalué à 6.
Ben fait le test suivant :
Tu ecris deux softs qui font le meme gros calcul.
Dans un des 2 tu mets un sleep() de 1s de temps en temps.
Compares le % de CPU utilise dans les 2 cas, marrant, mais le process le plus lent a le % de CPU le plus faible.
Tu peux comprendre ca de la maniere suivante :
Les 2 softs font 200'000 operations.
Un soft les fait en 4s --> 50'000 op/s
L'autre les fait en 10s --> 20'000 op/s (en 10s car il fait les choses dans le mauvais ordre, pas en non-bloquant, etc...)
Resultat : le 2eme soft a un % CPU plus faible, mais il est bcp plus lent.
[^] # Re: Le bug NFS
Posté par pasBill pasGates . En réponse à la dépêche Linux 2.6.8, suivi de près par Linux 2.6.8.1. Évalué à 5.
[^] # Re: Ah la lecture...
Posté par pasBill pasGates . En réponse au journal Mise à jour WP SP2: gare à la casse.... Évalué à 2.