Jar Jar Binks a écrit 1200 commentaires

C'est bien la question...

Il est prévu d'aller le 15 avril à 14h au tribunal de grande instance. Une réunion est prévue jeudi midi, je tâcherai de m'informer sur ce qui s'y dira.

Excusez-moi, l'émotion me fait faire plein de fautes. « les origines de l'Hocce » « avoir crié »

Oui, il faut bien que les bots à voter aient un nom. Je suis content pour toi, tu vas gagner plein d'XP.

Comme tu l'as dit au dessus, le système de package te mets des dépendances qui sont dues à la version trouvées sur la machine qui a servi à faire la package. Elles ne sont rarement une indication réelle de la version minimum qui est en fait compatible. Elles sont une indication réelle de la version minimum qui est GARANTIE être compatible, et je t'assure qu'il ne faut pas déconner avec ça. Une bibliothèque partagée quelle qu'elle soit est un paquet difficile à maintenir.

Dis-moi, tu as lu ce que j'ai écrit avant d'y répondre ? Je sais bien que ce n'est pas tellement la tradition ici (il vaut mieux poster un truc bien bateau vite fait dès que quelqu'un dit quelque chose de plus compliqué que « Redhat sux, KDE rox », histoire de gagner des XP), mais je t'assure que ça peut servir.

Tout à fait, merci de bien faire comprendre à tous pourquoi cette licence n'est pas libre.

Si c'est pour dire « je ne sais pas de quoi je parle, mais j'ai déjà entendu dire des trucs à propos de ça, donc je vais raconter des trucs pour être intéressant », ce n'est pas la peine de poster. On a déjà assez des posts de matiasf.

Le problème de VNC, c'est qu'il est lent. Horriblement lent. Sur un terminal X branché en 100 mbits, tu es comme sur la machine locale (sauf pour la lecture vidéo, par exemple). X11 reste aussi parfaitement utiliseble sur une ligne téléphonique.

Si tu crois au discours marketing d'apple qui dit qu'il faut de la 3d accelerée pour que la 2d soit rapide, c'est que t'as rien compris.
J'en veux pour preuve le driver nv de xfree, qui a de très bonnes performances en 2D...

