mercredi, février 10, 2010

Google Snowmobile: Streetview aux JO de Vancouver

Bien sûr la controverse StreetView n'est pas terminée: on attend toujours la décision du tribunal fédéral suisse.

Mais, entretemps, Google fait de son mieux pour montrer les aspects diverstissantes de cette technologie: pour faire partie de la fête à Vancouver, les ingénieurs de Mountain View ont déplacé la technologie utilisée auparavant sur des voitures standards vers un scooter des neiges qui s'est promené sur toutes les pistes de ski et installations des Jeux Olympiques de Vancouver pour permettre aux malheureux (comme moi...) qui n'en sont pas de s'immerger quand même un peu dans les lieux, au moins virtuellement....

Voici la présentation de la Snowmobile de Google



Et le fruit de son travail est bien sûr déjà "live" sur Google Maps: cliquez ici pour vous retrouver à l'arrivée du télésiège de la piste de la "Crête Noire du 7ème Ciel" (7th Heaven Blackcomb) comme si vous y étiez....

Sinon, voici une capture montrant à quoi cela ressemble. Vous remarquerez:
  • en haut, à droite, que Google inclut maintenant des photos générées par les utilisateurs sur Panoramio, Picasa pour enrichir Street View. Les explications détaillées sur le sujet sont ici.
  • en bas à droite, que la Snowmobile a semble-t-il parfois mis certains skieurs sur le c... lors de son passage ;-) En plus, le floutage nécessaire ailleurs sur Street View est ici superflu...


Sur ce, bonnes vacances à ceux de la 2ème zone qui se préparent à partir en vacances de neige! Chez nous, dans le Jura, elles ont débuté depuis le week-end dernier.

Source: blog Media & Tech (par didier durand)

mardi, février 09, 2010

L'Internet français est dominé par des sites américains

Les internautes français visitent en premier lieu des sites créés par des sociétés américaines. C'est ce qui ressort très clairement des chiffres du Top10 des sites français publiés par Hitwise.

Ils confirment des faits déjà connus:
On voit dans ce Top10 encore Orange, SkyRock et LeBonCoin.fr. Cocorico !

Mais, jusqu'à quand? Je vais encore une fois me lamenter et répéter que nous (Français et même Européens) semblons avoir perdu plusieurs batailles voire maintenant la guerre sur le front des services en ligne. Je le dis depuis Quaero (...aussi ici) mais je vais encore pouvoir le répéter désormais, chiffres concrets à l'appui....

Source: blog Media & Tech (par didier durand)

lundi, février 08, 2010

Ubuntu et contrôle (parental): horaires d'accès et d'utilisation

L'idylle entre Ubuntu et la famille Durand se poursuit: si vous avez manqué le 1er épisode, il est ici.

J'aimerais maintenant mettre en place quelques règles sur les horaires d'accès: mon fils devient un grand "Facebook-addict" (je sais, ils sont beaucoup...) au détriment de son sommeil et bientôt de ses études.

Je cherche donc une solution qui me permette de bloquer son compte Ubuntu (et seulement le sien...) de manière automatique entre 22:30 et 07:30 pour régler le sujet. Une exploration de la des fonctions d'administration et de la logithèque Ubuntu n'ont rien donné.

En termes de contrôle parental, j'ai déjà donné les raisons qui m'opposent au contrôle du QUOI. Par contre là, j'aurais besoin de votre aide pour le contrôle du QUAND afin de préserver la santé de Junior.

J'attends avec intérêt vos suggestions. Soyez-en déjà remerciés!

Source: blog Media & Tech (par didier durand)

vendredi, février 05, 2010

Facebook <> Google News: le bouche à oreille plus prolifique pour la presse que l'algorithmique!

Facebook et Google ont 2 visions opposées de l'internet:
  • pour Google, c'est l'algorithmique ubiquitaire qui fera un monde (virtuel) globalement meilleur car optimisé de manière quasi-matématique
  • pour Facebook, ce sont au contraire des relations inter-personnelles intenses à tendance brownienne qui nous feront collectivement progresser puisque nous trouvons à travers les liens partagés des tonnes de choses que nous ne cherchions pas, donc qui élargissent notre "bande passante cérébrale"
Facebook est donc l'enblème de l'Economie de la Sérendipité telle qu'elle émerge actuellement: vous voyez défiler à bon rythme sur votre écran (si vous avez suffisamment d'amis...) des milliards de pointeurs non sollicités vers des documents externes qui peuvent vous permettre du "wilfing" permanent si vous le souhaitez.... Ensuite, à charge de l'éditeur du site de monétiser votre visite!

