GeneralZod a écrit 2316 commentaires

C'est la même base de code et le format n'a pas évolué depuis, je te laisse imaginer la suite ...

Tu disais ?
http://www.amazon.com/MOTOROLA-XOOM-Android-Tablet-Wi-Fi/dp/B0045FM6SU/ref=sr_1_1?ie=UTF8&qid=1302858039&sr=8-1

Pourquoi avoir mis une corne en plein milieu du visage de Mr Hankey ?

En dehors de l'aspect trollesque, savez-vous pourquoi tout ces navigateurs alternatifs sont en gtkxx et qu'aucun ou presque (comme reconq) ne soit en qt ?

Ils sont tous en C, et pour rester dans le domaine du troll, ils proposent tous des raccourcis type vi et aucun des raccourcis type emacs !

À le prononcer ("Yuu zé beu le" aka "usable") ou à le lire ?

Jusqu'à récemment, GCC était conçu de sorte qu'il soit difficile de réutiliser autre part des morceaux du compilateur (comme le backend) sans devoir l'intégrer directement au tronc (pour éviter la "propriétarisation" du code). Ça a toujours été affirmé haut et fort par RMS et le projet GNU, rien à voir avec de la médisance.

mais évite de participer à l'usage de ce mot pour des choses qui n'ont rien à voir avec le nazisme.

Merci pour la leçon de morale, je sais très bien ce qu'est le nazisme.

Je sais, de l'autre coté de l'atlantique, ils y en a qui se permettent... Ils sont de l'autre coté et pas en Europe et ont parfois perdus le sens de l'histoire.

ou pas, la meilleure façon d'exorciser un traumatisme c'est d'en rire et d'aller de l'avant et pas de le refouler. Plus tu le refouleras, plus il reviendra en force (l'UMP le prouve brillamment depuis une dizaine d'années !).
Je respecte tout autant que toi la mémoire des victimes, mais je ne me priverais pas du droit de tourner en ridicule les bourreaux ! On ne terrasse pas un dragon en scellant sa grotte avec du papier mâché ...

Au temps pour moi, la version courante dans Fedora rawhide le propose encore (nautilus 3.0 a été compilé hier)

Il y a bien un process QA bien bien nazi limite debiannesque dans Fedora, par contre t'as un petit groupe qu'on appelerait par exemple Redhat Desktop & friends qui se croit tout permis.

Les fenêtres ne se minimisent pluS

alt+f9 (alt+clic droit affiche tjrs le menu par ailleurs)

Il n'y a pas encore d'application pour appliquer un thème personnalisé (en tout cas je n'en ai pas vu

gnome-tweak-tool (dispo dans les dépôts fedora) et évidemment dconf-editor. Pour les thémes personnalisés, une extension du shell est en cours de développement mais les extensions ne sont pas encore prêtes à être distribuées.

Il n'y a plus d'icônes sur le bureau

Tu peux demander à ce que nautilus gère le bureau, mais par défaut, ça n'a pas de sens puisque le bureau est centré sur l'application désormais.

Les boites de dialogues de configuration système on été refaites, et je ne les trouve pas très au point pour le moment

Ça s'inspire de Mac OS X plutôt, le but c'est de centraliser tout les panels de configuration dans une seule application et graphiquement cohérente. Reste quelques trucs à peaufiner mais ça me semble pas trop mal.

Il n'y a pas d'intégration avec zeitgeist contrairement à Ubunu Unity

Zeitgeist n'a pas été inclus à GNOME (principalement à cause de l'obstination de son mainteneur d'ailleurs)

Je ne sais pas ce qu'il en est pour NVidia, et Intel.

Quelques bogues avec Intel mais que Dave Airlie est en train de corriger dans les pilotes mesa.

Je pense que tu raconte n'importe quoi, je n'ai vu nulle part de problèmes d'implémentation du multi-threading dus à constexpr chez les développeurs de gcc.

Soit tu n'as pas du tout compris la sémantique de constexpr, soit effectivement, je raconte n'importe quoi ...
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2976.html (document de travail qui explique l'intérêt en général de constexpr dans la bibliothèque standard)

La norme C++2011 garantit qu'un constructeur déclaré avec constexpr et qui satisfait les conditions requires est initialisé statiquement (donc 100% thread-safe, aucun risque de data races, d'où le data-safety). Par exemple, la norme impose que le constructeur par défaut de std::mutex soit déclaré constexpr (pour rester avec les mutex, ça revient plus ou moins à ce que fait la macro PTHREAD_MUTEX_INITIALIZER dans la bibliothèque Posix Threads).

La quasi-totalité des développeurs a rejoint Jenkins, c'est très vite vu ...

Je ne vois pas le rapport entre constexpr et le multi-threading

two words: data-safety, c'est utilisé dans l'implémentation des mécanismes de synchronisation entre autre et c'est ce qui retarde la plupart des implémenteurs de compilo en ce domaine.

Visiblement, ils sont pas mal à la bourre sur la partie multithreading de C++0x, mais ça a l'air également valable chez visual et ICC

C'est principalement du au fait que l'implémentation de constexpr n'était pas finalisée jusqu'à présent, donc maintenant ça devrait aller vite côté GCC vu que le gros du boulot dans libstdc++ a été fait (merci Boost ;) ). Pour CLang and libc++, c'était le même problème.

