Posté par Mayfoev () le 11/02/2004 à 13:30. (lien). Évalué à 2.

Je voudrais au contraire te remercier pour ce journal.. Qui bien que je connaisse déjà la lettre de Novell a eu l'avantage de m'indiquer les article de The Inquirer.

Je trouve dommage non pas le désintérêt d'une partie des lecteurs de DLFP pour cette affaire, mais que cette partie (peut-être majoritaire) impose souvent son choix. Il est presque devenu malvenu d'évoquer SCO dans les journaux alors que c'est le seul endroit où on peut encore l'évoquer.

[ Répondre ]

Posté par Mayfoev () le 10/02/2004 à 15:26. (lien). Évalué à 2.

Non .... Puisque c'est un ver de port à port à la Blaster...

Les sources se retrouvent facilement sur amule/mldonkey ou autre réseau d'échange, étant donné que certains partagent leurs disques en totalité:

Le fichier s'appelle sync-src-1.00.tbz et il était déjà assez bien diffusé hier soir !

[ Répondre ]

Posté par Mayfoev () le 07/02/2004 à 04:21. (lien). Évalué à 3.

s/SARS/SRAS/g
s/légionélose/légionellose/g

Pas réveillé...

[ Répondre ]

Posté par Mayfoev () le 07/02/2004 à 04:11. (lien). Évalué à 4.

(si un sorcier pouvait maudire quiquonque ecrit son nom, et toute sa famille jusqu'à la 17 è génération ca serait pas un mal ;-) )

Voilà pourquoi j'ai le SARS, la grippe du poulet et la légionélose.... Je me disais bien aussi que c'était pas naturel tout ça...

[ Répondre ]

Posté par Mayfoev () le 07/02/2004 à 04:01. (lien). Évalué à 8.

Oui c'est ce que je pensais à peu près aussi...

Sinon, juste au cas où cela choquerait un lecteur, désolé d'avoir laissé quelques fautes d'étourderie et de précipitation!

[ Répondre ]

Posté par Mayfoev () le 07/02/2004 à 03:05. (lien). Évalué à 21.

C'est trop bourré de détail pour une dépêche non? J'ai bien fait alors de le laisser en journal?

[ Répondre ]

Posté par Mayfoev () le 13/01/2004 à 02:27. (lien). Évalué à 4.

En fait, il y a deux semaines, il y avait eu sur Slashdot et news.com.com un article disant qu'on approchait de 2^30 en temps Unix (ce qui est advenu à samedi 10 à 14h37min 4sec CET ). Et que bien des horloges basées sur une système à 30 bits allait poser problème... Beaucoup pensaient à des banques utilisant des logiciels préhistoriques... Faut croire que non..

L'article original de news.com.com était totalement bidon sur le plan de l'explication mais il a apparemment été corrigé depuis et me semble correct:

http://news.com.com/2100-7355-5129875.html(...)

Le thread sur Slashdot.org:
http://developers.slashdot.org/article.pl?sid=03/12/21/1952207&(...)

[ Répondre ]

Posté par Mayfoev () le 27/12/2003 à 02:39. (lien). Évalué à 1.

Il y a aussi rrd (Round Robin Database) mais sa façon de gérer les données est particulière: c'est conçu pour que au fur et à mesure du temps, la taille de la base de données reste constante... Autrement dit rrd profite du changement d'échelle au fur et à mesure du temps pour éliminer des données (les redondantes et semblables)

J'explique pas bien... M'enfin z'avez l'idée.

Et ça fait de très beaux graphiques...

[ Répondre ]

Posté par Mayfoev () le 04/12/2003 à 14:52. (lien). Évalué à 2.

Accessoirement, les news annonçant ça devrait plutôt être du type "Kiss se décide enfin à respecter (à peu près) la GPL", les lecteurs étant dispos depuis un moment, les sources en question auraient du être dispos à la même époque.

Tout à fait... En fait je crois que Kiss a été pris en plein défaut de non-respect de la GPL comme de nombreux fabricant de lecteurs basés sur le chipset de Sigma Designs (les mêmes qui n'avaient pas respectés la GPL de Xvid qu'utilisait une de leur carte ou je ne sais quoi, en aout 2002).

Certains s'en sont pleins récemment sur LKML:

http://lkml.org/lkml/2003/11/28/59(...)
http://lkml.org/lkml/2003/11/29/45(...)

[ Répondre ]

Posté par Mayfoev () le 02/12/2003 à 07:26. (lien). Évalué à 8.

Juste pour pointer vers le thread qui a lieu actuellement sur LWN en dessous de l'annonce Debian, et qui débute avec le post "Drawback of stable kernel development" qui soulève les questions suivantes: kernel.org ne devrait-il pas mieux communiquer sur la sécurité des versions stables (sans avoir à lire LKML)? Communiquer sur la sécurité doit-il incomber aux seuls distributeurs? Quid des gens qui utilisent un kernel Vanilla? Faut-il gérer les releases comme la branche 2.2.x ou de nouvelles versions stables étaient mises en lignes à chaque découverte d'une faille importante?

http://lwn.net/Articles/60772/(...)

Un post qui résume bien la discussion

You're confusing reality with good practice. It's true that if you want to know about security problems in the current stable kernel, you have to read lkml. The reason is that none of the kernel release managers seem to care about security*. Through the 2.2 series, security issues tended to prompt new kernel releases in fairly short order; this theory of "if you care about security, read lkml or run a kernel released by someone who gives a damn" is recent and wrong. Vanilla kernels are kernels in their own right; they're not just a bunch of code which is provided to vendors solely as a starting point for a real system. More than that, they're the only kernels backed by Linus and company; no one cares about vendor kernels except for one vendor and its user base. And so, the end result of the security apathy of Alan and the others is that the most recent official release of Linux 2.4 contained a local root exploit for three months. Does anyone really believe this to be acceptable?

* The most prominent recent example: Alan's fix to the ptrace bug broke a number of other things, but once the code was written no one was particularly interested in fixing it.

NB: Je ne suis pas responsable des propos ci-dessus... Ils ont simplement le mérite de bien résumer le thread... Ne pas me moinsser pour eux quoi ;-)

