Bon, je vais faire une réponse sérieuse malgré tout.
Il n'y a aucun risque étant donné l'évaporation que subissent les trou noirs.
Voir à ce sujet http://fr.wikipedia.org/wiki/Évaporation_des_trous_noirs
Où l'on voit que le temps d'évaporation serait proportionnel à la masse au cube du trou noir, donc pour les nano-trou-noir dont il est question ici ce temps est ridiculement petit.
Il faut un jre 1.5, mais pas forcément celui de Sun.
Il faudrait tester ce que ça vaut avec une jvm libre basée sur classpath, ou avec icedtea qui pré-figure le futur java7.
Essaye plutôt le paramètre -dumpstream de mplayer, ça te balance sur le disque les données telles que récupérées depuis le serveur, après tu es à ton aise pour regarder ou réencoder le fichier récupéré.
Avec fuse ( http://fuse.sourceforge.net/ ) tu peux avoir par exemple un ftpfs ou un sshfs monté directement dans ton système de fichier, et doncaccessible de façon transparente à tous les programmes (mais avec la lenteur que suppose un transfert réseau).
En plus les programmes fuse peuvent être lancés par un utilisateur normal, donc pas besoin de droits root.
(presque) tous les programmes KDE savent faire ça grâce à l'abstraction des kioslaves.
Je fais ça tout le temps, connection sftp ouverte dans konqueror, j'ouvre directement un fichier dans kwrite qui sait où le réenregistrer, comme si c'était en local.
Je pense qu'il y a un équivalent avec Gnome, mais je ne connais pas.
(tant pis, je marche dedans)
Tout simplement que la datasheet de ti n'a rien à voir avec le sujet puisque le post (de zenitram) auquel tu répondait parlait bien de la doc d'une carte graphique.
Tu répondais: Sort un peu de ton monde, et va me prendre un datasheet d'une puce matérielle (pas un truc avec un processeur a l'intérieur, et que tu push un code dedans, une VRAI puce matérielle).
Mais les cartes graphique actuelles sont justement des processeurs embarqués.
Ton post a donc été moinssé, très logiquement, parce qu'il n'était pas pertinent par rapport à celui auquel il répondait. Pour les suivants, c'est probablement parce que tu t'en-tête.
En effet, mea culpa!
Je viens de regarder en vitesse la spécification icccm ( http://tronche.com/gui/x/icccm/ ) et on peut effectivement demander des données de type "drawable" plutôt que "text", c'est au programme d'origine à gérer les différents cas (puisqu'il s'agit ici de communication inter-processus et non pas de placer une donnée quelque part pour laisser les autres la récupérer).
Et quand tu fais la même chose et que tu colle dans kwrite (ou un autre éditeur de texte) ça colle plein de données incompréhensibles ou l'URL du fichier?
Si tu obtient bien l'image dans OOo, c'est parce qu'il sait quoi faire avec cette URL et qu'il fait un traitement supplémentaire avec le contenu du presse papier.
Encore une fois, ce n'est pas l'image qui est copiée mais l'URL de l'image.
Ça fonctionnera avec les programmes qui peuvent comprendre cette URL. Avec une URL de type file:// beaucoup comprennent, mais déjà rien qu'avec du http:// openoffice ne sait plus quoi en faire.
Et même pour des fichiers locaux gimp ne comprend pas ce qu'on lui demande.
Un vrai copier/coller d'image supposerait que les pixels de l'image seraient placés dans le presse-papier et qu'un programmes de destination comprendrait qu'il s'agit là d'une image et le récupérerais en tant que tel.
Moi ce que j'utilise dans ce cas c'est le Alt-Tab: commencer le drag avec la souris puis, sans relâcher, je fais Alt-Tab jusqu'à arriver à la bonne fenêtre. On peut d'ailleurs aussi faire des changement de bureau pour atteindre la bonne fenêtre.
Mon test, ouvrir konqueror sur une page web avec une image, ouvrir un document dans kword. Glisser-déposer de l'image depuis la page web vers mon document, et paf. Où est le problème ?
Ben, justement, ce n'est pas du copier/coller, c'est du glisser/déposer. Le copier/coller ce serait si les données de l'image (et pas une URL) se trouvaient effectivement dans le presse-papier pour être collées ailleurs. Je pense que ça fonctionne entre applications KDE, mais celui de base de X ne gère que le texte.
Il manque le module noyau du driver propriétaire nvidia.
Tu a probablement installé automatiquement un nouveau noyau pour lequel il n'y a pas de module pré-compilé.
Tu peux essayer de redémarre sur l'ancien noyau pour avoir un système qui fonctionne.
La bonne solution en général est d'installer un des paquets
dkms-nvidia71xx dkms-nvidia96xx dkms-nvidia97xx
suivant ton matériel. il y a trois version différentes du driver nvidia qui supportent du matériel dfférent:
$ rpm -qa|grep nvidia
pour voir ce qui est déjà installé
$ urpmq -y dkms-nvidia
pour voir ce qui est disponible (installe celui correspondant à ce que tu as d'installé).
Avec ça, lors d'une mise à jour de noyau, le module sera recompilé automatiquement (c'est l'intérêt de dkms).
LaTeX (si c'est bien de lui que tu parle) n'est pas un traitement de texte, c'est un formateur de texte ou tu écrit des commandes de mise en forme de ton document puis tu le compile avec le programme TeX.
Dans la mdv2006 c'est dans le(s) paquet(s) tetex(-*).
Si tu veux un truc plus proche d'un traitement de texte, il y a LyX (paquet lyx, cf http://www.lyx.org ) qui propose l'édition de documents LaTeX de façon visuelle.
Il y a aussi texmacs, qui n'est pas basé sur LaTeX, mais qui propose un mode d'édition wysiwyg proche d'un rendu LaTeX.
il est communément admis, qu'à structure sociologique constante, un échantillon plus gros est plus représentatif.
Cela suppose que la méthode de sélection du contenu de l'échantillon soit parfaitement aléatoire sur l'ensemble de la population considérée. Or ce n'est vraisemblablement pas le cas ici (comportement différent vis à vis du javascript), l'échantillon est biésé de par la technique d'échantillonage même.
On pourrait aussi penser à un équivalent de screen mais pour X11, c'est à dire qu'un programme lancé au travers de ... appelons le xscreen, peut survivre même si le serveur X quitte, et peut être redirigée de manière transparente sur un autre serveur X. Ça pourrait être sacrément pratique.
Un programme ne peut pas fonctionner depuis la SWAP, quand il a besoin de s'exécuter il faut que l'OS mette dans la RAM toutes les pages que le programme veut lire/écrire. Donc même s'il était possible de placer un programme dans la SWAP à son démarrage (ce qui était plus ou moins l'intérêt du sticky bit sur les vieux unix) dès qu'il faudrait l'exécuter il faudrait le redéplacer vers la RAM.
Et avec un programme qui ne tient pas entièrement en RAM (comme ton cas) c'est particulièrement problématique car le système passe son temps à déplacer de la RAM à la SWAP et réciproquement suivant les segments de mémoire que le programme utilise.
Comme il a été dit plus haut tu devrait faire ton rsync en plusieurs fois. Si tu n'a pas de liens physiques à préserver c'est jouable.
# Évaporation
Posté par wismerhill . En réponse au journal Un trou noir qui absorbe la Terre.... Évalué à 4.
Il n'y a aucun risque étant donné l'évaporation que subissent les trou noirs.
Voir à ce sujet
http://fr.wikipedia.org/wiki/Évaporation_des_trous_noirs
Où l'on voit que le temps d'évaporation serait proportionnel à la masse au cube du trou noir, donc pour les nano-trou-noir dont il est question ici ce temps est ridiculement petit.
[^] # Re: liens directs
Posté par wismerhill . En réponse au journal Liens symboliques persistants ??? Idée de workflow pour les e-mails.. Évalué à 2.
Si tu veux le faire "from scratch" ben l'appel système link est là
http://www.linuxmanpages.com/man2/link.2.php
[^] # Re: liens directs
Posté par wismerhill . En réponse au journal Liens symboliques persistants ??? Idée de workflow pour les e-mails.. Évalué à 1.
Il y a peut-être (j'ai la flemme de chercher) déjà un truc équivalent dans le paquet disponible sur kde-apps:
http://kde-apps.org/index.php?xcontentmode=287
[^] # Re: Java
Posté par wismerhill . En réponse à la dépêche Correction grammaticale dans OpenOffice.org. Évalué à 2.
Il faudrait tester ce que ça vaut avec une jvm libre basée sur classpath, ou avec icedtea qui pré-figure le futur java7.
# dumpstream
Posté par wismerhill . En réponse au message Pb pour enregistrer un flux dans un fichier avec mencoder. Évalué à 2.
Exemple:
$ mplayer -dumpstream -dumpfile cp_2008_4.mov rtsp://unistream.unil.ch/unicom/cp_2008/cp_2008_4.mov
[^] # Re: Discussion tres interessante
Posté par wismerhill . En réponse au message Ces détails de l'interface windows qui manquent sous Linux.... Évalué à 3.
[^] # Re: on n'est pas vendredi mais
Posté par wismerhill . En réponse au message Ces détails de l'interface windows qui manquent sous Linux.... Évalué à 1.
T'es gonflé là avec ton argumentation absée sur les aptitudes de ta grand-mère. Tu trouve que c'est représentatif du grand public?
[^] # Fuse pour tous
Posté par wismerhill . En réponse au message Marre des transferts ftp faits à la main. Évalué à 3.
Avec fuse ( http://fuse.sourceforge.net/ ) tu peux avoir par exemple un ftpfs ou un sshfs monté directement dans ton système de fichier, et doncaccessible de façon transparente à tous les programmes (mais avec la lenteur que suppose un transfert réseau).
En plus les programmes fuse peuvent être lancés par un utilisateur normal, donc pas besoin de droits root.
# KDE et les kioslaves
Posté par wismerhill . En réponse au message Marre des transferts ftp faits à la main. Évalué à 4.
Je fais ça tout le temps, connection sftp ouverte dans konqueror, j'ouvre directement un fichier dans kwrite qui sait où le réenregistrer, comme si c'était en local.
Je pense qu'il y a un équivalent avec Gnome, mais je ne connais pas.
[^] # Re: ancien...
Posté par wismerhill . En réponse au message Pb : disque dur vide mais détecté. Évalué à 2.
[^] # Re: Polémique
Posté par wismerhill . En réponse à la dépêche Un point sur le projet Nouveau. Évalué à 5.
Tout simplement que la datasheet de ti n'a rien à voir avec le sujet puisque le post (de zenitram) auquel tu répondait parlait bien de la doc d'une carte graphique.
Tu répondais:
Sort un peu de ton monde, et va me prendre un datasheet d'une puce matérielle (pas un truc avec un processeur a l'intérieur, et que tu push un code dedans, une VRAI puce matérielle).
Mais les cartes graphique actuelles sont justement des processeurs embarqués.
Ton post a donc été moinssé, très logiquement, parce qu'il n'était pas pertinent par rapport à celui auquel il répondait. Pour les suivants, c'est probablement parce que tu t'en-tête.
[^] # Re: bash
Posté par wismerhill . En réponse au message Colorer stderr. Évalué à 2.
"$@"
(man bash, section PARAMETERS)
[^] # Re: A moi, a moi
Posté par wismerhill . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 3.
Je viens de regarder en vitesse la spécification icccm ( http://tronche.com/gui/x/icccm/ ) et on peut effectivement demander des données de type "drawable" plutôt que "text", c'est au programme d'origine à gérer les différents cas (puisqu'il s'agit ici de communication inter-processus et non pas de placer une donnée quelque part pour laisser les autres la récupérer).
[^] # Re: A moi, a moi
Posté par wismerhill . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 2.
Si tu obtient bien l'image dans OOo, c'est parce qu'il sait quoi faire avec cette URL et qu'il fait un traitement supplémentaire avec le contenu du presse papier.
[^] # Re: Exemple de script
Posté par wismerhill . En réponse au message Remplacement de fichiers. Évalué à 2.
[^] # Re: A moi, a moi
Posté par wismerhill . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 2.
Ça fonctionnera avec les programmes qui peuvent comprendre cette URL. Avec une URL de type file:// beaucoup comprennent, mais déjà rien qu'avec du http:// openoffice ne sait plus quoi en faire.
Et même pour des fichiers locaux gimp ne comprend pas ce qu'on lui demande.
Un vrai copier/coller d'image supposerait que les pixels de l'image seraient placés dans le presse-papier et qu'un programmes de destination comprendrait qu'il s'agit là d'une image et le récupérerais en tant que tel.
[^] # Re: Le (vrai) Drag and drop!
Posté par wismerhill . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 5.
[^] # Re: A moi, a moi
Posté par wismerhill . En réponse au journal Les config mal foutues dans les logiciels libres. Évalué à 2.
Ben, justement, ce n'est pas du copier/coller, c'est du glisser/déposer. Le copier/coller ce serait si les données de l'image (et pas une URL) se trouvaient effectivement dans le presse-papier pour être collées ailleurs. Je pense que ça fonctionne entre applications KDE, mais celui de base de X ne gère que le texte.
[^] # Re: Marche toujours pas
Posté par wismerhill . En réponse au message Problème de démarrage de Mandriva 2007.1 Spring en mode console après des mises à jour avortées. Évalué à 2.
Tu a probablement installé automatiquement un nouveau noyau pour lequel il n'y a pas de module pré-compilé.
Tu peux essayer de redémarre sur l'ancien noyau pour avoir un système qui fonctionne.
La bonne solution en général est d'installer un des paquets
dkms-nvidia71xx dkms-nvidia96xx dkms-nvidia97xx
suivant ton matériel. il y a trois version différentes du driver nvidia qui supportent du matériel dfférent:
$ rpm -qa|grep nvidia
pour voir ce qui est déjà installé
$ urpmq -y dkms-nvidia
pour voir ce qui est disponible (installe celui correspondant à ce que tu as d'installé).
Avec ça, lors d'une mise à jour de noyau, le module sera recompilé automatiquement (c'est l'intérêt de dkms).
[^] # Re: Déjà, il te faut un éditeur de texte
Posté par wismerhill . En réponse au message comment ecrir un script shell en linux. Évalué à 4.
[^] # Re: trop tard...
Posté par wismerhill . En réponse au journal eeePC d'Asus, le carton ?. Évalué à 2.
Hum, j'imagine que tu as inversé les prix.
# pas un traitement de texte
Posté par wismerhill . En réponse au message traitement de texte LATEX. Évalué à 2.
Dans la mdv2006 c'est dans le(s) paquet(s) tetex(-*).
Si tu veux un truc plus proche d'un traitement de texte, il y a LyX (paquet lyx, cf http://www.lyx.org ) qui propose l'édition de documents LaTeX de façon visuelle.
Il y a aussi texmacs, qui n'est pas basé sur LaTeX, mais qui propose un mode d'édition wysiwyg proche d'un rendu LaTeX.
[^] # Re: Imprécision
Posté par wismerhill . En réponse au journal Vista fait un bide, MacOS et Linux une percée !. Évalué à 2.
Cela suppose que la méthode de sélection du contenu de l'échantillon soit parfaitement aléatoire sur l'ensemble de la population considérée. Or ce n'est vraisemblablement pas le cas ici (comportement différent vis à vis du javascript), l'échantillon est biésé de par la technique d'échantillonage même.
[^] # Re: Retourner les fenêtres
Posté par wismerhill . En réponse à la dépêche Sortie de KDE 4.0. Évalué à 2.
C'est exactement le principe de vnc.
# Les programmes fonctionnent en RAM
Posté par wismerhill . En réponse au message Utiliser directement la SWAP. Évalué à 3.
Et avec un programme qui ne tient pas entièrement en RAM (comme ton cas) c'est particulièrement problématique car le système passe son temps à déplacer de la RAM à la SWAP et réciproquement suivant les segments de mémoire que le programme utilise.
Comme il a été dit plus haut tu devrait faire ton rsync en plusieurs fois. Si tu n'a pas de liens physiques à préserver c'est jouable.