Personnellement, j'attends beaucoup de la délégation et de l'héritage de constructeurs Les unrestricted unions, le support étendus des rvalues avec l'arrivée des move constructors dans GCC 46, c'est pas mal non plus ;)

La dépêche laisserait croire que la prise en charge du langage D est intégré dans le tronc GCC mais contrairement à Go, ça n'est toujours pas le cas :(
https://bitbucket.org/goshawk/gdc/wiki/Home

Nan, tout le monde sait que Django c'est une blague qui a mal tournée, si tu veux un vrai framework web Python, tu utilises TurboGears euh non Pylons, merde je veux dire Pyramid etc ...

Ce serait super que quelqu'un ponde un navigateur qui aurait à la fois les avantages d'Arora (moteur webkit-qt) et ceux d'uzbl (hyper-configurabilité).

uzbl utilise WebKitGtk donc bon ...

http://packages.ubuntu.com/maverick/mock C'est l'outil utilisé par fedora pour générer les chroots de compilation, tu peux utiliser le fichier de config epel-4 comme base.
1. je génére mon chroot avec tout les paquets dont j'ai besoin sur la machine de développement 2. j'ouvre un shell dans mon chroot mock 3. je compile 4. je balance sur la machine de production

Si tu fais des paquets RPMS, tu directement passer un src.rpm à mock et il récupérera les dépendances sur les dépôts et construira le paquet tout seul.

Les interface nazi vous en remercie ! ^^

SELinux permet déjà de contrôler finement les privilèges d'une application, du coup, quels sont les avantages de capsicum par rapport à cette solution ?
linuxplumbersconf.org/2009/slides/dan-walsh-selinux-sandbox.pdf

C'est défini dans les codings standards GNU (http://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html#Command_002dLine-Interfaces)

Effectivement, même si la norme Posix définit un modèle de gestion de la ligne de commande (man 3p getopt), c'est très limité: pas d'options longues qui sont très pratiques pour l'auto-documentation mais qui sont une extension GNU et plus ou moins rentrée dans les moeurs (info getopt_long -la page info propose également un exemple d'utilisation-).

En C++, Boost.Program_options permet de gérer de manière cohérente et très élégante la ligne de commande (fonction de callbacks, génération automatique de l'aide etc ...) ainsi que les variables d'environnements ou un fichier de configuration. Sauf si on ne peut pas faire autrement, éviter de parser à la main argv ce qui est bien cracra et pas super maintenable à long terme.

bazaar, launchpad

le monsieur, il a dit emblématique, pas comique ! (git/mercurial, github/bitbucket r0x0r \o/)

Le multi-threading potable au lieu des Usines à Gaz à la Twisted, c'est pour demain ?

Twisted est loin d'être une usine à gaz, de plus, le modèle événementiel asynchrone a le vent en poupe pour tout ce qui est entrées/sorties (les serveurs web haute-performance utilisent quasiment tous ce mode de fonctionnement)

PyPy à la place de CPython en standard, utopie ? La dernière fois que j'ai tenté de le compiler, ça a réussi à rendre inutilisable une machine quad-core avec 8Go de RAM pendant au moins 5 à 7h.

Question subsidiaire du vendredi: Pourquoi DLFP n'est pas réécrit en Django, si c'était mieux que RoR? Parce que Django sapusaipaWSGIApproved ;)

Maintenant que CPython 3.2 intégre les travaux d'Antoine sur le GIL (après plus d'un an de travail, chapeau !), quels sont les pistes pour améliorer les performances de Python dans un contexte multicore ?
Si j'ai bien compris, on a désormais un GIL qui gère les changements de contexte de façon plus équitable et déterministe (basé sur des ticks et non plus sur l'exécution d'opcodes), mais pour autant ça ne résoud pas tout les problèmes du GIL.

