Victor STINNER a écrit 1639 commentaires

j'aurais préfère une annonce plus pédagogique sans le côté sensace et paillette faisant passer par ailleurs l'expérience Linux d'avant/actuel comme horrible.

Il y a eu 3 versions de cette dépêche, j'ai écrit celle qui a été publiée. J'ai tenté de virer les superlatifs pour me concentrer sur l'aspect technique. Mais j'avoue ne pas avoir compris ce qui fait que le patch améliore la réactivité. Si quelqu'un a une bonne explication, je suis très intéressé.

Bah là j'ai pu faire un make -j64 du kernel et regarder ma vidéo en même temps, en gardant une interface réactive.

Tiens, ça me rappelle un sketch de Coluche...

(...)
- Le nouvel Omo c'est celui qui lave la tache qui est cachée dans le nœud du torchon.
- Vous avez vu ça à la télévision ???
- Y a le torchon, C'est deux gonzesse qui font la publicité, complètement abruties. Y en a une, elle sait même pas qu'il y a un nouvel Omo.
- Heu... l'autre, elle dit : "Ben dis donc ? T'en as fait une grosse tache sur ton torchon."
- Elle est triste la gonzesse, elle a vu la grosse tache. Et l'autre elle est toute gaite.
- Elle dit : "Ah! Ouaf, ouaf!"
- Elle est toute gaite, alors elle dit :
- "Bon ça fait rien avec mon nouvel Omo !"'
- Alors l'autre elle sait même pas que ça existe le nouvel Omo.
- Quoi! , Y a un nouvel Omo
- Alors l'autre :"Ben oui hé con."
- Et alors elle dit : "Regarde bien le nouvel Omo. Tu vois la grosse tache sur le torchon ???
- Je fais un noeud. Tac... et plus la tache!
- Et l'autre elle est sciée.
- Le nouvel Omo, ça lave la tache qui est cachée dans le nœud du torchon. - Mais il est bien le torchon après. Il est propre. Il est aussi propre qu'avec l'ancien Omo sans faire le nœud.
- C'est plus long, faut faire les nœuds.
- D'ailleurs, celui qui a 5 kilos de linge, il fait les nœuds le lundi, il fait la lessive le mardi et puis après il a toute la semaine pour défaire les nœuds.
- Parce que les nœuds qui ont été dans l'eau, bonjour hein.
(...)

Suite aux critiques de Con Kolivas, je me demande si ce patch améliore ou réduit les performances sur un bureau sur lequel on ne compile pas le noyau Linux avec -j64 en boucle ? Perso, ça fait plusieurs années que je n'ai pas compilé de noyau :-) (mais je compile régulièrement d'autres projets avec un Makefile) De ce que j'en ai compris, toutes les applications graphiques (Xorg, TTY7) sont dans le même cgroup. Faut-il mettre mplayer, Firefox et OpenOffice dans un cgroup dédié avec un % du CPU particulier ?

D'ailleurs, peut-on émuler le patch noyau avec des commandes shell ? Les cgroups peuvent être configuré avec un système de fichier virtuel.

Il me semble que c'est plutôt Ruby qui est utilisé pour scripter Ruby.

Il fallait lire : pour scripter Git ...

PS : Cette BD de nojhan est plutôt énervante par moment.

C'est quelque chose que j'ai perdu en passant à Git (faut wrapper la sortie, pas top) et cela me manque.

Il me semble que c'est plutôt Ruby qui est utilisé pour scripter Ruby. Sinon on dirait qu'on peut scripter Git dans pas mal de langages :
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,(...)

Est-ce qu'il n'existe pas une bibliothèque C pour git ? libgit2 semble être un bon candidat : « Pure C reimplementation of the core Git data structures and repository access. »
http://repo.or.cz/w/libgit2.git

Je vais peut-être dire une connerie, mais pour moi le wifi c'est tout pourri.

La portée est très limitée : avec ma Freebox, ça marche dans certaines pièces proches de la box, mais ça ne passe pas 2 ou 3 murs. D'ailleurs, avec un pc portable, je capte moyen quand je suis à 2 mètres de ma Freebox (je ne sais pas pourquoi). Peut-être que mon matos est pourri, mais justement : le matos grand public pour faire du wifi est tout pourri (d'ailleurs, pour les pilotes Linux c'était longtemps la croix et la bannière).

Et je sais pas vous, mais moi je perd plein de paquets avec le wifi. C'est à dire que le débit est moindre et la latence plus importante (si on compare à une connexion par cable ethernet par exemple).

