via Mac4Ever.com on 12/15/11
Doodle.com est un service très utilisé pour proposer un rendez-vous à des amis ou des collègues : vous spécifiez par exemple, plusieurs dates, et chacun peut voter pour celle(s) qui l'arrange. Le service vient de sortir un connecteur gratuit pour iCal, qui permet de synchroniser les événements,...

via LinuxFr.org : les dépêches by Bruno Michel on 12/6/11

Socat est un outil en ligne de commande pour manipuler des sockets réseau, sous licence GPL. La version 1.7.2.0 vient de sortir avec les nouveautés suivantes :

  • prise en charge des interfaces tun/tap sans adresse IP ;
  • ajout des options openssl-compress et max-children ;
  • amélioration pour certaines plateformes, et notamment Mac OS X Lion, DragonFly et Android.

Rappelons que socat sert principalement à relayer deux flux de données de manière bidirectionnelle. Comme ces flux peuvent être de types très variés et acceptent de nombreuses options, il est possible d'utiliser socat pour des usages très divers. Voici quelques exemples :

socat -d -d READLINE,history=$HOME/.http_history TCP4:www.domain.org:www,crnl
# Vous pouvez saisir du texte avec la bibliothèque readline et il sera envoyé en TCP à www.domain.org sur le port 80 (www). Pratique pour simuler des requêtes HTTP à la main.

socat TCP4-LISTEN:www TCP4:www.domain.org:www
# C'est un simple transfert de données entre 2 flux TCP. Tout ce qui arrive sur le port 80 (www) de la machine locale est envoyé vers www.domain.org et inversement.

socat -u TCP4-LISTEN:3334,reuseaddr,fork OPEN:/tmp/in.log,creat,append
# Dans cet exemple, socat va écrire tout ce qu'il reçoit sur le port 3334 dans un fichier.

Lire les commentaires

via 20minutes.fr, l'information en continu by no-reply@20minutes.fr on 12/5/11
INTERVIEW - Tangui Morlier, cofondateur du collectif «Regards Citoyens», donne son point de vue pour «20 Minutes» sur la plateforme d'open data lancée ce lundi par le gouvernement...

via w3sh magazine by chihonghoac on 12/5/11

Voici 11 photos intéressantes des « backstage » de tournages de 9 gros blockbusters hollywoodiens.

Les situations sont à la fois cocasses, parfois drôles et ironiques, souvent anachroniques.

FUN!

1. Planètes des singes

2. Game of Thrones


3. Seigneur des anneaux

4. Marie Antoinette

5. Titanic

6. Mad Men

7. Star Trek

8. Liaisons dangeureuses

9. Harry Potter

via MacGeneration by Arnauld de La Grandière on 8/12/11
skitched

Si Toy Story fut le premier long métrage intégralement réalisé en images de synthèse en 1995, ce fut Tron (premier du nom) qui marqua les esprits pour le nombre de plans intégrant des images calculées par ordinateur en 1982. En réalité les images n'étaient alors rendues qu'en mode fil de fer, les couleurs ayant été ajoutées à la main par les artistes de Disney…


Cinq ans auparavant, une scène de la Guerre des étoiles montrait l'un des premiers plans du cinéma calculé par un ordinateur, réalisé par Larry Cuba à l'aide des moyens de l'université de l'Illinois, qui semblent aujourd'hui indignes du moindre processeur. Chaque image de l'animation fut calculée « à la main », comme le dévoile la fascinante vidéo ci-dessous.



Avec la démocratisation de ces technologies, la télévision s'en empare : le clip de Money for nothing des Dire Straits fut le premier à utiliser l'image de synthèse de manière extensive.



Durant les années 90, les progrès techniques furent mis à profit par Hollywood : Abyss (1989), Terminator 2 (1991), ou encore Jurassic Park (1993) représentèrent chacun une étape marquante de ces progrès. Industrial Light & Magic, le studio d'effets spéciaux de George Lucas, régnait sans partage sur cette industrie, et reste aujourd'hui encore un acteur de premier plan. Le Mac a droit à sa petite part grâce notamment à Electric Image, un logiciel 3D alors prestigieux qui ne fonctionne que sur Mac (et auquel on doit notamment le rêve atomique de Sarah Connor dans Terminator 2). Un des superviseurs des effets visuels chez ILM, John Knoll, est d'ailleurs l'un des pères de Photoshop (lire Photoshop a 20 ans et Photoshop : la mère de toutes les démos).

