wismerhill a écrit 2608 commentaires

> S'il manque un require, ça ne marche pas. L'évaluation de "ça ne marche pas" n'est pas un avis polique. C'est un constat technique.

Même chose avec les suggest, si on les installe ça marche mieux, il y a plus de fonctionnalités puisque des composants non essentiels sont alors disponibles. C'est aussi un constat technique.

Par exemple: k3b fait usage de cdrecord/wodim, cdrdao et growisofs, mais il peut se passer de tous (on peut utiliser k3b pour faire de l'extraction de cd audio par exemple). Donc à ce niveau-là, utiliser le suggest pour indiquer que k3b permettra de faire plus de choses avec ces programmes est utile, et c'est bien au niveau du paquet que cette information est intéressante, parce qu'elle est vraie qu'elle que soit la distribution.

> Je vais probablement être moinsé pour ça, mais je remarque que, quoi qu'on en dise, Apple a une nouvelle fois montré la voie

Hum, KDE le faisait avant Apple, après tout, webkit est un fork de khtml (qui existe depuis KDE 2.0).

Argh, l'URL est pas passée correctement avec l'accent, la version sans accent redirige correctment côté wikipedia:
http://fr.wikipedia.org/wiki/Evaporation_des_trous_noirs

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.

Je ne comprend pas ta remarque.
Si tu veux le faire "from scratch" ben l'appel système link est là
http://www.linuxmanpages.com/man2/link.2.php

Pour konqueror ça peut surement se faire facilement avec un service menu.

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

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é.

Exemple:
$ mplayer -dumpstream -dumpfile cp_2008_4.mov rtsp://unistream.unil.ch/unicom/cp_2008/cp_2008_4.mov

C'est parce que ce n'est pas possible, sauf si tu restreint considérablement la liberté des différentes distributions.

Maintenant on peut ne pas être d'accord mais s'il vous plait, arrêtez les messages argumentés sur base d'habitudes/préférences personnelles.

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?

Je complète ma réponse:

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.

C'est un très vieux liveCD que tu as sorti pour qu'il soit nécessaire de créer les noeuds à la main?

(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.

$* ne fera probablement pas ce que tu veux par rapport aux caractères spéciaux et à la séparation des mots. Ce qui faut utiliser dans ce cas-là c'est

"$@"

(man bash, section PARAMETERS)

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.

Et en plus il lance les commandes ls et sed pour rien. bash fait très bien tout ça sans aide extérieure.

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).

kwrite est tout à fait adapté, ce n'est d'ailleurs qu'une version simplifiée de kate (ils utilisent le même composant d'édition de texte).

(299 euros la machine seule, ou 199 Euros avec l'abonnement 3G chez SFR, 39 Euros /mois)

Hum, j'imagine que tu as inversé les prix.

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.