Pour monter un internet alternatif avec du wifi, il faudrait que le wifi passe un peu mieux à travers les murs et ait une porté carrément plus importante. Ou alors il faudra à peu près que tout le monde utilise Netsukuku et que la densité de population augmente carrément à la campagne :-) (mais dans ce cas, y'a des soucis technique liés à la technologie wifi si j'ai bien compris)

>> ce fichier .srt va sans doute me permettre d'en faire un beau fichier de fortune, chose qui me semble plus compliquée si c'est intégré à la vidéo.
> Pour connaitre les ID des différentes pistes : mkvmerge -i "bla.mkv"

$ mkvmerge -i "bla.mkv"
mkvmerge: command not found
Alors que le .srt peut être lu avec vi, less et même notepad.exe (pas sûr à cause des retours à la ligne UNIX) savent le lire :-p

En même temps, rot13 a été supprimé dans Python 3.

J'ai pris un article au pif :
http://en.citizendium.org/wiki/Mao_Zedong

Si on compare à Wikipédia anglopgone :
http://en.wikipedia.org/wiki/Mao_Tse-Tung

J'ai comme l'impression que la version Wikipédia est plus riche : carrément plus de texte (donc plus d'informations), plus de photos, plus de sources, etc. Je ne suis pas allé vérifier si les informations de Citizendium ou de Wikipédia sont justes, je ne connais pas personnellement Mao. Mais si j'ai le choix, je préfère plus d'informations avec quelques inexactitudes que peu d'informations exactes.

D'ailleurs, quelqu'un aurait une idée de la tendance de Wikipédia vis à vis de l'exactitude des articles ? Je pense que depuis qu'on exige une référence ({{refnec}} !) quand il y a désaccord ou pour les faits qui semblent louches : la qualité de l'encyclopédie en a beaucoup bénéficié.

Qu'est ce que AssHoleDaemon (c'est le premier truc auquel j'ai pensé en voyant l'acronyme Ashd) apporte de plus par rapport aux Nginx, Cherokee et consorts (à part la page web digne d'une bonne vieille manpage) ?

À vrai dire, quand j'ai vu une annonce d'un nouveau serveur web : je pensais à libevent (*) ou aux API asynchrones (non bloquantes). Or quand je lis le code source, je vois des read()/write() bloquants (ou alors j'ai loupé un truc) dans sendfile.c et un select() dans lib/mtio.c. htparser utilise getc() pour parser une requête HTTP : ça ressemble à un premier jet, je pense que les autres serveurs web utilisent des structures plus optimisées pour cette opération.

Ashd 0.1 ne semble donc pas adapté pour supporter de nombreux clients simultanés. Il faudrait tester avec Apache Benchmark (ab) ;-)

(*) http://www.monkey.org/~provos/libevent/

Bon allez, j'ai ouvert sendfile.c : la fonction passdata() lit le fichier avec read par bloc de 64 Ko, puis écrit dans stdout avec write(). Bref, les données sont bien recopiées entre sendfile et htparser.

On peut comparer Ashd à Hurd / MINIX (micro-noyau) et Apache à Linux (monolithique). J'avais lu que Hurd a de gros problèmes de performances car les données doivent être copiées d'un processus à l'autre (bien qu'il semble que ces problèmes soient spécifiques au micro-noyau GNU Mach et que les autres genre L4 sont moins pires). Je me demande comment ça se passe pour Ashd qui vante la séparation de processus comme qualité en matière de sécurité.

