Victor STINNER a écrit 1639 commentaires

Perl6 a été annoncé il y a 10 ans. Il y a eu l'implémentation Pugs (écrite en Haskell), et maintenant il existe Rakudo (basé sur Parrot). Je vois que Parrot avance bien, mais qu'en est-il de Rakudo ?
http://perl6.org/
http://rakudo.org/

http://vidberg.blog.lemonde.fr/2009/05/27/faut-il-supprimer-(...)

Kpdf / Okular permet d'annoter un PDF, mais il n'est pas possible d'exporter / importer des notes. Je doute que ça soit interopérable avec Evince d'ailleurs.

1. Ouvrez le dialogue (Gnome) pour lancer une application (ALT+F2)
2. Saissez « free the fish »
3. LOL

(ça vaut pas « gegls from outer space »)

Oui, et c'est pour ça qu'OpenCVS a été écrit !

Yep, mais on parlait du pilote VESA là :-)

les pilotes vesa, si j'ai bien compris, ont pour but d'être compatible avec toutes les cartes graphiques. Il n'y a que la 2D et ont beaucoup de problème en 2D (mauvaise résolution, visionnage d'un film déconseillé etc).

VESA est implémenté dans un BIOS (celui du PC ou celui de la carte graphique, je sais pas trop). C'est un mode très restreint offrant une compatibilité maximale. Par restreint j'entend : aucune accélération matérielle (plus il affiche de pixels, plus c'est lent : oubliez le 1024x768 en 32 bits/pixel, pour un film c'est juste inutilisable car un film c'est 24 images / seconde), peu de résolutions disponibles (pas de 16/10 par exemple, aujourd'hui courant avec les écrans LCD et PC portables), etc.

Il y a un seul pilote VESA (pour Xorg), c'est le même pour toutes les cartes graphiques vu que l'API est volontairement standardisée.

les pilotes nouveau ont pour but d'être compatible avec les cartes nvidia. La partie 2D est semble-t-il, fonctionnelle. Il est depuis décembre intégré au noyau (ça montre que le code doit être bien écrit, bravo les dév!). La partie 3D est beaucoup moins fonctionnel, certaine carte ne fonctionne pas encore. De plus il manque aussi des fonctionnalités (les effets kikoolol ou compiz), de l'optimisation (voir http://www.phoronix.com/scan.php?page=article&item=nouve(...) ).

Nouveau implémente correctement l'API EXA ce qui offre d'excellentes performances 2D. EXA est aujourd'hui l'API la plus utilisée, c'est utilisé pour la composition (Xrender, effets graphiques).

Pour la 3D : elle fonctionne très bien pour les modèles de carte Nvidia les plus courants, mais supporte moins bien les cartes anciennes ou récentes. Voir la matrice de compatibilité :
http://nouveau.freedesktop.org/wiki/FeatureMatrix

Après oui je pense qu'il reste de la place pour l'optimisation. C'était déjà un travail pharaonique de faire l'ingénierie inverse de tous les GPU Nvidia : il y a une tripotée (genre Nouveau vise à gérer tous les GPU sorti depuis 10 ans) et un pilote 3D est autrement plus complexe qu'un pilote d'un clavier :-) Nouveau a également du attendre qu'un consensus soit trouvé entre les différents gestionnaires de mémoire dans le noyau (TTM vs truc Intel dont j'ai oublié le nom), que Gallium 3D soit écrit et stabilisé, a beaucoup été aidé par mmiotrace qui a aussi été développé pendant que Nouveau se montait, etc. Autrement dit, la 3D s'est beaucoup améliorée dans Linux/Xorg depuis que Nouveau est né, et Nouveau n'est y pas étranger.

les pilotes nv sont écrit par nvidia. Le code est très mal écrit (pas parce que les dév de nvidia code comme des pieds ils utilisent un moyen pour rendre peu lisible le code, c'est mesquin et ça montre l'idéologie étrange de nvidia). Il supporte assez bien la 2D.

Si je ne me trompe pas : nv implémente l'ancienne API 2D (XAA), qui est moins performante et aujourd'hui désuette. nv n'accélère pas complètement la 2D, et bien sûr n'offre aucun support 3D.

Le code a été obscursi pour protéger la propriété intellectuelle de Nvidia (sûrement exigé par les avocats Nvidia), et non pas parce qu'ils ne savent pas coder. L'idéologie n'est pas étrange, juste incompatible avec le libre :-) Dans l'embarqué, les pilotes matériels sont encore moins libre (ex: Poulso !).

--

Note : il existe un seul pilote VESA, un seul pilote Nouveau et un seul pilote nv :-)

