karteum59 a écrit 863 commentaires

Attention, ceci va ressembler à un troll mais c'est une vraie question :

La dernière fois que j'avais essayé Fedora (ce qui doit dater d'il y a à peu près 2 ans), yum se trainait (vraiment) comme un veau par rapport à urpmi/apt. Cette lenteur était insupportable (mon PC n'est pas une bête de course non plus). J'avais essayé (et adopté) Smart à la place, mais je trouvais quand même ça moins abouti que apt/aptitude/synaptic.

Y-a t-il eu du progrès sur ce point (notamment au niveau des performances) ?

ACDC !

OK... --> [] :)

C'est clair,
Comme alternative légère, autant Opéra avait le défaut de n'être pas libre, autant maintenant que Webkit se répand je vois de moins en moins quel avenir il peut y avoir pour Dillo...

A ce sujet, j'ai découvert Stackless Python il y a peu (http://www.stackless.com/ )
Est-ce que qqun sait s'il y a une coopération avec le Python legacy ?

Quelqu'un a une capture d'écran du file sélector de cette nouvelle version ? ou ça reste l'horrible truc dispo avec firefox ?

Pour résoudre le problème (sur Firefox en tout cas), va dans "about:config" et change la clé "ui.allow_platform_file_picker" à false

(N.B.: tu trouveras d'autres astuces dans le genre sur http://gentoo-wiki.com/HOWTO_Integrate_Firefox_with_KDE )

Regarde là-dedans (tous ceux avec "good" valent le coup d'oeil. Après, je ne connais pas AIR donc je ne sais pas dans quelle mesure c'est comparable ou pas)
http://www.geocities.com/SiliconValley/Vista/7184/guitool.ht(...)

En dehors des ténors super connus (QT, GTK, SWT...), il y en a d'autres que j'ai aussi bien aimé. Par exemple JUCE : http://www.rawmaterialsoftware.com/juce/
Fox-toolkit était également sympathique.
Ultimate++ semble pas mal aussi (mais je n'ai pas bcp essayé)

Eeeh beh, les temps sont durs pour les trolls (un vendredi, qui plus est !)
Car que reste t-il comme argument/exemple solide à GNewSense par rapport à Debian ? (Ubuntu installe des choses non-libres par défaut, Debian non (à ma connaissance))

Pourquoi basée sur Ubuntu plutôt que directement sur Debian ? (et d'ailleurs, qu'est-ce qui ne va pas avec Debian ? Il me semble que tout ce qui est non libre est isolé dans non-free...)

Petites questions de béotien en montage vidéo (non, ce ne sont pas des trolls :)
- que pensez-vous de Blender pour faire du montage vidéo ? (je suis débutant en Blender, mais il me semble qu'il pourrait jouer ce rôle même si ce n'est pas sa finalité première)
- pour ce qui est des effets en temps réel via OpenGL, j'avais entendu parler de Jahshaka et ça avait l'air plutôt sympa. Mais en pratique ça donne quoi ?
- y'a aussi LiVES qui semble pas mal du tout...

Moi je trouve que les extrémistes devraient être fusillés ! :)

Ce ne serait pas un peu équivalent au EBML (utilisé dans le format MKV) ?
http://ebml.sourceforge.net/

ils cherchent à le mettre en tôle
C'est clair que vu l'état des prisons françaises, l'expression n'est pas totalement usurpée... :)

OK je ->[]...

