Depuis son rachat par Disney, la licence Star Wars est traitée au même titre que la licence Avengers : pour faire patienter les gens entre les "vrais" films qui arrivent tous les 3 ans, on meuble avec des spin off dont la qualité varie.
Comme je le disais dans cet article, je considère l'Episode 7 comme une purge intergalactique, une repompe sans saveur de l'épisode 4 à la sauce teenage movie qui en plus de se payer le luxe de ne pas respecter le lore nous offre des moments lourds voire gênants. Alors que dire de Rogue One ? Gareth Edwards a-t-il réussi à obtenir quelque chose d'original malgré l'aspect sandboxé de l'histoire ? En ce qui me concerne, j'ai beaucoup aimé.
S'il est vrai que l'histoire est un peu faible et longue à démarrer, j'ai en revanche beaucoup aimé l'habillage, autant sur l'aspect réalisation que narration. Côté réalisation il y a un gros travail sur la notion de gigantisme mais aussi sur l'ambiance des planètes, plutôt sombres et froides ce qui est fait pour appuyer un autre aspect que je trouve couillu pour un Star Wars : le côté sale de la guerre. Sans vouloir spoiler, on nous offre une vision légèrement moins binaire des méchants et des gentils, notamment l'alliance rebelle, ce qui tranche avec l’Épisode 7 qui ne prenait aucun risque de ce côté. Quand on agrémente le tout par une multitude de clins d’œil respectueux envers l’Épisode 4, ne serait-ce que le look vintage de la technologie (écrans monochromes) et des personnages (moustaches des années 70) on comprend que Gareth Edwards a traité la licence Star Wars avec amour.
Je regrette tout de même l'absence de développement des personnages, voire les difficultés à comprendre les motivations de certains, ce qui m'amène à me demander s'il n'y a pas eu de scènes coupées. Peut-être est-ce simplement du à l'aspect sandboxé de l'histoire, c'est un film pensé pour se suffire à lui-même, qui doit démarrer et se terminer en 2h, il ne peut donc non seulement pas s'attarder mais ne doit pas non plus marcher sur les pieds des "vrais" films.
En résumé, même si Rogue One: A Star Wars Story souffre des limitations de son scenario et de ses personnages, il n'en reste pas moins un très bon Star Wars, respectueux et bienveillant envers la saga. Pour cette raison j'appose mon "Seal of approval" et vous encourage vivement à aller le voir.
PS : Et puis il y a Ip Man bordel !!! Vous devez voir ce film.
Ouvrez les paramètres de votre machine virtuelle, rendez-vous dans "Stockage, et cochez la case "Utiliser le cache E/S de l'hôte". Validez, et profitez de performances largement supérieures, proches du natif. La différence sera d'autant plus flagrante si vous utilisez un disque dur et non un SSD pour le stockage.
La case magique à cocher !
Pourquoi cette option n'est-elle pas activée par défaut ? Simplement parce que l'utilisation d'un cache ne permet plus d'assurer la fiabilité d'écriture des données. En effet, si votre PC s'éteint brutalement (coupure de courant), toutes les données en cache qui n'ont pas encore été écrites sur le disque seront perdues. C'est d'ailleurs pour cela qu'on trouve des batteries sur certains contrôleurs matériel RAID des serveurs.
A titre personnel, je recommande de l'utiliser car le risque est plus théorique que pratique, de plus NTFS est très bon pour s'auto réparer en cas de coupure brutale. Et puis le gain de performances est tellement énorme qu'il est difficile de s'en passer après avoir essayé.
EDIT (17-08-2017) : j'ai constaté un effet secondaire, si vous exécutez plusieurs machines virtuelles en même temps il semble se produire un phénomène de saturation du cache. Et lorsque celui-ci se vide, il va provoquer d'énormes lag sur l'hôte. Du coup à vous de jauger pour voir si cela vaut la peine.
J'ai fait du tri et mis hors ligne des articles que je juge peu flatteurs, peu pertinents ou obsolètes. Ce sont principalement ceux écrits sur un coup de tête ou relatifs à l'actualité. J'ai la chance d'être le dictateur de ce blog donc j'en profite pour réécrire l'histoire.
Le blog ne tourne plus Docker car j'aimerai refaire les images et containers de manière plus propre en me basant sur l'expérience que j'ai acquis dans cette techno. Docker est pratique et bien pensé, le problème est qu'il est peut-être trop accessible donc on trouve de tout et n'importe quoi et souvent des mauvaises pratiques ou des usages détournés.
J'ai réinstallé mon serveur car il a subit de nombreux bidouillages notamment pour Docker et je voulais repartir sur une base propre. J'en ai profité pour faire sa configuration avec Ansible, avec un playbook pour les bases (timezone, locales, reseau, hostname, paquets), un autre pour installer la stack web (nginx, php-fpm, letsencrypt, ufw) et enfin un pour déployer mes sites web (avec génération du certificat let's encrypt au passage). Je peux donc le gérer sans devoir y mettre les pieds en SSH, j'en reparlerai peut être plus tard :)
Dans le monde fantastique d'Android et ARM il y a des constructeurs qui veulent absolument avoir la main sur le firmware et l'OS en refusant de partager le code source ou simplement en interdisant l'accès root. Donc vous n'avez pas le choix : la sécurité, la solidité et les mises à jour sont soumises à leur bon vouloir. Sauf que le paradoxe c'est qu'ils n'ont pas l'envie ou les compétences pour s'en occuper, et c'est ainsi qu'on se retrouve avec des failles inacceptables telles que ce rootkit visiblement oublié par un sous-traitant qui exécute n'importe quelle commande root sans trop se poser de questions :
Le firmware concocté par la société Ragentek dispose d’un rootkit. Autrement dit, d’un composant se chargeant au démarrage du système, possédant des droits root, pouvant exécuter n’importe quelle action et cherchant à masquer sa présence (il ne répond pas aux commandes classiques, comme PS).
C'est très grave, et ça l'est encore plus quand on sait que ces problèmes sont fréquents et que là encore il faudra attendre une mise à jour fournie par le constructeur. Mais sur les 55 modèles impactés, combien auront droit à un correctif ? Probablement très peu, un classique dans le monde des smartphones. Et Google n'y peut rien car bien qu'il soit le créateur et mainteneur d'Android, il n'est pas possible aujourd'hui de déployer des mises à jour sur l'intégralité des appareils, le matériel étant beaucoup trop différent et non standardisé.
Même sans parler de logiciel libre ou même d'opensource il est urgent que les plateformes ARM se normalisent et implémentent un BIOS ou un UEFI comme sur le x86, ce qui permettrait de se libérer des constructeurs et avoir plus de souplesse sur le système d'exploitation. Il a été démontré de nombreuses fois qu'on ne peut pas leur faire confiance car ils voient leurs produits comme des gadgets électroniques et non comme des ordinateurs pour lesquels la sécurité doit être prise au sérieux.
Quelques journalistes peu informés ont sauté sur une faille Linux pour tenter de monter un buzz à l'aide d'articles bien putaclicks. En effet il semblerait que le maintient de la touche Entrée au démarrage, sur un système protégé par le chiffrement Luks, permet d'accéder à shell root. Il n'en fallait pas plus pour voir fleurir de nombreux articles :
Mention spéciale pour Tom's Hardware et ses "millions de systèmes Linux" ...
Non, cette faille ne permet pas de contourner le chiffrement
Et heureusement, vous imaginez le malaise si une touche entrée suffit à péter un chiffrement AES ? Cette faille ouvre un shell root, mais les partitions chiffrées restent chiffrées. Donc non, on ne contourne pas le chiffrement.
Elle requiert un accès physique
Et à partir du moment où vous avez l'accès physique à une machine, il existe de nombreux moyens d'ouvrir un shell root. En voici deux exemples :
Booter un LiveCD puis faire un chroot sur le disque
Extraire le HDD et le brancher dans un autre ordinateur, puis utiliser un chroot
Donc c'est tout sauf une nouveauté, et c'est pour ça qu'on met les serveurs dans des salles sécurisées.
Conclusion
C'est un pétard mouillé qui est plus un bug qu'une véritable faille.