[Sur ce thème de la séréndipité, plus ou moins réelle et plus ou moins contrôlée, je vous conseille l'incroyable article d'Olivier "Ingénieries de la Sérendipité" qui va faire date sur le sujet!]

Revenons à nos moutons (industriels) sur le sujet: quelle approche est la plus prolifique pour l'industrie des contenus et du divertissement (i.e celle des médias) ?

Eh bien, à taille actuelle quasi-égale (en termes de trafic) entre Facebook et Google, le billet publié chez Hitwise montre que c'est finalement le bouche à oreille (Facebook) qui bat maintenant à plate couture le travail de la machine (Google News) en ce qui concerne les visiteurs envoyés vers les sites de média: le facteur est de presque 3!


Si l'on suit les récents chiffres de Eric Schmidt qui annonce 1 milliard de visites depuis Google News + 3 milliards depuis le moteur de recherche, on en déduit que Google doit additionner tout son trafic (moteur + News) pour rester à hauteur de Facebook en termes de pur volume de visites générées !

Par contre, il y a une immense différence entre Google News et Facebook:
  • Google News est la cible des éditeurs (Ruppert Murdoch en tête) car son fonctionnement de "synthétiseur / agrégrateur" fait que 44% de ses visiteurs ne cliquent jamais sur un lien pour aller visiter le site de presse car la synthèse qu'ils reçoivent par les brefs extraits publiés par Google leur suffit. Quand, de plus, Google met de la publicité sur ces pages du service News, c'est la goutte d'eau qui fait déborder le vase (ou l'encrier dans ce cas...)
  • Facebook sera plus tôt perçu comme le service qui permet à un individu de faire connaître à des gens qui lui font confiance (ses "vrais" amis!) des contenus qu'il juge intéressant puisqu'il prend le temps de les partager et de les commenter sans en retirer de bénéfice pécuniaire ni pour lui ni pour Facebook (au moins à première vue...)
Le capital sympathie de Facebook parmi les éditeurs va donc augmenter alors que celui de Google va encore rester de rebonds en rebonds sur la pente descendante pendant longtemps encore....

Source: blog Media & Tech (par didier durand)

jeudi, février 04, 2010

Facebook: 400 milliards de pages consultées chaque mois!

Facebook vient de mettre en open source son compilateur Hiphop du langage PHP. PHP est la pierre angulaire de son propre système mais aussi de sa plate-forme de développement pour tiers.

L'objectif atteint à travers ce "compilateur" (en fait un transformateur de source) est de doubler les performances du langage par rapport à un interpréteur PHP standard. Pourquoi est-ce tellement important à l'échelle de Facebook ? Parce que Facebook utilise déjà à ce jour 40 '000 serveurs pour servir ses 350 millions de membres très actifs: la moitié d'entre eux se connecte tous les jours.

En conséquence sii Facebook a la même stratégie que Google en utilisant des machines à moins de 1'000 dollars, cela fait donc au bas mot 40 millions de dollars d'investissements économisés! Cela vaut bien l'effort de se pencher sur les performances du langage de programmation...

Et pour quoi faire tous ces serveurs ? Eh bien pour servir 400 milliards de pages à ses utilisateurs chaque mois. C'est l'information "en passant" (totalement nouvelle pour moi !...) que livre le billet annonçant la publication du compilateur Hiphop.

Si on ramène à une vision plus instantanée , Facebook sert chaque seconde plus de 154'000 pages! [400 000 000 000 / 86 400 / 30] C'est à comparer aux 34'000 requêtes traitées par Google chaque seconde! On est dans le même ordre de grandeur: une requête Google correspond à plusieurs pages avec 1 page de question + 3-4 pages de réponses successives. C'est finalement normal car Facebook est le 4ème site mondial depuis peu juste derrière le trio GYM (Google, Yahoo, Microsoft)

154'000 pages par seconde, c'est colossal pour moi (pour vous aussi?) qui suis fasciné par ses systèmes à très grande échelle (Google, Yahoo, Microsoft, Ebay, Amazon) que seul l'Internet a généré. Il faut un pool d'ingénieurs au top du top mondial pour fabriquer de tels monstres.