Mais si les techniques de rendu sont de plus en plus fidèles, à mesure que la puissance des fermes de calcul permet de réaliser ce qui était encore impensable il n'y a pas si longtemps, d'autres techniques sont venues renforcer encore le réalisme : les modèles physiques simulent les interactions entre les solides de manière bien plus réaliste qu'à la main, puis la fourrure (Jumanji, 1995), les particules (Twister, 1996), les tissus ou les fluides (En pleine tempête, 2000), l'intelligence artificielle permet l'animation des foules innombrables (Le seigneur des anneaux, 2001).

L'œil humain est particulièrement difficile à tromper : qu'un seul détail infime manque à l'appel et l'image semblera grossièrement truquée. Si Jurassic Park a été le premier film à présenter des créatures vivantes réalistes (quoique présentant l'avantage de ne souffrir d'aucune comparaison avec la réalité), il aura fallu simuler la manière dont les muscles roulent sous la peau, et dont celle-ci bouge de manière dynamique (inertie et gravité comprises) pour gagner en crédibilité sur l'animation image-par-image de Phil Tippett.




Le Saint Graal restait encore l'acteur virtuel : un être humain entièrement calculé par ordinateur. Mais c'était sans compter sur la « vallée dérangeante » : un phénomène de dégoût que l'on ressent lorsqu'un personnage est ultra-réaliste, mais pas encore assez pour nous pleinement nous convaincre. Final Fantasy, les créatures de l'esprit en 2001 en fait l'éloquente démonstration.



Si les images fixes peuvent faire illusion, c'est lorsque le corps s'anime que les choses deviennent délicates. La peau est translucide, les micro-mouvements du moindre muscle rendent l'animation à la main condamnée à la rigidité cadavérique. La technique du « motion capture » a certes amélioré les choses, mais reste trop limitée pour parfaitement retranscrire le jeu d'un acteur dans sa totalité. Ça n'est qu'avec Gollum dans Le seigneur des anneaux qu'un acteur, Andy Serkis, animera de ses propres expressions le visage et le corps d'une créature virtuelle de manière crédible.

Différentes techniques pour capturer le plus infime détail du jeu d'un acteur voient le jour, comme Light Stage (utilisé dans L'étrange histoire de Benjamin Button, the Social Network ou Avatar). Il s'agit d'un dôme recouvert de projecteurs et de capteurs photographiques, qui illuminent les acteurs sous tous les angles, et prennent leur image à la perpendiculaire de l'éclairage plusieurs dizaines de fois par seconde, ce qui permet de manipuler l'éclairage et l'angle de vue en post-production en totale liberté, pour intégrer un acteur dans n'importe quelle scène.



Mais avec ces prises de vue « virtuelles », qui enregistrent les mouvements des acteurs, la caméra elle-même devient virtuelle et peut être positionnée selon les moindres désirs du réalisateur. Mieux encore, une simple tablette devient une fenêtre sur l'apparence que les acteurs auront au final, en temps réel. Les machines sont devenues assez puissantes pour faire un rendu réaliste en temps réel, qui sert tant en pré-production en guise de story board des temps modernes que sur le plateau de tournage pour avoir un aperçu des images finales. En effet, une fois arrivé au rendu réaliste, c'est la rapidité de ce rendu qui offre plus de souplesse aux réalisateurs, mais surtout qui profile des retombées beaucoup plus larges.

Et s'il faut encore des machines surpuissantes et hors de prix pour satisfaire les besoins d'Hollywood, ces technologies sont en passe d'arriver dans l'ordinateur moyen, à plus forte raison avec le renfort du cloud computing (lire : OnLive viole la loi de Shannon).

Au-delà des techniques de capture, le rendu des propriétés physiques de la lumière permet un réalisme confondant, puisqu'il reproduit dans ses moindres propriétés la manière dont notre environnement est visible. Cette technique, appelée le Path Tracing, a grandement bénéficié du calcul parallèle et de la puissance des processeurs graphiques, à tel point qu'on envisage qu'il soit accessible en temps réel sur l'ordinateur du commun des mortels d'ici quelques années (lire : OpenCL dynamite le Path Tracing et : Fractal Lab : WebGL en mode onirique).



Si pour l'heure ce type de rendu présente encore du « bruit » (les rayons lumineux sont « lancés » aléatoirement), nombre de travaux sont actuellement en cours pour optimiser le calcul au maximum afin d'obtenir une qualité supérieure plus rapidement encore. Les jeux qui utiliseront ce procédé se profilent d'ici à quelques années.

