Ubuntu et contrôle parental des horaires d'accès et d'utilisation: solution

J'avais posé la question: "quels outils utiliser pour contrôler les horaires d'accès (et d'utilisation) à la machine Ubuntu familiale?" afin d'éviter les indigestions incontrôlées de Facebook par Durand Junior.

Je remercie tous ceux qui ont pris le temps de faire des recherches et/ou de répondre sur le sujet:; en particulier, ceux qui se sont nommés: Laurent Simon, Seb, Tonio, Mathieu, etc...

Mon choix s'est finalement porté sur la solution proposée par Seb: elle consiste en l'utilisation combinée de 2 utilitaires Linux PAM (via pam_time) et timeoutd. Elle est parfaitement détaillée par Jean-Michel Philippe sur son blog.


Mon problème est donc réglé! C'est vraiment bien l'entraide communautaire sur le web....

Source: blog Media & Tech (par didier durand)

Google rend la recherche locale plus efficace (indirectement)

Hors de la geekerie ésotérique, i.e dans la vraie vie et quand vous cherchez sur Google un plombier proche (par exemple), vous faites comment ? Vous allez sur le moteur et vous mettez "plombier+nom_de_votre_ville" comme mots-clefs.

Le souci: nous ne tombez pas sur les plombiers de la ville d'à côté puisqu'ils n'ont certainement pas le nom de votre ville dans leur page web. Le problème est identique à celui du plombier pour toute autre information pour laquelle on veut que Google décide de la pertinence des résultats qu'il retourne par rapport à la géographie (un critère parmi plus de 200) sans la citer explicitement.

Le souci n'existe plus: Google vient d'annoncer la possibilité de saisir le lieu comme "paramètre indirect" pour le classement de ses résultats

Comment profiter de cette nouvelle fonction:

• vous lancez votre recherche avec les mots-clefs mais sans la ville
• sur la page de résultats, dans la barre bleue supérieure, vous sélectionnez "affichez les options" et vous verrez parmi ces options (ou au milieu de vos premiers résultat) un lien indiquant "Modifier le lieu". Il n'y à plus qu'à faire cette modification et refaire la recherche.

Pourquoi Google fait-il cela maintenant ?

• Parce que le contenu sur le web le permet: avec 1'000 milliards de pages sur Internet, on est à eu près sûr de trouver une page de l'Internet sur tout sujet
• Parce qu'il veut devenir meilleur dans sa pertinence pour nous fidéliser davantage: comme je l'ai déjà écrit, cette nouvelle fonction est l'un de ces petits riens successifs qui cimentent un peu plus le monopole (67% de parts de marché)
  
• Parce qu'il améliore l'exhaustivité de la Base de Données des Intentions en lui ajoutant la dimension géographique (le OU?). Il s'ouvre ainsi grand les portes de publicité locale pour siphonner (on parle de plombier....) au maximum la double Longue Traîne des annonceurs locaux et des sites de proximité (parmi son million d'affiliés) en leur apportant ainsi des opportunités économiques supplémentaires.

Du WIN(Google)-win(internaute)-win(annonceur local)-win(site de proximité) en quelque sorte.

Source: blog Media & Tech (par didier durand)

Google Buzz: le "Social Network Service" interopérable émerge!

