Journal [Darty] Putain de wifi

Posté par  .
Étiquettes : aucune
0
30
juin
2008
Selon Zythom[1], dans le cadre de l'affaire darty, les expert n'ont mis que 40 minutes a installé Linux, mais 2h20 pour configurer le wifi.

De la à supposé qu'une machine avec un wifi non reconnus a été volontairement fournie...

Et pourtant parmi les problèmes récurent sous Linux on trouve

*Le Wifi
*Les Webcam et faire quelque chose de la webcam ( c'est bien qu'elle soit reconnue par le systeme mais comme ça marche pas sous jabber... )
* Les imprimantes et les scanner

Alors oui je sais quant on connaît Linux on regarde avant d'acheter du matos, mais malheureusement madame Michou n'a pas le réflexe et il est trop rare de trouver du matos avec un manchot dessiné sur la boite. Et je ne parle pas des vendeurs qui nous invite a rentrer a la maison pour regarder sur internet puis a revenir

[1]
Zythom est un expert judiciaire en informatique qui tiens un blog consacré entre autre à son metier
http://zythom.blogspot.com/2008/06/trois-heures-pour-install(...)

P.S.
Oui je sais normalement on fait un commentaire dans l'autre journal mais il déborde...
  • # D'un autre côté

    Posté par  . Évalué à 10.

    Le wifi, c'est aussi merdique sous Linux que sous Windows. Je crois que c'est un problème du wifi en lui même, même si l'implémentation sous linux semble meilleure, et encore...

    Le problème sous Linux : suivant la carte, la configuration est différente. Des fois, c'est nm qui gère, d'autres c'est à la main dans le fichier de configuration réseau. J'suis perdu. Le pire c'est network manager. Non pas que c'est un mauvais outils, mais point de vue transparence, c'est légèrement opaque. Quand y'a un problème avec le WPA, où faut-il aller voir pour avoir le message d'erreur qui indique quoi faire ?

    Le problème sous Windows : des fois ça marche, des fois ça ne marche pas. Mais quand ça ne marche pas, ça ne signifie pas que 15 minutes plus tard ça ne marche toujours pas. Des fois il suffit juste de regarder le pc et d'attendre pour que cela marche. La magie. Et je ne parle pas de vista...

    Le problème du wifi : y'en a partout, tout se mélange. Ma livebox était configurée sur le channel 10. Mon linux voyait le SSID mais n'arrivait pas à se connecter (de temps en temps). Le de temps en temps correspondait à une autre livebox qui apparaissait sur le même channel mais avec un autre SSID. Rien que ça, ça m'empêchait d'avoir une connexion qui marche. J'ai changé en channel 9, et tout est allé pour le mieux. Je n'ai pas chercher à comprendre.
    • [^] # Re: D'un autre côté

      Posté par  . Évalué à 6.

      Quand y'a un problème avec le WPA, où faut-il aller voir pour avoir le message d'erreur qui indique quoi faire ?
      C'est un problème NP-complet. Le message d'erreur doit bien exister quelque part, mais on a pas encore trouvé comment le calculer...

      Plus serieusement, travaillant dans le Wi-Fi, je peux te confirmer que c'est du grand n'importe quoi. Le standard initial était déjà assez corsé, c'est devenu de plus en plus le bordel au fur et à mesure que les extensions se sont rajoutées... et le pire, c'est que plus on avance dans le temps, plus ça part complètement en vrille, par ex. le 11y ou surtout le 11n (là on va atteindre des sommets dans l'incompatibilité totale entre les fabricants, malgré la débauche de protections tordues pour tenter de sauver les meubles). Il me semble que le problème vient des différents constructeurs qui veulent chacun imposer ses fonctionnalités, et qui s'accordent sur un compris du style : on inclut tout, mais tout est optionel. Le problème doit aussi venir du fait que les gars qui rédigent le standard n'ont plus tapé une ligne de code depuis l'école, et empilent des contraintes alambiquées sans se soucier un seul instant de l'implémentation.
      • [^] # Re: D'un autre côté

        Posté par  (site Web personnel) . Évalué à 2.

        C'est un problème NP-complet. Le message d'erreur doit bien exister quelque part, mais on a pas encore trouvé comment le calculer...

        Ah non, si c'est NP-complet, ça veux dire que on sait comment le calculer !
        (et même comment le calculer en un temps polynomial sur une machine de turring non déterministe)
        • [^] # Re: D'un autre côté

          Posté par  . Évalué à 2.

          Laisse moi deviner : tu bosses à l'IEEE!

          (c'était facile, tu t'es trahi en proposant une impémentation à base de machine de Turing non déterministe)
        • [^] # Re: D'un autre côté

          Posté par  . Évalué à 2.

          "une machine de turring non déterministe"
          Une machine sous Windows Vista ?
          ---> []
    • [^] # Re: D'un autre côté

      Posté par  . Évalué à 8.

      Sous Linux, le problème pour M'sieur Toutl'monde ne me paraît pas forcément tant être networkmanager que les drivers dont beaucoup sont encore très jeunes...

      La nouvelle pile wifi n'est pas là depuis si longtemps, et pas mal de drivers libres, qui feront fonctionner nativement de plus en plus de cartes, sont encore jeunes... comme ath, par exemple. Il me semble que ce ne soit toujours pas la joie non plus avec ce qui vient de broadcom, mais les WRT54G m'ont vacciné pour un bon moment quant à réessayer de toucher à ce qui vient de chez eux, de toute façon.

      Enfin, voilà, pour moi, de ce que j'ai vu, le plus gros problème avec le wifi, sous Linux, ce sont encore les drivers, souvent encore blobés, ou avec des firmwares non distribuables, ainsi que les frameworks pour les gérer (ce que nous a apporté la nouvelle pile wifi : plus besoin que chacun réinvente complètement son WPA et cie de son côté)... M'enfin, ça y travaille moult, comme partout dans le libre, aussi bien chez OpenBSD qui commence à implémenter WPA (PSK seulement, pour l'instant... pas que ce soit plus sékioure que du VPN, mais de quoi faire du VPN n'est pas embarqué partout, pas plus que tout ce qui a une antenne n'a un port ethernet sur lequel se rabattre), ou FreeBSD (qui commence à introduire des fonctions bougrement intéressantes, comme les VAP avec les drivers libres, pour faire plusieurs points d'accès distincts sur une seule carte, ou ce qu'il est possible de supporter dans 802.11n, même s'il n'y a pas encore de pilote pour ça... vivement la 7.1 ou la 8.0, d'ailleurs : ô oui : vivement ! Je vois bien un petit gros routeur/gateway/firewall/AP/... sous FreeBSD, que je découvre agréablement ces temps-ci, après avoir essayé d'autres Linux que de la Debian, et être promptement revenu aux sources, chez moi).




      Après, certes : network-manager est très jeune aussi... il ne permet même pas de gérer les adresses statiques - je crois que ça doit venir pour la 7.0 qui devrait sortir bientôt, et qui je crois même à été pré-intégrée dans suse... D'ailleurs, c'est pour ça que je ne m'en sers pas encore, préférant une tambouille-maison à base de /etc/network/interfaces, de ifplugd pour le roaming, avec IP fixe pour chez moi, et de mignoneries geekesques dans le genre...

      Maintenant, pour ce qui est des connexions faisant intervenir DHCP, ça marche plutôt pas mal depuis un moment. En tout cas sur ma Sid, dans "/usr/share/doc/network-manager/README.Debian", on peut lire (traduction libre) :

      "Seuls les périphériques *non* listés dans /etc/network/interfaces ou qui y ont été configurés avec "auto" et "dhcp" (avec aucune autre option) sont gérés par NM.

      Ainsi, vous pouvez définir une configuration personnalisée (statique) pour un périphérique, et NM n'essaiera pas de passer outre ce réglage."

      Et honnêtement, c'est exactement comme ça qu'il se comporte sur ma machine : "DHCP et auto dans le "interfaces" ou "pas configuré dans le interfaces", c'est lui qui gère, sinon, c'est à la mimine de bout en bout. Bon, après, je ne sais pas si ça marche comme ça partout - mais au moins, sur mon laptop, quand je m'en sers, surtout pour tester, je sais exactement quand c'est lui, et quand c'est moi, qui gère... et sinon, il me semble aussi être tombé sur un /var/log/NetworkManager.log ou quelque chose comme ça sur une Fedora ou une Suse (je ne sais plus très bien), pour debuguer ; mais après, je l'ai dit : je ne touche pas du NM tous les jours, donc je ne garantis rien...

      Cela dit, je suis bien tenté par l'essai de la 0.7, avec les IP fixes... le module VPN me tente également... s'il pouvait reconnaître les réseaux sur lesquels il est (avec du ping sur une adresse, ou une connexion à une certaine adresse MAC, à la ifplugd), et qu'on pouvait lancer des pre/post-up/down (peut-être que c'est déjà possible, en fait... je ne le connais pas assez pour ça, le manque d'adresses fixes me faisant trop défaut ), je m'en servirais vraiment en remplacement de mes scripts de barbu, et sans le moindre remord.




      Nonobstant, sorti de ça, pour revenir sur les 3h pour installer un linux, je ne vois pas en quoi ça justifierait de nous forcer à acheter une licence de ouin-ouin. Ca veut dire quoi, ça ? Que si ce n'est pas accessible à un expert quelconque, ça impliquerait forcément que je suis trop con pour avoir le droit de m'en contenter ou d'essayer ? Et comme je serais irrévocablement, unilatéralement, forcément un con, il serait bien normal qu'on décide à ma place ce qui est bon pour moi, et que je me fasse mettre en étant forcé d'acheter un truc que, en l'occurence, pourtant, je n'utiliserai pas (j'interprète ce qu'ils disent, hein... je ne vois pas de problème à ne pas savoir, ou à ne pas vouloir savoir ; mais le message de darty me paraît clairement être du tonneau de "t'es trop con, de toute façon : mange tmon foin") ? Eh bien... Qu'est-ce que ce serait si ce n'était pas dans mon intérêt ?
  • # Matériel supporté

    Posté par  . Évalué à 9.

    Pour moi le message est clair : aucune étape de l'installation ne pose plus aucun problème, contrairement à il y a seulement quelques années où répondre à certaines questions pour faire des choix propres au système n'était pas toujours trivial :) Aux constructeurs encore en retard de faire un pas dans la bonne direction maintenant.
    • [^] # Re: Matériel supporté

      Posté par  . Évalué à 2.

      on parle tout de même d'une techno qui s'est démocratisé depuis 5ans au moins...

      Mais remercions le "buzz" Linux, la décrépitude d'XP, le ramassage de VISTA, pour qu'un utilisateur lambda fasse fi de ces petites contraintes sous linux... y a 2ans, ça n'aurait pas été possible.
      • [^] # Re: Matériel supporté

        Posté par  . Évalué à -2.

        Ah mais les trucs rigolos sous Linux il y en a d'autres, un qui me revient regulierement (Ubuntu 8.04 serveur) :

        Tu demarres le systeme sans cable reseau branche, la machine a fini de booter, tu branches ton cable, une minute passe, pas d'addresse DHCP...

        Super. Perso j'ai regle ca facilement (un petit /etc/init.d/networking stop et start a la sauvage), ma grand-mere elle aura plus de mal par contre... J'ai un mal fou a comprendre le pourquoi de cela, c'est pourtant une situation 'banale'.
        • [^] # Re: Matériel supporté

          Posté par  . Évalué à 3.

          En même temps, ta grand-mère installe des versions serveurs de Linux ?

          Ou c'est toi qui lui fais, pour avoir un truc aux oignons (j'installe et maintient bien de la Debian stable sur le PC de ma mère), mais tu ne fais le boulot de fignolage qu'à moitié ?



          Non, parce que les pages de manuel, ça existe, et ça explique plutôt bien... genre "man interfaces", où on peut apprendre qu'une interface en auto (gérée par le ifup, donc entre autres par les scripts de démarrage), ce n'est pas la même chose qu'une interface qui autorise le hotplug (bon, là, faut aller à la page de manuel de ifup, qui indique que l'on peut faire ça avec hotplug, déprécié maintenant, et ifplugd, ce qu'il est conseillé d'utiliser)...



          Maintenant, est-ce qu'un serveur en DHCP qui autorise le branchage à chaud est vraiment ce qu'on rencontre le plus quand on installe un serveur ? Bof, j'aurais plutôt tendance à mettre un serveur en IP fixe quand c'est possible (ça n'engage que moi), et à tout inspecter minutieusement si j'y activais des services comme DHCP (et donc, à activer encore un truc en plus si je voulais le hotplug par DHCP), ou du OSPF que j'ai bien envie de tester sur des OpenVZ (je suis curieux de savoir comment se comporterait un quagga, ou assimilé, dans un conteneur, qui servirait de gateway physique à la machine)...

          ... et de même, pour ta grand-mère... si tu ne veux vraiment pas te saouler, tu lui proposes un truc qui embarque NM, et qui va se contenter de choper un bail DHCP (tant que la version 0.7 n'est pas sortie), tout seul, et gérer le hotplug, tout seul, sans rien configurer comme un barbu, vu qu'il ne s'occupe que des cartes non gérées par le /etc/network/interfaces (ou qui y sont en auto et DHCP)...

          Bon, pour ne pas être de mauvaise foi, je veux bien qu'on puisse regretter qu'à partir du moment où DHCP est activé, ifplugd et consorts ne le soient pas... c'est vrai que c'est un comportement auquel on pourrait s'attendre ; sauf que ça ajoute encore à gérer un truc (bazar, cathédrale, tout-ça) : le nommé ifplugd, ou networkmanager... Et après,lequel forcerait-on à utiliser par défaut (j'ai un peu de mal avec l'idée de NM sur un serveur... déjà que dhcp et ifplugd, bof) ? Est-ce que des gens se servent de DHCP sans hotplug ? ... c'est entre autres pour éviter d'avoir à me poser la question que je n'utilise pas de DHCP pour mes serveurs (et en pratique, d'ailleurs, nulle part chez moi) : toujours un truc de moins à gérer (et deux, d'ailleurs, avec le hotplug) - moins de bazar.
          • [^] # Re: Matériel supporté

            Posté par  . Évalué à 1.

            Maintenant, est-ce qu'un serveur en DHCP qui autorise le branchage à chaud est vraiment ce qu'on rencontre le plus quand on installe un serveur ? Bof, j'aurais plutôt tendance à mettre un serveur en IP fixe quand c'est possible (ça n'engage que moi), et à tout inspecter minutieusement si j'y activais des services comme DHCP (et donc, à activer encore un truc en plus si je voulais le hotplug par DHCP), ou du OSPF que j'ai bien envie de tester sur des OpenVZ (je suis curieux de savoir comment se comporterait un quagga, ou assimilé, dans un conteneur, qui servirait de gateway physique à la machine)...

            Je veux bien qu'un serveur n'ait pas besoin de DHCP, mais serieusement, du point de vue de l'utilisateur(parce que les versions serveur, elles sont utilisees par des developpeurs, etc...) c'est un bordel, chez lui ca marche, ici ca marche pas, c'est pourtant le meme OS, mais on a prefere enlever un comportement bien utile pour sauver x kilo-octets, qui n'auront honnetement quasiment aucun impact sur le systeme, et on emmerde l'utilisateur.
            Sans parler de l'impact sur le developpement, tu t'amuses comment a developper/tester tes softs avec des differences pareilles de comportement entre distribs et "variantes" d'une meme distrib ? Vive la complexite du code.
            • [^] # Re: Matériel supporté

              Posté par  . Évalué à 7.

              Attends ; tu veux une distrib "serveur" (à compter qu'on parle de la même chose : un truc qui t'installe une base minimale, à partir de laquelle tu te construis le système qui te plaît - typiquement, une Debian en netinstall sans rien rajouter, ou une Gentoo avec le livecd minimal en suivant le guide officiel)... si c'est pour les mêmes raisons que c'est ce que j'utilise, faut assumer au moins deux secondes : ton lego ne te convient pas ? Tu n'as qu'à retrousser tes manches, gougler, manner, expérimenter et apprendre - sinon, tu aurais pris un playmobil. Chacun sont truc : perso, l'une des raisons qui font que je pars toujours d'une base minimale, c'est que je trouve ça plus facile à maîtriser (il faut que je comprenne pour maîtriser ; que ça juste-marche ne me suffit pas), et que le premier à qui j'ai à m'en prendre si ce que je rajoute par-dessus ne me convient pas, c'est moi - ça m'incite à me bouger plutôt qu'à gueuler sur les autres...

              D'autant que ce que tu veux existe : si tu te contentes de DHCP (pour l'instant... m'enfin, ça, au moins, ça couvre les besoins de l'utilisateur Lambda qui n'y connait rien en réseau, et qui a déjà eu du mal à faire fonctionner sa box fai qu'il n'a pourtant qu'à brancher), tu as NM, dispo par défaut dans, je pense, toutes les distros en mode click-click-suivant, et installable sur toutes les autres ; si tu veux te faire ta tambouille parce que tu es un gros geek qui alterne entre les réseaux DHCP, les IP fixes, qui veut que du NFS soit monté ici mais pas là, qui branche et débranche câbles et antennes à tour de bras en dansant nu et en sacrifiant un capriné, et cie, tu as les pre/post-up/down, ifplugd, guessnet et cie (mais il faudra suer un minimum de sang et d'eau... ce qui n'est pas grave, partant du postulat que tu es un gros geek si tu fais ça, puisque sinon, tu aurais NM)...

              Maintenant, autant je veux bien admettre que le DHCP sans gestion du hotplug, ça me paraît un peu ballot, autant devoir se trimballer ifplugd et/ou consorts dans les paquets d'une base minimale, ça ne me tente pas trop... déjà que le tag en "important" de dhcp3-client dans Debian me paraît limite (je le verrais davantage en "standard"), s'il faut commencer à en bouffer encore plus, pour considérer que le roaming, où on se branche et se débranche à foison, est un cas par défaut, qu'il faut intégrer dans la base, quitte à la bloater et à se retrouver avec des serveurs qui embarquent NM... parce que bon, NM, quand il sera davantage fini, il sera assez ultime, je pense, dans le genre - maintenant, paye tes dépendances. Non, à choisir, j'éjecte le client DHCP de la base minimale.
              • [^] # Re: Matériel supporté

                Posté par  . Évalué à -1.

                Ben si tu es developpeur tu fais quoi ? Tu installes la desktop pour neuneu, la serveur pour gars qui a du temps a tout paufiner ou il y a une Ubuntu Hacker 8.04 qui est faite pour eux avec GCC, etc... installes d'office et KDevelop qui se lance au demarrage ? Moi j'ai pris la serveur car je ne veux pas tout le bordel qui vient avec la version neuneu, mais je me disais qu'il ne me demanderait pas de faire la moitie du boulot moi meme.

                Je comprends le besoin de mettre un minimum, mais il y a des trucs ou honnetement c'est trop, celui la c'est typiquement le cas de mon point de vue, niveau ressources ca ne bouffe quasiment rien, ca rend service a quasiment tout le monde, aucun danger en vue, ...

                Sans parler du mal de crane pour les developpeurs qui ont le malheur de dependre de ce genre de trucs, il leur faut ajouter dans leur soft(installer, code lui-meme, ... ou c'est necessaire bref) le code necessaire pour gerer les cas ou tel truc est present sur une distrib mais pas l'autre, etc...

                Il y a un minimum qui devrait etre standard a travers toutes les distrib(LSB quoi) et cela devrait en faire partie de mon point de vue. Je comprends qu'une distrib serveur n'ait pas d'UI, mais qu'elle ne gere pas le debranchement d'un cable reseau, c'est exagere.
                • [^] # Re: Matériel supporté

                  Posté par  . Évalué à 2.

                  > ca rend service a quasiment tout le monde

                  Bah non... moi, le client dhcp dans la base minimale, il me saoule...

                  La base minimale, sous Debian, ce sont les paquets taggués en "required" et en "important" (aptitude search ~prequired ~pimportant) - c'est ce qu'on obtient par défaut en debootstrapant ; or debootstraper, ça sert typiquement à chrooter ou à créer un conteneur (OpenVZ, VServer, ...), et je ne vois déjà pas l'intérêt d'y avoir un client DHCP. Et encore moins un truc qui va tester si une interface tout ce qu'il y a de plus virtuelle est branchée (si ça a un sens)...

                  Maintenant, quand on installe via netinstall, si on ne déselectionne rien (enfin, je parle en mode "expert"... je ne me souviens plus de si on nous le demande ou pas par défaut), les paquets taggués en "standard" (aptitude search ~pstandard) sont installés - et je verrais allègrement plus le client DHCP là-dedans. Après, à la limite, je veux bien que ifplugd puisse y être à sa place aussi. Ce qui est vraiment une base minimale, ça se discute encore (si on y inclue les "standard" ou pas, voire les "important" ou pas, pour le debootstrap de Lenny, qui le permet - mais là, c'est couillu : même pas d'aptitude, juste dpkg, par exemple).

                  Si tu veux vraiment savoir pourquoi ça n'y est pas, ou si tu estimes que c'est un bug, rien ne t'empêche de le signaler - si le mainteneur est de ton avis, ou pas, tu pourras en discuter avec lui. Sauf que comme les paquets "standard" sont installés par défaut si on ne spécifie pas explicitement le contraire, faudra te montrer convaincant, chasse-au-bloat-inside ; cela dit, les dépendances de ifplugd ne sont pas monstrueuses : tu sais ce qu'il te reste à faire, si tu veux être plus constructif qu'en vociférant...
                  • [^] # Re: Matériel supporté

                    Posté par  . Évalué à 1.

                    J'appelles pas ca un bug, c'est une decision prise de maniere volontaire, que je consideres personnellement comme mauvaise. J'ai pas forcement envie d'aller expliquer a Debian comment faire leurs distribs non plus, c'est la leur et ils font comme ils veulent.
                • [^] # Re: Matériel supporté

                  Posté par  . Évalué à 2.

                  Pourquoi tu veux une Ubuntu server pour faire du développement ?
                  Tu prends une Slackware et t'as un Linux qui bouffe peu de RAM (150 Mo chez moi avec Xfce/Kazehakase/Xfmedia/Claws-mail) et où les paquets incluent d'office les en-têtes/fichiers .pc/etc. .
                  Et t'as gagné une pile de scripts de configuration faisant appel à dialog .
                  Et si tu veux un bureau déjà configuré à ta place t'as Zenwalk .
                  • [^] # Re: Matériel supporté

                    Posté par  . Évalué à 0.

                    Pourquoi ? Parce que je veux utiliser la plateforme sur laquelle le soft final est sense tourner tout simplement.
                    • [^] # Re: Matériel supporté

                      Posté par  . Évalué à 2.

                      Et c'est pour ça que tu en charcles 80% (sûrement plus, même... un bootstrap de Debian, c'est dans les 120Mio, ou 50Mio en tar.gz... bon, je ne connais pas plus que ça la distro dérivée, et encore moins en version serveur, mais j'imagine quand même que ça doit être relativement sans trop de sucre), en prenant une version extrêmement allégée, notamment, sans le NM qui te fait tant défaut ?

                      Les distros peuvent parfois faire des choix discutables, ce n'est toujours pas la cohérence qui t'étouffe non plus...
  • # Une solution ? Le driver aléatoire !

    Posté par  . Évalué à 10.

    La rapidité des processeurs s'améliorant et la capacité des DD augmentant, la technologie des drivers aléatoires me paraît mûre pour une utilisation mainstream. En effet, un driver étant généralement petit, il suffirait d'essayer toute les possibilités mathématique de fichiers jusqu'à ce que le wifi marche. C'est-y pas beau ?

    Et vous voulez savoir le mieux dans tout ça ? C'est généralisable au reste des drivers ! Voilà qui devrait, en remplaçant l'ensemble des drivers noyaux par un petit script bash écrit en deux minutes montre en mains, grandement améliorer la compatibilité et la petitesse du noyau. \o/

    De rien.
    • [^] # Re: Une solution ? Le driver aléatoire !

      Posté par  . Évalué à 9.

      Je viens de mettre en place ta solution et ça
    • [^] # Re: Une solution ? Le driver aléatoire !

      Posté par  . Évalué à 4.

      « Tu fais quoi ? du bruteforce d'une clé SSH ? un cassage de la clé AES256 ? »
      « Non, non, j'écris un driver pour ma carte réseau »
    • [^] # Re: Une solution ? Le driver aléatoire !

      Posté par  . Évalué à 0.

      Questions naive mais ça marche comment ton driver aleatoire et plus généralement un driver ?

      Je me souvient d'une époque pas si lointaine ou il fallait aller à la pince a épiler pour regler les valeurs des IRQ ( c'est d'ailleur à ça qu'on reconnait un vrai geek il possede une pince a épilé :p )
      Si je comprend bien l'idée c'est de parler avec un protocole wifi a toute les irq jusqu' a trouver la bonne ( je croyais honetement que c'était le principe du plug and play)

      Et surtout est ce que tu peux faire d'entrer un truc pour tout les matos ? j'imagine qu'il faut tout de même savoir exactement ce qui rentre et sort du matos non ?
    • [^] # Re: Une solution ? Le driver aléatoire !

      Posté par  . Évalué à 1.

      Sauf que rien que pour un driver de 1 Ko ça correspond à 1024 nombres de 0 à 255 .
      Il y a donc 256^1024=2^8192=beaucoup trop de fichiers de 1Ko différents .
      Bien sûr, on peut attendre 12288 ans (ou un peu moins) pour faire appliquer la loi de Moore mais c'est trop long .
  • # Darty

    Posté par  (site Web personnel) . Évalué à 7.

    Dans le cas de l'affaire Darty, la seule chose qui est démontrée c'est qu'un driver out-of-the-box Windows existait, et pas un driver Linux out-of-the-box.

    Dans un cas équivalent sous Windows, le driver n'aurait pas été fourni et l'installation de Windows aurait pris un temps infini.

    Bref, test "Linux" bidon, à armes inégales, aucune démarche "scientifique" (une démarche scientifique aurait été d'installer Windows out-of-the-box aussi, et je suis prêt à parier que dans ce cas pas de driver Wifi qui va bien...) juste pour critiquer Linux. une démarche scientifique aurait été de dire que comme il n'existe pas de driver Linux, on n'utilise pas les drivers dans les deux cas pour parler de l'OS...
    • [^] # Re: Darty

      Posté par  . Évalué à 6.

      D'un autre côté, le but de l'expertise n'était justement pas de comparer l'installation de windows à celle de Linux, mais plutôt de voir si "on" pouvait "facilement" installer Linux. Il s'agissait de comparer l'installation de Linux à une pré-installation de windows, pour que le juge puisse décider si la demande de séparation des deux était justifiable ou pas.

      La conclusion du test est triste vu la décision qu'elle a amené le juge à prendre, mais il ne s'agit aucunement d'une comparaison des deux OS : il est bien entendu évident qu'un windows préinstallé se doit de marcher parfaitement au niveau matériel (le fabricant n'est pas idiot), et qu'installer un OS l'expose à marcher moins bien (forcément ; de façon identique, au mieux) qu'un OS préinstallé (pour lequel le fabricant se sera assuré que tout marche bien).

      D'un point de vue purement scientifique, la seule chose que démontre le test en fait, c'est qu'un matériel sans fil (bizarre) est moins bien détecté à l'installation d'une distribution que par un OS préinstallé. Manque de chance, ce n'est pas le cas général, c'est dommage que l'étude ne se soit pas attachée à d'autres configurations.
      • [^] # Re: Darty

        Posté par  . Évalué à 3.

        ce qu'on ne compte pas, c'est la stabilité générale des distributions Linux sur le long terme ; pendant ce temps, sous Windows, il faut : dévirusser, defragmenter, ergoter pour faire sortir des logiciels installés. Le quotidien sous Windows fini par être un enfert pendant que nous vivons un long fleuve tranquille sur les OS libres.

        PS: j'ai quand meme du réinstaller mon linux dont je tairais le nom, un peu par flemme. Il y avait des difficultés techniques : soucis d'hibernation si mes souvenirs sont bons et d'autres petits trucs un peu genants. Mais souvent mes installations Linux tiennent facilement les 6 mois. Pendant ce temps, le PC "des enfants" sous Windows ne tient pas si bien. En général je n'y touche pas, le moins possible. C'est bien la vocation de l'OS que de gerer la stabilité des fonctions. Actuellement c'est la souris qui bloq...
        • [^] # Re: Darty

          Posté par  (site Web personnel) . Évalué à 6.

          Mais souvent mes installations Linux tiennent facilement les 6 mois.

          Perso, c'est plutôt 6 ans qu'elles tiennent mes installations...
  • # Et bien il faudrait

    Posté par  (site Web personnel) . Évalué à 5.

    que je fasse appel à cet expert. J'ai passé bien plus de temps que 2h20 et j'ai toujours pas de WPA.
    • [^] # Re: Et bien il faudrait

      Posté par  . Évalué à 1.

      Je ne sais pas quelle carte tu as mais l'envie m'a pris de profiter du soleil et ca m'a pris 5 minutes pour me connecter.

      1. Installation des pilotes avec apt-get
      2. Installation du network-manager
      3. Ajout de mon compte utilisateur dans le group netdev pour les permissions (après 2 minutes de recherche sur google).
      4. Ajout d'un nouveau profil dans le network manager.
      5. Connexion, et surf ;-)

      J'ai une carte intel 4965 AG intégrée au portable. Le réseau est en AES avec une PSK.
      Je suppose que toutes les joyeusetées fonctionnant avec EAP doivent fonctionner également, en tout cas au pire avec wpa_supplicant.

      Alors bien entendu, tout dépend de son chipset, mais là, le problème se retrouve sur tous les OS!
      • [^] # Re: Et bien il faudrait

        Posté par  . Évalué à 3.

        5 minutes, ça laisse rêveur.

        J'ai bien eu au moins 4 ou 5 chipsets wifi sous la patte et un seul ne m'a pas posé problème, c'était le bon vieux Atheros AR5212 de mon thinkpad de 2003, sinon, rien, walou, keudalle.

        Le fameux ipw3945 qui ne se connecte pas aux AP cachés et au fonctionnement aléatoire, son projet libre WLWIFI qui ne supporte pas une mise en veille et qui met une plombe à scanner, mon AR5007eg reconnu comme un AR5006eg ne fonctionne pas en 64bits, la broadcom de mon dell D600 qui ne fonctionne pas sans bidouille ndiswrapperiesques...

        A cela, rajouter des scriptes de connexion à la main car, ça ne marche jamais avec NetworkManager qui est lui même incomplet et donc, peau de zobe pour l'utilisateur lambda

        Bref, le sans-fil, ce n'est pas sans soucis et malheureusement avec la démocratisation du matos aérien, ça devient vite fâcheux.

        J'ai connu de long moment de frustration en essayant de fournir un système complet à un utilisateur débutant mais quand je vois la qualité de l'ensemble (OS-Support), je peux encore accèpter de ruiner mon capital capillaire pour ces bricoles.
      • [^] # Re: Et bien il faudrait

        Posté par  . Évalué à 1.

        "1. Installation des pilotes avec apt-get"
        Et donc tu télécharges les pilotes qui te permettent d'aller sur le net ?
        C'est aussi bien que Windows : après tout sous Windows il suffit de double-cliquer sur l'icône du CD-ROM d'installation pour installer la souris ;)
        ~~~~~~~~~~~~~~~~~> []
    • [^] # Re: Et bien il faudrait

      Posté par  (site Web personnel) . Évalué à 1.

      Pour moi, au moins deux semaines. Surtout que le problème ne venait pas des drivers, mais de udev. Encore fallait-il le savoir...
  • # L'oeuf ou la poule ?

    Posté par  . Évalué à 5.

    Bon, je vais essayer de me calmer, mais : les install de linux ne pourrons jamais être aussi "faciles" qu'un OS préinstallé tant que cet OS préinstallé aura le monopole ! Et cette plainte a justement été déposée pour casser ce monopole ! Franchement, ils font exprès de ne pas comprendre ?

    Et le coup de la désinstallation d'applis qui pose des problèmes de stabilité (pour windows, hein), ça me donne vachement une bonne impression sur ces "experts" ...
    • [^] # Re: L'oeuf ou la poule ?

      Posté par  (site Web personnel) . Évalué à 5.

      Et pour être rigoureux on peut considérer les ordis avec Linux préinstallé... Le Dell XPS M1330 par exemple, certes il est préinstallé avec une Ubuntu 7.10 et le driver wifi avec le blob proprio, et LinDVD proprio aussi... mais ça fonctionne au déballage.
    • [^] # Re: L'oeuf ou la poule ?

      Posté par  . Évalué à 2.

      Tu ne dissocies pas l'installation de la configuration visiblement.

      N'importe qui peut installer un linux et à partir du moment où il est connecté filairement, il est opérationnel 2heures avant le premier accès au bureau VISTA/XP.
  • # Ca marche, ça marche plus

    Posté par  (site Web personnel) . Évalué à 2.

    Le plus pénible, c'est quand ça marche plus, après quelques années de loyaux services.
    Je me suis aperçut récemment que mon imprimante ne marchait plus. Et oui, des modifications dans les paquets Debian ont tout foutu par terre, et impossible de trouver où ça coince. Même après réinstallation propre, tests d'anciennes versions... Pour ce type de problème qui arrive de temps en temps, Linux commence à me les briser menues, pour parler franchement. J'aimerai bien un truc qui "juste marche" ou avec le minimum de maintenance. Avant, ça m'amusait. Plus maintenant. Pour moi, deux solutions : Debian stable au lieu de testing ou carrément Windows.
    • [^] # Re: Ca marche, ça marche plus

      Posté par  . Évalué à 2.

      Moé avant de t'exciter à dire Debian ou Windows, test avant le juste milieu genre OpenSuSe ou Fedora. Enfin je dis ça je dis rien :)
      • [^] # Re: Ca marche, ça marche plus

        Posté par  (site Web personnel) . Évalué à 1.

        A l'époque où j'avais testé "Redhat" et "Mandrake" (c'est vieux , vu les noms), j'ai constaté des liens vers des programmes sur le bureau qui ne marchaient pas alors que ça venait d'être installé, et d'autres trucs bancals. Je me suis dit, en caricaturant, "Sympa, pas de finition correcte, adieux" et j'ai découvert Debian, où il y a moins de mauvaises surprises. C'est pour ça que je pense à une stable, mais j'ai peur d'un manque de paquet par rapport à la testing. Et avec Ubuntu, j'ai peur de retrouver la finition Redhat ci-dessus. J'avoue, c'est l'énervement qui m'a fait dire Windows. Mais je préfère faire autre chose de mes soirées que de faire marcher mon imprimante...
    • [^] # Re: Ca marche, ça marche plus

      Posté par  . Évalué à 2.

      ... ou Debian stable en plus d'autres choses... testing, ça veut dire ce que ça veut dire : ça peut casser - même si en général, je n'ai rien vu de bien méchant, pour qui a l'habitude de mettre les mains dans le camboui... le plus ennuyeux sous testing, c'est l'évacuation ,fut-ce temporaire, de paquets dont la version de stable ne peut plus convenir, mais dont la version unstable n'est pas encore releasable...

      Après, si tu peux te permettre d'avoir une machine en plus pour faire un serveur, et y mettre ce qui ne doit pas casser, c'est quand même top...

      Avec une Debian stable ou autres distros qui ne bougent pas pendant une longue période (selon ses affinités), voire, avec des conteneurs (mes deux Cups, encre et laser, en Debian stable, sont sur un hôte vserver, en Debian stable aussi, aux "côtés" de mythtv, de slimserver, de sane, d'un SSHd qui sert à faire du SSHFS et d'un NFS userland... et c'est tellement stable que j'ai envie de le secouer pour passer tout ça sous openvz que je découvre et dont je trouve la virtualisation réseau et la migration en live d'un invité super cools), ça permet d'avoir une base très stable, et de faire ses conneries ailleurs (toutes mes workstations sont en sid, en ce moment, pour diverses raisons... et ça me va très bien)...
      • [^] # Re: Ca marche, ça marche plus

        Posté par  (site Web personnel) . Évalué à 2.

        Il me semblait que c'était les dépendances des paquets qui était "testing".
        Sinon, ton post est intéressant : J'ai un serveur sous stable qui tourne un fois par mois (notamment pour les sauvegardes via rsync), je n'ai pas pensé passer par lui pour cups, et la virtualisation (et cie) je n'y avait pas pensé comme ça. En plus, je doit avoir une vielle sid chrootée dans un coin que j'avais installée pour faire du dev gnome (mais j'ai comme toujours eu pleins d'erreurs de compil, j'ai laissé tomber au bout de quelques dizaines d'heures sur le sujet).
        Juste un truc pas très clair : pour vserver et openvz, le cpu doit supporter la virtualisation ou pas ? Comme j'ai un vieux cpu...
        • [^] # Re: Ca marche, ça marche plus

          Posté par  . Évalué à 4.

          > Il me semblait que c'était les dépendances des paquets qui était "testing".

          Hmmm... je ne vois pas trop ce que tu veux dire...

          Sous Debian, en tout cas :

          - stable ne bouge pas, à part pour les bugs critiques, la sécu, et récemment pour les paquets volatiles (nouveau sous-dépôt permettant par exemple d'avoir des bases clamav à jour) ;
          - unstable bouge tout le temps (et je la trouve vraiment "stable" pour quelque chose du genre - NB les guillemets à "stable");
          - testing bouge quand ça n'introduit pas plus de bugs critiques que le paquet qui existe dans stable et que ses dépendances ont migré ou migrent en même temps, ou quand le maintien d'un paquet dans testing provoquerait des problèmes de dépendances... auquel dernier cas, le paquet est (a priori temporairement) éjecté, comme ça a longtemps été le cas avec VLC, comme ça l'est encore pour Ardour, ou comme ça l'était il y a environ une semaine, pour gtk-qt-engine ; et personnellement, je trouve que c'est le plus saoulant dans testing (même si ça se comprend bien), et c'est d'ailleurs ce qui me fait utiliser des Sid.



          > Juste un truc pas très clair : pour vserver et openvz, le cpu doit supporter la virtualisation ou pas ? Comme j'ai un vieux cpu...

          Ca, c'est l'intérêt principal, pour moi : mes serveurs sont des Athlon XP de récup, sans moult RAM (512Mo max), et sans instructions spécifiques à la virtualisation...

          ... et c'est bien pour ça que j'utilise VServer (depuis 6 mois, sans le moindre soucis : rock-stable de chez rock-stable... et pourtant, j'y fais fonctionner de l'imprimante et du scanner USB, ainsi que des cartes TV, ce qui suppose un peu de configuration pour que les conteneurs y aient accès - ie démasquage de périphs, voire ajout de gestion de capacités du noyau au conteneur), et que je me suis mis récemment à tester OpenVZ (jusqu'ici, dans un Qemu, qui me permet déjà de m'amuser avec la virtualisation complète du réseau, ce qui est excellent, puisqu'il semble vraiment qu'on puisse tout faire comme dans un vrai, plutôt que la simple isolation qui passe par le loopback, comme dans VServer).

          Autre intérêt de taille, ne pas avoir à se saouler avec du CFS et cie pour partager des données entre les conteneurs : un bind mount (pas encore de possibilité de les faire en read-only, sous Etch, puisque je crois que c'est arrivé avec le kernel 2.6.24 ou 2.6.25), et zou : le conteneur à accès aux données que l'on veut.

          Par contre, pas de choses comme des serveurs NFS en plein kernel (de toute façon, l'hôte a plutôt intérêt à être minimal) - ce qui n'empêche pas d'utiliser un serveur NFS en userland, dans un conteneur, s'il est suffisant, selon l'utilisation (ce qui tombe bien : c'est mon cas ;) ).

          VServer est officiellement supporté par Debian (les paquets binaires du kernel patché et les outils sont dispos dans les dépôts officiels) - par contre, la doc est parfois un peu dure à trouver.

          OpenVZ est maintenu par ceux qui font Virtuozzo (ils fournissent un miroir Debian avec les kernels binaires et les outils qui vont bien, même si les sources du patch et quelques outils existent déjà dans Debian) - le wiki est prolifique (pas forcément trop orienté Debian, puisqu'ils se concentrent sur les distros à RPM... m'enfin, ça ne change pas grand chose), le forum assez vivant : bref, là par contre, niveau doc, ça me paraît mieux. Niveau fonctionnalités (quotas, virtualisation et non simple isolaton du réseau, avec des possbilités de fous [pour moi, jusqu'ici utilisateur de VServer], comme d'avoir accès au broadcast dans le conteneur, de l'interface réseau physiquement gérée par le conteneur sans même que l'hôte n'y ait accès, bridging et routage avancés, conteneur pouvant être bridgé et écouter en promiscuous, par exemple, pour y mettre une sonde d'IDS, IPv6 [apparemment], iptables dans le conteneur, migration de conteneur sans interruption de service...) aussi... A noter qu'ils semblent plutôt travailler en bonne intelligence avec upstream, pour le kernel : pour le 2.6.26-rc1, 299 patches [1] sur les quelques 7500 de la release-candidate [2], soit environ 4% des patches upstream commités par l'équipe d'OpenVZ, essentiellement sur les namespaces, dans le cadre de l'intégration dans le noyau des fonctions qui lui permettront nativement d'embarquer de quoi compartimenter. Voilà qui mérite un "Kudos, OpenVZ ! Kudos !". Si toutes les boîtes qui bénéficient du libre, quand bien même elles proposent un truc proprio à côté, faisaient comme eux...

          Si on n'a pas besoin de faire tourner des kernels différents, voire pire, si on ne peut pas le faire en accélérant matériellement (ce qui est faisable, mais lourd), et si on n'a pas trop de RAM à dépenser dans de la virtualisation complète, les conteneurs, c'est de la bombe : mangez-en ! Faudrait d'ailleurs que je fasse un journal quand j'aurai installé de l'OpenVZ sur des serveurs physiques, parce qu'aussi excellent qu'il ait l'air, niveau infos/publicité/... sur DLFP, c'est maigre [3].

          [1] http://community.livejournal.com/openvz/22369.html
          [2] http://kerneltrap.org/node/16101
          [3] http://www.google.fr/custom?cof=AH%3Acenter%3BLP%3A1%3BLW%3A(...)
  • # Hein ?!

    Posté par  . Évalué à 2.

    > les experts

    Quels experts ? J'ai lu le site de Zythom et il semble évoqué un autre rapport, mais en recherchant, on trouve rien;
    On tombe directement sur le "3h d'installation" (je parle pas du dernier post, mais du premier)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.