LupusMic a écrit 1481 commentaires

Tout dépend de la manière dont tu as branlé le bouzin.

Dans une pile classique LAMP, PHP est un module Apache : une sorte de librairie qui est chargée en mémoire d'Apache. SSL/TLS peut être géré par mod_ssl. Dans ce cas, on peut avoir le problème.

Maintenant, ceci est une architecture naïve, qui ne sera pas utilisée pour des applications bancaires. Pour les applications bancaires, tu auras d'abord un proxy SSL, puis Apache, puis PHP en FCGI par exemple. Les espace mémoire étant séparés, seules les données dans la mémoire du proxy SSL seront corrompues. C'est déjà pas mal, mais ça permet d'éviter l'exposition du code source et du paramétrage de PHP.

Du coup MS a quand même intérêt à ce que les VM ne fassent pas tourner des logiciels troués. Mais c'est appréciable d'avoir vu MS évoluer sur ces questions.

Ce n'est pas forcément bête. Dans un contexte où la sécurité prime avant tout, utiliser un processus neuf à chaque requête (ou pour chaque client) pourrait se justifier. C'est une question de priorité.

Par contre ça risque de coûter cher en ressources B-)

Certes, mais si le process Apache ne garde pas le keep alive, cest peut-être un nouveau process qui répond à chaque fois, c'est un peu l'idée derrière mon interrogation.

Hearthbeat, c'est un peu comme un ping dans une connexion SSH si j'ai bien compris. D'où l'association d'idées, d'où la question.

Du coup, est-ce qu'un serveur Apache avec keep alive désactivé était vulnérable ?

Il semblerait que ce soit même encore plus vieux, mais je ne parviens pas à trouver de références sur le sujet.

De mon point de vue, la culture des threads c'est répandue depuis MS Windows, qui en avait besoin pour contourner des défauts de conception des processus de MS Windows NT.

Maintenant, si tu as une source qui donne une histoire des threads, je suis preneur.

Je regrette beaucoup le peu de femmes présentent dans le monde du développement, parce que j'ai envie de croire qu'il n'y a pas de différence fondamentales imputable au sexe.
Malheureusement, si le résultat de l'ouverture aux femmes est GNOME 3, avec un état des finances catastrophique, sa donne du grain à moudre aux sexistes et m'entraîne à réviser mon jugement.
Mais bon, le résultat n'est pas imputable aux peu de femmes présentent dans le projet, à moins que, comme le croient les sexistes, les femmes sont un poison à faible dose.

Au delà de ses considérations sociologiques, je déteste le charity business et la discrimination dite « positive ». Dans un cas comme dans l'autre, il ne peut qu'y avoir le doute sur la compétence du bénéficiaire, une suspicion permanente. Donc brûler un quart du budget dans le charity business plutôt que de financer la création d'un bureau qui plait aux contributeurs (financier), oui, ça me fait mal au cul.

Pour finir, le problème de trésorerie n'est pas dû au programme de promotion des femmes dans le milieu : c'est la chute des dons et autres contributions qui a mis la fondation en difficultés. Dire que c'est la faute au programme de soutient des femmes, c'est accuser les femmes d'être les responsables de la crise pour pouvoir se dédouaner, et garder la tête dans le sable encore un peu plus longtemps. Et c'est détestable.

La fondation GNOME a publié sa nouvelle mouture. Au menu, autant de remaniements que de stabilisations. Le projet n’a jamais fait preuve d’autant de vitalité et pourtant a rarement été aussi inaccessible.

On peut rire ? C'est peut-être la formulation du paragraphe qui est maladroite, mais la fondation n'est pas vivante : elle vient d'être plongée dans un coma artificiel. http://www.phoronix.com/scan.php?page=news_item&px=MTY2Mjc

Ce n'est pas surprenant : en voulant acquérir des utilisateurs à la concurrence en proposant aux clients de la concurrence ce qu'ils ont déjà, et en expliquant à ceux qui utilisent GNOME au quotidien qu'ils sont des crétins conservateurs, il n'est pas étonnant que ces derniers ne supportent plus et que les premiers ne peuvent être charmés.

Bref, les fan boy GNOME Shell sont dans la place.

Si le concept de processus Léger a été inventé et est aujourd'hui si utilisé, c'est pas pour les chiens

Pour MS Windows en fait. La création de processus est tellement coûteuse sous MS Windows qu'il a bien fallut contourner.

Et oui c'est un argument contre, car n'importe qui qui a déja utilisé la shm sait à quel point c'est pénible, contraignant et source d'erreurs ( deadlock entre autre ).

Un peu comme pour les threads.

Les threads c'est très dangereux, tout autant que de partager de la mémoire entre processus via un IPC. La différence est qu'en utilisant un IPC, ce n'est pas l'ensemble de la mémoire du processus qui est partagée entre les différents threads.

Bref, les threads sont nécessaires, utiles, mais il ne s'agirait pas de raconter des conneries et de prétendre qu'une approche multi-processus est caduque. Le contre-exemple par excellence est Google Chrome : il allie à la fois l'usage des processus et des threads.