Mais le rendu en lui-même n'est pas la seule limite du temps-réel : le nombre de polygones affichables en simultané à l'écran a certes augmenté de manière considérable, mais reste encore trop limité pour prétendre au réalisme : les objets restent anguleux, ou surgissent de nulle part à mesure qu'ils deviennent affichables. Une société fait beaucoup parler d'elle depuis un an à ce sujet : Euclideon promet un moteur de rendu en voxels en temps réel.

Le voxel est à la 3D ce que le pixel est à la 2D : une unité de matière qui se détache de la modélisation en polygones. C'est notamment cette technique qui est utilisée en imagerie médicale pour l'affichage d'organes tridimensionnels, mais c'est une technique particulièrement gourmande en calcul, notamment parce qu'elle ne permet pas le tri en profondeur : chaque particule de matière doit être calculée, qu'elle soit visible ou non par la caméra. Euclideon promet une solution particulièrement véloce, grâce à un système de tri des voxels qui évite de calculer ceux qui ne seront pas visibles : ainsi il ne peut y avoir plus de voxels à l'écran que le nombre de pixels de sa définition. La méthode permet donc une finesse encore inégalée pour les modèles 3D, et le tout en nombre conséquent, sans impact sur la vitesse de calcul (jusqu'à intégrer des grains de sable tridimensionnels). De quoi donner le tournis et envisager, en y ajoutant un rendu en Path Tracing, une réalité virtuelle à la hauteur de la Matrice. À tel point que nombre d'observateurs se sont montrés dubitatifs face aux affirmations d'Euclideon, qui promet de revenir prochainement avec une démonstration téléchargeable.



On mesure les incroyables progrès qui ont été réalisés depuis que les premières images calculées par ordinateur se sont immiscées dans le cinéma, il y a une trentaine d'années, d'autant plus que ces animations ont longtemps été réputées pour nécessiter des heures de calcul pour chaque image. D'ici cinq à dix ans, chaque ordinateur sera en mesure d'en faire autant en temps réel, avec un niveau de détail encore impensable il y a peu. Ce niveau de réalisme ne sera qu'un moyen et non plus une fin en soi : reste à voir ce que nous en ferons.

Voir les commentaires et réagir

© 2011 - "L'image de synthèse, d'hier à demain" publié sur MacGeneration par Arnauld de La Grandière.



via w3sh magazine by chihonghoac on 8/10/11

Les designers et webmasters apprécieront le poster.

En plus de regrouper l’ensemble des données liés à la typo sur internet, elle regroupe en plus des fondamentaux qui vous permettront de progresser dans votre approche du web.

Ma maxime préférée : N’essayez pas d’être original, essayez juste d’être bon!

ENJOY!

(cliquez sur la photo pour agrandir)

typographic

via Engine Yard Blog by Hiro Asari on 8/9/11

Last month I visited a joint meeting for the Richmond Java User Group and Central Virginia Ruby Enthusiasts’ Group. The audience was evenly split between Java and Ruby developers, which made for an ideal setting for my presentation about Java-Ruby interoperability that JRuby facilitates. On the tails of another great JRubyConf last week, I was inspired to share a summary of my presentation and my slides with interested folks who weren't able to attend the talk.

Using a Java library from Ruby

In this article, I’ll focus on using a Java library from Ruby. You see, if you were to tinker with a single Java method, you would need to write a complete program with “public static void main(String[] args)”. As we will demonstrate here, with JRuby IRB, it becomes almost trivial to play with Java methods.

We will use the unique Java library Akka here. According to the Akka website, “using the Actor Model together with Software Transactional Memory [Akka raises] the abstraction level and provides a better platform to build correct concurrent and scalable applications.”

The Akka Getting Started Tutorial

To begin, let us look at the Akka Getting Started Tutorial written in Java, and translate it into Ruby.

The example computes π using the Madhava-Leibniz series.

Note that in the series, the neighboring terms can be gathered into a smaller work unit without disturbing the identity, or other work units. We created a worker and a few additional workers that communicate by passing a message--Plain Old Java/Ruby Object with a little extra information--along with the message router acting as a broker.

For comparison, here is the Ruby version, and the Java version. The Ruby version is shorter, and requires less ceremony in setting up various classes involved in the program.

Exploring the code