Des gens plus compétents que moi et très impliqués sur le sujet (au hasard, Keith Packard) ont conclu que le problème des sockets était un non-problème avec très peu d'overhead. L'overhead est ailleurs (apparemment, la nature de la XLib, ses appels bloquants et son caching inapproprié seraient davantage problématiques, d'où l'apparition de XCL/XCB). j'ajoute que sur une machine locale, il s'agit de sockets UNIX et que l'extension XSHM permet d'utiliser de la mémoire partagée (donc d'éviter les transfert que tu décris). Même les projets destinés à l'embarqué (comme feu PicoGUI ou les plus actuels Xynth/XFast) utilisent une architecture client/serveur comparable.

Par contre, j'ai tendance à être pas mal de l'avis de John Smirl (qui critiquait les efforts placés dans EXA dans la mesure où tous les chips actuels ont des capacités 3D, et qui préconisait +/- une couche d'abstraction 100% EGL/OpenGL à la place, surtout que les avancées d'OpenGL (shaders...) permettent d'imaginer des applications inconcevables par le passé, au hasard http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf ).

L'architecture de DirectFB 2.0 semble aussi s'orienter vers l'utilisation de backends (comme OpenVG) exploitant davantage l'accélération matérielle http://directfb.org/wiki/index.php/DirectFB_2.0:_Efficient_2(...)

celui-ci est plutôt sympa : http://www.ldlc.com/fiche/PB00063095.html (77€). Personnellement j'en ai trouvé un chez un fournisseur local à moins de 30€.
Y'a moyen de savoir où ? :)

celui-ci est plutôt sympa : http://www.ldlc.com/fiche/PB00063095.html (77€). Personnellement j'en ai trouvé un chez un fournisseur local à moins de 30€.
Y'a moyen de savoir où ? :)

http://billposer.org/Software/msort.html

le top reste d'utiliser un système de fichiers adapté répartissant les écritures
Normalement ça ne devrait rien changer car les CF devraient normalement intégrer la gestion du wear-levelling dans le hard (contrairement à une bête mémoire NAND sur un système embarqué, qui peut dans ce cas nécessiter l'emploi de JFFS2 ou équivalent).

Par contre, le wear-levelling ne fonctionne évidemment que s'il reste de l'espace disponible. Lorsque la carte est quasi-pleine, ça marche beaucoup moins bien...

J'ai eu la même idée, mais attention : Ce n'est gratuit que la 1e année (après c'est 6€ / an) ! Je ne dis pas que c'est très cher, mais simplement si c'est la gratuité qui t'a fait faire la démarche, pose-toi bien la question de savoir si tu comptes le garder (donc payer) après ou pas. Car si c'est juste pour jouer tant que c'est gratuit, alors évite de l'utiliser pour ton jabber/mail principal sinon tu vas en être dépendant (si tout le monde te contacte à cette adresse...).

La première dose est gratuite... :)

Deux petites choses :
- si tu payes ton rechargement via une carte bancaire, peut-on encore parler d'anonymat (vu qu'on peut tout à fait faire une corrélation entre n° de Navigo et n° de carte)... ?
- je crois que le Navigo Découverte ne marche pas avec les Vélib's

Tu trouves une doc sur le sujet ici :
http://linux-wizard.net/howto.php?section=1&key=urpmi_pa(...)

ne m'empêche pas de penser plus largement au logiciel libre et pas seulement à ma pomme

Joli... ;o)

Pour OpenOffice, soit, ils ne vont pas tout refaire maintenant.
Pour Abiword/KOffice, le support .doc était largement plus limité, et l'ouverture de ces documents est peut-être une bonne nouvelle pour pouvoir enfin se passer du lourdingue OpenOffice ! (surtout sur des vieux PCs retapés)

Le meilleur compromis alors c'est peut-être la LGPL, même pour les applis !

Avec la LGPL, je garantis que mon travail et ce qui en est dérivé reste libre, mais je n'impacte pas le choix des autres.

Avec la LGPL, je ne mets pas de limite technique à cause de choix politique (un autre exemple ? Tiens, suppose que je veuille expérimenter un noyau d'OS avec davantage de parties en user-space (sous forme de libs) et un micro-noyau tout petit. Je ne peux pas me baser sur Linux car autrement toutes les libs/applies qui se linkeront (par exemple) à ma lib qui gère le système de fichiers devront être sous GPL ! Aucun problème de cet ordre si tout était LGPL !)

Les devs BSD reconnaissent souvent eux-mêmes que la GPL leur pose problème, mais pas la LGPL... !

Par contre, je doute que les chipsets Intel puissent servir de copro pour du calcul scientifique, à l'instar des puces NViDIA
http://www.nvidia.com/object/cuda_home.html

C'est un peu hors-sujet, mais qqun sait-il pourquoi les distributions ne proposent jamais de rpm "différentiels" ? D'un binaire version n à sa version n+1, je suis sûr que la différence (via bsdiff, xdelta ou sdelta) doit être de taille minime, et pour upgrader ma Mandriva je préfèrerais de loin ne télécharger que la différence plutôt que les packages entiers (surtout pour des gros trucs comme KDE ou OpenOffice !)...
Peut-être qu'il y a une bonne raison de ne pas le faire ("patcher" via bsdiff a peut-être des inconvénients), mais pour l'instant je ne vois pas !