Soit les processus sont vraiment cloisonnés et il faut donc recopier les données d'un processus à l'autre. Au moins entre le processus qui génère le corps de la réponse HTTP et htparser qui gère la socket (ou bien htparser transmet la socket à son fils ? c'est possible sous Linux).

Soit les processus partagent de la mémoire. Ce qui revient un peu à utiliser des threads avec de la mémoire partagée. Un bug ou une faille de sécurité affectant un processus va contaminer tous les autres processus. Par contre, on peut éviter certaines copies mémoires. Maintenant quand je lis qu'un programme s'appelle "sendfile", je me demande justement s'il utilise l'appel système sendfile qui permet de copier les données depuis un fichier vers une socket sans aucune copie des données entre l'espace noyau et l'espace utilisateur (noyau (disque dur) => espace utilisateur (tampon), puis espace utilisateur => noyau (socket)).

Aucune idée. Par contre, le dépôt git semble actif.
https://git.netfilter.org/cgi-bin/gitweb.cgi?p=nftables.git;(...)

Euh, il n'y a pas que le bloc 48 :005/8 IANA UNALLOCATED
023/8 IANA UNALLOCATED
036/8 IANA UNALLOCATED
037/8 IANA UNALLOCATED
039/8 IANA UNALLOCATED
042/8 IANA UNALLOCATED
049/8 IANA UNALLOCATED
100/8 IANA UNALLOCATED
101/8 IANA UNALLOCATED
102/8 IANA UNALLOCATED
103/8 IANA UNALLOCATED
104/8 IANA UNALLOCATED
105/8 IANA UNALLOCATED
106/8 IANA UNALLOCATED
179/8 IANA UNALLOCATED
185/8 IANA UNALLOCATED
Bah justement, la police de IP, c'est l'IANA. Et l'IANA n'a pas encore décidé d'allouer ces 16 plages.

Je bosse pour un éditeur de parefeu et j'avoue que MySQL nous a donné du fil à retordre (ou détordre ? je ne sais plus trop). J'avais testé plusieurs types de données (VARCHAR(32), BINARY(16) et un autre je crois) en comparant les temps d'insertion, temps de recherche (comparaison), etc. Le choix n'est pas évident, mais dans notre cas, c'était l'analyse de log qui a tranché pour le type BINARY(16) car il est plus rapide pour le filtrage par des masques de sous-réseau de taille non multiple de 8. Je vous raconte pas comment c'est pratique pour déboguer avec le client MySQL en ligne de commande :-)

Bon depuis on a arrêté de déconner : on est passé à PostgreSQL qui propose un type de colonne « inet » qui gère IPv4 et IPv6 de base. Ca veut surtout dire qu'on peut écrire naturellement "ff02::2" dans une requête SQL.

Je m'en sers pour stocker les modules chargés dans mon application. Quand je quitte, je veux les décharger dans l'ordre inverse du chargement (et non pas l'ordre « aléatoire » du dictionnaire).

linuxfr.org est en train d'être réécrit en... Ruby :-)

La politique de Debian est très différente à ce niveau, donc ils ont déjà le travail d'installations parallèles de python depuis longtemps.

Debian a été une des dernières distrib Linux à intégrer Python 2.6. Ils ont beaucoup de mal avec le passage de site-packages à dist-packages. L'intégration de Python 3 a pris encore plus de temps, mais si j'ai bien compris a été possible grâce au travail sur l'intégration de Python 2.6 (3.1 a rapidement suivi l'arrivée de 2.6 dans Debian).

J'applaudis des deux mains mais bon c'est une nouveaute mais uniquement pour Fedora vu que cela existe depuis de nombreuses versions pour les debians-like et au moins depuis la 11.1 pour opensuse.

Dans Debian-like, est-ce que tu inclus Debian tout court ? Debian n'a intégré Python 3.1 que mi-janvier dans Sid (c'est entré dans Testing depuis). Autrement dit, Debian (Stable) n'offre pas encore Python 3.

Je tape ma recherche dans la barre d'adresse. Exemple avec konqueror « bla bla » ou « gg:bla » (j'ai modifié la config Konqueror pour utiliser le raccourci Google par défaut, actif dès qu'il y a au moins deux mots).

« Vim où Emacs ? »

DTC

Mandriva 10.0 aka Mandriva Linux 2010 : 2010
Gentoo 2008.0 : 2008
Gentoo 10.1 : 2010 (ah non, fin 2009, mais bon)

Windows 7: 2007 ? Mac OS 10 : 2010 ? OpenSuse 11.2 : 2011 ? Ah non, aucun rapport :-) (mais Windows 95 est bien sorti en 1995, et 98 en 1998)

jemalloc a apporté un énorme gain dans les programmes multithreadés (sous FreeBSD, comparativement à l'ancienne implémentation). Il me semble que le malloc() des dernières versions de la GNU libc a également été modifié pour être plus scalable avec plein de threads.

Ah non, George aurait dit « Monde de merde ». T'as la classe américaine, ou tu l'as pas.

J'ai l'impression que patrick_g a une dent contre C++, il n'a pas parlé des améliorations liées à ce langage !

GCC 4.5 features improved experimental support for the upcoming ISO C++ standard, C++0x, including support for raw strings, lambda expressions and explicit type conversion operators. An experimental profile mode has also been added to the libstdc++ runtime library. Other improvements have been made to the optimiser and integration with the MPC library allows GCC to more accurately evaluate complex arithmetic during optimisation. The developers also note that GCC now requires the MPC library in order to build.


New target platforms include among others the ARM Cortex-M0 and Cortex-A5 processors and the ARM v7E-M architecture and MIPS 1004K processors. Support for a number of older platforms, such as Tru64 Unix, Irix and Solaris 7, has been discontinued.
http://www.h-online.com/open/news/item/GNU-Compiler-Collecti(...)