benja a écrit 1211 commentaires

Ben, faut faire marcher son cerveau.
+1

A moins que tu aies un site à très fort trafic, 2400 requêtes par seconde est largement supérieur à ce dont tu auras jamais besoin.
C'est aussi pourquoi la performance des serveurs Web sur des pages statiques, de nos jours, n'a plus grande pertinence (sauf, encore une fois, si on s'appelle Yahoo/Google/etc.).

Btw il y a aussi moyen de limiter php dans sa conso mémoire (de même que mysql j'imagine ou les autres services, rlimit ? ,...). Enfin il faudrait d'abord trouver ce qui fait swaper le bousin car 1go de ram c'est pas rien quand même ! top ?

Nope tu n'as bien que 4Mo:

Flash device: 0x400000 at 0x1c000000

Le tmpfs, c'est en ram (et tu en as 16Mo).

Toutafé, c'est loin d'être du vapoware et il fonctionne très bien !
D'ailleurs j'ai l'impression que le rhythme de développement a ralenti, ce qui peut indiquer une certaine maturité du code.
Dommage qu'il n'y aie pas de GUI qui permette d'utiliser à fond toutes ses capacités (notemment les collections dynamiques, il y a moyen de faire des trucs assez "ouf" avec cf. le wiki d'xmms2).

Il y a aussi quelques services web qui implementent cela. Bon évidemment, il faut avoir confiance dans le serveur, auquel tu donnes tes identifiants de connection (à moins de s'emmerder à faire une install locale évidemment). Chercher "Jabber Roster Utility" (je ne sais pas s'il y en a un qui est particulièrement recommandé par jabber.org).

Heu non, un paquet debian ça s' ar -x. Tu dois confondre avec rpm...

La question est donc: il y-a-t-il un GET sur le robots.txt ?

Et d'ailleurs, cela fonctionne aussi sans javascript ! Une css qui va pomper des resources différentes en fonction de l'état visité du lien et le tour est joué. Ceci dit, il est vrai que javascript permet des optimisations plus intéressantes :)

Sinon, on en a déja parlé ici je crois (flemme de rechercher le journal).

D'après ce que j'ai pu comprendre, la position de tous les rouages n'est pas calculée toutes les secondes pour éviter de bouffer du cpu inutilement.

Ah ben on dirait au contraire qu'il recalcule l'angle de chaque engrenage tous les 1/10 de seconde ("pour que la petite aiguille ne soit pas à plus d'1s/10 de décallage").

Sinon, merci pour ce lien :-)

ed n'existe pas dans Haiku !? Moi qui croyais que c'était un Unice...

Certes Robert Griesemer n'a pas le CV des deux autres comparses néanmoins il a aussi participé à l'élaboration de ce language.

Sinon c'est chouette d'avoir un nouveau dans la classe. On verra s'il tient ses promesses. En tout cas, il a l'air déja plus sympa qu'Alef, le language concourrant de l'illustre Plan9 :-)

Dans la même veine :

« Alors que les agents du service public sont sommés d’oublier leurs missions pour engranger des profits, le management rebat les oreilles des salariés du privé avec les valeurs d’excellence et de dévouement. Ainsi, ceux qui sont au service de la collectivité se voient interdire de remplir leur rôle, tandis que ceux qui travaillent pour des intérêts particuliers doivent prétendre se consacrer à une noble cause. Comment s’étonner des souffrances que génèrent de telles situations ? »

http://www.monde-diplomatique.fr/2009/09/LINHART/18115

Ce qui est une pratique fortement déconseillée par Theodore Ts'o en personne...

Ok merci pour ces précisions. Je sens que je vais mettre des bulles (FC5) sur mon bureau :-)

Ah bon, es-tu sûr de cela ? Avec F10, quand tu passe l'option vga=xx au noyau et bien tu avais un boot graphique. Je m'imaginais que c'était ça le fallback framebuffer...

Btw, est-il est prévu que le fond d'écran qui change de couleur revienne (F8 ou F9) ? Je trouvais cela fort agréable. Dans la même idée, j'avais entendu parler un moment de vouloir empaqueter tous les anciens thèmes. Il faut dire qu'il y en a eu d'assez remarquables. Cela pourrait faire un bon "summer of code"...

Je ne sais pas ce qu'on veut dire par cela. Mais une des nouveauté est que l'on peut spécifier au bootloader sur quel disque booter par son numéro de série (exemple de la relnote: vfs.root.mountfrom="hammer:serno/AB34394.s1d"). Idem pour le fstab, où l'on peut aussi utiliser les numéros de séries... Linux fait le second*, mais je ne pense pas que grub fait le premier (p-ê grub2 ??). Concrètement, cela permet de bouger ses disque comme on veut (disque extèrnes e-sata) et garder un système opérationnel.

*: de manière un petit peu différente: j'ai l'impression que le UID de fstab se base sur une information contenue dans la partition, et non sur le numéro de série du disque. À confirmer...

Ca n'a rien, mais alors rien a voir avec le probleme et c'est faux

Pas besoin d'enfoncer le clou comme cela hein. Tu dis sensiblement la même chose que lui, pinaillage offert...