[ Répondre ]

Posté par Mayfoev () le 22/11/2003 à 23:42. (lien). Évalué à 3.

Qualifier Michel Vaillant de film est une insulte pour toutes les vrais productions. On pourrait qualifier ca de chose plutôt.

Moui dommage que d'honorables adaptations telles que la Couleur du Mensonge (adaptation de La tache (Human Stain) de Roth, une des meilleurs romans des 10 dernières années) soient si peu vues lorsqu'elles se retrouvent en face des commerciaux Matrix episode n et Vaillant et autres (et pourtant j'ai une certaine passion pour le sport automoblie)

Si l'adaptation du livre est perfectible, la Couleur du Mensonge est au moins à voir pour les extraordinaires performances de Nicole Kidman, Anthony Hopkins, et Ed Harris. Qui seront hélas trop peu vues. Gary Sinise est hélas un peu transparent. L'histoire d'une vie de mensonge, un mensonge, un silence qui aurait pu tout changer.

Je sais que c'est HS, mais si vous découvrir un petit trésor, allez passer 108 minutes devant ce film (distribué par la boite de Besson, Europa).

[ Répondre ]

Posté par Mayfoev () le 14/11/2003 à 14:15. (lien). Évalué à 1.

Il s'agit en fait du répertoire iso par rapport au répertoire Mandrake.
En fait je comprends ta confusion, les dizaine liens mirroirs mènent vers l'arborescence i586, et il n'y a que les quelques liens mirroir primaire et secondaire (discrets) qui mènent vers le répertoire Mandrake.

[ Répondre ]

Posté par Mayfoev () le 14/11/2003 à 14:10. (lien). Évalué à 1.

Aie on en parlait dans d'autres threads... Bon désolé pour ce post "redondant" comme on dit chez /.

[ Répondre ]

Posté par Mayfoev () le 14/11/2003 à 14:04. (lien). Évalué à 2.

Ca veux dire que les ISO "publiques" ne sont pas les mêmes ? Il y'a eu correction du bug avec les lecteur LG ?

Non, j'ai comparé les md5sum, et les isos publiques sont les mêmes que celles sorties voilà un mois sur le MandrakeClub. Finalement il n'y a donc pas eu de nouveaux isos, comme MandrakeSoft l'avait indiqué juste après l'alerte LG.

[ Répondre ]

Posté par Mayfoev () le 01/11/2003 à 13:49. (lien). Évalué à 4.

C'est un bogue d'installation ou du cache XUL.

Sans donner en détail les raisons de ces deux problèmes, voilà les solutions:
- si c'est le cache XUL, autant l'effacer... de mémoire sous win2k c'est dans le répertoire de ton profil (par défaut Documents and Settings//Application Data/Mozilla/<profilMozilla>/trucbidule.slt/ ... le fichier s'appelle XUL.mfl
- si ce n'est pas le cache XUL mais un bogue d'installation (mauvais dézippage du xpi), ou reste de la 1.4.1
a) repasser en anglais (redémarrage de Mozilla)
b) effacer la langue française (redémarrage de Mozilla optionnel)
c) installer la langue française (redémarrage de Mozilla)

[ Répondre ]

Posté par Mayfoev () le 01/11/2003 à 02:34. (lien). Évalué à 6.

Juste une anecdote. En fait la sortie des traductions date d'il y a une petite semaine, mais la release est restée assez confidentielle jusqu'à la mise à jour de frenchmozilla.org mercredi, et ce laps de temps a ainsi servi à tester la présence de coquille, qui aurait pu échapper à notre vigilance.

[ Répondre ]

Posté par Mayfoev () le 14/10/2003 à 17:35. (lien). Évalué à 7.

C'est bien ce que j'ai fait.. Et c'est intégré...

Je comptais simplement en faire profiter Mandrake aussi, un peu plus tôt. Quand à savoir si Mandrake n'intègre que les patches de ses outils propres, les packages XFree86 de Mandrake témoignent justement que ils ont subi aussi certains patches utilisateurs.

[ Répondre ]

Posté par Mayfoev () le 14/10/2003 à 17:26. (lien). Évalué à 10.

Il est juste dommage que Mandrake tienne si peu compte de certaines catégories de bogues dans son Bugzilla.

Ainsi je ne compte plus les semaines et les mois depuis l'ouverture un bogue XFree86 que j'ai signalé et patché... J'ai même posté sur la liste cooker.. Sans résultat.

Bien sûr à termes il sera inclus dans la distribution puisque XFree86 l'a commité le jour même.. C'est juste qu'il faudra attendre une future synchonisation avec l'arbre CVS d'XFree.

Tout ça juste pour pas me donner un accès contributeur...

Bon ok -> []

[ Répondre ]