Now let us walk through the key points in the Ruby version.

Preliminary stuff

require "java"

Line 1: Enable Java integration support in JRuby.

$: << File.join(File.dirname(__FILE__), 'lib')

Line 3: Add the lib directory (that resides in the same directory as the current file) to JRuby’s library search paths.

java_import 'akka.actor.Actors'
java_import 'akka.actor.ActorRef'
java_import 'akka.actor.UntypedActor'
java_import 'akka.actor.UntypedActorFactory'
java_import 'akka.routing.CyclicIterator'
java_import 'akka.routing.InfiniteIterator'
java_import 'akka.routing.Routing'
java_import 'akka.routing.UntypedLoadBalancer'
java_import java.util.concurrent.CountDownLatch

Lines 8 through 16: Import the Java library’s classes into the current namespace so we don’t have to prefix them with Java::…. This is similar to Java’s import statements.

def actorOf(&code)
  Actors.actorOf(Class.new do
                   include UntypedActorFactory
                   define_method(:create) do |*args|
                     code[*args]
                   end
                 end.new)
end

Lines 18 through 25: This is a convenient method to create an Akka actor instance through the use of Ruby’s Class.new, which is analogous to anonymous class declaration in Java. This greatly reduces the clutter when used on lines 81 and 125.

class Calculate; end
class Work < Struct.new(:start, :nrOfElements); end
class Result < Struct.new(:value); end

Lines 27 through 29: Define Plain Old Ruby Objects acting as messages between Akka actors. Note there is a lot less noise for these classes than there is for the Java counterparts.

Worker class

class Worker < UntypedActor
  # needed by actorOf
  def self.create(*args)
    new *args
  end

  # define the work
  def calculatePiFor(start, nrOfElements)
    ((start * nrOfElements)...((start + 1) * nrOfElements)).inject(0) do |acc, i|
      acc + 4.0 * (1 - (i.modulo 2) * 2) / (2 * i + 1)
    end
  end

  # message handler
  def onReceive(message)
    if message.kind_of? Work
      work = message

      # perform the work
      result = calculatePiFor(work.start, work.nrOfElements)

      # reply with the result
      context.replyUnsafe(Result.new(result))

    else
      raise IllegalArgumentException.new "Unknown message [#{message + b}]"
    end
  end
end

Lines 31 through 59 define the Worker class. The part that actually performs the calculation calculatePiFor is much more compact with the use of Enumerable#inject. When this actor is sent a message, it executes the methodonReceive.

Following the Java example, we are examining the class of the message passed; this is admittedly not characteristic of Ruby.

PiRouter class

class PiRouter < UntypedLoadBalancer
  attr_reader :seq

  def initialize(workers)
    super()
    @seq = CyclicIterator.new(workers)
  end
end

Lines 61 through 68 define the PiRouter class. Besides having an instance variable :seq, there isn’t much code, much of it is done in the Akka library itself.

Master class

class Master < UntypedActor
  def initialize(nrOfWorkers, nrOfMessages, nrOfElements, latch)
    super()
    @nrOfMessages, @nrOfElements, @latch = nrOfMessages, nrOfElements, latch
    @nrOfResults, @pi = 0, 0.0

    # create the workers
    workers = java.util.ArrayList.new
    nrOfWorkers.times { workers << Actors.actorOf(Worker).start }

    # wrap them with a load-balancing router
    @router = actorOf { PiRouter.new(workers) }.start
  end

  # message handler
  def onReceive(message)
    if message.kind_of? Calculate
      # schedule work
      @nrOfMessages.times do |start|
        @router.sendOneWay(Work.new(start, @nrOfElements), context)
      end

      # send a PoisonPill to all workers telling them to shut down themselves
      @router.sendOneWay(Routing::Broadcast.new(Actors.poisonPill))

      # send a PoisonPill to the router, telling him to shut himself down
      @router.sendOneWay Actors.poisonPill
    elsif message.kind_of? Result # handle result from the worker
      @pi += message.value
      @nrOfResults += 1
      context.stop if @nrOfResults == @nrOfMessages
    else
      raise IllegalArgumentException.new "Unknown message [#{message}]"
    end
  end

  def preStart
    @start = java.lang.System.currentTimeMillis
  end

  def postStop
    # tell the world that the calculation is complete
    puts format("\n\tPi estimate: \t\t%s\n\tCalculation time: \t%s millis",
        @pi, (java.lang.System.currentTimeMillis - @start))
    @latch.countDown
  end