Il faut arrêter de délirer sur la lenteur de XFree. Oui, il est un peu lent, mais sur les opérations non critiques. Que la fenêtre mette un dixième de seconde à se déplacer alors que ça pourrait être instantané, bin oui c'est dommage, mais à côté de ça, il y a un support de la 3D plutôt rapide, l'extension Xv qui est plus rapide que ce qui se fait dans tous les systèmes propriétaires, un support des polices qui commence à vraiment bien marcher... C'est bien de continuer dan ce sens, et ça va améliorer la vitesse, mais ce n'est pas le point crucial. La gestion du projet à long terme et la portabilité (qui vont ensemble, d'ailleurs) sont deux points beaucoup plus importants.

Aujourd'hui, XEmacs a enfonce emacs de loin.
Non, aujourd'hui emacs est un bloat qui essaye de supporter l'unicode en abandonnant complètement un support correct des charsets natifs, le rendant inutilisable en pratique pour les Européens. Quant à xemacs, c'est une grosse bouse buggée qui intègre les modifications un an après emacs.
Bref, alors qu'il y a quelques années c'était un bon logiciel que j'utilisais avec plaisir, je suis devenu adepte de nano et gvim, sauf pour le code TeX (c'est quand même 'achtement bien, auctex).

Cela dit, ça n'a probablement pas grand chose à voir avec le fait qu'il y ait eu fork, mais cette volonté de chacun des groupes d'être plus reconnu que l'autre au lieu de se contenter de faire un truc correct est assez symptomatique.

C'est clair, on dirait une bande de gamins.
J'espère que ça va marcher pour Keith, et qu'il va faire un fork :
* sous LGPL,
* qui se soucie d'améliorer la vitesse,
* qui intègre correctement les patches pour les architectures non-i386.
Je pense que tout le monde a à y gagner.

Ça ne répond pas à la question. Comment fais-tu pour installer toutes les bibliothèques dont dépend un paquet ? Qui plus est, je suis assez bien placé pour savoir que quand on utilise une version de développement, il est impossible de tout recompiler en même temps, ce qui conduit à un système tout cassé si les dépendances ne l'empêchent pas. Bref, les dépendances ne sont pas là pour faire chier, mais pour traduire sous forme compréhensible par l'ordinateur l'ensemble des interactions entre les programmes. Le système peut ainsi les gérer automatiquement (par exemple avec APT ou urpmi) mais surtout il empêche de faire des conneries, et ça c'est géré dans la couche inférieure (RPM ou dpkg). Si on ne fait pas confiance à APT ou urpmi pour résoudre les dépendances (ce qui peut se comprendre, les algorithmes ne sont pas parfaits), il est parfaitement possible de s'en passer. Par contre, ne pas avoir de dépendances du tout dans la couche inférieure, c'est une catastrophe qui peut très facilement conduire à casser tout le système.

Supermount est pourri de par sa conception.

Par contre, les automonteurs (autofs et am-utils, au choix), ça marche au poil, et c'est carrément plus souple.

Premierement, a mon avis, ce n'est pas une version 0.1 pour rien.
Sans aucun doute, et je ne râle pas, je fais juste remarquer que c'est dommage.

Deuxiemement, es-tu certain d'avoir la bonne version de xine-lib ?
Il n'y a hélas pas de version minimale indiquée dans la documentation. J'ai testé avec la 1beta6, sans problème de compilation. Faudrait peut-être réessayer avec la beta8, mais j'ai la flemme de la compiler moi-même, là.

MAI SAI JAINIAL !!!!!

Dites, à part des bots à voter, on trouve quoi aujourd'hui sur linuxfr ?
Quelqu'un peut m'expliquer en quoi remarquer que le logiciel ne fonctionne pas mérite 10 votes négatifs ? J'ai l'impression en lisant cette page que je suis le seul à avoir voulu le tester, pourtant, non ?

Program received signal SIGSEGV, Segmentation fault.
---Type to continue, or q to quit---
[Switching to Thread 32771 (LWP 6828)]
0x40155063 in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x40155063 in memcpy () from /lib/libc.so.6
#1 0x40027108 in xine_get_current_frame () from /usr/lib/libxine.so.1
#2 0x0804be3b in odk_event_handler ()
#3 0x0805219c in frame_output_cb ()
#4 0x4003d21d in vo_scale_redraw_needed () from /usr/lib/libxine.so.1

Je pense simplement que le bug à été découvert il y a quelques semaines/jours et tout le monde à travailler en collaboration avant de le rendre public...
Évidemment. C'est la qualité de ce travail collaboratif que je faisais remarquer, pas la vitesse de disponibilité du correctif (d'ailleurs rien ne dit qu'ils n'ont pas mis 3 semaines à le pondre). La liste vendor-sec sert à ça.

On peut espérer que ce type de gestion des alertes de sécurité sera considéré comme un exemple. Une réponse rapide, synchronisée et efficace, nous voilà loin des sendmail et autres SSH.

Évidemment qu'il n'y a pas de cabale, j'en discutais hier soir avec le président directeur général de la cabale, d'ailleurs.

QUI EST GROS ?

D'ailleurs c'est juste à ce moment là que le robot nous a expliqué en privé que la cabale n'existe pas. Comme c'est quand même le plus au courant, on a toutes les raisons de le croire. D'ailleurs ton robot qui surveille la tribune de woof pour ne pas rater une miette a bien fait de te prévenir, ça permet de rappeler qu'il n'y a pas de cabale.

En fait, ce qui serait vraiment bien, c'est qu'il se mette à lire le fichier au lieu de l'ajouter à la liste, si et seulement si il était en pause (ou fichier fini).

Je suis chiant, hein ?

Ah tiens, c'est corrigé dans le 0.95.
Méat coule pas.