Aller au contenu

lorinc

INpactien
 Afficher le profil  Afficher son activité

  • Compteur de contenus

    5 638

  • Inscription

  • Dernière visite

 Type de contenu 

Messages posté(e)s par lorinc

    "Hello World!" dans tous les langages

    dans Programmation et Lignes de code

    Posté(e)

    En même temps un test rapide me donne : 

    time php test.php >-

real	0m0.259s
user	0m0.088s
sys	 0m0.128s

    avec les doubles guillemets et 

    time php test.php >-

real	0m0.260s
user	0m0.088s
sys	 0m0.172s

    avec les simple guillemets.

    Le source de test.php : 

    <?
for ($i=0; $i<100000; $i++)
echo "Hello World";
?>

    Donc en gros tu es en train de nous dire que tu va éventuellement gagner quelque chose de l'ordre du centième ou du millième de seconde sur cent mille print. Sacré optimisation.

    Et encore dans le cas présent, c'est le contraire, ce sont les double guillemets qui sont plus rapides.

    Test non valide !

    Si le moteur de php est bien foutu, il parse une seule fois la chaîne puis la bufferise, donc absolument aucune différence entre "" et ' '.

    Pour faire un vrai test, il faudrait générer une chaîne aléatoire et l'afficher, le tout dans la boucle de 100.000. :youhou:

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    On le savait, flash c'est de la grosse merde en boite. On en a encore une nouvelle preuve aujourd'hui.

    http://it.slashdot.org/it/08/08/20/0029220.shtml

    C'est à dire "use Flash with ActionScript code to load (persistently) a malicious URL into a target clipboard." ? Si le process de flash est tué, le clipboard est denouveau disponible, non ?

    C'est un peu bidon comme "attaque", si je te fais lancer un programme qui fait du while(1) setClipBoard("urlalacon"); (genre un document OOo avec une macro débile, ou n'importe quoi du style), c'est la même.

    C'est plus un défaut sur le principe même du clipboard qui peut être modifié par n'imporet quel process à n'importe quel moment...

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    Salut à tous (ça faisait un moment...).

    Dites, j'ai une question qui me turlupine.

    Aujourd'hui je me suis "accroché" au boulot avec un collègue au sujet des impacts de la préemption.

    Je pense que la préemption facilite les deadlocks, par exemple il y a plus de risques de deadlocks avec CONFIG_PREEMPT qu'avec CONFIG_PREEMPT_VOLUNTARY ou CONFIG_PREEMPT_NONE, tout simplement parce qu'il y a plus de sections critiques, et donc de problèmes de synchronisation. En plus, mon expérience personnelle me conforte dans cette idée : j'ai porté un ensemble de modules de 2.4 vers 2.6, et ça a révélé pas mals de problèmes de synchro (deadlocks, pointeurs foireux...)

    Enfin, j'ai vu que les patches RT d'Ingo Molnar ont aussi permis de découvrir des problèmes similaires.

    Des avis?

    Hum. oui et non. J'aurais tendance à dire que je ne vois pas en quoi avoir une préemption plus souple augmente le nombre de section critiques. Les sections critiques le sont par essence (un variable partagée, un problème de réentrance, ...), et ceci indépendamment de quand précisément l'ordonnanceur décide de tourner. En fait, la majeure partie du temps utilisé l'est en espace utilisateur, ce qui rend totalement imprédictible le moment où ce situera le prochain ordonancement (dans le sens que l'on ne sait pas si cela arrive durant un code en mode noyau et si oui lequel).

    L'INpact sur les deadlocks il vient surtout du nombre de sections critiques et du SMP. Après, j'aurais tendance à dire, peu importe le schéma de préemption.

    mais je suis ouvert à d'autres explications :francais:

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    Moi, j'aime bien toutes ces petites particularités. La langue, c'est de l'art, et l'art, c'est quelque part l'expression de quelque chose de très personnel. Quelque chose qui ne devrait pas s'attarder sur des choses aussi futiles que l'efficace. L'efficace est l'antithèse de l'art, car c'est tout le contraire d'une décision prise arbitrairement, pour des raisons qui n'ont pas de quantificateur, ni de critère d'optimalité. Or c'est justement ce qu'est l'expression de soi, une décision arbitraire. C'est l'art, unique, personnel, et pourtant tout entier.

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    Pour ceux que ça intéresse, voici les premières photos du déballage d'un FreeRunner (anciennement OpenMoko).

    La version présentée n'est cependant pas la version de production mais une version développeur, néanmoins très proche de la version finale.

    Bon, si on regarde certaines images, et surtout si on lit la légende, on réalise qu'il y a encore des Kernel Panic :eeek2:

    Edit : j'ai dit une connerie ! C'est le Neo1973 (la version de dév.) qui faisait des Kernel Panic au premier démarrage, et non le FreeRunner :oops:

    quand j'ai vu ça http://monochromementality.com/data/phoo/2...30/t9-input.png

    j'avoue, j'ai bavé d'envie... :crever: :crever: :yes::love: :love:

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    punaise, quand il se fache, il se fache vraiment tout rouge le Linus... :ouioui:

    C'est là qu'on voit bien que Linus n'utilise pas debian, ce noob.

    Un vrai debian user aurait mis 10 minutes à corriger le problème du big kernel lock dans l'ensemble du noyau : 

    foreach (@kernel_files)
{
 open KERNEL_FILE, "+>$_";
 foreach (<KERNEL_FILE>)
  { s=^=//= if (m/(un)?lock_kernel/); }
 close KERNEL_FILE;
}

    :p

    c'est pas dit qu'il ait fallu deux ans avant que quelqu'un n'eût ralé pour celle-là, par contre :yes:

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    punaise, quand il se fache, il se fache vraiment tout rouge le Linus... :incline:

    Andrea, you're *this* close to going to my list of people who it is not

    worth reading email from, and where it's better for everybody involved if

    I just teach my spam-filter about it.

    That code was CRAP.

    That code was crap whether it's used once, or whether it's used a million

    times. Stop making excuses for it just because it's not performance-

    critical.

    So give it up already. I told you what the non-crap solution was. It's

    simpler, faster, and is about two lines of code compared to the crappy

    version (which was what - 200 lines of crap with a big comment on top of

    it just to explain the idiocy?).

    So until you can understand the better solution, don't even bother

    emailing me, ok? Because the next email I get from you that shows the

    intelligence level of a gnat, I'll just give up and put you in a

    spam-filter.

    Because my IQ goes down just from reading your mails. I can't afford to

    continue.

    Linus

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    En même temps une grande partie des linuxiens (de PCI j'ai envie de dire), sont surement sous ubuntu, et de plus ce sont souvent des débutants

    Donc un grand nombre d'utilisateurs et le fait qu'ils soient peu expérimenté est peut être l'explication à ta remarque :D

    Je dirais surtout que 75% des gens qui ont des problèmes sont ceux qui ont installé linux pour la première fois il y a moins de quelques heures. Et que ceux qui ont installer linux depuis quelques heures ont installé boubountou.

    Les autres distribs ne sont largement pas aussi populaires pour ce qui est d'attirer le windowsien qui veut voir un nouveau jeu (et non pas un nouvel OS).

    Le Linux BAR - Discussion de tout et de rien

    dans GNU/Linux, *BSD et dérivés d'UNIX

    Posté(e)

    bon, j'ai eu besoin de faire le master goretto : j'ai monté un paycay à aurielle avec une debian il y a quelques mois, et impossible de me souvenir du pass root... (alzheimer, ou bien la théorie de gnous qui finalement se serait révélée dévastatrice pour mes neurones. bref, je veux pas le savoir. :francais: ). Pas grave, je me dis, je boote sur un livecd, je chroote et passwd et hop. ça m'a permis de tester plusieurs liveCD :

    edubutunubut : 0/20. allez hop, poubelle. Le disque était en LVM, et y a pas les outils lvm sur ce disque. zéro pointé.

    débian : 0/20. c'est un vieux pc, mais avec un clavier usb, impossible de booter... déçu, mais grave...

    fedora : 2/20. ah, ça boote, victoire ! ah, y a lvm, victoire ! comment ça, y a pas chroot ??? un liveCD sans chroot, c'est comme une fourchette sans dent : poubelle. j'avoue que c'est zoli tout plein (le splash est bien foutu, le gestionnaire de connexion aussi).

    un vieux liveCD gentoo de 2004 : 20/20. ( :transpi: ), ça démarre, y a lvm, bon, j'ai pas pu chrooter, because il était trop vieux (fatal : kernel is too old), mais un coup de vi sur /etc/shadow pour virer le mot de passe, et ça marche... (ok, j'aurais pu le faire avec la fed, c'est vrai).

    Ok, je trolle un peu, mais c'est de bonne guerre, j'ai perdu 2h pour un pauvre mot de passe root... Il n'empêche qu'on voit tout de suite la différence entre les outils et les jouets...

    ;)

×
×
  • Créer...