dguihal a écrit 1031 commentaires

A bon ?

Et le File_Transfer_Protocol_over_SSL (ou FTPS) et le Secure_FTP c'est pour les axel ?

Et le reget ? Je ne savais pas que HTTP permettait de recommencer un transfert là ou il s'était interrompu.

A cela j'ajouterais le mget, mpost et la possibilité majeure à mes yeux de naviguer dans une arborescence distante à partir d'une ligne de commande, et même un semblant de complétion avec un bon client.

Et si tu veux de la sécurité plus avancée tu peux utiliser Secure_FTP.

Donc je suis désolé mais ftp à encore de beaux jours devant lui

Je ne suis pas sûr que les batailles d'avocats sont ce qu'il y a de mieux pour faire avancer la technologie, au contraire même.

Après il ne faut pas que cela tourne à l'entente commerciale mais j'ai dans l'idée que ce n'est pas prêt d'arriver.

Pour l'info kopete est supposé supporter le protocole jingle

Après pour la qualité et la maturité du supporte, je ne me prononcerait pas car je n'ai pas essayé

Etant donné que tu es directement impliqué dans le projet, tu es certainement très au courant, mais selon wikipedia le 780G ne supporte que l'UVD normal (pas 2.0) ref : http://en.wikipedia.org/wiki/Unified_Video_Decoder .

donc si tu as plus de précision sur le sujet je suis très intéressé.

Exact, mais il faut préciser qu'en fait ça concerne les chips graphiques supportant UVD2 ce qui comprends les radeon HD4XXX (et +) ainsi quel le chipset AMD 785G , intéressant pour les media-center.

Oui ... Si le player supporte va-api.

Des informations complémentaires ici : http://www.phoronix.com/scan.php?page=news_item&px=NzY2M(...)

Un gros un nouveau driver basé sur Gallium3D et partiellement libre pour le chipset poulsbo d'ici quelques mois

Perso je suis utilisateur Arch également et je tiens à apporter quelque bémols pour équilibrer

Déjà c'est pas yahourt mais yaourt :)

Il n'y a pas moyen de faire une recherche permettant de trouver un fichier manquant dans le dépôt. Si je ne suis pas clair, l'équivalent d'un urpmf ou d'un apt-cache search sur un fichier.

Distribution a ne mettre entre les mains que de ceux n'ayant pas peur d'ouvrir un terminal et de lancer un nano/vim/emacs pour gérer les fichiers de configuration.

Le principe de la rolling-release j'adore mais il suppose également de la part de l'utilisateur un maintenance permanente des fichiers de configuration ( les *.pacnew et *.pacsave pour ceux qui connaissent). Perso j'utilise vimdiff pour ça, mais pareil pas Mme Michu compliant.

Bref une excellente distrib pour ma part, mais qui reste et restera de part son mode de fonctionnement un distrib d'utilisateurs avertis

A propos de paint.net :

(1) Will it ever be ported to Mac OS, Linux, or any other operating system?
(2) What about Mono support? Wouldn't that be really easy?
We will not be doing any work to directly support Mac OS, Linux, Mono, or any other platform. We are taking this stance in order to focus on the best quality and support for the platform that we develop on: Windows with .NET.

Miguel de Icaza started a paint-mono project, which is a port of Paint.NET v3.0 to the Mono framework. However, it is incomplete and does not appear to have been updated in awhile.

Source : http://paintdotnet.forumer.com/viewtopic.php?t=489

