Benoît Sibaud a écrit 9672 commentaires

« Tout lien (...) est strictement interdit (...), sauf autorisation expresse de Bouygues. »

ça me semble assez clair personnellement. Ceci dit si leurs conditions ne sont pas claires, c'est aussi un problème...

Trouvé. La page ayant le plus de commentaires.

Ce n'est pas que « pour mémoire », c'est d'actualité même.

« Microsoft et l'INRIA reconduisent leur labo commun pour 4 ans »
http://www.silicon.fr/fr/news/2009/10/07/microsoft_et_l_inri(...)
« Informatique : Microsoft, premier partenaire industriel de l’INRIA »
http://www.innovationlejournal.com/spip.php?article4709

ESTP - École spéciale des travaux publics, du bâtiment et de l'industrie
57 boulevard Saint-Germain
75240 PARIS cedex 05

Librairie Eyrolles
55-63 bd Saint-Germain
75005 Paris

L'annonce April indique l'ESTP comme lieu,puis la libraire pour un pot.

En 2009 jusqu'à présent :
- Slashdot.org plusieurs milliers d'articles (peut-être 15 par jour sur 270 jours, soit plus de 4000)
- LinuxFr.org 846 dépêches, 1131 journaux
- Framablog 244 articles
- Standblog 240 articles
- ni Planet Libre ni planet.april.org ni aucun planet ne produit de contenus

En bot passerelle bidirectionnelle IRC<->IM, il y a aussi :
- xlib (Python, GPLv3) http://www.changaco.net/en/xib/ (utilisé par Vim-fr http://linuxfr.org/2009/09/21/25938.html )
- jirc-bridge (Perl, GPLv2) http://www.outflux.net/software/pkgs/jirc-bridge/ (utilisé par l'April par exemple)

$ df -H /dev/hda2
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hda2 343M 238M 87M 74% /
$ df -h /dev/hda2
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hda2 327M 227M 83M 74% /

$ du -h /boot/vmlinuz-2.6.29-1-686
1,7M /boot/vmlinuz-2.6.29-1-686
$ du --si /boot/vmlinuz-2.6.29-1-686
1,8M /boot/vmlinuz-2.6.29-1-686

...

Tant qu'on y est, sur les comptes utilisateur valides et utilisés au cours des 3 derniers mois et ayant un Jabber ID renseigné : 25% jabber.fr, 19% gmail, 11% apinc, 10% jabber.org, 2% fritalk.

Sur les comptes utilisateur valides et utilisés au cours des 3 derniers mois : 28% gmail, 16% free, 6% yahoo.fr, 4% laposte, 3% hotmail, 2% wanadoo, 1% hotmail, 1% ifrance, 1% no-log, 1% altern, 1% orange, 1% yahoo.com.

Ouais mais avec la présence dans XMPP, tu peux savoir sur ton écran incrusté dans le frigo si la lumière est allumée dedans ou pas. Et sinon tu peux aller dans le salon MUC pour discuter avec le congélateur et le microonde du dîner à préparer.

> [1] D'ailleurs, je me demande combien ça coûte en standalone, les seules que je connais sont celles qui sont intégrées dans les serveurs Dell, IBM et compagnie... C'est du même ordre ce que vous envisagez ici ?

Apparemment 275 € TTC hors livraison une carte Dell DRAC5.

Je n'en doute pas... je suis sûr que lorsque le noyau d'un système propriétaire aix plante, il renaît spontanément de ses cendres en autorécupérant via le « Void which binds » les dernières paroles du décédé qu'il inscrit alors soigneusement dans le grand registre des extraits de dernières paroles pour les générations futures. Bref quand le coeur du système (ici le noyau de l'hôte) plante, ben ça plante...

