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...
Journal [Darty] Putain de wifi
30
juin
2008
# D'un autre côté
Posté par Matthieu . Évalué à 10.
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 calandoa . Évalué à 6.
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 Gof (site web personnel) . Évalué à 2.
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 calandoa . Évalué à 2.
(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 FreeB5D . Évalué à 2.
Une machine sous Windows Vista ?
---> []
[^] # Re: D'un autre côté
Posté par Aefron . Évalué à 8.
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 Cyberdivad . Évalué à 9.
[^] # Re: Matériel supporté
Posté par NickNolte . Évalué à 2.
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 pasBill pasGates . Évalué à -2.
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 Aefron . Évalué à 3.
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 pasBill pasGates . Évalué à 1.
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 Aefron . Évalué à 7.
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 pasBill pasGates . Évalué à -1.
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 Aefron . Évalué à 2.
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 pasBill pasGates . Évalué à 1.
[^] # Re: Matériel supporté
Posté par FreeB5D . Évalué à 2.
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 pasBill pasGates . Évalué à 0.
[^] # Re: Matériel supporté
Posté par Aefron . Évalué à 2.
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 ThelittlegamerS . Évalué à 10.
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 kowalsky . Évalué à 9.
[^] # Re: Une solution ? Le driver aléatoire !
Posté par Prae . Évalué à 4.
« Non, non, j'écris un driver pour ma carte réseau »
[^] # Re: Une solution ? Le driver aléatoire !
Posté par Mais qui suis-je ? :) . Évalué à 0.
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 Jérôme Nègre (site web personnel) . Évalué à 4.
[^] # Re: Une solution ? Le driver aléatoire !
Posté par FreeB5D . Évalué à 1.
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 Zenitram (site web personnel) . Évalué à 7.
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 khivapia . Évalué à 6.
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 Marc Quinton . Évalué à 3.
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 TeXitoi (site web personnel) . Évalué à 6.
Perso, c'est plutôt 6 ans qu'elles tiennent mes installations...
# Et bien il faudrait
Posté par Fabimaru (site web personnel) . Évalué à 5.
[^] # Re: Et bien il faudrait
Posté par oat5hd . Évalué à 1.
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 NickNolte . Évalué à 3.
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 FreeB5D . Évalué à 1.
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 Yannick (site web personnel) . Évalué à 1.
# L'oeuf ou la poule ?
Posté par benoar . Évalué à 5.
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 Sufflope (site web personnel) . Évalué à 5.
[^] # Re: L'oeuf ou la poule ?
Posté par NickNolte . Évalué à 2.
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 Yannick (site web personnel) . Évalué à 2.
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 fredix . Évalué à 2.
[^] # Re: Ca marche, ça marche plus
Posté par Yannick (site web personnel) . Évalué à 1.
[^] # Re: Ca marche, ça marche plus
Posté par fredix . Évalué à 2.
[^] # Re: Ca marche, ça marche plus
Posté par TeXitoi (site web personnel) . Évalué à 2.
stable + bpo pour les paquets récents dont tu as besoin.
http://www.backports.org/
[^] # Re: Ca marche, ça marche plus
Posté par Aefron . Évalué à 2.
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 Yannick (site web personnel) . Évalué à 2.
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 Aefron . Évalué à 4.
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 Prae . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.