Donc pour ton soft majeur tu repasseras, et non y'a pas interop puisqu'il faut faire un portage (certainement au cause de l'API graphique différente)

Donc je le maintien pour moi ce framework est absolument inutile, donc OK pas dangereux a l'heure actuelle puisqu'il ne sert à rien ni a personne ....

Non une partie seulement de .Net est normalisée ECMA.

Il manque une grosse partie des API, celles touchant aux interfaces graphiques entre autres, d'où l'utilisation de GTK#.

La FAT32 a une réelle utilité pour l'interopérabilité, sinon bye bye les clés usb universelles, les cartes mémoires de APN et les vieilles partitions windows. Samba et ntfs-3g même s'ils ne sont pas dans le kernel à proprement parler ont également une utilité vis-à-vis de l'interopérabilité.

Maintenant cite-moi un soft majeur qui bénéficie de l'interopérabilité partielle de mono/.Net ?

Python et Ruby n'ont pas a ma connaissance une épée de damoclès signée microsoft au dessus de la tête.
Par contre se traîner un mono alors que l'ecosystème libre dispose de Perl / Python / Ruby / C++ et plein d'autres c'est à mon avis se faire chier pour que dalle.

Maintenant les devs font se qu'ils veulent c'est leur problème mais je donne mon avis.

Si il est inutile car les développeurs auraient pu faire la même chose sans mono et donc sans les incertitudes juridiques qui vont avec.
De plus quand on voit ce a quoi sert mono dans une distrib ... (f-spot / beagle, tomboy et ?? ) et qui ont tous un pendant, même dans le monde gtk/gnome on peut se poser des questions

Et comparer les deux/trois modules noyau qui réimplémentent des technos microsoft (fat32 p.ex.) avec un framework entier dédié aux techos microsoft est quelque peu osé.

Par dessus un framework complètement inutile et plus que douteux de surcroît (mono si vous n'aviez pas compris)

C'est vrai que maintenant que Arch a découpé ses paquets l'intérêt de kdemod a diminué.

Cependant je suis resté fidèle car je pense que les mecs qui bossent dessus sont vraiment à la pointe de ce que le couple Arch/KDE peut offrir, c'était déjà vrai avec leur version de KDE3 et je pense que ça prend le même chemin avec KDE4 + Chakra.

Après la première liberté, c'est celle d'avoir le choix :) .

Non, pas de KMS pour ma nvidia, mais plymouth peut maintenant passer en FrameBuffer.

Encore mieux, plymouth (le boot graphique fedora) a été porté sur Chakra / Archlinux : http://tuxce.selfip.org/informatique/plymouth-sur-archlinux (y'a même un paquet de dispo sur les dépôts kdemod je crois)
C'est encore expérimental mais perso j'ai essayé et sur ma nvidia et ça marche bien

Et gros avantages, on peut monter facilement monter un partage samba en cours de session et en tant que simple utilisateur (fuse / smb4k). J'ai jamais réussi a faire aussi propre et simple pour nfs

Comme on peut pas éditer un commentaire, voici l'équipe intel (issue de http://intellinuxgraphics.org/team.html) :

Intel Development Team
Carl Worth
Chris Wilson
Eric Anholt
Haihao Xiang
Ian Romanick
Jesse Barnes
Keith Packard
Nanhai Zou
Yakui Zhao
Zhenyu Wang

Intel Testing Team
Gordon Jin
Shuang He
Jian Zhao

Je suis pas sur qu'il y ai autant de monde a bosser sur les pilotes nouveau ou radeon

Les pilotes intel sont fais par des gens employés par intel et qui bossent a temps plein dessus. Ca aide beaucoup pour développer un pilote fiable et performant.

http://intellinuxgraphics.org/

J'ai dans l'idée aussi que les GPU intel sont loin de la complexité des GPU Ati/Nvidia

Arch utilise son propre format de paquet (des .pkg.tar.gz), et pour construire les paquets utilise un fichier nommé PKGBUILD (l'équivalent d'un fichier SPEC dans le monde rpm).

ABS en gros te permet de récupérer les PKGBUILD utilisés pour construire la version binaire de la distribution, de les modifier pour ensuite substituer les nouveaux paquets à ceux provenant des miroirs.

Lien : http://wiki.archlinux.fr/howto/archlinux/abs

Non, mais si tu utilise une Arch, donne moi, sur ton installation, le rapport entre les paquets précompilés et les autres (AUR et ABS).

A mon avis il sera très en défaveur des paquets sources.

Note : C'est pas parce que RH fourni ses src.rpm que ça en fait une distrib sources, mêmes si ABS c'est plus que ça l'idée est la même.

Peut-être parce que la plupart des gens l'utilisent sur Linux/CFS ?

Et que les autres ne sont en grande partie pas conscients que le moyen par lequel leur player joue du H264 c'est x264, quand ils se posent la question.

Si tu enlèves les possesseurs de CPU de folie et qui n'ont pas de pb de ressources, ceux qui décodent via la CG, et ceux qui cherchent pas plus que loin que le bout de leur nez (Ca marche pas, bon ben je vais changer la machine), il ne te reste pas grand monde pour trouver un bug pareil.

Arch n'est pas une distrib source !
Perso je dois avoir moins de 5% de mes paquets compilés via AUR, tout le reste c'est du binaire normal.

C'est pas parce qu'Arch te facilite la personnalisation des paquets qu'elle en devient une Gentoo (Note pour les gentooistes : Je n'ai rien contre la Gentoo)

Tu oublie de dire aussi que arts, esound et compagnie ont été crée également pour palier aux problèmes de mixage de son. Je me souviens qu'au début d'alsa dmix et plug n'étaient pas couramment configurés par défaut et encore moins connus. Il fallait donc un mixeur software car la plupart des cartes actuelles (en gros les chipset son des CM, mais aussi les cartes son dédiées et pas cher) ne possèdent pas de mixeur hard.