Quand l'accès aux disques se plante, le log du crash n'est pas stocké sur... le disque. Donc il est juste sur la console. Et comme la machine a été redémarrée (c'est pas le boulot du NOC de débugger notre serveur), pffiou, aucune trace du oops. Et quand bien même, on n'a pas non plus de kernel debugger sur un port série, c'est pas facilement utilisable.

La dernière sauvegarde hors site du site avait moins de 48h. On a deux sites distants de sauvegardes, des sauvegardes journalières et des hebdomadaires, ce n'était pas vraiment ça le souci...

Tant que personne ne code templin' le module noyau Linux pour templeet, ça ne devrait pas arriver.

La saturation d'un système de fichiers dans un vserver peut bloquer le Mysql concerné, à la rigueur ralentir jusqu'à l'insoutenable tout le vserver, à l'extrême limite ralentir l'hôte, mais pas provoquer un plantage noyau a priori. Bref le souci RAID et la saturation locale d'un système de fichiers me semblent décorrélés. Ensuite sur le plantage noyau, ça va être difficile d'avoir plus d'infos autrement que par divination.

Parce que les pôles de compétitivité sont régionaux.
« System@tic Paris-Région est un pôle de compétitivité d'Île-de-France créé en 2005 et consacré aux systèmes complexes. »
http://fr.wikipedia.org/wiki/System%40tic
http://www.systematic-paris-region.org/fr/index.html

Si les données sont chiffrées sur le portable (et donc qu'il faut un mot de passe fourni au clavier, par clé usb, par ..., via une zone d'amorce accessible), le méchant cracker n'a théoriquement pas de possibilité d'accéder aux données sauf à casser le chiffrement. Il peut par contre faire ce qu'il veut du portable matériellement parlant (le réinstaller, s'en faire un marche-pied ou une cale d'armoire, etc.). Il peut bien trifouiller dans la zone d'amorce autant qu'il veut, ça ne lui donnera pas le mot de passe.

Et avoir un composant matériel dans l'histoire ne change rien. Éventuellement il pourrait mettre un cheval de Troie dans la zone d'amorce et rendre le portable (ou plus probablement faire ça en douce à l'insu du propriétaire sans vraiment « voler » le portable), dans le but de récupérer le mot de passe lors de sa prochaine saisie. En même temps si on chiffre son disque, on essaie ensuite de faire attention à ne pas laisser n'importe où son portable.

> Mais pourquoi diable le mec de TF1 viré à cause de son mail n'attaque-t-il pas sa député pour violation de la correspondance lui ayant couté son poste, vraiment?

à cause de l'immunité parlementaire en France ? (à tort ou à raison)
http://fr.wikipedia.org/wiki/Immunité_parlementaire_en_France

Voir http://fr.wikipedia.org/wiki/Expropriation_pour_cause_d%27ut(...)
ou
http://www.ggl-exproexpress.fr/

> (d'ailleurs à quand un système de paiement aussi anonyme que l'argent liquide pour acheter sur internet ?)

Le système serait en tout cas bien pratique pour blanchir de l'argent. Tout dépend si on veut une système anonyme pour tous les acteurs (État, acheteur, vendeur, intermédiaires, ...) ou seulement certains (par exemple l'État peut toujours tracer, mais le vendeur et les intermédiaires ne savent rien sur le acheteur, tout en étant à peu prêt sûr qu'il peut payer).

Et surtout perso je garde mon Fit-PC 1 avec deux Ethernet qui me fait une passerelle internet qui me va très bien.

La dernière fois que j'ai eu ce souci, c'était dû à une différence du schéma SQL dans sqlite entre la version de lightning que je venais de déployer et la version d'iceowl-extension (le lightning chez Debian) que j'avais. Et j'ai sauvagement corrigé à la main au niveau des tables SQL...

J'ai quelques patches gruik pour contourner des soucis, genre il ne veut pas ajouter un événement si tu n'es pas destinataire de l'envoi (genre si l'envoi est fait sur une liste de diffusion, il ne sait pas que tu es abonné...), etc.

Concernant le referer, la possibilité de laisser passer sans était une demande des moules, car les clients dédiés à la tribune n'avaient pas la fonctionnalité. Le souci est que le test obligatoire du referer aurait dû être imposé par la suite (après avoir laissé un temps raisonnables aux clients de tribune de se mettre à jour). En attendant les navigateurs web étaient protégés, mais pas les clients de tribune qui n'avaient pas activé le renseignement du referer.

D'un autre côté le nonce traite le problème différemment et peut servir dans tous les formulaires pour éviter tout envoi direct vers la soumission sans passer le formulaire (par contre il faut modifier les clients dédiés, comme les clients de tribune, les clients de soumission de dépêches, etc.). Le test du nonce côté serveur est beaucoup plus strict que le test de referer qui est juste un champ renvoyé par le client (potentiellement modifiable).

Concernant la remontée de bugs, je répète ce n'est pas en ne le remontant pas qu'il sera corrigé (et merci pour ceux remontés). Ensuite une fois remonté, la correction peut être bien plus compliquée que l'utilisateur ne le pense, et on a largement plus d'entrées à traiter que de gens motivés pour le faire.

> J'ai compris il y a bien longtemps que les évolutions ici n'avaient lieu que lorsqu'un événement dérange les administrateurs, ou leur donne une bonne raison de censurer.

C'est effarant de mauvaise foi, de non-reconnaissance du boulot fait, et par ailleurs et surtout très contre-productif. Mais bref passons, il y aura toujours des gens pour ne pas savoir discuter...

Concernant tes journaux, ta page https://linuxfr.org/~see/ (utilisateur See) en dénombre 2. Après les multis...

> Je ne voudrais pas prendre parti, mais j'ai du mal à comprendre ce qu'apporterait ce nonce par rapport à la bête vérification du referer.

Très simple. La faille passe par le navigateur de la victime qui quasiment tout le temps envoie au serveur LinuxFr.org un REFERER (sauf privoxy, proxy, etc.), bref ça suffisait à bloquer la très grande partie des cas. Et la présence d'un bon REFERER aurait pu être systématique si on n'avait pas suivi les demandes des moules à l'époque.

Quand à la « politique sécuritaire » (sic), on en reparlera quand tu sauras faire la différence entre trouver un bug et le remonter pour correction, et trouver un bug et l'exploiter sans prévenir jusqu'à ce que ce tu te fasses taper sur les doigts. Clairement, il y a plus utile à faire pour le site que devoir intervenir sur les gamineries d'un type qui contribue très peu en contenus (pas de dépêches et juste 2 journaux) : le système de suivi contient suffisamment de tâches à prendre, y a suffisamment d'actus à rédiger en dépêches, le site est en cours de réécriture en RoR, etc. bref j'aimerai autant utiliser mon temps dispo pour LinuxFr.org plus intelligemment.