Nicolas Melay a écrit 113 commentaires

Error: Nombre: Unknown statement.

s/notamment/notablement/ ?

(et s/leur/leurs/, mais bon...)

Assis sur ma chaise de bureau je regarde vers le nord, et j'aurais plutôt tendance à dire que mon écran est orienté vers le sud (il envoie une image en direction du sud).

Et pour ôter toute ambiguïté, je peux dire simplement que mon écran est orienté le dos au nord.

...on continue à développer Symphony, le fork OOo maison.

http://symphony.lotus.com/

Ça serait sympa qu'ils se mettent tous autour d'une table et qu'ils discutent un peu entre adultes.
Si au final ils veulent tous se friter avec MS (bon peut-être pas Novell c'est vrai), c'est quand même un peu crétin d'y aller en file indienne.

Le top du top pour les captures d'écran, c'est un objet COM Microsoft Paint emballé dans un fichier Word.
C'est ce que mes sympatiques collègues m'envoient 9 fois sur 10.

À noter que je crois avoir constaté au fil des années que les fumeurs usent les lecteurs optiques plus vite que les non fumeurs.
Ce n'est qu'une impression, je n'ai pas de chiffres, mais bon si tu fumes tu sais ce qui te reste à faire. :)

Oui, c'est vraiment hallucinant à quel point les mauvaises habitudes ont la vie dure.
Le RAID 5 a eu son heure de gloire, à l'époque où les disques étaient hors de prix et les alternatives limitées.
Aujourd'hui tout pousse à le fuir : mauvaises performances en écriture, surcoût sur les petites configs, extension de volume souvent impossible, etc.

Et malgré ça, tous les revendeurs et mainteneurs à qui j'ai eu affaire proposent systématiquement des configs RAID 5 à leurs clients.
Récemment je me suis engueulé sévèrement avec l'un d'eux qui a réussi à en refourguer une (config RAID 5) à une de nos agences dans mon dos, en dépit de mes instructions.
Raison invoquée: il a appelé HP et ils lui ont dit que oui le RAID 5 c'est mieux [que le RAID 10].
Il y a des jours comme ça j'aimerais bien que mon téléphone me permette davantage d'interactivité...

Les offices de brevets considèrent surtout que plus il y a de brevets déposés, et plus ils ont de pognon qui rentre.
Et bien sûr plus il y a de brevets, plus il devient difficile de mettre un produit sur le marché, donc plus il faut déposer de brevet ou souscrire à des portefeuilles de brevets pour se protéger, et donc plus il y a de brevets déposés...

Quand on voit les dégats de ce système sur l'agriculture, la pharmacie et bien sûr l'informatique, c'est vraiment à vomir...

Encore faut-il être capable de réagir dans les 2 secondes en devant l'urgence !

Faut utiliser la touche '*' d'à côté de la touche Entrée, c'est plus sûr.

Ah? Je l'ai fait il y a quelques mois pourtant, et ça s'était plutôt bien passé.
Enfin comme une mise à jour de Mandriva quoi...
C'est dans la 10.1 que le rpm de la glibc prétendait apporter une version supérieure à la réelle ?

Ça y est, il y est : ftp://ftp.free.fr/mirrors/ftp.openoffice.org/localized/fr/2.(...)
J'imagine que l'annonce sur fr.openoffice.org a été repoussée le temps que les miroirs français se mettent à jour. Elle ne devrait plus tarder maintenant.

Pour ma part, j'en étais resté à Java 2.
Merci de ne pas confondre le langage et ses implémentations (Java SE/ME/EE chez Sun).

Sun sème déjà la confusion*, pas la peine d'en rajouter.

*: La dernière version de J2SE disponible est connue comme la 1.5.0 ou la 5 tout court, au choix.
Toute ressemblance avec le système de numérotation des versions de SunOS/Solaris du même éditeur...

Ça a l'air intéressant comme outil, mais je ne vois pas comment ça peut m'aider a réinstaller un paquet déjà présent.

D'après la description, urpmi.recover permet un suivi des (dés)installations de paquets et rollback éventuel, mais rien concernant l'intégrité des paquets actuellement installés.

J'ajoute le lien vers la page bugzilla, ouverte depuis mai 2005:
http://qa.mandriva.com/show_bug.cgi?id=16112

Autre hack possible: modifier la base de données rpm directement (sans utiliser rpm) et y changer le numéro de version installé (en ajoutant un caractère?).
De cette manière, une exécution consécutive de urpmi identifierait la version installée comme non-à jour et autoriserait la mise à jour.
Ça parait tordu mais ça a l'avantage d'être direct.
Par contre modifier la bdd rpm à la main (ou avec les db-utils qui vont bien?), ça risque de ne pas être de la tarte...

Encore une autre piste: regénérer un paquet rpm à partir de l'installation courante.
Est-ce possible?
Y a-t-il moyen de reconstruire un rpm à partir de la bdd rpm et des fichiers installés, tout en bidouillant son numéro de version à la volée ?

Qu'en pensez-vous?

...je viens de voir que la réinstallation de paquet est en tête des fonctionnalités demandées pour urpmi :
http://qa.mandriva.com/twiki/bin/view/Main/UrpmiDev

Pendant la finale de la coupe du monde j'étais au ciné devant Primary Colors (John Travolta, Emma Thompson, excellent film).
5 dans la salle, un vrai bonheur.

Mais depuis j'ai appris ai aimer le foot... :-/

Au passage, si tu tentes une mise à jour vers la Mandriva 2006.0 via urpmi, commence par mettre à jour la glibc avant tout autre paquet !

De mémoire :
Mandrake 10.1 contient une glibc dont les infos rpm sont incorrectes et indiquent un numéro de version supérieur à la réalité.
Mandrakesoft / Mandriva n'a pas jugé nécessaire à l'époque de diffuser une glibc corrigée...
Résultat, si lors de la mise à jour vers la 2006.0 un paquet qui dépend *réellement* de cette nouvelle version de glibc est mis à jour avant la glibc elle-même, il ne fonctionnera plus.
Et comme c'est le cas des paquets perl il me semble, il suffit de faire un « urpmi urpmi » pour ne plus avoir de urpmi !

En clair urpmi dépend de la nouvelle version de perl, qui dépend de la nouvelle version de glibc, qui selon la base rpm est installé, alors que ce n'est pas vrai.

Mandrivake 10.1 n'est plus maintenue depuis le 28 février 2006 (http://www.mandriva.com/fr/security/productlifetime).
Ce n'est donc pas une distrib vieille de deux ans, mais d'à peine plus de 2 mois.

Je ne vois vraiment pas où l'utilisation du SMTP peut poser un problème de sécurité.
Là il s'agit juste de l'utiliser comme moyen de faire communiquer des applications, et çe me semble tout à faire pertinent.

Si côté CMS tout message SMTP entrant est accepté sans restriction, là oui c'est un problème, mais ce n'est pas lié à l'utilisation sur SMTP.

Pour la sécurité on peut restreindre les clients SMTP autorisés, jouer sur des règles de pare-feu, utiliser des messages signés, encapsuler dans du SSH, etc.
Il existe sans-doute une extension SSL du protocole SMTP, mais bon si le but est de permettre au client SMTP le plus basique qui soit de publier des infos, ça risque de ne pas le faire.

Soit on RTFM, soit on STFW.
RTFW, ça me semble tout de même un peu démesuré...

« Copy Controlled » ne veut pas nécessairement dire qu'un rootkit sera installé par l'autorun Windows.
À ma connaissance seul SONY est allé jusque là pour l'instant, et ils ont semble-t-il fait marche arrière.

Cela veut simplement dire que le support ne respecte pas le standard CD audio (Red Book) défini par Philips.
Après, la palette de saloperies que les majors sont prêtes à nous faire subir est très large, du CD difficilement lisible au piratage de PC effectivement.

Pour la petite histoire, je me suis fait avoir sur l'achat du même CD et dans la même enseigne.
C'était un cadeau pour ma s½ur, donc je ne l'ai pas ramené (difficile d'offrir et reprendre), mais si cela avait été un achat perso, je n'aurais pas hésité.
Le CD n'est pas rippable proprement (du moins je n'ai pas réussi), donc elle ne peut pas l'écouter sur son balladeur MP3.

Depuis j'essaie de faire gaffe lors de chaque achat.
Dans ton cas, je te conseille de vérifier que la protection ne gêne aucune des utilisations que tu souhaites faire de ce « CD ».
Sinon, et à fortiori si le label « Copy Controlled » était masqué, il ne faut pas hésiter à le ramener ou à porter plainte.

En fait j'ai déjà testé. :)

Non ça ne marche pas.

Deux cas de figure :

1) head dans le pipe nommé
La sortie du pipe nommé arrive sur la sortie standard après la sortie de la commande principale.

Enfin en clair, route | tee >(head -n 2) | tail +3 ne fonctionne pas, les lignes d'entêtes apparaissent en fin de commande.
Et il ne s'agit pas juste d'un problème de timing, route | tee >(head -n 2) | (sleep 5; tail +3) donne le même résultat (mais 5 secondes plus tard ;)).

2) tail dans le pipe nommé
Dans l'autre sens, route | tee >(tail +3) | head -n 2 ne me renvoie que les entêtes.
Le head s'applique en fait à la sortie des 2 commandes.

Je ne suis pas 100% sûr de mon interprétation du résultat, mais enfin ce qui est certain c'est que ça ne fonctionne pas.

Prends-moi pour un c..

Je faisais plutôt allusion à fgets/getline.

Ouais bien vu.
Ça reste difficilement portable vers d'autres systèmes, d'autres locales, etc.