En tant qu'entreprise, ils ne veulent peut etre pas prendre la responsabilite d'encourager les gens a utiliser un pilote qui ne depend pas d'eux

Euh, Nvidia pourrait très bien contribuer à Nouveau : ils ont plus d'infos que les hackers de Nouveau, savent comment bien utiliser un GPU, etc.

Le problème est surtout que la société Nvidia est bourré d'avocats qui sont payés pour protéger leur propriété intellectuelle, que ça ait un sens ou non : conception des puces, algo brevetés implémentés dans les pilotes, DRM implémentés dans le pilote, etc. Suffit de voir la merde que c'est avec l'algo de compression de texture de S3 (interdiction de l'implémeter dans un pilote libre) :
http://en.wikipedia.org/wiki/S3_Texture_Compression

L'article suivant explique bien la différence fondamentale entre les bases de données relationnelles (MySQL, PostgreSQL et toutes les autres) et les bases NoSQL :
http://blog.nahurst.com/visual-guide-to-nosql-systems

CAP est un sigle pour désigner (traduction approximative) :
- Consistency (cohérence) : chaque client a toujours la même vue des données
- Availability (disponibilité) : tous les clients peuvent lire et écrire
- Partition tolerance (tolérance au partionnement ?) : le système peut être réparti physiquement à travers le réseau

Le théorème CAP dit qu'on peut pas tout avoir : au mieux, on peut en avoir que deux.

Les bases de données relationnelles ont choisi Consistency+Availability (donc mauvaise performance pour une base distribuée), Cassandra et CouchDB ont choisi Availability+Partition tolerance (donc mauvaise cohérence), et MongoDB a choisi Consistency+Partition tolerance (donc mauvaise disponibilité).

J'ai la flemme, mais demain peut-être.

Cela permettra à toutes les implémentations de python d'utiliser la stdlib. C'est un autre aspect qui fait que les implémentations de python alternatives restaient à la ramasse.

PyPy a recodé énormément de modules en pur Python. Par contre, l'implémentation native est toujours plus rapide.

Cela dit, ça résoudra pas la situation des numpy, PyQt et autres modules python en C.

ctypes est maintenant intégré à Python et PyPy l'utilise. Ca permet d'écrire des bindings en pur Python qui fonctionnent sur plusieurs implémentations de Python (notamment CPython et PyPy).

Entre Qemu (KVM) et VirtualBox, mon coeur balance. Une GUI pour gérer une VM me fait quand même gagner pas mal de temps ! Aussi bien pour la configuration, que pour contrôler la VM en cours de fonctionnement.

Quand à la faire intégrer, faudrait distribuer des tarballs. Si il y a des paquets debian à l'intérieur, pourquoi ne pas distribuer les tarballs ?

Ca n'a pas été fait par manque de temps. Les scripts d'installation sont spécifiques à Debian. il y a des Makefile, mais ils sont désuets : il va falloir les retravailler pour en faire quelque chose d'utilisable.

Oups, la documentation ne précise pas la taille minimale de la partition. La taille des partitions est hardcodées dans Nufirewall (4 Go ou plus pour la racine). Je ne connais pas la taille exact, mais je pense qu'il faut au moins 8 Go. Réessaye avec une image de 8 Go, ça devrait passer.

Pourquoi une depeche pour une version estampillé "beta1" sur le site de download ? Est ce que la version final a une roadmap, est ce que la beta 1 a des bugs connus ?

Il n'y a pas de bug majeur connu pour la béta 1. Si ça ne tenait qu'à moi, l'ISO distribuée serait déjà la finale. Certains geeks sont perfectionnistes :-)