Au niveau de la librairie standard, Python 3.2 arrive avec les futures qui semblent faire consensus (adopté par les langages mainstreams comme Java, C++0x, C#, etc ...) et un nouveau namespace concurrent qui ouvre la porte à pas mal d'améliorations: conteneurs concurrent-friendly, threading haut-niveau (des compréhensions de listes de haut niveau, etc ...), etc ... De ce côté-là, la roadmap semble plus claire, mais concrètement, qu'est-ce qui arrive dans le tuyau ?

Python, appuyé de frameworks web de qualité (Pylons, TG, Django etc ...) connait un grand succès en tant que langage web. Le passage de WSGI à Python 3 semble trainer depuis quelques temps notamment à cause du choix du type de données pour les flux (unicode ou bytes, ou selon le contexte), où en est-on ? Est-ce que la librairie standard verra un jour son support de WSGI enrichi et qu'on puisse enfin se débarasser de modules à moitié maintenus (mais que tout le monde utilise) comme Flup ?

Chez moi (Debian amd64) : GLib = 934K, QtCore = 2,6M. Mais il faut ajouter GObject parce que même si on peut utiliser GLib sans GObject

Que tu comptes ou pas GObject, GLib reste 2 à 3 fois plus petit que QtCore. Dans des systèmes embarqués, ça n'a rien de négligeable (d'ailleurs, tu peux compiler QtCore sans le support de la GLib pour cette raison).
Mais bon, ça n'élimine pas le problème du C++ et de son ABI de merde.

Il n'y a aucune dépendance circulaire entre GLib et QtCore, les deux sont implémentés indépendamment l'une de l'autre et n'utilise pas du tout l'autre.

Mes confuses, on ne s'est pas compris, c'est juste qu'exiger que la Glib ait un requirement vers QtCore parce que QtCore a une dépendance vers GLib, c'est juste stupide.

Et Xine ? Et mplayer/ffmpeg ? Sérieusement, tu dis n'importe quoi là

Ce ne sont PAS des frameworks multimédias ! (du moins pas aussi complet que GStreamer dans le cas de Xine)

• Xine a un champs d'action beaucoup plus réduit que GStreamer, il est clairement passé en mode maintenance et son architecture peu modulaire n'aide pas à sa diffusion.
• MPlayer est un gloubiboulga qui fait lecteur (certes, il le fait très bien!)
• FFmpeg une collection de codecs et de petits programmes. KDE a développé Phonon parce que GStreamer n'offrait pas suffisamment de garantie de stabilité d'API/ABI (GStreamer 0.10 est sortie en 2006, et on peut installer en parallèle plusieurs versions), FFmpeg c'est pire, bien pire, encore bien plus pire que ça.

comme PulseAudio, ça a mis des plombes à marcher correctement pour des utilisations basiques

PA va se trainer pendant combien de temps, les casseroles d'Ubuntu ? PA a été intégré dans Fedora 8 par son mainteneur et ça a fonctionné correctement dès le PREMIER jour, Mandriva, SuSE l'ont fait dans les 6 mois qui suivent sans problèmes majeurs.
Les branquignols de Canonical l'ont intégré comme des bourrins dans une version LTS sans prendre le temps de tester ni même contacter Lennart et après, c'est de la faute de PA ?

si on regarde les news du projet GStreamer depuis sa création, le développeur s'est rendu plusieurs fois au GUADEC (jamais à l'Akademy)

Est-ce que quelqu'un a offert de sponsoriser le voyage du développeur à aKademy ? Non.
À l'origine, c'était un projet universitaire et il s'est écoulé deux ans entre la première release publique et le rapprochement avec GNOME.

même sur la page wikipedia anglaise de GStreamer a une boite GNOME en bas, le citant parmi les technologies GNOME

Idem pour la page Qt qui le cite comme une technologie KDE, dois-je en conclure que KDE développe Qt ?
En parlant de Qt, c'est un peu agaçant de dire que KDE fait plus d'efforts que GNOME en terme d'intéropérabilité alors que rien n'est plus faux (pour autant GNOME n'en fait pas plus, on est bien d'accord).
La plupart des initiatives d'intéropérabilité viennent de Trolltech puis Nokia pour diverses raisons: ils vendent un framework cross-platform qui doit s'intégrer le mieux possible à la plateforme native GNOME compris. Les gens de KDE sont pas plus altruistes que ceux de GNOME.

Tu veux dire "faire comme les devs GNOME" ?

en l'occurrence s/GNOME/KDE/ ! Je pense qu'il y a un gros problème de communication.
Au début, t'as un mec qui bute régulièrement sur un problème commun à tous, selon son background, il aura une approche différente: GNOME: je propose une spécification avec un début d'implémentation, on discute, je modifie mon implémentation, si tout le monde est d'accord, c'est tacitement accepté.
KDE: je propose une implémentation fonctionnelle voire intégré à une version sortie, et on fait une spécification autour puis c'est explicitement accepté. Tu rajoutes la mauvaise foi coutumière des geeks libristes et ça donne un mélange explosif.

Donc forcément, les gens de GNOME voient les gens de KDE comme passifs et renfermés et les gens de KDE ceux de GNOME comme autoritaires. C'est un peu le problème de fd.o qui n'est pas vraiment un organisme de normalisation mais avant tout un forum de discussion, il faudrait éventuellement formaliser le processus pour gommer ce genre d'incompréhension.