end

Lines 70 through 116 define the Master class. Master responds to two kinds of messages. Calculate sets everything in motion. Result messages are sent from the PiRouter to the Master, which adds up the values of the Result messages until the set number of them were sent its way.

Pi class

class Pi
  def self.calculate(nrOfWorkers, nrOfElements, nrOfMessages)
    # this latch is only plumbing to know when the calculation is completed
    latch = CountDownLatch.new(1)

    # create the master
    master = Actors.actorOf do
      Master.new(nrOfWorkers, nrOfMessages, nrOfElements, latch)
    end.start
    master.sendOneWay(Calculate.new) # start the calculation
    latch.await # wait for master to shut down
  end
end

Pi.calculate(4, 1000, 1000)

Lines 119 through 133 include the top-level class with one class method that sets up the concurrency latch and sends the Calculate message to the Master.

Conclusion

This example shows the basics of Java-Ruby interaction in a complete program. These fundamentals are applicable to your first explorations. If you come up with your own harmony of Java and Ruby, be sure to share it with us in the comments section.

Thank you, Richmond! (And beyond?)

I enjoyed sharing JRuby with the user group members I met in Virginia. Thanks again to the Richmond Java User Group and Central Virginia Ruby Enthusiasts’ Group for hosting me. We are always excited to share JRuby with a larger audience and to hear your thoughts. If you are interested in arranging a JRuby presentation, drop us a line, and we’ll chat!

via LinuxFr.org : les dépêches by Xavier Teyssier on 8/7/11

Depuis quelques mois, le monde libre de la supervision sort de sa léthargie : des projets revivent, de nouveaux projets apparaissent... Dans les dépêches récentes de LinuxFr.org, on a vu le célébrissime Nagios sortir une nouvelle version mineure, histoire d’essayer de montrer que non, ce projet n’est pas encore mort. De même, nous avons régulièrement droit sur LinuxFr.org à des dépêches sur Shinken, le tout nouveau projet de supervision, qui couvre déjà la quasi totalité des fonctionnalités de Nagios, et qui continue à évoluer.

Mais l’actualité du monde de la supervision est bien plus vaste que cela. Voici quelques pointeurs vers certains des évènements de ces derniers mois qui n'ont pas encore été mentionnés sur LinuxFr.org.

Sommaire

Shinken

Pas encore de nouvelle version publiée depuis l’annonce de la version 0.6 sur LinuxFr.org, en revanche, entre-temps s’est déroulé le salon Solutions Linux, pendant lequel Jean Gabes, auteur de Shinken, a fait une présentation de son bébé. Le PDF contenant les transparents est accessible ici : Présentation de Shinken à Solution Linux 2011 (PDF, 1,3Mo). Si nous n’avez pas encore effectué la migration Nagios → Shinken, ces transparents pourraient bien vous convaincre de franchir le pas !

Centreon

Centreon, développé principalement par la société Merethis, est un outil dédié à la supervision s’appuyant sur Nagios et quelques outils supplémentaires, avec une surcouche graphique pour intégrer le tout. Pour une description plus précise, on peut se référer à la dépêche précédente sur LinuxFr.org, à propos de la sortie de la version 2.1. Depuis, Centreon a bien évolué, et une version 2.2 a été publiée en mai dernier. Parmi les nouveautés, on notera que dorénavant, plusieurs moteurs de supervision sont disponibles : en plus de Nagios, Icinga et Shinken sont maintenant utilisables avec Centreon. On notera aussi une gestion plus souple des ACL, une navigation plus aisée dans les graphiques dédiés à la métrologie, avec des possibilités de Zoom ou d’export, etc. Depuis, nous avons d’ailleurs eu droit à une version 2.2.1 et 2.2.2.
À propos de Centreon, Intelli’n TV a profité du salon Solution Linux pour réaliser un entretien avec Romain LE MERLUS (société Merethis), qui nous présente Centreon : http://www.youtube.com/watch?v=4lw6r_0oBRI

Centreon Engine