Il y a quelques bugs mineurs (plus des questions d'ergonomie ou de packaging) qui seront corrigés pour la version finale. La roadmap de la version finale est de corriger tous les bugs bien sûr :-)

Quel est l'objectif exact de cette distribution ? Est ce pouvoir tester le produit avant d'adopter une solution matérielle, à destination des entreprises donc.

Non, ce n'est pas juste une jolie démo. C'est un parefeu complet parfaitement fonctionnel. On peut le comparer à OpenWall par exemple. Il n'y a pas de limitation. Le seul problème est que ce n'est pas très modulaire : pour le moment, ce n'est distribué que sous forme d'un OS complet, et il faut une machine dédiée ou alors utiliser de la virtualisation.

Ou bien est ce de pouvoir utiliser le produit à des fins associatives ou personnelles ?

Tu es libre de l'utilisé à des fins personnelles, associatives ou professionnelles (tu peux le vendre si tu veux).

Ces appliances sont décrites essentiellement en fonction de la charge attendue : par exemple la plus petite des appliances est estampillée "100 utilisateurs" (...) La limitation de gestion du nombre d'utilisateurs est elle logicielle ? Ou bien uniquement en corrélation avec la capacité du matériel sur lequel elle est installée ?

Les gammes sont déterminées en fonction de la tenue en charge en fonction du nombre d'utilisateurs. Il faut un boitier un peu plus costaux pour gérer 500 utilisateurs simultanés que 10 utilisateurs :-)

Si je souhaite utiliser cette distribution dans le cadre d'un évènement associatif, pouvant amener à gérer plus de 200 utilisateurs lors de la manifestation, est ce possible avec cette distribution ?

Bien sûr, par contre il faudra dimensionner la machine en fonction de la charge. Après ça dépend de l'utilisation du réseau que font tes 200 utilisateurs (ex: P2P ou consultation de courriels ?) et de ton jeu de règles (nombre de règles, logger ou non les connexions, règles authentifiantes ou non, etc.).

Ce projet semble très intéressant (OSD pour afficher si les entrées sont redirigées, architecture peer-to-peer), mais aussi spécifique à Gnome :-/

Proposes tu de nommer Debian Stable en Debian PasFiable, et Debian Instable en Debian Fiable ?

est ce que vous envisagez de faire une interface web d'administration

J'ai longtemps utilisé les interfaces d'EdenWall3 qui étaient écrites en PHP, HTML, CSS et Javascript. Et bien, je te conseille vivement de jouer avec la version « client lourd » (Qt) pour que tu remarques à quel point le web est lent et peu interactif. Je trouve l'interface Qt beaucoup plus réactive et rapide. Après comme c'est une nouvelle version, on a corrigé les erreurs du passé en rendant les interfaces plus simples, mais la simplicité n'est pas lié à Qt par contre :-)

Après comme l'a dit feth : EdenWall n'a pas prévu de version web. Il faut savoir que le plus gros du travail est fait côté serveur, et que le client se concentre vraiment sur l'affichage et l'interface utilisateur. Le serveur offre un interface XML-RPC que j'estime « simple ». Pour reprendre l'exemple de PKI : créer un certificat consiste en un seul appel de services en passant des arguments sous forme d'un dictionnaire Python :
nupki.createCertificate({
'pki': 'EdenWall',
'type': 'client',
'cname': 'client',
'email': 'courriel',
'organization_unit': '',
'state': 'Ile-de-France',
'location': 'Paris',
'country': 'fr',
'force': True})
(force=True pour demander à créer immédiatement le certificat)

Et je sais que si jamais un jour Debian intégre les softs ( le jour ou il y aura autre chose qu'une iso )

NuFirewall utilise déjà des paquets Debian. Comme tout le code est sous licence GPLv3, l'intégration dans Debian est tout à fait envisageable.

Ca n'a pas encore été fait, car actuellement les paquets sont un peu trop spécifiques à une installation sur EdenWall (solution tout intégrée). Les paquets sont un peu tous interdépendants. C'est un défaut (problèmes de packaging) et une qualité : nuconf-nuface-nupki fonctionnent ensemble. nuconf peut utiliser les PKI générées par nupki en 3 clics, nuface réutilise les réseaux définis dans nuconf, et nuconf permet de rajouter des règles locales à nuface (interface pour gérér les droits d'accès aux réseaux).

Comme indiqué à la fin de la dépêche : il va falloir un peu de boulot pour rendre les briques plus autonomes, mais c'est prévu. Le travail a un peu été préparé en amont. On peut par exemple se passer de nupki pour fournir un certificat sous forme de 4 fichiers (CA, certificat, clé et CRL). Et on peut aussi créer ses propres réseaux dans nuface sans passer par nuconf.

Les précédentes versions de nulog et nufw font parti de Debian :
http://packages.qa.debian.org/n/nufw.html
http://packages.qa.debian.org/n/nulog.html

Et pour les autres (nuface & cie), EdenWall propose son propre dépôt Debian :
http://software.inl.fr/trac/wiki/INLDebianPackages

D'autres distributions comme Mandriva packagent aussi ces applications.

la doc ne pourras pas en faire parti, ce qui peut être génant pour un outil d'une telle complexité qu'une interface de firewall.

Oui, la documentation de NuFirewall est non libre. Sans vouloir dénigrer le travail de notre documentaliste : je pense quand même que les interfaces sont suffisamment intuitives pour pouvoir se passer de documentation :-) Bien sûr, c'est mieux avec la doc !

J'utilise toujours la même config depuis plusieurs années :

section: screens
marge:
barney:
end
section: links
marge:
left = barney
barney:
right = marge
end

Bon, j'ai du changer le nom des machines quand l'une ou l'autre est morte :-)

Est-ce qu'il existe d'autres options intéressantes ?

J'ai l'impression que le jit a complètement changé la donne à ce niveau. Est-ce qu'il est envisageable que PyPy devienne l'implémentation de référence ?

Unladen Swallow utilise un JIT et semble également plus rapide que CPython. Bien qu'Unladen Swallow soit un "simple" fork de CPython, le merge a été refusé (cf. ma dépêche).

PyPy est un tout nouveau projet écrit depuis zéro. Bien qu'il soit compatible Python, il est conçu complètement différement de CPython. D'ailleurs, il est écrit en RPython (et Python) en non pas en C. Il n'est donc pas question de le merger dans CPython.

Pour que PyPy devienne l'implémentation de référence, il faudrait qu'il soit apprécié par les utilisateurs puis tellement populaire qu'il rende CPython désuet. Or PyPy semble encore peu utilisé en production, voir pas du tout. Un ami m'a par exemple dit que le module distutils de PyPy est complètement bogué, or il est hyper important pour Python : sans ça, PyPy est inutilisable.

Même si PyPy devient populaire, CPython et PyPy risquent de coexister très longtemps. Le mieux qui puisse se produire serait d'arriver à détacher la bibliothèque standard Python du projet CPython pour que ça devienne un projet à part entière. CPython sera un interprète tout nu. CPython, PyPy, Jython, Unladen Swallow, IronPython, ... utiliseraient tous la même bibliothèque standard plutôt que chacun utilise sa propre bibliothèque plus ou moins patchée dans son coin.

CPython est l'implémentation de référence mais aussi celle qui apporte les nouveautés du langage et de la bibliothèque standard. Ça pose d'ailleurs problème : chaque implémentation est plus ou moins bien compatible avec CPython. CPython est par exemple la seule implémentation de Python3 ! Un moratoire a été voté pour interdire les modifications du langage (mais pas de la bibliothèque standard), ce qui devrait permettre à Python3 d'être adopté plus rapidement, et aux autres implémentations d'arriver au même niveau que CPython. Si CPython évolue sans arrêt, les autres implémentations n'arriveront jamais au même niveau.

J'espère que ma longue réponse t'aura un peu éclairé :-)

Le site web indique la liste suivante :

4stAttack
Alien Blaster
Armagetron
Cube
Flobopuyo
Foo Billard
Gl 117
IceBreaker
Pengupop
Pouet Chess
Puzzles
Sudoku
Ze Race

Cette liste contient 13 jeux et non pas 39 ???

je sors l'extension Firefox Readability

Elle ne gère pas le « multi colonnage » malheureusement, mais ça semble pas mal ouais.

La question est mal posée. Le problème n'est pas la taille mais l'aspect pratique, comment est-ce qu'on va lire l'article. L'article une très longue page HTML. Si l'écran est large, les lignes font une cinquantaine de mots ou plus (mesure au pifomètre de compétition). Les magazines et journaux utilisent plusieurs colonnes pour qu'on puisse plus facilement voir sur quelle ligne on est (limiter le nombre de mots par ligne). C'est une limitation de la technologie web. J'avais lu que CSS3 permettrait ça mais j'ai l'impression que ce n'est pas implémenté ou que personne ne l'utilise :-/ Dans mon cas, c'est aussi plus fatiguant de lire sur un écran plutôt que sur du papier. Tous ces défauts mis ensemble font que c'est difficile de lire tes longs articles. Je veux dire que le même article correctement mis en forme sur papier ne me poserait aucun problème. D'ailleurs, la mise en forme sur papier impose un découpage par pages, alors qu'une page web a juste une longue barre de défilement pas toujours pratique (ah merde j'en étais où ?).

C'est pourquoi je pense qu'il serait plus pratique pour moi que tes articles soient découpés en plusieurs parties. Il faudrait arriver à trouver un découpage logique. Pour la dépêche 2.6.33, je pense par exemple que l'interview de Frédéric serait une très bonne dépêche à part entière. Pour le reste c'est plus délicat. Un découpage possible serait :
* toutes les nouveautés
* pour en savoir plus : historique du développements (les phases RC) et les développements futurs

Je pense que comme ça, chacun y trouvera son compte. Ceux qui s'intéressent au noyau Linux mais sans plus ne liront que les nouveautés. Ceux qui veulent tout lire, liront... tout, mais pourrons reposer les yeux et leur cerveau (ça bouillone vite avec tes articles !) entre deux dépêches. Je pense également que les commentaires pourront être plus ciblés et donc pertinents.