Re: Récupération de don
Le 17-09-2011, à 17:51:01 +0200, Jean-Yves F. Barbier (12u...@gmail.com) a écrit : On en est à 832 photos récupérées, c'est cool ! Plus que 3000 heures à attendre... ça n'est pas si long 125 jours, et puis tu peux te consoler en te disant que 3000 heures ça fait intellectuellement moins que 1080 secondes :) Oui mais une seconde c'est quand même moins long qu'une heure :) On en est à plus de 2900 images, ce qui représente environ les 20% du total en taille. A propos de cool, vérifie donc la température de ton HD. # hddtemp /dev/sdh /dev/sdh: Hitachi HDT721010SLA360: S.M.A.R.T. non disponible Je peux lui mettre un doigt dessus pour voir. Et si je remarque qu'elle est trop élevée, je fais quoi pour la diminuer ? Quelqu'un parlait d'une bombe à je ne sais plus quel produit..sinon, un ventilo ? s. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110918062954.ga31...@mangoo.homelinux.org
Re: Récupération de don
Le Sun, 18 Sep 2011 08:29:55 +0200, steve dl...@bluewin.ch a écrit : Le 17-09-2011, à 17:51:01 +0200, Jean-Yves F. Barbier (12u...@gmail.com) a écrit : On en est à 832 photos récupérées, c'est cool ! Plus que 3000 heures à attendre... ça n'est pas si long 125 jours, et puis tu peux te consoler en te disant que 3000 heures ça fait intellectuellement moins que 1080 secondes :) Oui mais une seconde c'est quand même moins long qu'une heure :) On en est à plus de 2900 images, ce qui représente environ les 20% du total en taille. A propos de cool, vérifie donc la température de ton HD. # hddtemp /dev/sdh /dev/sdh: Hitachi HDT721010SLA360: S.M.A.R.T. non disponible Je peux lui mettre un doigt dessus pour voir. Et si je remarque qu'elle est trop élevée, je fais quoi pour la diminuer ? Quelqu'un parlait d'une bombe à je ne sais plus quel produit..sinon, un ventilo ? s. bonjour, pour ton problème de surchauffe essaye de te procurer une plaque à décongeler et à partir de là si ce n'est pas suffisant, prend une poche à glace ... exemple : http://www.vitrinemagique.com/v/cuisine/ustensiles-cuisson/la-plaque-a-decongeler-38500-6748.html http://www.boutiquemarathon.com/accessoires-pratiques/1595-poche-de-glace-zamst-icing.html slt bernard -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110918090156.41ba05d7.bernard.schoenac...@free.fr
Xen : lenteur réseau.
Bonjour, J'ai détecté un fonctionnement très lent du réseau entre des DOMu et l'extérieur dans ma configuration. Je dispose d'un dom0 avec deux cartes réseau : eth0 (safe) est sur le réseau interne et eth1 (evil) est sur celui qui va vers internet au travers d'une neuf box. J'ai configuré (du moins c'était l'objectif) trois bridge : bri_safe pour l'interne, bri_dmz sans connexion physique et bri_evil pour l'acces internet. 6 domU sous debian sont définis : un routeur qui dispose d'un interface sur chaque bridge, un serveur web/mail dans bri_dmz et uniquement dans la dmz et les autres ne sont que dans bri_safe (sauf le serveur asterisk qui est aussi sur bri_evil). Les règles sur le routeur ont été simplifiées au maximum : il autorise tout et fait uniquement du nat depuis safe vers evil sur une adresse (eth1) est depuis dmz vers vil sur une autre adresse (eth1:0). J'ai aussi une autre machine (le vieux serveur avec firewall et squid) qui est physiquement à cheval sur le réseau interne et le réseau vers la boite internet. je constate les phénomènes suivants : - pas de problème de communication inter DomU - depuis internet (une autre boîte sfr) les connexions ssh vers le vieux serveur fonctionnent confortablement : pas de lenteur excessives dans l'écho des commandes. - depuis internet (une autre boîte sfr) les connexions ssh vers le DomU de routage fonctionnent avec beaucoup de lenteur : à l'établissement de la connexion (+ieurs secondes avec parfois des échecs de non réponse), au fonctionnement avec des temps d'attente avant d'avoir une nouvelle ligne du prompt de plusieurs secondes (par paquets de 10 ou plus). - en observant les traces réseau (tshark) sur les bridges de dom0, j'ai observé des trames qui indiques des duplication d'acquittement. - j'ai transféré squid du vieux serveur sur le routeur en domU = les temps d'accès aux pages sont très très long (plusieurs minutes pour avoir toute la page de http://mozilla-europe.org/fr/). - j'ai constaté des échecs de résolution de nom (dig www.mozilla.com) depuis le serveur dns qui est en domU sur le reseau safe. puis au bout d'un moment cela passe. Je suppose que j'ai des trames qui se perdent en interne et qui ne sortent pas ou dont les réponses ne reviennent pas à leur expéditeurs... J'en déduis que j'ai un problème dans la configuration/utilisation de xen. Mes premières recherches n'ayant pas donné de résultats, je me tourne vers la liste pour savoir si quelqu'un aurait une piste... Cordialement. -- Yann. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110918104143.6d622...@yan.ianco.homelinux.org
Re: Xen : lenteur réseau.
re-bonjour voici un exemple du problème sur l'envoi du précédent mail qui n'est pas passé du premier coup (extrait de mail.info) : Sep 18 10:38:27 www postfix/smtp[5429]: C03D32EF15: to=debian-user-french@lists.debian.org, relay=none, delay=18, delays=0.16/0.02/18/0, dsn=4.4.1, status=deferred (connect to smtp.mgp.neufgp.fr[93.17.128.85]:25: No route to host) Sep 18 10:48:21 www postfix/smtp[5457]: C03D32EF15: to=debian-user-french@lists.debian.org, relay=smtp.mgp.neufgp.fr[93.17.128.85]:25, delay=613, delays=612/0.04/0.14/0.17, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 78F1B756) ou bien fectmail qui ne trouve pas de route pour accéder au serveur pop, puis qui me les trouve les mail puisque je les lis ! Sep 18 11:49:37 www fetchmail[1231]: Connection errors for this poll:#012name 0: connection to pop.online.net:imap [88.190.253.248/143] failed: No route to host. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110918115344.0c39a...@yan.ianco.homelinux.org
Re: Xen : lenteur réseau.
Le Sunday 18 September 2011 10:41:43 Yann Cohen, vous avez écrit : Bonjour, Bonjour, [...] Je suppose que j'ai des trames qui se perdent en interne et qui ne sortent pas ou dont les réponses ne reviennent pas à leur expéditeurs... J'en déduis que j'ai un problème dans la configuration/utilisation de xen. Mes premières recherches n'ayant pas donné de résultats, je me tourne vers la liste pour savoir si quelqu'un aurait une piste... J'ai eu des symptômes similaire à une époque. Cela venait de la combinaison carte réseau/bridge. La carte prenait en charge la fonctionnalité LRO. De ce que j'ai compris, ça permet de regrouper les trames pour les envoyer ou traiter en un coup. Sauf qu'avec un bridge, les trames ne sont pas forcément destinées à la même interface (les interfaces virtuelles des VM, avec leur adresse MAC). Bref, le driver que j'utilisais avait une option pour désactiver cette fonctionnalité (disable_tpa). signature.asc Description: This is a digitally signed message part.
Re: Piratage Mysql
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 18/09/2011 01:10, Jean-Yves F. Barbier a écrit : Je rajoute de base à mauvaise analyse: quand on se retrouve avec des tables et des filtres aussi gros c'est que la conception de base s'est fourrée le doigt dans l'œil jusqu'au trognon. (je parle de l'antérieur). J'ai le droit à un joker pour les concepteurs de la base antérieure ? =) Mais sinon, même sans ça, j'ai du mal à voir comment on aurait pu faire mieux, une transaction bancaire étant RÉELLEMENT aussi complexe à décrire, le modèle de données l'est tout autant. Ou alors il aurait fallu des champs banalisés ou structurés, mais on aurait perdu en capacité de requétage. Effectivement, ça n'est gérable que par du middleware. Ben pourtant, j'ai l'impression que l'approche par SP parvient très vite à ce niveau de complexité. Après, il y a peut-être des manières de faire que je ne vois pas pour le moment qui permettent de limiter les dégâts, mais de ce que je connais des SP et de leur fonctionnement, j'en doute très fortement. Là n'était pas le PB, il se trouve dans la phrase au-dessus: comment avez-vous pu accepter de reprendre cette DB telle quelle?!; Faut bien travailler parfois =) je ne parle même plus des tables à 400 colonnes, mais bien des mauvaises indexations; c'est typiquement symptomatique d'un mille-feuille jamais retouché (à moins que les concepteurs de base n'aient *vraiment* été des burnes, ce qui existe malheureusement). Les choix technologiques antérieurs n'étaient pas pertinents (Microsoft SQL Server, SSIS…). L'absence d'indexes s'expliquait par exemple par le fait que les tables étaient partitionnées par date pour des contraintes de purge rapide des données (daily rolling window). Sauf que du coup, la pose d'indexes ne contenant pas la clef de partitionnement était interdite afin de pouvoir aussi partitionner les indexes, sinon le rolling conduisait à une reconstruction intégrale des indexes, qui plombait les purges (3j au lieu de 10s). Wai, ça revient à l'histoire de mon pote: on vous a refilé le truc dont personne ne voulait en cachant bien la merde au chat. Tout le monde a connu un projet comme ça malheureusement… D'ailleurs, je me demande si ça ne serait pas une idée de site pro à monter ça: un répertoire des boîtes qui se foutent du monde rapport à leurs demandes impossibles... Ah ben c'est simple : tout le monde… En tout cas en SSII, les appels d'offre qu'on reçoit, c'est le cas, sinon la boîte en face l'aurait gardé en interne ! La plupart du temps, le client est elle-même prestataire et se rend compte qu'il ne pourra pas tenir les délais de l'appel d'offre initial, mais il doit bosser. El prend le contrat, et sous-traite au forfait une partie plus ou moins cruciale, en tentant de cacher la misère. Celui qui signe la sous-traitance s'engage avec obligation de résultat, ne tiendra pas ses délais, mais la boîte d'origine pourra rejetter la faute du retard (anticipé…) sur son presta, voire lui faire payer des pénalités qui compenseront celles (prévues…) que la boîte doit payer à son client final. J'entends bien, mais là encore les défauts de base de la DB étaient rédhibitoires. Pas tant que ça. Une fois qu'on a (enfin) pu faire comprendre au client que les SPs, c'était pas le bon plan, on a foutu un middleware et un ORM, et roule. En 3 semaines, le taff était fait, contre 12 mois pour la version SP (et sans parvenir au bout…). Les données provenaient de systèmes externes et/ou de sous-systèmes, sous la forme de web-services. C'est plus une usine à gaz mais un complexe pétrolier au grand complet ton histoire :( C'est souvent le cas en système d'info, tu ne dépends que très rarement que de ton seul sous-système. La plupart du temps, tu t'interfaces avec des systèmes tiers, via web-service, échange de fichiers, FTP, SSH, messaging… La base de données est souvent totalement contre-indiqué pour ce genre d'usage (N clients différents, polling de masse, données peu ou pas structurées, contrôle d'intégrité et de cohérence, chiffrement, signature…) Tout est une histoire de mesure. Tombé dans l'OLAP, c'est quand même le canon de 14 pour tuer un moustique. La mitrailleuse lourde est déjà bien suffisante et possède assez de marge pour descendre une marmotte si le besoin s'en fait sentir. Ben pas vraiment, vu comment tu décris la chose (d'un autre monde:) OLAP, middleware(s) et le reste qui va bien avec - mais même comme ça, ça reste du monstrueux construit sur une base inacceptable (la DB). Ca permet aussi n'importe quelle gymnastique dans le cadre du reporting sans trop d'efforts à fournir. Le problème était clairement la BdD faite avec 2 pieds gauches. Si on avait pas eu le soucis d'historique du bordel, c'est clair que c'était OLAP, ETL, Birt, OW2… Les trucs que je ne comprends pas c'est pourquoi vous avez pris l'affaire sachant que la base était pourrie (principe de la chaîne), ni cassé le contrat lorsque le client vous a avoué que
Re: Récupération de don
On Sun, 18 Sep 2011 08:29:55 +0200, steve dl...@bluewin.ch wrote: A propos de cool, vérifie donc la température de ton HD. # hddtemp /dev/sdh /dev/sdh: Hitachi HDT721010SLA360: S.M.A.R.T. non disponible Je peux lui mettre un doigt dessus pour voir. Et si je remarque qu'elle est trop élevée, je fais quoi pour la diminuer ? Quelqu'un parlait d'une bombe à je ne sais plus quel produit..sinon, un ventilo ? Non, surtout pas un coup de bombe au fréon ni autre icepack: ça créerait un choc thermique et là pour le coup tu risquerais de vraiment le péter. S'il te semble trop chaud, tu peux le mettre sur des supports pour favoriser la convection (Lego, boîtes, etc - mais tenus ensemble pour éviter qu'il ne ne tombe par vibration), et si ça ne suffit, tu peux le souffler. Mais bon, ça c'est *vraiment* s'il te parait trop chaud (50°), sinon n'y touche pas il ne s'en porteras que mieux. -- Our comedies are not to be laughed at. -Samuel Goldwyn -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110918134528.7d4edeb6@anubis.defcon1
Re: Xen : lenteur réseau.
Le Sun, 18 Sep 2011 11:56:38 +0200, Gilles Mocellin gilles.mocel...@free.fr a écrit : Le Sunday 18 September 2011 10:41:43 Yann Cohen, vous avez écrit : Bonjour, Bonjour, [...] [...] J'ai eu des symptômes similaire à une époque. Cela venait de la combinaison carte réseau/bridge. La carte prenait en charge la fonctionnalité LRO. De ce que j'ai compris, ça permet de regrouper les trames pour les envoyer ou traiter en un coup. Sauf qu'avec un bridge, les trames ne sont pas forcément destinées à la même interface (les interfaces virtuelles des VM, avec leur adresse MAC). Bref, le driver que j'utilisais avait une option pour désactiver cette fonctionnalité (disable_tpa). J'ai trouvé des références à disble_tpa uniquement pour des puces Broadcom. Les deux cartes physiques qui sont dans le serveur sont basées sur des puces realtek. Je n'ai pas trouvé d'indice sur ce type de fonctionnement sur ce module (r8169). Comment m'assurer que j'ai pb similaire et comment le résoudre ? 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) Subsystem: ASUSTeK Computer Inc. Device 8432 Flags: bus master, fast devsel, latency 0, IRQ 751 I/O ports at d800 [size=256] Memory at fdfff000 (64-bit, prefetchable) [size=4K] Memory at fdff8000 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 04:05.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet Adapter (rev 10) Subsystem: D-Link System Inc DGE-528T Gigabit Ethernet Adapter Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 20 I/O ports at e800 [size=256] Memory at febffc00 (32-bit, non-prefetchable) [size=256] Expansion ROM at f000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Kernel driver in use: r8169 En fouillant un peu la configuration des bridge sur dom0 je me pose des questions. root@xianco:~# brctl show bridge name bridge id STP enabled interfaces br_dmz 8000.feff no vif10.0 vif3.2 br_evil 8000.1caff7e48678 no peth1 vif3.1 vif9.1 br_safe 8000.20cf30a7e833 no peth0 vif10.1 vif3.0 vif5.0 vif7.0 vif8.0 vif9.0 Là je comprends bien pas de Pb. root@xianco:~# brctl showmacs br_dmz port no mac addris local? ageing timer 2 00:16:3e:66:c3:87 no 7.88 1 00:16:3e:a2:8a:bc no40.34 1 fe:ff:ff:ff:ff:ff yes0.00 root@xianco:~# brctl showmacs br_evil port no mac addris local? ageing timer 1 00:04:30:17:f5:e9 no79.25 1 00:13:d3:b7:1e:b8 no79.25 3 00:16:3e:a2:8a:bd no10.03 1 00:17:33:a1:85:74 no79.25 1 1c:af:f7:e4:86:78 yes0.00 3 fe:ff:ff:ff:ff:ff yes0.00 root@xianco:~# ifconfig br_dmzLink encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff adr inet6: fe80::247c:7ff:feaf:bbd0/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:17297 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:8951511 (8.5 MiB) TX bytes:468 (468.0 B) br_evil Link encap:Ethernet HWaddr 1c:af:f7:e4:86:78 inet adr:192.168.1.20 Bcast:0.0.0.0 Masque:255.255.255.0 adr inet6: fe80::1eaf:f7ff:fee4:8678/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:962897 errors:0 dropped:0 overruns:0 frame:0 TX packets:25382 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:265639580 (253.3 MiB) TX bytes:1422898 (1.3 MiB) br_safe Link encap:Ethernet HWaddr 20:cf:30:a7:e8:33 inet adr:192.168.3.20 Bcast:0.0.0.0 Masque:255.255.255.0 adr inet6:
Re: Piratage Mysql
On Sun, 18 Sep 2011 12:32:47 +0200, Aéris ae...@imirhil.fr wrote: ... J'ai le droit à un joker pour les concepteurs de la base antérieure ? =) C'est pas possible!? ... Là n'était pas le PB, il se trouve dans la phrase au-dessus: comment avez-vous pu accepter de reprendre cette DB telle quelle?!; Faut bien travailler parfois =) À n'importe quel prix (heu... perte)? ... La plupart du temps, le client est elle-même prestataire et se rend compte qu'il ne pourra pas tenir les délais de l'appel d'offre initial, mais il doit bosser. El prend le contrat, et sous-traite au forfait une partie plus ou moins cruciale, en tentant de cacher la misère. Celui qui signe la sous-traitance s'engage avec obligation de résultat, ne tiendra pas ses délais, mais la boîte d'origine pourra rejetter la faute du retard (anticipé…) sur son presta, voire lui faire payer des pénalités qui compenseront celles (prévues…) que la boîte doit payer à son client final. Comme disait Coluche: et dire qu'il suffirait de ne pas l'acheter pour que ça ne se vende pas (mais je comprends que le taff ne courant pas les rues...) ... C'est plus une usine à gaz mais un complexe pétrolier au grand complet ton histoire :( C'est souvent le cas en système d'info, tu ne dépends que très rarement que de ton seul sous-système. La plupart du temps, tu t'interfaces avec des systèmes tiers, via web-service, échange de fichiers, FTP, SSH, messaging… La base de données est souvent totalement contre-indiqué pour ce genre d'usage (N clients différents, polling de masse, données peu ou pas structurées, contrôle d'intégrité et de cohérence, chiffrement, signature…) Ca d'accord, mais quand même, à ce point ça fait beaucoup. ... Le pire cas que j'ai vu passer, c'est une incompréhension sur un terme du langage courant, qui changeait tout le fonctionnement du système si on prenait sa signification réelle métier. En gros, c'était comme si je te disais « tu n'as pas éteint la lumière ». En langage courant, tu en comprends qu'elle est allumée et que tu dois aller l'éteindre. En langage métier, ça signifiait qu'elle était peut-être allumée et qu'il fallait l'éteindre, mais aussi que si elle était éteinte, il fallait l'allumer puis l'éteindre aussitôt ! Faute de specs dignes de ce nom, déboîtage du projet… Tu devrais faire un blog avec tous tes déboires: on dirait du Victor Hugo, avec le client dans le rôle de Ténardier; et puis tu pourrais intituler les commentaires la p'tite causette ;-) Je pensais naïvement qu'avec le temps les déboires des SSII s'étaient un peu atténués, mais je m'aperçois que c'est exactement le contraire. -- Please read the prospectus carefully before you invest or send money. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110918141456.68bcd75b@anubis.defcon1
Re: Piratage Mysql
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 18/09/2011 14:20, Jean-Yves F. Barbier a écrit : Faut bien travailler parfois =) À n'importe quel prix (heu... perte)? Certains soutiennent qu'il vaut mieux 10 ingés sur un truc qui ne rapporte rien au final (coût salarial = X, facturation client = X) que 10 ingés en intercontrat (coût salarial = X, facturation client = 0) =) Tu devrais faire un blog avec tous tes déboires: on dirait du Victor Hugo, avec le client dans le rôle de Ténardier; et puis tu pourrais intituler les commentaires la p'tite causette ;-) Ouaip, il risquerait d'être assez rapidement rempli je pense ^_^ Je pensais naïvement qu'avec le temps les déboires des SSII s'étaient un peu atténués, mais je m'aperçois que c'est exactement le contraire. Ben tant qu'on restera dans le fonctionnement actuel des appels d'offre, c'est-à-dire un choix de prestataire fonction du montant du devis à 90% de la décision, on aura forcément ce genre de problème. Quand on signe enfin un contrat, le 1er réflexe au niveau technique, c'est presque « Merde, on était moins cher que tout le monde, qu'est-ce qu'on a raté ‽‽‽ » et d'aller au charbon pour tenter de connaître les tarifs des devis de la concurrence et des infos pour savoir où on va se faire niquer et qu'eux avaient vu. À titre de comparaison avec l'Allemagne (où les achats refuseront purement et simplement une proposition en dessous de l'estimation interne et où la MOA est prêt à mettre plus de moyen à condition de garanties fortes de tenir les délais) qui doit obtenir des taux de dépassement de projet de l'ordre de 20%, en France on serait plutôt à 80%… Le mode « forfait » est souvent vu par les clients comme un bon moyen de se faire financer le projet par le prestataire, parfois avec des méthodes douteuses, comme par exemple de faire miroiter de la régie ou de la TMA à long terme si on mène le projet forfaitisé à son terme (quoi qu'il en coûte au presta, et quelque soit le retard). À ce sujet, je serais d'ailleurs intéressé par des retours d'autres collègues de SSII (voire de clients, mais là j'ai des doutes d'en avoir un jour !), parce que malgré que la situation me semble générale, il y a une espèce d'Omertà là-dessus, et qu'au contraire tout le monde y fonce tête baissée, par peur de la perte du client. - -- Aeris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOdefTAAoJEK8zQvxDY4P9AQgIAJS4GFX1gNJU7CQnTx/tWgp1 62NJZZQu8bQ80HL8wHZRe9xN16wREAluOmb+AsWwRBwZvUK4RCHnfCBDABx1UYBQ a4A0jrADV/6849V82iEInc5NeUj1/pdZmiojN22tpi/qMl4MtC8N2h5vs5SDTIV1 NOUtDNStSgmQWRiwnxOYekazQo4elkcBAPgfnFPEG5QnysIstsTzhyS4z4OrhCb2 i/l8rIbszxru6B4Slvp4C2Ufg9oYDmERjpKhg0nxdy5UZAjyDIbyuUJnIJfIda96 kCGsVbT1KdSvkM7tJrvD/GF1r4oB1x7BIenSuH7S/QcSoVqiKnQvC97UCpi3q74= =Dg2C -END PGP SIGNATURE- -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4e75e7d9$0$15032$426a3...@news.free.fr
Re: Piratage Mysql
On Sun, 18 Sep 2011 14:45:13 +0200, Aéris ae...@imirhil.fr wrote: ... À titre de comparaison avec l'Allemagne (où les achats refuseront purement et simplement une proposition en dessous de l'estimation interne et où la MOA est prêt à mettre plus de moyen à condition de garanties fortes de tenir les délais) qui doit obtenir des taux de dépassement de projet de l'ordre de 20%, en France on serait plutôt à 80%… Ta réflexion est intéressante et correspond à mes propres retours Allemands. Il est d'ailleurs assez inique de constater que sur les 30 dernières années, eux ont amélioré leur situation (les français, particulièrement, les disaient lourds, lents, trop planificateurs et pas assez déhotteurs au pied levé) en piquant de la spontanéité ici; alors que dans le même temps le trait système-D des français s'est amplifié au point de devenir une caricature, sans avoir rien retiré de leurs coopérations avec nos voisins d'outre-Rhin... -- Horse sense is the thing a horse has which keeps it from betting on people. -- W. C. Fields -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110918152341.6f5fdaa7@anubis.defcon1
Re: Le Load_Cycle_Count : encore des problèmes ?
Le samedi 17 septembre 2011 à 21:51:26, Eddy F. a écrit : […] Quand est-ce que la valeur repasse à 128 ? Je suis à 128 par défaut ! […] Ensuite si je change la valeur, par ex. 160, le niveau reste à 160 et n'est modifiée que par un reboot, une sortie de veille en ram ou une hibernation. Ok. Donc soit c’est un script (v. plus loin), soit c’est le disque. Mon premier souci est que, partout où je cherche (listes debian, rapports de bugs, forums debian ou ubuntu...) le problème est résolu depuis 2 ou 3 ans ! Attention. Le bogue/problème résolu, c’est la valeur par défaut utilisée par les scripts. Debian a décidé d’utiliser 128 sur batterie et 254 sur secteur, crois-je. Le problème des disques qui font n’importe quoi n’est pas résolu vu que ce sont certains disques (pas tous) qui font n’importe quoi… Et le problème n'est pas lié à la distribution testing. Sur un autre portable où squeeze est installée, j'ai aussi le même niveau de 128 par défaut (mais là cela ne cause pas de souci de load_cycle_count - je suppose parce que c'est un autre disque). Yep. […] Chez moi aussi donc. Mais est-ce le disque qui est responsable ? Ou est-ce dû aux scripts de mise/sortie de veille/hibernation ? Étant donné que, par défaut (en tout cas sous Sid ce jour), aucun script dans /etc n’utilise hdparm (à part ceux de hdparm), qu’aucun fichier de config (notamment ACPI) ne parle de hdparm ni ne contient 128 (dans un sens hdparmiesque), je vois mal comment ça pourrait être un script ou c’est très mal foutu. Le seul script qui passe de 128 à 254 et réciproquement est l’exemple donné dans /usr/share/doc/acpi- support/examples/*.d/90-hdparm.sh (lequel est plutôt bien écrit : il laisse laptop_mode gérer s’il est là pour ça). […] La variable $hdparm_opts de ce script est lue dans /etc/default/hdparm. Oui, c’est pour cela que la première ligne de mon script est . /etc/default/hdparm Chez moi, elle est vide. Cela explique-t-il pourquoi je suis au niveau 128 au démarrage ? Oui, puisque 128 semble être la valeur préférée de ton disque. Est-ce normal qu'elle soit vide ? Oui. Est-ce un bug ? Non. Y écrire -B 254 ne sera pas satisfaisant car j'aimerais tout de même conserver cette valeur de 128 quand je suis sur batterie. Dans ce cas, il faut utiliser laptop-mode-tools ou avoir un script plus malin dans /etc/acpi/. En fait, je n'y connais rien et donc ne comprends rien à ce qui se passe dans la gestion de l'énergie et du disque : hdparm, acpi, apm, pm-utils... qui fait quoi dans quel ordre. Bonnes questions. Quelques réponses : hdparm : juste un outil pour vérifier/régler le matériel ACPI : un beau merdier… APM : en général, juste un acronyme, à ne pas confondre avec l’APM qui était le système de gestion d’énergie dans les BIOS avant ACPI (même acronyme mais certaines vieilles pages ou vielles gens peuvent confondre, donc ne pas utiliser comme mot-clef dans ses recherches) pm-utils : des scripts pour suspendre/hiberner, lesquels lancent les scripts adéquats dans /etc/pm/*.d/ acpi-support : des scripts qui gèrent les évènements ACPI, dont l’appel aux scripts de pm-utils lors d’un appui sur le bouton ACPI correspondant (p.ex. fermeture de l’écran). On peut mettre ses scripts (hooks) dans /etc/acpi/*.d/. (Note que ces répertoires n’existent plus, et ne sont plus visités, dans les dernières versions d’acpi-support et donc que le script /etc/acpi/power.sh est aussi à modifier suivant l’exemple de /usr/share/doc/acpi-support/examples/acpi/ ; remarque que l’on peut aussi tout traiter directement dans ce power.sh…) acpi-support utilise aussi upower (c’est notamment indiqué dans les commentaires de /etc/default/acpi-support). upower : démon qui donne des infos sur et active les fonctions de la gestion d’énergie, via D-Bus. Il doit utiliser les scripts de pm-utils (et donc passer par /etc/pm/*.d/*) lorsque l’on suspend/hiberne… Que se passe-t-il quand on clique bêtement sur le bouton hiberner de gnome ou kde ? Maintenant, ils sont censés passer par upower, via D-Bus. Ils peuvent aussi gérer les boutons ACPI (ce qui peut causer une double gestion et des soucis avec acpi-support ?). Ou trouver une documentation sur le sujet (si possible spécifique à Debian) ? Lire /usr/share/doc/paquet/README.Debian (et les fichiers autours), regarder aussi les pages web indiquées dans les descriptions des paquets (ou les README)… Peut-être que maintenant laptop-mode-tools le fait aussi mais, la dernière fois que j’ai regardé, il fallait éditer le script pour modifier ces valeurs (à plusieurs endroits en plus ; et à refaire/vérifier à chaque m-à-j)… Bon, a priori, ce paquet n'est pas indispensable. Je vais essayer sans. Tant que je ne comprends pas comment le laptop-mode fonctionne, pas besoin d'en utiliser des outils :-( Je crois que, pendant un moment, laptop-mode-tools et pm-utils étaient en
ATELIER Java , le 8 octobre
APPRENEZ LE JAVA avec GCJ (GNU Compiler for Java) (OpenSource) le samedi 8 octobre 2011, à 14 heures, 1 rue de la Solidarité 75019 Paris (Métro Danube ou Ourcq) Un atelier architecture logicielle avec le langage Java, animé par Christophe Roux, ingénieur INSA de Lyon et spécialiste Java. (atelier gratuit ouvert à tous, mais avec pré-inscription obligatoire) Objectif : être capable d’aborder le développement en programmation orientée objet avec Java. (niveau débutant sur le sujet mais bon utilisateur en informatique et sa culture général). Programme (concret et pratique) : - Les points marquants et originaux du langage Java ; - Être capable d’écrire un programme source en Java ; - Savoir le compiler avec le GCJ : GNU Compiler for Java ; - L'architecture logicielle à travers le langage Java : les concepts orientés objet, qu’est‐ce qu’une classe, un objet ? - Inciter à vouloir en découvrir plus sur Java et l’architecture logicielle, à travers la modélisation en 3D. Infos et vous inscrire : http://linuxfr.org/news/atelier-de-formation-%E2%80%94%C2%A0apprenez-java-avec-gcj-le-8%C2%A0octobre%C2%A02011 -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201109181625.44285.cor...@free.fr
Re: Xen : lenteur réseau.
Le Sunday 18 September 2011 13:55:41 Yann Cohen, vous avez écrit : Le Sun, 18 Sep 2011 11:56:38 +0200, Gilles Mocellin gilles.mocel...@free.fr a écrit : [...] J'ai eu des symptômes similaire à une époque. Cela venait de la combinaison carte réseau/bridge. La carte prenait en charge la fonctionnalité LRO. De ce que j'ai compris, ça permet de regrouper les trames pour les envoyer ou traiter en un coup. Sauf qu'avec un bridge, les trames ne sont pas forcément destinées à la même interface (les interfaces virtuelles des VM, avec leur adresse MAC). Bref, le driver que j'utilisais avait une option pour désactiver cette fonctionnalité (disable_tpa). J'ai trouvé des références à disble_tpa uniquement pour des puces Broadcom. Les deux cartes physiques qui sont dans le serveur sont basées sur des puces realtek. Je n'ai pas trouvé d'indice sur ce type de fonctionnement sur ce module (r8169). Comment m'assurer que j'ai pb similaire et comment le résoudre ? L'outil ethtool peut apparemment agir sur ces paramètres : gilles@guitare:~$ ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: on large-receive-offload: off rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off receive-hashing: off LRO = large-receive-offload. Chez moi (driver r8169 aussi, il est désactivé par défaut) Pour le désactiver si c'est supporté : gilles@guitare:~$ sudo ethtool -K eth0 lro off Chez-moi, ça me dit que ce n'est pas supporté. [...] Pour le reste, je ne connais pas assez Xen pour répondre, mais ça me parait anormal d'avoir la même adresse MAC sur plusieurs interfaces, qu'elles soient virtuelles ou non. Surtout avec un format étrange avec beaucoup de f. signature.asc Description: This is a digitally signed message part.
Re: sortie de veille sur ASUS 1215B
Bonsoir, Merci de ta réponse. J'ai déjà essayé C6 du bios sans résultat. Si j'ai bien compris tu as la m^eme config (hormis le µp, j'ai C50) et tu n'as pas résolu le problème non plus !? beug noyau alors ?? Si j'utilise le driver libre je n'ai plus la 3D il me semble ! Eb tout cas j'ai aussi essayé cela sans succès. Bon enfin à suivre... JC GARNIER Le dimanche 18 septembre 2011 à 00:40 +0200, Guy Roussin a écrit : Bonsoir, Deux pistes : - désactiver le mode C6 (bios) - voir bug 620324 (essayer le driver libre radeon) Guy PS: j'ai le 1215B E350 avec le même soucis. Le 18/09/2011 00:21, garnier a écrit : Bonjour, Voilà ça fait un bout de temps que je bataille sur ce problème : l'ordinateur se met bien en veille mais impossible de ravoir l'écran qui reste noir. Pourtant il se reveille car les voyants l'indiquent mais impossible de retrouver l'affichage. Ma config : Débian squeeze à jour + pinning testing/ustable CG ATI radeon 6250 (driver proprio pour la 3D) Noyau 3.0... Mes essais : divers versions Acpi, eeepc, pm je ne sais plus quoi, scripts glanés de ci de là, etc... Une ré-install du bureau Une ré-install du system (methode dselect vers une net-install minimale) Ma meilleure piste : une histoire d'usb qui ne se couperait pas correctement à la mise en veille mais bon ça ne marche pas non plus. Je me demande si d'autres personnes ont rencontrées le m^eme problème sur ce modèle !? Ce PC fonctionne parfaitement par ailleurs et je ne m'attendais pas à avoir ce genre de soucis sur Linux (marche sur seven;n'y aurait'il pas une possibilité d'utiliser le driver win cf Ndiswrapper? ). Par avance merci de vos conseils ou pistes à suivre, JC GARNIER -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/1316366753.8539.5.camel@garnier-PC-asus
Re: Le Load_Cycle_Count : encore des problèmes ?
Bonjour, Tout d'abord, il me semble que grâce à votre aide j'ai pu résoudre mon problème. Je détaillerai ce que j'ai fait plus bas. Peut-être cela pourra servir à quelqu'un d'autre (modestement, j'en doute) ; peut-être corrigera-t-on ma façon de procéder. Le dimanche 18 septembre 2011 15:33:15, Sylvain L. Sauvage a écrit : [...] Attention. Le bogue/problème résolu, c’est la valeur par défaut utilisée par les scripts. Debian a décidé d’utiliser 128 sur batterie et 254 sur secteur, crois-je. Le problème des disques qui font n’importe quoi n’est pas résolu vu que ce sont certains disques (pas tous) qui font n’importe quoi… Ok, je commence à piger... un peu. Le disque aime le niveau 128. Debian le laisse faire. Naïvement, je croyais justement que la résolution de bug consistait à imposer la valeur 254. Visiblement, je me trompais. Effectivement, je ne trouve nulle part de script qui cherche à imposer cette valeur. [...] Mais est-ce le disque qui est responsable ? Ou est-ce dû aux scripts de mise/sortie de veille/hibernation ? Étant donné que, par défaut (en tout cas sous Sid ce jour), aucun script dans /etc n’utilise hdparm (à part ceux de hdparm), qu’aucun fichier de config (notamment ACPI) ne parle de hdparm ni ne contient 128 (dans un sens hdparmiesque), je vois mal comment ça pourrait être un script ou c’est très mal foutu. Le seul script qui passe de 128 à 254 et réciproquement est l’exemple donné dans /usr/share/doc/acpi- support/examples/*.d/90-hdparm.sh (lequel est plutôt bien écrit : il laisse laptop_mode gérer s’il est là pour ça). Et j'ai essayé ce script. En fait, j'ai essayé tellement de trucs que j'ai sûrement plus usé mon disque à force d'arrêt et redémarrage qu'à cause de ce mauvais réglage ;-) Bon sérieusement, ce script n'a pas fait ce que je voulais mais j'ai peut- être gaffé. À force d'essayer plein de choses, je m'embrouille parfois. [...] Y écrire -B 254 ne sera pas satisfaisant car j'aimerais tout de même conserver cette valeur de 128 quand je suis sur batterie. Dans ce cas, il faut utiliser laptop-mode-tools ou avoir un script plus malin dans /etc/acpi/. Ah oui. Voir plus loin ce que j'ai fait. En fait, je n'y connais rien et donc ne comprends rien à ce qui se passe dans la gestion de l'énergie et du disque : hdparm, acpi, apm, pm-utils... qui fait quoi dans quel ordre. Bonnes questions. Quelques réponses : C'est bien ce que j'aime sur cette liste. On ne te dit pas de cliquer ci et là puis de rebooter, on te donne des pistes pour comprendre. hdparm : juste un outil pour vérifier/régler le matériel ACPI : un beau merdier… Ça me rassure un peu. J'avais en effet beaucoup de mal à m'y retrouver. APM : en général, juste un acronyme, à ne pas confondre avec l’APM qui était le système de gestion d’énergie dans les BIOS avant ACPI (même acronyme mais certaines vieilles pages ou vielles gens peuvent confondre, donc ne pas utiliser comme mot-clef dans ses recherches) Sur ce coup, j'étais perplexe : j'ai quand même un dossier /etc/apm et un paquet apmd installé. Mais la doc me dit qu'il n'est pas utilisé. D'ailleurs un pgrep apmd ne renvoie rien et # apm me dit, comme attendu, No APM support in kernel Bête question : il sert à quelque chose ce paquet ? Un apt-get -s purge apmd ne semble pas provoquer d'hécatombe. pm-utils : des scripts pour suspendre/hiberner, lesquels lancent les scripts adéquats dans /etc/pm/*.d/ acpi-support : des scripts qui gèrent les évènements ACPI, dont l’appel aux scripts de pm-utils lors d’un appui sur le bouton ACPI correspondant (p.ex. fermeture de l’écran). On peut mettre ses scripts (hooks) dans /etc/acpi/*.d/. (Note que ces répertoires n’existent plus, et ne sont plus visités, dans les dernières versions d’acpi-support et donc que le script /etc/acpi/power.sh est aussi à modifier suivant l’exemple de /usr/share/doc/acpi-support/examples/acpi/ ; remarque que l’on peut aussi tout traiter directement dans ce power.sh…) acpi-support utilise aussi upower (c’est notamment indiqué dans les commentaires de /etc/default/acpi-support). Oui, j'avais bien lu dans /usr/share/doc/acpi-support/README.Debian qu'en principe ces scripts de /usr/share/doc/acpi-support/examples sont « deprecated ». [...] Et bien un grand merci pour toutes ces pistes. Pour résumer, je voudrais une valeur supérieure à 128 pour le niveau APM de mon disque quand je suis sur secteur et de 128 sur batterie. Je voudrais que ce soit détecté convenablement au démarrage, modifié automatiquement au changement d'alimentation. Et en plus que ce ne soit pas perturbé par la mise en veille et l'hibernation. man acpid me dit d'aller voir /etc/acpi/events /etc/acpi/events/ac me dit qu'il exécute /etc/acpi/power.sh (bon vous me l'aviez dit aussi ; j'explique après coup comment j'aurais dû pouvoir démêler le fil moi même) /etc/acpi/power.sh exécute
Organisation d'une journée chasse aux bogues
Bonjour, Le salon de discussion de la communauté Debian francophone sur Jabber organise une journée de chasse aux bogues prochainement. En espérant vous retrouver nombreux, voici l'annonce: À la date notable du 01/10/11, le salon regroupant la communauté Debian francophone sur jabber vous propose de participer à une journée de chasse aux bogues. Cette journée sera principalement axée sur la clarification et la résolution de bugs. Mais elle se veut également l'occasion pour les utilisateurs moins familiers avec la gestion des bugs de pouvoir apporter leur contribution au projet Debian, par exemple en réalisant des traductions de description de paquet ou en étoffant des pages du wiki. Utilisateurs désireux d'apporter leur aide au projet Debian pour une heure ou deux, ou développeurs chevronnés, vous serez les bienvenus sur le salon ! L'adresse du salon est la suivante: debian...@chat.jabberfr.org L'heure de rendez-vous pour la présentation et l'organisation de la journée est proposée à 10h30 (heure de Paris). Pour les personnes qui ne sont pas familières avec Jabber/XMPP, vous pourrez trouver plus d'informations sur http://wiki.jabberfr.org ; vous pouvez également rejoindre le salon en un clic via le client web: https://www.jappix.com/?r=debian...@chat.jabberfr.org A bientôt, Manu -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4e7659e7.60...@laposte.net
GNOME et Emacs inutilisables ensemble
Bonsoir, Avez-vous déjà subi les plantages d'Emacs avec GNOME ? Plus précisément, je ne parviens plus à lancer GNU Emacs (23.3+1-1.1) graphiquement sous GNOME (1:2.30+11) : la session GNOME est immédiatement plantée et je reviens à GDM. En revanche, Emacs fonctionne toujours correctement en mode texte (emacs -nw) même sous GNOME (gnome-terminal 3.0.1-1). Une idée ? Merci beaucoup ! Cordialement, [CITATION ALÉATOIRE : Psychologue : Celui qui regarde les autres quand une jolie femme entre dans la pièce. Pierre Desproges] -- Pierre Crescenzo mailto:pie...@crescenzo.nom.fr http://www.crescenzo.nom.fr/ -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/878vpl4hq9@tpol.unice.fr
