Victor STINNER a écrit 1632 commentaires

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.

Trop gros, passera pas.

\_°< ce commentaire est inutile.

pan !

Les logiciels de capture sont très utiles, mais ont deux gros inconvénients qui en font un cauchemar pour la sécurité :
- ils tournent en root (il faut voir si on peut éviter cela avec des capabilities)
- ils parsent des données potentiellement très dangereuse, puisque circulant sur le réseau, ou internet

On peut séparer les deux : tcpdump pour sniffer le trafic (tourne en root) et wireshark pour parser les paquets (tourne sous un utilisateur non privilégié, voir dans un bac à sable).

Par contre, je ne sais pas si on peut utiliser tcpdump + wireshark pour voir le trafic en temps réel (j'en doute). Du coup, j'utilise wireshark en root chez moi pour les tests (dans mon LAN j'estime quand même que le risque est très faible).

Certes ça permet encore à bob qui intercepte ton réseau d'utiliser ton compte

Euh... je trouve ça TRÈS gênant. Imagine le scénario cauchemardesque : un attaquant vole mon compte linuxfr et écrit un commentaire calomnieux en ton nom !

mais une fois que tu cliques sur "se déconnecter" ça lui coupe l'accès

Je sais pas toi, mais moi mis à part sur le site de ma banque je ne le fais pas. La plupart du temps, je me débrouille plutôt que le cookie ait la durée de vie la plus longue car ça me saoule de me réauthentifier.

C'est moins gênant que si on divulgue ton mot de passe avec lequel on peut tout faire

Euh, le mot de passe n'est pas très utile. Au mieux il permet de voler le compte un peu plus longtemps, mais le cookie est déjà très largement suffisant pour faire énormément de choses.

et malheureusement souvent aller taper sur d'autres services avec ton compte parce que les gens utilisent le même mot de passe

Tiens, récemment j'ai changé tous mes mots de passe justement pour ne plus utiliser le même partout. Pour justement éviter le problème de la fuite d'un mot de passe.

Essaye le salon IRC (#wormux et #wormux-fr sur le serveur Freenode) et (les archives de) la liste de diffusion.

Si tu mets les différentes opérations de copie dans une file d'attente et qu'elles sont faite les une à la suite des autres, ca durera moins longtemps que si tu fait les copies en parallèles.

Gnome sait faire ça de base. KDE4 ne sait pas le faire, mais a au moins des boutons Pause et Stop. KDE4 affiche les copies dans la zone de notification avec la progression globale de toutes les tâches (ça gère d'autres trucs que les copies) et l'estimation du temps restant total. On peut aussi avoir les détails au besoin.

Ne faudrait-il pas patcher Gnome et/ou KDE plutôt que de développer à outil tiers ?

À ces histoires de version, c'est compliqué. Les développeurs cherchent la perfection pour la version 1.0, alors que les commerciaux courent après le plus gros numéro possible.

gstreamer est passé de 0.9 à ... 0.10 :-) Je me demande s'ils vont passer de 0.10 à 0.11 ou à 1.0. En tout cas, ça commence à être compliqué à suivre :-)

Durant 2 ans, le noyau Linux a enchainé les version 0.9xxx dont la dernière était la « 0.99 patch level 15Z » (rah le bodel !). Il aura mis 3 ans à sortir en version 1.0.

Mplayer existe depuis 9 ans et n'est pas encore en version 1.0... Bien que Mplayer soit extrêmement répandu, embarqué dans des lecteurs vidéos de salon, etc. La dernière release a maintenant 2 ans (version 1.0rc2) : son site web conseille de télécharger la version trunk via Subversion (The daily Subversion snapshots are generally stable, hum hum).

Le projet VLC a été lancé en 2001 et la 1.0 est sortie en 2009 (8 ans plus tard).

À côté de ça, le projet Chromium est passé de la 1.0 à la 4.0 en un an :-)

Plus sérieusement, Emacs en est à la 23.1 alors que vim se traine à la version 7.2. Faites votre choix.

(je vais pas parler de Linux 2.6.32 < Windows 7 < Mac OS 10.6.2, c'est tabou)