http://news.netcraft.com/
Les dernières études de Netcraft montre une descente aux enfers d'Apache (qui ne représente plus que 50% de part de marché) et une hausse très significative de IIS (35% environ)
Depuis le début 2007, cela s'accentue, ce qui laisse présager que IIS deviendrait leader en 2008 (et pour la première fois).
Est ce quApache est en train de se faire Netscapiser ?
Quelles sont les raisons de ce déclin ?
- Un IIS 6.0 plus fiable et performant, pas trop cher ?
- Apache 2.x qui ne plait pas ?
- Une campagne marketing poussée de Microsoft ?
- La démocratisation de Windows 2003 ?
De mon côté, mon entreprise (qui fabrique entre autre des logiciels de type N-tiers) a choisi Apache comme serveur Web par défaut pour ses applications (Apache est requis par certains logiciels). Mais la raison n'est pas pour sa fiabilité, sa robustesse ou encore sa velocité (en fait les Bench ont montré que sous certaines conditions, IIS 6 l'emportait), mais tout simplement parce que IIS etait mono plateforme, et que c'etait incompatible avec une grande partie des pré-requis de nos clients (même problème pour SQL Server 2005, pourtant pas mauvais, on a du se rabattre sur Oracle et DB2 car SQL Server 2005 ne fonctionnait que sous Windows).
Dommage car ça pourrait faire des clients supplémentaires pour Microsoft
Journal apache perd du terrain face à IIS de manière inquiétante
8
sept.
2007
# Le nombre de serveurs Apache croit toujours,
Posté par Bruno Ethvignot (site web personnel) . Évalué à 7.
Certaines raisons que j'ai identifiées :
- Microsoft a payé certains gros hébergeur comme Go Daddy pour passer leurs pages statiques de Apache à IIS
- Google a passé de Apache à son propre serveur Web (4,90 % en moins pour Apache)
- Le succès de MySpace qui est une solution entièrement hébergée sur IIS
[^] # Re: Le nombre de serveurs Apache croit toujours,
Posté par BAud (site web personnel) . Évalué à 2.
Effectivement, les "pages de parking" et les plateformes de bloggers jouent pas mal (il faudrait un indicateur "nombres de serveurs" en plus de celui de "nombre de domaines", même s'il y aurait des surprises àmha dans les 1er résultats...).
Le prix des serveurs joue aussi beaucoup, les *BSD et GNU/Linux présentant sur ce point le même avantage que des serveurs Windows, et bien d'autres avantages sur tout le reste bien sûr ;-) ).
# PGP ??
Posté par eastwind☯ . Évalué à -10.
# Plusieurs hypothèses
Posté par Jerome Herman . Évalué à 10.
La seconde hypothèse est que PHP/Perl ont complètement loupé le coche. je ne veux pas tomber dans le troll sur langage PHP, mais ilf aut bien admettre que malgré les gros efforts du zend optimizer et les améliorations dans la série 5, le PHP a pris une génération de retard au niveau de la faclité de dev et de la productivité. Ruby (on rail ou pas), Python et (mon favori personnel) Erlang ne sont pas encore au niveau pour assurer la relève. Résultat on a rien de comparable à la plateforme .Net sous Linux. J2EE étant un poil trop complexe pour pouvoir être utilisé "partout". Et pourtant .Net est une très mauvaise plateforme (gestion mémoire catastrophique, système de cache à la con, threads à configurer un par un pour éviter les catastrophes en j'en passe).
Dernière hypothèse, et c'est à mon sens une grave lacune du monde libre aujourd'hui : on a pas de cubes et surtout pas de plateformes pour les exploiter. Vu l'espace disque dont on dispose aujourd'hui, pourquoi créer une base de données quand on peut faire un cube ? Si celui-ci est bien créé on se facilite la tache de façon monstrueuse pour tout ce qui est reporting. Plus besoin de faire venir un dev qui touche bien se bille en SQL si il faut consolider les données de l'années. Et au niveau simulation c'est le jour et la nuit par rapport aux BDD classiques. Seulement interroger un cube OLAP ou même en Star-Schema en ligne de commande bonjour. Il faut donc un SDK complet avec un générateur de requètes optimisé et un système d'audit de perf capable de remonter quelles hiérarchies simplifieraient/accelerreraient le travail. A ce niveau là en solution sous Linux (propriétaires ou libres) on est au point mort. Et pas de bras, pas de chocolat...
Sinon il y a aussi un phénomène boule de neige. Avec un Active Directory, Exchange (autre très mauvais produit, même en version 2005) et IIS il y a moyen assez simplement de créer un groupware complet extranet. Si on ajoute reporting services (obligatoire avec Exchange 2005) on a un outil de gestion de documents et de suivi assez complet. Donc on fait rentrer des compétences IIS pour tirer parti à fond des licences qui ont déjà été achetées, et un fois que les compétences IIS sont là...
[^] # Re: Plusieurs hypothèses
Posté par Anonyme . Évalué à -7.
[^] # Re: Plusieurs hypothèses
Posté par Thomas Douillard . Évalué à 3.
OLAP, etc, c'est pas tout jeune à ce que je sache, j'ai vu des soutenances de thèse dans lesquelles c'était loin d'être l'état de l'art. Pourquoi on a pas ça en libre ? question d'interface dans laquelle la philosophie CLI qui a longtemps été fonfamentale dans le libre est pour le coup vraiment has been quand on cherche à visualiser des données multidimentionelles ou tirer des infos complexes de Bases de données, manques de compétences, qui seraient rares et chères, manque d'intéret direct de la communanuté, techniques "à la pointe" qui nécessitent pas mal d'investissement en r&d ? IBM qui n'est pas très enclin à libérer ce genre de technologie "haut niveau" par opposition au trucs plus bas niveau genre kernel ou IDE "de base", genre eclipse, et qui porte la valeur ajoutée, justement là dessus, niveau décisionnel ?
Même chose pour la souplesse de configuration du serveur version perf et/ou sécurité. La communauté se serait elle un peu laissée endormir ? d'un autre coté on a toujours été partisants des solutions versions "c'set possible de le faire, mais faut mettre la main dans le cambouis" question configuration.
Ou alors a l'inverse la position d'ubutu d'avoir un truc qui "juste marche" mais plus adapté au grand public qu'au monde de l'entreprise.
Ça pose à réfléchir ...
[^] # Re: Plusieurs hypothèses
Posté par BAud (site web personnel) . Évalué à 6.
et avec https://linuxfr.org/2007/08/25/23034.html "Kochizz, éditeur de configuration Apache, est disponible", ceux qui préfèrent un clickodrome pour effectuer la configuration, cela permet de bénéficier du meilleur des deux mondes.
[^] # Re: Plusieurs hypothèses
Posté par Jerome Herman . Évalué à 7.
Tout d'abord il est assez simple sous IIS de sauvegarder et de restaurer une config ou l'ensemble des configs web que ce soit via une sauvegarde brute (par vbs ou par copie des entrées de la base de registre) et de la redéployer derrière. De plus généralement il ne suffit pas de dupliquer les fichier de config, mais il faut aussi redéployer tout les objets qui font tourner le site. C'est à dire redéclarer les bibliothèques, redescendre les bons droits sur les répertoires et les fichiers, ouvrir les règles firewall etc. Là un Windows 2003 peut, suivant les cas être au final plus facile à déployer qu'un équivalent libre. Une règle dans l'Active Directory, un MSI (packageur sous windows) bien fait et ca rouel tout seul.
Même si personellement je préfère avoir un CHROOT assez complet que je peux trimblaller facilement d'un serveur à un autre, la lourdeur liée aux clickodromes est facile à esquiver pour peut que l'on se donne un peu de mal au début sous Windows.
[^] # Re: Plusieurs hypothèses
Posté par BAud (site web personnel) . Évalué à -1.
non, pas besoin de répondre, tu parles de AD, MSI... ceux que je connais trouvaient ça trop compliqué, ils se disaient pourtant admin :/ (et pourtant j'avais la main pour proposer effectivement des archis propres). Bref, au moins avec de l'apache, c'est plus simple de convaincre de se simplifier la vie que dans le monde windows où il faut toujours déployer un nième serveur troué estampillé proprio (et surtout ne pas se poser de question ou réfléchir).
[^] # Re: Plusieurs hypothèses
Posté par Misc (site web personnel) . Évalué à 1.
Faire un mapping direct des options de apache, c'est pas forcement le meilleur moyen de faciliter la configuration. Il faut essayer de retreindre et faire du plus haut niveau
C'est comme prendre gcopnf-editor et appeler a un éditeur de configuration.
Mais je reconnait que je me base uniquement sur les screenshots.
Et je rappelle aussi que c'est pas nouveau, il y avait comanche , dispo il y a 5 ans, et complement inutilisisé ( et je pense qu'il a même disparu ).
[^] # Re: Plusieurs hypothèses
Posté par gazbhan . Évalué à 2.
En plus de l'interface (web) fournie (JPivot), il en existe d'autres comme FreeAnalysis.
C'est développé par Bpm-conseil et ca marche plutot bien ... Le but étant d'avoir une plateforme OLAP complète, permettant de se connecter à du Mondrian, du SSAS, Hyperion ....
(oui j' avoue je fais ma pub :) )
[^] # Re: Plusieurs hypothèses
Posté par Gniarf . Évalué à -1.
[^] # Re: Plusieurs hypothèses
Posté par yellowiscool . Évalué à 1.
Envoyé depuis mon lapin.
[^] # Re: Plusieurs hypothèses
Posté par Nicolas Schoonbroodt . Évalué à 6.
[^] # Re: Plusieurs hypothèses
Posté par Mars . Évalué à 2.
>
En effet il est très rare qu'un seul facteur soit la cause de tous les maux. Concernant la chute relative d'Apache il en est certainement de même.
Tout comme il est certain que l'un de ces maux est plus important que les autres.
Je pencherais pour l'arrivée conjointe de Silverlight (MS) et Air (Adobe) comme facteur déstabilisant pour le Monde du Libre. Apache n'est pas la seule victime désignée mais très certainement Mozilla aussi.
Et ce n'est pas le portage de Silverlight - par Mono interposé - par Miguel de Icaza/Novell qui va améliorer les choses. Tout d'abord parce que Mono court après .Net et n'est pas prêt de le ratrapper et secondo parce qu'il est peu probable que MoonLight puisse jamais rivaliser avec l'original qui aura lui aussi en permanence une longueur d'avance. Sans compter les problèmes de licence que MS fait peser sur qq brevets .Net/Mono.
Si Php/Mod_perl/Ruby/Python n'avaient pu constituer une alternative libre plus que valable - simple et puissante à la fois - aux solutions propriétaires comme JSP/ASP il fort probable qu'Apache n'aurait pas constitué pendant tant d'années 2/3 des serveurs Web.
Aujourd'hui avec les RIA/RDA de Microsoft on est à la croisée des chemins pour les outils libres adaptés au Web. Tout comme pour le Desktop d'ailleurs.
Les accords Adobe et MoFo ne couvrent pas tout le champ d'exploitation de ces technogies. La seule bonne et vraie avancée dans ce domaine concerne Tamarin. Pour le reste j'ai quelques doutes sur leur impact réel au profit du libre.
Pourtant à travers XUL/XulRunner il existait une plateforme/language qui non seulement constituait une alternative crédible mais surtout posait les bases de ces plateformes qui semblent constituer le Web nouveau.
Dans un article - traduit je crois chez Framasoft - Mitchell Baker refuse tout engagement/aide de sa précieuse MoFo et de son pactole pour ce RAD. Je crois sincèrement que c'est une erreur terrible.
Hier les décisions et le courage de M.Baker - et des ses amis/équipiers - de l'ex-feu-Netscape ont sauvé l'univers du Web et Mozilla par la même occasion d'une main mise totale d'une partie du Web par Microsoft.
Aujourd'hui ces mêmes personnes se focalisant sur le développement de Firefox et de son univers afin de toujours gagner des parts de 'marché' (sans faire commerce par ailleurs) ne voient pas que l'outil central du Web - le navigateur et le respect des sacro saintes normes de la W3C - n'est plus le centre des enjeux pour les firmes. L'affichage aux normes HD des vidéos de YouTube est peut-être à leurs yeux plus important que la résolution parfaite du test Acid. A ce jeu là Flash/ADOBE prend date pour le futur de manière plus convaiquante que Png/W3C.
Donc ces sauveurs d'hier risquent par leur aveuglement d'être la cause de la chute possible de Mozilla/Firefox et par ricochet d'Apache. Certes le discourt de Mit Baker est pertinent : c'est à la communauté de se prendre en charge et d'assurer le developpement de Xulrunner. Vrai très certainement. Mais peut-être pas aussi simple que cela :
- regardez Php et sa communauté. Eux aussi ils se sont fait déborder par de petits nouveaux venus du libre tout d'abord comme RoR. Demain il est plus que probable que le challenger principal soit la solution proposée par MS ou par Adobe.
- à ce moment là le challenge sera autrement plus élevé et conséquent en terme de moyens que celui proposé il y a quelques années par le couple ASP/IE4. Ce dont a profité Apache en apportant sa pierre à l'édifice. D'autant que ce dernier a de plus profité d'un revers juridique de la firme de Redmond sur son 'interprétation' du Java à la sauce Redmond. Apache, Tomcat, Sun ont été fort aise de de cette gamelle de leur meilleur ennemi. Aujourd'hui celui-ci a bien récupéré et compte bien se refaire...
D'ailleurs c'est par le succès relatif de RoR malgré la vague AJAX/Web2 que l'on peut être amener à douter que la communauté du Libre soit à même de proposer une alternative crédible - surtout si elle n'est pas l'initiatrice mais doit plutôt courir après - du fait que les moyens financiers sont beaucoup plus importants et donc nettement plus déterminants qu'il y a quelques années.
Il semble que dans le domains des GUI qu'elles soient adaptées aux Web ou au Desktop le Bazar se fasse damer le pion par la Cathédrale.
Gnome/KDE/Enlightenment/GnuStep sont ils à la hauteur de l'interface MacOSX ?
Y a t-il un équivalent - autre qu'à l'état de projet - au iTouch/iTel de Mac ?
Il semble que la firme californienne est une vue et un projet globals sur les IHM numériques alors que le libre ne semble apporter qu'une réponse au coup par coup au proposition faites par les entreprises. Et encore uniquement lorsqu'il existe des projets (là je pense à Google search et ses dérivés).
Ainsi il existe des alternatives à Spotlight aussi bien chez KDE que chez Gnome. Mais combien de temps après ?
Alors KDE4 sera t'il ce chevalier blanc tant attendu ? Quelle alternative nous propose Gnome dans un futur pas trop lointain ? Personnellement je l'ignore.
Et ce n'est pas sur leur site que je serais plus éclairé.
Soyons clair le libre n'est pas moribond. Loin s'en faut. Et il peut se targuer de TRES BELLES réussites. D'ailleurs elles sont trop nombreuses pour que je les cite. Trop peur d'en oublier ;-)
Il se trouve que depuis quelques temps je suis troublé par l'arrivée de Silverlight à la fois comme RIA que comme RDA et par la prise de position de Mitchell Baker.
La chute des stats d'Apache n'ont fait que renforcer cette inquiétude.
[^] # Re: Plusieurs hypothèses
Posté par Gniarf . Évalué à 4.
[^] # Re: Plusieurs hypothèses
Posté par BAud (site web personnel) . Évalué à 6.
http://fr.wikipedia.org/wiki/Rich_Internet_Application
http://fr.wikipedia.org/wiki/Smart_client (définition de Rich Desktop Application)
La MoFo est bien sûr la Mozilla Foundation et je pense que tout le monde connaît le XUL http://fr.wikipedia.org/wiki/XML-based_User_interface_Langua(...) et RoR http://fr.wikipedia.org/wiki/Ruby_on_Rails
[^] # Re: Plusieurs hypothèses
Posté par Misc (site web personnel) . Évalué à 6.
Tu penses à quels brevets exactement ?
Et en quoi est ce que c'est un probléme plus grave que les potentiels brevets sur tout le reste que microsoft devrait avoir, si j'en croit le discours de la FFII ?
J'ai du mal à croire que microsoft ne posséde pas de brevet liés au .doc ( openoffice, koffice, aboirod ), ou ntfs ( qui est dans le kernel linux upstream ).
[^] # Ror : Plusieurs hypothèses
Posté par Ontologia (site web personnel) . Évalué à 3.
Je me pose quelques questions au sujet de RoR qui à l'air assez fantatisque, surtout que je ne connais pas les concurents proposés par Adobe et MS.
Pourquoi RoR reste assez confidentiel ?
- Peut être parce que l'infrastructure serveur est assez complexe : en production il faut allier Apache et Mongrel, le mod_ruby posant quelques problèmes parait-il
- Jeunesse de l'application qui n'est stable que depuis 2004, soit moins de 3 ans, cela fait peu, et il faut bien voir que 3 ans pour former des compétences c'est peu. Voir des entreprises se lancer dans le développement de logiciels entiers utilisant ce framework, quand pas mal d'entre elles imposent celui-ci (souvent Java, pour être sûr de pouvoir repasser derrière à coup sûr) cela prend du tout. L'effet boule de neige est lent à démarrer au début.
- La lenteur : Selon le Shootout (bon ça vaut ce que ça vaut), Ruby est 3 fois plus que PHP qui est lui même 10 fois plus lent que Java ! Ca dissuade dans un contexte ou l'on essaye de faire des économie d'électricité dans les salles serveur, lorsque les problèmes de gestion de la climatisation restent problématiques. Et dans un contexte multi-coeur, Ruby est-il facilement multi-thread ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Ror : Plusieurs hypothèses
Posté par Yusei (Mastodon) . Évalué à 1.
Concernant la lenteur, il n'y a pas actuellement de solution, et Ruby ne tire pas vraiment profit des multi-coeurs. Les threads Ruby n'utilisent qu'un coeur. Par contre, il faut savoir que:
- Avec Rails et un serveur web bien configuré, on peut traiter plusieures requetes en parallèle et donc là le multi-coeur est exploité automatiquement
- La prochaine version de Ruby utilisera une machine virtuelle avec, si j'ai bien compris, compilation JIT.
Concernant l'alliage entre Apache et Mongrel, je me demande comment ça fonctionne, car Mongrel est un serveur web. Peut-être veux tu dire Apache et FastCGI ? C'est en effet d'une lourdeur indicible, et un gros frein au déploiement d'applications Rails. Ça fait un an que j'en installe régulièrement et que je ne fais (presque) que des applicatons rails, et je galère encore parfois avec FastCGI.
En dehors de ça, c'est quand même un framework génial. Pas parfait, mais très agréable à utiliser. Au point de me faire parfois choisir de coder une application web plutôt qu'un client lourd, alors qu'en réalité je préfère les clients lourds.
[^] # Re: Ror : Plusieurs hypothèses
Posté par Hank Lords . Évalué à 2.
Le principe c'est de mettre un apache pour servir les pages statiques (images, etc, ...), chose que apache (ou lighttpd, ou autre) sait très bien faire, puis de rediriger les autres requetes (avec mod_proxy ou mod_rewrite) vers mongrel qui sert rail.
Après tu peux compliquer en faisant du load balancing sur un cluster de process mongrel ou même faire du cache. Mais là il vaut peut-être mieux utiliser un 'vrai' reverse proxy à la squid ou un truc plus moderne (j'ai oublié les noms).
Rien que du classique finalement :)
[^] # Re: Ror : Plusieurs hypothèses
Posté par fredix . Évalué à 4.
Mongrel est surtout un serveur applicatif, donc il suffit de configurer un proxy Apache via un vhost en quelques lignes... Je te déconseille l'utilisation de fastCGI, Mongrel est très efficace et c'est trivial à mettre en oeuvre. En plus il est facilement extensible, voir le shortcuts de O'Reilly.
[^] # Re: Plusieurs hypothèses
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
> ASP avec des paramètres totalement différents pour des raisons de
> sécurité qui appellent la même base de données avec d'un coté des
> appels extrèmement intensifs pour une mise à jour immédiate des
> données et de l'autre une gestion de cache optimisée pour minimiser
> les accès base est assez délicat sous Apache/PHP, rien que de gérer
> des php.ini différents en fonction des sites est problématique, et
> pour la gestion des accès il va probablement falloir se farcir une
> gestion du cache à la main (ce qui est toujours une très mauvaise
> idée, tant la question est délicate). Sous IIS ca se fait facilement.
> On met un processus middle tier par site et on règle les paramétrages
> OleDB par site et basta.
Mais que je sache il n'y a pas de possilités similaires au chrootage ou
à la mise en jail pour IIS - sauf à virtualiser. Ce n'est donc pas
véritablement de l'isolation.
[^] # Re: Plusieurs hypothèses
Posté par Jerome Herman . Évalué à 2.
à la mise en jail pour IIS - sauf à virtualiser. Ce n'est donc pas
véritablement de l'isolation.
C'est possible, mais ca demande un boulot de dingue et ca n'est pas franchement recommander. Généralement on se contente de déplacer dans le bon répertoire les DLL et les objets COM que l'on veut instantier avec des droits spécifiques.
Mais bon d'un autre coté dans APACHE l'utilisateur qui hérite du HTTPD et qui écoute sur le port 80 a tous les droits en lecture sur toutes les pages de tous les sites web, et tous les droits en execution sur tous les modules et tous les CGI. Sous IIS il est possible d'avoir un utilisateur qui ne fait que lancer le service et d'avoir d'autres utilisateurs pour la lecture et l'execution des pages et des middle tier.
Dans les deux cas il y a des avantages et des inconvennients. L'ideal serait d'avoir les deux, comme c'est le cas par exemple avec TOMCAT ou le demon APACHE ne sert que de vecteur au middle tier, lequel peut ainsi être complètement isolé (que ce soit au niveau des droits ou au niveau système). Mais je serais personellement bien en peine de dire laquelle des deux strategie (isolation des droits ou isolation système) est en théorie la plus forte. Dans un cas on est sur que même si il y a escalade de privilèges, l'intrus ne pourra pas détruire plus que le contenu du jail, dans l'autre cas on est sur que si l'on a un site qui est percé, celà ne présente pas d'avantages pour percer le site d'à coté.
Cependant il existe sous Linux un moyen d'avoir les deux en créant un chroot-jail divisé en domaines SE-Linux et avec une gestion d'ACL-Posix. Seulement SE-Linux c'est à se taper la tête contre les murs. Aucune distribution ne gère SE-Linux au niveau des paquetages (pour les utilisateurs de Fedora, bien que la gestion utilisée soit mieux que rien, elle n'apporte au final pas grand chose) ce qui entrainne que toute mise à jour implique que l'on passe pas mal de temps (ie plusieurs jours) le nez plongé dans la doc à corriger les domaines et les droits...
Donc la double isolation existe sous Linux, mais elle n'est pas utilisable...
[^] # Re: Plusieurs hypothèses
Posté par briaeros007 . Évalué à 5.
Vraiment ?
(http://packages.debian.org/sid/apache2-mpm-itk)
Bon je suis d'accord que c'est expérimental, mais ca existe.
[^] # Re: Plusieurs hypothèses
Posté par BAud (site web personnel) . Évalué à 5.
euh non, pas dans le cas général en tout cas, pour exécuter du php avec moins de droits, voir module suphp de apache, avec la gestion appropriée des droits au niveau Unix/Linux tout simplement pour éviter de remonter dans les arbos des autres sites.
Sinon, tu penses bien que sur du mutualisé, ce serait bien simple de récupérer pas mal de passwords...
Après, s'il manque la même chose pour python, ruby, perl... dommage quoi, c'est un frein pour les hébergements mutualisés sur lesquels il vaut mieux isoler les différents utilisateurs...
Pour les autres besoins de sécurité d'un web mutualisé, voir http://faq.tuxfamily.org/WebArea/Fr#Pourquoi_TuxFamily_ne_fo(...)
[^] # Re: Plusieurs hypothèses
Posté par Jerome Herman . Évalué à 1.
Attention à ne pas confondre deux choses :
- D'une part la descente de droits. A savoir que le process initialisé par Apache se récupère un autre uid au moment de l'execution et de fait perd des droits.
- D'autre part l'isolation : à savoir que IIS ne peut pas du tout faute de droit initaliser tel fonction ou tel objet.
Pour modéliser rapidement dans un cas on a un utilisateur système qui gère tout et qui ensuite rabaisse les droits des différents processus, et dans l'autre on a plusieurs utilisateurs qui gèrent chacun leur morceau et pas plus et qui communiquent entre eux.
suphp permet de rabaisser les droits du script d'execution à ceux du propriétaire du fichier, mais rien n'empècherait l'utilisateur httpd de lancer le fichier sans passer par suphp et de fait de l'executer avec les mêmes drotis que ceux d'Apache. Donc si il y a une faille dans le script PHP lui même, on est protéger, mais si il y a une faille dans httpd la porte est grande ouverte et l'intrus qui gagnerait les droits pourrait alors avoir accès à l'ensemble des fichiers et des modules/CGI gérés par Apache.
A contrario si il y a une faille dans IIS 6.0 en mode isolation, l'intrus peut arreter et redemarer IIS envoyer des requètes au différents modules et objets COM normalement appelés directement par IIS, mais il n'a pas accès, aux source des pages, aux scripts .Net ni aux comportement des objets COM.
[^] # Re: Plusieurs hypothèses
Posté par fredix . Évalué à 3.
On a quand même pentaho et talend : http://www.talend.com/ http://www.pentaho.com/
[^] # Question stupide
Posté par Ontologia (site web personnel) . Évalué à 2.
Ca pourrait aider ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Plusieurs hypothèses
Posté par wismerhill . Évalué à 4.
(moi je ne connais que la figure géométrique)
[^] # Re: Plusieurs hypothèses
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Plusieurs hypothèses
Posté par Jerome Herman . Évalué à 6.
Pour schématiser prenons une socitété. Cette société comprend plusierus services. Chaque service a un budget qui lui est propre et qu'elle répartie dans différent centre de couts ou qu'elle investit sur différents projets. bein entendu il y a à la tête de chaque service un chef et idem à la tête de chaque projet. Tous les mois ces gens font le bilan entre ce qui a été budgeté, Ce qui a été dépensé et ce qu'il est prévu de dépenser au final. Bien entendu celà doit être remonté, par service, par projet et en global par rapport total pour que la société puisse savoir mois après mois ou elle en est.
en approche classique c'est à se taper la tête contre les murs. Il faut créer des clefs et des contraintes dans tous les sens, faire la différence entre ce qui a été alloué directement au projet et ce qui vient des services, le tout avec un suivit mensuel. Et si par malheur deux services fuisonnent ou qu'un projet passe à la trappe, il faut appeler un DBA chevronné pour réussir à recréer des données cohérentes.
Un cube va permettre d'organiser tout celà comme un seul agrégat de données. On va définir des hierarchies et c'est le cube qui va se charger de faire les opérations qui vont bien pour donner des chiffres cohérents.
On aura donc un cube "société"
Une première hiérarchie "année" portant sur toutes les années interressantes (de 2004 à 2008 par exemple)
une seconde hiérarchie "mois" avec les trimestres qui sont la somme des mois correspondant. etc.
Au final :
Année
- 2004
- 2005
- 2006
- 2007
- 2008
Mois
-1 er trimestre
-- janvier
-- février
-- mars
- 2eme trimestre
-- avril
etc.
Services
- informatique
-- administration
--- admin linux
--- admin windows
--- réseaux
--- bases de données oracle
--- bases de données DB2
--- support
etc.
Ensuite on interroge les dimensions : par exemple on peut demander pour l'année 2007 au mois de mars combien le service windows a couté. Le cube va alors chercher l'ensemble des données qui correspondent aux critères et les combine (ici ce sera une addition) pour donner le résultat souhaité.
Le requètage devient alors simplissime. Au cas ou deux services fusionnent il suffit de les déplacer en hiérarchie pour obtenir les données combinées.
exemple :
Services
- informatique
...
--- bases de données unifiées
---- bases de données oracle
---- bases de données DB2
et le cube se charge de mettre dans le nouveau service "bases de données unifiées" la somme des deux anciens services.
Une fois le travail (fastidieux, et j'en sais quelquechose) de définition des hiérarchies terminé on a alors un système de données extrèmement simple et intuitif à interroger. Les utilisateurs finaux peuvent alors créer eux mêmes leurs propres requètes et le DBA n'a qu'à surveiller la charge machine et l'occupation disque (dans un monde théorique hein...)
# la forte progression d'IIS en decembre 2005
Posté par ArnY (site web personnel) . Évalué à 4.
Il y a aussi le fait que Google utilise maintenant un apache modifié qui s'annonce comme Google Web Server alors qu'il etait comptabilisé comme apache précedemment.
# .Net ?
Posté par Bruno Adele (site web personnel) . Évalué à 3.
# Kochizz pourrait changer la donne
Posté par Denis Szalkowski . Évalué à 2.
Je crois également que l'accord Zend-M$ sur le Php pour IIS permet aujourd'hui d'envisager de migrer vers IIS. Les entreprises cherchent à minimiser leurs plates-formes à administrer. Malgré l'augmentation significative de serveurs Linux, en pourcentage, compte tenu de la croissance de ce marché, j'ai l'impression que Linux régresse.
Enfin, les grosses entreprises mettent en oeuvre des proxy inverses pour limiter la fragilité de IIS si il était exposé en frontal.
Pour faire simple, les raisons sont multiples.
La suite -> ici
# 1.3.37 vs 2.2.6
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Et vous trouvez vous qu'apache2 soit à la hauteur de la première version ? Sommes nous vraiment des gros nazes ou y a-t-il en terme de performances une différence notable ?
[^] # Re: 1.3.37 vs 2.2.6 et godwin
Posté par allcolor (site web personnel) . Évalué à 0.
Ça doit provenir d'un problème de nazisme.
=====>[je n'étais de toutes façons pas là]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.