(Dans le contexte, celui d'une mise à jour ou remplacement de fichiers systèmes, cela nous fait une belle jambe de savoir que 2 process peuvent lire le même fichier; "le verrou exclusif" se comprend bien sûr "empêcher le remplacement" ).

Ah ok merci pour cette précision. Je n'étais pas sur, c'est pour cela que je ne l'avais pas mentionné dans mon premier commentaire. Le souvenir des autotools m'a induit dans l'erreur. Ceci explique pourquoi la vitesse mesurée n'est "que" de 5x.

Maintenant, il s'avère que gold implémente aussi un support partiel des scripts ld. Si j'ai bien compris, sa plus grande vitesse est due au fait qu'il "hardcode" plus de choses, tout en se limitant au format elf.

non, il y a peut-être un problème de pilote... goto loop;

Peut-être que dans l'autre sens ce serait moins trollesque ? Soit: ld utilise une myriade de scripts shell, ce qui le rend plus lent qu'une implémentation compilée tout en un.


"At the moment gold has only one significant advantage over the
existing linker: it is faster. On large C++ programs, I have measured
it as running five times faster." http://sourceware.org/ml/binutils/2008-03/msg00162.html

Il y a existe un linker alternatif pour gcc qui s'appelle gold. Celui-ci est codé en c++ uniquement (ld se base sur des scripts), ce qui le rend plus rapide. L'utilisez-vous ?

Ce journal ne sera pas le lieu d'une intense réflexion. Tant mieux !

N'est-ce pas aussi appelé polymorphisme ad-hoc ?

Tu sais que ton driver de FS, le truc qui ecrit directement sur ton disque sans barriere de securite, a plante.

Ben non, le "driver de FS" n'écrit pas sur le disque dur, mais bien le driver (micro-serveur) "disque dur". Avec une architecture traditionnelle, quand ton pilote controleur disque dur plante, il entraîne ton pilote FS avec. Avec une architecture telle que minix3 ce n'est pas forcément vrai. Comme on dit, 90% des écrans de la morts sont dûs à de mauvais pilotes; j'ai la faiblesse de penser que les autres couches sont plus robustes.

Tu as vraiment envie de le redemarrer et effectuer a nouveau l'operation X qui a de bonnes chances de l'avoir fait planter elle-meme au risque qu'il detruise ta partition ?
Quand ton pilote FS s'est craché, redemarrage (de la machine) ou pas, je ne ferais pas trop confiance quant à la cohérence de ce qui reste sur ton disque dur...

Le FS c'est hyper-sensible, que le code qui le gere soit en user-mode ou kernel-mode n'y change pas grand chose, et un probleme la dedans est le plus souvent fatal.
Toutafé, mais nous discuttions de problèmes dûs aux pilotes et tu nous parles de problème de sous-systèmes indépendants du matériel. Au risque de me répéter, ton bug qui apparaît quelque part dans ton noyau peut impacter une toute autre partie de celui-ci (le temps qu'"il se rende compte que qq chose ne va pas"), entraînant des dégats collatéraux non déterminés/ables; ce qui n'arrive pas avec un micro noyau.

Tu peux voir un peu la meme chose sous Unix avec X11 [...] qui tourne en user-mode
Il tourne en user-mode mais le noyau lui permet de dialoguer directement avec le matos, le plaçant donc au niveau des autres pilotes. C'est à cause de cette dichotomie kernel/user mode qu'on se retrouve avec des trucs goret comme cela.

Les pilotes de cartes réseau sont en général assez simple et peu buggués...
Qu'est-ce qui te fais dire cela ? J'aurais tendance à penser qu'ils deviennent de plus en plus complexes à l'instar des cartes: tcp/ip offloading, queue multiples, wifi-n, ...

[...] le support de l'userspace est probablement très bon dans sa globalité en ce qui concerne les coupures impromptues du réseau.

J'imagine que l'intérêt de la démonstration était justement que wget n'en sache rien, c.-à-d. que sa connexion tcp/ip n'a pas été coupée*. En ce qui concerne la gestion des coupures réseaux, c'est clairement une fonction de la pile tcp/ip qui, pour le noyau linux, ne se trouve pas dans l'"userspace" ! Tu peux débrancer-rebrancher ton cable réseau sans que tes connections tcp/ip ne se coupent mais cela ne marchera pas au point de faire un rmmod-insmod.

Le test que tu propose avec le pilote hdd suit aussi la même logique et ne devrait donc pas poser de problèmes majeurs. Le micro-serveur qui s'occuppe du FS n'a qu'a attendre que le pilote se recharge** avant de soumettre la suite de ses ordres. L'idée est justement de séparer les sous-système dépendants en serveur différents et, je suppose que, minix3 gère cette résillience de manière +/- générique pour n'importe quel pilote.

Même si dans l'hypothèse fort improbable que Linus décide d'implementer la possibilité de recharger un pilote sans déstabiliser les couches logicielles qui en dépendent, tu n'obtiendra jamais le niveau de résillience d'un micro-noyau parce qu'il n'y a pas de séparation d'espace mémoire entre les différents pilotes/sous-systèmes et que donc un bug dans un driver peut modifier le comportement d'une autre partie du noyau (dans le pire cas), voir le crasher (dans le meilleur, car je n'aimerais pas avoir mon fs détruit à cause d'un mauvais pilote résaux ou une carte réseaux détruite à cause d'un Xorg foireux ;-)).

*:Effectivement, wget s'en sort plustôt bien quand la connection est _coupée_ en essayant de reprendre le téléchargement. Il y a dans ce cas une nouvelle connection tcp/ip effectuée et la restauration de l'état précédant la coupure est effectué par _l' application_. C'est de très loin un comportement minoritaire parmis toutes les applications réseaux existantes et qui n'est permis que parce que le protocol http/ftp permet cet usage. Rien à voir avec l'exemple qui nous occupe où la connection n'est tout simplement pas coupée...

**:En admettant qu'il ne faille pas dépendre de ce pilote pour recharger le serveur/pilote. Je ne sais pas comment minix3 gère ce cas mais en théorie cela est tout à fait possible, il suffirait d'avoir un serveur "chargeur" qui garderait en mémoire les pilotes à recharger.

Peux-tu nous fournir une référence à propos du problème que tu évoque ? Merci.