C'est pour cela qu'Eric Schmidt, ceo de Google, considère que sa capacité à construire puis exploiter une tel système est le véritable avantage stratégique du géant de Mountain View, plus critique pour le maintien de ses multiples hégémonies que les 1'000 années-hommes investies dans les algorithmes de recherche.

Mark Zuckerberg doit partager cette vision de l'excellence opérationnelle puisque les performances dy système de son entreprise prouve qu'il rivalise déjà sur ce terrain avec son ennemi viscéral!

Source: blog Media & Tech (par didier durand)

lundi, février 01, 2010

Mozilla Weave: pour sauvegarder et synchroniser sans effort ses multiples navigateurs Firefox

La fondation Mozilla a libéré publiquement son extension Weave pour Firefox. Je l'utilisais personnellement en bêta depuis plusieurs mois.

Mozilla Weave est une extension de Firefox qui permet à l'utilisateur de sauvegarder en temps réel toute l'activité dans son navigateur Firefox vers les serveurs centraux de la fondation Mozilla. On sauvegarde ainsi ses marques-pages, son historique de navigation, les onglets ouverts, les préférences de configuration, les mots de passe des différents sites, etc.

Le but est double:
  • mettre en sécurité toutes ces infos hors de son PC de manière à pouvoir les récupérer si jamais un crash obligeait à un réinstallation violente (i.e avec formattage du disque) devait être enclenchée. Aucun temps perdu alors à récupérer toutes ces URLs auxquelle on tient comme la prunelle de ces yeux.. Même avec un Google de plus en plus affûté, il faut quand même parfois du temps pour retrouver la page (parmi 1 000 milliards!) dont on sait qu'on l'a lue mais dont on a perdu les mots-clefs de recherche par un moteur....
  • partager ces informations entre plusieurs PCs: les "firefoxophiles" (toujours plus nombreux !) sont souvent des techno-geeks avertis dotés de plusieurs PCs, téléphones mobiles and co: rien de plus fastidieux pour eux que de reconstituer leur patrimoine d'URLs en repassant d'une machine à l'autre car le lien dont a besoin maintenant est bien sûr resté dans les marque-pages de l'autre navigateur hors de portée pour l'instant. La célèbre loi de Murphy en action....