Encore un fork ! À l’occasion de la sortie de Centreon 2.2.0, la société Merethis en a profité pour annoncer son propre fork de Nagios Core. Centreon Engine est né, basé sur Nagios Core 3.2.x. Ce fork a été provoqué par la quasi inactivité du développement de Nagios Core. L’objectif officiel est d’améliorer les performances et de remotiver la communauté pour relancer la machine à innovation. Les premières versions ont permis de se lancer dans du nettoyage de code, de diminuer les dépendances entre fichiers, d’ajouter des test unitaires (un suivi de la couverture de test est d’ailleurs disponible à l’adresse : http://cdash.centreon.com/), etc. L’avenir nous dira si ce fork est pérenne, et si la cohabitation avec Nagios Core se déroulera bien : Ethan Galstad, “dictateur bienveillant” de Nagios, a annoncé lors d’un entretien trouver le projet intéressant, et il attend de voir si les auteurs de Centreon Engine remonteront leurs patchs à Nagios Core... D’ici là, vous pouvez aller en apprendre un peu plus par là : http://www.centreon.com/Centreon/centreon-engine-overview.html

Ganglia

Ganglia est un outil de surveillance basé sur RRDTools pour des systèmes de type cluster ou grille d’ordinateurs. Pour voir à quoi cela peut ressembler, on peut se reporter du côté de Wikimedia, qui utilise Ganglia pour surveiller son parc de serveurs (http://ganglia.wikimedia.org/). On peut différencier deux projets : Ganglia, le moteur de supervision lui-même, et Ganglia Web, une surcouche graphique améliorée en PHP. Au cours des dernières semaines, nous avons eu droit à la publication de la version 3.2.0 de Ganglia, mais aussi, et surtout, à la publication de la version 2.0.0 de Ganglia Web, alors que ce projet était en sommeil depuis des années. On notera comme évolutions notables la possibilité de zoomer dans les graphiques, une version optimisée pour les mobiles, et quelques autres évolutions montrant que le projet s'est bien relancé.

Zabbix

Zabbix est une autre solution tout-en-un de supervision. Contrairement à la politique suivie aujourd'hui par des produits comme Nagios, il n’y a pas une version libre limitée et une version complète propriétaire. Ici, une seule version complète, en GPLv2, gratuitement accessible. Le principe du tout-en-un est assumé, et même une ligne directrice : pas besoin de récupérer un moteur de supervision d’un côté, une interface web de l’autre, etc. Tout est inclu directement dans le produit. Ici, les données (configuration, historique, etc.) sont toutes conservées dans une base de données. La dernière version de zabbix (1.8.6) vient tout juste de sortir. Elle apporte son lot de corrections de bogues, la compatibilité avec la dernière branche de PostgreSQL (9.x), une plus grande rigueur dans l’analyse des fichiers de configuration, etc.
Puisque l’on parle de Zabbix, mentionnons également une conférence dédiée qui se déroulera fin Septembre à Riga, en Lettonie. Plus d’informations ici : http://www.zabbix.com/conference2011.php

FAN

FAN, Fully Automated Nagios, est une distribution Linux dédiée à Nagios. Elle se présente sous la forme d’une image d’installation, qui installera une CentOS avec un Nagios et tous les outils gravitant autour (Nagios plug-ins, Centreon, Nagvis, NDOUtils, NRPE, etc.). La version 2.2, apportant des versions à jour de chacun des outils inclus, ainsi qu’un support du 64 bits, vient de sortir en RC1. N’hésitez pas à tester et à rapporter les problèmes rencontrés pour stabiliser au mieux cette nouvelle version.

via MacGeneration by Christophe Laporte on 8/2/11
Comment distinguer son offre de la concurrence ? Le casse-tête est d'autant plus ardu quand il s'agit d'un disque dur externe. Iomega tente d'apporter sa réponse avec le Mac Companion Hard Drive.



Ce dernier s'entend assez bien avec le Mac, puisqu'il comporte à la fois de deux portes FireWire 800, deux ports USB 2.0 et un câble FireWire 400/800. En outre, il intègre un port USB permettant de synchroniser son terminal iOS (à condition bien entendu que le produit de Iomega soit relié à votre ordinateur). Mieux encore, le port en question est suffisamment puissant pour recharger un iPad.



Le Companion Hard Drive embarque un disque dur à 7200 tr/min avec 8 Mo de cache et formaté par défaut en HFS+. Compatible Time Machine, il est livré avec le pack Iomega Protection Suite édition qui comprend entre autres Trend Smart Surfing.

Deux modèles sont disponibles à la vente : 2 To (219 €) et 3 To (329 €).

Voir les commentaires et réagir

© 2011 - "Iomega : un compagnon pour le Mac et pour l'iPad" publié sur MacGeneration par Christophe Laporte.