aucune configuration serveur nécessaire

Même pas un p'tit Vhost ?

pas de base de données à installer et configurer (c'est du sqlite)

Misère ! Apache avec un droit en écriture dans le répertoire qui contient les sources ?!!

De ce fait, Zotero qui délivre des versions standalones (Mac, Windows, GNU/Linux, extensions browsers) est clairement obsolète en 2014 (à titre personnel).

C'est comme la vie privée, c'est clairement too 2013.

Je suis heureux de voir que les développeurs Java ont découverts les pointeurs de fonctions membre :-D

L'explication est intéressante, merci.

Je me suis certainement mal exprimé : le problème ne sont pas les lambdas en Java : ce sont les lambdas le problème. Que ce soit en JS, en PHP, en C++ ou en Python, je n'utilises jamais les lambdas. Je définis toujours une fonction que je peux tester unitairement et réutiliser plus tard ou ailleurs.

J'avoue, j'utilises les lambdas pour le prototypage, pour pouvoir écrire mon code en flux tant que je tiens une idée. Après, je nettoie.

Heureusement tout le monde ne s'est pas couché devant le délire des adorateurs de PSR. Tout comme je ne pense pas qu'il soit sain d'avoir une monoculture de l'OS, autant je trouve ça stérilisant et abêtissant de le faire là où la créativité devrait être reine.

Mais bon, les gens qui ont mis au point les PSR sont principalement des « développeurs Web depuis MS Windows », et on ressent bien la culture MS Windows dans l'approche des différents frameworks se réclamant de PSR.

Notes bien que PSR c'est tellement pensé que, avec à peine 5 PSRs, la 4 corrige déjà la 0…

Je n'aime pas les lambda. Même si c'est pratique, ça brise le principe DRY. Un peu comme un programme en C dans lequel est réimplémente une liste chaînée dans chaque module où c'est nécessaire.

En C++11, la création de lambda peut entraîner la génération et l'invocation d'un functor si l'inlining n'est pas trivial. Ce n'est pas le cas avec les lambdas Java ?

Voici la complexité d'un proxy naïf :

<?php

class proxy
{
    private $targets = array();

    public      function __construct(array $targets = array())
    {
        $this->targets = $targets;
    }

    public      function __call($method_name, $args)
    {
        foreach($this->targets as $target)
            if(method_exists($target, $method_name))
                return call_user_func_array($target, $method_name);

        throw new exception(sprintf('Method \'%s\' doesn\'t exist', $method_name));
    }
}

class first
{
    public      function first()
    {
        return 'first';
    }
}

class second
{
    protected   function second()
    {
        return 'second';
    }
}

$proxy = new proxy(array(new first, new second, new third));
assert('first' === $proxy->first());

try
{
    $proxy->third();
    assert(false);
}
catch(exception $e) { }

$proxy->second(); // This trigger a fatal error
assert(false);

Avec une VM nommée « Just a scratch » :o)

Il y a en fait déjà des erreur/warning liés aux standards stricts pour PHP. Du genre, on ne peut pas changer la signature d'une fonction réécrite dans une classe dérivée. Mais si tu désactives l'alerte dans la configuration error_reporting, tu ne le vois plus (mais c'est mal).

Voir E_STRICT dans :

• http://php.net/manual/en/function.error-reporting.php
• http://php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
• http://php.net/manual/en/errorfunc.constants.php

Ce n'est pas parce qu'un système marche bien qu'il ne peut aller mieux. Le langage en lui-même semble satisfaisant, avec son workflow qui permet d'avancer rapidement quand on prototype, puis conçois, puis finalise un produit.

FB voulait gagner en performance pour économiser de l'argent et en facilité pour gagner du temps. Bref, plutôt que d'inventer un langage caduque comme JavaScript, ils ont gardé un langage pas trop mal, simple, qu'il est possible d'évoluer facilement en interne.

Plutôt que de conclure qu'ils sont dans l'erreur, peut-être que tu devrais accepter que le plus gros site web utilises PHP pour le templating de ses pages web ? Et que ça marche bien.

Tu peux tester avec ton PC en veille 30 jours pour voir ce que ça donne à son réveil ? :p

Ce qui est pragmatique, c'est d'urtiliser les outils de Google, gratuits et simples. Refuser cette centralisation c'est tout sauf pragmatique.

http://en.wikipedia.org/wiki/BitTorrent

J'dis ça, j'dis rien.

Tu n'as jamais dû utiliser VirtualBox pour prétendre que c'est une solution acceptable. Tout simplement, c'est bogué jusqu'à la moelle. Mais j'avoue que des machins bogués jusqu'à la moelle, qui ont eu du succès parce que simple, il y en a un qu'on aime particulièrement par ici.

Ah, et un truc qui s'appelle VM4Nerds, ça annonce la couleur qu'il faut un peu de compétences techniques, et donc de travailler depuis un OS qui fonctionne.

Euh, en fait non. Les dernières « normes » du Web sont écrites à partir des expérimentations des différents navigateur. Il n'y a qu'à voir XmlHttpRequest par exemple.