La crainte à avoir pour l'internaute autour d'un tel système déjà avancée à l'époque du lancement de Google Browser Sync qui resurgit maintenant pour Google Chrome? la sempiternelle violation de la sphère privée, i.e que ses informations soient utilisés pour un meilleur ciblage publicitaire de l'internaute voire même accéder à ses comptes (bancaires) dont il aurait stupidement accepter le stockage (nom d'utilisateur, mot de passe) par le service.

Sur ce sujet, la fondation Mozilla a fait de son mieux en encryptant fortement ces informations dès leur production pour avoir un stockage à moindre risque sur ses serveurs centraux. Ces informations seront alors hors d'atteinte pour tous, y compris les généreux donateurs de Mountain View ;-) ....

Moi, c'est un service dont je suis fan ! Il correspond à 100% à l'évolution de mon utilisation de l'Internet: toujours plus critique et toujours plus distribuée.

Longue vie donc et plein succès à Mozilla Weave !

Source: blog Media & Tech (par didier durand)

NACA tools & Zaap Processors: transcode a Cobol application to Java and still run it (but much more cheaply…) on the IBM mainframe with zOS!

UPDATE: Project NACA has given birth to Eranea, a company dedicated to 100% automatic migration of mission-critical apps to Java & Linux. Check out www.eranea.com or email to contact@eranea.com for more information
________________________________________________________________________________

In the NACA project (offload from a mainframe to Linux on Intel servers through 100% automatic transcoding of the 4+ millions lines of Cobol of the in-house application), in order to reach the maximum level of savings, we took a radical approach (downsize to Linux and stop the mainframe) to free up as much financial resources as possible. We wanted to maximize the investments for upcoming projects in our IT budgets:
  • replace IBM operating system zOS by Linux and Cobol by Java (through our automatic transcoder now open-.sourced)
  • replace the zSeries architecture of the mainframe by very simple Intel servers as soon as our benchmarks demonstrated that it was feasible at no risk for our level of activity (750'000 CICS transactions per day). Thanks to Moore's Law, the Intel Pentium proved itself to be highly powerful to handle high transactional workloads.
This very radical approach made us eventually very satisfied: immense cost reductions, availability and performances of new system, rollout of an internal disaster recovery mirror system, etc.
But, since the open sourcing of our NACA transcoding tools, we had the opportunity to discuss with many companies evaluating our technologies or already running transcoding projects with them on 4 continents (only Africa missing as of now!...).
Those discussions led us to develop a smoother and more "fluid" approach for corporations wanting simultaneously to leverage their mainframe assets and their strengths and to rejuvenate their legacy application:
  • Rejuvenate the application functionally: via the NACA tools, the Cobol application is automatically transcoded to Java source code and enjoys then following benefits: (a) as new "official" source code is Java, ability to leverage the very sophisticated environment of Java Virtual Machine still evolving very quickly (b) availability of many (open source) Java packages to integrate with the newly transcoded application to augment its capabilities (c) use of a state-of-the art user interface fully web-based (HTML-CSS-AJAX) as transcoded from the original 3270 BMS maps with no human intervention.(d) use of very modern development IDE (Eclipse through a specific plug-in) that strongly increases their productivity of legacy programmers as they continue seeing their initial and familiar Cobol code to maintain it.
  • Rejuvenate the application technically: the Java world is still highly dynamic and improving on a recurring basis. When on JRE, an application can progress just by "being here" and not doing much: we saw a 30% improvement in performances just by upgrading from Java 5 JRE to Java 6 JRE. This is in line with official Sun benchmarks. The Java community improves the JVM day after day to make Java now a clear rival of very efficient languages like C/C++.
  • Leverage mainframe assets and strengths: IBM wants its current clients to avoid such radical decisions as ours to keep them in the mainframe community. Consequently, IBM has launched some specialized processors dedicated to handling Java workload on the mainframe. They are called Zaap pour "zSystem Applicat ion Assist Processor". By using them and without any major evolution of the mainframe configuration in place, the naca-transcoded application now runs on those dedicated processors and consequently preserves a very stable and deeply known zOS environment.

Those Zaap processors have a double financial advantage as created by the IBM marketing:
  • they are themselves much cheaper than a regular mainframe processor (GCP)
  • their mips don't add themselves on top of the mips of the regular processors: they don't as such have a negative influence on the monthly software bill of the mainframe for zOS essentially based on mainframe performance. As a matter of fact, they even tend to reduce this bill as the workload run on Zaaps means less mips needed in the regular processors. See details of Zaaps below

Consequently, it is possible to use our NACA transcoding tools to transcode 100% automatically to Java and to simultaneously stay in the "comfort" of the established mainframe environment after transcoding. The application will then run under Websphere (or even in the transactional monitor CICS or IMS but in Java) in a JVM powered by Zaap under direct control of zOS. For batch programs, same architecture but simpler: only the JVM is needed.
Such a mainframe-hosted Java architecture is needed by corporations who want to leverage all the benefits of a transcoded application to Java and web-based UI (see above) but who want to keep it on the mainframe. The company can this way maintain all the integration of the transactional activity with other mainframe subsystems (batch, archiving, printing, etc) sometimes developed over many decades.
Everything stays "in the same box" but the end users can benefit right away from additional functionnalities of their application brought to state-of-the-art.
As additional benefit, this architecture can reduce the mainframe total cost of ownership at double level: (1) the Mips of the transactional workload have now migrated from the costly regular processors to the cheap Zaaps (2) the "regular" (Cobol/CICS) mainframe workload has become smaller, replaced by functionally equivalent Java workload, and the monthly software bill can be reduced as less mips are consumed (see IBM below)
The resulting effects are triple:
  • The legacy application has become state-of-the art, from both a user and a developer standpoint: 100% Java and Web
  • A smooth and fluid evolution: a potential mainframe-less future is prepared at no risk as current machine, very well mastered by teams in place, remains the unique vector of activities.
  • Savings generated by optimized configuration: all possible workload is transferred to the cheapest possible Java environment and the requirements of expensive GCP mips is highly reduced through maximum use of Zaaps wherever possible through the CICS workload migrated to Websphere or Tomcat.
This is the clear proof that gradual paths exist to massively leverage the financial and functional advantages of new technologies (Java) for legacy applications. The existing runtime system is not jeopardized: the operational competencies accumulated on the mainframe for decades can further be leveraged and at the same time the business competencies accumulated by in-house are also preserved as they continue maintaining familiar structures of source code. No leap jump is required when such is a the wish!
============== IBM Zaap processors
Source for schemes of this article: IBM presentations of Kathy Walsh.
Zaap processors are a significant step in the continuous investment by IBM to maintain the competitiveness of its mainframe zOS platform in the market, when facing fierce rivalry from Open Source (Linux) highly due to the intrinsic expensiveness of zSeries.
To achieve this goal, IBM consistently introduces new processors dedicated to some specific workloads. Those workloads transferred on cheaperinternal processors reduce the TCO of the global machine.
By Publicitas, we did start the NACA project on this path of dedicated processors: we initially started on an IFL processor (IFL = Integrated Facility for Linux) integrated in our ultimate mainframe in order to run another operating system than zOS: zLinux (linux distribution for the mainframe). We decided to move to linux on Intel servers only when internal benchmarks demonstrated that there was almost no risk and significant additional financial advantage to do so.
Since then, IBM has strengthened the concept of dedicated processors beyond the IFL original concept: the Zaap doesn't require another operating (zLinux) to offload activities but runs directly under the control of zOS. The slide below demonstrates the technical and marketing goals of IBM in this technology ( the yellow rectangle at bottom is to be read in details):



Through a marketing "secret sauce", it is all about migrating "central" mips to Java mips on a dedicated processor. The emergence of this new technology brings the opportunity of selling it on a different price scale and also the opportunity of eliminating it of the mips total used to bill the zOS software. So, the current software renting by the mips total remains unquestioned by the community of corporation running their core activities on mainframe. At the same time, the Zaap can be presented as the "white knight" reducing the total of mips hence the price.
As a result, the competitiveness of zOS is clearly improve din its current fight against the linux adoption for critical applications.
Source: blog Media & Tech (par didier durand)

vendredi, janvier 29, 2010

Sphère privée et expérience Panopticlick: l'empreinte unique de nos navigateurs Internet

Les grands réseaux publicitaires vivent d'un ciblage toujours plus pointu des bannières ou autres formes publicitaires qu'ils affichent: pour un réseau Adsense comme celui de Google fort de 1 000 000 de sites affiliés, il s'agit, pour un rendement maximum des budgets publicitaires du million d'annonceurs-clients, de retrouver un même internaute au travers de ses diverses visites sur les nombreux sites et sur les 1 000 milliards de pages du réseau.

Le principe est finalement. "montre-moi ce que tu lis / écoutes / regardes et je devinerai alors qui tu es". Le but = le ciblage comportemental plus que l'accès aux paramètres de l'identité (nom, prénom, adresse, etc.)

Les information ainsi collectées et analysées vont grossir la Base de Données des Intentions de Google (pour ne parler que de lui), critique pour son coeur de métier puisqu'il vit toujours à plus de 95% de cette publicité.

La croyance générale est qu'il suffit de stopper la gestion / émssion des cookies dans la configuration de son navigateur pour devenir l'Homme Invisible lors de ses errances internautes.

Eh bien, c'est faux: l'expérience Panoptclick de l'EFF, réputée pour ses actions de protection de la sphère privée le démontre très clairement.

Lors d'une simple visite sur cette page Panopticlick, l'EFF accède par Javascript (inclus dans cette page) à tous les éléments de configuration du navigateur (type, versions, options de configurations, extensions installées, etc...) et les retourne au serveur.

Avec ces éléments, l'EFF calcule (aller ici pour la théorie détaillée) une" signature" de mon navigateur pour déterminer à quel point sa configuration est unique.

Elle publie les résultats sous la forme de ce tableau (Cliquer l'image pour mieux voir)
Impressionnants tous les éléments que l'on peut découvrir avec une analyse un peu fine du système!

A ce moment, l'EFF dit que la signature de mon navigateur est unique parmi les 275'00 participants à l'expérience comme moi. Je vous encourage à participer pour voir à quelle point cette unicité est réelle pour vous aussi en faisant en parallèle grossir le "matériel" de l'expérience pour notre bien virtuel à tous!

Conclusion: quand vous êtes sur un site Web, souriez ! Que vous le vouliez ou pas, vous êtes "filmé"......

Source:
blog Media & Tech (par didier durand)

jeudi, janvier 28, 2010

Outils NACA & Processeurs Zaap: transcoder son application Cobol vers Java en restant (plus économiquement) sur son mainframe IBM avec zOS!

UPDATE 01-2012: Le projet NACA a donné naissance à Eranea, société dédiée à la migration 100% automatisée de grandes applications métier vers Java et Linux. Voir  www.eranea.com ou email à contact@eranea.com pour plus d'informations
_______________________________________________________________________
Dans le projet NACA (abandon du mainframe pour Linux et transcodage 100% automatique de Cobol vers Java des 4 millions de lignes de notre application maison), pour atteindre les économies maximales nous permettant ensuite des investissements plus massifs sur nos projets stratégiques, nous avons pris une approche radicale pour libérer un maximum de moyens financiers:


  • remplacer le système d'exploitation zOS par Linux (et Cobol par Java par transcodage automatique de notre application)
  • ensuite, remplacer l'architecture zSeries du mainframe par de simples serveurs Intel très basiques quand des bancs de test nous ont prouvait que l'architecture Pentium finalement hyper-puissante grâce aux vertus de la loi de Moore.

Cette approche radicale nous a finalement apporté pleine satisfaction (réduction drastique des coûts, stabilité et performance du nouveau système, possibilité de disaster recovery interne, etc.)
Mais, dans nos multiples discussions avec diverses sociétés (sur 4 continents - Elles mènent leur propre projets sur base de nos outils) depuis la mise en Open Source des outils de NACA, nous avons développé une approche beaucoup douce et fluide pour les sociétés qui veulent avoir le beurre et l'argent du beurre en ménageant la chèvre et le chou:
  • le "beurre logiciel": les outils de NACA sont utilisés pour transcoder l'application vers Java et ainsi bénéficier de tous les avantages d'un transcodage (voir les détails ici), i.e. (a) d'une mutation du code source de référence d'une application vers un environnement logiciel très sophistiqué mais en permanente amélioration, (b) de la profusion de packages logiciels ouverts et gratuits à intégrer à l'application transcodée pour la bonifier (c) d'une interface utilisateur native très moderne HTML+CSS+Javascript (=Ajax) sans avoir à retoucher les programmes anciens (d) de l'utilisation d'outils modernes (Eclipse à travers un plugin spécifique) permettant une augmentation de la productivité des programmeurs sans les perdre puisqu'ils retrouvent ligne-à-ligne leur programme Cobol initial
  • le "beurre opérationnel": le monde Java est clairement plus vivant et dynamique que le monde Cobol. Par exemple, en basculant à Java, on peut faire progresser son application avec un effort très faible: nous avons observé une amélioration des performances de 30% (et c'est confirmé par Sun) en passant "simplement" (sans rien faire d'autre...) de Java 5 à Java 6. L'immense communauté de programmeurs Java chasse en permanence les bugs de la JVM pour en faire un environnement d'une stabilité redoutable et qui rivalise désormais en performances avec des langages aussi rustiques que C.
  • l'argent du beurre en ménageant la chèvre et le chou: pour éviter à ses clients les décisions trop radicales que nous avons prises et les garder dans son giron, IBM commercialise désormais sur ses mainframes des processeurs spécialisés et dédiés au traitement de Java. Ils sont appelés Zaap pour "Zsystem Application Assist Processor". Sans aucune évolution majeure de la configuration globale du système et au cœurs même du mainframe en place, l'application transcodée peut fonctionner sur ces processeurs dédiés préservant ainsi un environnement établi et stable.


Ces processeurs Zaap ont un double avantage financier mis au point par le marketing IBM: ils sont facturés eux-mêmes à un prix très raisonnable et leur puissance ne vient pas s'additionner aux Mips des processeurs d'un mainframe. Ces Mips sont la base du système de location des logiciels zOS sur le mainframe: ils faut donc les minimiser! Les détails des processeurs Zaap sont donnés ci-dessous.
Il est donc possible d'utiliser nos outils de transcodage NACA 100% automatiques de Cobol vers Java tout en restant dans le "confort" de son mainframe: après le transcodage, l'application fonctionne dans Websphere "posé" dans une JVM propulsée par un Zaap sous le contrôle direct de zOS. Pour le cas du batch, c'est le même principe, mais sans Websphere: seulement la JVM sur le Zaap. Une telle architecture est parfois essentielle pour une société qui veut migrer son application transactionnelle de Cobol/3270 à Java/Navigateur Web sans faire le pas vers une sortie du mainframe.
Elle peut ainsi conserver toute l'intégration très étroite (qui représente parfois des décennies d'investissement!) de son activité transactionnelle avec les autres sous-systèmes de son mainframe (batches, infocentre, etc.) puisque qu'elle reste sur le mainframe mais tourne désormais sur le(s) processeur(s) Zaap(s) plutôt que sur les processeurs classiques du mainframe. Tout reste donc "dans la même boîte" alors que les utilisateurs bénéficient très vite des fonctionnalités de la nouvelle application plus modene.
Au passage, cette architecture peut même faire baisser la facture mainframe puisque les Mips du moniteur transactionnel (CICS) en Cobol sont libérés (voir slides IBM ci-dessous) au bénéfice du transfert de cette activité sur le Zaap en Java.
Le triple résultat:
  • une application transactionnelle modernisée: 100% Java et Web
  • une évolution douce, préparatoire de l'avenir et sans risque: le mainframe reste l'unique vecteur des activités dans un contexte déjà maîtrisé par les équipes opérationnelles
  • des économies par le transfert de puissance utilisé: des processeurs classiques du mainframe pour CICS et Cobol vers les processeurs Zaap pour la JVM avec Websphere (ou Tomcat) et Java.
Ce qui précède est démonstration claire qu'il existe également des chemins graduels pour profiter massivement, économiquement et rapidement des avantages des nouvelles technologies (Java)en continuant à capitaliser sur les connaissances métier accumulées dans une application parfois de plusieurs décennies, à fonctionner dans un environnement parfaitement stable et maîtrisé donc sans demander de bonds quantiques vers l'avant aux équipes en place.
Source des graphiques de cet article : présentations IBM 2009 de Kathy Walsh
Ces processeurs Zaap sont une étape dans l'investissement continu réalisé par IBM pour maintenir sa plate-forme mainframe (hardware zSerie et système zOS) compétitive face entre autre à l'Open Source (Linux) malgré le désavantage financier intrinsèque à cette architecture sophistiquée donc coûteuse.
Pour ce faire, IBM introduit successivement des processeurs dédiés à certains types de tâches dans son architecture mainframe multi-processeurs:
Nous avons, chez Publicitas commencé le projet sur une base de processeur IFL (Integrated Facility for Linux) intégré à notre ultime mainframe pour faire tourner un autre système d'exploitation que zOS: Linux (distribution de Linux pour le mainframe). Des bancs de tests ultérieurs nous ont poussé à franchir le Rubicon et à en sortir définitivement
Depuis, IBM a encore poussé plus loin le concept de processeur dédié: il a en rendu l'intégration plus facile en le faisant tourner sous le contrôle de zOS plutôt qu'en nécéssitant un second système d'exploitation Linux. Le slide ci-dessous démontre la volonté technologique et marketing d'IBM autour de ce processeur (voir l'encart en jaune en bas):

Par une certaine forme "d'alchimie marketing", il s'agit de transférer les Mips Java vers un processeur dédié dont la nouveauté lui permet d'être moins cher et de ne pas affecter les coûts logiciels zOS existants (voir de les réduire, cf. plus haut) sans générer de questions autour d'un schéma tarifaire accepté par la communauté des grandes sociétés utilisatrices. Son avantage majeur est même de permettre une réduction des coûts du mainframe puisque que le Zaap peut permettre d'alléger les Mips "classiques", base de facturation des logiciels zOS.
Source: blog Media & Tech (par didier durand)

mercredi, janvier 27, 2010

[Fun] Google: atteinte flagrante à la sphère privée et discrimination bovine!

Voilà qui justifie clairement le procès helvétique (même si la scène ci-dessous est danoise...) contre Google Streetview! Depuis le temps que l'on cherchait des preuves massives d'atteintes "profondes" (si je puis dire....) à la sphère privée par ce service de Google ....

La catastrophe était annoncée, la voici:


Grand point d'interrogation: pourquoi une telle discrimination de la race bovine alors que la race équine est particulièrement protégée par le géant de Mountain View, mieux que les représentantes du plus vieux métier du monde ?

;-))

[Via Tomhtml]

Source: blog Media & Tech (par didier durand)

lundi, janvier 25, 2010

Google - les petits riens successifs qui cimentent le monopole:67% du marché mondial!

Selon les derniers chiffres Comscore pour décembre 2009, Google dispose d'une part de marché mondiale sur les moteurs de recherche de 67% (87 809 / 131 354).

Nous cherchons collectivement de plus en plus: la demande a progressé de 46% en 12 mois depuis décembre 2008. Google a gagné du terrain: il a fait +58% pendant la même période! Yahoo, le numéro 2 du secteur (presque 10 fois plus petit !) régresse pendant ce temps en ne prenant que 13%....

Si je refais mes calculs, on est passé de 30'000 requêtes à presque 34'000 requêtes par seconde traitées par les 2 millions de serveurs de Google.

L'activité du moteur de recherche est définie depuis toujours par son management comme le coeur de ses sources de revenus. Pour le dernier trimestre, cette activité a certainement rapporté 90% des revenus de ses propres sites (i.e hors AdSense), soit 3.96 milliards de dollars. Ainsi, chaque requête de recherche rapporte donc en moyenne: 3.96 / 3 / 87. 8 = 1.5 cts de dollar.

Impressionnant, non ? J'oublie souvent que je rapporte 1.5 cts à Google chaque fois que je clique sur "Rechercher" et je le fais des dizaines de fois par jour, donc je fais au passage mes quelques clics rémunérateurs pour lui... Je devrais être rémunéré à mon tour, non ?

Pour que nous continuions à lui générer des revenus à travers son coeur de métier, Google nous "soigne aux petits oignons": il a déjà investi 1'000 années-hommes de recherche dans ses algorithmes de recherche et continue à les modifier 450 fois par an pour optimiser les 200 paramètres qu'il prend en compte.

Dernier exemple en date annoncé tout récemment: une utilisation toujours plus pointue de la compréhension sémantique pour affiner les contenus de la Base de Données des Intentions. Concrètement, si vous posez (en anglais pour l'instant) une question du type "Empire State Height", le moteur comprend depuis peu que vous recherchez la hauteur du bâtiment et vous positionnera alors son extrait de résultat sur la réponse à cette question en mettant en gras la hauteur elle-même plutôt que le mot hauteur dans la page qui la contient.

Un petit rien me direz-vous ? Certes, mais c'est en mettant ainsi, inlassablement, des centaines de petites nouveautés bout à bout que Google rend ses résultats de recherche toujours plus pertinents pour tous nous lier à lui sans envie d'aller voir ailleurs....

C'est cette addiction progressive qui cimente la croissance de ses résultats: on peut la qualifier de vertigineuse puisque son dernier trimestre 2009 fait +17% par rapport à 2008 (avec un bénéfice net à presque 30% des revenus ! Une marge quasi-indécente...) au milieu d'une crise économique historique. Bien des entreprises classiques souhaiteraient atteindre de tels +17% déjà en période de prospérité...

Source: blog Media & Tech (par didier durand)

mercredi, janvier 20, 2010

Facebook évalué (à nouveau) à 14 milliards: une bonne chose ?

Facebook n'est pas côté en Bourse officiellement à ce jour. C'est certainement cependant la prochaine société d'importance qui sera cotée: c'est prévu pour 2010 dès que la crise permettra de le faire dans de bonnes conditions.

Les feux se mettent progressivement au vert pour ce faire: l'équilibre financier opérationnel (mais pas encore complet, i.e. hors amortissements investissements lourds en infrastructure) est là. l'empreinte sociale de la société est mondiale et massive.

Il est donc normal de s'intéresser à sa valorisation actuelle. Au moment du deal avec Microsoft, Facebook avait été évaluée (avec un certain biais) à 15 milliards de dollars. Après s'en est suivi le "trou" de la crise toujours en cours. Malgré tout, au vu de son succès chez ses utilisateurs, Facebook remonte la pente et Techcrunch vient de se repencher sur sa valorisation actuelle. Elle est maintenant de 14 milliards de dollars selon les offres d'acheteurs exprimées sur la plate-forme Second Market. On revient donc vers les sommets antérieurs alors que crise reste en cours: une explosion du cours (virtuel) Facebook à prévoir dès la fin de crise ?

Il est aussi à noter que Facebook est maintenant dans les mêmes eaux que Google (23 milliards) lors de son entrée en bourse....

Je souhaite personnellement cette entrée en bourse pour les raisons suivantes:
De cette saine émulation et de l'équilibre des forces naîtra un web meilleur (respect sphère privée, innovation, etc...) que je suis toujours le premier à souhaiter.

Mon grand regret déjà exprimé (ici à propos de ceci): que l'Europe (sans parler de la France) n'ait pas d'acteur majeur à opposer à ces mastodontes tous américains. Par attentisme, nationalisme limitatif, etc., nous avons déjà perdus n batailles dans la conquête du nouveau monde (virtuel), nous finirons par le payer cash! ...

Source: blog Media & Tech (par didier durand)