Journal : [Darty] Putain de wifi
Posté par Mais qui suis-je ? :) () le 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...
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...
> Lire le journal (45 commentaires, moyenne: 3,3).
Vous avez demandé le commentaire #946024.
Run by 
Cette page a été générée par Templeet en 0.0539s (dont 0.0052 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Ca marche, ça marche plus
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
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 :)
RubyFrance
[^]Re: Ca marche, ça marche plus
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
j'avais le même profil que toi (debian rulez, testé le mandrake d'il y a 8 ans) et j'avoue que j'ai été bluffé par Fedora, aussi je te conseille de tester :)
RubyFrance
[^]Re: Ca marche, ça marche plus
C'est pour ça que je pense à une stable, mais j'ai peur d'un manque de paquet par rapport à la testing.
stable + bpo pour les paquets récents dont tu as besoin.
http://www.backports.org/
[^]Re: Ca marche, ça marche plus
... 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
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
> 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(...)