[Je n'ai pas parlé de buzz lors de sa naissance: le web était "blindé" sur le sujet. Maintenant que l'agitation retombe, je peux y revenir. Mon article préféré sur le thème d'un point de vue utilisateur est celui de F. Cavazza: il donne la meilleure synthèse bien étayée du sujet]

Tim-Berners avait évoqué il y a plus de 2 ans la nécessité de l'émergence d'un GGG (Giant Global Graph) pour casser les silos informationnels actuels des Facebook, Twitter, LinkedIn et autres Xing qui nous imposent:

• soit un temps passé infernal à recopier son profil et les activités de son lifestream personnel de l'un à l'autre
• soit la mise en place de services en ligne multiples (et sans garantie de pérennité...) souvent "obscurs", en tout cas réservé aux geeks pour faire des passerelles plus ou moins solides entre tout ce petit monde
  

Un tel système n'est pas tenable à terme: les internautes vont se lasser de gaspiller une telle énergie pour tenter d'échanger leurs états d'âmes ou photos avec leur proches et connaissances.

En annonçant Buzz, Google a fait des choses en profondeur qui n'ont pas encore été discutées: il a jeté les bases du "Social Network Service" interopérable précédemment évoqué.

Bien sûr, en surface, il y a aussi l'envie de lutter contre Twitter et Facebook qui sont les 2 fers de lance (actuels) du micro-blogging social. [Et bien sûr, vu le domaine, il y a eu les soucis de jeunesse sur le sujet de la sphère privée]

Mais, ainsi qu'il le fait actuellement avec succès pour le monde du mobile, Google préfère l'hégémonie lente au ko rapide. En effet, l'hégémonie lente lui amène au mieux ce qu'il recherche en premier lieu: une utilisation plus grande de l'internet qui fait prospérer son coeur de métier (la publicité = 98% de ses revenus). C'est le même but qu'il réalise parfois par une autre moyen: la destruction créatrice (cf Feedburner, etc.)

Pour maximiser cette utilisation du web, Google a donc mis en action une multitude de protocoles ouverts ui sont destinés à restituer sous une forme programmatique toutes les informations disponibles sur ce contenu Buzz: QUI a crée QUOI depuis OU, etc... Il souhaite ensuite qu'une armée de développeurs tiers (comme chez Amazon...) bâtissent des services innovants générant donc une utilisation maximum.

Les protocoles standards mis en action sont les suivants:

[je vous laisse chercher les points d'entrée vers la foultitude de protocoles ci-dessous. Si vous ne les trouvez pas, contactez-moi]

• les flux des utilisateurs de Buzz sont intégralement publiés en temps réel sous forme de flux Atom. A chaque Buzz est par ailleurs associé un autre flux Atom: celui des commentaires sur ce buzz. Des mécanismes de découvertes sont inclus pour permettre de retrouver ces flux alors même qu'ils peuvent être en provenance de multiples machines totalement distribuées sur l'Internet. Pas de création de monopole possible...
• les mises à jours sont pilotées par le protocole Pubsubhubhub afin d'éviter que dans une telle (future) architecture distribuée tout le monde crawle tout le monde ne permanence...
  
• la sémantique de ces flux est très élevée: ils sont enrichis d'éléments descriptifs du protocole ActivityStrea.ms pour définir au mieux les actions de l'utilisateur. Les éléments multimédia sont décrits sémantiquement par le protocole MediaRss
  
• les données de profil de l'utilisateur sont décrites par le protocole WebFinger associé à PortableContacts, SocialGraph API, aux microformats, etc...
• le flux des commentaires autour d'un article publié et re-publié vont se trouver davantage dispersés. Le protocole Salmon est là pour les faire percoler à 100% (quel que soit leur lieu d'émission) vers la source et tous les points de publication intéressé.
  
• la partie privée de Buzz est protégée par OAuth qui permet une délégation d'accès aux informations sans risque
• etc...

Dès que j'ai un moment, je vous fait un graphique combiné montrant la conjonction de tous ces protocoles. J'y reviens rapidement, c'est promis!

Cette conjonction de protocoles est très intéressante: elle permet (au moins en théorie... et au prix d'une bonne infrastructure et de pas mal de développements) de pouvoir reconstituer, pour son propre service, un miroir intégral des données publiés dans Buzz et de tous les clones ou concurrents qui se mettront à respecter ces mêmes standards.

Une vraie démarche ouverte dès la genèse du service en quelque sorte! Et ce alors que cette ouverture est encore souvent conçue comme un moyen ultérieur de catalyser le développement d'un service quand ses moyens propres et propriétaires ne lui permettent plus de croître de manière endogène.

Une autre conséquence intéressante de cette démarche: ses concurrents (Twitter, Facebook, etc.) vont certainement devoir aussi réviser - quand Google Buzz aura un peu grandi: si l'on part du principe que 9 millions de buzzes d'utilisateurs Buzz en 2 jours, c'est petit.... - leurs positions très propriétaires actuelles en termes de formats et de protocoles et les contraindre à s'ouvrir.

Un bien pour nous autres internautes certes mais pas forcémment un bien pour ces services car leur modèle d'affaires (actuel) est basé sur un étroit contrôle du contenu généré par leurs utilisateurs alors que ce sont finalement ces utilisateurs qui en ont les propriétaires.

Conclusion: bien joué, Mr Google! Sa taille de l'ordre de grandeur de l'Internet lui-même et sa profitabilité lui permettent d'avoir une stratégie de croissance propre parfaitement alignée avec la plus grande masse d'acteurs de l'Internet et d'avoir aussi la patience de la mettre en oeuvre. En l'appliquant, de plus, il plante en plus systématiquement ses banderilles sur ces adversaires en les forçant à bouger dans des directions désagréables pour eux.

PS: en tant qu'utilisateur, je vois 3 avantages initiaux majeurs à Google Buzz par rapport à ses concurrents:

• pas de limite de taille: on peut se tenir aux 140 caractères de Twitter mais on peut aussi faire plus bavard si on voit qu'il y a un créneau sur Buzz pour la volubilité
• flux multimédia: Twitter impose un clic vers un service idoine pour aller voir une photo qu'un utilisateur voulait associer à son tweet. Dans Google Buzz, le multimédia (photos, vidéos, etc... ) intégré dans le texte.
• commentaires attachés: le service Twitter basique (sans l'utilisation de client sophistiqués) impose une gymnastique fastidieuse de rebond entre les différents flux des intervenants d'une conversation. Dans Google Buzz, si je lis un billet initial, je vois juste en dessous les commentaires associés.
  

Source: blog Media & Tech (par didier durand)

Youtube: comparez vos performances vidéo

On ne développe pas une "machine" de la taille de Youtube (1+ milliard de vidéos vues chaque jour par des centaines de millions d'utilisateurs - 4ème site consulté en France) sans l'instrumenter abondamment pour ne pas en perdre le contrôle.

Ces tableaux de bord hyper-détaillés sont une partie de l'excellence opérationnelle que E. Schmidt, le ceo de Google considère comme l'avantage stratégique premier de Google.

Eh bien, aujourd'hui, Youtube lève une partie du voile sur ses tableaux de bord afin de nous permettre de comparer nos performances à ceux de nos proches.

A l'adresse http://www.youtube.com/my_speed (quand je suis connecté à mon compte), Youtube publie un graphe de moyenne et un graphe historique comparatifs des performances de téléchargement sur ma ligne et des agrégations hierarchiques de niveau supérieur (ma ville, mon ISP, mon pays, etc.)
Ce que j'en tire comme premières conclusions d'usage direct:

• que ma connexion rurale n'est trop mal par rapport aux autres connexions urbaine de la grande ville la plus proche (Besançon) : 1.61 Mbps <> 1.73 Mbps
• qu'en Franche-Comté, nous sommes ADSL-ment parlant presque 2 fois plus lent que la moyenne nationale: 1.71 <> 2.91 [C'est sûrement aussi pour cela que l'on parle avec un fort accent lent et traînant dans le secteur... ;-) ]
  
• que la France tient son rang de pays bien connecté au niveau mondial: 2.91 <> 2.93
• que, d'après le graphe historique, sur 1 mois, tout cela est fort stable

Ce que j'en tire comme conclusion indirecte: avec sa Base de Données des Intentions, Google a une forte connaissance du QUOI de mes activités Internet mais je réalise aujourd'hui qu'il aussi une connaissance très précise du COMMENT de ses activités.

Ce que cela lui apporte par rapport à son coeur de métier (la publicité, part très majoritaire des revenus: 98%) ? Un choix plus pertinent des formes publicitaires (de leurs caractéristiques techniques: multimédia, etc.) à me présenter pour que j'en consomme (i.e clique - c'est ce qui rapporte) un maximum.

Source: blog Media & Tech (par didier durand)

Robotshop: pour développer vos propres robots comme ces exemples !

Je ne suis pas un immense adepte de bricolage mécanique: ma femme vous le témoignerait volontiers! ;-)

Je suis plus un fan du hacking abstrait. Il n'en est pas moins que je suis de près le monde de la robotique en tant que prolongement palpable de toute la mécanique abstraite du logiciel.

Je suis fasciné par ses avancées et ce qui mefascine encore davantage, c'est que la fabrication de robots sophistiqués est maintenant à la portée de tous. Dernier exemple en date: mon camarade blogosphérique Vincent a rejoint la société RobotShop qui permet à Monsieur Tout le Monde de se lancer en y achetant ses premiers kits de construction puis toutes les pièces et services de réparation et conseils pour des robots de plus en plus sophistiqués. Des robots professionnels (voir exemple ci-dessous) y sont également en vente.

Ce que cela permet de faire ? Des exemples:

Un robot pour résoudre le RubikCube (L'intelligence est fournie par un téléphone Nokia).



Des robots combattants



Plus utile, un robot (professionnel) pour nettoyer les vitres



Allez, lancez-vous aussi! J'attends vos propres réalisations en commentaire de ce billet.


Source: blog Media & Tech (par didier durand)

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)

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:

• Le monopole de Google (67% du marché mondial de la recherche) existe aussi dans l'Hexagone. C'est ainsi que Google se retrouve sur la 1ère marche du podium.
  
• Facebook qui talonne Google déjà sur le secteur de l'information par le bouche à oreille est maintenant le 2ème site français. Si je regarde l'activité de ma femme et mon fils sur ce site qui contribuent activement aux 400 milliards de pages vues chaque mois, je comprends pourquoi le service de Mark Zuckerberg est déjà challenger pour la place suprême
• la vidéo sur Internet est écrasée par Youtube aussi en France: elle devient sans équivoque la TV 2.0 pour la génération Y (qui porte tellement bien son nom...) qui se construit son programme de la soirée à travers les suggestions reçues en live par les autres "potes" sur Facebook.
  

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)

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)

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)

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)

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)